「施策は毎週打っているのに、プロダクトが前に進んでいる気がしない…」
プロダクトマネージャー（PdM）としてキャリアを重ねる中で、こんな停滞感に襲われたことはないでしょうか。多くの機能をリリースし、バックログは常に満杯。忙しく働いているはずなのに、なぜかプロダクトの本質的な成長が感じられない。
この停滞感の根本原因は、アイデアや実行力の不足ではありません。多くの場合、取り組むべき「課題」の解像度が荒いことにあります。
この記事では、プロダクト開発における停滞感を打ち破るための思考法として、漠然とした懸念を「解くべき価値のあるシャープな課題」へと転換する「課題の構造的定義」のプロセスを解説します。
この記事の要約
- プロダクトの停滞は、解像度の低い課題に取り組むことで発生する「モグラ叩き開発」「ロードマップの無政府状態」「疲弊するチーム」という3つの病が原因
- 課題は「見つける」ものではなく、「影響・原因・対象・JTBD・制約」という5つのレンズを通して構造的に「設計」する
- 課題設計のゴールは、Why（課題）とWhat（施策）の因果関係を可視化する「戦略ツリー」を構築し、チーム全体の羅針盤とすること
「解像度の低い課題」が組織にもたらす3つの病
僕たちが「課題だ」と思っているものの多くは、実は課題そのものではなく、表面に現れた「症状」に過ぎません。例えば、「ユーザーの離脱率が高い」や「コンバージョン率が低い」といったKPIの悪化は、あくまで結果です。この症状だけを見て慌てて対策に走ると、組織は深刻な病に蝕まれていきます。
病1：モグラ叩き開発
これは、表面的な問題に場当たり的に対処し続ける状態です。
「ユーザーアンケートで『このボタンの色が気に入らない』という声が多かったので、色を変えましょう」
「とにかくDAUを上げるために、通知の回数を増やしましょう」
こうした施策は、一見するとユーザーの声に応え、KPIに向き合っているように見えます。しかし、根本原因（Root Cause）を無視しているため、本当の問題は解決しません。ボタンの色の問題は、実は「ボタンの配置が悪く、ユーザーがその機能の価値に気づけていない」という課題の現れかもしれません。通知を増やしても、プロダクトのコア体験が向上しなければ、ユーザーはただ通知をオフにするだけ。
結果として、貴重な開発リソースを浪費し、チームは達成感のない作業に疲弊していきます。
病2：ロードマップの無政府状態
解くべき課題が明確に定義・共有されていない組織では、ロードマップの優先順位付けが機能不全に陥ります。
「どの課題が事業インパクトとして最も大きいのか」という共通の物差しがないため、優先順位の決定は、声の大きい部署や役員の鶴の一声といった「政治」に左右されがちです。いわゆるHiPPO（Highest Paid Person’s Opinion）が意思決定の中心になってしまう状態。
結果として出来上がるのは、戦略なき機能の寄せ集め。プロダクトは一貫性のないキメラとなり、ユーザーにもチームにも「このプロダクトはどこへ向かっているのか」が伝わらなくなります。
病3：疲弊するチーム
これが最も深刻な病です。人間は、自分の仕事に意義を見出せないと、パフォーマンスが著しく低下します。
「なぜこの機能を作るのか？」
「これが、ユーザーの何の役に立つのか？」
この問いにPdMが明確に答えられないと、エンジニアやデザイナーはただ言われたものを作る「作業者」になってしまいます。自分の仕事が、誰のどんな課題を解決し、どうプロダクトの成功に繋がるのかが見えない。この状態が続くと、チームのモチベーションは静かに、しかし確実に蝕まれていきます。
課題を「設計」するための5つのレンズ
これらの病を避け、プロダクトを前進させるためには課題は偶然「見つける」ものではなく、知的に「設計（デザイン）」するものだ、と捉える必要があります。
そして課題を構造的に設計するために、以下の5つの「レンズ」を通して物事を捉えるようにすることをおすすめします。
1. 影響のレンズ：本当のコストは何か？
このレンズは、目の前の事象がビジネスやユーザーに与える「本当のコスト」を問うものです。数値をただの数字としてではなく、価値の損失として捉え直しましょう。
- 問い: この問題が放置された場合、失われる機会や価値は具体的に何か？金額や時間に換算するとどれくらいか？
- 例: 「コンバージョン率が1%低い」のではなく、「毎月1,000万円の売上機会を損失している」と捉える。「ユーザーが操作に3分迷っている」のではなく、「全ユーザーの累積で毎月5,000時間分の貴重な時間を奪っている」と捉える。
このように捉え直すことで、問題の深刻度を客観的に評価し、ステークホルダーと危機感を共有できます。
2. 原因のレンズ：なぜ「本当に」起きているのか？
表面的な事象の裏側にある根本原因を探るレンズです。多くのPdMが知る「なぜなぜ分析」ですが、重要なのは一足飛びに結論を出さないこと。複数の仮説を立て、その構造を明らかにします。
- 問い: この事象を引き起こしている直接的な原因は何か？さらにその背景にある根本的な原因は何か？
- 例: DAUが低下しているケースなら、「通知がうざいから（直接原因）」の裏に、「プロダクトのコア体験に価値を感じず、通知をきっかけに思い出す動機がないから（根本原因）」という構造がないか探る。
3. 対象のレンズ：誰が「最も強く」影響を受けているか？
「全ユーザー」という存在はいません。このレンズは、問題の影響を誰が、どのような状況で最も強く受けているのかを特定し、解像度を上げます。
- 問い: この問題で一番困っているのは、新規ユーザーか？ヘビーユーザーか？特定の属性（年代、地域、利用目的）を持つユーザーか？
- 例: 「ユーザーが定着しない」という課題でも、「登録後3日以内の20代ユーザーが、主要機能の価値を理解できずに離脱している」まで特定すれば、打ち手は全く変わってきます。
4. JTBDのレンズ：「本当に」達成したいことは何か？
JTBD（Jobs-to-be-Done / 片付けるべき仕事）とは、経営学者のクレイトン・クリステンセンが提唱した理論で、「顧客は製品を買うのではなく、特定の仕事を片付けるために製品を雇う」という考え方です。このレンズは、ユーザーの表面的な要望の奥にある、本質的な動機や目的を明らかにします。
- 問い: ユーザーはこのプロダクトを使って、どんな「仕事（Job）」を片付けようとしているのか？その仕事の裏にある感情的な欲求は何か？
- 例: ユーザーが「もっと多くの画像フィルターが欲しい」と要望した場合、そのJTBDは「SNSで友人から『センスが良いね』と思われたい」かもしれません。この場合、提供すべきは単なるフィルター機能ではなく、センスを良く見せるための「テンプレート機能」や「AIによる自動補正機能」である可能性が見えてきます。
JTBDについては、“ペルソナ”だけで終わらない。ジョブ理論（JTBD）と掛け合わせて実在する顧客を捉える方法でも詳しく解説しています。
5. 制約のレンズ：どのような「現実」の中で戦っているのか？
最後のレンズは、理想論で終わらせないための現実的な視点です。技術、リソース、ビジネス、市場環境など、我々が動く上で無視できない制約条件を直視します。
- 問い: この課題に取り組む上で、技術的な負債、チームのスキルセット、予算、開発期間、法的要件などの制約は何か？
- 例: 「全く新しい推薦アルゴリズムを開発する」という理想的な解決策も、「既存のインフラを刷新する余裕はない」という制約の前では現実的ではありません。その制約の中で、最善の一手は何かを考える必要があります。
実践プロセス：漠然とした「懸念」を、解くべき「課題」に変える4ステップ
では、これらのレンズを使って具体的に課題を設計する4つのステップを紹介します。
ステップ1：症状の言語化と分解
まず、チームが感じている漠然とした「懸念」や「問題」を、具体的な「症状」としてすべて書き出します。
「なんか最近、売り上げが伸び悩んでいるんだよな…」という懸念であれば、
-
- 新規顧客の獲得数が先々月比で15%減少している
- 既存顧客の平均購入単価が前年比で8%低下している
- LTVの高い優良顧客の解約率が上昇傾向にある
- セールスチームから「競合の〇〇に比べて機能が弱い」という声が週3回以上挙がっている
このように、一つの懸念が複数の事象（症状）から成り立っていることを明らかにします。
ステップ2：5つのレンズを用いた仮説立案
次に、分解した各症状に対して、第2章で紹介した5つのレンズを当てて、構造化された課題の仮説を複数立てます。ここは発散のフェーズ。質より量を重視して、考えられる可能性を洗い出します。
例えば、「優良顧客の解約率が上昇」という症状に対して、
【課題仮説の例】
長期間利用している(対象)、プロダクトのヘビーユーザーは、日々の業務をさらに効率化したい(JTBD)と考えているが、最近追加された多機能さが逆に操作を複雑にしており(原因)、結果として「使いこなせない」というストレスから競合のシンプルツールへ乗り換えている(影響)のではないか？
この段階で重要なのは、仮説の正しさではなく、論理的な構造で課題を記述することです。
ステップ3：定量・定性での検証サイクル
立てた仮説の中から、最もインパクトが大きく、検証可能性が高いものをいくつか選び、検証サイクルを回します。仮説はあくまで仮説。ファクトに基づいて絞り込んでいく必要があります。
- 定量検証: ログデータやCRMデータを分析し、仮説を裏付ける、あるいは否定する客観的な証拠を探します。上記の仮説であれば、「解約したヘビーユーザーは、新機能の利用率が低かったか？」「セッションあたりの滞在時間が増加（＝迷っている）していないか？」などを分析します。（参考: ログ分析→ユーザーインタビューの流れで、「本当に解くべき課題」を明確にする）
- 定性検証: 仮説の対象となるユーザー（この場合は解約したヘビーユーザー）に直接ユーザーインタビューを行い、仮説の裏にある「なぜ」を深掘りします。彼らの言葉から、データだけでは見えないコンテキストや感情を掴むことが目的です。
ステップ4：課題定義の言語化
検証サイクルを経て、最も確からしいと判断した課題を、チームの誰もが誤解なく理解できるシャープな文章に落とし込みます。例えば以下のテンプレートでシンプルにまとめてみましょう。
「[対象] は [JTBD] を達成したいが、[根本原因] により [問題] が生じ、結果として [影響] が出ている」
このテンプレートに沿って最終的な課題を定義します。
【最終的な課題定義の例】
「当プロダクトを2年以上利用するパワーユーザー（対象）は、日々の定型業務を1秒でも速く終わらせたい（JTBD）と考えているが、ここ半年のアップデートで追加された多機能さが、彼らの主要業務フローを逆に複雑化させており（根本原因）、結果として作業時間が平均15%増加し、生産性の低下という致命的な問題（影響）を引き起こしている。」
ここまで言語化できて初めて、その課題は「解くべき価値のある課題」になります。
構造化のゴール ー 課題と施策が一枚岩となる「戦略ツリー」とは？
さて、課題をここまでシャープに定義できたとして、それで終わりではありません。プロダクト開発は、課題を定義してからが本番です。
「プロダクトの課題が施策とセットで構造的に整理された状態」とは何か？
それは、「Why（なぜやるのか）」と「What（なにをやるのか）」が、誰の目にも明らかな因果関係で結ばれた状態です。
この理想的な状態を可視化し、チームの共通認識とするためのツールの1つが、プロダクト思考の第一人者であるTeresa Torres氏が提唱する「オポチュニティ・ソリューション・ツリー（Opportunity Solution Tree）」です（参考: 機能要望の“カオス”を整理し、顧客に本当に必要な価値を届ける「Opportunity Solution Tree」の活用法）
*文脈上「戦略ツリー」と呼びます
これは、プロダクトが目指す成果から逆算して、課題（機会）と施策（解決策）を構造的に整理するフレームワークです。
「戦略ツリー」の構造
戦略ツリーは、大きく4つの階層で成り立っています。
- 根（Root）- 成果（Outcome）: プロダクトが目指す、測定可能なビジネス上の成果や北極星。例：「新規ユーザーの30日後リテンション率を20%向上させる」
- 太い枝（Branches）- 課題（Opportunity）: 成果を達成するために解くべき、構造化されたユーザーの課題。第3章で定義した課題がここに入ります。例：「新規ユーザーが、最初の1週間で成功体験を得られず離脱している」
- 細い枝（Twigs）- 施策仮説（Solution）: 各課題を解決するための具体的な施策のアイデア。例：「オンボーディングを改善し、最初の習慣設定を成功させる」「ゲーミフィケーション要素で初期のモチベーションを高める」
- 葉（Leaves）- 実験（Experiment）: 施策仮説が正しいかを検証するための、具体的なアクションや実験。例：「A/Bテスト：習慣テンプレート提案機能の実装」「ユーザビリティテスト：新しいオンボーディングフローのプロトタイプ」
このツリーがあることで、末端の「葉」（個々の実験や機能開発）が、なぜ重要なのかを、「枝」を遡って「根」（ビジネス成果）まで、誰にでも一目で説明できるようになります。これこそが「課題と施策が一枚岩となった状態」なのです。
なぜ「戦略ツリー」がプロダクトの成否を分けるのか
この戦略ツリーを構築し、運用することは、単なるドキュメント作成作業ではありません。プロダクト開発のOS（オペレーティング・システム）そのものをアップデートする行為です。
フォーカスとレバレッジ
ツリー全体を俯瞰することで、「どの『太い枝』（課題）に注力すれば、最も『根』（成果）の成長に貢献するのか？」という、レバレッジの効いた問いを立てることができます。リソースは常に有限。最も効果的な一点にチームの力を集中させることが可能になります。
アラインメントとスピード
戦略ツリーは、チーム全体の共通言語となります。「なぜこれを今やるのか？」というロードマップに関する議論は、このツリーを見れば一目瞭然。エンジニアは自分の書くコードがどの課題解決に繋がるのかを理解し、セールスやCSはプロダクトの進化の意図を顧客に説明できるようになります。この共通理解が、手戻りや不毛な議論を減らし、意思決定のスピードを劇的に向上させます。
再現性と学習
たとえ施策（葉）が失敗に終わったとしても、それは貴重な学びとなります。「この施策は、この課題を解決するには至らなかった」という事実が明確になるからです。成功も失敗も、すべてがツリー上の学びとして蓄積され、次の意思決定の精度を高めていきます。これが、プロダクトと組織が持続的に成長するエンジンとなります。
「解決者」か、それとも「設計者」か
「施策は打っているのに、プロダクトが前に進んでいる気がしない」
この記事の冒頭で提示したこの停滞感は、いわば地図を持たずに暗闇の森を歩いている状態です。一つ一つの木（施策）をなぎ倒しても、森全体（プロダクト）から抜け出すことはできません。
課題を構造的に定義し、戦略ツリーを描くことは、この森を上空から眺め、目的地までの最短ルートを示す地図を手に入れる行為に他なりません。
優れたPdMは、単なる「解決者（Solver）」ではありません。解くべき価値のある問題を特定し、チームが向かうべき道を照らし出す「設計者（Designer）」です。プロダクトの未来は、あなたがどんな「課題」を設計するかで決まるのです。
今日から実践できるアクション
- 懸念を書き出す（5分）: あなたのプロダクトで「なんだか気になる懸念」を一つ選び、それに関連する「症状」を3つ以上書き出してみてください。
- 一つの症状をレンズで眺める（15分）: 書き出した症状の中から一つだけ選び、第2章で紹介した「5つのレンズ」を当ててみてください。特に「対象」と「JTBD」を考えると、新しい視点が得られるはずです。
- 課題をテンプレートで記述してみる（10分）: 「[対象] は [JTBD] を達成したいが、[根本原因] により [問題] が生じ、結果として [影響] が出ている」というテンプレートを使って、仮説レベルで良いので課題を一行で記述してみましょう。
Q&A
- Q1. 課題設計に時間をかけると、開発が遅れると上司に言われます。どうすれば良いですか？
- A1. これは「初期投資」だと説明するのが効果的です。最初に1週間かけて課題を正しく設計することで、その後の3ヶ月で発生するであろう手戻りや方向修正のコスト（＝無駄な開発期間）を未然に防げると伝えてみてください。「急がば回れ」を地で行くのが課題設計です。初期段階での不確実性を減らすリスク管理の一環である、という視点も有効です。
- Q2. スタートアップで時間もデータもありません。このプロセスは実践できますか？
- A2. もちろん可能です。むしろ、リソースが限られているスタートアップだからこそ、的外れな開発を避けるための課題設計が生命線になります。データがなければ、まずは顧客数名へのデプスインタビューから始めましょう。完璧な分析より、スピード感のある仮説検証が重要です。「リーン・スタートアップ」の考え方に通じますね。（参考: 【要約】プロダクト開発の定番書『リーン・スタートアップ』をあらためて噛み締める）
- https://pm-ai-insights.com/lean-startup/
- Q3. 課題と施策をツリーで管理するのは大変そうです。もっと簡単な方法はありますか？
- A3. 最初から完璧なツリーを目指す必要はありません。まずはGoogle Docsやスプレッドシートに、「成果」「課題」「施策案」の3つを箇条書きにするだけでも思考は整理されます。重要なのは、ツールではなく、常にあらゆる施策を「これはどの課題を解決するためだっけ？」と問い続ける習慣です。
参考情報
- Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.
- Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). Competing Against Luck: The Story of Innovation and Customer Choice. HarperBusiness.
- 安宅和人. (2010). イシューからはじめよ――知的生産の「シンプルな本質」. 英治出版.
コメント