フレームワーク活用ガイドひとことで言うと#
プロダクト開発で失敗する原因を「価値リスク」「ユーザビリティリスク」「実現可能性リスク」「事業性リスク」の4つに分類し、作る前にそれぞれを検証することで、無駄な開発投資を防ぐフレームワーク。
押さえておきたい用語#
- 価値リスク（Value Risk）
- ユーザーがその機能を本当に欲しいと思うか、使ってくれるかという不確実性のこと。作ったけど誰も使わない、が典型的な失敗。
- ユーザビリティリスク（Usability Risk）
- ユーザーがその機能を迷わず使いこなせるかという不確実性。機能自体は求められていても、UIが複雑すぎて使われないケースを指す。
- 実現可能性リスク（Feasibility Risk）
- 現在のチームの技術力・インフラ・期間で技術的に実現できるかという不確実性。
- 事業性リスク（Business Viability Risk）
- その機能がビジネスモデル・法規制・営業チャネル・パートナーシップなど事業の制約条件と整合するかを問う不確実性を指す。
- プロダクトディスカバリー（Product Discovery）
- 4つのリスクを開発（デリバリー）の前に検証する活動の総称。プロトタイプ、ユーザーインタビュー、技術スパイクなどの手法を使う。
プロダクトの4つのリスクの全体像#
こんな悩みに効く#
- 半年かけて開発した機能がリリース後にほとんど使われなかった
- 「とりあえず作ってみよう」が口癖で、手戻りが多い
- エンジニアが「技術的に難しい」と言っているが、どの程度のリスクか判断できない
- 機能は良いのに法務やコンプライアンスで止められた
- プロダクトディスカバリーを体系的に進める方法がわからない
基本の使い方#
具体例#
MAU 50万人のフードデリバリーアプリが、「友達と一緒に1つの注文にまとめられるグループ注文機能」の開発を検討した。
4リスクの検証結果:
| リスク | 検証方法 | 結果 |
|---|---|---|
| 価値 | ユーザーインタビュー12人 | 8人が「使いたい」、特にオフィスランチ需要が強い |
| ユーザビリティ | Figmaプロトタイプで5人テスト | タスク完了率60%。招待フローでつまずく人が3人 |
| 実現可能性 | 技術スパイク2日 | リアルタイム同期に WebSocket が必要。既存インフラで対応可 |
| 事業性 | 営業・法務レビュー | 決済の分割が資金決済法に抵触する可能性あり |
価値リスクはクリア、実現可能性も問題なし。しかしユーザビリティと事業性にリスクが残った。招待フローをURLシェア方式に簡略化し（ユーザビリティ改善）、決済は「1人がまとめて払い、アプリ外で割り勘する」形に変更（法的リスク回避）。再検証でタスク完了率が 92% に改善し、開発GOとなった。
従業員80名のBtoB SaaS企業（人材マッチングプラットフォーム）が、求職者にAIで求人をレコメンドする機能を検討した。
価値リスク: 既存顧客10社にヒアリングした結果、7社が「マッチング精度が上がるなら月額料金の15%アップも許容する」と回答。需要は確認できた。
ユーザビリティリスク: レコメンド結果の表示UIをモックアップし、人事担当者5人にテスト。全員が「なぜこの候補者がレコメンドされたか」の説明を求めた。ブラックボックスでは信頼されないことが判明。
実現可能性リスク: MLエンジニアが2日間の技術スパイクを実施。学習データ量が十分で精度78%のモデルは作れるが、レコメンド理由の説明（Explainable AI）に追加で3週間必要と判明。
事業性リスク: 個人情報保護法との整合を法務に確認。AIによるプロファイリングは同意取得が必要で、利用規約の改定が必要だった。
結果的に、ユーザビリティ（説明性）と事業性（同意取得）のリスク対策に4週間を追加し、当初の開発計画を6週間から10週間に延長して開発GOとした。リリース後のマッチング成約率は 23%向上 した。
地方銀行（預金残高1.2兆円）が、スマホバンキングアプリにローンの即時審査・即時融資機能を追加する企画を立てた。
価値リスクの検証として、既存アプリユーザー3,000人にアンケートを実施。「スマホだけでローンが完結するなら使いたい」と回答したのは 42%。特に20〜30代の住宅ローン検討層に需要が集中していた。
実現可能性リスクでは、審査AIモデルの構築に外部ベンダーのAPIを使う想定だったが、技術スパイクの結果、レスポンスタイムが平均8秒と遅く「即時」の体験が損なわれることが判明。キャッシュ戦略とAPI呼び出しの非同期化で3秒以内に短縮できる見通しが立った。
事業性リスクが最大のハードルだった。金融庁ガイドラインへの準拠、反社チェックの自動化、貸金業法の広告規制など、法務・コンプライアンス部門との調整に2か月を要した。
4リスクすべてをクリアした上でリリースした結果、初月のローン申込件数が窓口比 3.2倍 に増加。ただしユーザビリティテストで発見した「審査結果の待ち時間表示」を入れなかったら離脱率が高かったはずで、ディスカバリーの効果は大きかったと振り返っている。
やりがちな失敗パターン#
価値リスクを飛ばして作り始める — 「社長が言ったから」「競合がやっているから」でユーザーの需要確認をスキップする。これがプロダクト開発の失敗原因の最大要因。まず価値があるかを5人に聞くだけでもリスクは大きく下がる。
4つのリスクを順番に検証する — 実際には並行して検証できるものが多い。エンジニアが技術スパイクをしている間にPMがユーザーインタビューを行うなど、時間を最大限活用する。
実現可能性リスクをエンジニアに丸投げする — 「作れる？」と聞くだけでは不十分。制約条件（期間・予算・既存システムとの互換性）を明示した上で判断を仰ぐ。PMとエンジニアが一緒にリスクを評価するのが正しいアプローチ。
事業性リスクをリリース直前に確認する — 法務や営業との調整を開発完了後に回すと、根本的な設計変更が必要になることがある。ディスカバリーの段階でステークホルダーを巻き込む。
1回の検証で合否を決める — プロトタイプテストが1回うまくいかなかっただけで機能をお蔵入りにする。リスクが高い部分を特定して改善し、再検証するイテレーションを回す。
まとめ#
Marty Caganの4つのリスクフレームワークは、プロダクト開発の失敗パターンを「価値・ユーザビリティ・実現可能性・事業性」の4象限で整理する。最も見落とされやすいのは価値リスクと事業性リスクで、技術的に作れるかどうかだけでなく「そもそも求められているか」「ビジネスとして回るか」を開発前に検証することが、無駄な投資を防ぐ最大のレバレッジになる。