伝達・プレゼンテーションフレームワーク

伝達・プレゼンテーションフレームワーク

ユーザーの $ARGUMENTS に基づき、以下のフレームワークから適切なものを適用してください。

フレームワーク選定ガイド:

場面	推奨フレームワーク
上司への報告・メール・Slack	PREP
経営層への提案・稟議	TAPS
複雑な主張の論理構築・長文レポート	ピラミッドストラクチャー
投資家・初対面の相手への自己紹介/事業紹介	エレベーターピッチ

---

01. PREP

目的: 結論ファーストで論理的に伝えるための話法フレーム。ビジネスコミュニケーションの基本中の基本であり、あらゆる場面（プレゼン、報告、メール、Slack、1on1）で使える万能フレーム。

いつ使うか:

• 上司やクライアントへの報告・連絡
• メールやチャットでの要件伝達
• 会議での発言・意見表明
• 面接での質問回答

テンプレート:

ステップ	内容	ポイント
Point（結論）		一文で言い切る。「〜すべきです」「〜が必要です」
Reason（理由）		結論を支える根拠を1〜3つ。「なぜなら〜」
Example（具体例）		数字・事実・体験で理由を補強。「実際に〜」
Point（結論の再提示）		冒頭の結論を別の表現で繰り返し、行動を促す

記入例

場面: 週次定例会議で、マーケティング予算の再配分を提案する

ステップ	内容
Point（結論）	Q3のデジタル広告予算を、リスティング広告からSNS広告へ30%シフトすべきです。
Reason（理由）	SNS広告のCPA（顧客獲得単価）がリスティング広告の半分以下であり、同じ予算でより多くの新規顧客を獲得できるためです。
Example（具体例）	先月のA/Bテストでは、SNS広告経由のCPAが1,200円だったのに対し、リスティング広告は2,800円でした。さらにSNS広告経由の顧客はLTV（顧客生涯価値）が15%高い傾向があります。
Point（結論の再提示）	したがって、Q3ではSNS広告への予算シフトを実施し、新規獲得効率の最大化を図りましょう。具体的な配分案は来週月曜までにお出しします。

よくある失敗

1. 結論が曖昧: 「〜について検討した方がいいかもしれません」のように曖昧な表現で始めてしまう。結論は「〜すべきです」「〜を提案します」と言い切ること。
2. 具体例が抽象的: 「売上が伸びています」ではなく「前年比120%、月商3,000万円に到達」のように数字で示す。Exampleは「聞き手が映像として思い浮かべられるレベル」が目安。
3. 最後のPointが単なるコピペ: 冒頭と全く同じ文を繰り返すだけだと印象が弱い。最後のPointでは「だからこそ〜しましょう」「次のアクションとして〜」と行動喚起を含めること。

活用のヒント

• 30秒ルール: PREPは30秒〜1分で話せる長さに収める。長くなる場合はピラミッドストラクチャーを検討する。
• Reason は3つまで: 理由が4つ以上あると聞き手は覚えられない。最も強い理由を1〜3つに絞る。
• 書き言葉と話し言葉で使い分ける: メールでは箇条書きで構造を見せる。口頭では「結論から申し上げると」「理由は2つあります」と接続詞で構造を明示する。
• ネガティブな報告こそPREP: 悪い報告ほど結論を先に言うことで、相手の信頼を得られる。

次のステップ

• PREPで伝えた提案の根拠をさらに強化したい場合 → ピラミッドストラクチャー（本スキル 03）で論理構造を深堀り
• 提案の前段として問題の構造化が必要な場合 → problem スキル（ロジックツリー、イシューツリー）
• 提案内容を実行計画に落とし込む場合 → execution スキル（OKR、WBS、ガントチャート）

---

02. TAPS

目的: 相手を動かすための説得・提案フレーム。「変えなければならない」という当事者意識を持たせ、行動変容を促すことに特化している。経営層への提案、社内稟議、クライアントへの改善提案に最適。

いつ使うか:

• 経営層への新規事業提案・改善提案
• クライアントへのコンサルティング提案
• 社内稟議書の作成
• チームメンバーへの変革の呼びかけ

テンプレート:

ステップ	内容	ポイント
To be（あるべき姿）		相手が共感できる理想像を描く。定量的な目標があるとなお良い
As is（現状）		客観的なデータ・事実で現状を示す。感情的にならない
Problem（問題）		To beとAs isのギャップを明確化。「このままでは〜」という危機感
Solution（解決策）		具体的・実行可能な打ち手を提示。コスト・期間・期待効果を含める

記入例

場面: 社長に対して、カスタマーサポートのDX化を提案する

ステップ	内容
To be（あるべき姿）	顧客からの問い合わせの80%を24時間以内に解決し、顧客満足度（NPS）を業界平均の+40以上に引き上げる状態。
As is（現状）	現在の平均応答時間は48時間、NPS は+12。問い合わせの60%が「配送状況の確認」「返品手続き」など定型的な内容であるにもかかわらず、すべて人手で対応している。サポートチームの残業時間は月平均35時間。
Problem（問題）	定型問い合わせに人的リソースが圧迫され、複雑な問題への対応品質が低下している。このまま放置すると、来期の顧客数20%増加時にサポート崩壊のリスクがある。また、競合A社は既にチャットボットを導入しており、対応速度で差をつけられつつある。
Solution（解決策）	AIチャットボットを導入し、定型問い合わせの70%を自動化する。初期投資800万円、月額運用費30万円。導入期間3ヶ月。期待効果: 応答時間を48時間→4時間に短縮、サポートチームの残業50%削減、NPS +30以上を6ヶ月以内に達成。ROIは12ヶ月で回収見込み。

よくある失敗

1. To beが自社都合: 「売上を倍にしたい」ではなく、相手（経営層・顧客）が「そうあるべきだ」と共感できる理想像を描く。顧客視点・市場視点を含めること。
2. As isにデータがない: 「なんとなく遅い」ではなく「平均応答時間48時間」と定量化する。データがない場合はまず計測から提案する。
3. ProblemとSolutionが飛躍: 問題の分析が浅いまま解決策に飛ぶと説得力がない。「なぜその問題が起きているのか」の因果関係を1段階掘り下げてからSolutionを提示する。

活用のヒント

• To beから書き始める: As is（現状の愚痴）から書き始めると視野が狭くなる。先に理想像を描いてからギャップを洗い出す。
• 相手のTo beに合わせる: 提案相手が社長なら経営指標、現場マネージャーならオペレーション指標、エンジニアなら技術的指標でTo beを語る。
• Solutionは複数案を用意: 「松・竹・梅」の3案を出すと意思決定がしやすい。推奨案を明示しつつ、選択肢を与える。
• 数字の根拠を別紙で用意: TAPS本体はA4で1枚に収め、詳細データは別紙（Appendix）にする。

次のステップ

• To be / As is のギャップを深く構造化したい場合 → problem スキル（As is / To be 分析、ロジックツリー）
• Solution の実現可能性を市場面から検証したい場合 → market スキル（PEST分析、5Forces）
• Solution を具体的な実行計画にする場合 → execution スキル（WBS、RACI）
• 提案書のストーリーラインを論理的に組み立てたい場合 → ピラミッドストラクチャー（本スキル 03）

---

03. ピラミッドストラクチャー

目的: 主張とその根拠を階層構造で整理し、論理的で説得力のある文章・プレゼン・報告書を作る。マッキンゼーのバーバラ・ミントが体系化した手法であり、コンサルティング業界の標準的な思考・伝達ツール。

いつ使うか:

• 経営報告書・提案書・企画書の作成
• 複雑な主張を論理的に組み立てる必要がある場面
• 会議資料やプレゼンスライドの構成設計
• 論文・レポートのアウトライン作成

