システム開発の詳細設計書/内部設計書に書くべき内容・レベル
「細かく書きすぎるとコード書くのと変わんなくなっちゃうし…」
「ざっくり過ぎると足りないし…」
通常の開発工程は、
- 要件定義
- 基本設計(外部設計とも言う)
- 詳細設計(内部設計とも言う)
- 実装
- テスト
と続きますよね。
この中でも詳細設計は軽視されがちで、きちんと設計を終えずに実装工程に入ってプログラミングを始めることも多いかと思います。
そうなってしまうのには理由があります。詳細設計書はプログラムを実装するのが誰かによって、書き方を変えるべきものだからです。
そんなわけで今回は「詳細設計に書くべき内容・レベル」を紹介します。
そもそも詳細設計書って必要?
「いらないんじゃ…?」と思ってる方も多いかと思います。
実際、詳細設計書を作らないプロジェクトもたくさんあります。
趣味でコードを書く時も詳細設計書なんて書きませんよね。
なので、詳細設計書がなくたって、プログラムを作れます。
ですが、詳細設計書が必要なケースがあります。
設計者と実装者が違う場合は、しっかり書くべき
設計をする人と、プログラムを実装する人が違う場合は、詳細設計書がしっかりと書かれていないと、プログラムが書けません。
その結果、何度も仕様確認のやりとりが生まれます。
あるいは、あいまいに書かれている箇所を間違った解釈をして実装してしまうかもしれません。
ですから、作業分担をスムーズに行うためにしっかりと詳細設計書を書く必要があります。
設計と実装を同じ人がやる場合は、書かなくても良い
仕様が頭の中にあるので、詳細設計書を書かなくてもプログラムが書けます。
とはいえ、仕様を再確認する意味で簡易的な粗い設計書を書くのは良いことです。
設計書を書いているうちに、想定が間違っていたことに気が付くことがありますからね。
書き方のレベルは合わせるべき?
作業効率から考えると上記で述べたように、設計と実装を同じ人が行う場合は詳細設計書は粗く書いて、別の人が行う場合はしっかりと詳細に書くのが良いわけですが、そうすると、プログラムによって書き方のレベルが異なってしまいます。
大抵のプロジェクトは、設計書のレベルを合わせます。粗いレベルに合わせてしまうと、設計と実装者が違うモジュールの作業がうまくいかないので、細かく書くレベルに合わせることになります。
すると不必要にしっかりと設計書を書く工数が増えてしまいます。体裁にこだわるプロジェクトの場合はそうなりがちです。
なので、ベストなのは、納品物としての詳細設計書は書かないことにして、作業分担用のメモとして設計者が実装者へ詳細設計書を渡すというのがいいのではないかと思います。