基本設計・詳細設計
作成: 2026.03.24更新: 2026.03.24
基本設計・詳細設計とは
基本設計（外部設計）は、システムの外側から見える仕様を決める工程である。詳細設計（内部設計）は、基本設計で決めた仕様をどのようにプログラムで実現するかという内部の仕組みを決める工程である。要件定義で「何を作るか」を決めた後、設計工程で「どう作るか」を具体化する。
なぜ SIer で重要か
SIer のプロジェクトでは、設計書がそのまま顧客への納品物（成果物）となることが多い。設計書の品質がシステムの品質に直結するだけでなく、設計書自体が契約上の成果物として扱われる。また、大規模プロジェクトでは設計者と実装者が異なるケースが一般的であり、設計書がコミュニケーションの手段として機能する。正確で分かりやすい設計書を書く力は、SIer の SE にとって最も基本的なスキルの一つである。
基本概念
基本設計（外部設計）
基本設計では、ユーザーやシステムの外部から見える仕様を定義する。「このシステムは外からどう見えるか、どう操作するか」を決める工程と捉えるとよい。
| 設計対象 | 内容 | 成果物 |
|---|---|---|
| 画面設計 | 画面のレイアウト、入力項目、バリデーションルール、画面遷移 | 画面一覧、画面レイアウト、画面遷移図 |
| 帳票設計 | 帳票のレイアウト、出力項目、出力条件 | 帳票一覧、帳票レイアウト |
| DB 設計 | テーブル構成、カラム定義、リレーション | ER 図、テーブル定義書 |
| IF 設計 | 外部システムとの連携方式、データフォーマット | インターフェース一覧、IF 定義書 |
| バッチ設計 | バッチ処理の一覧、実行スケジュール、入出力 | バッチ一覧、バッチフロー図 |
詳細設計（内部設計）
詳細設計では、基本設計の仕様をプログラムとしてどう実現するかを定義する。実装者が設計書を見てコーディングできるレベルまで具体化する。
| 設計対象 | 内容 | 成果物 |
|---|---|---|
| 処理フロー | 画面操作やバッチ処理の処理手順 | フローチャート、アクティビティ図 |
| クラス設計 | クラスの責務、メソッド、プロパティ | クラス図、クラス定義書 |
| シーケンス設計 | オブジェクト間のメッセージのやりとり | シーケンス図 |
| SQL 設計 | 具体的な SQL 文、インデックス設計 | SQL 定義書 |
| エラーハンドリング | 異常系の処理方針、エラーコード定義 | エラーコード一覧、例外処理方針 |
SIer での使われ方
設計書の種類と記載例
SIer のプロジェクトで一般的に作成される設計書を以下に整理する。
画面一覧
すべての画面を一覧化し、画面 ID、画面名、概要、CRUD（どのデータを参照・登録・更新・削除するか）を記載する。
| 画面 ID | 画面名 | 概要 | CRUD |
|---|---|---|---|
| SCR-001 | ログイン画面 | ユーザー認証を行う | R（ユーザーマスタ） |
| SCR-002 | ユーザー一覧画面 | ユーザーの検索・一覧表示 | R（ユーザーマスタ） |
| SCR-003 | ユーザー登録画面 | ユーザー情報の新規登録 | C（ユーザーマスタ） |
テーブル定義書
テーブルごとに、カラム名、データ型、桁数、NOT NULL 制約、デフォルト値、説明を記載する。
| カラム名 | 論理名 | データ型 | 桁数 | NULL | PK | 説明 |
|---|---|---|---|---|---|---|
| user_id | ユーザーID | VARCHAR | 20 | NO | PK | 一意のユーザー識別子 |
| user_name | ユーザー名 | VARCHAR | 100 | NO | - | 表示名 |
| メールアドレス | VARCHAR | 256 | NO | - | ログイン用メールアドレス | |
| created_at | 作成日時 | TIMESTAMP | - | NO | - | レコード作成日時 |
| updated_at | 更新日時 | TIMESTAMP | - | NO | - | レコード最終更新日時 |
設計書駆動開発の文化
SIer の現場では「設計書を書いてからコードを書く」という文化が根付いている。これは以下の理由による。
- 設計書が納品物になる --- 顧客に納品する成果物の一部として設計書が含まれる契約が多い。コードだけでなく設計書の品質も問われる。
- 設計者と実装者が分かれる --- 大規模プロジェクトでは SE が設計を行い、PG（プログラマー）が実装するという分業体制を取ることが多い。設計書が実装の指示書となる。
- 保守・運用フェーズでの参照 --- システムのリリース後、保守担当者が仕様を理解するために設計書を参照する。設計書がないとソースコードから仕様を読み解く必要があり、保守コストが増大する。
設計書作成のポイント
- 粒度を揃える --- 同じ種類の設計書内で、記述の粒度（詳しさ）にばらつきが出ないようにする。
- 用語を統一する --- プロジェクト内で用語集を作成し、同じ概念に異なる言葉を使わないようにする。例えば「ユーザー」と「利用者」が混在するとレビューの効率が下がる。
- 設計の理由を残す --- 「何を決めたか」だけでなく「なぜそう決めたか」を記録しておくと、後から見た人が経緯を理解しやすい。
- レビューで品質を担保する --- 設計書のレビューは必須。設計レビューチェックリストを用意し、観点の漏れを防ぐ。
まとめ
- 基本設計はシステムの外部仕様（画面、帳票、DB、IF 等）を、詳細設計は内部仕様（処理フロー、クラス設計等）を定義する
- SIer では設計書がそのまま顧客への納品物となるため、設計書の品質が極めて重要である
- 画面一覧、テーブル定義書、ER 図、処理フローなど、多くの種類の設計書を作成する
- 設計書は実装の指示書であると同時に、保守・運用フェーズでの仕様参照にも使われる
- 用語の統一、粒度の統一、設計理由の記録、レビューの実施が品質向上の鍵である