ドキュメント軽視の理由（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

なぜある種の開発方法論がドキュメント軽視を生むのか。時間をフェーズで区切りそれぞれの成果物を定義する。あるフェーズの終わりに納期が来る。プロジェクトのある一時点の状況を考えてみる。それは詰められた要件と漠然とした希望レベルの要件が混在する状況であろう。プロジェクトの途中で全ての話が煮詰まっているなどありえない。そして設計書の記載レベルは当然粒度の粗いほうにできるだけ合わせることになる。要するに煮詰まっている要件でも細かいレベルまでは記載しないような動機付けが働いてしまう。

ウォーターフォール型プロジェクトがドキュメント軽視を生む理由がもう一つある。それはドキュメントの納期が過ぎた後の修正作業に負のインセンティブが発生することである。成果物は納期を過ぎると一旦FIXしたものと見なされる。一般に過去の蓄積に対する変更は好まれない（前述のトラブルの定義参照）。つまりドキュメントの変更が好まれないから、詳細に設計を紙に落とすことも、まめにメンテナンスすることも結局は好まれないのである。これもまた本末転倒の類であろう。

システム構築プロジェクトが必然的にドキュメント軽視を生むとは思わない。ただし、そうしないためにはリリース直前までドキュメントの変更を励行しなければならない。それができるマネージャがいるだろうか。そんなことをしたらウォーターフォール型開発の前提が崩れるではないか。筆者はそこは崩しても問題ないと思っている。事実、マイクロソフトの開発プロジェクトはリリース直前まで設計書を更新すると「ジョエル・オン・ソフトウェア」（オーム社）にあった。正しいと思う。常に設計書を最新にしておくことは、最善の実践としか思えないではないか。

トラブルを恐れるからさまざまな本末転倒が生まれるのだ。トラブルを自然なものと受け入れ、その上でベストの対応を取ればよい。設計書の修正もその一つである。