Coinbase式、最強の意思決定法

これはRyo Iida／飯田諒くんに協力してもらってCoinbase CEOのBrian Armstrongの以下記事を翻訳したものです。意思決定のフレームワークにパラメータを設定して、各人5点を良いと思う選択肢に投票する、という定量性を加味している点はとてもユニークだと思いますので、起業家の皆さん！是非一度試してみてはいかがでしょうか。

(一部誤訳があるかもしれませんので気になる方は原文を参照ください)

この記事では、より効率的に意思決定を行うためにCoinbaseで開発されたフレームワークを紹介する。会社のコアバリューには「クリアなコミュニケーション」と「効率的な実行」というものがあり、紹介するフレームワークはこれらのコアバリューを可能にしている一例である。

以下のような意思決定の際に使用できる：

• 候補者を採用するかどうか
• 商品開発のロードマップで何を優先するか
• 他社の買収や自社の売却の是非
• プロダクトやチームをどう名付けるか

など。

もし困難な判断を迫られて、決定できずに延々と会議を続けていたり、気分が晴れなかったり、後悔するかもしれないと恐れている場合は、このフレームワークが役に立つかもしれない。

Coinbaseが開発した意思決定テンプレートも用意したので、プロセスを確認してみてほしい。Google Driveに保存して、複製したものを自分用に使ってみよう。

簡単にステップ分けすると、大きく3つである。

1. パラメーターの設定
2. 熟考
3. 最終判断

これら3ステップは一つずつみていくが、その前にまず「良い意思決定」と「悪い意思決定」はどんなものかを確認する。

良い意思決定とは何か

どんな時にフレームワークが役立つのか

会社運営における意思決定のほとんどは、リスクが低いため上層部によってトップダウンに行われる。（スタンドアップミーティングを月曜から火曜に変えるべきだろうか、など）

フレームワークが必要とされるのは、明確な基準を以って、リスクが高い意思決定をできない時である。リスクが高いということは、その意思決定が長期的に影響を及ぼす可能性があり、一度なされた判断を撤回するのにとてもコストがかかるということだ。

フレームワークを使ってもすぐに終わってしまうケースもある。（ミーティング中にフレームワークを使って15分で終了したこともあった）しかし一方で、より重要性の高い意思決定の際は何週間にもわたって検討がなされることもある。

経験を積めば、このフレームワークが意思決定の際に有益かどうかを事前に判断することができるようになる。もし事前に判断できなくても、チーム内で合意に至らなかったり次のステップが明確にならない場合に必要だと感じるだろう。

Coinbase式意思決定フレームワーク

1. パラメーターを設定する

まずは、どのように意思決定がなされるかどうかについて全員で合意形成を取る。サポートを得やすくし、後々の後悔を最小化するために、このプロセスは事前にやっておいたほうがいい。

以下のようなことに気づくだろう：

• 意思決定の期日

分析のしすぎでキリがなくなるのを防ぐために、あらかじめ期日を設定しておく。これにより、判断を待つ人たちも安心する。

• 再検討の期日

一度下された判断に対してどれくらいの期間コミットするかをあらかじめ決めておく。これにより、まだ判断の成否がはっきりする前に再検討を始めてしまうことを防ぐことが可能になる。どの意思決定も完璧ではなく、適切なコミット期間を経た再検討が必要である。責任者は下された判断があまりにもうまくいかない場合に”非常事態”として再検討を早める権限も持つ。

どんな意思決定においても、3種類の関係者がいる。

• 責任者（Decision maker）：意思決定を下す判断をする人
• 情報提供者（Input providers）：情報を提供することにより意思決定に影響を与える人
• その他関係者（Affected parties）：意思決定によって影響を受ける人

情報提供者は3–8人であるのが理想的である。8人を超えるとディスカッションをする意味がなくなってしまうからだ。意思決定が想定よりも広い範囲の関係者に影響を与える可能性があるため、影響がありそうな関係部署から少なくとも1人は情報提供者として参加してもらうようにしよう。

