実践

デザイン思考でプロダクトロードマップを優先度付けする——機能積み上げから脱出するための実践論

プロダクトロードマップの優先度付けにデザイン思考を適用する方法を解説。機能要望の「積み上げ地獄」から脱出するために、Teresa TorresのOpportunity Solution Tree、Kanoモデル、HMW問いを組み合わせた実践的フレームを提示します。

12分で読める
#デザイン思考 プロダクト管理 #プロダクトロードマップ 優先度 #Opportunity Solution Tree #Kanoモデル 実践 #プロダクト管理 デザイン思考

プロダクトマネージャーが「機能要望リスト」と向き合うとき、たいていこんな状況に陥っています。営業から「大手クライアントが○○機能を求めている」という声が入る。CSから「解約の理由に△△がない点が挙げられる」という報告が上がる。エンジニアからは「□□の技術的負債を解消したい」という要望がある。それを全部リスト化すると、優先度の根拠がどれも「言っている人が強い」になる。

ProductPlanが毎年実施するState of Product Management調査では、機能優先度付けがプロダクトチームの最大の運用課題として繰り返し上位に挙がっています（2024年版）。この問題の本質は、機能の要望を受け取る体制は整っていても、顧客の「本当の問題」を理解する体制が整っていないことにあります。

「機能の積み上げ」が起きる構造的理由

ロードマップが機能のリストに変質する理由は、意思決定のプロセスが「インサイドアウト」になっているからです。社内の各部門が自分たちの問題意識からロードマップに機能を追加し、顧客の実際の体験から逆算される機能が後回しになる。

デザイン思考の視点からこの問題を診断すると、「共感フェーズを省略したまま定義・発想フェーズに入っている」状態です。顧客が何に困っているかを深く理解せずに、解決策（機能）を先に積み上げている。

ステップ1：Opportunity Solution Tree で問いの構造を作る

Teresa Torres（プロダクトディスカバリーコーチ、producttalk.org主宰）が2016年に提唱したOpportunity Solution Tree（OST）は、この問題に直接対処するフレームです。

OSTの構造は4層です。

Outcome（達成したいビジネス指標）→ Opportunity（顧客の課題・ニーズ・欲求）→ Solution（Opportunityに対応する解決策）→ Experiment（Solutionが機能するかを検証する実験）

最重要なのは「Opportunityの層」です。Torresの主張は明確で、「機能を優先度付けする前に、解くべきOpportunityを優先度付けする」ことが先決です。Opportunityとは「顧客インタビューから発見された、顧客の未充足ニーズ・痛み・欲求」であり、社内の要望ではありません。

OSTをロードマップ策定に使うとき、順序は次の3段階になる。

まず、チームが追うべきOutcomeを1つに絞ります（例：「60日以内のチャーン率を月1%以下に下げる」）。次に、顧客インタビューを通じてOpportunityを収集します（例：「オンボーディング後に毎日ログインする理由がわからない」「他チームへの共有方法が複雑で、そこで止まる」）。Opportunityが揃ったら、その中で「どれが最もOutcomeに影響するか」を優先度付けします。機能の優先度付けは、Opportunityの優先度が決まった後に行います。

この順序の逆転が、機能積み上げ地獄から脱出する核心です。

ステップ2：Kanoモデルで顧客価値の次元を分類する

Opportunityが整理できたら、次は解決策の候補を「どれが顧客満足に最も効くか」の観点で評価します。Kanoモデルはそのために有効なツールです。

Kanoモデルは、1984年に狩野紀昭ら（東京理科大学）が提唱した顧客満足モデルです（Kano, Seraku, Takahashi, Tsuji “Attractive Quality and Must-Be Quality,” Journal of the Japanese Society for Quality Control, 14(2), 1984）。機能を3カテゴリに分類します。

「当たり前品質（Must-Be）」 は、なければ強い不満を生むが、あっても当然とみなされる機能です。例：バグのない動作、基本的なデータ保存。

「一元的品質（Performance）」 は、良くするほど満足が上がり、悪くするほど不満が増す機能です。例：読み込み速度、検索精度。

「魅力的品質（Attractive）」 は、あると嬉しいが、なくても不満にはならない機能です。顧客が自分では言語化していないニーズを満たす。例：予想外の自動化、思いがけない発見につながる推薦機能。

優先度付けへの示唆は、「魅力的品質を見つけることが差別化の源泉」という点にあります。競合他社がすでに持っている機能は、時間が経つと「当たり前品質」に下がります。顧客インタビューでまだ言語化されていないニーズを見つけ、それを「魅力的品質」として実装することが、ロードマップの戦略的価値を作ります。

