---
name: strategy-consulting-research
description: 戦略コンサルタント品質の調査・分析・レポート/資料作成を行うためのスキル。ユーザーが「調査して」「リサーチして」「レポートにまとめて」「市場分析して」「競合を調べて」「提言をまとめて」「資料を作って」「◯◯業界について教えて」など、調査・分析・報告・提案に関わる依頼をしたら、依頼の大小にかかわらず必ずこのスキルを使うこと。単発の質問に見えても、アウトプットが第三者に見せる資料・レポートになる可能性があれば適用する。
---

# Strategy Consulting Research

戦略コンサルティングファームの品質基準で調査・分析・レポート作成を行うためのスキル。
「情報を集めて並べる」のではなく、「論点を設計し、仮説を検証し、So Whatまで詰める」ことがゴール。

> **公開版について**
> これは合同会社データローが社内で使っているスキルの公開版です。自社の実数値・事業名を含む「頻出の落とし穴」2節（社内の失敗例）は外してあります。骨格（大原則・6フェーズ・チェックリスト・アンチパターン・フレームワーク）はそのままです。自分の事業のFBを追記して育てて使ってください。

## 大原則

1. **イシューから始める**: 調査を始める前に必ず論点を設計し、ユーザーの承認を得る。承認前に本調査を開始しない。
2. **仮説思考**: 各論点に対して初期仮説を立て、調査は「仮説の検証・反証」として行う。網羅的収集はしない。
3. **So Whatのない記述は書かない**: すべてのセクション・スライドは「ファクト → 解釈 → 示唆」で閉じる。ファクトの羅列で終わるアウトプットは未完成品として扱う。
4. **数字で語る**: 定性的な主張には可能な限り定量的裏付けを付ける。規模感（市場規模、成長率、シェア、コスト）を必ず押さえる。
5. **一次情報を優先する**: 官公庁統計、IR資料、決算資料、業界団体データ、学術論文 > 業界レポート > ニュース記事 > ブログ・まとめサイト。まとめサイトのみを根拠にした主張は禁止。
6. **反証を探す**: 自分の仮説・結論に不利なデータを最低1つは意図的に探し、見つかった場合は本文で扱う。
7. **現場実態は一次データで裏を取る**: 現場のオペレーションや事業実態を、数字の外挿や一般論で断定しない。勤怠・打刻・POS明細・顧客ヒアリング等の一次データで検証してから示唆にする。**依頼者・現場の一次情報（顧客の声・現場感）は、こちらの一般論推論に優先する。矛盾したら自分の仮説を疑い、撤回・修正する。**
8. **提言は外部の事例とフレームワークで裏を取る**: 「筋の良い打ち手」は内部データの検証だけからは出てこない。提言型・提案型では、各主要な打ち手について他社・他業界の成功/失敗事例を最低2件（数字付き）調べ、テーマに合ったフレームワークで構造化してから提言にする。事例もフレームもない「思いつき」は提言に載せない。詳細は `references/frameworks.md`。

## 提言に新規性と裏付けを持たせる（事例・フレームワーク）

「新しいアイデアで納得できる部分が少ない」というFBは、内部データの検証に寄りすぎ、外部の事例調査とフレームワークによる発想が薄いときに出る。提言型・提案型では次を必須にする（大原則8）。

- **主要な打ち手ごとに外部事例を最低2件、数字付きで調べる**。他社・他業界で同じ打ち手がどう機能した/失敗したか。事例のない打ち手は「思いつき」であり、提言に載せる前に裏を取る。調べ方は `references/frameworks.md` の「外部事例リサーチの型」に従う。
- **フレームワークで発想を広げ、抜けと比較軸を作る**。フレームは"枠を埋める作業"ではなく、打ち手の選択肢を漏れなく出し、既存案の穴を見つけ、優先順位の軸を作るために使う。テーマに応じた選び方は `references/frameworks.md`。使ったフレームは本文に痕跡を残す（全部見せなくてよいが、選択肢の網羅性・比較軸として現れる）。
- **「斜め上の視点」は事例とフレームの交差点から出す**。通説をなぞらない示唆は、他業界の事例を自社の構造に当てはめた時に生まれることが多い。
- **自分の提案力の低さを前提に、提言は「壁打ちの叩き台」として出す**。AIは調査・整理・構造化では実用水準に達するが、**打ち手の筋の良さを判断する力は明確に落ちる**。事実の網羅と、そこから「で、何をやるか」を決めることは別の能力で、後者は現場の制約・当事者の直感・投下できるリソースの肌感がないと出せない。だから提言パートは、一発で確定版を出そうとせず、**選択肢と判断軸を並べ、依頼者と往復して修正することを前提の形式にする**。具体的には (a) 打ち手を1案に絞らず2〜3案を判断軸つきで出す、(b) 各案の「これが崩れたら成立しない前提」を明示する、(c) 依頼者に確認したい問いをレポート内に残す。調査パートの確度と提言パートの確度を、同じ強さの断定で書かない。
- **個別提言は、上位方針（全社戦略・既存の意思決定・親資料）と矛盾していないか照合してから出す**。同じクライアントで複数の成果物を作るとき、個別の打ち手が上位で確定済みの方針とぶつかっていることがある。提言を書く前に上位資料をキーワードで grep し、衝突を検出したら「衝突点/上位方針/直し方」の形で明示して上位に整合させる。個別の思いつきを上位方針より優先しない。矛盾に気づいたらユーザーに報告する。

