正解を探すな、候補を捨てろ: エラーと大喜利に共通する問題解決の技法

「問題解決が苦手な人は、考えが足りない」のではない。むしろ、考える範囲を広げすぎているのかもしれない。

プログラムが動かないとき、初心者はコード全体を眺め続ける。会議で良いアイデアを求められたとき、人は可能性を広げようとして、結局どれも選べなくなる。ところが、熟練したデバッガーも、即興で答えを返す人も、最初から無限の可能性を扱ってはいない。観察し、候補を絞り、残った狭い空間で精度を上げている。

ここには、一見すると矛盾した問題解決の原理がある。視野を広げることが賢さだと思われがちだが、実際には、適切に視野を狭めることでしか見えないものがある。

良い問題解決とは、答えをすぐに当てることではない。答えでないものを、正しく捨て続けることである。

この考え方を、エラーメッセージの読み方と、制約のある発想術から掘り下げてみたい。両者をつなぐのは、絞り込みは思考停止ではなく、思考を見えるようにする技術だという事実である。

「分からない」は、情報が少ないのではなく多すぎる状態

プログラムが実行時に止まり、「TypeError」と表示されたとする。これは単なる失敗の通知ではない。文字列に対して数値のような操作をしている、あるいは想定していたデータ型と実際の型が違う、といった種類の不一致を示している。

同じように、「ReferenceError」は存在しない変数や関数を参照している可能性を示す。「RangeError」は許容された範囲の外側にある値を使っていることを示す。「SyntaxError」は、処理の意味以前に、書き方の規則を破っていることを知らせる。

重要なのは、エラーの名前が原因そのものではなく、原因が存在する領域を限定する地図だという点だ。エラーが出た瞬間、問題は「コードのどこかにある謎」から、「文法、参照、型、範囲のどれかに関係する現象」へと変わる。これは小さな変化に見えるが、考えるべき可能性を大幅に減らしている。

人間の会話でも同じことが起きる。誰かが「この企画はうまくいかない」と言ったとき、その言葉をそのまま受け取れば、原因は予算かもしれないし、顧客かもしれないし、実行体制かもしれない。だが、「うまくいかない」とは、売上が足りないのか、継続率が低いのか、社内の合意が取れないのかを尋ねるだけで、問題の空間は急速に狭くなる。

曖昧な問題は、難しい問題とは限らない。分類されていない問題であることが多い。

この見方をすると、最初にすべきことは答えを出すことではなく、失敗や違和感に名前を与えることになる。名前はラベルにすぎない。しかし、ラベルによって観察の焦点が定まり、初めて比較や検証が可能になる。

絞り込みは決めつけではなく、仮説を検証するための枠である

「決めつけると視野が狭くなる」という警戒は正しい。最初に原因を一つに固定してしまえば、都合の悪い証拠を無視するからだ。しかし、候補を絞ること自体が危険なのではない。危険なのは、絞った仮説を事実だと思い込むことである。

この違いは、デバッグの手順を見ると分かりやすい。まず実際にコードを動かし、エラーが再現するか確かめる。次に、正常に動いている部分をいったん切り離し、問題が起きる範囲を狭める。さらに、自分が正しいと思って確認している箇所に、本当に誤りがないかを点検する。そして、正常なケースと異常なケースを比較する。

これは、単なる作業手順ではない。仮説を小さく作り、現実にぶつけ、外れたら捨てるための循環である。

例えば、買い物リストを表示するコードでエラーが出たとする。最初から全行を読み直すのではなく、次のように問いを分解する。

1. エラーは毎回起きるのか、それとも特定の商品データでだけ起きるのか
2. 商品名の表示で止まるのか、価格の計算で止まるのか
3. 正常な商品と異常な商品のデータ型は同じか
4. 空の値、文字列として保存された数値、想定外の範囲がないか

こうしていくと、「何となく動かない」は、「価格の計算時に、一部のデータが数値ではない」という観察可能な主張に変わる。問題が小さくなったことで、初めて解決策が具体化する。

発想の場面でも、構造は同じだ。たとえば「新しい広告案を考える」という依頼は広すぎる。「十秒以内で商品の意外な使い方を伝える」「忙しい人が一目で価値を理解できる比喩を作る」と制約を置くと、候補は減る。しかし、減ったからこそ、言葉の選び方や視点の反転に集中できる。

大喜利のような短い回答も、無制限な連想ではない。お題、時間、形式、聞き手の期待という制約の中で、どの前提をずらせば意外性が生まれるかを探している。制約はアイデアを削る壁ではなく、アイデアが輪郭を持つための型なのである。

良い答えは、正しさより先に「比較可能性」を作る

問題解決が停滞する大きな理由は、候補が多いことだけではない。候補同士を比較できないことにある。

「A案も良いし、B案も良い。C案も捨てがたい」と言うとき、私たちは選択肢を持っているようで、実際には評価軸を持っていない。プログラムのバグを前にして「この辺が怪しい」と言い続けるのも同じだ。場所も条件も決まっていないため、観察が感想のまま止まっている。

