プロダクトリスクキャンバス

英語名 Product Risk Canvas
読み方 プロダクト リスク キャンバス
難易度
所要時間 1〜2時間(チームワークショップ)
提唱者 Marty Cagan(SVPG)の4リスクモデルを発展
目次

ひとことで言うと
#

プロダクトリスクキャンバスは、新しいプロダクトや機能を評価する際に、**価値リスク(作る価値があるか)、使いやすさリスク(使えるか)、実現性リスク(作れるか)、事業性リスク(事業として成立するか)**の4象限でリスクを1枚にマッピングするフレームワーク。マーティ・ケイガン(SVPG)の4リスクモデルをキャンバス形式に発展させたもので、「作ったが使われなかった」を防ぐための事前チェックリストとして機能する。

押さえておきたい用語
#

押さえておきたい用語
価値リスク(Value Risk)
ユーザーがそもそもこの製品・機能を欲しいと思うかのリスク。ニーズが存在しない、または既存の代替手段で十分という場合に顕在化する。
使いやすさリスク(Usability Risk)
ユーザーが使い方を理解し、目的を達成できるかのリスク。機能が複雑すぎる、UI/UXが直感的でないといった問題が該当する。
実現性リスク(Feasibility Risk)
チームが技術的・リソース的に実現できるかのリスク。技術的な不確実性、開発期間の不足、チームのスキルギャップなどが該当する。
事業性リスク(Business Viability Risk)
この製品・機能が事業として持続可能かのリスク。法規制、コスト構造、既存事業とのカニバリゼーション、ステークホルダーの合意などが含まれる。

プロダクトリスクキャンバスの全体像
#

4つのリスク象限
価値リスクユーザーは本当に欲しいか?既存の代替手段より優れているか?検証法:ユーザーインタビュープロトタイプテスト使いやすさリスクユーザーは使いこなせるか?学習コストは許容範囲か?検証法:ユーザビリティテストモックアップ評価実現性リスク技術的に作れるか?期間・リソースは十分か?検証法:技術スパイクPoC実装事業性リスク事業として成立するか?法規制・コスト・利害関係は?検証法:事業計画レビュー法務・経理確認4つのリスクを1枚のキャンバスでチェックする
プロダクトリスクキャンバスの使い方
1
4象限を埋める
各リスクの具体的な懸念事項を書き出す
2
最大リスクを特定
4象限のうち最も不確実性が高い領域を選ぶ
3
最大リスクから検証
最もリスクが高い象限から先に実験・検証する
リスクを下げてから開発
「作ったが使われない」を事前に防ぐ

こんな悩みに効く
#

  • 開発に3ヶ月かけた新機能がリリース後にほとんど使われなかった
  • 「技術的に可能か」ばかり議論して、「ユーザーが欲しいか」を検証していない
  • 新プロダクトのGo/No-Goの判断基準が曖昧

基本の使い方
#

4象限それぞれに具体的なリスクを書き出す

チームで1〜2時間のワークショップとして実施するのが最も効果的。

  • ホワイトボードまたはMiroに4象限を描く
  • 各象限に「最も心配なこと」を付箋で貼り出す(1人3〜5枚を目安)
  • 価値リスク:「本当にユーザーはこれを必要としているか?」
  • 使いやすさリスク:「初めて使う人が5分以内に価値を体験できるか?」
  • 実現性リスク:「チームのスキルセットで3ヶ月以内に作れるか?」
  • 事業性リスク:「この機能を維持するコストは売上に見合うか?」
最もリスクが高い象限を1つ特定する

4象限すべてを同時に検証しようとしない。最大のリスクから潰す。

  • 各象限のリスクを「高・中・低」で評価する
  • 「高」と判定された象限が最優先の検証対象
  • 価値リスクが高い場合 → 開発前にユーザーインタビューやプロトタイプテスト
  • 実現性リスクが高い場合 → 技術スパイクやPoCを先行実施
  • リスクが低い象限は後回しにしてよい
最大リスクの検証結果をもとにGo/No-Goを判断する

検証結果が出たら、キャンバスを更新してチームで共有する。

  • リスクが十分に下がった → 次のリスク象限の検証に進む or 開発開始
  • リスクが下がらなかった → ピボット or 中止の判断
  • すべての象限が「中」以下になった状態が「Go」のサイン
  • キャンバスは1枚で保存し、プロジェクト期間中いつでも参照できるようにする

具体例
#

例1:BtoB SaaSの新機能「AIレポート自動生成」

