うーむ、当初は2種類の予定だったんだけど増えた。
- ソフトウェアを作るために必要なドキュメント
- ソフトウェアを作った後に、保守の手助けとなるドキュメント
- 実体として全く意味がないんだけど、納品物として要求されるドキュメント
1のドキュメントは更に、
- チーム内外の合意事項を明示したもの(要件定義書や議事録、コーディング規約など)
- 思考を纏めるために書いたもの(設計書だけじゃなくて、ホワイトボードに書いた図とか裏紙に書いたメモとかも含む)
- コミュニケーションの補助(レビューのためや「ここはこうなってるから〜」と伝えるために)
の3つになるのかな。
で、まぁ、それぞれのドキュメントを作成する目的ってのを意識すると、「どのタイミングで、どのドキュメントに、どんだけ体力を割くのか」を判断しやすくなる。
例えば、「いきなりプログラムを書き始めると訳分からんから、クラス図書いた」って感じのドキュメントがあるとしよう。で、その後、プログラミングしていく過程でクラス構成が変わったとする。そんでも、その事前に書いたクラス図をプログラムにあわせて修正する必要はない。そうしたいという何らかの動機があればしてもいいけど、「単に最新にしておかなきゃ」ってだけなら、そこに体力をかける意味がない。このドキュメントは、プログラムを書き始めるために必要であっただけで、もうその役割を終えてしまっているのだ。
一方、システムリリース後の保守を想定して記述されたドキュメントは、常にシステムの状態を正しく表したものでないとマズイだろう。その内容がプログラムとちゃんと同期していなければ、ドキュメントを見た人が誤った根拠に基づく誤った判断をすることになりかねない。ちなみに、この手のドキュメントはシステムをある程度作り終えるまでは、着手しても意味ないと思っている。
実体として全く意味のない納品ドキュメントは、本来作る意味がないものだから、どんだけ体力を割かずに済むかが勝負だと思う。