TL;DR
「Disagree & Commit」とは、意思決定のプロセスにおいて、個人が自分の意見を表明し異議を唱えることが許される一方で、一度決定が下されると、全員がその決定を実行に移すことを約束するマネジメントの原則です。
このことについてメンバーには認識してもらうだけでなく、下記のようなことも組み込み、「ためらい、懸念事項、質問」などを解消できると良いとされています。
- 沈黙は不合意とする
- 参加者の多いミーティングでは、素早くパルスチェックする
- ゴールを設定しテストして学ぶ
はじめに
組織やチームで、意思決定をする際に議論をする機会というものは幾度なくあると思います。しかし、そういった議論をする際に下記のようなことが起こったりしませんか？
- 誰かが独断で話しており、皆黙認している
- 全員の意見が一致せず意見の対立が起き、話が進まない
- 意見するハードルが高く(心理的障壁で)、傍観の立場のメンバーがいる
私も、エンジニアリングマネージャー(EM)として、チームメンバーと議論するときにこういった経験は何度もあります。
特に最悪なことは、「誰かが独断で話しており、皆黙認している」場合で、例えば「EMがそう言っているし、いいんじゃないかな」といった思考停止の状態です。このような意思決定にメンバーが参加していない状況というのは、後々実行フェーズになると必ず不満が噴出します。そして、EMとしては「議論したことなのに、何を今更…」となるわけです(体験談1)。
こういった議論で欠けていることは何かというと「合意形成」です。ただ、議論中に「ここまで合意できる？」とただ確認するだけではあまり良い結果にはならなかったです(体験談2)。各人の考えを引き出した上で、合意を取る必要があります。
でもどうやって引き出せばいいのか、そう考えていた時に知ったのがこの 「Disagree & Commit」です。このコンセプトは Intel や Amazon によって広く知られるようになったらしいのですが、私が知ったのは「プロダクトマネージャーのしごと」からでした。
今回は、この「Disagree & Commit 」について紹介します。
対象読者
- エンジニア組織で働くすべての方
Disagree & Commit とは？
まず概要をついてですが、下記のような感じです。
Disagree & Commit とは、意思決定が行われている間は個人の意見を異にすることは許されるが、いったん決定が下されたら、全員がその決定を実行に移すことを約束しなければならないというマネジメント原則である。 Disagree & Commit は、コンセンサスの欠如が不作為につながるコンセンサスの罠を回避する方法である。
また、Amazon のリーダーシッププリンシプルには、下記のような記載があります。
Have Backbone; Disagree and Commit
リーダーは同意できない場合には、敬意をもって異議を唱えなければなりません。たとえそうすることが面倒で労力を要することであっても、例外はありません。リーダーは、信念を持ち、容易にあきらめません。安易に妥協して馴れ合うことはしません。しかし、いざ決定がなされたら、全面的にコミットして取り組みます。
つまり、「Disagree & Commit」とは、意思決定のプロセスにおいて、個人が自分の意見を表明し異議を唱えることが許される一方で、一度決定が下されると、全員がその決定を実行に移すことを約束するマネジメントの原則です。
最終合意を取る際には、全員がその意思決定にコミットメントする意思が必要になります。
ここでいうコミットメントする意思というのは、反対/賛成どちらでも良く、大事なのは「決めたからには全員で取り組む」ということです。スタンスは常に反対でも良いわけです。
BUSINESS INSIDER の記事になりますが、Amazonの創業者ジェフ・ベゾス氏は下記のようなことを記したそうです。
｢たとえ同意が得られなくても、ある方向について確信があるなら、次のように言えば良い。『この件について、我々が同意できていないことは分かっている。だが私に賭けてみないか？ 反対し、コミットしないか？』と。この時点では誰にも正解は分からない。おそらく、皆がすぐにイエスと言うだろう｣
チーム内だとこう独善的に振る舞うべきではないですが、正解の分からない物事に対して意思決定し物事を前に進める仕組みであることは伺えます。
確かに、こういったルールでメンバーの意思決定に対する「自分ごと化」は促せそうな気もしましたが、肝心なメンバーの不満に対してどう向き合えばいいのでしょうか？「プロダクトマネージャーのしごと」に運用のコツが記載されていたため、そちらも触れたいと思います。
Disagree & Commit の運用について
「プロダクトマネージャーのしごと」では、この Disagree & Commit の目的は下記を表出させるために運用しているとしています。
- ためらい
- 懸念事項
- 質問
決して、反対意見を遮って意見を通すための仕組みではないことに留意する必要があります。つまり、議論することの問題点を把握・改善した状態で意思決定や合意をしたいわけです。いわゆる「リスク管理・分析」をきちんと行いたいわけです。
この Disagree & Commit についてメンバーには認識してもらうだけでなく、下記のようなことも組み込むと良いとされています。
- 沈黙は不合意とする
- 参加者の多いミーティングでは、素早くパルスチェックする
- ゴールを設定しテストして学ぶ
沈黙を不合意とすれば、メンバーの思考停止や思わぬ意見を拾える結果になりますし、「ここまで合意できる？」といった質問もパルスチェックとして有効になるように思えます。反対派に対しても、事前に成功基準や判断期間等を設けて、その意思決定の確からしさを一緒に確認することができれば不満も少なくなるように思えます。
また、個人的には議題への理解が低いメンバーも意見できるように、「心理的安全性を確保すること」も重要なのかなと思いました(アイスブレイクの時間をきちんと確保すべきかもしれない)。
おわりに
如何でしたでしょうか？
「Disagree & Commit」は、効率的な意思決定を可能にし、チーム全体での判断力を高める有効な方法です。しかし、その効果を最大化するためには、議論の過程を重視し、最終的な決定に対する納得感を持たせることが必要です。異なる意見が尊重されつつも、一つの方向に進むことで、メンバーのモチベーション維持や自分ごと化に繋がれば良いなと思っています。
参考リンク
Disagree & Commit 言及しているサイトのリンクをまとめました。