実際の評価方法は、顧客に「この機能が（ある/ない）とき、どう感じますか？」という2方向の質問を投げ、回答の組み合わせからカテゴリを判定します。

ステップ3：HMW問いでOpportunityを具体化する

Opportunityを発見した後、アイデア出しに入る前に「解くべき問い」を一文で立てる。デザイン思考のHow Might We（HMW）問いが、この橋渡しを担う。

HMW問いの設計原則は、「広すぎず、狭すぎず」です。「ユーザーのオンボーディングをどう改善するか？」は広すぎる——解決策が無限に広がりすぎて収束できません。「ウェルカムメール件名をABテストする方法は？」は狭すぎる——一つの施策に閉じていてアイデアが広がりません。

適切な幅の例：「新規ユーザーが最初の1週間で、自分のチームにとって価値を感じる瞬間を作るには？」

このHMW問いを、Opportunity一つにつき1〜3問設計します。次の発散フェーズ（アイデエーション）がこの問いを起点に進むことで、「解決策から始まる議論」ではなく「問いから始まる議論」になります。

ステップ4：RICE × Opportunity の統合評価

機能候補が出揃ったら、定量的な評価フレームと組み合わせます。RICEスコアは、プロダクト管理でよく使われる優先度評価フレームです。

RICE = Reach（どれだけ多くのユーザーに影響するか）× Impact（1ユーザーへの影響度）× Confidence（確信度）÷ Effort（開発工数）

ただし、RICEをそのまま使う落とし穴があります。Reach と Impact の推定値が、社内の印象論に依存することです。ここでデザイン思考の顧客インタビューデータを接続します。

「Reach」はOSTで収集したOpportunityの頻出度から算出する。「Impact」はKanoモデルの分類（魅力的品質>一元的品質>当たり前品質）から重み付けする。「Confidence」は顧客インタビューで何人がそのOpportunityを語ったかを参照する。 この接続により、RICEスコアが「数字の印象論」から「顧客インサイトに根拠を持つ評価」に変わります。

チームでの実践：1日ワークショップの設計

上記のフレームをチームで使うには、1日のワークショップ形式が効果的です。

午前（3時間）：Opportunityのマッピング。直近の顧客インタビュー録音・録画・メモを素材に、チーム全員でOpportunityを付箋に書き出します。ここで重要なのは「機能の要望」ではなく「顧客の状況・感情・課題」を書くことです。付箋を類似性でグループ化し、Opportunityクラスターを作ります。

午後前半（2時間）：HMW設計とアイデエーション。優先OpportunityごとにHMW問いを設計し、クレイジーエイツ（8分で8案スケッチ）などのアイデエーション手法でソリューション候補を発散します。

午後後半（1時間）：RICE評価と合意形成。Kanoモデルの分類とRICEスコアを組み合わせて、上位5〜10件に絞り込みます。この段階で合意が取れなかった点は「仮説と検証設計」として翌週のスプリントに持ち越します。

「データドリブン」との違い

「顧客データを見ればいい」という反論があります。確かに行動ログ・ファネル分析・NPS調査は優先度付けの重要な材料です。ただ、定量データが教えてくれるのは「どこで問題が起きているか」であり、「なぜ起きているか」は教えてくれません。

デザイン思考の顧客インタビューは、この「なぜ」を補完します。チャーンした顧客の行動ログを見て「ステップ3で離脱が多い」ことはわかっても、「そのとき頭の中で何を考えていたか」はログに残らない。この「ログの隙間」に、最も価値あるOpportunityが埋まっていることが多い。

まとめ

プロダクトロードマップの優先度付けは、「声が大きい順に並べる」でも「スコアの高い順に自動決定する」でもなく、顧客の問題を深く理解した上で、解くべきOpportunityを選ぶ意思決定です。

OSTで問いの構造を作り、Kanoモデルで価値の次元を分類し、HMW問いで発想を促し、RICEで評価する——この流れが、デザイン思考とプロダクト管理を統合する実践的なフレームです。

機能要望の積み上げを止めるには、「何を作るか」の議論より前に「誰の、どんな問題を解くか」を決める順序を、チームの習慣として設計することから始めます。

関連記事：デザイン思考とアジャイルの統合、ジョブ理論とデザイン思考の接続

参考文献・出典

Related

実践

「良いUXなのに使われない」を解く——デザイン思考にB=MAP（Motivation×Ability×Prompt）行動モデルを組み込む

 実践

デザイン思考とストーリーテリング：洞察を「動く言葉」に変える技術

 実践

デザイン思考とリーダーシップ｜統合的思考が組織を変える