FDE研修 AI活用PdMプログラム

戦略・業務コンサル出身メンバーが、AIを武器にクライアント案件の「プロダクト推進役(FDE型PdM)」を自走で務められる状態をつくる12週間プログラムの教材サイトです。現在はM1・M2を公開しています。

差分4領域

構造化・仮説検証・ステークホルダー管理は既存資産として教えず、以下の差分4領域のみを扱います。

公開中のモジュール

進め方

各モジュールは「自習(週3〜4時間)→ 提出課題 → 隔週ワークショップ(3時間)」で構成されます。左のメニューから教材・課題・WS運営ガイドを参照してください。

M1 プロダクト思考 モジュールガイド

目的

「分析して提案する」から「仮説を作って検証し、アウトカムに責任を持つ」へ頭を切り替える。

所要時間

• 自習: 6〜8時間(週3〜4時間 × 2週)
• 提出課題: 自習時間内で作成し、不足分は各自調整
• WS#1: 3時間

前提

• 対象は戦略・業務コンサル出身のFDE候補5〜8名。
• 構造化、仮説検証、ステークホルダー管理は既習として扱う。
• M1では、提案の正しさを説明する力ではなく、検証可能な仮説に落とし、次に作るものを決める力を扱う。

M1で身につけること

2週間の学習スケジュール

教材一覧

提出課題

自分が関わった、または想定するクライアント課題を1つ選び、以下を作成する。

• リーンキャンバス1枚
• PRD初版3〜5ページ
• 検証すべき最もリスクの高い仮説
• その仮説の検証方法

提出先と形式は assignments/課題-リーンキャンバスとPRD初版.md に従う。

WS#1の位置づけ

WS#1は、PRDの完成度を競う場ではない。
各自のPRD初版を使い、「その仮説はどう棄却されうるか」を相互に問う場である。

実施内容:

• 各自PRDデモ 7分/人
• 相互批評: 良い点1つ + 棄却可能性1つを全員が出す
• ミニ実技: 同一お題で30分ストーリーマッピング
• M2 AI実装力への接続確認

評価基準

各基準は3段階で評価し、未達は1回まで再提出できる。

01 プロダクトディスカバリー基礎

目的

作る前に検証すべき仮説を見つけ、業務課題を機会、ソリューション、検証の形に変換する。

所要時間

• 読み物: 45分
• 演習: 45分

前提

• 戦略・業務課題の構造化は既習として扱う。
• 本教材では、正しい提案を作ることではなく、作る前に何を検証するかを決める。
• 演習では自分の過去案件、またはM0の48時間実技課題で選んだテーマを使う。
• 本教材はMarty Cagan『INSPIRED』とTeresa Torres『Continuous Discovery Habits』の考え方をコンサル出身者向けに要約したものである。深掘りする場合は原典を参照する。

1. プロダクトディスカバリーとは

プロダクトディスカバリーは、作るものを決める前に、価値があるか、使われるか、作れるか、事業として成り立つかを検証する活動である。

コンサル提案では、課題の構造化、原因分析、施策案、ロードマップを作り込むことが多い。FDE型PdMでは、その前後に次の問いを置く。

• このユーザーは本当に困っているか
• その困りごとは、今すぐ解く価値があるか
• この解き方で、ユーザー行動は変わるか
• 最小の形で何を作れば、仮説を検証できるか
• 作る以外の選択肢と比べて、なぜ今これを作るのか

提案の完成度より、棄却可能な仮説の質を上げる。

2. 4つのリスク

プロダクトディスカバリーでは、少なくとも4つのリスクを分けて扱う。

この4つを混ぜると、検証が曖昧になる。
例えば「現場の入力負荷を下げるダッシュボード」を考える場合、価値リスクは「現場が本当に入力負荷に困っているか」、ユーザビリティリスクは「業務中に3分以内で入力できるか」、実現可能性リスクは「必要データを既存システムから取れるか」、事業実現性リスクは「運用責任者が継続的に見るか」である。

3. 検証してから作る

プロダクト開発では、作ってから反応を見るのではなく、作る前に最も危ない仮説を見つける。

進め方:

1. 望ましいアウトカムを書く
2. そのアウトカムを阻害している機会を洗い出す
3. 機会ごとに複数のソリューションを出す
4. ソリューションごとに4つのリスクを確認する
5. 最も外すと痛い仮説から検証する

「作らないと分からない」は最後の手段である。インタビュー、業務観察、紙芝居、クリック可能なモック、手作業の代替運用で検証できるなら、先にそれを使う。

4. 機会ソリューションツリー

機会ソリューションツリーは、アウトカムから逆算して、機会とソリューションをつなげる整理方法である。

アウトカム
  ├─ 機会A
  │   ├─ ソリューションA-1
  │   └─ ソリューションA-2
  ├─ 機会B
  │   ├─ ソリューションB-1
  │   └─ ソリューションB-2
  └─ 機会C
      └─ ソリューションC-1

書く順番は、ソリューションからではなくアウトカムから始める。

5. 例

テーマ: 提案初期検討の論点整理を早くする

アウトカム: 提案初期検討で、論点整理にかかる時間を平均2日から半日に短縮する
  ├─ 機会A: 過去提案の参照に時間がかかる
  │   ├─ ソリューションA-1: 過去提案検索ツール
  │   └─ ソリューションA-2: 業界別論点テンプレート
  ├─ 機会B: 課題、仮説、検証方法が混ざる
  │   ├─ ソリューションB-1: 提案骨子レビュー支援ツール
  │   └─ ソリューションB-2: レビュー観点チェックリスト
  └─ 機会C: 価格・体制の前提が案件ごとに曖昧
      └─ ソリューションC-1: 見積り前提の入力フォーム

この例では、いきなり検索ツールを作らない。まず「過去提案を探す時間が本当に支配的か」「論点整理の質を落とさず半日に短縮できるか」を検証する。

演習: 過去案件を機会ソリューションツリーに変換する

手順

