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

匠Lab 代表取締役の萩本順三氏が、既存のソフトウェア開発プロセスにメスを入れる！

[萩本順三，匠Lab]

開発者の悩みその2　「設計モデルを時間かけてつくったが、実装段階で大幅に変わってしまった」

　オブジェクト指向技術を使ってしっかりと設計したつもりでいた。しかし、実際には、実装段階で大幅に設計を変えざるを得ない問題が生じてしまった。いま思えば、設計などせず、実装した方が効率的だったのではないかとさえ思っている。

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

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

（注）これは経験の浅い設計者にも同様のことがいえる。