この記事の要点（UIXHERO視点）
- 解決策（Solution）に飛びつく前に、問題（Problem）に恋をしろ。
- 「何を作るか（How）」の前に「なぜ作るか（What/Why）」を定義する。
- この2つを混ぜると、誰も欲しがらない機能を完璧に作ることになる。
導入：我々は「解決策」に恋をしすぎる
「AIを使ったチャットボットを作ろう！」 「ブロックチェーンで信頼性を担保しよう！」 「モーダルウィンドウで注意を引こう！」
プロジェクトの初日、ホワイトボードはこうした「アイデア」で埋め尽くされます。 チームは高揚し、すぐに・画面設計（UI）や実装の議論が始まります。
しかし、ここで冷水を浴びせるような質問をひとつ投げかけてみてください。
「で、それは誰の、どんな問題を解決するんだっけ？」
一瞬の沈黙の後、「えっと、便利になるから…」といった曖昧な答えが返ってきたら危険信号です。 これが解決空間（Solution Space）への偏りです。
UIXHEROでは、これを単なる「手順の違い」ではなく、「思考の領域汚染」と呼びます。 問題が明確でないまま解決策を議論することは、地図を持たずに全力疾走するのと同じです。
問題空間と解決空間とは（定義）
用語データ
「何が問題か（What）」と「どう解決するか（How）」を、明確に別世界として扱う思考法
| 項目 | 内容 |
|---|---|
| 英語表記 | Problem Space / Solution Space |
| 日本語表記 | 問題空間 / 解決空間 |
| 分類 | プロダクト戦略 / デザイン思考 |
語源と背景
この概念は、『リーン・スタートアップ』（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比較）
UX倫理と長期価値
解決空間に偏ったプロダクトは、しばしば「機能過多（Featuritis）」に陥ります。 問題解決に寄与しない機能を追加することは、ユーザーの認知リソースを奪い、使いやすさを損なう行為です。
真に誠実なデザインとは、コードを書くことでも、美しい絵を描くことでもありません。 「不要なものを作らない」という決断こそが、最大の貢献である場合も多いのです。
優れたデザイナーは、すぐに答え（UI）を出さない。 徹底的に「問い（Problem）」を愛し、その問いが解くに値するかを見極める者である。
まとめ
- 分離する: 「何が問題か」と「どう解決するか」を混ぜて議論しない。
- 留まる勇気: 足りないのは技術力ではなく、不確実な問題空間に留まる精神力かもしれない。
- ハブとして使う : 迷ったら OST（Opportunity Solution Tree） を描き、現在地を確認しよう。