テンプレート:

            [主張（メインメッセージ）]
           ／        │        ＼
    [根拠1]      [根拠2]      [根拠3]
    ／    ＼      ／    ＼      ／    ＼
[事実] [事実] [事実] [事実] [事実] [事実]

レベル	内容	チェックポイント
主張		一文で言い切れるか？ So What?に答えているか？
根拠1		主張を直接支えているか？
└ 事実・データ		検証可能な事実か？出典はあるか？
根拠2		根拠1とMECEになっているか？
└ 事実・データ
根拠3		3つの根拠で主張を十分に支えられるか？
└ 事実・データ

構築の2つのアプローチ:

• トップダウン: 結論（主張）を先に決め、「なぜ？」を繰り返して根拠と事実を導く。プレゼン・報告向き。
• ボトムアップ: 事実・データを集め、「So What?（だから何？）」を繰り返して根拠→主張を導く。調査・分析向き。

MECEチェック: 根拠同士が「漏れなくダブりなく」整理されているかを確認する。典型的な切り口:

• 時間軸: 短期 / 中期 / 長期
• 対象軸: 顧客 / 自社 / 競合（3C）
• プロセス軸: 企画 / 開発 / 販売 / サポート

記入例

場面: 取締役会で「自社ECサイトを強化すべき」という提案書を作成する

        [自社ECサイトを優先的に強化すべきである]
           ／           │           ＼
  [収益性が高い]   [顧客基盤を     [競合環境の
                   直接握れる]      変化に対応]
   ／      ＼       ／      ＼       ／      ＼
[EC粗利率  [モール [顧客データ [リピート [大手モール [D2C
 45% vs    手数料   の自社蓄積  率がEC     の手数料    ブランド
 モール     年間     で高精度    は38% vs  値上げが    の台頭で
 30%]      2億円]   マーケ可能] モール22%] 3年で2倍]  市場拡大]

レベル	内容
主張	自社ECサイトを優先的に強化すべきである
根拠1	収益性: 自社ECの粗利率はモール経由より15pt高い
└ 事実	自社EC粗利率45% / モール粗利率30% / モール手数料 年間2億円
根拠2	顧客基盤: 自社ECなら顧客データを直接保有・活用できる
└ 事実	自社ECリピート率38% / モールリピート率22% / データ活用によるLTV向上余地
根拠3	競合環境: モール依存リスクの増大とD2Cトレンドへの対応
└ 事実	モール手数料が3年で2倍に上昇 / D2Cブランドの市場シェア拡大（年率15%成長）

よくある失敗

1. So What? が弱い: 根拠を並べただけで、主張が「だから何？」に答えていない。「売上が伸びている」→ So What? →「今が投資拡大の好機である」まで昇華させる。
2. 根拠がMECEでない: 根拠同士に重複がある（例: 「売上が伸びている」と「顧客数が増えている」は重複の可能性）。または重要な視点が抜けている。切り口を先に決めてからファクトを当てはめるとMECEになりやすい。
3. 階層の深さが不均一: 根拠1は事実が5つあるのに根拠3は1つしかない、のようなアンバランスは論理の弱さを示す。各根拠を同程度の粒度で支える。

活用のヒント

• スライド1枚 = ピラミッド1つ: プレゼンスライドの見出しがメインメッセージ、ボディが根拠と事実、という構造にする。
• 「帰納法」と「演繹法」を意識: 根拠の並べ方が「事例A + 事例B + 事例C → 共通法則」なら帰納法、「大前提 + 小前提 → 結論」なら演繹法。帰納法の方がビジネスでは使いやすい。
• 反論を想定して根拠を選ぶ: 聞き手が「でも〜では？」と思いそうなポイントを先回りして根拠に含める。
• 3の法則: 根拠は原則3つ。2つでは薄く、4つ以上は散漫になる。

次のステップ

• ピラミッドの根拠となるデータを集める段階 → market スキル（PEST、5Forces）、customer スキル（STP、ペルソナ）
• ピラミッドで構築した主張をPREPで端的に伝える → PREP（本スキル 01）
• 主張の実行計画を組み立てる → execution スキル（OKR、ロードマップ）
• 根拠の切り口をMECEに整理する → problem スキル（MECE、ロジックツリー）
• 組織的な意思決定の枠組みが必要な場合 → strategy スキル（アンゾフマトリクス、SWOT）

---

04. エレベーターピッチ

目的: 30秒〜1分で事業やアイデアの本質を伝える。エレベーターで偶然居合わせた投資家に、降りるまでの短時間で興味を持たせることが由来。新規事業の社内提案、スタートアップのピッチ、営業の初回アプローチなど「第一印象で勝負が決まる」場面に最適。

いつ使うか:

• 投資家・VCへのピッチ
• 社内新規事業コンテスト
• 展示会・カンファレンスでの自己紹介
• 営業の初回商談（アイスブレイク後の導入）
• 採用面接での自社紹介

テンプレート:

要素	内容	ポイント
対象顧客	（誰）にとって	具体的なペルソナ。「中小企業」ではなく「従業員50名以下のIT企業の経営者」
課題	（何が）問題で	顧客が日常的に感じている痛み。定量化できるとなお良い
プロダクト名	（製品名）は	覚えやすい名前。なければ仮称でOK
カテゴリ	（カテゴリ）であり	聞き手が既知のカテゴリに紐づけて理解できるようにする
主要ベネフィット	（主な価値）を提供する	機能ではなくベネフィット（顧客にとっての価値）で語る
競合との違い	（競合）と異なり	最も有名な競合を1つ挙げる
独自の差別化	（差別化ポイント）が特徴	競合が簡単に真似できない独自の強み

完成文テンプレート: 「______にとって______が課題です。______は______であり、______を提供します。______と異なり、______が特徴です。」

記入例

場面: 社内新規事業コンテストで、AIを活用した議事録自動作成サービスを提案する

要素	内容
対象顧客	週に10回以上の社内会議がある大企業のマネージャー
課題	議事録作成に毎週3〜5時間を費やしており、本来の意思決定業務に集中できない
プロダクト名	MeetingBrain
カテゴリ	AI議事録・会議アシスタントSaaS
主要ベネフィット	会議の自動録音・要約・タスク抽出により、議事録作成時間を95%削減する
競合との違い	既存の文字起こしツール（Otter.ai等）と異なり
独自の差別化	社内の業務コンテキスト（プロジェクト名・社内用語・過去の決定事項）を学習し、「誰が何を決めて、次に何をすべきか」まで自動抽出する点

完成文: 「週に10回以上会議があるマネージャーにとって、議事録作成に毎週3〜5時間を費やすことが課題です。MeetingBrainはAI議事録・会議アシスタントSaaSであり、議事録作成時間の95%削減を提供します。既存の文字起こしツールと異なり、社内の業務コンテキストを学習して意思決定事項とネクストアクションまで自動抽出する点が特徴です。」

よくある失敗

1. 機能を語ってベネフィットを語らない: 「AIで文字起こしします」（機能）ではなく「議事録作成を95%削減します」（ベネフィット）。聞き手は技術ではなく、自分にとっての価値を知りたい。
2. 対象顧客が広すぎる: 「すべてのビジネスパーソン」では誰にも刺さらない。最初は意図的にニッチに絞る。「誰のためのものではないか」を明確にすることで、かえって説得力が増す。
3. 差別化が弱い・一時的: 「UIがきれい」「安い」は差別化として弱い。競合が半年で追いつけない構造的な優位性（独自データ、ネットワーク効果、技術特許など）を語る。

活用のヒント

