監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
基本設計と詳細設計は、ウォーターフォール型の開発で要件定義とプログラミングの間に置かれる二つの工程です。基本設計は利用者から見える画面や帳票、データの流れといった「何を作るか」を固め、詳細設計は内部のモジュール構成や処理ロジックといった「どう作るか」を記述します。前者を外部設計、後者を内部設計と呼ぶこともあります。
要件定義で合意した「やりたいこと」を、いきなりプログラムに落とすのは無理があります。そこで、設計を利用者視点と作り手視点の二段階に分け、確認する相手と確認する内容を変えていきます。これが基本設計と詳細設計を分ける主な理由です。
この分け方には、手戻りを早い段階で抑える狙いがあります。利用者に関わる部分を基本設計で固めてから内部に進めば、実装が進んでから「画面の項目が足りない」といった大きな差し戻しが起きにくくなります。PMは、どちらの工程でどんな関係者を巻き込むかを計画段階で決めておくと進めやすくなります。
基本設計は、要件定義書で合意した内容を出発点に、システム全体の見える部分を具体化する作業です。業務の担当者やアプリケーションの設計者が中心となり、要件を一つずつ画面や処理の形に置き換えていきます。
代表的な成果物は基本設計書で、画面定義や機能説明、データ定義などをまとめた文書です。PMの役割は、この設計書を顧客やユーザー部門と読み合わせ、合意を文書として残すことです。合意が曖昧なまま次へ進むと、後の工程で判断の拠りどころを失いやすくなります。
詳細設計は、基本設計で固めた「何を作るか」を、実装できる粒度の「どう作るか」に翻訳する工程です。主な担い手は開発を担当するエンジニアで、プログラムを書く直前の設計図を用意していきます。
成果物は詳細設計書やテーブル定義書などで、これをもとに実装と単体テストが進みます。PMとしては、詳細設計のレビューが実装前の最後の手戻り防止点になるため、レビューの時間を工程に組み込んでおくことが欠かせません。
基本設計と詳細設計は地続きの工程ですが、担当者と目的が異なるため、境界のあたりで混乱が起きやすくなります。違いを軸で整理しておくと、PMとして進捗や品質を見るときに判断しやすくなります。
つまずきの多くは、工程の順序ではなく「誰と何を合意するか」の設計から生まれます。PMは、それぞれの設計書を誰がレビューするかをあらかじめ決めておくと、手戻りを抑えやすくなります。
基本設計と詳細設計の違いを押さえておくと、PMとして工程の間にあるリスクを早めに察知しやすくなります。設計工程は、要件定義で合意した内容が実装可能な形に変わっていくところで、ここで合意相手や粒度を取り違えると、後のテストや実装に手戻りが波及します。PMがこの橋渡しを管理できると、スケジュールや品質の見立てが安定します。
また、設計書を誰がレビューするかを計画段階で決める習慣は、要件定義やテスト工程の進め方にも応用できます。工程名や成果物の役割を正しく理解していることは、開発チームと発注側の双方に対する説明力につながり、上流工程を任される際の土台になります。
基本設計と詳細設計はどちらを先に行いますか。
通常は基本設計を先に行い、その内容を受けて詳細設計に進みます。基本設計で利用者から見える振る舞いやデータの流れを固め、詳細設計でそれを実装できる粒度の内部構造に落とし込む流れが一般的です。順序を飛ばすと、合意していない前提のまま実装が進むおそれがあります。
外部設計・内部設計という言葉との違いは何ですか。
外部設計は基本設計、内部設計は詳細設計とほぼ同じ意味で使われることが多い言葉です。利用者から見える外側を外部設計、作り手だけが触れる内側を内部設計と呼び分けています。現場やドキュメントの慣習で呼称が異なる場合があるため、用語の定義を関係者とそろえておくと混乱を避けられます。
PMは設計工程で具体的に何を見ればよいですか。
成果物の有無よりも、誰と何を合意したかを確認することが中心になります。基本設計では顧客やユーザー部門との合意が文書に残っているか、詳細設計では実装前のレビューが終わっているかを見ます。レビューの時間を工程に組み込んでおくと、後工程での手戻りを抑えやすくなります。