1. 自分の過去案件、またはM0の48時間課題から1テーマを選ぶ。
2. 望ましいアウトカムを1つ書く。
3. そのアウトカムを阻害する機会を3つ書く。
4. 各機会に対してソリューションを2つずつ書く。
5. 4つのリスクのうち、最も大きいリスクを1つ選ぶ。
6. 次に検証する実験を1つ書く。

記入テンプレート

完了条件

• アウトカムが、成果物名ではなく行動・状態の変化になっている
• 機会とソリューションが混ざっていない
• ソリューションが1案に固定されていない
• 次の実験が、プロトタイプ作成より小さくできるか検討されている

02 アウトカム定義とNorth Star Metric

目的

アウトプット、アウトカム、インパクトを分け、測定可能なアウトカムとNorth Star Metricを書く。

所要時間

• 読み物: 45分
• 演習: 45分

前提

• KPIツリーや業務指標の設計経験は既習として扱う。
• 本教材では、提案上の指標ではなく、プロダクトで変えたいユーザー行動と業務状態を定義する。
• 演習ではM1提出課題で扱うテーマを使う。

1. アウトプット、アウトカム、インパクト

M1で最初に切り替えるのは、成果物起点からアウトカム起点への移行である。

アウトプットは必要だが、目的ではない。
FDE型PdMは「何を作るか」だけでなく、「作った結果、誰のどの行動が変わるか」を持つ。

2. 測定可能なアウトカムの条件

測定可能なアウトカムは、最低限次の要素を含む。

書き方:

[対象] が [行動・状態] を [現状] から [目標] に [期限] までに変える。
測定方法は [データソース] とする。

例:

案件マネージャーが、会議後のアクション項目を当日中に登録できる割合を、現状40%から4週間後に80%へ上げる。
測定方法は議事録作成日時と課題登録日時の差分とする。

3. North Star Metric

North Star Metricは、そのプロダクトがユーザーに価値を届けているかを代表する1つの指標である。
売上や稼働時間のような会社都合の指標ではなく、ユーザーが価値を得た行動に近い指標を置く。

選定条件:

• 対象ユーザーの価値獲得に近い
• チームが日々の判断に使える
• 短期の操作で不正に上げにくい
• 事業インパクトに接続できる
• 機能数ではなく利用・成果の質を表す

例:

4. 指標設計で避けること

5. 悪い例から良い例への書き換え

6. 補助指標とガードレール

North Star Metricだけでは、品質や副作用を見落とす。補助指標とガードレールを置く。

例えば「初回提案骨子作成時間」を短縮する場合、ガードレールとして「顧客レビューでの重大論点漏れ件数」を置く。

演習: アウトカムを書き換える

手順

1. M1提出課題で扱うテーマを1つ選ぶ。
2. 最初に思いつくアウトプットを3つ書く。
3. それぞれをアウトカムへ書き換える。
4. North Star Metricを1つ選ぶ。
5. 補助指標とガードレールを1つずつ置く。

記入テンプレート

書き換え演習

以下の悪い例を、自分のテーマに合わせて良い例へ書き換える。

完了条件

• アウトカムに対象、変化、期限、測定方法が含まれている
• North Star Metricがユーザー価値に近い
• 補助指標とガードレールが分かれている
• その指標を見て、次に作るものを変えられる

03 ユーザーストーリーとPRDの書き方

目的

ユーザーストーリー、ストーリーマッピング、PRDを使い、検証すべき最もリスクの高い仮説を明示した初版を書く。

所要時間

• 読み物: 60分
• 演習: 60分

前提

• 要件定義書の網羅性ではなく、次に検証するプロダクト仮説を明確にする。
• PRD初版は完成版ではない。M2で動くプロトタイプへ変換するための入力として扱う。
• 演習ではM1提出課題で扱うテーマを使う。

1. ユーザーストーリー

ユーザーストーリーは、機能をユーザー価値の形で書くための最小単位である。

As a [ユーザー],
I want to [やりたいこと],
so that [得たい価値].

日本語では次の形でよい。

[ユーザー] として、[やりたいこと] したい。
それにより [得たい価値] を得たい。

例:

案件マネージャーとして、会議後のアクション項目を議事録から抽出したい。
それにより、担当者への依頼漏れを当日中に減らしたい。

良いユーザーストーリーは、画面要素ではなく行動と価値を表す。

2. 受け入れ条件

ユーザーストーリーには、受け入れ条件を付ける。受け入れ条件は、実装完了のチェックだけでなく、検証の観点でもある。

例:

ユーザーストーリー:
案件マネージャーとして、会議後のアクション項目を議事録から抽出したい。
それにより、担当者への依頼漏れを当日中に減らしたい。

受け入れ条件:
- 議事録テキストを入力できる
- アクション、担当者、期限、優先度の候補が表示される
- 担当者と期限を編集できる
- 登録対象外の項目を除外できる
- CSVとして出力できる

3. ストーリーマッピング

ストーリーマッピングは、ユーザーの業務フローに沿ってストーリーを並べ、MVPスコープを決める方法である。

手順:

1. 対象ユーザーの主要業務フローを書く
2. 各ステップで必要なユーザーストーリーを出す
3. 価値検証に必要な最小ストーリーを1段目に置く
4. 後回しにできるストーリーを2段目以降へ下げる
5. M2で作るプロトタイプ対象を明確にする

例:

MVPは「少ない機能」ではなく「最大リスク仮説を検証できる最小の形」である。

4. PRDの構成要素

PRDは、何を作るかだけでなく、なぜ作るか、何を検証するか、何を作らないかを合わせて書く。

5. 最大リスク仮説の特定

PRDで最も重要なのは「検証すべき最もリスクの高い仮説」を1つに絞ることだ。

手順:

1. 仮説を洗い出す
2. 4つのリスクに分類する
3. 各仮説を「外した時の痛さ」と「不確実性」で評価する
4. 最初に検証する仮説を1つ選ぶ
5. その仮説を棄却できる条件を書く

評価表:

優先度は、単純に痛さ × 不確実性で置いてよい。点数は精密でなくてよい。議論すべき仮説を前に出すために使う。

