前回、安易に「わかったつもり」にならない誠実さについて考えた。では、実際に目の前でトラブルが起き、原因がさっぱり見えない時、私たちはどう振る舞えばいいのだろうか。
「わからない」という壁にぶつかったとき、まず大切なのは、その大きな塊をバラバラに分解することだ。一気に正解にたどり着こうとすると足がすくむが、「どこまでなら確実に言えるか」と「どこからが推測か」の境界線を引き直してみる。わかっている事実を一つひとつ机に並べていけば、正解ではないにせよ、「ここまでは潔白だ」という地図が見えてくる。
次に必要なのは、仮説という名の「アタリ」をつけることだ。確証がなくてもいい。「もしここが原因だとしたら、こういう挙動をするはずだ」と予測を立てて、実験や確認を繰り返す。たとえ予想が外れても、それは「ここが原因ではない」という立派な前進だ。何もせずに悩むのではなく、動くことで「わからない範囲」を少しずつ削り取っていく。
ここで気をつけたいのが、偶然の罠だ。何かをいじったら、たまたま現象が収まった。それを「直った」と決めつけるのが一番危ない。Ａを変えてＢが良くなったからといって、Ａが真犯人だとは限らないからだ。原因がはっきりしないなら、無理に一つに絞らなくてもいい。複数の可能性を挙げた上で、「今はまだ特定できない」と正直に記録に残すべきだ。
エンジニアにとって「わからない」状態は、決して恥ではない。むしろ、そこがスタート地点だ。無理に自分を納得させる答えをひねり出すよりも、事実を冷静に見つめ、曖昧さを曖昧なまま正しく扱う。
その粘り強さこそが、本当の意味でトラブルを乗り越え、次の現場に確かな知恵をつないでいく力になるのだと思う。
