業務システムで見落とされがちだけど重要なこと

by tanabe on March 31, 2008

しかし、ソースコードには、さらに他の利用者がいることを忘れてはいけません。2、3ヵ月後、何かの変更を加えるために誰かがコードを読もうとするかもしれません。この利用者の存在は、軽視されがちですが、実際には最も重要なのです。コンピュータがコンパイルするのに余分な CPU サイクルがちょっとかかったからといって誰が気に留めるでしょうか。これに対して、プログラマがコードを修正するのに1週間かかったとなると、これは問題となります。コードを理解できれば、わずか1時間で済んだかもしれないのです。

プログラムを動作させようということに必死で、将来の開発者のことを考えていられないというのでは問題です。

「リファクタリング - プログラミングの体質改善テクニック」(Martin Fowler著) 第2章 リファクタリングの原則(P56)より

業務システムを長期で使っていくことを考えると、開発のコストをいかに小さく抑えるかというのは非常に重要だ。特に毎日の資金繰りに困らない程度の規模の企業であれば、初期投資のコストも大事だがメンテを 10 年続けたときに全体でいくらかかるのかという視点が大事になる。(あまりまともに試算されている例を知らないが。)

業務システムを開発するのに必要な視点は複数あるが、コンピュータサイエンスの視点よりも上位の視点(コンピュータサイエンスも含んでしまうという程度の意味であり、価値が上という意味ではない)としてこのメンテナンス可能性という視点が必要だと思う。

ひがさんが「メンテナブルなコード」という表現を使って同じような主張をしているが、「システムをメンテナンス可能にし続けておくための全体の仕組み」を作ることが重要だ。(たぶん、ひがさんはそれをフレームワークで実現できると考えているから、コードという表現になるのだと思う。こちらも参照。)

「どこで何をしているか」「ある目的のことを変えたいときはどこを変えるべきか」「ある箇所を変えた場合の影響はどの範囲に出るか」といった内容が容易に把握できるような状態を維持し続ける必要がある。そのために、ソフトウェアアーキテクチャやドキュメント(無用な誤解を避けるためにあえて設計書とも仕様書とも呼ばない)、人の採用、トレーニングプログラム、開発プロセスなどの全体の仕組みを最適化し続けていかなければならない。

それを実現するためには多くのスキルが求められる。プログラマーであることを目的とするのではなくて、プロフェッショナルであることを目的とするならそのスキルを身に付けることが必要になる。(だって、自分でやらないと誰もやってくれないのがふつうだし。)

色々なツールを知ることや使えるようになることももちろん大事だけど、どんな目的に貢献させるのかを意識しながら複数のツールを組み合わせて活用していくスキルというのはこれからもっと重要になっていくと思う。

ということで、日々の非プログラミング系の仕事のプロセスをプログラミングに模して、さらにそれをリファクタリングしようという codemaniax さんのエントリを読んでいて共感したので、最近考えていたことをメモしてみた。これも衰えない技術だよな。