すべてのチームが知っておくべき7つの意思決定モデル
本来なら本物の意思決定が行われるはずの会議を思い浮かべてください。8人、40分。それなのに、いつのまにか一番声の大きい意見が通り、静かな3人の声は最後まで聞かれないままです。2週間後、結局何が決まったのか、誰が責任を持つのか、誰も合意できていません。
たいていのチームに足りないのは思考力ではなく、プロセスです。ふさわしい意思決定モデルは、「選ばなければならない」から「私たちはこう選んだ、そして担当はこの人だ」までの共通の道筋をグループに与えてくれます。優秀なチームほど、まさにここでつまずきます。やっかいなのは、唯一の最良のモデルなど存在しないことです。取り消し可能な200ドルのソフトウェアの判断には、採用の決定やプロダクトの方針転換とは違うプロセスがふさわしいのです。そこで、知っておく価値のある7つのモデルを挙げます。それぞれが何か、いつ手を伸ばすべきか、簡単な例とともに紹介し、最後にシンプルな選び方を示します。
重大な判断のための構造化モデル
ある選択が高くつき、取り消しが難しいときには、あえてスピードを落とすプロセスが欲しくなります。「決定がどれだけの厳密さに値するか」という尺度の両端に、2つの古典的なモデルが位置しています。
1. 合理的（構造化）モデル
何か： 教科書どおりのアプローチです。問題を定義し、基準を設定し、情報を集め、選択肢を挙げ、各選択肢を基準に照らして採点し、最高得点のものを選び、結果を検証します。秩序立った方法で代替案を評価できるだけの情報を集められる、という前提に立っています。
いつ使うか： 時間的なプレッシャーが小さく、誤った場合のコストが分析のコストをはるかに上回るような重大な判断。ベンダー選定、重要ポジションの採用、参入市場の選択などです。
簡単な例： 給与計算サービスを選ぶチームが、5つの必須条件（コスト、連携性、サポートの応答時間、コンプライアンス対応範囲、導入の容易さ）を書き出し、4社を調査し、誰かがデモに惚れ込む前に各社を1〜5の尺度で評価します。
2. 限定合理性（満足化）
何か： Herbert Simon による合理的モデルへの修正です。現実の人間は、情報の制約、思考容量の制約、時間的プレッシャーに直面しているため、すべての選択肢を評価することはできません。そこで人は最大化するのではなく*満足化（satisfice）*します。これは Simon が satisfy と suffice を掛け合わせて作った言葉で、「十分によい」という閾値を最初に越えた選択肢を選び、先へ進むということです。
いつ使うか： 完璧な答えが探索コストに見合わない、取り消し可能で重要度の低い判断。正直なところ、日々の決定のほとんどがこれです。
簡単な例： 明日の会議室が必要だとします。12部屋すべてを比較したりはしません。8人が入れて午後2時に空いている最初の1部屋を押さえるだけです。これで完了です。
ヒント： 分析を始める前に、声に出して一つ問いかけてください。「この決定は取り消せるか？」もし1週間のうちにわずかなコストで元に戻せるなら、満足化して先へ進みましょう。合理的モデルは、取り返しのつかない判断のために取っておくのです。あらゆる決定を重大事として扱うこと自体が、一種のまずい決定です。
仕分けと割り当てのためのモデル
ときに難しいのは、選択肢の間で選ぶことではありません。そもそも何が注目に値するのか、あるいは誰が決めるべきなのかを見極めることです。次の2つのモデルがそれに取り組みます。
3. Eisenhower マトリクス（緊急 vs. 重要）
何か： Dwight Eisenhower 大統領にちなんで名付けられ、Stephen Covey によって広められた2×2のグリッドです。タスクを「緊急」と「重要」という2軸で4つの象限に仕分けます。すぐやる（緊急かつ重要）、予定に入れる（重要だが緊急でない）、任せる（緊急だが重要でない）、捨てる（どちらでもない）です。このモデルが正してくれる落とし穴は、緊急だが些末な仕事に、重要だが目立たない、実際に前進させてくれる仕事を押しのけさせてしまうことです。
いつ使うか： チームや個人がやることリストに溺れ、どの火事が消す価値のあるものか見分けられないとき。
簡単な例： サポートのリーダーが1週間を割り振ります。顧客のエスカレーションは「すぐやる」へ、四半期プレイブックの書き直しは「予定に入れる」へ、繰り返し届く「このメールを転送してくれる？」という依頼は「任せる」へ、誰も読まない社内 Slack チャンネルは「捨てる」へ。
4. DACI / RAPID（誰が推進し、承認し、貢献し、知らされるか）
何か： 大勢が関わる意思決定のための、2つの役割割り当てフレームワークです。DACI（Driver、Approver、Contributor、Informed）は1980年代に Intuit から生まれ、プロセスを回す Driver をちょうど1人、判断を下す Approver をちょうど1人指名し、Contributor が専門知識を提供し、Informed には後から状況を共有し続けます。RAPID は Bain & Company によるもので、作業を Recommend、Agree、Perform、Input、Decide に分け、DACI では曖昧になりがちな実行の明確な担当者を加えています。
いつ使うか： 「船頭多くして」になり、結局誰が決めるのか誰も分からないことが本当の問題になっている部門横断的な意思決定。日々の素早い判断には DACI を使い、ガバナンスが複雑で誰かが展開を担わなければならないときには RAPID に手を伸ばします。
簡単な例： ある価格変更は、営業、財務、プロダクトに関わります。PM が Driver、プロダクト担当 VP が Approver、営業と財務のリーダーが Contributor、より広い市場投入チームは決定が固まったあとに Informed となります。もう「待って、これって誰が決めるの？」はありません。
スピードと巻き込みのために作られたモデル
さらに2つのモデルがあり、それぞれ多くのチームを破綻させる2つの状況に対応します。時計が敵になるとき、そして他の人をどれだけ巻き込むべきか本当に分からないときです。
5. OODA ループ（速く、不確実な状況）
何か： 空軍大佐 John Boyd が1970年代初頭に戦闘のために開発したサイクルで、いまではビジネスから緊急対応まであらゆる場面で使われています。Observe（観察、何が起きているかを集める）、Orient（情勢判断、自分の経験を通して濾過する）、Decide（決定）、Act（行動）と進み、そのまま Observe に戻ります。Boyd は Orient を最も重要なステップと呼びました。同じデータを見ても、2人がまったく違うふうに読み取ることがあるからです。核心にあるのは、状況、あるいは競合が変化するよりも速くサイクルを回すという考え方です。
いつ使うか： 完全な情報を待つコストが、部分的な情報で動くコストを上回るような、速く動き不確実な局面。インシデント対応、競合の不意打ちのローンチ、横道にそれていくライブイベントなどです。
簡単な例： プロダクトのローンチ中にサイトがダウンします。オンコールチームはエラーの急増を観察し、直近のデプロイを有力な原因と情勢判断し、ロールバックを決定し、行動に移します。そしてすぐに、メトリクスが回復するかを見守るために戻り、次の手をいつでも試せるよう備えます。
6. Vroom-Yetton（チームをどれだけ巻き込むか）
何か： Victor Vroom と Philip Yetton による、一つの問いに答えるモデルです。リーダーは他者をどれだけ巻き込むべきか？それはあなたの状況を、独裁的なものから完全にグループ主導のものまで、5つのスタイルに対応づけます。一人で決める（A1）、チームから情報を集めてから一人で決める（A2）、一対一で個別に相談する（C1）、グループに相談してから一人で決める（C2）、あるいはグループに一緒に決めてもらう（G2）です。この選択は3つの要素にかかっています。決定の質が決定的に重要かどうか、定着させるために合意（バイイン）が必要かどうか、そして人々を巻き込む時間があるかどうかです。
いつ使うか： 「これは自分で決めてしまうべきか、それともチームを引き入れるべきか？」と思い悩んでいる自分に気づいたとき。常に合意をデフォルトにする、あるいは常に命令をデフォルトにするのではなく、参加の度合いをその場面に合わせるための道具です。
簡単な例： オフィスのコーヒーの注文を選ぶマネージャーは一人で決めます（A1）。同じマネージャーが、合意こそすべてであるチームのワークフロー再編を行うときには、グループセッションを開いてチームに形づくらせます（C2 または G2）。
ヒント： 人々に決定を本当に実行してもらいたいなら、決まったあとではなく、決まる前に巻き込みましょう。Vroom-Yetton の研究はこの点について率直です。合意（バイイン）は、より遅く、より参加型のプロセスを確実に正当化してくれる数少ないものの一つだ、と。「最終」決定を発表してから支持を求めるのは、順序が逆さまです。
7. 費用便益 / 加重決定マトリクス
何か： 比べにくい選択肢を比較するための採点ツールです。基準を挙げ、それぞれに重要度の重みを与え、各基準に照らしてすべての選択肢を採点し、掛けて足し合わせます。加重合計が最も高い選択肢が、紙の上では勝ちます。自分が実際に何を、どれだけ気にかけているのかを声に出して言わせてくれること、それが価値の半分です。
いつ使うか： 競合する複数の要因があり、直感が行ったり来たりし続けるような多択の決定。仕事のオファー、ソフトウェア、立地、候補者の間で選ぶときなどです。
簡単な例： 3つのプロジェクト管理ツールから選ぶとき、チームは「連携性」に30%、「価格」に25%、「使いやすさ」に25%、「サポート」に20%の重みを置き、各ツールを1〜5で採点します。すると、価格が本当の重みを持った途端、派手なお気に入りが2位に終わることが分かります。
ふさわしいモデルの選び方
7つすべてを暗記する必要はありません。必要なのは4つの問いで、その答えがふさわしい道具を指し示してくれます。
- 重要度： 重要度が高ければ、合理的モデルや加重決定マトリクスへと引き寄せられます。重要度が低ければ、満足化して先へ進みましょう。
- 取り消しやすさ： 安く元に戻せるなら、素早く緩やかに決めましょう。一方通行の扉なら、速度を落として文書化します。
- 時間： 時計が拘束条件であるとき、OODA ループはどんな入念なプロセスにも勝ります。遅すぎたよい決定は、ただの悪い決定だからです。
- 曖昧さ： 難しいのが誰が決めるか、誰の合意が必要かであるとき、問題は分析ではなく役割です。それは DACI、RAPID、あるいは Vroom-Yetton の領域です。
そして見落としやすいのがここです。たいていのチームが失敗するのは、モデルを選ぶところではなく、何を決めたかを覚えておくところです。フレームワークは、その場での明快な選択へと導いてくれます。ところが部屋が空っぽになると、根拠は薄れていき、1か月後には誰もなぜを書き留めていなかったために、誰かが一件まるごと蒸し返します。チームが会議で判断を下すとき、何が決まり、誰が責任を持つのかを記録することが、戦いの半分です。Laxis のような AI 議事録ツールは、決定とその裏にある理由を記録し、アクションアイテムと担当者を自動で抽出し、誰もが見つけられる場所に置いてくれます。だから会議が終わった瞬間に決定が消えてしまうことはありません。
会議が終わったあとに決定を失うのをやめましょう
Laxis は会議を記録し、文字起こしし、要約します。そして Zoom、Meet、Teams 上で40以上の言語にわたり、決定、担当者、次のステップを自動で抽出します。始めるための無料プランもあります。
まとめ
最高のチームとは、いつも「正しい」モデルを選ぶチームのことではありません。間違ったモデルに滑り込んでしまったことに気づけるチームのことです。昼食の注文に6基準のマトリクスを回しているチームや、緊急に感じたからと一方通行の扉の判断を5分で下しているチームのように。モデルは安上がりです。自分が誤用していることに気づくこと、それこそが本物のスキルであり、「これはどんな種類の決定なのか？」という問いが反射になるまで、チームとして声に出して練習する価値があります。
よくある質問
意思決定モデルとは何ですか？
意思決定モデルとは、問いから選択へとたどり着くための、繰り返し使えるプロセスです。論理に関するものもあります。たとえば、問題の定義から結果の評価まで6つのステップを踏む合理的モデルです。役割に関するものもあります。たとえば DACI で、1人の Driver、1人の Approver、複数の Contributor、そして Informed を指名します。要点は、道筋を明示しておくことで、チームが毎回プレッシャーの下でそれを一から作り直さずに済むようにすることです。
DACI と RAPID の違いは何ですか？
どちらも意思決定の役割を割り当てますが、強調する点が異なります。DACI（Driver、Approver、Contributor、Informed）は1980年代に Intuit で生まれ、ファシリテーションと参加を明示するため、素早い部門横断の判断に向いています。RAPID（Recommend、Agree、Perform、Input、Decide）は Bain & Company によるもので、実行のための明確な Perform 役割と承認のための Agree 役割を加えており、誰かが展開を担わなければならない複雑で多層的なガバナンスに向いています。
チームはいつ OODA ループを使うべきですか？
状況が速く動いて不確実で、完全な情報を待てないときに、空軍大佐 John Boyd が1970年代初頭に開発した OODA ループを使いましょう。Observe、Orient、Decide、Act を巡り、そして戻ります。Boyd は Orient を最も重要なステップと考えました。見たものを自分の経験を通して濾過するからです。遅く入念な選択よりも、インシデント対応、競争上の動き、ライブのローンチに適しています。
限定合理性における満足化（satisficing）とは何ですか？
満足化（satisficing。Herbert Simon が satisfy と suffice を掛け合わせて作った言葉）とは、最適なものを求めてあらゆる可能性を評価するのではなく、「十分によい」という閾値を最初に越えた選択肢を選ぶことを意味します。これは限定合理性を反映しています。現実の人間は、情報の制約、思考容量の制約、時間的プレッシャーに直面しているため、選択肢が自分の望む水準に達したところで探索をやめるのです。重要度が低く取り消し可能な判断にとって、これは正しいアプローチです。
ふさわしい意思決定モデルはどう選べばよいですか？
4つの要素を天秤にかけます。重要度、取り消しやすさ、時間、そして曖昧さです。重要度が高く取り消しにくい決定は、合理的モデルや加重決定マトリクスのような構造化モデルを正当化します。取り消し可能で重要度の低いものは満足化が向いています。時計が拘束条件であるときは OODA ループを使います。問題が主に誰が決めるか、誰が合意するかであるときは、DACI、RAPID、あるいは Vroom-Yetton に手を伸ばしましょう。
