プロダクトマネージャーの皆様。曖昧な課題を前に「何が問題か分からないまま、とりあえず作業する」という状況に陥っていないでしょうか？
僕自身、テック企業でPMやマーケターを務める中で「問題の解像度」が足りないと苦労が増え、成果が伸び悩むのを何度も見てきました。
そこで、本記事では『解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の4視点と行動法』（以下『解像度を上げる』と表記）を要約し、プロダクトマネージャー向けにそのエッセンスを濃厚にお伝えします。
本書は曖昧な問題をいかにクリアにし、行動まで落とし込むかを「深さ」「広さ」「構造」「時間」という4つの軸で解説しており、PMの実務に活用できるヒントが詰まっています。
なぜ「解像度を上げる」ことが大事か
『解像度を上げる』は、曖昧さに翻弄される現場で、物事をいかに明確化し、高い精度の決断を行うかをテーマとする一冊です。
「よく分からないままやる」「なんとなく指示されたから動く」といった「解像度の低い思考」では、短期的な努力の割に成果が出ないし、チームや顧客との齟齬も増えてしまいます。
解像度を高めるには、表面的な認識に留まらず、問題を立体的・多面的に把握する必要がある。そのための枠組みとして、本書は「深さ」「広さ」「構造」「時間」の4視点を提示します。
僕自身、例えばtoCスタートアップをやっていてプロダクトロードマップを引く際に「この機能が本当に必要か？」を見極められないまま進めてしまい、リリース後に使われない機能が生まれる経験をしました。
その反省を踏まえ、「深さ・広さ・構造・時間」を意識して要件やタスクを検討すると、自然と施策の優先順位が定まり、不要な作業を減らせます。
本書が解説する4視点は、そんな苦い経験をもつPMにとって「曖昧を脱出するための羅針盤」になると感じています。
「深さ」 – 表面だけでなく根底の原因や目的を徹底的に追う
4つの視点のなかで、何よりもまず重要なのが深さ。
本書では、大体の場合について深さが足らない、と言及されています。
曖昧な状態とは、言い換えれば「本質が見えず、表層的な理解に留まっている」こと。
たとえばユーザーが「このUIが使いにくい」と言ったとき、そこから一歩踏み込んで「なぜ、いつ、どの操作が難しいのか」を掘り下げるプロセスが必要。
そこを端折ると、「なんとなくUIを綺麗にする」程度の対応に留まり、根本的な課題（実際はデータ入力が面倒だった、サポートがないなど）を取り逃してしまう。
つまり、ユーザーやドメイン知識にダイブして、ドリルでどんどん深く掘っていくかのようにとにかく深く、深く理解していくのです。
具体的な深掘り手法としては、インタビュー質問で5 Whysを活用したり、定性情報をGTM（Grounded Theory Method）で分析するなどのアプローチが効果的。
プロダクトマネージャーの実務でも、深さを意識すれば「ユーザーの声を表面的にまとめるだけ」から脱し、実際にどんな操作や心理が絡んでいるかを綿密に理解できる。
たとえば「ChatGPTでユーザーインタビューの分析を爆速にする具体手法を解説」の記事なども、深さを確保する一助になると実感しています。
そのほかにも、「深さ」を出す方法として以下のようなものがあります。
- （繰り返しですが）ユーザーインタビューを繰り返す
- エスノグラフィー
- 実際にユーザーと同じ行動をする
- みんなで自分たちと競合のサービスを触って記録する
- 関連する本を10冊読む
- chatGPTのDeep Researchで1時間とにかくそのユーザーとドメインのことを調べ上げる
「広さ」 – 視野を広げ、多面的に捉える力
次が、広さ。
深さが“縦”なら広さは“横”のイメージ。
ぼくたちは往々にして、特定のユーザーや機能にフォーカスしすぎるあまり、他のセグメントや競合、周辺機能を見落とす場合がある。結果、改善策が局所的で大きなインパクトに繋がらないこともある。
「視野を狭くしすぎると、最適解を得られない」ので、周辺領域のリサーチや代替手段の調査などを怠らない姿勢が重要です。
たとえばBtoB SaaSで考えると、実際に操作する現場担当者以外に導入意思決定をする役員や法務部、経理など多くのステークホルダーが存在。
ここで広さを確保しなければ、「実は決裁者がそこにコストをかける意義を感じていない」「現場担当者の声だけでは不十分」というズレが生じる。
競合製品やユーザーが使っている既存のシステムとも比較しないまま開発を進めれば、後から「すでに同じ機能が一般化していた」という笑えないオチもありえる。
そういう失敗を防ぐためにも、深さと広さを両輪で回すことが欠かせません。
「構造」 – 複雑な要素間の繋がりを整理し、ブレを減らす
3つ目の視点である構造は、問題を解像度高く捉えるうえで欠かせません。
深さと広さを確保しても、それらをバラバラに持っているだけでは「どの要素がどう繋がっているか」不明なまま。そこに構造という視点を加え、要素同士の関係や因果を図解・モデル化していく。
プロダクト開発の具体例でいえば、画面遷移図やデータフロー、ユーザージャーニーなどが挙げられます。あと基本的にはロジックツリーは大体のケースで使えるので僕はいつも使っています。
なぜ構造が重要かというと、チーム全員が同じマップを共有すれば、ある機能変更のインパクトがどこに波及するか瞬時にイメージでき、意思決定が速くなるからです。
『解像度を上げる』でも、構造化による思考の明確化を強く推奨しています。複雑な問題を扱うときは、まず各要素（ユーザー、機能、データ、ステークホルダーなど）を洗い出し、論理的な繋がりを可視化。
プロダクトマネージャーにとっては、ロードマップの構造やチーム編成の構造なども含めて、全体像がスッキリ見渡せる状態を作ることが、混乱を大幅に減らす近道といえるでしょう。
僕自身、過去にmiroでプロダクトの利用開始からの全ての画面を並べてフロー図化して、それまでのユーザーインタビューや分析で上がった課題を全てプロットし、課題同士を構造的に接続しようと試みました。これがめちゃくちゃワークして、チーム全員で自分たちのサービスやその顧客が直面している課題を構造的に捉えることができました。
「時間」：変化の流れを読み取り、計画倒れを防ぐ
4視点の最後は「時間」です。
曖昧な課題の解像度を高めるには、深さ・広さ・構造の観点だけでなく、「いつ、どのように問題を捉え、変化を追うか」の時間軸を考える必要があると本書は訴えます。
例えば、同じ課題でも「今の課題」なのか「5年後にも続く課題」なのかで対処が変わります。時間を軸に課題の推移や関連要素の変化を捉えることで、単なる“点”ではなく“流れ”として問題を理解できます。
プロダクト開発でも、時間を無視してタスクを並べると「せっかくの学びを次のリリースに反映できない」「ユーザーインタビュー結果が腐ってしまう」などの事態に陥ることが多い。
時間を意識した設計としては、次のような方法が挙げられます。
- スプリント計画：どのタイミングで検証し、いつ開発に反映するかを明確化
- 中長期視点：5年後の市場変化やユーザー行動の変遷を予測し、課題が将来も有効か見極める
- バージョン管理：リリースを段階的に行い、フェーズごとに学習フィードバックループを回す
たとえば「2週間のスプリントでUIのプロトタイプを作成し、ユーザーインタビューでフィードバックを得る。翌スプリントで修正、さらに次のリリースで本番投入」という時間的流れを先に組むだけで、計画倒れを防ぎやすい。
4つの視点を組み合わせる：深さ・広さ・構造・時間が解像度を高める
ここまで説明した4視点「深さ・広さ・構造・時間」は、本書『解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の4視点と行動法』のコアです。
ただし、「一つの視点だけ磨いても、曖昧さを払拭できない」ことに注意が必要です。例えば
- 深さにこだわりすぎて広さを欠くと、狭いケースしかカバーできない（重要な課題を見逃す）
- 構造が整理されないまま時間ばかり意識しても、実装で整合性が崩れる
などなど。
4つを同時に意識することで、あらゆる方向から課題を明確化し、最小のコストで最大の成果を出しやすくなるのだと本書は述べています。
プロダクトマネージャーがよく直面するのは「仕様がぼんやりしたままスケジュールだけが決まっている」という状況。
このときにこそ、深さで課題を掘り下げ、広さで周辺要素を俯瞰し、構造でチームの認識を揃え、時間で計画を分割する仕組みを入れましょう。
結果、曖昧だった問題が段階的にクリアになり、チームも納得して動き出せるというわけです。
PMが4視点を使う具体ステップ
著者が提示する4視点を、実際にプロダクト開発でどう取り入れるか。僕自身、以下のようなステップに落とし込むことを意識しています。
1. 課題・要望を受けたら4視点チェックリストで確認
- 深さ: どこまで掘り下げたか？
- 広さ: 他セグメントや競合など見落としてないか？
- 構造: 図やマッピングで関連を整理したか？
- 時間: スプリントやリリーススケジュールはどうするか？
2. 会議やインタビューで使う
- 例：インタビュー時、
- 「このセグメントの声をどの程度掘り下げるか」(深さ)
- 「周辺のセグメントをも考慮すべきか」(広さ)
- 「分析結果をどう構造化するか」(構造)
- 「いつ施策反映するか」(時間)。
3. ロードマップ策定時にテンプレ化
- 施策ごとに4視点を書き込める欄を作り、バックログ優先度を決める前に詰める。
- 深さ・広さ・構造・時間が不明瞭な施策は後回しか保留。
- 例えば「深さ」「広さ」「構造」「時間」の各列をNotionなどに設置。
今日から実践できるアクション
- タスクに4視点のメモをつける
スプリントバックログやロードマップ項目に「深さ」「広さ」「構造」「時間」を一言で記載。
曖昧なタスクを減らし、次のステップを具体化する。 - インタビューガイドに4視点を落とし込む
深さ: どの程度掘り下げるか。
広さ: どのセグメントを対象にするか。
構造: 質問項目をどう並べるか。
時間: 結果を何週間後の開発に反映するか。
これで漠然としたインタビューを避けられる。 - チームレビューで4視点の観点からフィードバック
「深度が不十分」「他要素との連携（構造）が曖昧」「広さが足りない」「次のリリースまで時間軸が合ってない」などを具体的に指摘。
全員が4視点を意識すれば、自然と解像度が上がる。 - 小さな成功事例を作り、組織に広める
まずは1つの施策で4視点を徹底活用。結果が良ければチーム全体に共有し、文化として根付かせる。
「解像度を上げる」ことのメリットを実感できると、皆の意識が変わる。
Q&A
- Q1. 4視点を全部カバーしようとすると時間がかかりませんか？
- A. すべてを完璧にやる必要はありません。最初は最重要施策だけに4視点を適用し、深く検討するところから始めれば十分効果を感じられます。
- Q2. すでにアジャイル開発やMVP検証を取り入れています。何が変わりますか？
- A. アジャイルやMVPとも非常に相性がよいです。深さや構造などを意識することで、検証対象が明確化し、スプリント中のタスクがさらに有機的に繋がります。
- Q3. チームメンバーが多忙で、4視点に従ってドキュメント化するのは大変なのでは？
- A. 大規模なドキュメントは不要。箇条書きや簡易な図でも構いません。大事なのは「深さ・広さ・構造・時間」のそれぞれを意識したメモやテンプレをチームが共有すること。
少しずつ慣れれば大きな負担にならず、むしろコミュニケーションがスムーズになります。
参考情報
- 『解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の4視点と行動法』
- Jakob Nielsen & Thomas K. Landauer (1993). “A Mathematical Model of the Finding of Usability Problems.” Proceedings of ACM INTERCHI’93
- Eric Ries『The Lean Startup』（2011）
- 安宅和人『イシューからはじめよ』（ダイヤモンド社, 2010）
- ユーザーインタビュー前に「筋の良い仮説」をチームで設定する具体的な方法やフレーム
- ユーザーインタビューの目的・設計・やり方・分析まで完全ガイド
- プロトタイプを使って、ユーザーインタビューで新機能の検証を行う方法・Tips
コメント