6. PRDひな形 3〜5ページ版

以下をそのままコピーして使う。

# PRD: [プロダクト名]

## 1. 背景と課題

- 対象ユーザー:
- 現在の業務:
- 現在起きている摩擦:
- 既存の代替手段:
- なぜ今取り組むのか:

## 2. アウトカム

- 測定可能なアウトカム:
- North Star Metric:
- 補助指標:
- ガードレール:
- 測定データ:

## 3. ユーザーとユースケース

### 主要ユーザー

- ユーザー:
- 役割:
- 利用頻度:
- 利用場面:

### 主要フロー

1. 
2. 
3. 
4. 

## 4. 仮説とリスク

| 仮説 | リスク種別 | 外した時の痛さ 1〜5 | 不確実性 1〜5 | 検証方法 |
|---|---|---:|---:|---|
|  | 価値 / ユーザビリティ / 実現可能性 / 事業実現性 |  |  |  |

### 検証すべき最もリスクの高い仮説

- 仮説:
- 選んだ理由:
- 棄却条件:

## 5. MVPスコープ

### 作るもの

| 機能 | 対応するユーザーストーリー | 優先度 | 理由 |
|---|---|---|---|
|  |  | Must / Should / Could |  |

### 作らないもの

| 作らないもの | 理由 | 再検討条件 |
|---|---|---|
|  |  |  |

## 6. ユーザーストーリー

### Story 1

- ユーザー:
- やりたいこと:
- 得たい価値:
- 受け入れ条件:
  - 
  - 
  - 

### Story 2

- ユーザー:
- やりたいこと:
- 得たい価値:
- 受け入れ条件:
  - 
  - 
  - 

## 7. 検証計画

- 検証対象:
- 検証方法:
- 対象者:
- 使用するプロトタイプまたは代替手段:
- 成功条件:
- 棄却条件:
- 検証後の判断:

## 8. 制約・未決事項

| 種別 | 内容 | 次アクション |
|---|---|---|
| 技術 |  |  |
| データ |  |  |
| 運用 |  |  |
| セキュリティ |  |  |

演習: PRD骨子を作る

手順

1. 教材01の機会ソリューションツリーから、最初に扱うソリューションを1つ選ぶ。
2. 教材02のアウトカムとNorth Star Metricを転記する。
3. ユーザーストーリーを3〜5本書く。
4. ストーリーマップを作り、MVPに入れるものを選ぶ。
5. 仮説を5つ以上洗い出し、リスク × 不確実性で最大リスク仮説を1つ選ぶ。
6. PRDひな形の1〜8を埋める。

完了条件

• ユーザーストーリーが画面要素ではなく行動と価値になっている
• MVPスコープと作らないものが両方書かれている
• 最大リスク仮説が1つに絞られている
• 棄却条件が書かれている
• M2でプロトタイプ化する対象が読み取れる

04 コンサル提案書とPRDの違い

目的

コンサル提案書の「正しさの証明」から、PRDの「検証可能な仮説の束」へ書き換える。

所要時間

• 読み物: 45分
• 演習: 45分

前提

• 提案書作成能力は既習として扱う。
• 本教材では、提案書を否定しない。用途の違いを理解し、FDE型PdMとして必要なPRD表現へ変換する。
• 演習ではM1提出課題で扱うテーマを使う。

1. 目的の違い

提案書は「なぜこの取り組みを始めるべきか」に強い。
PRDは「何を最初に検証し、何が分かれば次に進むか」に強い。

2. 同一テーマの対比例

テーマ: 提案初期検討支援ツール

コンサル提案書としての書き方

背景:
提案初期検討では、過去提案、業界知見、想定課題、体制案、見積り前提が担当者ごとに散在している。そのため、初回提案骨子の品質にばらつきがあり、レビュー工数も増加している。

提案:
AIを活用した提案初期検討支援ツールを導入し、過去成果物の検索、論点テンプレートの提示、提案骨子の自動レビューを実現する。

期待効果:
初回提案作成時間を短縮し、レビュー品質を標準化する。将来的には提案ナレッジを蓄積し、営業・デリバリー資産として再利用する。

推進計画:
フェーズ1で要件定義とデータ整備、フェーズ2でプロトタイプ開発、フェーズ3で一部BUに展開する。

この書き方は、取り組みの妥当性を説明するには有効である。一方で、最初に何を検証するか、どの仮説が外れたら止めるかが弱い。

PRDとしての書き方

対象ユーザー:
提案リード。新規提案の初期2日間で、課題仮説、提案骨子、体制案を作る役割。

測定可能なアウトカム:
提案リードが初回提案骨子を作る時間を、現状平均2日から4週間後に半日へ短縮する。ただし、レビューで重大論点漏れが指摘される件数を増やさない。

North Star Metric:
初回レビューで「検証可能な仮説」と「想定アウトカム」を含んだ提案骨子の割合。

最大リスク仮説:
提案リードは、過去成果物検索よりも、提案骨子の仮説レビューに価値を感じる。

棄却条件:
5名中4名以上の提案リードが、紙芝居プロトタイプを使った後に「既存のレビュー観点チェックリストで足りる」と回答し、次回提案で使う意向を示さない。

MVPスコープ:
提案メモを入力すると、アウトカム、最大リスク仮説、検証方法の不足を指摘する。過去成果物検索、見積り、体制案生成は作らない。

PRDでは、作る範囲と同じくらい、作らない範囲と棄却条件が重要になる。

3. 書き換えの観点

4. コンサル出身者が陥りやすいパターン

網羅性への逃避

症状:

• 関係者、業務フロー、課題、施策をすべて並べる
• MVPが「主要機能一式」になる
• 作らないものが書かれていない

矯正:

• 最大リスク仮説を1つ選ぶ
• その仮説を検証しない機能はMVPから外す
• 後続論点は未決事項に逃がす

検証不能な提言

症状:

• 「効率化」「高度化」「標準化」で止まる
• 成功条件がアンケート満足度だけ
• 棄却条件がない

矯正:

• 対象、現状、目標、期限、測定方法を書く
• 棄却条件を先に書く
• ユーザー行動が変わるかで見る

アウトプット納品思考

症状:

• PRD、画面、プロトタイプの完成が目的になる
• 作った後の検証計画が薄い
• ユーザーに当てる前に完成度を上げすぎる

矯正:

• 成果物を「検証の道具」として扱う
• 5人に見せるために何が最低限必要かを決める
• 次に作るものではなく、次に分かることを書く

5. 提案書とPRDを併用する

FDE案件では、提案書とPRDの両方が必要になる。

M1ではPRDを作る。M5では、PRDをもとにFDE型エンゲージメントの提案骨子へ戻す。

演習: 提案書表現をPRD表現に変換する

手順

1. 自分のテーマを、まず提案書風に5行で書く。
2. その中から検証不能な表現を3つ選ぶ。
3. それぞれをPRD表現へ書き換える。
4. 作らないものを3つ書く。
5. 棄却条件を1つ書く。

記入テンプレート

完了条件

• 「効率化」「高度化」「標準化」だけで止まっていない
• 作るものより先に検証すべき仮説が書かれている
• 作らないものが明確である
• 棄却条件が第三者にも判定できる

課題 リーンキャンバスとPRD初版

目的

自分が関わった、または想定するクライアント課題を1つ選び、リーンキャンバス1枚とPRD初版3〜5ページに整理する。

所要時間

• 教材01〜04の演習成果物を再利用する場合: 仕上げ1〜2時間
• 演習を経ずに新規作成する場合: 2〜3時間

前提

• M1教材01〜04を終えた後に作成する。
• 「検証すべき最もリスクの高い仮説」の明示を必須とする。
• 完成度の高い提案書ではなく、WS#1で棄却可能性を議論できるPRD初版を提出する。

課題仕様

自分が関わった、または想定するクライアント課題を1つ選び、以下を提出する。

1. リーンキャンバス1枚
2. PRD初版3〜5ページ
3. WS#1用の7分デモ準備

テーマは実案件に近いほどよいが、クライアント名、個人情報、機密データは使わない。必要に応じて業界、業務領域、役割を一般化する。

テーマ選定の条件

提出形式

提出ファイル名は 氏名_M1_リーンキャンバス_PRD初版 とする。

リーンキャンバス記入テンプレート

PRD記入テンプレート

# PRD: [プロダクト名]

## 1. 背景と課題

- 対象ユーザー:
- 現在の業務:
- 現在起きている摩擦:
- 既存代替手段:
- なぜ今取り組むのか:

## 2. アウトカム

- 測定可能なアウトカム:
- North Star Metric:
- 補助指標:
- ガードレール:
- 測定データ:

## 3. ユーザーとユースケース

- 主要ユーザー:
- 利用場面:
- 利用頻度:
- 主要フロー:
  1. 
  2. 
  3. 

## 4. 検証すべき最もリスクの高い仮説

- 仮説:
- リスク種別: 価値 / ユーザビリティ / 実現可能性 / 事業実現性
- 選んだ理由:
- 外した時に起きること:
- 棄却条件:

## 5. MVPスコープ

### 作るもの

| 機能 | 対応するユーザーストーリー | 優先度 | 理由 |
|---|---|---|---|
|  |  | Must / Should / Could |  |

### 作らないもの

| 作らないもの | 理由 | 再検討条件 |
|---|---|---|
|  |  |  |

## 6. ユーザーストーリー

| No. | ユーザーストーリー | 受け入れ条件 |
|---|---|---|
| 1 | [ユーザー]として、[やりたいこと]したい。それにより[得たい価値]を得たい。 |  |
| 2 |  |  |
| 3 |  |  |

## 7. 検証方法

- 検証方法:
- 対象者:
- 使用するプロトタイプまたは代替手段:
- 成功条件:
- 棄却条件:
- 検証後の判断:

## 8. 制約・未決事項

| 種別 | 内容 | 次アクション |
|---|---|---|
| 技術 |  |  |
| データ |  |  |
| 運用 |  |  |
| セキュリティ |  |  |

必須要件

WS#1 7分デモ仕様

スライドは任意。PRD本文を画面共有して説明してよい。

提出前チェック

• 検証したい仮説が1文で言える
• 作るものより、分かることが前に出ている
• 成功条件だけでなく棄却条件がある
• アウトカムが「便利になる」「効率化する」で止まっていない
• ユーザーストーリーが機能名ではなく行動と価値になっている
• 機密情報を含めていない

M1 ルーブリック

目的

リーンキャンバスとPRD初版を3基準 × 3段階で評価し、M2へ進めるための修正点を明確にする。

所要時間

• 評価者レビュー: 1件あたり15〜20分
• 受講者の自己点検: 20分
• 再提出対応: 60〜90分

前提

• 評価対象は、リーンキャンバス1枚、PRD初版3〜5ページ、WS#1での7分デモである。
• 未達の場合、再提出は1回まで認める。
• 評価はM1単体の合否ではなく、M2で動くプロトタイプに変換できる状態かを見る。

評価基準

評価結果の付け方

卓越は加点評価であり、必須ではない。第1期の合格ラインはL2であり、M1ではM2に接続できるPRD初版を作ることを優先する。

再提出運用

フィードバック記入欄

受講者の自己点検

提出前に以下を確認する。

WS#1 運営ガイド

目的

各自のリーンキャンバスとPRD初版を相互批評し、最大リスク仮説と検証方法をM2でプロトタイプ化できる状態へ絞り込む。

所要時間

3時間

前提

• 参加者はFDE候補5〜8名。
• ファシリテーターはBUMが主導する。
• 参加者はWS#1開始前に、リーンキャンバス1枚とPRD初版3〜5ページを提出済みである。
• 相互批評では「良い点1つ + 棄却可能性1つ」を全員が必ず出す。

事前準備

3時間タイムテーブル

参加者が5〜6名の場合、各自PRDデモの余剰時間は相互批評に回す。

各自PRDデモ 7分フォーマット

相互批評の運用