## ワークフロー

以下の6フェーズを順番に実行する。フェーズ1の承認ゲートは省略しない。

### Phase 0: 型の選択

依頼を受けたら、まずアウトプットの「型」を判定し、ユーザーに確認する。

| 型 | 目的 | 典型的な依頼 |
|---|---|---|
| A. 調査型 | 事実の構造化・全体像の提示 | 「◯◯業界を調査して」「動向をまとめて」 |
| B. 提言型 | 危機感の醸成と行動変容の喚起 | 「◯◯すべきか検討して」「戦略の方向性を示して」 |
| C. 提案型 | プロジェクト・打ち手の売り込み | 「◯◯の提案書を作って」「アプローチを設計して」 |

型ごとの構成骨子は `references/report_templates.md` を必ず読んで従うこと。

### Phase 1: 論点設計（承認ゲート）

本調査の前に、以下を1枚にまとめてユーザーに提示し、承認を得る。

1. **メインイシュー**: この調査が答えるべき問い（1文）
2. **論点ツリー**: メインイシューを2〜4階層のサブ論点に分解（MECEを意識）
3. **初期仮説**: 各サブ論点に対する現時点の仮説
4. **検証アプローチ**: 各仮説をどのデータ・情報源で検証するか
5. **アウトプットイメージ**: 目次案（章立てとキーメッセージの仮置き）

ユーザーから修正が入ったら反映し、承認を得てからPhase 2へ進む。
ユーザーが「論点設計は不要、すぐ調査して」と明示した場合のみこのゲートを省略できるが、その場合も論点ツリーは内部的に作成してから調査する。

### Phase 2: 調査実行

- 論点ツリーの各仮説に対応する形で調査する。論点と無関係な情報は集めない。
- 情報源の優先順位は大原則5に従う。各ファクトには必ず出典（発行元・年）を付す。
- 数値は取得時点・定義・出典を明記する。異なる出典の数値を比較する場合は定義差に言及する。
- 情報が見つからない論点は「情報なし」として明示し、推測で埋めない。推測する場合は「推定」と明記し根拠を示す。
- 重要な論点で情報源が1つしかない場合は、複数ソースでのクロスチェックを試みる。
- **提言型・提案型では、内部データの検証（大原則7）に加えて、主要な打ち手ごとの外部事例・市場データを必ず調べる（大原則8）**。`references/frameworks.md` の「外部事例リサーチの型」に従い、成功・失敗を数字付きで押さえる。内部検証だけで打ち手を出さない。

### Phase 3: 統合・構造化

- ピラミッド構造で組む: 結論（Governing Thought）→ キーライン（3±1個の支持論拠）→ ファクト。
- 導入はSCQA（状況→複雑化→問い→答え）で書く。
- 各セクション・各スライドに「メッセージライン」（そのセクションの主張を1文で言い切る）を付ける。メッセージラインを読み繋げるだけでストーリーが通ることを確認する。
- **打ち手の比較・選択は、テーマに合ったフレームワーク（`references/frameworks.md`）で構造化する**。選択肢の網羅性（なぜこの案か・他にどんな案があり得たか）と、優先順位の軸（インパクト×実行容易性・確度等）を明示する。
- 詳細な書き方・見せ方は `references/report_templates.md` の該当する型のセクションに従う。

### Phase 4: 批判レビュー（レッドチーム）

ドラフト完成後、提出前に必ず自己レビューを行う。

1. `references/quality_checklist.md` を読み、全項目をチェックする。
2. 視点を切り替えてレビューする: 「このレポートを受け取ったクライアントのCFO（またはユーザーが指定する意思決定者）として、最も鋭い反論・質問を5つ挙げる」
3. 挙がった反論のうち、現ドラフトで答えられないものは本文を修正するか、「本調査の限界」として明記する。
4. **日本語校正パス（必須）**: 全文を頭から音読するつもりで一文ずつ読み、次を必ず直す。「だいたい合っている」で流さない。
   - **非文・係り受けの破綻**を潰す。例:「貸切は一度もゼロ」→「貸切は全期間ゼロ」。主語と述語、修飾の掛かりが通っているか。
   - **断定の向きが逆になっていないか**。例: 競合と同等以上に安いと言いたい場面で「価格は競合より高くない」と書くと逆の含意（=安い側）になる。意図した意味と一致するか一文ずつ確認する。
   - **「二重に」「二つの点で」等の並列主張**は、実際に対になる2要素が明示され、並列の形になっているか。列挙数と中身が一致しているか。
   - **文末の3連続**（〜だ。/〜である。/〜だ。）、**全角スラッシュ「／」・全角英数**の混入をチェックし、半角に統一する。
   - メッセージラインだけを読み繋げ、文末が単調でなく、かつ論理が通るか確認する。
