要件定義書が一切変更されないプロジェクト
プロジェクトの最初から最後まで要件定義書が変更されないとしたら、そのプロジェクトはいびつでなにか問題を抱えている可能性が高いだろう。
要件定義書とは顧客から見て何が行われるかを示すものである。どのような設定があり、どのように動作し、どのような見た目をしているかを記述する。逆に言うとプログラムでどのような実装がされているかの情報は必要ないと言える。
要件定義書が変更されない理由はいくつか考えられる。
1. 本来変更が入る箇所を要件定義書以外のドキュメントで管理している。
2. 最初から完璧なドキュメントが用意されているので、変更の必要がない。
2については「簡単なプロジェクトなんでしょうね」くらいしか言うことはない。
ここでは1について説明したい。
そもそも、なぜ1のような事象が起きるのだろうか。
要件定義書というのは本来顧客が作成するものである。もちろんシステムの機微に詳しいベンダーが手伝う場合もあるだろう。
原因は会社間でやり取りするドキュメントなので変更管理が難しいということにあるのではないかと思う。
一度作った要件定義を変更するのが面倒なので、要件定義は変更されないことにして次のタスクに進むといったことをしている。そのため本来変更すべきものを変更対象に出来ず1のようなことが起きるのではないだろうか。
では要件定義書じゃないならどこで変更すべきものの調整が行われているのかというと、これは詳細設計書で行われる。 詳細設計書とはSIer特有のプログラムがどのように実装されているかを示す書類である。 これには問題点がいくつかある。
- 要件定義書だけではシステムの使い方が分からず、詳細設計書まで顧客に納品しなければならない
- 顧客は使用方法だけが知りたいにも関わらず、プログラムの実装方法を見る羽目になる
- 顧客が受け入れ検証する際のノイズとなる
- 納品の際に、要件だけでなく詳細設計書の内容を満たすかどうかの証左が必要となる
- 詳細設計書ありきになってしまい、いざというときに詳細設計書をなくすことができない
詳細設計書に該当する記述は本来プログラミング中のコメントとして記述し、プログラムからの自動生成を行えることが望ましい。
結論
詳細設計書を顧客に渡してるプロジェクトは地雷。 仕事としてドキュメントを書くからには、誰が何のために読むのかを考えなければならない。
