基本設計書と詳細設計書の違い それぞれの目的・記載内容・作成順序・品質を高めるコツを解説

「基本設計書と詳細設計書の違いを説明できない」「どこまでを基本設計に書くべきかわからない」「設計の粒度が曖昧で、後工程で認識違いが発覚した」。こうした問題は、両者の役割や記載範囲を明確に分けられていないことで起こります。

基本設計書は、システムが「何をするか」をユーザー視点で定義する文書です。一方、詳細設計書は、基本設計で定めた内容を「どのように実現するか」を開発者視点で具体化します。つまり、基本設計は画面や機能など外側の仕様、詳細設計は内部処理やデータ構造など実装方法を設計する文書です。

本記事では、それぞれの目的や記載内容、開発工程での位置づけ、違い、設計書の品質を高めるポイントまでわかりやすく解説します。

この記事でわかること

・基本設計書と詳細設計書それぞれの定義と目的の違い

・基本設計書に記載すべき内容と代表的な成果物

・詳細設計書に記載すべき内容と代表的な成果物

・開発工程における基本設計と詳細設計の位置づけと流れ

・設計書の品質を高めるための実践的なコツ

無料サービス資料

AIコンサル・AX伴走支援サービス
ご紹介資料

• 
• 
• 

少数精鋭で高利益率な「筋肉質企業」への変革を実現するための考え方や支援内容をまとめた資料です。

こんな方におすすめ

• AI導入を検討している
• 業務改善の進め方を知りたい
• 導入事例を確認したい

サービス資料をダウンロードする

基本設計書とは ─ 「システムが何をするか」を定義する

基本設計書は、要件定義の結果をもとに、システムがユーザーに対してどのような機能を提供し、画面上でどのように操作され、どのようなデータを扱うかを具体的に定義する文書です。「外部設計書」とも呼ばれ、システムの「ユーザーから見える部分」を設計することに主眼を置いた、開発プロジェクトの方向性を決定づける重要な文書です。

基本設計書の最も重要な読み手は、システムの発注者（クライアント）です。発注者は基本設計書をレビューすることで、「要件定義で伝えた内容がシステムの設計に正しく反映されているか」「完成時に自社の業務で使えるシステムになりそうか」を確認します。そのため、基本設計書は技術的な専門用語をできるだけ避け、発注者が読んで「自社の業務でこのシステムをどう使うか」をイメージできる言葉と表現で書くことが強く求められます。

基本設計書に記載する代表的な内容

基本設計書には、以下のような文書が構成要素として作成されます。

業務フロー図は、システムを使って業務がどのような流れで進むかを図で示したものです。画面設計（画面レイアウト）は、各画面にどのような要素がどの位置に配置されるかを定義します。画面遷移図は、各画面間の移動のルールを矢印で表現した図です。機能一覧は、システムが提供するすべての機能を一覧として整理したものです。帳票設計は、印刷される帳票や出力されるレポートのレイアウトと出力項目を定義します。データベースの概要設計は、システムが扱うデータの種類と、データ同士の関連性を概要レベルで定義します。

関連記事：業務効率化アイデア55選｜部門別30＋AI15＋明日から3つで成果を出す方法

詳細設計書とは ─ 「それをどのように実現するか」を定義する

詳細設計書は、基本設計書で定義された機能や画面の仕様を受け取り、それをプログラムとしてどのように実装するかを、開発者が迷いなくコーディングに着手できるレベルの粒度で具体的に記述する文書です。「内部設計書」とも呼ばれ、システムの「ユーザーから見えない裏側の仕組み」を設計することに主眼を置いています。

詳細設計書の読み手は、実際にプログラムを書く開発者（プログラマー）です。詳細設計書を読んだ開発者が、追加の情報を設計者に確認しなくても実装に着手できる状態にまで仕様が落とし込まれていることが、品質の高い詳細設計書の条件です。

詳細設計書に記載する代表的な内容

詳細設計書には、以下のような文書が構成要素として作成されます。

処理フロー（プログラム処理の流れ）は、各機能の内部で行われる処理の手順を、条件分岐やループも含めて具体的に記述したものです。データベースの物理設計は、テーブルの構造、各列のデータ型と桁数、主キーと外部キー、インデックスの設定を定義します。画面項目の詳細定義は、各入力項目のデータ型、桁数、入力チェックの条件、初期値、必須入力かどうかを一つひとつ定義します。エラー処理の定義は、入力エラー、通信エラー、データの不整合などが発生した場合のシステムの振る舞いとエラーメッセージを定義します。バッチ処理の設計は、定時に自動実行されるデータ処理の入力データ、処理手順、出力結果を定義します。

無料サービス資料

AIコンサル・AX伴走支援サービスご紹介資料

• 
• 
• 

AI導入・業務改善の進め方や支援内容、導入実績がわかる資料です。

この資料でわかること

• 社外AI役員とは
• 支援内容
• 導入の進め方
• 導入実績・効果

サービス資料をダウンロードする

基本設計書と詳細設計書の違いを5つの観点で比較する

観点1：設計の対象 ─ 外側か内側か

基本設計は、ユーザーが直接目で見て操作する画面、帳票、データの流れなど「外側」を設計する工程です。詳細設計は、それらの機能を実現するためのプログラムの処理手順、データベースの物理構造、エラー処理など「内側」を設計する工程です。

観点2：主な読み手 ─ 発注者か開発者か