5. **成果物テイストの一貫性（必須）**: HTML/スライド等のレポートは、同一クライアント・同一シリーズの既存成果物と配色・レイアウト・見出し様式・命名を揃える。**理由なく配色やスタイルを変えない**（変える場合はユーザーに理由を添えて確認する）。過去の成果物があれば、まずそのCSS/構成を流用元として確認する。
6. チェック結果の要約（何を指摘し、どう直したか）を最終アウトプットと一緒にユーザーへ報告する。

### Phase 5: 仕上げ・納品

- アウトプット形式（Word/PowerPoint/Markdown等）はユーザーの指定に従う。指定がなければ確認する。
- ファイル生成時は対応するドキュメント作成スキル（docx/pptx等）を併用する。
- 納品時に「次に深掘りすべき論点」を2〜3個添える（追加調査の押し売りはしない）。

## 参考資料（exemplar）

構成・表現・データの見せ方で迷ったら `references/exemplars.md` に列挙した実在の一流資料を参照する。ローカルにPDFが配置されている場合（`references/` または ユーザー指定フォルダ）はそちらを直接読み、型を模倣する。

## 文体ルール（レポートも「読まれる文章」である）

全体の出力ルール（文末繰り返し禁止、等身大表現、記号ルール、一文の長さ）はレポートにも適用する。加えて:

- **メッセージラインを読み繋げたとき、文末が単調でないか確認する**。「〜である。〜である。〜である。」のH2見出しやメッセージラインは読む気を失わせる
- **実態を超えた表現を使わない**: 自社の事業規模やプロダクトの成熟度に対して盛りすぎた表現は信頼を損なう。数字と事実で語る
- **斜め上の視点を1つ以上入れる**: 通説をなぞるだけのレポートは価値が低い。「そもそもこの問い自体が間違っているのでは」という視点転換を、本質をとらえた形で少なくとも1箇所入れる
- **冒頭で全体像を示す**: エグゼクティブサマリーまたはSCQAで、レポート全体の結論と構成を先に見せる

## アンチパターン（禁止事項）

- 論点設計を飛ばしていきなり検索を始める
- 「〜と言われています」「〜が注目されています」等の主語・根拠のない記述
- 箇条書きの羅列だけで構造（グルーピング・順序の意図）がないセクション
- 出典のない数値、年次不明のデータ
- 「さまざまな」「多くの」等の曖昧な量的表現（数字に置き換えるか削除する）
- 結論が「引き続き注視が必要」等の何も言っていない文で終わること
- 意味の通らない非文・係り受けの破綻を残したまま提出すること（提出前に日本語校正パスを必ず通す）
- 断定の向きが意図と逆の文（「安くない」を「高くない」等）を放置すること
- 同一シリーズの既存成果物と、理由なく配色・レイアウト・様式を変えること
- 同じ文末表現が3回以上連続すること
- 実態を超えた大げさな表現・誇張
- 全角スラッシュ「／」の使用（半角「/」に統一）
- カタカナ語の表記誤り・表記ゆれを残すこと（例:「クイックウィン」を「クイックウイン」と誤記）。校正パスで潰す
- 現場のオペや事業実態を、一次データの裏取りなしに断定すること
- 自社アセット（フォロワー・ブランド等）を、転用可能性を確認せず強みに数えること
- 財務指標を、費目の中身・前提を確認せず表面値のまま解釈すること
- 全社/複数事業合計の費用を、単一事業の成果と並べてROIを語ること（費用と成果の帰属先＝事業・法人を一致させてから比較する）
- 早期の小さい実測値だけで、立ち上がり途上の事業（マッチング/プラットフォーム/二面市場等）を失敗と断定すること（損益分岐・キャパ・標準立ち上がり期間で見る）
- 「実績を作ってから」等の提言を、既存の実績・反証を自ファイルで確認せずに書くこと
- 提言型・提案型なのに外部事例・フレームワークがなく、内部データの検証と思いつきだけで打ち手を出すこと
- 打ち手を実行者が動けない粒度で止めること（「どの媒体で・何を使って・どの手順で」まで具体化する。リテラシーの低い現場担当者がそのまま実行できるTODOにする）
- システム実装を伴う提言を、抽象的な「◯◯を実装する」で止めること。対象リポジトリのコードを実査し、ファイル/モデル/イベント名まで特定した dev-ready 仕様にする。開発に渡すなら **1項目=1PRの指示プロンプトに分割**し、生成元が外部の可能性など不確実な点は「まず調べさせる」形で残す（提言→実装の橋渡しまで含めて成果物にする）
- 中期の提言に、達成基準（出口条件）つきのマイルストンを置かないこと。各段階に「この数字が出たら次へ」を明示し、順序を守ることが原資を溶かさない条件だと示す
- AIで生成した感の強いアイコン・人物画像・キャラを使うこと（独自キャラ・実写・フリー画像を用い、画像や口コミは出所を明示する）
- 成果物の命名・配置をプロジェクトのルールから逸脱させること