監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
基本設計は、要件定義で決めた「何を実現するか」を、画面・帳票・機能・データといった外から見える単位に落とし込む工程です。詳細設計は、その基本設計を受けて、プログラムが動く単位まで内部の構造や処理手順を具体化します。前者を外部設計、後者を内部設計と呼ぶ現場もあります。要件とプログラミングの間をつなぐ二段構えの工程、と捉えると整理しやすいはずです。
基本設計と詳細設計は、同じ「設計」でも視点の高さが異なります。軸は「誰の目線で、どこまでを決めるか」です。基本設計は利用者やシステムの外側から見える振る舞いを決め、詳細設計は開発者がコードを書けるところまで内側を決めます。
この順序には理由があります。外側の振る舞いが固まらないまま内部を作り込むと、後から画面や機能が変わったときに詳細設計の広い範囲を書き直すことになりがちです。まず基本設計で輪郭を合意し、それから詳細設計で中身を詰める、という流れが崩れにくい進め方だと言えます。
ここでの軸は「誰が・何を・どの順で作るか」です。ウォーターフォール型の開発では、要件定義の後に基本設計、続いて詳細設計という順で進み、それぞれ成果物がレビューと承認を経て次工程に渡されます。
担当の重心も変わります。基本設計では、業務を理解したSEやリーダー格のメンバーが、ユーザー部門との対話を重ねながら書き進めます。詳細設計では、実装を担う開発メンバーが具体化を進め、設計と実装の距離を縮めていきます。PMは直接すべてを書くわけではありませんが、どの成果物がいつ揃い、誰の承認で次に進むのかという段取りを押さえておくと、工程の抜けに気づきやすくなります。
軸は「どこで手戻りが生まれやすいか」です。二つの設計は境界が曖昧になりやすく、曖昧なまま進むと後工程に負担が寄ります。
いずれも、工程の切れ目で「何を決め終えたか」を明確にしておくことで、後からの手戻りを小さくできます。
軸は「前後の工程とどう対応するか」です。基本設計と詳細設計は単独で完結せず、上流の要件と下流のテストに紐づいています。
アジャイル開発では、これらを一度にまとめて固めるのではなく、反復のなかで少しずつ設計と実装を進める形が取られます。設計という営み自体が消えるわけではなく、決める粒度やタイミングが変わると捉えると、開発手法が違っても見通しが立てやすいはずです。
基本設計と詳細設計の切り分けを理解していると、PMとして工程の段取りを組み立てやすくなります。どの成果物がどの工程で確定し、誰の承認を経て次に進むのかを把握できれば、スケジュールの節目やレビューの置き所を見通せるからです。特に、基本設計はユーザー部門との合意、詳細設計は開発チームとの技術的な詰めと、関わる相手が変わる点を押さえておくと、調整の相手を間違えにくくなります。設計工程を自分で書き切る必要はありませんが、工程の境界で「何が決まったか」を確認する姿勢は、要件定義からテストまでの流れ全体を管理するうえで土台になります。開発手法がウォーターフォールでもアジャイルでも、設計で決める内容の粒度が変わるだけだと捉えられれば、現場に応じた進め方を選びやすくなるはずです。
基本設計と詳細設計は何が違うのですか。
決める対象の視点が違います。基本設計は画面や機能、帳票など外から見える単位を固め、ユーザー部門との合意の土台になります。詳細設計はそれを受けて、プログラムの処理手順やモジュール構成など内部の作りをコードが書ける水準まで具体化します。外部設計と内部設計と呼び分ける現場もあります。
どちらを先に進めるのですか。
要件定義の後に基本設計、続いて詳細設計という順が一般的です。外側の振る舞いを先に合意し、それから内部を詰めることで、後からの作り直しを小さく抑えやすくなります。外側が固まらないまま内部を作り込むと、画面や機能の変更が内部設計の広い範囲に波及しがちです。
PMはどこを見ておけばよいですか。
自分で全部を書くより、どの成果物がいつ揃い、誰の承認で次工程に進むかという段取りを押さえるのが実務的です。特に基本設計書はユーザー部門の合意の根拠になるため、誰が何を確認したかを残しておくと、後のテスト段階での認識の食い違いに気づきやすくなります。