はじめに：もっとも速い道がもっとも遠い道になるとき
月曜の朝、チームに一つの依頼が届きます。「検索結果ページに無限スクロールを入れてください」。
真面目なエンジニアならすぐに手が動きます。ページネーションのロジックを取り除き、スクロールイベントを付け、次のページを先読みするprefetchを実装します。三日できれいに動く無限スクロールが完成します。コードレビューも通り、デプロイも滑らかに終わります。誰もが満足そうに見えます。
ところが二週間後、同じ依頼者がまたやってきます。「ユーザーが相変わらず欲しい結果を見つけられないと言っています。無限スクロールを入れたのに」。ここでようやく本当の対話が始まります。実は問題は「スクロールが不便だ」ではなく「検索精度が低い」だったのです。ユーザーはページをめくるのが面倒だったのではなく、10ページめくっても欲しい項目が出てこなくて諦めていたのでした。無限スクロールは、悪い結果をより速く、より多く見せる装置にすぎませんでした。
三日がまるごと消えました。正確に言えば、三日のあいだ非常に効率よく**間違った問題を解いた**のです。
この記事は「もっと頑張れ」という話ではありません。むしろ逆です。仕事を始める前に少し立ち止まり、「いま解いているものは、本当に解くべき問題なのか?」を確認する、おそらく費用対効果がもっとも大きい習慣についての話です。答えを上手に出す力はありふれています。問題を上手に選ぶ力は稀です。そしてほとんどの場合、後者のほうが重要です。
1. 間違った問題を解くことの本当のコスト
私たちはふつう「遅く働くこと」を無駄だと考えます。しかし実際にもっとも高くつく無駄は「速く間違った答えにたどり着くこと」です。なぜなら間違った答えは、それが間違っていたという事実をずっと後になってから教えてくれるからです。
無駄の構造を広げてみるとこうなります。
間違った問題を選ぶ
│
▼
設計 / 実装（時間の投入）
│
▼
デプロイ / リリース
│
▼
「なぜ効かないのか?」（遅れてやってくる気づき）
│
▼
原因分析 / ロールバック / 作り直し
│
▼
本当の問題を定義し直す（出発点へ逆戻り）
この流れでもっとも恐ろしいのは「遅れてやってくる気づき」です。間違って解いた問題は、すぐに赤信号を出しません。コードはちゃんと動き、機能は問題なく動作します。ただ誰も望まなかったものを上手に作っただけです。その事実が表に出るまで、数日、ときには数か月かかります。
これに加えて二つの隠れたコストがついてきます。
第一に、**サンクコストの罠**です。すでに三日を費やした無限スクロールを前に「実はこれが問題ではありませんでした」とは言いにくい。だから多くのチームが間違った解決策の上にさらに別の機能を積み、問題を大きくしてしまいます。
第二に、**信頼の浸食**です。依頼者の側には「ちゃんと頼んだものを作ってもらったのに、なぜ解決しないのか?」という疑問が積もります。やがて「このチームは仕事は速いが問題を解けない」という評判ができます。速い手がかえって信頼を削るという逆説です。
ですから問題定義に使う時間はコストではなく投資です。30分の問いが三日の作り直しを防ぐなら、それは100倍を超える利回りです。
2. 解決策ではなく問題を受け取る
ほとんどの依頼は問題としてではなく、**すでに解決策のかたちで**届きます。「無限スクロールを入れてください」「ダッシュボードにグラフを追加してください」「通知をもっと頻繁に送ってください」。これらはすべて、誰かが頭の中で一度問題を解いたうえで出してきた答えです。
依頼者が解決策を持ってくるのは自然なことです。彼らも忙しく、自分なりの文脈の中で「こうすればいいだろう」と考えたからです。問題は、その答えが彼らの持つ情報と時間の中で出てきた間に合わせの解にすぎない、という点です。その領域を毎日見ている専門家は、むしろ依頼を受ける側です。
ですから最初の動作はいつも同じです。**解決策から一段さかのぼって問題を復元すること。**
依頼者が言ったこと：「無限スクロールを入れて」 ← 解決策
│ （一段さかのぼる）
▼
実際の不便： 「欲しい結果が見つからない」 ← 症状
│ （もう一段）
▼
本当の問題： 「検索精度が低い」 ← 問題
│ （もう一段）
▼
根底のニーズ： 「速く正確な情報にたどり着きたい」← ニーズ
このさかのぼりを飛ばすと、私たちは他人の頭の中の解を代わりに実装する人になります。さかのぼれば、私たちはより良い答えを一緒に探す人になります。その違いは、作業の結果だけでなく、仕事における私たちの立ち位置を変えます。
3. 5 Whys：症状から原因へ
問題をさかのぼるもっとも単純で強力な道具は、トヨタ生産方式に由来する5 Whysです。やり方は名前のとおり。「なぜ?」を五回ほど繰り返して、表面の症状から根本原因まで掘り下げます。五という数字は規則ではなく目安です。たいてい五回ほど問うと、もう制御できない領域（市場、天候、人間の本性）に届くか、実際に手を打てる原因にたどり着きます。
実際の事例で解いてみましょう。あるSaaSチームに「新規登録数が減っている」という問題が上がってきました。
問題：今月の新規登録が前月比20%減少した。
なぜ登録が減ったのか?
→ 登録ページ訪問者のうち登録を完了する割合（コンバージョン率）が下がった。
なぜコンバージョンが下がったのか?
→ 登録フォームの最終ステップで離脱する人が増えた。
なぜ最終ステップで離脱するのか?
→ そのステップで「会社の決済情報」を先に入力するよう求めている。
なぜ決済情報を先に求めるのか?
→ 先月、無料体験の悪用を防ぐためカード登録を前段に移した。
なぜカード登録を前段に移したのか?
→ 悪用対策を「登録ステップの強化」だけで考え、
他の防御手段（メール認証、利用量制限）を検討しなかった。
根本原因：悪用を防ぐ方法として「登録の摩擦を増やすこと」を選び、
その副作用で正常なユーザーまで一緒にブロックしている。
最初に受け取った問題は「登録が減った」でした。もしここで止まっていたら、広告をもっと出したり登録ボタンを大きくしたりして対応したでしょう。すべて無駄骨です。5 Whysを経てみると、本当の問題は「悪用対策が正常なユーザーをブロックしている」という、まったく別の問題でした。解決策も変わります。カード登録を後ろに回し、メール認証と利用量ベースの制限で悪用を防げばよいのです。
5 Whysを使うときの注意点がいくつかあります。
- **人ではなくシステムに向ける。**「誰がやったのか?」ではなく「なぜそれが起こりえたのか?」を問うべきです。犯人探しに流れると、人は防御的になり、本当の原因は隠れます。
- **一本筋だけで掘らない。**ある問題は原因が複数に枝分かれします。必要なら「なぜ?」から枝を出して複数の経路をたどってください。
- **証拠で確認する。**「なぜ?」の答えが推測なら、それはまた別の仮説にすぎません。可能ならログ、データ、ユーザーインタビューで各段階を検証してください。
4. リフレーミング：同じ状況を別の問題に
5 Whysが「下へ掘る」道具なら、リフレーミングは「横へひねる」道具です。同じ状況をまったく別の問題として言い直すことです。
トーマス・ウェデル＝ウェデルスボルグが挙げた有名な例があります。あるビルの入居者たちが「エレベーターが遅すぎる」と絶えず不平を言います。エンジニアの本能は明確です。モーターを交換するか、アルゴリズムを改善するか、新しいエレベーターを設置するか。すべて高くつき、時間もかかります。
ところがビルの管理者は問題を別の言い方で述べました。「エレベーターが遅い」ではなく**「待ち時間が退屈だ」**。こう問題を変えると解決策がまったく変わります。エレベーターの横に鏡を取り付けます。人々は鏡の前で自分の姿を見たり、他人をそっと観察したりして、待ち時間を感じにくくなります。不平は消えます。ほぼタダで。
リフレーミングの核心は「この問題を別の言い方で述べたらどうなるか?」という問いです。いくつかの実践的な角度があります。
元の言い方： 「エレベーターが遅い」
─────────────────────────────────────
別の主体で： 「管理室が不平対応に追われている」
別の感情で： 「待ち時間が退屈だ」
逆に： 「そもそも人が待つという事実をどう減らすか」
範囲を広げる：「このビルの動線そのものが非効率だ」
範囲を狭める：「出勤時間の8〜9時だけ待ちが長い」
それぞれの言い方が、異なる解決策の扉を開きます。「遅い」は土木工事を、「退屈だ」は鏡を、「8〜9時だけ」は時差出勤や一台をその時間帯専用に回す運用変更を呼びます。よい問題定義者は、答えを探す前に言い方を複数作ってみます。
リフレーミングを日常に取り入れる小さな習慣はこうです。問題を一文で書いたあと、**その文の中心となる名詞や動詞を一つずつ入れ替えてみる**ことです。「ユーザーが機能を見つけられない」の「見つける」を「必要とする」に変えると、「ユーザーはその機能を本当に必要としているのか?」という、より根本的な問いが開きます。
5. インバージョン：逆から考える
チャーリー・マンガーが好んで引用する思考法がインバージョン（逆転）です。「どうすれば成功するか?」を問う代わりに「どうすれば確実に失敗するか?」を問います。失敗の条件を並べてそれらを避けると、しばしば正攻法より鮮明な道が見えます。
問題定義にインバージョンを当てはめるとこうなります。
順方向の問い：「どうすればオンボーディングを改善できるか?」
→ 漠然としている。何でも答えになりうる。
逆方向の問い：「どうすれば新規ユーザーを確実に離脱させられるか?」
→ 登録直後に空白の画面だけを見せる
→ 最初のステップから難しい設定を強いる
→ 何をすべきか案内しない
→ 最初の成功体験までを長くかからせる
この一覧を裏返すと = やるべきことの一覧になる。
→ 登録直後に意味のある最初の画面を見せる
→ 設定を最小化するか後回しにする
→ 次の行動を明確に案内する
→ 最初の成功体験を素早く作る
インバージョンが強力なのは、人は「何を足すか」より「何が台無しにするか」のほうをはるかに具体的に思い浮かべるからです。漠然とした改善課題を渡されたとき、少し方向を裏返して「これを確実に台無しにする方法」を書いてみると、意外と手につかめる行動の一覧が出てきます。
6. 本当のニーズを見つける方法：解決策の下にある欲求
問題をさかのぼっていくと、やがて**根底のニーズ（underlying need）**にたどり着きます。人が依頼するものと、本当に望むものは、しばしば違います。よく引かれるたとえのように、人はドリルを買いたいのではなく壁に穴を開けたいのであり、さらに深くは壁に絵を掛けたいのです。
ニーズを掘り出すときにもっとも多い罠は、「何が欲しいですか?」と直接尋ねることです。人は自分のニーズをよく知らなかったり、知っていると錯覚したり、すでに解決策の言葉で答えたりします。だから未来の仮定を尋ねる代わりに、**過去の事実を尋ねる**べきです。これがロブ・フィッツパトリックの「The Mom Test（ママ・テスト）」が与える核心の教訓です。母親に事業のアイデアを尋ねれば嘘（善意のお世辞）を聞きますが、母親の実際の行動を尋ねれば真実を聞きます。
よいニーズ発掘の問いと、悪い問いを比べてみましょう。
| 悪い問い（解決策/仮定を尋ねる） | よい問い（事実/行動を尋ねる） |
| --- | --- |
| この機能があれば使いますか? | 最後にこの作業をしたとき、どうしましたか? |
| 通知がもっと多いとよいですか? | いまはこれをどう管理していますか? |
| いくらなら買いますか? | 似た道具にいまいくら使っていますか? |
| これ、よいアイデアだと思いませんか? | この問題で最後に困ったのはいつですか? |
| ダッシュボードは必要ですか? | その数字を確認するためにいまどんな手順を踏みますか? |
左の問いはすべて未来の意見や仮定を尋ねます。人は礼儀として「はい、よさそうですね」と答え、私たちはそのお世辞を根拠に間違ったものを作ります。右の問いはすでに起きた具体的な行動を尋ねます。行動は嘘をつきません。「先週その数字を確認するために三つのスプレッドシートを開いて手で合算した」という答えは、どんな「ダッシュボードいいですね」よりも本当のニーズを正確に教えてくれます。
7. XY問題：解決策に閉じ込められた問い
ニーズを見つけられない典型的なパターンに名前がついています。XY問題です。本当の問題Xがあるのに、自分なりに思いついた解決策Yに行き詰まり、Yについてだけ質問してしまう状況です。
技術サポートのチャネルで毎日起きる対話で見てみましょう。
質問者：ファイル名から最後の三文字だけ取り除くにはどうしますか?
回答者：その三文字を取り除いて何をしようとしているのですか?
質問者：ファイルの拡張子を変えようとしています。
回答者：ああ…拡張子はいつも三文字とは限りません（.jpeg、.html）。
本当にやりたいのは「拡張子を変える」ことですね。それはこうします…
質問者はX（「拡張子を変えたい」）を解こうとして、自分でY（「最後の三文字を取り除く」）という解決策を思いつき、そのYに行き詰まってYについてだけ問いました。回答者がYだけ解いていたら、質問者は「.jpeg」のようなファイルで静かに壊れるコードを手にしていたでしょう。
XY問題を破る問いはいつも一つです。**「それで結局、何をしようとしているのですか?」**または**「一段上で、本当に解こうとしている問題は何ですか?」**この問いは相手を自分の解決策の井戸から引き上げ、元の問題へ連れ戻します。私たちが問われる側のときも、問う側のときも、つねに投げる価値があります。
8. よい問いの構造
問題を上手に定義することは、結局のところ上手に問うことです。問いにも構造があります。
8.1 オープン型 vs クローズド型
クローズド型の問いは、はい/いいえや決まった選択肢の一つで答えさせます。オープン型の問いは、相手に自分の言葉で語らせます。どちらも役に立ちますが、**問題を探索する段階ではオープン型が、決定を絞る段階ではクローズド型が**適しています。
| クローズド型（絞る、確認する） | オープン型（広げる、探索する） |
| --- | --- |
| この機能、使いにくかったですか? | この機能を使ったとき、どんな体験でしたか? |
| 締め切りは金曜で合っていますか? | この日程でもっとも心配な点は何ですか? |
| A案とB案、どちらがよいですか? | この決定でもっとも重要な基準は何ですか? |
探索段階でクローズド型の問いばかり投げると、私たちはすでに思いついた選択肢の中でしか答えを聞けません。肝心の選択肢の外にあった本当の問題は、ついに表に出ません。だから序盤は「どうやって」「何を」「なぜ」「どんな場合に」のようなオープン型の語頭で始まる問いを、意識的に多く投げるべきです。
8.2 仮定をあぶり出す問い
すべての問題の言い方には隠れた仮定が敷かれています。よい問いはその仮定を水面の上へ引き上げます。
依頼：「決済ページの読み込みが遅いので直さなければなりません」
隠れた仮定をあぶり出す問い：
- 遅いとは具体的に何秒のことですか?（定量化）
- すべてのユーザーに遅いのですか、特定の条件だけですか?（範囲）
- 遅くて実際にどんなことが起きていますか?（影響）
- 読み込み速度が本当の問題ですか、それとも離脱が本当の問題ですか?（再定義）
- いま直すのが適切な理由はありますか?（優先順位）
「遅い」という一語の中には「どれくらい」「誰に」「だから何が問題なのか」という三つの仮定が圧縮されています。この仮定を広げないと、私たちは測られていない目標に向かって働くことになります。何が「十分に速い」のか合意されないままに。
8.3 問いにも礼儀がある
問いはともすると問い詰めのように聞こえます。同じ問いも口調によって協力にも、抵抗にも聞こえます。核心は**問いの前に意図を先に明かすこと**です。
抵抗に聞こえる問い：
「これ、いまどうしてもやらなきゃダメですか?」
協力に聞こえる問い：
「これで達成したい目標が分かれば、もっとも合った方法を提案できそうです。
この作業はどんなより大きな目標とつながっていますか?」
「なぜ?」は問い詰める言葉ではなく、「もっとうまく助けるために文脈をください」という合図であるべきです。意図を先に敷けば、同じ問いが防御ではなく協業への招待になります。
9. 仮説を立てて検証する
問題を定義したからといって、それが正しい保証はありません。問題定義そのものも一つの仮説です。だからよい問題定義は、検証可能なかたちで書かれるべきです。
検証可能な仮説は、おおよそこんな枠に従います。
[誰]が[どんな状況で][何のために][どんな困難]を抱えていると
私たちは信じる。これが事実なら、[観察可能な兆候]が見えるはずだ。
私たちは[方法]でこれを確認する。
検索の事例に当てはめるとこうなります。
私たちはこう信じる：
検索を使うユーザーが、結果の精度が低いために、欲しい項目を
見つけられず離脱している。
事実ならこんな兆候が見えるはずだ：
- 検索後の最初の3件のクリック率が低い
- 同じキーワードで何度も再検索する
- クリックなしで終わる検索セッションの割合が高い
こう確認する：
- 検索ログで上記の指標を測定する
- ユーザー5人に実際の検索過程を観察する
こう書いておくと二つの利点があります。第一に、問題が間違っているときに早く分かります。兆候が見えなければ仮説が間違っているので、三日を使う前に方向を変えます。第二に、後で「この問題をなぜ解くことにしたのか」の根拠が文書として残ります。直感ではなく検証された判断になります。
小さく検証できるなら、いつでも小さく検証するほうがよいです。全体を作ってリリースしてから市場で確認するより、プロトタイプ一つやユーザーインタビュー五件で先に確認するほうがはるかに安く済みます。
10. 制約と範囲を明確にする
問題を定義しても、境界が曖昧だと仕事は際限なく広がります。「検索を改善しよう」は一か月かかることも、一年かかることもあります。だから問題には必ず制約と範囲をつけるべきです。
三つを明示的に書いてください。
範囲内（In scope）：
- キーワード検索結果のランキングアルゴリズム改善
- 誤字補正
範囲外（Out of scope）：
- 音声検索
- レコメンドシステムの全面刷新
- 検索UIのリデザイン
制約（Constraints）：
- 2週間以内に最初の改善をデプロイ
- 既存の検索インフラ内で解決（新しい検索エンジン導入不可）
- 応答時間を200ミリ秒以内に維持
「範囲外」を明示することは、「範囲内」を定めることと同じくらい重要です。何をやらないかを合意しないと、よい意図を持った誰かが新しい要求を入れ続け、問題を膨らませます。いわゆるスコープクリープです。制約は窮屈な柵ではなく、終わらせてくれるトラックです。ベースキャンプのShape Upが言う「固定された時間、変動する範囲（fixed time, variable scope）」も同じ精神です。時間を固定しておけば、私たちはその中で何が本当に重要かを強制的に選り分けることになります。
11. ステークホルダーの整合：全員が同じ問題を見ているか
同じ問題でも、人によって頭の中の絵は違います。営業は「大口の顧客が検索がいまいちだと言う」を、デザイナーは「検索UIが古い」を、エンジニアは「検索インデックスが遅い」を思い浮かべます。三人とも「検索の問題」を口にしていますが、実は三つの異なる問題を語っています。
問題定義の段階でこの違いをあぶり出さないと、後で成果物をめぐって衝突します。だから一文の合意された問題の言い方を作ることが重要です。これを一行で書き、関係する人全員に「これが私たちの解こうとしている問題で合っていますか?」と確認してもらってください。
合意された問題の言い方（一文）：
「エンタープライズのユーザーが、よく使うキーワードで検索したとき、
欲しい結果が上位3件の中に出てこず、手動で資料を探し直す
非効率を抱えている。」
確認の問い：
- 営業：「大口の顧客が言ったのはこれで合っていますか?」
- デザイン：「UIの問題ではなく精度の問題と見てよいですか?」
- エンジニア：「この範囲なら2週間以内に最初の改善が可能ですか?」
この一文が合意されると、その後のすべての議論が短くなります。誰かが新しいアイデアを持ってきても、「それがこの問題の言い方に合っていますか?」という一つのものさしで素早くふるい分けられます。整合は会議の時間を延ばす手続きではなく、後の作り直しと対立を減らす投資です。
12. 具体的な事例：要求を裏返す
問題の再定義が実際にどう仕事を変えるか、一つの事例を最後まで追ってみましょう。
営業チームから依頼が来ます。「顧客ごとにレポートをPDFで書き出すボタンを追加してください。顧客がしきりにPDFを求めています」。
性急なチームはすぐにPDF生成機能を作ります。フォントが崩れ、表がページをまたぎ、チャートの解像度が合わないなど、PDFレンダリングのあらゆる落とし穴に三日を費やします。ところが問題をさかのぼってみます。
依頼： 「PDF書き出しボタン」 ← 解決策
│ なぜPDFが必要なのか?
▼
症状： 「顧客がレポートをPDFで欲しがる」
│ なぜPDFの形を望むのか?
▼
理由： 「顧客が社内の役員にそのレポートを共有しなければならない」
│ 役員に共有するときPDFでなければならないのか?
▼
本当の問題：「顧客が私たちのデータを自分の組織の中で
簡単に共有できない」
│ では共有をもっともよく助ける方法は?
▼
ニーズ：「信頼できる形で、受け取る人が別途ログインなしに
見られるように共有したい」
本当の問題が「共有」だと分かると、解決策の選択肢が広がります。PDFはそのうちの一つにすぎません。
可能な解決策（本当の問題 = 「簡単な共有」）：
- ログインなしで見られる共有リンク（読み取り専用）
- メールでレポートの要約を自動送信
- PDF書き出し（元の依頼）
- 役員向けの一ページ要約ビュー
ここで興味深いのは、共有リンクがPDFより作りやすいことがあり、同時につねに最新のデータを見せるというより大きな価値を与える点です（PDFは作った瞬間から古くなり始めます）。もちろんセキュリティ上、外部の共有リンクが使えない顧客もいるでしょうから、最終的な答えは一つとは限りません。核心は、「PDFボタン」という依頼をそのまま受け取っていたら絶対に浮かばなかった選択肢が、問題を一段さかのぼったとたんにすべてテーブルの上に乗った、という点です。
13. アンチパターン：避けるべき落とし穴
問題定義を台無しにする典型的なパターンがあります。知っておけば、自分自身がその落とし穴に落ちる瞬間に気づけます。
**解決策から提示する。**もっとも多く、もっとも高くつく落とし穴です。問題を聞いた途端に「ああ、それはXでやればいいですよ」と答えが飛び出します。頭の回転が速い合図のように感じますが、実は問題を十分に理解する前に、自分の経験の中の慣れた答えへ跳んだのです。答えが浮かぶのは止められませんが、その答えを口に出す前に「ところで本当の問題は何だったかな?」と一度問い直す習慣が、違いを生みます。
**問題を測らない。**「遅い」「不便だ」「いまいちだ」のような形容詞だけで問題を書くと、解けたのかどうか永遠に分かりません。「3秒が1秒に減れば解決」のように測定可能なかたちで書いてこそ、終わりがあります。
**一人の声を全体だと勘違いする。**「顧客がPDFを望む」の「顧客」が実は一人かもしれません。一人の強い依頼と、多数の静かなニーズを区別できないと、少数のために多数の資源を使います。
**症状を繰り返し消す。**同じ問題がしきりに別の姿で戻ってくるなら、私たちは根本原因ではなく症状だけを消しています。5 Whysが必要な瞬間です。
**問題定義に無限にとどまる。**逆方向の落とし穴もあります。分析だけを際限なく続けて何も始めない、分析麻痺です。問題定義の目的は完璧な理解ではなく、「いま一歩を踏み出してもよいくらいの十分な理解」です。検証可能な仮説を立て、もっとも大きな仮定を確認したなら、その次は小さく動きながら学ぶ段階です。
バランスが重要です。問題定義は仕事を先延ばしにする言い訳ではなく、仕事をきちんと始めるための準備です。
14. 実践チェックリスト
依頼を受けたとき、仕事を始める前に次を素早く点検してみてください。ささいな、あるいは明白な仕事なら、すべてを通す必要はありません。しかし時間がかかる仕事ほど、この一覧の価値は大きくなります。
[ 問題の復元 ]
- この依頼は解決策か、問題か?
- 解決策なら、一段さかのぼった本当の問題は何か?
- 「それで結局、何をしようとしているのか?」を問うたか?（XY問題の確認）
[ 根本原因 ]
- 5 Whysで症状の下を掘ってみたか?
- 各「なぜ?」の答えは推測か、証拠か?
- 問題を別の言い方で述べてみたか?（リフレーミング）
[ ニーズと検証 ]
- ユーザーの「意見」ではなく「行動/事実」を問うたか?
- 問題定義を検証可能な仮説として書いたか?
- もっとも大きな仮定を一つ、安く確認する方法があるか?
[ 範囲と制約 ]
- 何が範囲内で、何が範囲外か?
- 時間/技術/資源の制約を書いたか?
- 成功の測定基準は何か?
[ 整合 ]
- 一文の合意された問題の言い方があるか?
- 関係する人々が同じ問題を見ているか?
[ バランス ]
- 分析麻痺に陥らず、一歩を踏み出せるくらい理解したか?
おわりに：答えを上手に出す人から、問題を上手に選ぶ人へ
答えを出す力は、ますますありふれてきています。道具は速くなり、情報はあふれ、何でも素早く作れる時代です。だから逆説的に、より貴重になった力は「何を作るかを選ぶ力」、すなわち問題を定義する力です。
この記事で扱った道具は大げさではありません。「なぜ?」を五回問うこと、同じ状況を別の文で書いてみること、逆さに裏返してみること、意見の代わりに行動を問うこと、一文で合意すること。すべて30分あればできることです。しかしその30分が三日を、ときには一四半期を救います。
覚えておくことは単純です。仕事を始める前に少し立ち止まって問うてください。**「いま解いているものは、本当に解くべき問題ですか?」**この問いを礼儀正しく、しかし欠かさず投げられるなら、あなたは言われた仕事を処理する人を越えて、何をするかを一緒に決める人になります。そしてほとんどすべての組織で、その違いがやがて信頼と影響力を生みます。
よい答えを急ぐ前に、よい問題を先に選んでください。答えより問題が重要です。
参考資料
- Thomas Wedell-Wedellsborg, "Are You Solving the Right Problems?" — Harvard Business Review (hbr.org/2017/01/are-you-solving-the-right-problems)
- Thomas Wedell-Wedellsborg, *What's Your Problem?*（問題の再構成/リフレーミングに関する書籍）
- 「5 Whys」技法の概要 — Wikipedia (en.wikipedia.org/wiki/Five_whys)
- Lean Enterprise Institute (lean.org) — トヨタ生産方式と根本原因分析
- Rob Fitzpatrick, *The Mom Test* (momtestbook.com) — 本当のニーズを掘る問いの立て方
- XY問題の説明 (xyproblem.info)
- Will Larson, lethain.com — 戦略・文章・エンジニアリングの意思決定に関する記事
- Basecamp, *Shape Up* (basecamp.com/shapeup) — 問題を形づくり、範囲を固定する方法
- Richard Feynman / 第一原理思考（first principles）に関する一般的な資料
현재 단락 (1/245)
月曜の朝、チームに一つの依頼が届きます。「検索結果ページに無限スクロールを入れてください」。