基本設計書は発注者（クライアント）がレビューして「要件が正しく反映されているか」を確認するための文書であり、技術的な専門用語をできるだけ避けて書く必要があります。詳細設計書は開発者がプログラムを実装するための技術的な指針であり、データ型やアルゴリズムなど技術的に正確な記述が求められます。

観点3：記述の粒度 ─ 「何を」か「どのように」か

基本設計書は「このボタンを押したら注文が登録される」のように「何が起こるか」をユーザーの言葉で記述します。詳細設計書は「ボタン押下時に注文テーブルにデータを挿入し、在庫テーブルの数量を減算し、処理結果を画面に返す」のように「どのような処理が行われるか」を技術的な粒度で記述します。

観点4：作成の順序 ─ 基本設計が先、詳細設計が後

開発工程では、「要件定義→基本設計→詳細設計→開発→テスト」という順序で進行し、基本設計で「何を作るか」が確定した後に、詳細設計で「どう作るか」を設計するという流れが標準的です。基本設計が曖昧なまま詳細設計に入ると、「何を作るか」という前提が固まっていない状態で内部構造の設計に入ることになり、完成間際で根本的なやり直しが発生するリスクが極めて高くなります。

観点5：テストとの対応関係 ─ それぞれ対になるテストがある

基本設計書は「システムテスト（総合テスト）」の検証基準として使用され、詳細設計書は「単体テスト」および「結合テスト」の検証基準として使用されます。設計書に書かれた内容がテストケースの根拠となるため、設計書の記述が曖昧であればテストケースの設計も曖昧になり、結果としてテスト漏れや品質不良につながるという重要な因果関係があります。

開発工程における基本設計と詳細設計の位置づけ

システム開発の標準的なウォーターフォール型の工程では、「要件定義→基本設計→詳細設計→開発（プログラミング）→単体テスト→結合テスト→システムテスト→受入テスト」という順序で各工程が進行します。

基本設計は、要件定義で「何が必要か」が決まった後に、「それをシステムとしてどのような形で実現するか」を設計する工程です。発注者にとっては「完成時にどのようなシステムが出来上がるのか」をイメージするための最も重要な確認の場であり、発注者と開発チームの認識を一致させるこのレビュー工程の質が、後続のすべての工程における品質の水準を決定的に左右します。

詳細設計は、基本設計の内容が発注者の承認を得て確定した後に、「基本設計で定義された機能を、プログラムとして具体的にどう組み立てるか」を設計する工程です。開発者はこの詳細設計書をもとにプログラミングに着手するため、詳細設計書の一行一行の正確さが、開発工程での生産性とコードの品質にそのまま直結するのです。

設計書の品質を高めるための5つのコツ

コツ1：読み手を常に意識して書く

基本設計書の読み手は発注者であるため、業務用語を使い、技術用語を避けて書くことが重要です。詳細設計書の読み手は開発者であるため、技術的な専門用語を適切に使い、データ型、処理手順、条件分岐、エラー処理に至るまで、開発者がコードに直接変換できるレベルの正確性が求められます。読み手を間違えると、設計書としての役割を果たさなくなり、結果として関係者の間で認識のずれが拡大してしまいます。

コツ2：曖昧な表現を排除し、具体的な数値と条件で記述する

「適宜表示する」「必要に応じて処理する」といった曖昧な記述は、読む人によって解釈が異なり、実装のばらつきを引き起こす最大の原因です。「入力文字数が50文字を超えた場合」「登録件数が0件の場合は『該当なし』と表示する」のように、条件と動作を具体的に記述しましょう。

コツ3：正常系だけでなく異常系も漏れなく設計する

正常な操作の場合だけでなく、入力ミス、通信エラー、データの不整合、タイムアウトといった異常系の挙動まで設計しておくことが、信頼性の高いシステムを設計するための基本です。

コツ4：設計書のフォーマットをプロジェクト内で統一する

設計者ごとに書式やレイアウトが異なると、レビューや引き継ぎの際に余計な時間がかかります。プロジェクトの開始時に設計書のテンプレートを用意し、全員が同じフォーマットで書くルールを定めることで、プロジェクト全体を通じて設計書の品質と可読性のばらつきを最小限に抑え、レビューや保守の効率を大幅に向上させることができます。

コツ5：設計書のレビューを省略しない

基本設計書は発注者と開発チームの双方でレビューし、詳細設計書は開発チーム内で相互レビューを行います。レビューは設計書の品質を確保するための最も効果的な手段であり、スケジュールが厳しくても省略してはならない工程です。

関連記事：AI研修とは｜目的・種類・費用・助成金から失敗しない選び方まで

まとめ

基本設計書は「システムが何をするか」をユーザー視点で定義し、詳細設計書は「どのように実現するか」を開発者視点で定義する文書です。基本設計では画面や帳票、業務フローなどを、詳細設計では処理フローやデータベース、エラー処理などを具体化します。

開発では、基本設計を作成して発注者の承認を得た後、詳細設計へ進むのが一般的です。設計書の品質を高めるには、読み手に合わせた記述、曖昧な表現の排除、異常系の網羅、フォーマットの統一、レビューの徹底が重要です。

システム開発の設計品質を高めたい方は、要件定義から設計工程の改善、開発体制の構築、社員研修まで支援するネクストスケールへご相談ください。

AIコンサル・AX伴走支援サービスご紹介資料

• 
• 

この資料でこんなことがわかります！

• 社外AI役員とは
• 支援内容
• 導入の進め方
• 導入実績・効果

＼3ステップで簡単入力／