そこで必要になるのが、差分を作ることである。

正常なケースと異常なケースを比べるとき、すべてが違っていてはいけない。商品名だけ、入力値だけ、実行環境だけのように、比較する変数をできるだけ一つに近づける。すると、原因候補との距離が測れる。

企画でも同じである。二つの案を比較するなら、「面白さ」だけでなく、誰に届くか、何を一番に伝えるか、実行に何日かかるかを揃えて見る。評価軸が明示されれば、好みの争いだったものが、検証できる議論になる。

この方法を、私は「候補削減の四段階」と呼びたい。

1. 現象を固定する

まず、何が起きているかを観察可能な言葉にする。「動かない」ではなく、「入力が空のとき、三行目で停止する」と書く。「企画が弱い」ではなく、「初見の人が商品の利点を説明できない」と書く。

2. 範囲を切る

次に、問題が起きていない領域を除外する。すべてを調べるのではなく、正常に動く部分を積極的に捨てる。これは怠慢ではなく、調査資源を原因候補に集中させる行為である。

3. 差分を一つずつ見る

正常と異常、採用案と不採用案、伝わった説明と伝わらなかった説明を比べる。違いが多すぎるなら、実験を小さく組み直す。

4. 仮説を捨てる

確認して外れた仮説に執着しない。自分が時間をかけた説明ほど、捨てるのが惜しくなる。しかし、仮説を捨てることは進捗である。候補が一つ減れば、残った候補の価値が上がる。

この四段階の核心は、知識量ではない。思考を比較できる単位まで加工する能力である。

失敗は、答えを与えるものではなく質問を改善するもの

エラーメッセージを読んでも、原因が一瞬で分かるとは限らない。TypeErrorを見て、すぐ修正コードを書けるとは限らない。だが、少なくとも「次に何を確認すべきか」は変わる。

ここで、エラーを結果ではなく情報として扱う視点が生まれる。エラーは「あなたは間違っている」と断罪するものではない。「この前提と実際の状態が一致していない」と教える信号である。

たとえば、年齢を数値として扱うつもりで入力欄から受け取った値が、実際には文字列だったとする。計算が失敗したとき、問題は計算式だけではない。「入力されたものは、本当に自分が想定した種類のデータなのか」という、より基本的な問いが必要になる。

人間関係や仕事でも、似た信号は頻繁に出ている。返信が遅い、会議で反対される、顧客が申し込まない。これらを「相手のやる気がない」「見る目がない」と解釈すれば、調査は終わる。だが、「相手は何を理解できていないのか」「どの条件で反応が変わるのか」と問い直せば、失敗は観察に変わる。

失敗から得られる最も valuable なものは、正解ではない。次に試すべき、より良い質問である。

問題解決の質は、最初の答えの鋭さだけで決まらない。失敗したあとに、質問の粒度をどれだけ改善できるかで決まる。

すぐに使える「絞り込み」の実践法

日常の問題にこの思考を移すなら、次の五つを試してほしい。

1. 現象を一文で記録する 「うまくいかない」ではなく、「誰が、いつ、どの操作をしたとき、何が起きたか」を書く。感情や評価をいったん外すだけで、調査の出発点ができる。

2. 正常な例を一つ保存する 異常なケースだけを見ていると、何が普通なのか分からなくなる。動いた入力、伝わった説明、成功した商談を基準として残す。

3. 一度に一つだけ変える 文言、対象者、価格、順番を全部変えてしまうと、何が効いたか分からない。小さな実験に分け、差分を追跡できるようにする。

4. 仮説に反証条件を付ける 「原因は入力形式だ」と考えるなら、「形式を直しても再現したら、この仮説は外れ」と決めておく。これにより、都合の良い証拠だけを集めるのを防げる。

5. 制約を一つ追加する アイデアが出ないときは、「一文で」「初心者向けに」「十秒以内で」「反対の立場から」など、条件を置く。自由を増やすより、探索空間を小さくしたほうが発想が動き出すことがある。

結論: 賢さとは、広く考え続けることではない

私たちは、視野が広い人を賢いと思う。もちろん、早すぎる決めつけは危険だ。だが、可能性を無限に保持し続けることも、別の形の思考停止である。候補が多すぎれば、何も比較できず、何も試せず、何も捨てられない。

本当に強い人は、最初から正解を知っているのではない。現象を正確に見て、問題を分類し、正常な例との差分を取り、外れた仮説を惜しみなく手放す。そして、必要な範囲まで世界を狭めたところで、初めて大胆な発想を使う。

大喜利の一言も、デバッグの一行の修正も、同じ能力から生まれる。無限の可能性から、いま扱える候補だけを選び、制約の中で意外な組み合わせを見つける能力だ。

だから次に問題に出会ったら、「もっと考えなければ」と焦る前に、こう尋ねてみよう。

何を知れば、候補を一つ捨てられるだろうか。

その問いを持てた瞬間、問題はまだ解決していなくても、すでに小さくなり始めている。そして、見えなかった世界は、広げた先ではなく、正しく絞り込んだ先に現れる。