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