詳細設計 しょうさいせっけい
簡単に言うとこんな感じ！
家を建てるとき「リビングを南向きにして寝室は2つ」って決めるのが基本設計なら、詳細設計は「コンセントの位置は床から30cm、ドアノブはレバー式」まで決める設計図だよ。プログラマーが「これを見れば迷わずコードが書ける」レベルまで落とし込むのが詳細設計なんだ！
詳細設計とは
詳細設計とは、システム開発の工程のひとつで、基本設計（外部設計）で決めた「何を作るか」をもとに、「どうやって作るか」を具体的に定義する作業のことです。「内部設計」とも呼ばれ、プログラマーがコードを書き始める直前の段階に位置します。
基本設計が「画面の見た目」「機能の一覧」「他システムとのつなぎ方」を決めるのに対して、詳細設計ではモジュール（部品）の分割方法・処理の流れ・データの持ち方・エラー処理の手順など、実装レベルの仕様を決めます。成果物となる「詳細設計書」は、プログラマーへの指示書であり、後のテストや保守の根拠にもなる重要なドキュメントです。
発注者や業務担当者が直接レビューすることは少ないですが、この工程の品質がそのまま開発コスト・バグの多さ・後からの改修しやすさに直結します。「詳細設計が甘かった」ことが原因で手戻りが発生するケースは非常に多く、発注側もその重要性を理解しておく必要があります。
詳細設計で決めること
| 決定事項 | 具体例 |
|---|---|
| モジュール分割 | 「ログイン処理」「認証チェック」「セッション管理」を別々の部品に分ける |
| 処理フロー | 「入力値を受け取る → バリデーション → DB検索 → 結果を返す」の順序を定義 |
| データ構造 | 変数名・型（文字列か数値か）・桁数・初期値を定義 |
| エラー処理 | 「DBに接続できない場合はエラーコードE001を返してログに記録する」 |
| 共通部品の定義 | 複数画面で使い回す部品（バリデーション関数など）の仕様 |
| パフォーマンス条件 | 「1000件のデータを3秒以内に表示する」などの性能要件の実現方法 |
覚え方：「詳細設計＝プログラマーへの指示書」
「設計書を渡したらコードが書ける」状態にするのが詳細設計のゴールです。「なんとなくこんな感じで」が残っていたら詳細設計は未完成、と覚えておきましょう。
主な成果物（ドキュメント）
- プログラム仕様書：各モジュールの入力・処理・出力を記述
- フローチャート / アクティビティ図：処理の流れを図で表現
- クラス図 / ER図：データの構造・関係を図示
- 画面遷移詳細：各ボタン押下後の内部処理まで定義
- 共通部品一覧：使い回す関数・クラスの仕様
歴史と背景
- 1960年代：大型コンピューター（メインフレーム）向け開発で設計工程の体系化が始まる。コードを書く前に仕様を固める重要性が認識される
- 1970年代：ウォーターフォールモデルが提唱され、「要件定義→基本設計→詳細設計→製造→テスト」という段階的な開発プロセスが標準化される
- 1980〜90年代：日本ではゼネコン型の多重下請け構造が定着。詳細設計書が「発注元→元請→下請け」への作業指示書として機能するようになる
- 2000年代：アジャイル開発の台頭により、「詳細設計書を先に全部作る」アプローチが見直され始める。ただし大規模・官公庁・金融系では依然として重視される
- 現在：アジャイル開発では「設計書を都度更新」「コードが仕様書」という考え方も広まっているが、外部委託・大規模システムでは詳細設計書の作成が契約上も求められることが多い
開発工程における詳細設計の位置づけ
ウォーターフォール開発における各工程と詳細設計の関係を整理します。
基本設計 vs 詳細設計の違い
| 比較項目 | 基本設計（外部設計） | 詳細設計（内部設計） |
|---|---|---|
| 視点 | ユーザー・発注者目線 | プログラマー目線 |
| 主な読み手 | 発注者・業務担当者 | 開発エンジニア |
| 決めること | 「何を」作るか | 「どうやって」作るか |
| 成果物の例 | 画面設計書・機能一覧 | プログラム仕様書・フローチャート |
| 発注者の関与 | レビュー・承認が必要 | 任意（内容確認推奨） |
発注側が押さえておくべきポイント
詳細設計は基本的に開発会社が行いますが、発注側として以下の点は把握しておく価値があります。
1. 詳細設計書は「資産」として受け取る 完成したシステムとあわせて詳細設計書を納品物に含めることを契約に明記しておきましょう。将来の改修・別会社への乗り換え時に必ず必要になります。
2. 工数の大きな割合を占める 詳細設計はシステム開発全体の工数の15〜25%を占めることもあります。「設計に時間がかかっている」と感じても、ここを削ると後のバグや手戻りが増えます。
3. 詳細設計のレビューで手戻りを防ぐ 製造（コーディング）に入る前に詳細設計書のレビュー会を設けることで、認識のずれを早期に発見できます。修正コストは後工程になるほど膨らむため、このタイミングの確認が非常に重要です。