意思決定は大きく分けて3種類ある。

• バイナリー（二択）：yesかnoで判断がつくこと（例：採用するか否か）
• 優先づけ：強制的に物事にランクづけをすること（例：100あるうちの打ち手の中から5つ選ぶ）
• 選択：あらゆる可能性の中から1つだけ選択すること（例：商品名を決める）

一週間後に実行される完璧な計画よりも、今確実に実行されるそこそこの計画の方が良い。

- Gen. George S. Patton

意思決定の責任者は1人であるべきか、それとも複数であるべきか

多くの場合、シンプルにするために責任者は1人である方が良いだろう。しかし、その意思決定が高いリスクをはらんでいる場合、複数の責任者で判断を下すこともうなずける。（誤って「Yes」と判断する事により発生するコストが、誤って「No」と判断する事によるコストを上回る場合など）

銀行が多額の資金が絡む判断を下す際に複数の承認を得なければいけないのと同じように、リスクが高い判断を下す場合は、責任者を複数人にして各人に拒否権の行使を認めることによって適切に判断を”コントロール”しても良いだろう。

情報提供者の承認を1人ずつ取っていけばダウンサイドリスクを限りなく減らせることができるが、その一方でアップサイドも限られてくる。ベンチャーキャピタル（VC）などの分野における「yes」判断は、ほとんどの人の合意を得られない逆張り投資のような一面もあるので、安全志向に偏りすぎるのも逆に危険である。

一般的には、誤った判断を下した時のコストが許容範囲であれば、素早い判断にレバレッジをきかせられるように1人の責任者で行う。もし下す判断が不可逆的もしくは高コストな場合は、複数の責任者で行うのが良い。

2. 熟考

次に、情報提供者と意思決定責任者を一部屋に集め、情報共有を行った上で投票を行う。

• 選択肢の洗い出し

選択肢を挙げるためにちょっとしたブレインストーミングをする。多くの選択肢が出てくることを優先する為、ここでの批判はしないように。参加者がクリエイティブに発想できるような雰囲気作りを心がける。一通り終わったら、まとめられるものがないか確認する。もし二択の中から一つ選ぶ判断をする場合、これはスキップしてもらって構わない。もうすでに「yes」と「no」という選択肢があるのだから。

• 持ち合ったデータの発表

顧客、スプリットテスト、リーガルチーム、外部コンサルタントなどからデータがすでに集まっている場合は、このタイミングで共有する。もし事前に準備することができれば、あらかじめ読んできてもらうのがベター。

• 第1回目投票

全体の空気感を掴むために、まず情報提供者による投票を行う。できれば目を伏せて他の人が見えない状態で投票しよう。二択の判断の場合、「3, 2, 1」の合図で親指を上げるか下げるかで投票するのがいい。優先づけ／選択の場合、投票権を各参加者に分配し、それぞれが好きな選択肢に番号を振る。この場合も、他の人の投票をみないように投票者に伝える。

• 良い点と悪い点の議論

一番年齢(役職)が低い人から順に、先ほどの投票で自分がなぜそれを選んだかを説明する。自由に話させていいが、一定時間で区切ることも忘れずに。述べられた意見の中から、その選択肢に関する良い点・悪い点を抽出する。参加者が恥ずかしがらずに発表できるようにして、他の人の意見から何か新しいことを学ぶようにしよう。この段階で、先ほどブレストで挙げた選択肢のどれにも当てはまらない新たな選択肢が頻繁に出現するので、常に選択肢をまとめたり追加したりすることで更新しよう。

• 第2回目投票

他の人の意見を全て聴き終わったところで、2回目の投票を行い、意見の変化があるか確認する。投票結果もスプレッドシートにまとめておく。場合によってはこのタイミングで全会一致を得られる可能性もある。その場合、意思決定プロセスはこれにて完了だ。しかし多くの場合、「最終ステップ」に進むこととなる。必要に応じて、追加の議論と投票を行っても良い。しかし、いつまでに決めるかの期日ははっきりしておくように。

3. 最終判断

