第22章 提案を相手の意思決定に合わせる

第21章では、業種別テンプレートの仮説を小さく試し、追加、変更、中止を選べる証拠へ変えました。分析結果を時系列に並べて説明しても、経営会議が知りたい「今、何を承認するのか」には答えられません。

提案とは、調べた内容を報告することではありません。意思決定者が選択肢、根拠、危険、次の行動を比較し、責任を持って決められる形へ編集することです。

本章では、3 つの成果物を分けます。提案は推奨と根拠を示して選択を求める行為、判断票は会議前に選択肢を比較する資料、決定記録は会議後に決定と条件を残す正式な記録です。

22.1 説明する順序と判断する順序を分ける

分析者は、依頼、調査、発見、検討、結論という順で仕事をします。意思決定者は通常、次の順で知りたいと考えます。

1. 何をいつまでに決めるのか
2. 推奨する選択は何か
3. なぜ今それを選ぶのか
4. ほかに何と比べたのか
5. 何が不確実で、失敗時にどう止めるのか
6. いくら、誰が、いつまでに実行するのか

作業日誌の順ではなく、相手が判断する順に並べます。結論を先に言うことは、根拠を隠すことではありません。相手が検証すべき主張を先に示すことです。

22.2 一つの提案で一つの意思決定を求める

「新規事業について」「AI 活用について」という題名では、会議の終了条件が分かりません。

意思決定:
2027 年 1 月から 3 か月、20 社を上限に、
業種別テンプレートの限定提供へ 200 万円まで投資するか。

決定者:
事業責任者

期限:
2026 年 12 月 15 日

相談、情報共有、意見交換、承認を同じ資料へ混ぜません。複数の決定が必要なら、依存関係と決める順番を分けます。

資料と確認の重さは、金額、不可逆性、顧客損害、法令・安全、部門横断性に比例させます。少額で可逆、低リスクの判断なら、決めること、推奨、根拠、上限、中止条件、責任者だけの短いメモで十分です。

22.3 エグゼクティブサマリーを判断票にする

エグゼクティブサマリーは本文の短縮版ではありません。それだけで意思決定の骨格を確認できる1ページです。判断票には版、作成者、情報の基準日時を付けます。

決めること、推奨、成立前提、比較、主要な未知、承認条件、次の判断は必須です。ほかは重要性に応じて詳しくします。数字には期間、単位、比較対象を付けます。「売上 20% 増」ではなく、どの顧客群の、何月から何月までの、何との比較かを書きます。

22.4 結論を主張と根拠へ分ける

「段階導入を推奨する」だけでは、好みと区別できません。結論を、検証できる主張へ分けます。

結論:
200 万円の限定提供を承認し、追加投資は留保する。

根拠 1:
課題は対象顧客で反復して観測されている。

根拠 2:
手動提供では完了と支援時間に改善の兆候がある。

根拠 3:
一括開発より、設定品質と継続の未知を小さくできる。

条件:
最低現金、安全、提供能力の上限を守る。

各根拠には、事実、推定、判断を示します。観測、比較、モデル、専門判断など証拠の種類と限界も示します。出典があることと、因果関係や一般化が強いことは同じではありません。複数の弱い根拠を大量に並べても、強い根拠にはなりません。

22.5 選択肢と推奨しない理由を示す

推奨案だけを説明すると、比較を行ったか分かりません。

採用しない理由は、案を永久に否定するものではありません。どの前提が変われば再検討するかも残します。

推奨を先に示すと、後の情報がその案を基準に見えるアンカリングが起きます。現状維持を含む選択肢と評価基準は推奨を作る前に合意し、同じ基準で評価します。重要な案件では分析に直接関与していない確認者が主張と証拠を点検し、その確認者の利害関係も開示します。

22.6 不確実性と反対意見を提案に含める

提案を強く見せるために未知を隠すと、承認後に信頼を失います。次を分けます。

• 分かっていることと出典
• 推定したことと計算方法
• まだ分からないこと
• 反対結果が出たときに変える選択
• 少数意見と、その意見が正しくなる条件

「リスクがあります」では不十分です。原因、起きる結果、兆候、予防、発生時対応、責任者を書きます。安全や法令の最低条件は、期待便益で相殺しません。

反対意見は推奨者が都合よく弱めず、可能なら意見を述べた本人が要約を確認します。誰が反対したかより、どの前提と証拠が争点で、何が起きれば再検討するかを残します。

22.7 スライドを情報の倉庫にしない

1 枚のスライドには、原則として一つの主張を置きます。題名を「市場分析」ではなく、「対象市場は大きいが、初年度は支援能力が成長上限になる」のような結論にします。

