これって開発者がデバッグするときのプロセスの例えというか、デバッギング作業がどういうものか一般の人になんとなくだけど理解してもらえる助けになるかもしれないと思った。それから、こういう思考の訓練は、「プログラミング的思考」の一部とみなしていいのか分からないけど、少なくとも「ソフトウェア開発活動をしている時に頻繁に動員するべき思考方法」だということは、開発者の方には賛同いただけると思います。
バグの原因が分からないときは大抵「これだったらこうなるはずなのに、そうじゃなくて、こんなことになっちゃってる・・・なんで？！」って状況で、「そうなっちゃう可能性としては・・・」みたいにいろいろ考える。まさに「蒸発した」とか「虫がのんだ」とか、そういう仮説を立てる。そしてその仮説ひとつひとつを確かめていく。とても地味な作業です（映画のハッカーがキーボードをパタパタやって、画面にコードがズラーっと表示されるイメージがあるけど、あんなのただの演出。）
よくあるのが、ごく単純な、根本的な前提が成り立っていなかったってケース。「いやそれは絶対確認しなくても大偉丈夫ってぐらい自信ある仮説」が、念の為、確認してみるとそうでなかった、みたいなことって本当によくあります。電化製品で言うところの「コンセントが入ってなかった！」みたいなの。あるはずのデータを、プログラムがいくら探しても無くて、データが削除されたのかもしれないと、いろいろと過去のデータを確認したりして、でも見つからない。ふと、そのプログラムに別のユーザーとしてログインしてたからデータが消えてように見えてただけでした、とか。そういうオチのバグっていっぱいあります。
あと最近あったのが、とあるURLで表示される画面が期待しているものじゃない。URLにいろいろとパラメータがあるんだけど、そのうちのひとつはappId=123 でした（大文字のIに着目！）。どうしてもうまくいかなくて、詳しい人にちょっと聞いてみたら「iを小文字にしてみて」って言われて appid=123 にしたらうまくいきました（これはAPIの仕様が相当ひどいですけどね）。「虫がのんだ」の発想が出来る子は、もしかしたら地力でこの答えにたどり着いたかもしれません。
どんなに「当たり前」だったり「バカバカしい」仮説だとしても、いったんは「いや、絶対ないとは言えないよな」というスタンスで仮説の中に入れる方がいいし、そういう発想が出来る人と一緒に仕事をすべきだし、そういう発想が出来る人材を育てるべきだと思う。