• 意思決定する

意思決定の責任者は1~2日かけて会議の内容を振り返って熟考し、最終判断を下す。もしベストなオプションがなかったとしても、期日までに行う。

• 判断を伝える

決定事項によって影響を受ける全ての関係者にメールを送信する。メールには、情報提供者、挙げられた選択肢、判断の根拠、再検討を行う日を含める。一つのチームとしての意思決定であるので、「参加者の誰がどちらに投票した」の情報は必要ない。

• 判断理由を保存する

Google Docsに使用したスプレッドシートを保存して、後日チェックできるようにする。あらかじめ決めておいたタイミングで、下された判断の振り返りをするために会議参加者を集めて反省会を行うのも良い。いかにして間違った判断がなされるのかというのを知れるので面白いし、たらればの話を防ぐことにも繋がる。

物議を醸す判断になる場合は、対面で知らせると感情的になる恐れがあるので、噛み砕いて理解する時間を作るという点でメールで知らせるのがよいだろう。

まとめ

組織運営において、困難な意思決定をするのはストレスの源だろうが、本来はそうであるべきではない。結果を出している組織は往往にして、それをストレスとしてみるのではなく、素早い進化を遂げ、イノベーションを起こし、そして勝利するための絶好の機会としてみている。

意思決定のプロセス上には様々な失敗しやすいポイントがあるが、経験を積めばだんだんとなって良くなっていくものだ。下に失敗しやすいケースを列挙し、覚えやすいようにキャッチーな名前にしてみた。

• たくさんのおしゃべり（Lots of chatter）：一気に全員を呼んで情報共有をするのではなく、細切れのチャットのような情報共有がダラダラと続くこと。
• 蝿の王（Lord of the flies）：参加者間に派閥ができるまで意思決定の責任者が決まらず、ズルズルしてしまうこと。*同名の映画、小説
• ギリギリでの追加（Last minute addition）：情報提供者を意思決定プロセスに追加することが遅れてしまい、ギリギリになること。
• 利害の相反（Conflict of interest）：中立的でない人が意思決定責任者に選ばれること。
• 大忙し（In the weeds）：本当は他のチームメンバーに任せられたのに、マネージャーが自ら意思決定責任者をつとめてしまうこと。
• 特権の行使（Pulling rank）：上司が意思決定責任者として誰か他の人を選び、最終決定の直前で責任者の発言を封じて自分の思うがままに議論を進めること。（どのような判断であれ、自分が委任した責任者の判断に純粋に従うべきである）
• イエスマン（Yes people）：年長もしくは地位の高い人の言うことにばかり影響されて、他の人の意見を対等に聞くことができない人のこと。
• 非本質的な承認（Accidental yes）：メール、ポツポツとした会話、もしくは忙しい参加者による余裕のない会議、によって行われた議論を踏まえて出された結論のこと。全員の同意を取れているように見えるが、判断を下すのに必要な情報をインプットしないまま行われているので、本質的ではない。
• 分析のしすぎ（Analysis paralysis）：さらなる情報が入るのではないかと期待して、期日を過ぎても判断を下せないこと。（「これをスプリットテストしてみよう」という掛け声は分析のしすぎに繋がるかもしれない）
• クリエイティビティ・キラー（Creativity killer）：選択肢の「列挙」と選択肢の「評価」を混同してしまうこと。
• 投げやり（Tearing off the bandaid）：「良い選択肢がない」ことを言い訳にして、「一番マシな選択肢を選ぶ」ことができないこと。
• 多すぎるプロセス（Too much process）：すぐさま判断を下しても良いようなリスクの低いものに対してもこの意思決定プロセスを使ってしまうこと
• 不本意な民主主義（Unintentional democracy）：意思決定責任者がベストだと思う選択肢を選ぶべきだというのを忘れて、一番票を獲得した選択肢を選ぶことに圧力が加えられること。

Coinbaseが開発した意思決定フレームワークのテンプレがここで確認できる。Google Driveに保存して、複製したものを自分用に使ってみよう。