全員が、各発表者に対して以下を1つずつ出す。

批評例:

避ける批評:

• 便利そう
• UIをもっと良くした方がよい
• 技術的に難しそう
• 自分なら使う

ファシリテーター台本

オープニング

今日の目的は、PRDを完成させることではありません。
M2で動くプロトタイプに変換する前に、何を検証するために作るのかを明確にします。
批評では、必ず「その仮説はどう棄却されうるか」を問いにしてください。

評価基準の確認

見る基準は3つです。アウトカムが測定可能か、最大リスク仮説が1つに絞られているか、検証方法が具体的か。
未達の場合は1回まで再提出できます。指摘は人格や努力ではなく、PRDのどこを直せばよいかに限定します。

デモ前

7分で、対象ユーザー、アウトカム、MVP、最大リスク仮説、検証方法を説明してください。
細かい機能説明より、作ることで何が分かるのかを優先してください。

相互批評前

ここからは全員が発言します。
各発表者に対して、良い点を1つ、棄却可能性を1つ出してください。
棄却可能性は「どんな事実が出たら、この仮説は間違いと言えるか」の形で書きます。

M2予告

M2では、このPRDの中核機能を動くプロトタイプに変換します。
作る範囲は、今日絞った最大リスク仮説を検証できる最小スコープです。
完成度よりも、仮説検証に足る動くものを評価します。

ミニ実技: 30分ストーリーマッピング

お題

案件マネージャー向けに、会議後のアクション項目を漏れなく追跡する社内ツールを考える。
現状、議事録は各自が作成し、アクション項目はチャットや口頭で流れている。会議後24時間以内に担当者と期限が明確になっていないため、次回会議で同じ論点が再燃している。

目標アウトカム:

案件マネージャーが、会議後24時間以内に担当者と期限が明確なアクション項目を登録できる割合を、現状40%から4週間後に80%へ上げる。

実技手順

成果物テンプレート

つまずきポイントと介入

WS#1後のアウトプット

M2 AI実装力 モジュールガイド

目的

M1で作成したPRDを「動くもの」に自力で変換できるようになる。本プログラムの技術的中核として、AIツールを使った実装、ハーネス設計、評価、検証の習慣を身につける。

所要時間

• 自習: 6〜8時間(週3〜4時間 × 2週)
• 提出課題: 自習時間内で作成し、不足分は各自調整
• WS#2: 3時間

前提

• M1でリーンキャンバス、PRD初版、検証すべき最もリスクの高い仮説を作成済みである。
• 特定AIツールのUI手順ではなく、要件を実装に変換し、検証可能な形に収束させる力を扱う。
• クライアントデータ、個人情報、APIキー、認証情報は教材・課題に使わない。

M2で身につけること

2週間の学習スケジュール

教材一覧

提出課題

M1のPRD中核機能を、動くプロトタイプとして実装する。完成度よりも、検証したい仮説が検証できる最小の形を重視する。

必須提出物:

• 動くプロトタイプ
• 自分用ハーネス(CLAUDE.md + 最低1つのskill)
• 作業ログ
• 検証ログ
• WS#2デモ準備

提出仕様は assignments/課題-プロトタイプとハーネス.md に従う。

WS#2の位置づけ

WS#2は、作ったものの完成度を競う場ではない。
M1で置いた最大リスク仮説に対して、プロトタイプが何を検証できる状態になったかを確認する場である。

実施内容:

• プロトタイプデモ
• 相互批評: 「これでどの仮説が検証できたか」を問う
• ライブ実技: 全員同時に同じ改修課題をAIで実装し、アプローチを比較する
• 社内エンジニア/インド側FDE経験者によるフィードバック

評価基準

各基準は3段階で評価し、未達は1回まで再提出できる。

01 vibe codingの実践

目的

M1のPRDを入力にして、AIツールで要件→実装→修正のループを回し、検証可能な小さなプロトタイプを作る。

所要時間

• 読み物: 45分
• 演習: 45分

前提

• M1でPRD、ユーザーストーリー、受け入れ条件、最大リスク仮説を作成済みである。
• 使用ツールは問わない。Claude Code等のエージェント型コーディングツール、AIチャット、IDE支援を使ってよい。
• 目的はAIに丸投げすることではなく、AIを実装パートナーとして使い、差分を確認しながら前進することである。

1. vibe codingで扱う最小単位

AI実装で失敗しやすいのは、PRD全体を一度に渡すことだ。最初は、M1のPRDから以下を切り出す。

最初の目標は「PRD全部を実装する」ではない。最大リスク仮説を検証できる1フローを動かすことである。

2. 実装指示の粒度

弱い指示:

このPRDをもとにアプリを作って。

強い指示:

以下のユーザーストーリー1本だけを実装してください。

目的:
会議後24時間以内に担当者と期限が明確なアクション項目を登録できるかを検証する。

ユーザーストーリー:
案件マネージャーとして、議事録テキストからアクション項目候補を確認したい。
それにより、担当者への依頼漏れを減らしたい。

受け入れ条件:
- 議事録テキストを入力できる
- アクション候補、担当者、期限、優先度を一覧表示できる
- 担当者と期限を手で編集できる
- CSVとして出力できる

制約:
- 認証は作らない
- 外部APIは使わない
- ダミーデータで動けばよい
- まず最小の画面だけを作る

完了後に、変更ファイル、起動手順、未実装範囲を報告してください。

良い指示は、目的、スコープ、制約、完了条件、報告形式が明確である。

3. 要件→実装→修正のループ

1回で完成させない。短いループを回す。

AIの出力は提案であり、完了判定ではない。完了判定は受け入れ条件と動作確認で行う。

4. 差分レビューの習慣

AIが出したコードは、必ず差分で確認する。

見る観点:

• PRDにない機能を勝手に追加していないか
• 作らないものに入れた範囲へ踏み込んでいないか
• 依存ライブラリを追加していないか
• APIキーや認証情報を埋め込んでいないか
• ダミーデータと本番データの境界が曖昧でないか
• エラー時に壊れたままにならないか
• 実行手順が第三者に分かるか

