詳細設計

詳細設計の目的は、実装の判断を設計時点に前倒しし、コーディングの段階で迷いや個人差が出にくい状態をつくることです。基本設計が「何を・どう見せるか」という外側の振る舞いを決めるのに対し、詳細設計は「その振る舞いを内部でどう実現するか」を決めます。プログラムの構造を言葉と図で先に固めておくことで、複数の開発者が並行して作業しても、つながりが破綻しにくくなります。

工程としては、要件定義、基本設計に続く位置づけです。ウォーターフォール型の開発では、詳細設計が終わってから製造（コーディング）に進み、その成果物を単体テストで検証します。設計内容が単体テストの観点表の土台になるため、詳細設計の精度が後工程の手戻り量に影響しやすい、という関係にあります。

登場人物としては、設計担当のSEやリードエンジニアが中心になり、実装担当のプログラマがレビューに加わることが多い工程です。PMは直接ドキュメントを書かない場合もありますが、設計の粒度がそろっているか、基本設計との整合が取れているかを確認する立場になります。

進め方は、基本設計で決めた機能単位を、より小さな処理の単位に分解するところから始まります。一つの機能を画面・処理・データの3つの側面から見て、それぞれを実装できる粒度まで具体化していきます。おおまかな順序は次のようになります。

• 機能の分解とモジュール定義
  基本設計の機能一覧を受け取り、内部の処理をモジュールやクラスに分けます。それぞれの責務と呼び出し関係を決めます。
• 処理ロジックの具体化
  入力の受け取り方、条件分岐、計算や変換の手順、正常系と異常系の振る舞いを、フローチャートや疑似コードで表します。
• データとインターフェースの定義
  テーブルの項目、画面と処理の間で受け渡す値、外部システムとの連携項目などを、桁数や型のレベルまで決めます。

成果物としては、詳細設計書のほか、モジュール構成図、クラス図やシーケンス図、画面項目定義、データベースの物理設計、エラーメッセージ一覧などが挙げられます。どこまでを文書化するかは開発規模や体制によって幅があり、小規模なチームでは図と補足メモに絞ることもあります。

詳細設計でよく起きる問題は、粒度のばらつきです。担当者ごとに書き込む詳しさが違うと、ある機能は疑似コードまであるのに別の機能は概要だけ、という状態になり、実装時の解釈差につながります。設計を始める前に、どこまで書くかの基準をチームで合わせておくと、この差は小さくできます。

もう一つは、基本設計との不整合です。詳細設計を進める中で「この処理は基本設計の想定では実現しにくい」と気づくことがあります。ここで設計を無断で変えてしまうと、外側の仕様と内側の作りがずれます。気づいた時点で基本設計に戻して調整し、変更の記録を残す進め方が無難です。

異常系の設計漏れも起きやすい点です。正常に動く流れは書かれていても、入力エラー、通信の失敗、データの重複といった例外時の振る舞いが曖昧なまま実装に進むと、テストや運用の段階で問題が表面化します。正常系と異常系を対にして考える習慣が、後工程の負担を軽くします。

詳細設計は、要件定義や基本設計と地続きですが、扱う視点と読み手が異なります。違いを「決めること」「読み手」「抽象度」という軸で整理すると、位置づけがつかみやすくなります。

• 要件定義との違い
  要件定義は、システムで何を実現したいかという要求を言葉にする工程で、主な読み手は発注側やユーザーです。詳細設計はその要求を満たすための内部の作りを決める工程で、読み手は主に開発者です。
• 基本設計との違い
  基本設計は外部設計とも呼ばれ、画面や帳票、機能の振る舞いなど、利用者から見える部分を決めます。詳細設計は内部設計として、その裏側の処理構造を決めます。同じ機能でも見る向きが逆になります。
• 抽象度の違い
  上流ほど抽象的で、下流に進むほど具体的になります。詳細設計は設計工程の中では最も具体に近く、次の製造工程との距離が短い位置にあります。

これらは段階を追って詳しくなる連続した流れであり、どこかが飛ぶと後工程で埋め合わせが必要になります。境界を意識しつつ、前工程との整合を保つことが求められます。

プロジェクトマネージャーは詳細設計書を自ら書かないこともありますが、この工程の理解はスケジュールと品質の管理に直結します。詳細設計の粒度がそろっているか、基本設計との整合が取れているか、異常系が抜けていないかを確認できると、実装後半での手戻りを早い段階で減らしやすくなります。レビューの場で設計の穴に気づけるかどうかが、PMとしての見立ての精度を左右します。

また、詳細設計の進み具合は開発全体の見通しを測る材料になります。設計が固まらないまま製造に入っていないか、という観点で工程を見ると、遅延の兆しを早めにつかみやすくなります。上流から下流までの工程のつながりを説明できることは、SIerやSES、社内開発など多くの現場で評価されやすい素養の一つと考えられます。

詳細設計は基本設計とどう違いますか。

基本設計は画面や帳票など利用者から見える外側の振る舞いを決める外部設計、詳細設計はその裏側の処理構造やデータの扱いを決める内部設計です。同じ機能でも、見せ方を決めるのが基本設計、実装方法を決めるのが詳細設計と整理すると分かりやすいです。

詳細設計書にはどこまで書けばよいですか。

開発者がコーディング時に大きく迷わない粒度が目安です。モジュールの責務、処理の流れ、データ項目、異常系の振る舞いまで書くことが多いです。ただし規模や体制で必要な詳しさは変わるため、着手前にチームで基準をそろえておくとばらつきを抑えられます。

アジャイル開発でも詳細設計は行いますか。

工程として独立させないことはありますが、内部構造を決める行為自体はどの進め方でも必要です。アジャイルでは設計を軽い文書や図、コードそのもので表し、反復の中で少しずつ具体化することが多いです。文書量よりも、実装の判断を共有できているかが要点になります。