最初の仕様変更がその後を決めることって多々あると思います。
システム設計で、最初の仕様は将来何が起きるか分からない上、そんなにコストをかけられない、もしくは主機能にコストを費やしているので、必要かどうかすら読めない拡張性なんてものに時間を費やせない場合がほとんどです。これはある意味仕方の無いことかと思います。
ですが、1発目の変更時はよーく考えた方がいいですね。そこでその先の方針、というか設計思想が固まると思って良いかと。理由は、ある程度運用上の問題や顧客要望も見えてきて、あるべき姿や拡張の可能性、方向性も見えてくる頃であることが多いからです。いわば、初期納品時には見えなかった課題が明確になる頃。良い方に向かわせるチャンスなのですが、ここできちんとした方向を示さないと、その後の追加変更は「このときこうしてるのだから、おなじようにやろう」という風になります。
もちろん、大規模なリファクタリングが容易にかけられるような、自動テストなどの環境がそろっていれば大なたを振るうこともできるでしょうが、たいていは
- 初期設計者、開発者と担当者が違う。
- 十分なドキュメントや説明も得られない。
- コストは最小限といわれる。
という状況になりますから、できるだけ、今あるものはそのままに、なるべく変えないようにしがちです。そこでどの辺まで手をいれられるか……なんですけどねぇ。ねぇ。
やはり、そこで「あるべき姿」に変えられるくらいの余力を持ちたいものです。プロジェクトとして。それには、メンテナンスしやすい体制、資料、環境などが整っている必要があります。そうなると、プロジェクト単独の話というよりも組織としての開発体制の話になってしまいますが…。難しいものです。