差分レビューで気づいたことは作業ログに残す。M2では、実装結果だけでなく検証過程も評価対象になる。

5. 動作確認ループ

動作確認は、画面を開いて眺めることではない。受け入れ条件に対して確認する。

確認で落ちた項目だけを、次のAI指示に戻す。

演習: ユーザーストーリー1本を実装指示に変換する

手順

1. M1のPRDから、M2で最初に作るユーザーストーリーを1本選ぶ。
2. 最大リスク仮説と受け入れ条件を転記する。
3. 作らないものを3つ書く。
4. AIツールへの実装指示を書き、実行する。
5. 変更差分を確認する。
6. 受け入れ条件に沿って動作確認する。
7. 失敗した条件を1つ選び、修正指示を書く。

記入テンプレート

完了条件

• PRD全体ではなく、ユーザーストーリー1本に絞った実装指示を書けている
• 受け入れ条件に沿って動作確認している
• 差分レビューの観点を作業ログに残している
• 失敗した条件だけに絞って修正指示を出している

02 ハーネス設計

目的

CLAUDE.md、skill、カスタムコマンドを使い、AI実装の作業品質と再現性を高める。

所要時間

• 読み物: 45分
• 演習: 45分

前提

• 特定ツールのUI操作ではなく、AIに渡す作業前提、制約、検証方法を整えることに重心を置く。
• M1のPRDとM2のプロトタイプを継続的に更新する前提で考える。
• 社内資産(SHOGUN-X、memory-dream、copy-and-shift)は本環境から参照できないため、本教材では中身を扱わない。

1. ハーネスとは

ハーネスは、AIに毎回同じ品質で作業させるための作業環境・指示・検証手順のまとまりである。

M2で扱うハーネス:

ハーネスがない状態では、AIの出力は毎回ぶれる。
ハーネスがある状態では、AIに何を守らせ、何で完了判定するかを固定できる。

2. 良いCLAUDE.mdの構成要素

# プロジェクト概要

- 対象ユーザー:
- 検証したい最大リスク仮説:
- 今回のMVPスコープ:
- 作らないもの:

## 作業ルール

- 変更前に対象ファイルを読む
- 既存のスタイルに合わせる
- 新しい依存は必要理由を説明してから追加する
- APIキー、認証情報、機密情報をコードに入れない
- 大きな変更は小さなステップに分ける

## 実装時の制約

- ダミーデータのみ使用する
- 認証は作らない
- 外部APIはモックで代替する
- M1のPRDにない機能は追加しない

## 完了条件

- 受け入れ条件を満たす
- 起動手順を更新する
- 既知の制約を記録する
- 動作確認結果を作業ログに残す

## 検証コマンド

- 起動:
- テスト:
- lint:
- 手動確認:

CLAUDE.mdは長ければよいものではない。AIが迷いやすい判断を先に固定することが目的である。

3. skillの切り出し方

skill化するのは、毎回説明するとぶれる作業である。

skill化に向くもの:

• PRDからユーザーストーリーを実装タスクへ分解する
• 受け入れ条件から手動テスト観点を作る
• 変更差分をレビュー観点に沿って確認する
• デモ前チェックリストを作る
• 作業ログを提出形式に整える

skill化に向かないもの:

• 一度しか使わない単発の調査
• 対象プロジェクトに依存しすぎる例外対応
• まだ手順が固まっていない作業

4. カスタムコマンドの使いどころ

カスタムコマンドは、短い指示で定型作業を呼び出すために使う。

例:

コマンド名よりも、何を入力に取り、何を出力するかを決めることが重要である。

5. ハーネスの育て方

最初から完成形を作らない。失敗した作業を、次回ぶれないようにハーネスへ移す。

ハーネスは成果物である。M2の課題では、動くプロトタイプと同じく評価対象になる。

【社内資産差し込み箇所】

ここに、運営側が社内資産の解剖教材を差し込む。

対象候補:

• SHOGUN-X
• memory-dream
• copy-and-shift

本環境では上記資産を参照できないため、中身を推測して記述しない。運営側は、各資産について以下の観点で差し込む。

差し込み手順

1. 対象資産の利用可否、機密区分、共有範囲を確認する。
2. 受講者に共有可能な範囲で、実ファイルまたは抜粋を準備する。
3. 以下のテンプレートに沿って、ハーネス設計の観点で解剖する。
4. 機密情報、顧客名、認証情報、内部URLを削除する。
5. 教材へ差し込む前に、BUMと社内エンジニアがレビューする。

差し込みテンプレート

演習: 自分用CLAUDE.mdの初版を作る

手順

1. M1のPRDから、対象ユーザー、最大リスク仮説、MVPスコープを転記する。
2. 作らないものを3つ以上書く。
3. 実装時の制約を書く。
4. 完了条件と検証方法を書く。
5. skill化したい作業を1つ選ぶ。
6. そのskillの入力、手順、出力を1ページで書く。

記入テンプレート

完了条件

• CLAUDE.md初版に目的、制約、作らないもの、完了条件、検証方法がある
• skill候補が1つ以上ある
• skillの入力、手順、出力が書かれている
• 社内資産の中身を推測して書いていない

03 プロンプト設計と評価

目的

AI出力のばらつきを抑えるために、制約、出力契約、例示、evalケースを先に設計する。

所要時間

• 読み物: 45分
• 演習: 45分

前提

• M2では、AIの出力を一度で正解にすることではなく、品質を観察し、制約を追加して改善する。
• evalは大規模な評価基盤ではなく、少数ケースで回帰を確認する初歩として扱う。
• 使用するAIツールやモデルは問わない。

1. ばらつきが起きる理由

AIの出力は、入力が曖昧だとぶれる。

よくある原因:

• 目的が抽象的
• 作らないものが明記されていない
• 出力形式が自由すぎる
• 良い例と悪い例がない
• 完了判定が人の感覚に依存している
• 前回の失敗が次回の指示に反映されていない

ばらつきを抑えるには、プロンプトを長くするより、制約と評価を先に置く。

