最近、若い部下がプログラムの不具合に対して原因の究明とデバッグの作業をしているのを見ていたんですけどね。ちょっとやり方がいまいちだなあ、なんて思ったりしてまして。今日はその話です。
「問題解決のために大切なこと」というのは、自分は以下の2点だと思ってます。
ひとつは「あらゆることを疑う」ということ。
問題の原因を見つけるために必要なのは「可能性を潰していく」ということです。「可能性を潰す」ということは、「問題の範囲を狭めていく」ということで。ローラー作戦のようなものですね。
その「可能性を潰していく」作業というのは「正しいに決まっていること」に対してもするべきで。「正しいに決まっていることが思い込みかも知れない」「正しいに決まってるところに原因があった」なんてことは、それなりに経験を積んでる人には「あるある話」だと思うんですよね。
「正しいに決まっていること」を確認して、それが原因になっているケースは希だけど、それでも「原因では無かったことが確認できた」という事実の裏付けって結構重要なんです。
「そのファンクションは自分がよく知ってるものだから確認を割愛しても良い」などと思わずに念のため見てみることが大事で。もしかしたらそのファンクションが自分の知っているものと微妙に違ってるかもしれないし、特定の外部パラメータを参照しているときだけ違う動きをしてるかもしれない。
若い人たちの様子を見たり会話したりしていると、その確認を怠っているが故に原因が突き止められず無為に時間を費やしている、ということが多いように思うんですよね。
もうひとつは「あらゆることに興味を持つ」ということ。
これも若い部下の様子を見ていて思ったことなんですけど、些細なことを見逃してるんですよね。「このファンクションは何となく問題なさそうだからスルー」みたいな感じで読み飛ばしてることが多いんですよね。
で、結局原因がそのファンクションの中にあったりする。原因とは言わないまでも、問題解決の重要な手がかりになる情報がその中にあったりする。
なので、「このファンクションってどういう動きをしてるんだろう？」ってのに興味を持って、その中身を追ってみるのは問題解決する上で大事だと思います。
今回のケースだとプログラムのソースコードですけど、プログラムコードに限らず、問題解決における考え方って共通するかなと思うんですよね。なので、この考え方って、自分がその分野で門外漢だとしても、ある程度であれば有効なんじゃないかなと。
…ちゃんと若手にそういうのを指導する機会を設けないとなあ、なんて思いながら今日も仕事してました。
まあ、今回の投稿は、今後若手に指導するための備忘録的な内容ですね。