基本設計と詳細設計 — 2つの設計フェーズの違いと役割 - システム設計をちゃんと理解する

「設計」と一口に言っても、実務では基本設計と詳細設計という2つのフェーズに分かれます。この2つの境界が曖昧だと、基本設計で細かいことを議論しすぎたり、詳細設計でアーキテクチャの根本を覆したり、非効率な進め方になります。

この章では、それぞれのフェーズで決めること・成果物・粒度の違いを整理します。

学習者

「基本設計」と「詳細設計」って何が違うの？どっちのフェーズで何を決めるの？

基本設計（外部設計）で決めること

基本設計は「システム全体の構造と外部から見た振る舞い」を決めるフェーズです。

基本設計のアウトプットは「このシステムは全体としてこういう構造で、こう動く」という合意を取るためのものです。

詳細設計は「実装者がコードを書ける粒度まで落とし込む」フェーズです。

項目	内容
テーブル定義	カラム名・型・制約・インデックス
API詳細仕様	リクエスト/レスポンスのフィールド定義、バリデーションルール
処理フロー	主要ロジックのシーケンス図・フローチャート
エラーハンドリング	エラーコード体系、異常系の振る舞い
画面項目定義	入力フォームの項目・制約・初期値

「プログラマーがこのドキュメントだけ見てコードを書けるか」が詳細設計の粒度の目安。

成果物	粒度	例
テーブル定義書	カラム単位	`users.email VARCHAR(255) NOT NULL UNIQUE`
API仕様書	フィールド単位	リクエストボディ `{ name: string, email: string }`
シーケンス図	処理ステップ単位	注文処理: バリデーション → 在庫確認 → 決済 → 注文作成
画面項目定義書	入力項目単位	メールアドレス: 必須, 形式チェック, 255文字以内
エラーコード一覧	エラー単位	`E001: メールアドレスが既に使われています`

先生

基本設計書に「users テーブルの email カラムは VARCHAR(255)」と書く必要はない。逆に、詳細設計書に「全体のサーバー構成をどうするか」は書かない。粒度を間違えると、レビューの観点もずれるよ。

ウォーターフォール型では基本設計→詳細設計→実装と順に進みますが、アジャイルではスプリントごとに必要な分だけ設計します。

アプローチ	設計のタイミング
ウォーターフォール	実装前に基本設計・詳細設計をすべて完了する
アジャイル	スプリント0で全体のアーキテクチャ決定、各スプリントで必要な詳細設計を行う

実務では「設計書を書く時間がない」「とりあえず作ってから考える」という圧力がかかることがあります。

よくある状況	対応策
「設計書は後で書く」	後で書かれた設計書は例外なく陳腐化する。最初に書く方が早い
「コードが設計書だ」	コードは「どう実装したか」であり「なぜこの構造にしたか」は残らない
「スケジュールが厳しい」	設計を省くと実装の手戻りで余計に時間がかかる

設計書の目的は「きれいなドキュメントを作ること」ではなく「チーム内で合意を取ること」。合意に必要な粒度で書けばよい。

次の章では、詳細設計の中核となる詳細設計書の書き方を具体的に見ていきます。