「基本設計が終わったので詳細設計に入ります」。プロジェクトの報告でよく聞く言葉ですが、基本設計との違いがよくわからないという方も多いのではないでしょうか。
この記事では、詳細設計とは何か、基本設計との違いをわかりやすく解説します。
この記事でわかること
- 詳細設計とは何か（シンプルな定義）
- 基本設計との違い
- 詳細設計で決めること
- 詳細設計とコーディングの関係
- 非エンジニアが知っておくべきポイント
詳細設計とは？
詳細設計（内部設計とも呼ばれます）とは、基本設計で決めた「どんなシステムを作るか」を受けて、エンジニアがコードを書けるレベルまで仕様を細かく詰める工程のことです。
プログラマーが「この設計書を見れば迷わずコードが書ける」という状態を作ることが目標です。
身近な例で考えると
注文住宅の流れで考えると、
- 基本設計：「リビングはここに置く。窓は3か所」という間取り図レベル
- 詳細設計：「窓のサイズは縦120cm×横180cm。ガラスは複層ガラスで断熱仕様。位置は南から80cm」という施工仕様書レベル
詳細設計は、大工さんが「この仕様書通りに作れば完成する」という詳細な指示書です。
詳細設計で決めること
プログラムの処理フロー（フローチャート） 条件分岐（if〜then〜else）やループ処理の詳細をフローチャートや擬似コードで表現します。
データベースの詳細設計 テーブルの列名・データ型・制約（NOT NULLなど）・インデックスなど、データベースの詳細を設計します。基本設計で概要を決めたものを細かく詰めます。
APIの仕様（インターフェース設計） 外部システムやフロントエンド・バックエンド間のデータのやりとりの仕様を定義します。「どんなデータを・どんな形式で・どんな順序で送受信するか」を決めます。
エラー処理・例外処理 「このエラーが起きたときはどう処理するか」を細かく定義します。
基本設計と詳細設計の違いをまとめると
| 項目 | 基本設計（外部設計） | 詳細設計（内部設計） |
|---|---|---|
| 主な問い | どんなシステムを作るか | どうコードを書くか |
| 視点 | ユーザー・業務目線 | エンジニア目線 |
| 成果物 | 基本設計書・画面設計書 | 詳細設計書・DB定義書・API仕様書 |
| 主な関わり手 | PM・エンジニア・顧客 | エンジニア中心 |
IT現場ではどう使われるか
- 詳細設計書は、エンジニアがコードを書く際の「設計図」になる
- 複数のエンジニアが分担して開発するとき、インターフェース仕様が重要になる
- 詳細設計でバグが起きやすい部分を事前に洗い出す（設計レビュー）
- テストケース作成の元資料としても使われる
初心者がつまずきやすいポイント
「詳細設計は全部エンジニアの仕事」ではない PMも詳細設計フェーズに関わることがあります。特に「どんなエラーをユーザーに見せるか」「エラーメッセージは何語で表示するか」などの仕様は、業務側の判断が必要です。
詳細設計のレビューはエンジニア同士でも重要 詳細設計段階でバグの種が混入することは珍しくありません。設計のレビューをしっかり行うことで、開発後の手戻りを減らせます。
設計書の更新が漏れることがある 開発中に仕様変更が発生したとき、設計書の更新を忘れて「コードと設計書が一致しない」という状態になりやすいです。
関連用語
- フローチャート：処理の流れを図で表したもの
- ER図（詳細版）：データベーステーブルの詳細な関係図
- API仕様書：APIのリクエスト・レスポンスの詳細定義
- ウォーターフォール開発：要件定義→設計→開発→テストの順に進める開発手法
仕事で使うときの注意点
PMや非エンジニアが詳細設計フェーズで確認すべきは、「基本設計の内容と一致しているか」「業務上の判断が必要な仕様が漏れていないか」という点です。コードの詳細は読めなくても、業務フローとの整合性のチェックはできます。
また、「詳細設計に時間がかかっている」という報告があったとき、それは「仕様の不明確な部分を詰めている」か「想定外の複雑さが発覚した」どちらかのケースが多いです。スケジュールへの影響を確認しておきましょう。
さらに学ぶなら
設計工程の全体像を理解したい方には、FEX-119「要件定義の読み方入門」がおすすめです。家を建てる設計図というたとえで、開発の工程とドキュメントの構造をわかりやすく解説しています。
- 自分に合う講座を探す：/course-diagnosis/
- 設計・要件定義のIT基礎シリーズを見る：/courses/
- 講師クーポンを確認する：/coupons/