1. てくてくラジオ
  2. 172. Disagree & commit
2025-02-03 27:00

172. Disagree & commit

サマリー

ポッドキャストエピソード172では、意思決定における「disagree and commit」という原則に深く掘り下げています。この原則は、意見が異なっていても、決定が下された後は全員がその決定を実行することを求めるもので、アマゾンのジェフ・ベゾスによって広められています。このエピソードでは、ディスアグリーアンドコミットの重要性を討論し、意見の相違をどのように解決するかの方法を探ります。特に、意思決定に必要な情報やチームでの役割分担の重要性にも触れています。

disagree and commitの概念
スピーカー 2
こんにちは、こばちえです。
スピーカー 1
こんにちは、たなけんです。
スピーカー 2
てくてくラジオは、仕事の合間にするような、ゆるい雑談を配信するポッドキャストです。
今週もよろしくお願いします。
スピーカー 1
よろしくお願いします。
スピーカー 2
はい、ではエピソード172、やっていきたいと思います。
スピーカー 1
はい、やっていきましょう。
スピーカー 2
はい、では今週なんですけど、先日ね、あの、弊社の中で、ちょっとなんかCEOがいい話をする時間があって、
その話の中でね、気になるキーワードを知ったので、言葉を知ったので、それについて今日は話してみたいと思います。
スピーカー 1
はい、話してみたい。
スピーカー 2
で、その言葉、キーワードっていうのが、disagree and commitっていう言葉です。
スピーカー 1
はい。
スピーカー 2
disagree and commitって、あと、disagree but commitっていう場合もあるみたいなんですけど、たなけんさん知ってました?
スピーカー 1
知らなかったです。
スピーカー 2
私も知らなかった。ちょっと不勉強で知らなかった。
スピーカー 1
うん。
スピーカー 2
ですが、たぶん一般的というか、知ってる人は知ってるんじゃないかと思うんですけど、ちょっと説明を最初にしますね。
はい。
えっと、wikipediaの、えっと、イングリッシュ版の方の記述を日本語に訳したのを読みます。
はい。
disagree and commitとは、意思決定が行われている間は個人が意見を異にすることは許されるが、
一旦決定が下されたら、全員がその決定を実行に移すことを約束しなければならないという経営原則である。
です。
スピーカー 1
なるほど。
スピーカー 2
なんかね、アマゾンのジェフ・ペゾスさんとかがね、
言ったとかっていうので結構、もしかしたら話題になったりとかしてたのかな、
と思います。
意見の相違とコミットメント
スピーカー 1
なるほど。
スピーカー 2
今日この絵についてちょっと話してみたいと思うんですけど、
うーん、そうだな。
パッと聞いて、
ダンケンさん的に印象とかありました?
スピーカー 1
そうですね。
すごく分かりやすい言葉だなって思いました。
まず、第1印象としては、
disagreeだけどcommit and commit。
だから、意見が異なっていても、
コミットするんだぞっていうのが、
一言で分かりやすいなってまずは思ったと。
で、あとは何だろうな、
自分たちがどれくらいできてるかなっていうのはすぐ考えましたね。
スピーカー 2
そうね、私も考えた。
自分がどうかなとかチームがどうかなっていうのを考えて、
いやー、なかなかできてないかもって思いました。
ダンケンさんどうでした?どうですか?
スピーカー 1
そうですね。
できてるかできてないかは、
割とできてるほうかもなって思いましたね。
その、言を言って、
自分の意見、
自分が思っているこうした方が良さそうっていう
意思決定にはならなかったけど、
まあ、それはそれでやるか、みたいな感じ。
ある種割り切っているというか。
スピーカー 2
ああ、そうだね。
なんか、できてないのが、
disagreeをagreeにするまで話しちゃうっていう部分が、
そこに時間かけちゃってるかもっていうところかも、
できてないって思ったの。
だから、コミットは結構決めたらそこに向けて頑張るぞってなってるけど、
決めるっていうところが効率よくできてないというか、
もうちょっとスピードアップしてもいいのではって、
このdisagree and commitを聞いて思ったかな。
スピーカー 1
なるほどね。
なんか、disagreeとagreeのすごい解釈が難しいなという部分もあるんですよ、僕の中では。
スピーカー 2
ああ、確かにね。
スピーカー 1
なんか、賛成です。そうした方が良いと思いますっていうのと、
agreeって結構、かなり確信を持っている時だったりするなって思ってて、
どっちでもいいなとか、一旦やってみたら分かるでしょうみたいなやつとか、
あとは、自分はどっちかというとそうは思わないdisagree側なんだけど、
相手の言っていることも分からんでもないというか、理解はできるな、
共感はできないけど理解はできる、理屈は分かるなみたいな。
そこまでいったら、もう決める担当者というかオーナーに任せるっていう、
そういう考えもあるよね。やってみよう。
やってみた後に、やっぱりちょっと違ったかもねって振り返るか、
逆に、その通りで、そっちの意思決定ですごいgoodな感じで進んだじゃん、みたいな。
自分の当時の考えはちょっと逆にずれてたな、みたいなことが分かったりとかするから。
そうだね。
アグリーまでやろうとしちゃうの、アグリーっていうのが、
なんか結構解釈が揺れそうだなって思いましたね。
スピーカー 2
そうですね。
みんながその方法でいいじゃんってなるまで、分かるまで調べたりとか、
確実性を上げようとしちゃうかもなと思って、
何が分かったら判断できるんだろうみたいなところの、
その判断材料集めがちだなと思ってて、
でもなんかその、それって100%分かることってないじゃないですか。
スピーカー 1
ないですね。
スピーカー 2
だからそれってある程度のところで、
じゃあもうこのくらいで行ってみよう、みたいな意思決定をしなきゃいけないと思うんですけど、
記録と振り返りの重要性
スピーカー 2
そこら辺をどの程度にするか、
もうちょっと改善の余地ありかなって自分自身に対して思った。
スピーカー 1
なるほど、めちゃめちゃいいですね。
なるほどね。
確かに逆になるべく近づけようとしちゃうのはあるかもね。
スピーカー 2
みんなの賛成意見を集めて安心しようとしちゃうみたいなところとか、
失敗したくないみたいな気持ちも出ちゃうから、
っていうのがあるなーって聞いてて私は思ったのでした。
スピーカー 1
確かに。
なんかすげー心当たり、直近僕心当たりあるのが、
何かチーム内で方針2つアイデアがあって、
どっちにするかなーって話してるときに、
データ調べてみましょうかっていうことを言ったんですよ。
すごい安直に僕言ってて、
で、言った後にデータ調べたら結果、例えば何だろうな、
こういう使い方をしているユーザーが何割いたから、
アイデアAにしましょう。
思ったよりも少なくて何割しかいなかったからアイデアBにしましょう、
みたいな意思決定が仮に分岐するとして、
データを調べた結果、何パーセントって割合が分かるとするじゃないですか。
スピーカー 2
はい。
スピーカー 1
それって何だろうな、どんぐらいの割合だったら意思決定が分岐するかっていうのを
あんま考えずに、なんかとりあえず調べましょうかみたいなことを
その時言ったなーって思って、
そういう前提としてデータ集めるという作業の前に
意思決定に関わるラインはどこなんだろうっていうのを
考えてなかったし、考えた上でデータをそんなに緻密に調べる必要あるのかとか、
なんかそういう議論というかそういう思考が出てきたはずだよなと思って、
なんかすごい安直にデータ調べましょうって言ってた自分は、
なんか安心できる材料をただ求めていた、みたいなのはすごい感じたんですよね。
スピーカー 2
わかる。なんかすぐ何割あるか調べてみますか、
スピーカー 1
どれくらいの件数あるか調べてみますか、みたいなの言いがち。
スピーカー 2
結果、意思決定に関わるのはどこなんだっていうのがやっぱ大事で、
スピーカー 1
なんか一方でね、そういう趣味的にデータを調べてみて、
なんか不意に気づくこととかあったりするから、それはそれで面白いんだけど、
限られた時間の中で動く上ではやらなくてもいいことだよなとか思ったりね。
スピーカー 2
何割ぐらいだったらこれはこっちだの方がいいねとか、
基準をまず決めて調べるっていうのは良いかもしれないですね。
スピーカー 1
そうですね。
スピーカー 2
なんかいろんなことを決めるっていうのもそうだし、
そのコミットするっていう方も、いつまでコミットするかみたいのも決めたいよね。
スピーカー 1
そうですね。
スピーカー 2
なんかdisagree and commitのいいところって、
多分早く決めて早く失敗して、ダメならすぐに早く失敗して、
じゃあもう1回次のループを回すっていうのが早くできるっていうのが多分メリットだと私は理解してるんだけど、
その早くも決められないし、いつまでやればいいのかもわかんないしだと早くないもんね。
やるんだったらやる条件というか、いつまで試してみるかみたいなのを決めておくのがやっぱり良さそう。
スピーカー 1
そうなんすよね。
いつまでっていうのは決まらないと、じゃあこの意思決定に今後ずっと従わなきゃいけないのかとかね、
そういうことになるから、そうじゃないし意思決定の連続であってみたいな変わっていくものであって、
その中でもいつまではちょっとこれをしっかり実行しようかっていうのを決める。
例えば案Aと案Bがあって、Aを今月末まで、24時までやりますみたいな。
なったら逆にBは絶対にやらないみたいなことがなんか大事だと思ってるんですよね。
スピーカー 2
その間はね。
スピーカー 1
そうそうその間はね。
で、それBもやっぱりBもやった方がいいと思うからBにするわとか言ってて、AとBが同時に走ってたりとか。
ね、そうそう。
もちろんそれは今のA、Bって言いながら、A、Bテストとかだったらいいんだけど。
スピーカー 2
そういうちゃんとしたね。
スピーカー 1
そうそうそう。
スピーカー 2
一応持ち合うんだったらいいけどね。
スピーカー 1
そういうやつだったらいいんだけど、そうじゃない、中途半端に結果が混ざるようなことをやると、
結局その今月末の24時を過ぎた後で、結局どっちが良かったんだろうねみたいな話になったりするので、
振り返りがすごくしにくい。で、次の意思決定につなげにくいと思うんで。
スピーカー 2
そうだね。
スピーカー 1
やらないっていうこと、なんかやることを決めることはやらないことを決めることなんだよなみたいな話はよくあると思うんですけど。
スピーカー 2
確かに。
スピーカー 1
それはめっちゃ大事なんだよなって思いますね。
スピーカー 2
振り返りも大切だしね。
なんかみんなで話してて、これでいこうってみんなで話し合った後に、
で、じゃあそれで進み始めてますってなった後に、たまにやっぱりこの方がいいんじゃないですかねって、
あっちの方なんでこれやんないんでしたっけみたいな議論、再伝させるパターンあるじゃないですか。
スピーカー 1
あるあるある。
あれなんか自分もやってきてるかもしれないし、やられた時めっちゃイラッとするんですよね。
やってるかもしれないけど、だからやんないようにしないとなって常に思ってる。
それね、あのやんないことを決めた時に、なぜやらなかったのかの記録を残すことがめっちゃ大事だなって思ってて。
スピーカー 2
ほんとだね、そうそう。
スピーカー 1
大抵忘れる、ほんとに。あれこれなんでこれやんな、こうしようと思ってたってアイデアもありましたよねとか言って、
あれなんか確かにあった気がするけど、なんでそれやんなかったんだっけっていうのを、
僕のチームの場合どっかに書いてあるんですけど、書く場所が一時期分散してて、
いろんな朝会とか、いろんな共有会とかでちょっとそのページにメモしておくみたいなやつで、
分散してて、今はちょっと議題ごとのページを別途作って必ずそっちに書きましょうっていう風に結構寄せてるんですけど、
いいですね。
分散してて、あれ絶対話したはずだけどそれ書いてあったのどこだっけみたいなやつとか、
そう、その辺がちゃんとまとめきれてないっていう時があったんで、
それはなんかすごい、なぜやらないのか、なぜやるのかの議論はせっかくした議論がね、再念するともったいないので、
どっかに記すっていうのは大事だなって思ってますね。
スピーカー 2
ね、ほんとだね。
その時の議論再念ってわけではないけど、
今ある仕様が何でこの仕様になってるのかって、後から入ってきた人分かんなかったりするじゃないですか。
スピーカー 1
そうする、はい。
スピーカー 2
そのためにも何か記録が残ってるのはやっぱいいですよね。
スピーカー 1
大事ですね。
スピーカー 2
何でこの仕様になってるんですかっていうのを、あまり残ってなくて、私がいるプロダクトでも。
結局昔からいる人に聞いて、もう句伝の物語みたいになったりするので、
もうどっかでドキュメント残さなきゃなって思ってる。
スピーカー 1
なるほど。僕らのチームの方、そっちのチームもあるかもしれないけど、
アーキテクチャーディシジョンレコードみたいなノーション、ありますか?
ないです。
スピーカー 2
ないですか。
スピーカー 1
そっちに結構大きめの、そんなに大きくなくても、
DB設計、新しいテーブルからも追加しますとか、っていうやつとかはそれなりに残ってたりしますね。
スピーカー 2
いいですね、そう。やりたいんですよね。ADR的な記録残すやつ。
スピーカー 1
でもなんか最近、新しいメンバーからの疑問で来たのは、
意思決定の背景
スピーカー 1
なんでクライアントサイドとサーバーサイド、レポジトリ分かれてるんですよね、僕のチームの方は。
なんでこれモノレポじゃないんでしたっけ?なんで分かれてるんでしたっけ?っていう話が出てきて、
それは記録が残ってなくて、そっか、確かに、みたいな感じになって。
で、開発当初の、外部にお願いしていた時期もあって、
スピーカー 2
その時の意思決定がそのままなんで、誰もなぜそうしたのかっていうのは知らないっていう結論でした。
謎になった。
謎であるということが分かった。
そういうこともある。
スピーカー 1
だからモノレポにしない理由はないんだなっていうところまで分かったけど、
そういうのも結構大変だよね、実際すでに動いてるアプリケーションを。
丁寧にやっていく必要があるんで、ちょっと大変だよねっていうので、
仮にモノレポにしたいってなっても、ちょっとまだ腰は重いかもね、みたいな話はしてましたけど。
スピーカー 2
確かに、ディスアグリアンドコミットの話に戻ると、
これね、なんかどうやってうまくやっていけるのかな?
そのディスアグリ自体も、自分の意見を言うだけじゃなくって、
相手の意見を尊重しつつ、自分の意見をちゃんと説明できなきゃいけないじゃないですか。
スピーカー 1
そうですね。
スピーカー 2
ただ反対っていうだけじゃなくて、
だからやっぱりその自分の意見を筋道立てて説明できることだったりとか、
あとその前提として、そもそも自分の意見を持つところまで、
対象に対しての理解が進んでいるかどうかっていうのも大切だなと思うんで、
まあ自分のスタンス取るっていうところにつながると思うんですけど、
そこがまずはできるようになって、みんなができるようになっていくのが大切そうだなって思います。
スピーカー 1
なるほど。
スピーカー 2
だから経緯を把握できるっていうのも、自分の意見を言うためのインプットになるかなって思ってる。
スピーカー 1
確かにな。
でもなんか意見を持ちづらいシチュエーションとかもあるとも思ってて、
例えばAとBっていう案があって、
なんとなくBは嫌だと思うんですよねって人が言った時に、
なんとなくが言語がちゃんとできてない状況じゃないですか。
はいはい。
で、それってちょっとチャンスだなと思って、
なんで言語ができてないのかっていうのが、
その人が例えば情報が足りてないのか、知識が足りてないのか、
判断する対象の情報が足りてないのか、判断するための技術や知識が足りてないのかとか、
そこを意見が曖昧な人がいる時って、
その人がどうやったら自分の意見をもうちょっと解像度高く言語化して言えるようになるかっていうのを壁打ちすることで、
チームにここの情報の共有が足りてないとか、
ここの知識がないとこれ、知識とかスキルがないと、
ここに対してアグリディスアグリの判断ができないんだということを知るみたいなことは、
なんか結構チャンスなのかもしれないと思っていて。
スピーカー 2
それは確かに、オンボーディングとか、そういう観点ではそうかなって思いつつ、
ちょっと最初の話に戻っちゃうんですけど、
じゃあみんな理解して、みんな同じレベルまで知識を高めた上で意思決定しましょうって、
結構やりたがるってきた気がしてて。
そうするとみんなが同じ状態になるまで時間をかけてってなるから、スピード落ちるんですよね。
スピーカー 1
そうですね。
スピーカー 2
なので、分かんない、判断する材料が少ないですとか、
っていうのはもちろん材料は出さなきゃいけないと思うんですけど、
そもそも前提知識として新しく入ったメンバーとかが、
知らないことが多いから判断できませんっていうのをどこまで揃えるか、
意思決定の場面でそれをどこまで揃えていくかは結構難しいかなって思った。
ゲームと仕事の共通点
スピーカー 1
そうですね。
中長期的にはスピード上がると思うんですけどね、意思決定のための情報を育てるみたいな。
スピーカー 2
そうです。
スピーカー 1
単発で見るとちょっと一個一個の判断は時間がかかるかもしれない。
だから期待値にもよるんだよな、そのメンバーに、
例えばデブ同じ開発チームのメンバーだったらある程度、
何だろう、意思決定に必要な情報は揃っていた方が多分良いし、
技術専門の違う、例えばセールスのメンバーとかに、
技術の話を完全に理解してもらった上で納得してもらうのは、
さすがにやりすぎだから、みたいな。
確かにね。
その相手に対してどういう観点での意思決定を期待するかにももちろんよる、
とも思いますよね。
スピーカー 2
そうだね。
参考サイトとしてまたちょっとリンク貼っておくんですけど、
70%の情報ルールっていうのを書いてあって、
70%の情報が集まったあたりで判断は、
大概の判断は行うべきであるっていうのをベゾズさんが言いましたっていう話が書いてあって、
やっぱなんか、完全にみんなが同じだけの情報を理解した上で判断を行うとか、
材料としても100%の材料を集めて判断を行うとかではなく、
やっぱ70%ぐらいを目安に、
人数なのかみんなのそれぞれの理解度なのかちょっとわかんないけど、
たぶん雰囲気70%で判断していこうぜっていう感じな気がしてる。
スピーカー 1
なるほど、確かに。
スピーカー 2
ここね、たぶんいろんな理解があると思うから、
私もよくわかってないし難しい部分だと思うんだけど、
前で前でで判断していこうっていうのがいいのかなって最近は思ってる。
スピーカー 1
そうですね。
確かにな。
完全に情報が揃うのを待っていたら遅いっていうのは本当にそうだろうな。
スピーカー 2
走りながら理解してもらうとかね、走りながら情報を集めるっていう感じにしないといけないってことだよね、きっとね。
スピーカー 1
そうですね。
スピーカー 2
ふわふわっと話してきましたけど、
スピーカー 1
Disagree and Commitについて話しておきたいことありますか?
そうだな、一応メモに書いたのは、なんかゲームでも同じだなってなんか思ってて、
チームを組んで、3人1チームとか4人1チームとか、あるいはもうちょっと多い人数で1チームとかで組んでやるゲーム、対戦ゲームとかって、
よく見たりとか自分自身やったりすることあるんですけど、そういうのって意思決定する人が決まってて、
大体役割を決めるんですよね、ゲームの種類にもよりますけど、この人がなんかリーダー、
ゲームの中で意思決定をするリーダーだっていうのを決めて、
その人の指示に従ってチーム全体でフィールドどっちに動くとか、どの場所を取るとか、どういう攻撃をするとか、
どういうふうに守るとか、なんか決めて動くんですよね。
それが戦略としてチームの動きになって勝敗を分けるという感じなんですけど、
なんかそのあたりがもう決めたことは守る。
決めたことに反することをやってると、やっぱり振り返りの時に振り返りがすごく精度が下がるというか、
いうところもすごいあるなーって思うし、ゲームで特徴的なのはプレイ時間が5分間って例えば決まってたりとか、
こうなったらゲームは終了しますっていうのが明確に決まっているので、
そこまでっていう、さっきまで話してた、いつまで実行するかを決めるっていうのがゲーム側が決めてくれてる。
スピーカー 2
なるほど。
スピーカー 1
なのでそれを守った上で1ゲームやりきって振り返りをして、じゃあ次のゲームはこういう戦略でいこう。
ゲーム中の意思決定もチームメンバーの中のリーダーがするっていうのが明確になっているので、
それを繰り返してどんどんチームが強くなっていったりするんですよね。
っていうのを見てると、仕事の面でもそういうことなんだろうなーって、そういうことをやると多分チームの意思決定が強くなったり、
振り返りがより精度が上がったりとかするんだろうなーって思ってますね。
スピーカー 2
ほんとだ、なんか同じことな感じがありますね。
いいですね、ゲームが似てるわ。
スピーカー 1
大事だなって思いました。
時間を決めるのと意思決定者を決めるっていう。
スピーカー 2
時間じゃなくてもいいかもしれないですけどね、その実際の仕事の場合はね。
スピーカー 1
そうですね。
スピーカー 2
これここまでいったらもう一度立ち止まって考えてみようみたいなの決めとけばね。
こういう結果になってきたらとか。
スピーカー 1
終了条件が決まってるっていうのは多分大事なんだと思います。
スピーカー 2
そうですね、確かに確かにそれを決めとくの大切そう。
そこらへん改めて認識してやっていこう。
スピーカー 1
はい。
スピーカー 2
今回はそんなところかな。
スピーカー 1
はい。
スピーカー 2
ではエピソード172ではDisagree and Commitについて話してみました。
今回も最後まで聞いていただいてありがとうございました。
スピーカー 1
ありがとうございました。
スピーカー 2
バイバイ。
スピーカー 1
バイバイ。
スピーカー 2
70%ぐらいを目安にみんなの理解度も高め。
人数なのかみんなのそれぞれの理解度なのかちょっとわかんないけど、
多分雰囲気70%で判断していこうぜっていう。
27:00

コメント

スクロール