打ち合わせ資料は、自分が報告したいことを並べるものではなく、相手が判断するために知りたいことに答えるものです。書く前にOPQ分析で「相手の問い」を1つに絞り、その答えを頂点にピラミッド構造で根拠を組めば、文章はほぼ自動で書けます。さらに冒頭1ページを決まった型で作ると、進捗報告で終わらず論点が出る会議になります。
「で、何が言いたいの？」と返される原因
提案書や会議資料に対して、次のような反応が返ってきた経験はないでしょうか。
- 「結論から言って」
- 「長くて読めない」
- 「それで、こちらは何を決めればいいの？」
これは文章力の問題であることは少なく、書く前に考えが整理されていないことが原因です。典型的なパターンは4つあります。
- 自分が調べたこと・考えたことを、調べた順に並べている
- 根拠を10個すべて載せていて、焦点がぼやけている
- 結論が最後にあり、しかも「〜と思います」で曖昧
- 社内用語や専門用語が多く、決裁者に伝わらない
これを解消する手順が、OPQ分析 → ピラミッド構造 → 文章化の3ステップです。文章化は最後で、前の2つが固まれば文章は自然に書けます。
Step 1：OPQ分析で相手の問いを特定する
OPQは、読み手の頭の中を3つの要素で整理する方法です。
| 記号 | 意味 | 自問 |
|---|---|---|
| O（Objective） | 相手が目指している状態 | 相手は何を達成したいか |
| P（Problem） | 理想と現状の差を生んでいる問題 | 何が邪魔をしているか |
| Q（Question） | 問題を解くために相手が知りたいこと | 相手は何を聞きたいか |
Qへの答えが、資料全体の主メッセージになります。書き始める前に、次のテンプレートを埋めてください。
宛先：（名前と役職）
O：相手は何を達成したいか
P：何がそれを邪魔しているか
Q：相手の頭にある疑問を1文で（「〜は何か？」「どうすべきか？」の形）
Qを見つけるときのコツ
Qでよくある間違いは、自分が答えたい質問をQにしてしまうことです。
- 自分本位のQ：「現状分析の結果、何がわかったか？」
- 相手本位のQ：「入力作業を減らすために、どの施策から着手すべきか？」
判定基準は「そのQに答えると、相手が次の行動を決められるか」です。また、同じテーマでも相手によってQは変わります。経営層なら投資対効果、経理なら予算と回収期間、IT部門なら既存システムとの整合、現場の担当者なら「自分の作業はどう変わるか」が典型です。
Step 2：ピラミッド構造で結論と根拠を組む
主メッセージを頂点に、それを支える要約を2〜3個、その下に根拠を置きます。
［主メッセージ］Qへの1文回答（数値を含める）
├─［要約A］述語のある1文
│ ├─ 根拠（数値・事実）
│ └─ 根拠（数値・事実）
└─［要約B］述語のある1文
├─ 根拠（数値・事実）
└─ 根拠（数値・事実）
ルールは3つです。下の段は上の段を支える根拠になっていること、同じ段は漏れなく重複なく分かれていること、1段の要素数は2〜5個に収めることです。
根拠がたくさん集まったら、そのまま並べずにグループにまとめます。たとえば「伝票の二重入力」「Excel転記」「目視の突き合わせ」は「入力作業の重複」というグループに、「承認待ちの滞留」「担当者不在時の停止」は「承認フローの詰まり」というグループにまとまります。
要約は「テーマ」ではなく「メッセージ」で書く
| テーマ書き（悪い例） | メッセージ書き（良い例） |
|---|---|
| 入力作業について | 入力作業の重複をなくすと、月60時間の作業が減らせる |
| 承認フローの課題 | 承認を金額で分岐させれば、滞留の8割は解消できる |
| 〇〇の重要性 | 〇〇をしないと、月末の締めが毎月2日遅れ続ける |
要約だけを上から順に読んで意味が通れば、構造はできています。
Step 3：文章化する
ピラミッドができていれば、文章化は流し込むだけです。
- 結論を最初に書く：主メッセージを1〜2行で言い切る
- 数を予告する：「理由は2つあります」と書き、読み手に枠を作る
- 要約から詳細へ：各段落の冒頭に要約、その後に根拠を書く
- 依頼で閉じる：「〇〇の承認を〇月〇日までにお願いします」
「〜だと思います」「〜の可能性があります」「効率化」「最適化」は、数値や断定に置き換えます。調べた経緯（「検討した結果」「私は調べました」）は読み手の関心外なので削ります。
会議資料は冒頭1ページで決まる
ここからは会議で使う資料の話です。まず、その会議を開くべきかを確認します。招集前に「この会議で何を決めるか」を1行で書けないなら、開かずにメールやチャットで済ませます。進捗共有だけならテキストで十分で、会議は判断と合意のために使います。
開くと決めたら、資料の冒頭1ページに次の型を置きます。
【プロジェクト名／第N回／日付】
① 前回の振り返り：決まったこと、その後の進捗
② 今回のゴール：この会議で何を決めて帰るか
③ 全体地図：スケジュール上の「今ここ」
④ 本論：論点・選択肢・判断材料（次ページ以降）
⑤ ネクストアクション：担当・内容・期日（最終ページ）
①と②が抜けると、ただの進捗報告会議に戻ります。⑤が抜けると、翌日に「誰が何をやるんだっけ」が起きます。
相手の頭を揃える順番
本論に入る前に、相手の頭を全体から枝葉へ揃えます。プロジェクトのゴール、課題の分解（イシューツリー）、解決策の分解、今日の論点の順です。冒頭30秒で「プロジェクト全体のどこの話か」を示すだけで、議論がぶれにくくなります。
仮説と事実を混ぜない
論点にはまず仮説を立てて進めます。ただし資料の上では、事実（確認済み）・仮説（未検証）・未確認（確認待ち）を区別できるようにラベルを付けます。仮説を事実と取り違えると、間違った前提で意思決定が進みます。数字にも「月60時間削減【仮説・現場確認前】」のように付けておくと安全です。
実例：システム導入プロジェクトの第3回定例
倉庫管理システムの導入を進めていて、第3回の定例で「ハンディ端末を初期導入に含めるか」を決めたい場面を考えます。相手は物流部長です。
O：出荷ミスをなくし、繁忙期でも残業を増やさずに出荷を回したい
P：ピッキングを紙のリストで行っており、品番の読み違いが月に十数件出ている
Q：ハンディ端末は初期導入に含めるべきか、後回しでよいか？
主メッセージは「ハンディ端末は初期導入に含め、出荷頻度の高い2ラインから始めるべき」です。要約は「読み違いによる出荷ミスの大半はバーコード照合で防げる」「2ラインに絞れば端末費用と教育負担を抑えられる」の2つに整理できます。
冒頭1ページは次のようになります。
| ブロック | 内容 |
|---|---|
| ① 前回の振り返り | 入荷・棚入れの画面仕様を合意済み。在庫データ移行は先週テスト完了 |
| ② 今回のゴール | ハンディ端末の初期導入範囲を決める |
| ③ 全体地図 | 設計フェーズ60%（計画どおり）。導入範囲の確定が来週の発注期限 |
| ④ 本論 | 案1：全ライン導入／案2：2ラインから開始／案3：後回し。各案の費用と現場負担 |
| ⑤ ネクストアクション | 決定内容をもとに端末の見積を依頼（担当・期日を記載） |
「どうでしょうか」ではなく「案1〜3のどれにするか」を相手に問う形になっているので、会議の場で判断が出ます。
よくある失敗
- 進捗を並べて意見を求める：論点が設計されていないので、相手も何を判断すべきかわからない
- Qが「〇〇について」になっている：疑問形になっていないため、主メッセージが定まらない
- 根拠を全部載せる：重要な根拠が埋もれる。3つ程度に絞り、残りは別紙に回す
- 「遅れています」だけ報告する：何日・何%遅れているか、理由、回復策、判断してほしいことをセットにする
- ネクストアクションに担当と期日がない：誰のボールか曖昧なまま次の定例を迎える
- 参加者が別々の話をしている：現状の確認、あるべき姿、スケジュールなど、今日どの話を合わせるのかを冒頭で宣言していない
この記事のまとめ
- 資料は、相手が判断するために知りたいこと（Q）に答えるもの
- OPQ分析でQを1つに絞り、その答えを主メッセージにする
- ピラミッド構造で根拠をグループ化し、要約は述語のある1文で書く
- 文章は結論から書き、理由の数を予告し、依頼で閉じる
- 会議資料の冒頭1ページは、振り返り・ゴール・全体地図・本論・ネクストアクションの型で作る
- 仮説と事実はラベルで区別する
打ち合わせ資料の作成は、ロードマップのStep 4「あるべき姿を描く」で、TOBE業務フローと組み合わせて使うスキルです。論点の分解はイシューツリー、根拠の立て方は仮説思考の記事も参考になります。演習付きで学ぶなら、FDEガイドのミーティング資料作成を参照してください。スライド・演習問題・テストはlecture.iplot.jpで取り組めます。