2. プロンプトの基本構成

目的:
何を達成したいか。

入力:
PRD、ユーザーストーリー、受け入れ条件、既存コード、制約。

制約:
作らないもの、使わない技術、変更してよい範囲、機密情報の扱い。

出力契約:
どの形式で、何を返すか。

評価基準:
良い出力と悪い出力の違い。

例:
1つ以上の良い例、必要なら悪い例。

出力契約の例:

出力は以下の形式にしてください。

1. 実装方針
2. 変更対象ファイル
3. 受け入れ条件との対応
4. リスクと未決事項
5. 次に実行する確認

3. 制約の書き方

制約はAIを縛るためではなく、判断を安定させるために書く。

4. evalの初歩

evalは「AI出力が良いか悪いか」を先に決めることから始める。

M2での最小eval:

1. 代表ケースを3つ用意する
2. 期待出力を短く書く
3. NG条件を書く
4. 同じプロンプトで3回実行する
5. ばらつきを記録する
6. 制約を追加して再実行する

例:

少数evalでも、AIの癖を見つけられる。

5. ばらつきの観察ログ

制約追加後:

6. 評価を実装に接続する

プロンプト評価は、実装前の遊びではない。プロトタイプの品質に接続する。

評価結果は、PRDの制約、受け入れ条件、既知のリスクにも反映する。

演習: 同一プロンプトを3回実行してばらつきを観察する

手順

1. 自分のプロトタイプでAIに任せたい処理を1つ選ぶ。
2. 最初のプロンプトを書く。
3. 代表ケースを3つ用意する。
4. 同じプロンプトを3回実行し、出力のばらつきを記録する。
5. NG条件をもとに制約を追加する。
6. もう一度3回実行し、改善した点と残る問題を書く。

記入テンプレート

完了条件

• 代表ケースが3つある
• 同一プロンプトを3回実行してばらつきを記録している
• NG条件をもとに制約を追加している
• 評価結果をプロトタイプの仕様または実装に反映している

04 AIの限界を体感する

目的

ハルシネーション、コンテキスト制約、長時間タスクの劣化を意図的に体感し、AI出力を鵜呑みにせず検証する習慣を作る。

所要時間

• 読み物: 45分
• 演習: 45分

前提

• AIの限界は知識として読むだけでは定着しない。小さく失敗を再現し、観察し、対処する。
• 特定ツールやモデルの欠点を批評することが目的ではない。FDE型PdMとして、案件で事故らない使い方を身につける。
• 演習にはダミーデータのみ使う。

1. 限界を前提に設計する

AIは強力だが、以下の限界がある。

対策は「AIを使わない」ではない。疑う観点と確認手段を先に持つことである。

2. 演習A: ハルシネーションを再現する

再現手順

1. 自分のプロトタイプに関係する架空の社内API名を作る。
2. AIに「このAPIを使って実装してください」と依頼する。
3. AIが仕様を確認するか、存在する前提で進めるかを観察する。
4. 次に「存在確認できないAPIは使わず、必要なら質問してください」と制約を追加する。
5. 出力がどう変わるか記録する。

観察ポイント

• API仕様を捏造したか
• 存在確認の質問をしたか
• モック実装に切り替えたか
• リスクとして明記したか

対処パターン

• 存在確認できないものは使わない
• 外部APIはモックで代替する
• 仕様不明点は質問または未決事項にする
• 「推測で進めない」をCLAUDE.mdに入れる

3. 演習B: コンテキスト制約を再現する

再現手順

1. PRD、作らないもの、受け入れ条件、既存コード概要を長めに渡す。
2. AIに改修を依頼する。
3. 作らないものに入れた機能を追加していないか確認する。
4. 次に、入力を「目的、対象ファイル、受け入れ条件、作らないもの」だけに圧縮して再依頼する。
5. 出力の違いを記録する。

観察ポイント

• 重要制約を見落としたか
• 既存コードの前提を誤読したか
• 変更範囲が広がったか
• 入力を短くした時に改善したか

対処パターン

• 長い背景より、今回の目的と制約を先頭に置く
• 変更対象ファイルを限定する
• 作らないものを箇条書きにする
• 大きな依頼を複数ステップに分ける

4. 演習C: 長時間タスクの劣化を再現する

再現手順

1. AIに複数機能の実装を一括で依頼する。
2. 途中で目的、制約、受け入れ条件を再確認せず進める。
3. 出てきた差分を確認し、脱線、過剰実装、未検証箇所を記録する。
4. 次に、同じ内容を3つの小タスクに分けて依頼する。
5. 差分の大きさ、動作確認のしやすさ、脱線の少なさを比較する。

観察ポイント

• 差分が大きすぎてレビュー不能になったか
• 途中から目的がずれたか
• 実行手順や検証結果が曖昧になったか
• 小タスク化で改善したか

対処パターン

• 1依頼1ユーザーストーリーにする
• 各ステップで差分レビューと動作確認を挟む
• 完了後に変更ファイル、確認結果、未実装範囲を報告させる
• 長時間作業では途中でCLAUDE.mdとPRDを再提示する

5. 鵜呑み検証のチェックリスト

AIの説明をそのまま信じない。以下で確認する。

演習: 限界観察ログを作る

手順

1. 演習A〜Cから2つ選ぶ。
2. 再現手順を実行する。
3. 観察ポイントに沿って記録する。
4. 対処パターンをCLAUDE.md、skill、プロンプトのいずれかに反映する。
5. 提出課題の作業ログに反映箇所を書く。

記入テンプレート

完了条件

• 演習A〜Cのうち2つ以上を実施している
• AIの出力で問題だった点を具体的に記録している
• 自分で確認した方法が書かれている
• 対処パターンをCLAUDE.md、skill、プロンプトのいずれかに反映している

課題 プロトタイプとハーネス

目的

M1のPRD中核機能を、検証したい仮説が検証できる最小の動くプロトタイプに変換し、再利用可能なハーネスと合わせて提出する。

所要時間

