分析モデルはユーザー視点でシンプルに：ソフトウェア開発の匠（2）（2/3 ページ）

　さて、これは何がいけなかったのだろうか。このような問題は、未知のドメイン（問題領域）については最初から正しい設計などできるはずがないことを理解していない場合に引き起こる。一度経験しているドメインについては、最初からじっくり設計してもうまくいくだろう。しかし、未経験なドメインについて、最初から正しい設計などできるはずがない（注）。よって、アジャイルやTDD（テストドリブンデベロップメント）的な発想が必要となる。つまり最初は動作することを目標に作成し、その後で、リファクタリングを行う方が、最適な設計というゴールに行き着けるのである。

　また、このような問題に陥る場合、設計ドキュメント過多になっていることが多い。その原因の1つに、設計者が設計中に保守ドキュメントを作ろうとすることがある。そもそも設計は、反復しながら洗練していくのだが、保守を考慮し大量のドキュメントを残してしまう。揚句の果てには、開発途中でメンテナンスができず、実装結果と異なる設計書で納品することになりかねない。開発中のドキュメントは開発に必要なものだけにとどめるようにし、保守ドキュメントは、保守に望まれている形態に合わせて作成期間を別途設けるようにするのが現実的なのである。