人についたノウハウを組織に残す
システム開発を行うと、それに参画した人々は色々な技術やノウハウを身に付けることができます。システムの仕様書には基本的なことしか書かれていなくても、システム設計書には詳細なフローチャートやパラメータが記載されます。システムを作ることは設計書があればできます。
問題は、システムが完成すると設計書と試験成績書は残りますが、システムアーキテクチャをどう決めたのか？パラメータの範囲はどう決めたのか？といった設計根拠が開発に携わった人々の頭の中にしか残らないことです。人についたノウハウを組織に残すため、忙しく時間がないのは分かりますが、設計根拠資料を残しましょう！
システムの無理な拡張を回避するため
設計根拠が分からないと、後からシステムに手を入れて拡張する際に、どこまでが現行システムの延長で可能で、どこから以上は新システムに移行すべきかということが分かりません。よくあることは、システム拡張をした結果、思わぬバグがでて、そのバグを修正しようとしたら次々に修正が入ることになり二進も三進もいかなくなることです。システムの無理な拡張を回避するためにも設計根拠資料を残しましょう！
システムの性能問題の限界を明確化するため
システムの性能は、最初に開発したシステムに大きく依存します。単位時間当たりのジョブの処理量は最初のシステム設計時にはもちろんマージンを持って設計します。システムが使われだすと、当然のことながら処理量は増加し、ある負荷以上になると動作が不安定になる、システムが挙動不審な動きをすることがおきる場合があります。性能問題はその限界が見えにくいものなので、システムの性能問題の限界を明確化するためにも設計根拠資料を残しましょう！