本文は、題名の主張を検証する証拠だけに絞ります。詳細な計算、出典、定義、比較分析は付録へ置き、質問時にたどれるようにします。意思決定を変えない分析は資料へ詰め込まず、保管先だけを示します。

色だけで良否を伝えず、記号と文章を併用します。図表には結論、単位、期間、出典を付け、文書の見出し順と読み上げ順を揃えます。提案者が口頭で補わなくても、判断票から付録の根拠へたどれるようにします。

ただし、1 枚 1 メッセージを機械的な規則にしません。一つの意思決定に必要な比較表を無理に分割すると、選択肢を同時に見られなくなります。視線の単位と判断の単位を揃えます。

22.8 相手に合わせても事実を変えない

経営者、財務、現場、技術、法務では関心が違います。

相手に合わせるのは、順序、詳細、用語、次の行動です。都合の悪い数字を相手別に隠したり、同じ指標の定義を変えたりしません。

22.9 AI で構成と反論を検査する

AI は、資料の構造、冗長な説明、想定反論、根拠の欠落を点検できます。

意思決定者、決めること、期限、選択肢、推奨、根拠、未知、
最低条件、次の行動を示します。

1. 判断する順にエグゼクティブサマリーを構成する
2. 各主張と、それを直接支える証拠を対応させる
3. 事実、推定、判断、未検証を分ける
4. 推奨しない選択肢への最も強い反論を作る
5. 財務、現場、技術、法務の立場から不足を指摘する
6. 根拠のない強い表現と、定義の変化を指摘する
7. 新しい数字、出典、顧客発言を作らない

AI にもっともらしい出典、数値、引用を補わせません。主張と証拠の対応は原資料へ戻って確認します。機密情報は利用環境と契約を確認し、必要最小限へ匿名化します。

22.10 提案前に意思決定可能性を確認する

資料完成後ではなく、会議前に次を確認します。

• 決定者が出席し、決定権を持っているか
• 必要な確認者が事前に内容を見たか
• 選択肢と評価基準が合意されているか
• 資金、能力、安全の最低条件が確認されたか
• 追加情報が必要なら、誰がいつまでに出すか
• 承認、条件付き承認、見送り、中止を記録できるか

条件付き承認は、条件、確認責任者、期限、条件未達時の扱いを決めます。情報不足で判断できない保留は承認と区別し、待つ情報、再判断日、無決定の費用を記録します。全体を決められなくても、支出上限付きの調査など、今決められる範囲へ問いを狭められないか確認します。

事前確認は、定義、事実、実行不能な条件を会議前に直すために行います。結論への反対や未解決の価値判断まで水面下で消し、会議を追認の場にしません。会議で決められない構造上の理由を、スライドの追加で解決しようとせず、権限、参加者、事前確認、議題を直します。

22.11 決定を正式な記録へ変える

会議後は、判断票をそのまま議事録にせず、次を決定記録へ残します。

• 決定、条件、決定日時、決定者
• 決定に必要な会議体の成立条件と最終責任者
• 採用しなかった選択肢と理由
• 反対意見と再検討条件
• 成立前提と、変化時に再提案する責任者
• 実行責任者、期限、支出上限
• 翌営業日までに始める最初の行動
• 決定時に予想した結果と観測期限
• 記録の配布先と確認期限

記録担当者が作成し、決定者が内容を確認します。会議中に判断票の数字や条件が変わった場合は、版を上書きせず差分と理由を決定記録へ残します。後の結果だけで当時の判断を評価せず、その時点の情報、選択肢、手順が妥当だったかを振り返れる状態にします。

考えてみる問い

最近の提案について、「誰が、いつまでに、何を決めるか」を一文にしてください。次に、推奨、比較した選択肢、根拠、主要な未知、最低条件、次の判断を 1 ページへ並べてください。

提案とは、分析を短く見せることではありません。相手が選択肢と代償を理解し、未知を引き受け、次の行動へ責任を持てるように編集することです。

第23章では、資料だけでは解けない立場の違いを、会議の目的、論点、決定事項へ変え、合意形成を進めます。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の SaaS 事例、エグゼクティブサマリー表、AI への依頼例は、以下の資料を踏まえた本書独自の整理です。

• Barbara Minto『The Pyramid Principle』第 3 版、FT Publishing International、2026 年 ― 結論と根拠を階層化し、読み手の問いへ答える構成を参照
• U.S. Securities and Exchange Commission ― A Plain English Handbook ― 読み手を基準に、明確で簡潔な文書を設計する考え方を参照