「差し戻しをするとうまく承認できない問題」とどう向き合うか
システムを開発していると、しばしば品質が重要になります。あまりに低品質すぎる機能をリリースしてしまうと、ユーザーが離れたり、運用に無駄なコストが発生して非効率になったりといった問題が発生します。
そのため、一般に管理者や上位権限者は、品質を理由に作業の差し戻しを指示することがあります。あまりにバグバグのPRはマージできない、みたいなことですね。
このような差し戻し、あるいは却下を行いながら、同じ人が肯定・承認を行うのは中々難しいように感じます。特に、申請者と承認者の間に力量の差がある場合には、申請者が事前に考えきれていない観点での指摘が発生したりして、徐々に申請者が自分で考える力をなくしていく事もあります。しかし、顧客に影響を与えるような事象があったとすれば、承認者はスルーするわけにはいきません。
このような「差し戻しをするとうまく承認できない問題」は、私が過去に所属していた組織でしばしば遭遇して、また自分自身もそのような事象を経験することがありました。
この問題と、どう向き合うか。
一つの答えを見つけたので、紹介します。
チーム内にサブチームを作り、相互作用を設計する
次に示す図が、その答えです。
※他に適切な表現があまりなかったため営業と書いていますが、実際には"営業"は販売提供運用みたいなことまでやっています。開発以外の全てかも...
このチーム構造に、（勝手に）デュアルマネジメントという名前をつけました。
チーム内に、職能によるサブチームを2つ作り、そのサブチームの間で相互に依頼・フィードバックを個人が自由に行うようにします。職能チームといえど、各個人には一定の専門領域・担当があって、それがお互いにわかるようにしておき、必要な事があれば担当の人に依頼していくというイメージです。
各メンバーは、依頼を受けたら自分でそれをできるか判断して、必要ならスケジュールの調整などを申し出るようにします。各サブチームの管理者は最終的な可否を判断、ないし承認して、柔軟に対応していきます。依頼と関係なく、差し戻しが必要な場合には管理者は差し戻しを行うこともあります。
こうしてある依頼が完了したら、依頼主は自然と感謝を述べ、また称賛します。
この枠組は通常のスクラムとは並立しない事に注意します。
というのは、通常スクラムチームはこの図では右側の開発サブチームのみ、あるいはプロダクトオーナーのみ左側のサブチームといった編成になり、左側のサブチームから各メンバーに直接（スプリントバックログを飛び越えて）依頼をするのはスクラムの流儀に反します。また、スプリントゴールに影響を与えるような作業を差し込むという概念もありません。
私の実践が営業と開発によるサブチームだったので、営業と開発で話をしていますが、必ずしも営業と開発でなくてもワークするようには思っています。特に、私自身が開発の管理者に位置して仕事をしているので、しばしば開発の目線からの説明になっている部分がありますが、本質的には開発でなくても同じだと思います。
デュアルマネジメント構造がメンバーの成長を強く促す
自律の促進、承認サイクル
この構造では、メンバーに対して強い自律性が要求され、また成長を促されることになります。
例えば上図のメンバーYさんがメンバーPさんから直接依頼を受ける場合、まずメンバーYさんはその依頼に関する専門家、仕事を出来る人であるという前提で依頼を受けることになります。また、メンバーPさんが完璧に要件を整理できているという事は多くはなく、Pさんと対話をしながらYさん自身も要件を整理する事になり、必然的に主体的な振る舞いが求められます。
スケジュール等についてもYさん自身での判断が必要になります。ここでもし、自身の抱えている他のタスク等が多い場合には、Yさん自身がそれを調整することを検討し、相談します。
この対応が完了すると、Yさんは直接的にPさんから称賛を受けます。これには大きな承認機能があり、仮に管理者Bさんが品質等の問題で途中にうまく承認できない場面があったとしても、最終的な成果をもとにYさんは一定の承認を受けることができます。そうすると、Yさんの自信が強化され、担当者としてより積極的に取り組めるようになります。もちろん、Bさんが自然に承認できる場合には一層の承認を受けるという事になります。
このような承認のサイクルを実現することで、メンバーの育成をPさんを含めたチームが行うという事になります。
技術的なコーチ、QCD管理、問題解消に専念できる管理者
この構造では、管理者は承認の心配をせずに次のような事に集中できます。
- 技術的なコーチ
- QCD管理
- 問題解消（ブロッカー解消）
もちろん、管理者からも承認が出来るに越したことはありませんが、その業務のQCD的な側面を検討すると、承認ができない場合はどうしても存在します。そのような時には、チームが承認を与える ことで補うことができるのです。特に、管理者であっても別のサブチームのメンバーであれば差し戻しのような事なく一定の承認を与えることができます。
これによって、直接的な管理者からのフィードバックは純粋に技術的・仕事に関することに絞られ、品質が上がります。また承認をチームから受けられる事でフィードバックを受け入れやすくなるので、難しいフィードバックもしやすくなります。
客観的な視点からのチームの情報共有
管理者が2人いることによって、お互いの認識を共有することで相互に客観的な視点からのチームの状況を共有することができます。
これもフィードバックのしやすさや精度を向上させ、各メンバーの成長を促します。
なぜサブチームがないとうまくいかないか
実は、サブチームのない類似の構造はよく存在しているのではないかと思います。
例えば、受託開発のチームであって、管理者1名と作業者N名からなるチームは、そのような構造をしています。この同一職能・同一サブチームのとき、デュアルマネジメントと比較してどのような課題が生じているのかを振り返ってみましょう。（類似の構造との比較なので、例えばスクラムなどとの比較ではありません）
自律的に振る舞う場面が減る
同一職能・同一サブチームによる構成になると、図で示したオレンジ色の線が全てなくなるという事になります。特に依頼の量が大きく減ることになるので、依頼をきっかけにして自律的に振る舞う場面・自律性を育む場面が減ることになります。
同一職能の場合、一定の専門性はあるにしても、それぞれの人ができる事はある程度同じであるはずで、単純に依頼する必要がないという点で依頼自体が少なくなるはずですし、実際それが効率的なあり方と思われます。
同一職能・同一サブチームの場合、称賛しにくい
管理者BさんがメンバーYさんの申請を差し戻しする場合、別のメンバーZさんがその時点でメンバーYさんの申請を肯定的に捉えることが難しくなります。というのは、差し戻しの内容が正しければ、同一職能チームであればメンバーZさんにもその内容が理解できるはずで、その申請自体を肯定的に捉えるのが相対的に難しくなるということです。したがって、称賛することも難しくなりますし、称賛を受ける側としても「本当にそうか？自分の能力が足りないだけでは？」と思ってしまう状態になります。
一方で、別職能のメンバーPさんからすると、極端な言い方をすると「自分にはすぐには判断できないが、頑張っていても何か難しい事がうまくできなかったんだな」ぐらいに捉えられたり、あるいはメンバーPさんが依頼主であったとすれば 「メンバーYさんは実現のために頑張ってくれたが、自分も含めて考慮不足の点があったんだな、むしろ申し訳ない」 ぐらいに思ってもらえます。つまり、メンバーPさんが依頼主の場合には、サブチーム内で差し戻しがあったとしても、その仕事を自然に心から称えるという事が可能になります。これは、PさんとZさんの立場の違いが非常に重要で、職能や知識が違っているからこそ自然に振る舞えることがあって、それによって称賛を受ける側の影響も大きく変わります。
この称賛のしやすさ・結果の違いによって、自尊心を回復できたり、自分で考えて行動をできたり、といった違いが生まれる事になります。
管理者の判断が絶対視されがち
管理者一人のチームで管理者の差し戻しが発生するということは、つまり差し戻しに関しては管理者が絶対的であるということですが、これが繰り返し生じると、なんというか「管理者は絶対的な存在であって、その指示に従うべき」といった考え方になってしまう事があります。
一方デュアルマネジメント構造の場合、メンバーYさんが依頼に基づいて行動をしている場合には、確かに管理者Bさんの判断は差し戻しという点において絶対であるとしても、依頼であるという前提があるので「どう解決するか」という事を強く考えることになります。そのため、 「絶対視するとしてもそれはあくまでも技術的な事であって、むしろそれを踏まえて物事をどう解決するか」 という視点での行動に変わり、 指示に従うというマインドではなくて指摘を受けながら自分で物事を完遂するというマインドに自然に切り替わります。
フロー効率によるデュアルマネジメント構造の利点の説明
これまで説明してきたような効果とは別に、フロー効率の観点でもデュアルマネジメント構造には利点があります。というのは、別のサブチームからの相談に対して即座に対応を検討できるので、依頼に対するフロー効率が顕著に良くなる という事があります。
もちろん、依頼がない間は遊んでいる、つまりリソース効率を下げるという事では全くなくて、依頼がない場合には重要なタスク（だが、必ずしも急がなくてよいこと）を進めます。
この重要なタスクについては、細かく期日を決めるのではなくて、ある程度のスケジュール感は持ちつつも細かい日程のずれは許容していくという考え方で管理します。一定の差し込みを想定した大スケジュールを組みつつ、細かい動きは臨機応変にする事を許容して、それによって依頼のフロー効率を稼げる という構造が生まれます。デュアルマネジメントには、実はマネージャーが2人という意味だけではなく、重要なタスクと急ぎの依頼の2軸で管理をするという意味もあります。
必要なこと（または、構造以外でカバーすべきこと）
この運用を行う上で、個人的に重要と思ったことを記載します。ただ、これらの事項にはまだ不足があるかもしれません。
サブチーム間の相互のリスペクト
当たり前ですが、サブチームの間に相互のリスペクトが必要です。お互いにリスペクトできないと、依頼に対する称賛ができません。
テイカーや自分さえよければいいメンバーがいない
失敗を相手のサブチームに押し付けたり、あるいは自分にだけメリットがあるような事を依頼したり、といった事があると、リスペクトが欠けた場合と同様、謙虚な立場からの称賛が機能しません。
小さいスケジュールをずらせるようにしておく
各メンバーが主体的に相談や交渉を行えるには、そもそも自分でスケジュールを決める余地がある、つまりギチギチに期日が決まっていない事が重要です。
大きなスケジュールはずらさない
ただし、細かい調整を何度も行った結果として全体スケジュールがずれる、といった事は無いようにします。細かい案件の期日はなくても、事業展開上の大きな計画というものはあって、これがズレるようになると相互のサブチームのリスペクトが失われます。
管理者による進捗の悲観的な把握
スケジュールの調整などにGoを出すためには、進捗を把握していないといけません。楽観的に考えていると大変な事になるので、常に悲観的な把握はしておきましょう。
管理者無しで直接メンバー同士の交渉だけで管理されると、メンバーが失敗した場合に再調整やリカバリーの余地がなくなるので、メンバーが失敗しても調整できるように管理者がプランBを持っておくようにします。サブチーム間の相互のリスペクトを維持するために必要です。
同時にマルチタスク処理しようとすることを避ける
何かを依頼する時、その依頼したタスクを並行で処理しようとして効率が下がるのを避けるため、一度に行うことは一つになるように調整します。重要なタスクと急ぎのタスクが発生した場合に、重要なタスクと急ぎのタスクを同時に捌くのではなくて、一旦重要なタスクはペンディングにして急ぎのタスクに注力する、というようなことができるようにタスク量の管理をします。管理者がこれを意識するには、上記の進捗の悲観的な把握が不可欠です。
※もちろん、待ち時間などを利用してうまく仕事を進めることは否定しませんが、変に同時に仕事を進めようとするとおかしくなります。
振り返りの習慣化
スクラムと比較すると、単純にこの構造にするだけではレトロスペクティブに相当する動きがないので、それを取り入れる必要はあります。
むすび
デュアルマネジメントは、技術的なコーチングの意味では管理者にある程度の負荷がかかります。特にプレイングマネージャーや品質へのこだわりが強いマネージャー、およびそれを受けてきちんと仕事をしようとするメンバーがサブチームを問わず多く揃っている場合に機能します。
向き不向きもあると思うので、色々なマネジメント体制がある中で、一つの選択肢として理解いただけるとよいのかなと思います。
デュアルマネジメントという名前をつけたとき、当初は深く考えていませんでしたが、実はデュアルという言葉は以下の3つにかかっています：
- サブチームが2つあり、相互の役割が双対になっているのでデュアル
- 重要なタスクと依頼（緊急度の高いタスク）の2軸で管理するのでデュアル
- マネージャーとメンバーのそれぞれが管理するのでデュアル
チームでメンバーが育つことや、メンバーの自律性に注目した名前をつけることもできたはずで、セミホラクラシーといった名前も考えたりしていました。何かいい名前や、既に実践されている取り組みがあればぜひ教えてください。
以下、この記事を書いたきっかけについて記したポエムです。デュアルマネジメントの仕組みそのものとは関係ありません。
ポエム
はじめに「差し戻しをするとうまく承認できない問題」という問題の取り上げ方をしましたが、この問題には別の見え方もあります。
「管理者が品質についての真っ当な指摘をし過ぎると作業者が考えなくなる問題」
「想定外の事をあらゆる角度から指摘する管理者が神格化されてしまう問題」
「『管理者は正しい』『管理者の言っている事は私にはできない』という矛盾する事を、自分は管理者より劣ると言いながら自信満々で強く主張する作業者問題」
これらは、すべて本質的に同じ問題の別の見え方であると思っています。
私が尊敬している人物が、このような問題によくぶつかっていました。その人は私から見れば非常に優秀で、また努力の人でもあり、かつ謙虚な管理者でしたが、この問題は何度も発生しているように見えました。
一方で私は、同じマネジメントを受けつつ成長した事が多分にあり、その意味でマネジメントには正しい部分もあって、また少なくともその人の指摘そのものはほとんどの場合間違っていなくて、言っている事も一般論として極めて正しいように思えました。最初はその人の頭の良さによるものに見えましたが、それは実際には単純な努力や「フラットに考えれば小学生でも分かること」の積み重ねであることがほとんどに見えて、頭の良さに依存しているものではないと思うようになりました。誰でもわかるはずのこと、とでも言うべきなのでしょうか。実際、ある程度説明をすれば、ほぼ全ての人が指摘について理解を示していました。
お客様に物を提供する立場として、あるいはコーチとして人を育てる立場として、これは指摘をしないといけない、という場面は沢山あります。理想論としては、そのような重要な知識について大きな差がある状態をなくして、知識の差がなくなるまで十分に教育してから仕事をしろという事なのかもしれませんが、そのような知識が体系的にまとまっている事は多くはなく、またそもそも現在のチームにとって全く新しい事に挑戦するといった場面も少なからずありました。
そのような全く新しい物事であっても、それまでの様々な経験や執念から管理者が作業に対して指摘を出来る場合が存在していて、そのような時にどうすればよいのか。指摘を控えたからといってうまくいくイメージはなく、慎重に丁寧に指摘をすることは管理者の時間を奪うので単純計算で非効率。指摘をせざるを得ないが、指摘するとよりマイクロマネジメントに近い状態が生まれてしまう。
これは私にはめちゃくちゃ難しい問題に思えて、人生の間に解決しない問題かもな、という事をぼんやりと思っていました。単純な実力不足で生じる問題なのかもしれないけれども、本当に実力不足だけの話なのだろうか、同じやり方で成長できる事もあるのはなぜだろうか、というようなことを。
ところが、この数年で、それがうまく行っている場合がありました。私が過去に作業指示をした人の中では、間違いなく一番伸びていると言える事例ができました。ただ、それが個人のやる気や才能によるものなのか、それ以外のなにかによるものなのか、全然わからず、とりあえず仕事を続けていました。その結果、それは偶然ではなくてある程度の再現性がある事がわかってきて、その成功と失敗を比較分析して行き着いた結論が、 「開発チームのメンバーを真の意味で育てているのは、私や開発チームではなくて、営業チームである」 ということでした。つまり、私が指摘をすると承認サイクルを回しにくいのですが、私の代わりに依頼をした人たちが自然かつ素直にメンバーの仕事を称賛してくれるので、"勝手に"承認サイクルが回って、営業チームにメンバーが育てられていたのでした。思えば、私自身が「このメンバーと仕事をしたい」という事を決め手として、事業部内に開発組織が存在しなかった今の会社・事業部を選んでいて、それは今でも変わっていないので、当然といえば当然でした。
すごく難しいと思っていた指摘と承認の問題、開発/営業を超えたチームの意義、自分がなぜ今の会社に居るのか、なぜ自分たちがスクラムを選択していないか、首尾一貫感覚はどうやって養うことができるか、リソース効率とフロー効率の話...
そういった、私の最近の考えがすべて結実して「わかった」ので、その言語化のためにこの記事を書きました。
Discussion