• 声に出して30秒で言えるか試す: 書いた完成文を実際に口に出して時間を測る。1分を超えたら削る。
• 「So What」テスト: 各要素について「だから何？」と自問する。答えられない要素は書き直す。
• 聞き手に合わせてカスタマイズ: 投資家には市場規模とスケーラビリティを強調。顧客候補にはペインポイントと解決策を強調。社内上層部にはROIと既存事業とのシナジーを強調。
• 「〜版の〜」アナロジーを活用: 「法人向けのShazam」「飲食店版のSalesforce」のように、既知のサービスに例えると瞬時に理解される。ただし、アナロジーだけに頼らず独自性も必ず補足する。

次のステップ

• エレベーターピッチの各要素を深掘りする場合:
  • 対象顧客の理解を深める → customer スキル（ペルソナ、カスタマージャーニーマップ、STP）
  • 課題の構造を分析する → problem スキル（ロジックツリー、なぜなぜ分析）
  • 競合との違いを体系的に分析する → market スキル（5Forces）、strategy スキル（SWOT、VRIO）
• ピッチ後の詳細説明資料を作る場合 → ピラミッドストラクチャー（本スキル 03）で論理構成
• ビジネスモデル全体を設計する場合 → strategy スキル（ビジネスモデルキャンバス、リーンキャンバス）
• アイデアの実現可能性を評価する場合 → idea スキル（フィージビリティスタディ、ペイオフマトリクス）

---

対話の進め方

フェーズ1: ヒアリング（状況把握）

AskUserQuestion で以下を確認する:

1. 伝えたい内容: 何を伝えたいのか？（提案、報告、説得、紹介）
2. 相手: 誰に伝えるのか？（上司、経営層、クライアント、投資家、チームメンバー）
3. 場面: どのような場面か？（会議、メール、プレゼン、商談、Slack）
4. 時間制約: 何分/何文字で伝える必要があるか？
5. 相手の前提知識: 相手はこのテーマについてどの程度知っているか？
6. 期待するアウトプット: 最終的にどのような形で出力したいか？（スライド構成、メール文面、話し言葉のスクリプト）

ヒアリングのポイント: すべてを一度に聞かず、最初は1〜2問で大枠を把握し、フレームワーク選定後に詳細を深掘りする。

フェーズ2: フレームワーク選定と提案

• ヒアリング結果に基づき、最適なフレームワークを1つ提案する
• なぜそのフレームワークが最適かを簡潔に説明する
• 必要に応じて「PREPで骨格を作り、ピラミッドストラクチャーで論理を補強する」のような組み合わせも提案する

フェーズ3: テンプレート記入（対話的に埋める）

• テンプレートの各要素について、ユーザーと対話しながら埋めていく
• ユーザーの回答が曖昧な場合は、具体化を促す質問をする
  • 「もう少し具体的に言うと？」
  • 「数字で表すとどのくらいですか？」
  • 「相手がそれを聞いて最初に思う疑問は何でしょう？」
• 各ステップで「よくある失敗」に該当していないかチェックし、該当する場合はやんわり指摘する

フェーズ4: 完成・出力

• 完成したフレームワークをMarkdownで整形して出力する
• 出力形式はユーザーの希望に合わせる:
  • プレゼン用: スライドごとの構成案（見出し + ボディ + ノート）
  • メール用: 件名 + 本文の完成形
  • 口頭用: 話し言葉に変換したスクリプト（時間目安付き）
  • 報告書用: セクション構成 + 本文
• 最後に「次のステップ」として、他のフレームワークとの連携を提案する

フェーズ5: ブラッシュアップ（オプション）

• ユーザーが希望する場合、以下の観点でフィードバックを提供する:
  • 論理チェック: 根拠は主張を十分に支えているか？飛躍はないか？
  • 聞き手目線チェック: 相手の立場で読んだとき、疑問や反論が残らないか？
  • インパクトチェック: 冒頭の一文で興味を引けるか？最後に行動を促せるか？