なぜ「問題を解く」前に「問題を疑う」べきなのか
多くの問題解決が失敗するのは、解き方が間違っているからではない。 解くべき問題そのもの を間違えているからだ。
アルバート・アインシュタインは「もし私が問題を解くために1時間与えられたなら、55分を問題の定義に使い、5分を解決に使うだろう」と述べたとされる。この言葉が示すのは、問題を正確に定義することの重要性だ。
日常のビジネスシーンでは、目の前に現れた「 症状 」をそのまま「 問題 」として扱い、対処療法的に解決しようとするケースが後を絶たない。売上が下がった→広告を増やそう。社員が辞めた→給料を上げよう。クレームが増えた→マニュアルを改訂しよう。しかし、これらの対処は根本原因に届いていない可能性がある。
以下の25の問いは、表層的な症状から一歩踏み込み、本質的な問題にたどり着くために設計されている。
問題を定義する問い（1-8）
- 今「問題」だと思っていることは、本当に問題なのか？ それとも症状にすぎないのか？
頭痛は病気ではなく症状だ。鎮痛剤で頭痛を抑えても、原因が脳腫瘍なら解決にならない。同様に、ビジネスの「問題」として認識されているものも、多くの場合はより深い構造的問題の症状にすぎない。
- この問題を最初に「問題だ」と定義したのは誰か？ その人の視点にバイアスはないか？
問題の定義は、 定義者の立場や利害 に影響される。営業部が「価格が高すぎる」と言い、開発部が「機能が足りない」と言うとき、同じ現象を異なる角度から見ている。誰の定義を採用するかで、解決策の方向性がまったく変わる。
- この問題が存在しなかったとしたら、何が起きるか？ 何も起きないなら、それは本当に問題か？
すべての問題が解決に値するわけではない 。解決しなくても大きな影響がないなら、それは優先度の低い問題だ。限られたリソースを本当に重要な問題に集中するために、この問いは不可欠だ。
- この問題は「いつから」存在しているか？ 何がきっかけで顕在化したか？
問題の時系列を追うことで、根本原因に近づける。「3か月前から売上が落ちている」なら、3か月前に何が変わったかを調べる。新製品の投入、競合の参入、組織変更、季節要因——時系列 は因果関係の手がかりを与える。
- この問題を5歳の子どもに説明するとしたら、どう言うか？
複雑に見える問題も、シンプルに言い換えることで本質が浮かび上がる。専門用語やビジネス用語を剥ぎ取ったとき、問題の核が見えてくる。「要するに、お客さんが欲しいものを作れていないってこと？」——子どもの目線は、大人が見落としている本質を突くことがある。
- この問題には、誰が、どれくらい困っているか？ その「困り度」を数値化できるか？
問題の深刻さを定量化することで、優先順位と投資判断が明確になる。「顧客が困っている」ではなく「月間3,000件の問い合わせのうち800件がこの問題に起因し、推定機会損失は月額2,400万円」と言えるかどうか。
- この問題を「制約」として受け入れた場合、別のどんな可能性が開けるか？
すべての問題が解決すべきものとは限らない。ある問題を「制約」として受け入れ、その制約の中で最適化する方が、より良い結果を生むことがある。 制約は創造性の触媒 になり得る。
- この問題が完全に解決された理想状態を、具体的に描写できるか？
ゴールが曖昧なまま解決に着手すると、どこまで行っても「解決した」と言えない。理想状態を具体的に言語化し、チーム全員で共有することが、効果的な問題解決の出発点だ。
原因を掘り下げる問い（9-16）
- 「なぜ？」を5回繰り返すと、最後に何が残るか？
トヨタ生産方式 で知られる「 5 Whys 」の手法。表層から一段ずつ深く掘り下げることで、対処療法では届かない根本原因にたどり着く。ただし、「なぜ？」の方向を間違えると的外れな結論に至るため、複数の方向で試みることが重要だ。
- この問題に関わっている「システム」の全体像はどうなっているか？ 要素と要素の間にどんな相互作用があるか？
問題を単独の要素として捉えるのではなく、システムの一部として理解する。部門間の連携、情報の流れ、インセンティブ構造——要素間の関係を図示すると、思わぬ因果関係が見えてくる。
- この問題を引き起こしている「構造」は何か？ 個人の努力では変えられない仕組みが原因ではないか？
ピーター・センゲが『 学習する組織 』で指摘したように、多くの問題は個人の能力や意欲の問題ではなく、 構造の問題 だ。評価制度、組織構造、業務プロセス——構造が行動を規定している。
- 問題の原因を「人」に求めていないか？ 「仕組み」に目を向けるとどう見えるか？
人に原因を帰属させるのは簡単だが、根本解決にはつながりにくい。同じ仕組みの中にいれば、誰でも同じ問題を起こす。個人を責める前に、 なぜその行動が合理的に見えるのか を考える。
- データは何を示しているか？ そのデータは信頼できるか？ 重要なデータが欠けていないか？
直感ではなくデータに基づいて原因を特定する。ただし、データの品質にも注意が必要だ。サンプルの偏り、測定方法の問題、見えていないデータの存在——データリテラシーが問題解決の精度を左右する。
- この問題を異なる3つの立場から見たとき、それぞれどう見えるか？
顧客の視点、現場担当者の視点、経営者の視点——同じ問題も、見る角度によってまったく異なる姿を現す。多角的な視点を意識的に取ることで、盲点を減らせる。
- 過去に似た問題を解決したことはあるか？ そのとき何がうまくいき、何がうまくいかなかったか？
歴史は繰り返す。過去の類似事例から学べることは多い。ただし、状況の違いにも注意を払い、過去の成功パターンを盲目的に適用しない判断力が求められる。
- この問題が「解決されない方が都合がいい」人がいないか？
組織の中には、問題の存在によって 権力や予算、存在意義 を確保している人がいることがある。この政治的力学に気づかなければ、表面的な合意は得られても、解決は進まない。
解決策を吟味する問い（17-22）
- 最もシンプルな解決策は何か？ 複雑にしている要因を取り除けないか？
オッカムの剃刀——同じ結果を説明できるなら、最もシンプルな仮説を選べ。解決策も同様だ。複雑な施策より、シンプルな一手の方が実行しやすく、効果も測定しやすい。
- この解決策は「問題を移動させる」だけではないか？ 別の場所に新たな問題を生まないか？
ある部門の効率化が別の部門の負荷増大を招く。コスト削減が品質低下を招く。問題を「解決」したのではなく「 移動 」させただけではないか、 全体最適 の視点で確認する。
- 何もしない、という選択肢を真剣に検討したか？
「何もしない」は消極的な選択ではなく、戦略的な判断になり得る。問題が自然消滅する可能性、介入のコストが問題のコストを上回る可能性、時間が解決する可能性——何もしない合理性を検討した上で、行動を選ぶべきだ。
- この解決策の効果を、どうやって測定するか？ いつまでに、何がどうなっていれば「解決した」と言えるか？
測定できない解決策は改善できない。成功基準と測定方法、タイムラインを事前に合意しておくことで、解決策の有効性を客観的に評価できる。
- 想定しうる最悪のシナリオは何か？ その場合のリカバリープランはあるか？
解決策が逆効果になった場合のリスクを事前に評価する。最悪のシナリオを想定しておくことで、撤退ラインと代替案を持った状態で実行に踏み切れる。
- 10倍のリソースがあったらどう解決するか？ 逆に10分の1のリソースしかなかったらどうするか？
制約を変えると思考も変わる。リソースが潤沢なら根本的な構造改革を選ぶかもしれないし、極端に少なければ最小限の介入で最大効果を狙うアイデアが生まれる。
学びを次に活かす問い（23-25）
- この問題から、組織として何を学ぶべきか？ 学びを仕組みとして定着させるには？
問題が解決したらそれで終わりではない。同類の問題が再発しないよう、学びをプロセスや仕組みに埋め込むことが、組織の成長につながる。
- この問題を「予防」することは可能だったか？ 何があれば早期に発見できたか？
消火活動よりも防火対策 の方が効率的だ。問題が発生してから対処するのではなく、問題の芽を早期に発見するセンサー機能を組織に組み込めないか考える。
- 今回の問題解決のプロセスで、最も時間を無駄にしたのはどこか？ 次回はどうすれば避けられるか？
問題解決のプロセス自体を振り返ることで、次回の問題解決がより効率的になる。 メタ認知——自分の思考プロセスを客観視する能力——が、問題解決力の継続的な向上をもたらす。
問いの使い方
25の問いすべてに答える必要はない。しかし、問い1-8（問題の定義）を飛ばしていきなり問い17-22（解決策）に飛ぶことは避けてほしい。
急いでいるとき: 問い1、5、9、17の4問だけでも、問題解決の質は大きく変わる。問題を疑い、シンプルに言い換え、根本まで掘り、最もシンプルな解を探す——この4ステップを習慣にしよう。
チームで使うとき: 各メンバーが異なる問いを担当し、それぞれの回答を持ち寄る形式が効果的だ。同じ問題でも、視点が異なれば見えるものが変わる。
答えに詰まったとき: それが最も重要な問いかもしれない。詰まった問いの周辺にこそ、見落としていた本質が潜んでいる。
