それは説明責任の問題
ソフトウェア開発者の仕事は、もちろん納期通りに要求されたソフトウェアを開発することだけど、それだけではない。成果物に対する説明責任も伴うはずだ。
- どのようなアーキテクチャ、デザインパターンを採用しているのか？
- モジュール構成、クラス構成はどうなっているのか？
- 何をどのようにテストすれば良いのか？
- 性能面、機能面でのボトルネックはどこか？
- どのような障害が発生したのか？
- 次の派生開発時に改善すべき問題は何か？
通常、これらの情報は仕様書などの資料として残したり、申し送り事項という形で整理されるはずだ。もちろん、ソースコードを読めば分かるようなことはどうでも良くて、そのコードの背景にある設計思想とか、大量のコードの中に埋もれがちな考え方、役立った開発資料などの情報の方がずっと重要な意味を持っていたりする。こんな情報こそ整理しておく価値があると思う。
しかしながら、開発が終わって一安心するのか、そんな情報は充分な形でまとまっていないことが珍しくない。しかも、大量の情報の中からエッセンスのみを抜き出して、その要点を簡潔にまとめられるだけの力を持つ人はどうしても限られてしまうようだ。自分が考えていたことをまとめるだけの事なのだから、特に難しくはないはずなのだが、メモの断片でお茶を濁してしまうケースが多いのは残念なことだ。それなりの意図があって作ったものである以上、自分の言葉で説明するのは当然のことだと思う。
最後に、わたしが新人の時に先輩から言われた言葉をご紹介させていただきます。
ググるな危険：プログラマで、生きている：エンジニアライフ
「自分で説明できないコードを1行たりとも書くな！」
間違うのはしかたありません。けれども、「自分はこう考えたからこう書いた」と説明できないコードを書いてはいけません。
