?設計書に書くべき範囲

投稿日:2007年04月11日 作成者:yasunaka

システム開発には「なんたら設計書」というのが多く伴います。通常のウォーターフォールによる開発では業務要件定義書に始まり、システム要件定義書、システム概要設計書、システム基本設計書、外部仕様書、テスト仕様書etc…が作られますね。

大量のドキュメントを作成しながら、実際には現場ではあまり有効活用されていないケースも見受けられます。なぜでしょうか? そういう立場のプロジェクト・メンバーになったつもりで考えてみましょう。

1.量多すぎ。頭に入りきらない。
2.実際に作るとなると参考にならないことが多い。

一番の理由はおそらくこんなところではないでしょうか? こんな理由から上流工程のドキュメントは下流工程のプログラマーが読んでいないことが多いと思いますし、それが当たり前のように思われているところもあるかもしれません。実際のところ「自分のやる範囲の仕様書だけ見てればいいや」っていうプログラマーも多いかもしれません。

でもこれってもったいないですよね。ちゃんとみんなが「使う」「使える」ドキュメントを作るべきだと思いませんか?

じゃあなぜ、量が多くなりすぎるのか。 そして実際に作るとなると参考にならないことが多いのか。 それは設計書に余計なことを書きすぎているからではないでしょうか? 設計書に一般論や誰でもわかることなど書く必要はなく、そのシステムが「他と違うこと」「特別なこと」を書くべきなのではないでしょうか? 何がエッセンス(本質)かということをきちんと捉えて、そこにフォーカスしたドキュメントであれば、それは量は少ないけど中身がとっても濃いもの、読みやすくてためになるものになると思います。

設計書を納品物として納める場合、設計書に「厚み」が要求されることも多いと思いますが、本来逆で、「お、こんなに薄くまとめられたの? すごいね!」と、紙としての薄さと内容の濃さで勝負できるように変えていくべきだと私は思います。