考えないエンジニア

プログラマー”まだまだ”現役続行 (技評SE選書)

• 作者: 柴田 芳樹
• 出版社/メーカー: 技術評論社
• 発売日: 2010/09/04
• メディア: 単行本（ソフトカバー）

この本は改訂版であり、初版は2006年9月に出版した『プログラマ－現役続行』です。しかし、初版は書き下ろしではなく、雑誌の記事を再編集したものです。その最初の記事は、「XML PRESS, Vol.2」（2000年12月）に掲載された記事「論理思考と正しい知識」です。つまり、この書籍の多くは、私が40代前半までに経験したことがベースとなっています。そして、残念ながら、この書籍で述べている昔見た光景は、今でも見かけます。その主な理由は、ソフトウェア開発は複雑な作業である上に、家内手工業だからだと思います。つまり、常に頭の中で考えたことを手を動かしてプログラミングして作り上げる作業なのです。

考えないエンジニア

　今日では、コンピュータ技術の急速な発展のおかげで、コーディングをしてからあっという間にコンパイルができ、すぐに実行可能です。プログラミング初心者の特徴として、コンパイルエラーのエラーメッセージや、実行時エラーが発生した場合のスタックトレースの表示をきちんと読まないということがあります。
　その結果、書いたコードにエラーがあると、「なぜエラーになったのか」を考えることなく、ちょっとだけソースコードを修正して、すぐにまたコンパイルと実行を行ったりする人が少なくありません。さらに、動作させてうまくいかないと、その理由をじっくりと考えることなく、またちょっとソースコードを修正して、同じサイクルを繰り返したりします。
　つまり、ソースコードやエラーメッセージをじっくりと読んで考えることなく、試行錯誤を繰り返すのです。
　このようなことを繰り返していると、自分が書いたプログラムであっても、コードを実行せずにコードの動きを頭の中でシミュレーションしながら、正しいかどうかを冷静に判断することができなくなります。そして、どのように動作するかを実行することだけで確かめようとするのです。
　このように、コンピュータ技術の急速な発展は、皮肉にも、論理的に思考あるいは推論をしないでソフトウェアを開発するエンジニアを増大させる一因となっているような気がします。

『プログラマー”まだまだ"現役続行』（p.57）

エラーメッセージをきちんと読まないとか、起きている現象（不具合）をきちんと理解しないまま、「動かなかった」としか報告できず、「それは、具体的にどういうこと？」と聞いても「動かなかった」としか説明できないようではソフトウェアエンジニアとしては失格です。実際に動作させてみると、セグメンテーションフォルトが起きていて、その旨のメッセージが表示されていたりします。

バグは自然と消えたりはしない

　ソフトウェアエンジニアにとって、論理的に思考することは重要です。
　スティーブ・マグワイアは、著書『ライティング ソリッドコード』の中で、「バグは自然と消えたりはしない」と述べています。つまり、バグ自身が勝手に修正したりすることはないのです。
　しかし、エンジニアによっては、「あのバグどうなった？」とたずねると、「新しいバージョンでは出なくなりました」と答えるだけで、「なぜ前のバージョンでは出て、新しいバージョンで出なくなったのか」を説明できなくても気にしない人がいます。
　また、いろいろと試行錯誤した結果動作するようになった場合、「なぜ動作するようになったかわからないが、動作するのでよし」とする人もいます。つまり、論理的に説明できなくても気にしない人がいるわけです。
　もちろんその反対に、「論理的に説明できないと、心のどこかに何か引っかかるものがあって落ち着かない」という人もいます。そういう人のほうが、結果的に優れたエンジニアになっていくと思います。
　そうはいっても、現実の開発ではスケジュールの関係で、「バグがなぜ消えたのか」を十分調査する時間がなく、そのまま出荷せざるを得ない場合もあるでしょう。
　しかし、その場合でも「もう出荷したから忘れてもいいや」と思うのではなく、「時間ができたときに調べよう」と思うことが重要です。そうすれば、ひょっとしたらかなり後になって、原因に思い当たったりするかもしれません。

『プログラマー”まだまだ"現役続行』（p.58）

論理的にデバッグするのではなく、単なる試行錯誤を繰り返すと、本人は「デバッグも終わり、動作も確認しました」と報告されても、その中身をよく見ると、どう考えて正しく動作しているはずがないようなコードになっている場合もあったりします。