フレームワーク活用ガイドひとことで言うと#
プロダクトチームの仕事を「何を作るべきか探る（ディスカバリー）」と「確実に届ける（デリバリー）」に分離し、エンジニア・デザイナー・PMの3者がディスカバリーに対等に関わることで、ロードマップの消化ではなく成果（アウトカム）に責任を持つ組織を作るモデル。
押さえておきたい用語#
- ディスカバリー（Discovery）
- 作るべきものを見極める探索活動。プロトタイプや実験で価値・使いやすさ・実現性・事業性の4リスクを検証する。
- デリバリー（Delivery）
- ディスカバリーで検証済みのアイデアを本番品質のプロダクトとして出荷するプロセスを指す。
- エンパワードチーム（Empowered Team）
- 機能の納品ではなくビジネス成果への責任を持ち、解決方法を自ら選べる開発チームである。
- フィーチャーチーム（Feature Team）
- ロードマップに並んだ機能を順に実装する受注型のチーム。ケイガンはこれを「機能ファクトリー」と批判している。
- プロダクトトリオ（Product Trio）
- PM・デザイナー・テックリードの3名で構成されるディスカバリーの最小ユニットを指す。
ケイガン式プロダクトモデルの全体像#
こんな悩みに効く#
- ロードマップを消化しているのに、ユーザーの反応が薄い
- 開発チームが「言われた機能を作るだけ」になっている
- PMが一人で仕様を書き、エンジニアに渡す一方通行の体制
- リリース後に「実はニーズがなかった」と判明することが多い
- プロダクト開発の意思決定に数字が使われていない
基本の使い方#
具体例#
会員12万人のフィットネスアプリで、月次解約率が 8.2% と高止まりしていた。PMがロードマップから「トレーニング動画の追加」を進めようとしたが、テックリードが「まず解約理由を調べよう」と提案。
プロダクトトリオで解約者15名にインタビューした結果、動画不足ではなく「1人で続けるモチベーションが湧かない」が主因と判明した。
| 検証したリスク | 仮説 | 実験 | 結果 |
|---|---|---|---|
| 価値リスク | 仲間の存在が継続率を上げる | 5人グループのLINE共有機能をモック | 12/15名が「使いたい」 |
| UIリスク | 毎日の報告が面倒にならないか | ワンタップ記録のプロトタイプ | 平均操作時間4秒 |
| 事業性リスク | 開発コストに見合うか | 解約率1%改善で月180万円の効果試算 | ROI 3.2倍 |
グループ機能をリリースした結果、解約率は 8.2% → 5.7% に改善。動画追加に3ヶ月かけるより、2週間のディスカバリーで正しい課題を見つけた方が効果的だった。
従業員200名のクラウド会計SaaS企業。開発チーム5つがロードマップに従って機能を納品する「フィーチャーチーム」体制だった。年間60機能をリリースしたが、利用率が10%を超えた機能はわずか8つ。
CPOがケイガン式モデルを導入し、まず1チームをパイロットとしてエンパワードチームに転換した。
移行で変えたこと:
- チームの目標を「四半期で◯機能リリース」から「有料転換率を15%→20%に引き上げる」に変更
- PMが毎週10件の顧客インタビューを実施し、デザイナー・テックリードも同席
- ディスカバリーで検証した仮説のうち、約60%はデリバリーに進まず棄却
半年後、パイロットチームの担当領域の有料転換率は 15% → 22.4%。他チームが同期間にリリースした12機能の平均利用率5%に対し、パイロットチームがリリースした3機能の平均利用率は 38% に達した。数を減らして質を上げる好例となり、翌四半期に全チームへ展開された。
年間観光客40万人の温泉地で、観光協会が宿泊・体験のオンライン予約システムを構築する計画を立てた。外注先の開発会社から1,200万円の見積もりが出ていた。
協会の担当者が勉強会でケイガン式モデルを知り、いきなり全機能を発注するのではなく、まずディスカバリーを実施することにした。
観光客30名にヒアリングしたところ、予約自体の不満より「現地に来てから何ができるか分からない」という情報不足のジョブが大きかった。そこで予約システムの前に「今日できること」を表示するシンプルな1ページWebアプリをノーコードツールで2日で作りテスト。利用者の 72% が「便利」と回答し、そこから体験予約への導線をつけたところコンバージョン率は 11% になった。
最終的に、当初1,200万円の見積もりの機能のうち実際に必要だったのは3割程度と判明し、開発費は 380万円 で収まった。
やりがちな失敗パターン#
ディスカバリーを「調査フェーズ」と誤解する。 ディスカバリーは一度やって終わる工程ではなく、デリバリーと並行して常に回し続けるもの。ウォーターフォールの上流工程と混同すると形骸化する。
PMだけがディスカバリーを行い、エンジニアとデザイナーに結果だけ伝える。 これでは従来の「PMが仕様を書いて渡す」体制と変わらない。トリオ全員で顧客に会うことが不可欠。
「やめる判断」ができずに全アイデアをデリバリーに流す。 ディスカバリーの価値はNOを言えることにある。検証で否定されたアイデアを「せっかく調べたから」と作り始めると、機能ファクトリーに逆戻りする。
アウトプットの指標（リリース数）を残したままアウトカムも追加してしまう。 二重の目標はチームを混乱させる。アウトカム指標に一本化しないと、結局リリース数で評価されてしまう。
まとめ#
ケイガン式プロダクトモデルは、「何を作るか」と「どう届けるか」を分離し、PM・デザイナー・テックリードの三位一体で課題を探るアプローチだ。検証で潰せるリスクをコードを書く前に潰すことで、使われない機能の量産を防ぐ。導入の第一歩は、チームの目標を「リリース数」から「ビジネス成果」に書き換えることから始まる。