詳細設計書がなくてもシステムは出来る

Protected Blog › Log in
詳細設計書も問題だけど、それ以上に成果物定義が問題 - プロマネブログ
別に建設的な話を書くつもりはないです。

詳細設計書に何を書くべきか、と考えた場合に、果たして詳細設計書フェーズでやらなければならない「設計」とは何で、その成果として何をアウトプットしたらよいかということを把握しているでしょうか。ダメなプロジェクトって大体そこのところで認識が相違していたり、「作業しかできない」レベルの要員が（人手不足やらトレーニングやらという理由で）配置されていることに起因する問題が致命的だったりします。

直近でトラブったプロジェクトはやっぱり詳細設計書がプログラム仕様書っぽくて、かつ、「なぜそうなっているのか」という観点の記述はほとんど欠落しています。それって「設計」してないですよね。

詳細設計ともなると、処理要件は固まっていて、データ項目も固まっていて、後はそれをどうシステムに落としこむかという世界になります。古い言い方で言うと、モジュール分割してモジュール間I/Fが確定するところで設計の根本は終わりで後は処理要件から業務ロジックの具体化へつなげていくだけですね。

新規システムにおいては詳細設計における「なぜ」を担当しているのが基本設計から継続している人だったりしますので、その思想は暗黙的に共有されていて（なので共有していない人のところから問題が発生しがちですが）、「なぜ」が書かれてなくてもなんとかシステムとして組み上がってしまったりします。もっと言うと、頭のなかで設計したことがそのままコードに直結するのであれば、詳細設計書なんてものなくてもシステムは出来ます。メンテしない作りっぱなしシステムを作るのであれば（そしてそのシステムが十分に小さいのであれば）、詳細設計書は不要かもしれません。

これは完全に作る側の観点でしか無いし、プロジェクトの大きさが一定を超えると、システムとしての整合性を個人の範疇を超えて必要とし始めます。詳細設計書がなくて困るのはそういう時。

だから、詳細設計書に処理そのものが書かれているものってぶっちゃけ要りません（業務要件として、例えばデータ項目に対する具体的な計算方法などが書かれている必要はある）。僕としては基本設計書に書かれている機能毎に処理の単位と条件がわかれば十分じゃないかなって思います。設計書はある程度の抽象レベルを保っていないと実装の変更にともなって変更が必要というアホな話にもなります。だから詳細設計書が変わるってのは仕様レベルが変わる（あるいは直る）ってことですよ？って思うんだけどな。

そういう意味では複雑な仕様の処理だったら条件マトリクスをきっちり作ったり、詳細項目レベルのデータ遷移のパターンをきっちり洗い出したり、という作業こそが詳細設計の主眼であって、詳細設計書はそういった資料をまとめあげるインデックスと補足みたいなものに徹するのが良いのかもしれないですね。