• 教材01〜04の演習成果物(実装指示、CLAUDE.md初版、evalケース)を再利用する場合: 仕上げ1〜2時間
• 演習を経ずに新規作成する場合: 2〜4時間

前提

• M1でPRD初版、最大リスク仮説、MVPスコープを作成済みである。
• 完成度よりも、仮説検証に足る最小フローが動くことを重視する。
• AIの出力は必ず差分レビュー、動作確認、検証ログで確認する。

課題仕様

以下を作成する。

1. M1のPRD中核機能を実装した動くプロトタイプ
2. 自分用ハーネス(CLAUDE.md + 最低1つのskill)
3. 作業ログ
4. 検証ログ
5. WS#2用デモ準備

プロトタイプは本番品質でなくてよい。M1で明示した最大リスク仮説を検証できる最小の形に絞る。

実装スコープの決め方

必須提出物

CLAUDE.mdテンプレート

# M2プロトタイプ作業ルール

## 目的

- 対象ユーザー:
- 検証したい最大リスク仮説:
- MVPスコープ:

## 作らないもの

1. 
2. 
3. 

## 作業ルール

- 変更前に対象ファイルを読む
- 大きな変更は小さなステップに分ける
- 新しい依存は必要理由を説明してから追加する
- APIキー、認証情報、個人情報をコードに入れない
- PRDにない機能を追加しない

## 完了条件

- 受け入れ条件を満たす
- 起動手順が明記されている
- 既知の制約が記録されている
- 動作確認結果が検証ログに残っている

## 検証方法

- 起動:
- 手動確認:
- evalケース:
- デモ確認:

skillテンプレート

# Skill: [作業名]

## 目的

[何を再現可能にするか]

## 入力

- 
- 

## 手順

1. 
2. 
3. 

## 出力

- 
- 

## 完了条件

- 
- 

作業ログテンプレート

検証ログテンプレート

WS#2デモ仕様

デモはライブ操作を基本とする。環境不調に備え、画面録画をバックアップとして持ってよい。

提出前チェック

M2 ルーブリック

目的

プロトタイプとハーネスを3基準 × 3段階で評価し、M3以降へ進めるための修正点を明確にする。

所要時間

• 評価者レビュー: 1件あたり20〜30分
• 受講者の自己点検: 20分
• 再提出対応: 60〜120分

前提

• 評価対象は、動くプロトタイプ、CLAUDE.md、最低1つのskill、作業ログ、検証ログ、WS#2デモである。
• 未達の場合、再提出は1回まで認める。
• 評価は完成度ではなく、仮説検証、再現性、検証習慣を見る。

評価基準

評価結果の付け方

再提出運用

フィードバック記入欄

受講者の自己点検

WS#2 運営ガイド

目的

M1のPRDから作ったプロトタイプをデモし、仮説検証への足り方、ハーネスの再利用性、AI出力の検証習慣を確認する。

所要時間

3時間

前提

• 参加者はFDE候補5〜8名。
• ファシリテーターはBUMが主導し、社内エンジニアまたはインド側FDE経験者をゲストに招く。
• 参加者はWS#2開始前に、プロトタイプ、CLAUDE.md、最低1つのskill、作業ログ、検証ログを提出済みである。
• 批評では「これでどの仮説が検証できたか」を必ず問う。

事前準備

180分タイムテーブル

参加者が5〜6名の場合、デモの余剰時間は相互批評とゲストフィードバックに回す。

プロトタイプデモ 7分フォーマット

相互批評の運用

全員が、各発表者に対して以下を出す。

批評例:

ライブ実技

お題

共通スターターとして、議事録アクション抽出ツールの小さなプロトタイプを使う。画面には、議事録入力欄、抽出結果一覧、CSV出力がある。

改修課題:

期限が曖昧なアクション項目を「期限未確定」として表示し、ユーザーが手で期限を入力するまでCSV出力時に警告する。

制約

• 外部APIは使わない
• 認証は作らない
• 新しい依存は追加しない
• 変更対象はUI、抽出ロジック、検証ケースに限定する
• AIへの指示、差分レビュー、動作確認を記録する

30分の進め方

受け入れ条件

• 「来週中」「なる早」「別途調整」などの曖昧な期限を期限未確定として扱う
• 期限未確定の行は画面上で分かる
• 期限未確定のままCSV出力しようとすると警告が出る
• ユーザーが期限を手入力すると警告対象から外れる

アプローチ比較の観点

ゲストへの依頼事項

社内エンジニアへの依頼

• 変更差分の読み方について、危険な兆候を指摘する
• 新しい依存追加、エラー処理、データ扱い、セキュリティの観点で講評する
• 「動くが危ない」状態と「MVPとして許容できる」状態の境界を説明する

インド側FDE経験者への依頼

• AIエージェントを含む実案件デリバリーで、ハーネスが効く場面を話す
• オフショアや分散チームで再現性を確保する観点を補足する
• 受講者の作業ログを見て、次スプリントで改善すべき運用を指摘する

フィードバック形式

ファシリテーター台本

オープニング

今日見るのは、完成度ではありません。
M1で置いた最大リスク仮説に対して、プロトタイプが何を検証できる状態になったかを見ます。
もう1つの評価対象はハーネスです。次の改修でも同じ品質でAIを使えるかを確認します。

デモ前

7分で、仮説、MVPスコープ、動くもの、ハーネス、検証ログを見せてください。
機能説明よりも、何が検証できて、何がまだ検証できないかを優先してください。

相互批評前

批評では必ず「これでどの仮説が検証できたか」を言語化してください。
動いていることと、仮説が検証できることは別です。まだ判断できない仮説も明確にします。

ライブ実技前

ここからは全員同じ改修をAIで実装します。
目的は速さではなく、指示、差分レビュー、検証の進め方を比較することです。
実装できなかった場合も、どこで詰まったかを記録してください。

クロージング

M3では、今日作ったものを技術的に説明する側へ進みます。
何が動いているかだけでなく、どんな構成で、どんな技術判断が必要かを扱います。
再提出対象者は、指摘された基準だけを3営業日以内に直してください。

WS#2後のアウトプット