こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp
社内で口癖のように使っている「製品解像度」と「UX志向」について自分の思考の整理もかねて記事にまとめてみました。
- はじめに：私たちは「誰」を見ているのか？
- 「製品解像度」とは何か？
- まず押さえたい：製品解像度が低いと起きる“あるある”
- なぜ「お客様解像度」だけでは不十分なのか？
- UX志向を支える「意思決定」の力
- 製品解像度を高めるために
- 製品解像度が上がると何が起きるか：アウトプットの質が変わる
- おまけ：製品解像度を上げるための「10の問い」（会議で使える）
- おわりに：最高のUXへの近道
はじめに：私たちは「誰」を見ているのか？
「UX（ユーザーエクスペリエンス）志向」 「ユーザー中心設計」 「顧客視点」プロダクト開発の現場にいると、これらの言葉を聞かない日はありません。私たちプロダクトに関わるメンバーは、常にお客様のことを考え、彼らの課題に寄り添い、最高の体験を届けようと日々奮闘しています。しかし、ここで一度立ち止まって考えてみたい問いがあります。
「お客様のことさえ深く理解していれば、本当に優れたプロダクトは作れるのだろうか？」
という問いです。自分としての結論は“お客様理解だけでは足りない”です。 もちろん、お客様を理解することは不可欠です。しかし、それだけでは「良いプロダクト」を継続的に生み出し、育てていくことはできません。
時に「お客様のため」を思うあまり、ビジネスとして成立しない機能を作ってしまったり、技術的に無理のある実装を強いてプロジェクトを破綻させてしまったりすることさえあります。
では、私たちには何が必要なのか？ そこで私が提唱したいのが、「製品解像度」という概念です。 今回は、単なる「お客様解像度」を超え、真の意味でプロダクトを成功に導くための「製品解像度」について、その定義となぜそれが不可欠なのかを紐解いていきます。
「製品解像度」とは何か？
まず、「解像度」という言葉についてです。自分の中では解像度は写真の比喩が一番しっくりきます。ピントが合っていない写真は、全体の雰囲気はわかるけれど、重要なディテール（表情・文字・境界線）が見えません。プロダクトでも同じで、解像度が低いと、議論が抽象的になり、判断が“気分”や“声の大きさ”に引っ張られます。逆に解像度が高いと、論点が具体になり、仮説と事実が整理され、意思決定が速くなる。
この「ピントの合い方」を、製品を取り巻く全体に広げたものが“製品解像度”として自分は定義しています。具体的には、次のような観点です。
- お客様：誰が、どんな状況で、どんな目的で使っている／使おうとしているか （運用中・導入準備中・導入検討・未検討といったフェーズも含む）
- システム：制約、データの流れ、既存アーキテクチャ、運用条件
- UI/UX：主要導線、つまずきポイント、体験の一貫性
- ドメイン：業務知識、法令、慣習、現場の「当たり前」
- 自組織／他組織：意思決定構造、責任分界、依存関係、コミュニケーション経路
- 事業戦略：何を伸ばし、何を守り、何を捨てるのか（優先順位）
- 市場：競合、代替、ポジショニング、差別化要因
- 未来：中長期の方向性、ロードマップ上の“意味”
- 開発プロセス／役割：どう作り、どう届け、どう改善していくか
製品解像度とは、プロダクトを取り巻くエコシステム（生態系）全体に対する理解の深さを意味します。これら全てを網羅し、それぞれの要素がどう絡み合っているかを理解している状態こそが、「製品解像度が高い」状態と言えます。
まず押さえたい：製品解像度が低いと起きる“あるある”
製品解像度が低い状態は、努力不足というより「見えていないから判断できない」状態です。現場でよく起きる症状を挙げます。
- 顧客要望をそのまま機能要件に翻訳してしまい、根っこのジョブや制約を見落とす
- 「これが良さそう」という仮説だけで意思決定してしまい、後から前提が崩れて手戻りする
- “十分な検討のないトレードオフ”になり、関係者の納得が得られない
- リリース後、成果が測れず、改善が続かない（やりっぱなしになる）
- 部署間の認識がズレて、会議で「それは誰が決めるの？」が発生する
どれも、個人の能力というより「判断材料が揃っていない」ことが原因です。だからこそ、解像度を上げることが、チームの再現性をつくります。
なぜ「お客様解像度」だけでは不十分なのか？
「お客様第一」は美しい言葉ですが、プロダクトマネジメントの現実はもっと複雑で泥臭いものです。なぜ「お客様解像度」だけでは戦えないのか、その理由を構造的に解説します。
The Product Management Triangle Posted by Dan Schmidt, Product Logic
※ラクスのプロダクト部向けにカスタマイズ
プロダクト開発には有名な「プロダクトマネジメント・トライアングル」という概念があります。これは、プロダクトが以下の3つの要素のバランスで成り立っていることを示しています。
- 開発者（Developers）
- お客様（Customers）
- ビジネス（Business）
この3つの頂点を繋ぐ辺（関係性）を見てみましょう。
- お客様 × 開発者 ＝ UX（ユーザー体験） お客様のニーズを技術でどう解決するか。ここから優れたUXが生まれます。
- お客様 × ビジネス ＝ 価値交換（収益） お客様への価値提供が、いかに対価としてビジネスに還元されるか。ここから利益が生まれます。 3. 開発者 × ビジネス ＝ 実現可能性（デリバリー） ビジネスの要求を、限られたリソースと技術でどう実現するか。ここから製品が世に出ます。
もし、あなたが「お客様解像度」しか持っていない場合、見えるのは「1. UX」の領域だけです。 「お客様がこう言っているから機能を追加しよう」と提案しても、それがビジネス的に採算が合わない（2の視点の欠如）ものであれば却下されるでしょう。また、技術的に莫大なコストがかかる（3の視点の欠如）ものであれば、開発チームとの信頼関係を損なうかもしれません。
「製品解像度」を持つということは、このトライアングル全体を俯瞰し、3つの辺すべてを健全に機能させる視点を持つということです。
質の高いアウトプットを生む土壌
「アウトプットの質」とは何でしょうか？ 単に「見た目が美しいUI」や「バグのないコード」のことでしょうか？
プロダクト開発における「質」とは、「実現可能性（Feasibility）」と「事業性（Viability）」と「有用性（Desirability）」が高い次元で融合していることです。 お客様の要望（顕在ニーズ）に応えることは重要です。しかし、プロフェッショナルであるならば、その要望をそのまま形にするのではなく、「技術的に最も効率的で」「ビジネスとして持続可能で」「かつユーザーの課題を根本から解決する」ソリューションを導き出さなければなりません。
システム構造を知らなければ、非効率なUIを設計してしまうかもしれません。 事業戦略を知らなければ、来年には不要になる機能を作り込んでしまうかもしれません。製品解像度を高めることは、これら「見落とし」をなくし、手戻りを防ぎ、最初から精度の高いアウトプットを生み出すための必須条件だと考えています。
UX志向を支える「意思決定」の力
プロダクト開発は「意思決定」の連続です。 「Aという機能を優先するか、Bという改善を優先するか」 「リリースを早めるか、品質を高めるか」 こうした岐路に立ったとき、製品解像度の差が如実に現れます。
「OR」ではなく「AND」を模索する
解像度が低いと、安易なトレードオフ（ORの決断）に逃げがちです。 「ビジネス側の要求だから、UXは諦めよう（Business OR UX）」 「技術的に難しいから、仕様を落とそう（Tech OR UX）」
しかし、製品解像度が高い人は、各要素のつながりが見えているため、「AND」の解を模索できます。 「技術的にはこの制限があるが、UIの工夫でユーザーの負担は減らせるのではないか？」 「ビジネス目標のKPIは、この機能を少し簡略化しても達成できるのではないか？」
ビジネスの制約（利益・コスト）、技術的な制約、そしてお客様のニーズ。これら全てを深く理解しているからこそ、単なる妥協ではない、創造的な第三の案を生み出すことができるのです。
「架け橋」としての役割
プロダクト部のメンバーには、ビジネスチームと開発チームの「架け橋」としての役割が求められます。
通訳をイメージしてください。英語しか話せない人と日本語しか話せない人の間に入る通訳が、片方の言語しかわからなかったらどうなるでしょうか？ 会話は成立しません。
これと同じです。 ビジネスサイドの言語（売上、KPI、市場シェア）と、開発サイドの言語（アーキテクチャ、工数、技術的負債）。そしてお客様の言語（使いやすさ、課題解決）。 これら全ての「言語」を理解し、翻訳できるのが「製品解像度が高い人」です。
ビジネスチームには「なぜこのUX改善が将来の売上につながるのか」をロジカルに説明し、開発チームには「なぜこのビジネス要件が重要で、どう実装するのが最適か」を技術背景を踏まえて相談する。 この動きができる人材こそが、組織の中で真に信頼されるプロダクトパーソンとなれるのです。
ラクス プロダクト部としての「UX志向」
プロダクト部では本組織が組成される前（PdM組織の頃）から、以下を提示して、メンバーや自分自身もこれに従うようにしています。
製品解像度を高めるために
では、どうすれば製品解像度を高めることができるのでしょうか？ 明日からできるアクションをいくつか提案します。
1. 「越境」を恐れない
自分の担当領域の外に出ましょう。デザイナーなら、売上の数字を見てみる。エンジニアなら、営業に同行してお客様の声を聞く。プロダクトマネージャーなら、システム構成図を書いてみる。 「それは私の仕事ではない」と線を引いた瞬間、解像度の上昇は止まります。
2. 「なぜ？」を問い続ける
仕様書や要件定義書を見たとき、そこに書かれていることの背景を想像してください。 「なぜこの機能が必要なのか？（ビジネス背景）」 「なぜこの実装方法なのか？（技術背景）」 「なぜ今なのか？（市場背景）」 わからないことは、その領域のプロフェッショナル（営業担当やエンジニア）に質問しましょう。彼らは自分の領域に関心を持ってくれる人を歓迎するはずです。
3. プロダクトの「歴史」と「未来」を知る
過去の意思決定の経緯（なぜこの機能があるのか）を知ることで、現在の制約の意味がわかります。そして、ロードマップ（未来の構想）を知ることで、今作るべきものの優先順位が見えてきます。点ではなく、線でプロダクトを捉えましょう。
製品解像度が上がると何が起きるか：アウトプットの質が変わる
製品解像度の価値は、抽象論ではなく、アウトプットに表れます。具体的には次の変化が起きます。
1) 要求仕様が“外れにくくなる”
解像度が高いと、論点の抜け漏れが減り、前提が揃うので、要求仕様（PRD）やデザインが当たりやすくなります。組織の重点取り組みでも「製品を取り巻く解像度を向上し、外れのない要求仕様を策定して開発に提供できる状態」を目指す、と明確に言語化されています。まさにここが、製品解像度が“成果”に変わる瞬間です。
2) トレードオフの説明責任が果たせる
UXは必ずトレードオフの連続です。どれを捨て、どれを採るか。その判断が“十分な検討のないトレードオフ”になってしまうと、ステークホルダーは納得しないし、ユーザーも幸せにならない。製品解像度が高いチームは、制約を含めて説明できるので、合意形成が進みます。
3) 「事実に基づく」文化が回りやすくなる
お客様の声、利用データ、市場情報、開発・運用の実態。これらを同じテーブルに乗せられるようになると、仮説と事実が区別され、議論の質が上がります。「なんとなくこう思う」から、「この事実があるからこう判断する」へ。UX志向の行動原理と相性が良いのはここです。
4) “作って終わり”から“学習して伸ばす”に変わる
解像度が高いチームは、指標（NSMや関連指標など）を置き、リリース後に成果を回収し、開発にも共有して次に活かします。改善が単発のイベントではなく、学習ループになります。
おまけ：製品解像度を上げるための「10の問い」（会議で使える）
この問いは、答えを完璧に揃えるためというより、「ピントが合っていない領域」を早めに炙り出すために使ってもらえればと思います。
おわりに：最高のUXへの近道
「製品解像度を持つべきだ」という主張は、一見するとUX志向とは対極にある「ビジネス寄り」「システム寄り」の話に聞こえるかもしれません。 しかし、逆です。 本当に優れたUXを実現したいのであれば、製品解像度を高めることが一番の近道なのです。
お客様のことしか見ていない「優しさ」は、時にプロダクトを脆弱にします。 ビジネスと技術という現実の厳しさも含めてプロダクトを愛し、理解する「強さ」こそが、長く愛され続けるサービスを育てる土壌となります。 私たちプロダクト部のメンバー一人ひとりが、お客様解像度だけでなく、この「製品解像度」という武器を持ったとき。私たちの組織は、ビジネスの要請にも、技術の進歩にも、そして何よりお客様の期待にも、かつてない高いレベルで応えられるようになるはずです。
まずは今日、隣の席の別職種のメンバーに、彼らが見ている「製品の景色」について聞いてみることから始めてみませんか？
製品解像度を上げることは、意思決定の質を上げるだけでなく、結果として“お客様の業務が止まらない/迷わない”体験に直結すると自分は思っています。
記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー／PdM の方 は、ぜひカジュアル面談からご応募ください。
※プロダクトマネージャーのカジュアル面談は、基本的に私（稲垣）が担当します！
●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp
