ひとことで言うと#
プロダクトリスクキャンバスは、新しいプロダクトや機能を評価する際に、**価値リスク(作る価値があるか)、使いやすさリスク(使えるか)、実現性リスク(作れるか)、事業性リスク(事業として成立するか)**の4象限でリスクを1枚にマッピングするフレームワーク。マーティ・ケイガン(SVPG)の4リスクモデルをキャンバス形式に発展させたもので、「作ったが使われなかった」を防ぐための事前チェックリストとして機能する。
押さえておきたい用語#
- 価値リスク(Value Risk)
- ユーザーがそもそもこの製品・機能を欲しいと思うかのリスク。ニーズが存在しない、または既存の代替手段で十分という場合に顕在化する。
- 使いやすさリスク(Usability Risk)
- ユーザーが使い方を理解し、目的を達成できるかのリスク。機能が複雑すぎる、UI/UXが直感的でないといった問題が該当する。
- 実現性リスク(Feasibility Risk)
- チームが技術的・リソース的に実現できるかのリスク。技術的な不確実性、開発期間の不足、チームのスキルギャップなどが該当する。
- 事業性リスク(Business Viability Risk)
- この製品・機能が事業として持続可能かのリスク。法規制、コスト構造、既存事業とのカニバリゼーション、ステークホルダーの合意などが含まれる。
プロダクトリスクキャンバスの全体像#
こんな悩みに効く#
- 開発に3ヶ月かけた新機能がリリース後にほとんど使われなかった
- 「技術的に可能か」ばかり議論して、「ユーザーが欲しいか」を検証していない
- 新プロダクトのGo/No-Goの判断基準が曖昧
基本の使い方#
チームで1〜2時間のワークショップとして実施するのが最も効果的。
- ホワイトボードまたはMiroに4象限を描く
- 各象限に「最も心配なこと」を付箋で貼り出す(1人3〜5枚を目安)
- 価値リスク:「本当にユーザーはこれを必要としているか?」
- 使いやすさリスク:「初めて使う人が5分以内に価値を体験できるか?」
- 実現性リスク:「チームのスキルセットで3ヶ月以内に作れるか?」
- 事業性リスク:「この機能を維持するコストは売上に見合うか?」
4象限すべてを同時に検証しようとしない。最大のリスクから潰す。
- 各象限のリスクを「高・中・低」で評価する
- 「高」と判定された象限が最優先の検証対象
- 価値リスクが高い場合 → 開発前にユーザーインタビューやプロトタイプテスト
- 実現性リスクが高い場合 → 技術スパイクやPoCを先行実施
- リスクが低い象限は後回しにしてよい
検証結果が出たら、キャンバスを更新してチームで共有する。
- リスクが十分に下がった → 次のリスク象限の検証に進む or 開発開始
- リスクが下がらなかった → ピボット or 中止の判断
- すべての象限が「中」以下になった状態が「Go」のサイン
- キャンバスは1枚で保存し、プロジェクト期間中いつでも参照できるようにする
具体例#
状況: マーケティングSaaS。「AIがレポートを自動生成する機能」の企画が上がった。経営層は乗り気だが、PMは「本当に使われるか?」と疑問
4象限の評価:
- 価値リスク:高 — 顧客がレポート作成に困っているのは事実だが、「AI生成のレポートを信頼するか」が未検証
- 使いやすさリスク:中 — UI自体はシンプルにできるが、出力のカスタマイズ性が求められる可能性
- 実現性リスク:中 — LLMのAPI活用で技術的には可能だが、精度の担保にチューニングが必要
- 事業性リスク:低 — API利用コストは許容範囲、既存プランの付加機能として提供可能
最大リスクの検証: 価値リスク。既存顧客10社にモックアップを見せてインタビュー → 8社が「使いたい」、ただし「手動で修正できないと使えない」という条件付き
結果: 「完全自動生成」から「AIドラフト+手動編集」にコンセプトを修正して開発開始。3ヶ月後のリリースで利用率42%を達成。「もしインタビューをせずに完全自動生成で出していたら、使われなかっただろう」とPMは振り返っている。
状況: 全国50店舗のラーメンチェーン。モバイルオーダー(事前注文→来店時に受け取り)の導入を検討中。IT部門と店舗オペレーション部門の意見が割れている
4象限の評価:
- 価値リスク:低 — 他チェーンの成功事例多数。顧客アンケートでも「待ち時間を減らしたい」が1位
- 使いやすさリスク:中 — 高齢の常連客が使えるか。メニューのカスタマイズ(麺の硬さ等)をアプリで表現できるか
- 実現性リスク:中 — 既存POSとの連携が技術的に複雑
- 事業性リスク:高 — 店舗スタッフのオペレーション変更が大きい。厨房の動線を変える必要があり、ピーク時の混乱が懸念
最大リスクの検証: 事業性リスク。2店舗でパイロット運用を2週間実施。厨房に「モバイルオーダー専用レーン」を仮設
結果: パイロットで判明した課題(ピーク時のオーダー集中、受取場所の混雑)を対策した上で展開。全50店舗への展開後、平均待ち時間が8分→3分に短縮。客単価も12%向上(アプリでのついでオーダーが増加)。
状況: 個人開発者がデザイナー向けの素材ダウンロードサービス(月額980円)を企画。技術力には自信があるが、事業としての見通しが不安
4象限の評価:
- 価値リスク:中 — 類似サービスが多い。差別化ポイントが明確でない
- 使いやすさリスク:低 — 検索→ダウンロードのシンプルなUX
- 実現性リスク:低 — 個人でも構築可能な技術スタック
- 事業性リスク:高 — 素材の著作権管理、月額980円で収益が成立するか(損益分岐点の会員数は?)
最大リスクの検証: 事業性リスク。損益分岐点を計算→月額980円で黒字化には会員300人が必要。素材調達コスト(クリエイターへの報酬)を試算すると、月15万円。まずは自作素材100点でβ版を公開し、50人の有料会員が集まるか検証
結果: β版で3ヶ月後に有料会員38人。300人は遠いが、ニーズは確認。「日本のイラスト素材に特化」という差別化で価値リスクも下げ、6ヶ月後に会員120人に到達。「4象限で整理したおかげで、最初に潰すべき不安が明確になった」と本人は話している。
やりがちな失敗パターン#
- 実現性リスクだけを検証する — エンジニアチームは「作れるか」に注力しがちだが、作れても使われなければ意味がない。価値リスクの検証を先に行う
- 4象限を1人で埋める — PM1人の視点では偏る。エンジニア、デザイナー、営業など異なる立場のメンバーで埋めることでリスクの見落としが減る
- キャンバスを作って満足する — リスクを書き出しただけでは何も変わらない。最大リスクの検証方法と期限を決め、実際に検証を回す
- リスクを理由にすべてNo-Goにする — リスクはゼロにならない。「許容可能なレベルまで下げる」が目標であり、リスクの存在自体は開発しない理由にはならない
まとめ#
プロダクトリスクキャンバスは「作る前に考えるべき4つの問い」を1枚にまとめたフレームワークだ。価値・使いやすさ・実現性・事業性の4象限を埋めるだけで、チームのリスク認識が揃い、「何を最初に検証すべきか」が明確になる。1〜2時間のワークショップで完成するシンプルさもこのフレームワークの強み。新しいプロダクトや機能を企画するとき、コードを1行も書く前にこのキャンバスを1枚描いてみてほしい。