状況: マーケティングSaaS。「AIがレポートを自動生成する機能」の企画が上がった。経営層は乗り気だが、PMは「本当に使われるか?」と疑問

4象限の評価:

  • 価値リスク: — 顧客がレポート作成に困っているのは事実だが、「AI生成のレポートを信頼するか」が未検証
  • 使いやすさリスク:中 — UI自体はシンプルにできるが、出力のカスタマイズ性が求められる可能性
  • 実現性リスク:中 — LLMのAPI活用で技術的には可能だが、精度の担保にチューニングが必要
  • 事業性リスク:低 — API利用コストは許容範囲、既存プランの付加機能として提供可能

最大リスクの検証: 価値リスク。既存顧客10社にモックアップを見せてインタビュー → 8社が「使いたい」、ただし「手動で修正できないと使えない」という条件付き

結果: 「完全自動生成」から「AIドラフト+手動編集」にコンセプトを修正して開発開始。3ヶ月後のリリースで利用率42%を達成。「もしインタビューをせずに完全自動生成で出していたら、使われなかっただろう」とPMは振り返っている。

例2:飲食チェーンのモバイルオーダー導入

状況: 全国50店舗のラーメンチェーン。モバイルオーダー(事前注文→来店時に受け取り)の導入を検討中。IT部門と店舗オペレーション部門の意見が割れている

4象限の評価:

  • 価値リスク:低 — 他チェーンの成功事例多数。顧客アンケートでも「待ち時間を減らしたい」が1位
  • 使いやすさリスク:中 — 高齢の常連客が使えるか。メニューのカスタマイズ(麺の硬さ等)をアプリで表現できるか
  • 実現性リスク:中 — 既存POSとの連携が技術的に複雑
  • 事業性リスク: — 店舗スタッフのオペレーション変更が大きい。厨房の動線を変える必要があり、ピーク時の混乱が懸念

最大リスクの検証: 事業性リスク。2店舗でパイロット運用を2週間実施。厨房に「モバイルオーダー専用レーン」を仮設

結果: パイロットで判明した課題(ピーク時のオーダー集中、受取場所の混雑)を対策した上で展開。全50店舗への展開後、平均待ち時間が8分→3分に短縮。客単価も12%向上(アプリでのついでオーダーが増加)。

例3:個人開発者がサブスクリプションサービスを企画

状況: 個人開発者がデザイナー向けの素材ダウンロードサービス(月額980円)を企画。技術力には自信があるが、事業としての見通しが不安

4象限の評価:

  • 価値リスク:中 — 類似サービスが多い。差別化ポイントが明確でない
  • 使いやすさリスク:低 — 検索→ダウンロードのシンプルなUX
  • 実現性リスク:低 — 個人でも構築可能な技術スタック
  • 事業性リスク: — 素材の著作権管理、月額980円で収益が成立するか(損益分岐点の会員数は?)

最大リスクの検証: 事業性リスク。損益分岐点を計算→月額980円で黒字化には会員300人が必要。素材調達コスト(クリエイターへの報酬)を試算すると、月15万円。まずは自作素材100点でβ版を公開し、50人の有料会員が集まるか検証

結果: β版で3ヶ月後に有料会員38人。300人は遠いが、ニーズは確認。「日本のイラスト素材に特化」という差別化で価値リスクも下げ、6ヶ月後に会員120人に到達。「4象限で整理したおかげで、最初に潰すべき不安が明確になった」と本人は話している。

やりがちな失敗パターン
#

  1. 実現性リスクだけを検証する — エンジニアチームは「作れるか」に注力しがちだが、作れても使われなければ意味がない。価値リスクの検証を先に行う
  2. 4象限を1人で埋める — PM1人の視点では偏る。エンジニア、デザイナー、営業など異なる立場のメンバーで埋めることでリスクの見落としが減る
  3. キャンバスを作って満足する — リスクを書き出しただけでは何も変わらない。最大リスクの検証方法と期限を決め、実際に検証を回す
  4. リスクを理由にすべてNo-Goにする — リスクはゼロにならない。「許容可能なレベルまで下げる」が目標であり、リスクの存在自体は開発しない理由にはならない

まとめ
#

プロダクトリスクキャンバスは「作る前に考えるべき4つの問い」を1枚にまとめたフレームワークだ。価値・使いやすさ・実現性・事業性の4象限を埋めるだけで、チームのリスク認識が揃い、「何を最初に検証すべきか」が明確になる。1〜2時間のワークショップで完成するシンプルさもこのフレームワークの強み。新しいプロダクトや機能を企画するとき、コードを1行も書く前にこのキャンバスを1枚描いてみてほしい。