詳細設計は必要です

業務アプリで詳細設計書と呼ばれるものをプログラムを作成したあとにリバースして作成しているようなことも良くみます。これは詳細設計をせずにプログラムを書いていることになります。詳細設計は意味のないことなのでしょうか?無駄な作業なのでしょうか?
個人的には詳細設計の目的には以下の2つがあり重要な作業と考えています。*1

  1. 仕様の詳細化
  2. プログラムへのマッピング

仕様の詳細化

「仕様の詳細化」は機能仕様や画面仕様をプログラム可能なレベルに具体化・詳細化することです。詳細化すべき内容も多岐にわたり、仕様間の整合性も必要になるため重要な作業になります。このような作業をしないと誤った仕様でプログラミングが量産されてしまうのではないでしょうか。

プログラムへのマッピング

「プログラムへのマッピング」はアプリケーションアーキテクチャで定義したクラスやメソッドなどの構成要素に割り付ける作業です。どのコンポーネントにどのような責務があるかを決めてアプリケーションを構造化することは、均質な構造が求められる業務アプリにとっては重要な作業になると考えています。

詳細設計の作業マップ

以下は詳細設計の作業の流れと成果物を整理したマップです。このマップを見ても詳細設計の作業が多岐にわたる事が判ると思います。

まとめ

詳細設計の主要な作業として「仕様の詳細化」と「プログラムへのマッピング」があり作業も多岐にわたります。これらの作業はあとから調整し難いものもあり、この作業を省略すると品質にも大きな影響を与えると考えています。ただ、ソースコードと1対1の擬似コードを延々と記述するような詳細設計書や仕様化レベルの一貫性がないヌケモレがある詳細設計書は多くの時間を使ったわりには得るものが少ないとも考えています。
いろいろ方法はあると思いますが、いずれにしても何を決めるのか設計ポイントをよく考えて詳細設計を行うことが重要だということですね。

追記

詳細設計と詳細設計は意図的に言葉を分けています。これは、詳細設計書というとメンテナンスが必要なドキュメント(最終成果物)のようなイメージですが、ドキュメント自体は重要だと考えていないためです*2。ただ、ドキュメントがないとコミュニケーションやレビュー時に困ることが多いので、設計作業を誘導するワークシート的(中間成果物)なもの用意するのが良いと考えています。最終的にはソースコードを詳細設計レベルのドキュメントの位置づけにします(これをcode as Documentと呼びます)

追記2

詳細設計の作業として行うかどうかは必ずしもないのですが、実装作業の脱出基準を決める作業もあります。たとえば、テストデータのパターンや性能や環境に対する条件です。カバレッジやテスト密度、コード(ピア)レビュー結果などの一般的なものはグランドルールで決めれば良いと思いますが、処理固有のものは詳細設計で考えて設定する必要があると思います。特に性能に関しては一律でないので、これがないと、1000万件のデータを想定しないといけない処理で100件ぐらいのデータでテストしてあとで性能がでないみたいな問題が発生します。

*1:ここでの詳細設計とは前工程の基本設計の成果物として機能仕様(ユースケースシナリオ)、論理DB(ER図)、画面デザイン・方式設計(アプリケーション・アーキテクチャ)をもとに、これを後工程のプログラムに変換できるようにする作業と考えています

*2:詳細設計書の維持コストが高いためにすぐにメンテナンスされなくなることも大きな理由の1つです