この記事の要点(UIXHERO視点)
- 解決策(Solution)に飛びつく前に、問題(Problem)に恋をしろ。
- 「何を作るか(How)」の前に「なぜ作るか(What/Why)」を定義する。
- この2つを混ぜると、誰も欲しがらない機能を完璧に作ることになる。
導入:我々は「解決策」に恋をしすぎる
「AIを使ったチャットボットを作ろう!」 「ブロックチェーンで信頼性を担保しよう!」 「モーダルウィンドウで注意を引こう!」
プロジェクトの初日、ホワイトボードはこうした「アイデア」で埋め尽くされます。 チームは高揚し、すぐに・画面設計(UI)や実装の議論が始まります。
しかし、ここで冷水を浴びせるような質問をひとつ投げかけてみてください。
「で、それは誰の、どんな問題を解決するんだっけ?」
一瞬の沈黙の後、「えっと、便利になるから…」といった曖昧な答えが返ってきたら危険信号です。 これが 解決空間(Solution Space)への偏り です。
UIXHEROでは、これを単なる「手順の違い」ではなく、 「思考の領域汚染」 と呼びます。 問題が明確でないまま解決策を議論することは、地図を持たずに全力疾走するのと同じです。
問題空間と解決空間とは(定義)
用語データ
「何が問題か(What)」と「どう解決するか(How)」を、明確に別世界として扱う思考法
| 項目 | 内容 |
|---|---|
| 英語表記 | Problem Space / Solution Space |
| 日本語表記 | 問題空間 / 解決空間 |
| 分類 | プロダクト戦略 / デザイン思考 |
Interactive Example (Live)
const Definition = () => { return ( <div className="bg-[#FFF9E5] border border-[#FFE082] rounded-lg p-6 text-slate-800 mb-8"> <div className="text-[#8B5E3C] font-bold text-xs tracking-widest mb-3 uppercase">UIXHERO Definition</div> <div className="text-lg font-medium leading-relaxed"> 問題空間と解決空間とは、「<b>ユーザーが直面している課題や状況(Problem)</b>」と「<b>それに対する具体的な施策・機能・UI(Solution)</b>」を、意図的に分離して扱う思考枠組みである。<br/> 優れたプロダクト開発では、この2つを同時に議論せず、まず問題空間を十分に探索・定義したうえで、解決空間へと移行する。 </div> </div> ); }; render(<Definition />);
語源と背景
この概念は、『リーン・スタートアップ』(Eric Ries)や『The Design of Everyday Things』(Don Norman)など、多くのUX・プロダクト開発の名著で語られてきました。 特に「ダブルダイヤモンド(Double Diamond)」モデルでは、この2つを 発散と収束 のプロセスとして視覚化しています。
研究からの引用 : "Fall in love with the problem, not the solution." (Uri Levine, Waze Founder)
イスラエルの起業家Uri Levine(Waze創業者)が繰り返し強調する言葉である。
なぜ重要なのか(心理的背景)
なぜ私たちはすぐに解決策に飛びついてしまうのでしょうか?それには人間の心理的なバイアスが関係しています。
1. 解決策バイアス(Solution Bias)
人間は本能的に「問題を解決すること」に快感を覚えます。曖昧な「問題空間」に留まることは不安であり、具体的な「解決策(画面やコード)」を作る作業は、進捗が出ているように感じるため安心できます。これを Cognitive Closure(認知的完結)への欲求 とも呼びます。
2. ハンマーを持つ人(Law of the Instrument)
「ハンマーを持つ人には、すべてが釘に見える」という格言通り、特定の技術(AI、ブロックチェーン、React Nativeなど)を使いたいという動機が先行すると、無理やりそれを適用できる問題を探し始めます(Solution looking for a problem)。
具体例:ドリルと穴、そしてエレベーター
ケース1:ドリルと穴(セオドア・レビット)
- 解決空間 : 「毎分3000回転する最高性能のドリルが欲しい」
- 問題空間 : 「壁に直径5mmの穴を開けたい」
- もし問題空間をさらに掘り下げて「お気に入りのポスターを飾りたい」だとしたら?
- 解決策は「ドリル」ではなく「剥がせるテープ」や「強力磁石」になるかもしれません。
ケース2:遅いエレベーター
- 問題 : 「ホテルの客から『エレベーターが遅い』とクレームが来ている」
- 解決空間のアプローチ : モーターを交換する、アルゴリズムを最適化する。(数億円のコスト)
- 問題空間のアプローチ : 「客は『待たされている時間』にイライラしている(退屈している)」
- 真の解決策 ** : エレベーターホールに ** 鏡 を置いた。客は身だしなみをチェックすることに夢中になり、待ち時間を苦痛と感じなくなった。(数万円のコスト)
関連ツール:Opportunity Solution Tree (OST)
問題空間と解決空間を正しく接続するための強力なツールが、 オポチュニティ・ソリューション・ツリー (Opportunity Solution Tree) です。
これはテレサ・トーレス(Teresa Torres)が考案したもので、以下の4層で思考を整理します。
- Outcome (成果) : ビジネス上の目標(例:解約率を下げる)
- Opportunity (機会) : ユーザーの課題・問題空間(例:使い方がわからない、値段が高い)
- Solution (解決策) : 解決空間(例:チュートリアル動画、料金プラン改定)
- Assumption Test (検証) : その解決策が機能するかの実験
OSTを使うことで、「思いつきの機能(Solution)」が「どの課題(Opportunity)」に紐付いているのかを一目で確認でき、迷子になるのを防げます。
👉 オポチュニティ・ソリューション・ツリー (Opportunity Solution Tree) の詳細はこちら
改善のための設計原則
具体的な改善策(OK/NG比較)
Interactive Example (Live)
const OkNgComparison = () => { return ( <div className="overflow-x-auto my-8"> {/* PC view table */} <table className="w-full border-collapse border rounded-lg hidden md:table"> <thead className="bg-muted/50"> <tr className="border-b"> <th className="text-left p-4 font-bold border-r w-1/6">フェーズ</th> <th className="text-left p-4 font-bold border-r w-5/12 text-destructive">解決空間偏重(NG)</th> <th className="text-left p-4 font-bold w-5/12 text-primary">問題空間重視(OK)</th> </tr> </thead> <tbody> <tr className="border-b hover:bg-muted/10"> <td className="p-4 font-bold border-r">会議の議題</td> <td className="p-4 border-r">「このボタンの色はどうする?」「どんなアニメーションにする?」</td> <td className="p-4">「ユーザーはなぜここで迷うのか?」「そもそもこの画面は必要か?」</td> </tr> <tr className="border-b hover:bg-muted/10"> <td className="p-4 font-bold border-r">ユーザー調査</td> <td className="p-4 border-r">「この機能を使いたいですか?」(解決策の評価)</td> <td className="p-4">「普段どのように作業していますか?」(現状の課題発見)</td> </tr> <tr className="border-b hover:bg-muted/10"> <td className="p-4 font-bold border-r">失敗した時</td> <td className="p-4 border-r">「作り方が悪かった」(UI/バグのせいにする)</td> <td className="p-4">「解くべき問題が違っていた」(前提の誤りを認める)</td> </tr> </tbody> </table> {/* Mobile view */} <div className="md:hidden space-y-4"> <div className="border rounded-lg p-4"> <h4 className="font-bold mb-2 border-b pb-1">解決空間偏重(NG)</h4> <ul className="space-y-2 text-sm"> <li><span className="font-bold">会議:</span> 「このボタンの色はどうする?」</li> <li><span className="font-bold">調査:</span> 「この機能を使いたいですか?」</li> <li><span className="font-bold">失敗:</span> 「作り方が悪かった」</li> </ul> </div> <div className="border rounded-lg p-4 bg-primary/5"> <h4 className="font-bold mb-2 border-b pb-1 text-primary">問題空間重視(OK)</h4> <ul className="space-y-2 text-sm"> <li><span className="font-bold">会議:</span> 「ユーザーはなぜ迷うのか?」</li> <li><span className="font-bold">調査:</span> 「普段どう作業していますか?」</li> <li><span className="font-bold">失敗:</span> 「解くべき問題が違っていた」</li> </ul> </div> </div> </div> ); }; render(<OkNgComparison />);
UX倫理と長期価値
解決空間に偏ったプロダクトは、しばしば 「機能過多(Featuritis)」 に陥ります。 問題解決に寄与しない機能を追加することは、ユーザーの認知リソースを奪い、使いやすさを損なう行為です。
真に誠実なデザインとは、コードを書くことでも、美しい絵を描くことでもありません。 「不要なものを作らない」という決断 こそが、最大の貢献である場合も多いのです。
優れたデザイナーは、すぐに答え(UI)を出さない。 徹底的に 「問い(Problem)」 を愛し、その問いが解くに値するかを見極める者である。
まとめ
- 分離する : 「何が問題か」と「どう解決するか」を混ぜて議論しない。
- 留まる勇気 : 足りないのは技術力ではなく、不確実な問題空間に留まる精神力かもしれない。
- ハブとして使う : 迷ったら OST(Opportunity Solution Tree) を描き、現在地を確認しよう。