問題発見の手順と仕事の上での教育について

先のエントリ、プログラマーの問題解決能力 - novtan別館に頂いたトラックバック(久々だなー)先のエントリーを読んで。

逆からたどると、修正が最小限で済むのです。計算過程を最後からたどっていきますから、ミスを見つけた場合には、そのミスより後ろを修正するだけですみます。また、修正箇所より後ろはミスがないことが保証されますから、どこにミスがあるのか迷うことなく、一つずつミスを解消できます。

http://jyunkailog.blog.fc2.com/blog-entry-25.html

そうなんだよね。問題点がはっきりしているときの最速解決手段は、速やかに間違った箇所を修正する、なのはもちろんそう。目星が完全に付いているのであれば、その周辺を目を皿のようにするのが一番早いでしょう。
でも、目星がつかないから困っているわけで、そのための手順というか順序と言うのは逆からたどる、というのが一番確実(見逃しが少ない)わけですよね。

例えば、プログラムの出力がおかしい。ここで「なんか出力がおかしいんですけど」って言われて萎えることがよくあります。どうおかしいのか。項目が期待するように出ていないのか、文字化けしているのか、行が足りないのか、そもそも出力されていないのか。まずスタートはここです。問題を把握することとは、今何が起きているかを把握することから始まります。
で、何がおかしいかがわかったら(そもそもそれがわからなかったら問題にはならないわけで)、今度はそれがなぜ起こったかを調べるわけです。まず、初めに考えるのは、ロジックが間違っているか、データが間違っているか。逆からと考えると、出力のロジックを調べるのが先決でしょう。
そこですべきなのは、ロジックの正しさを考えることではなく、デバッガなどを使い、出力直前の値がどうなっているかを見ます。それがおかしいのは多分自明なのですがまず見ます。で、おかしかったらじゃあ、その値を設定しているひとつ前のロジックで正しく値を渡せているかを調べます。それがおかしくなければ、そこのロジックがおかしいし、そうでなければその前のロジックで既におかしいです。という具合に、確実にちゃくちゃくと一歩一歩調べていくことが肝心。
いや、まずデータが正しいかを見ようよ、という流儀もあると思います。少なくとも、入力としてのデータが想定通りかどうか、想定通りにデータが取得できているか、ということを最初に調べるというのは価値があると思います。順方向に一歩一歩進んでいくことも方法論としてはありということですよね。ここで大事なのは、順方向でも逆方向でもいいから一度方向を決めたら途中で向きをかえたり飛ばしたりしないということです。

こういう地道な作業は、自分の中に「失敗パターン」を蓄積していく非常に良い機会です。そしてプログラムのミスは、そういうパターンに分類されうるものの出現頻度が高いものです。なので、失敗パターンを多く体験することで、段々「これはこのパターンではないか」という仮説の精度が上がっていくわけですね。こうなってくると、調査は端からではなく、経験に基づいたショートカットが可能になっていきます。いわゆる「勘が良くなる」というやつです。これが非常に大事なのです。

わからないことは覚えてなくても調べられればいいや、というのがここ最近の風潮のひとつにあると思います。僕も、調べ方を知っておくことはとても大事だし、それによって覚えてなくても済むことはたくさんあるな、と思っています。でも、肝心な時にリファレンスを引いて調べるということはありますが、たいていのことはやはり記憶の中から引き出しています。じゃないと、有機的に知識が連携してくれません。連携しない知識など人間にとってはなんの役にも立たないものです。学習するとはそういうことだろうし、仕事の上で教育する、というのは知識をただ提示するのではなく、役に立つ形で定着させるということなんだろうと思います。なので、実践経験を積ませるということが重要になってくる。

じゃあ、机上の勉強には意味が無いかというと、そういうわけでもないと思います。知識が繋がるためにはやはり知識として蓄えられていないといけないわけで、暗記しているということが非常に大事。その時は理解できていなくても、かけらだけでもいいから覚えている、ということが後で生きてきます。なので、実践ばかりを大事にして机上の勉強を疎かにするというのもいただけないですね。

プログラムの問題を発見する、という小さなことが、お客さんのシステム、業務に問題を発見する、という大きなことに繋がっていき、その問題解決のためにいいシステムを作る、というのがSIのおもしろさなんですよね。せっかくこの業界に入ったのであれば一人でも多くの人のその面白さを伝えたいものです。