はじめに
「基本設計と詳細設計の違いがよくわからない」「システム開発プロジェクトで、どの工程で何を決めるべきか判断できない」──DX推進やシステム開発に関わるビジネスパーソンから、こうした声が頻繁に聞かれます。
基本設計と詳細設計は、システム開発における重要な工程ですが、その違いや役割を正確に理解している人は意外と少ないのが現状です。これらの違いを理解せずにプロジェクトを進めると、要件の認識齟齬、開発の手戻り、予算超過といった問題が発生しやすくなります。
本記事では、基本設計と詳細設計の違いを、定義・役割・成果物・工程の観点から体系的に解説します。外部設計・内部設計との関係や、実装工程との繋がりも含めて、システム開発全体の流れの中で各設計工程がどのように位置づけられるかを明確にします。
この記事を読むことで、システム開発プロジェクトにおける意思決定の精度が高まり、クライアントやエンジニアとの円滑なコミュニケーションが可能になります。
基本設計と詳細設計の基本的な違い
それぞれの定義と位置づけ
基本設計（外部設計）: 基本設計は、システムが「何をするか」を定義する工程です。ユーザーから見た機能や画面、操作の流れなど、システムの外部仕様を決定します。別名「外部設計」とも呼ばれ、ユーザー視点での設計が中心となります。
この工程では、クライアントや業務担当者が理解できる言葉で、システムの全体像と機能を定義します。技術的な実装方法ではなく、「どのような機能が必要か」「ユーザーはどう操作するか」といった要件を明確にすることが目的です。
詳細設計（内部設計）: 詳細設計は、システムを「どのように作るか」を定義する工程です。基本設計で決定した機能を、実際にどのようなプログラミング構造で実現するかを具体化します。別名「内部設計」とも呼ばれ、エンジニア視点での設計が中心です。
この工程では、データベースの構造、プログラムのモジュール分割、処理のアルゴリズム、使用する技術など、実装に必要な技術的詳細を決定します。エンジニアがこの設計書をもとに、実際のプログラミング作業（実装工程）を進められるレベルまで詳細化します。
システム開発工程における位置づけ
システム開発は一般的に以下の工程で進行します。
- 要件定義：何を作るかを決める
- 基本設計（外部設計）：システムの外部仕様を決める
- 詳細設計（内部設計）：実装方法を決める
- 実装（プログラミング）：実際にコードを書く
- テスト：動作を確認する
- リリース・運用：本番稼働と保守
基本設計は要件定義と詳細設計の橋渡しをする工程であり、詳細設計は設計と実装の橋渡しをする工程です。それぞれが明確な役割を持ち、段階的にシステムの具体性を高めていきます。
基本設計と詳細設計の違いを比較表で理解
主要な違いの一覧
| 比較項目 | 基本設計（外部設計） | 詳細設計（内部設計） |
|---|---|---|
| 視点 | ユーザー視点、クライアント視点 | エンジニア視点、システム内部視点 |
| 目的 | 何をするかを定義 | どう作るかを定義 |
| 対象者 | クライアント、業務担当者、PM | 開発エンジニア、プログラマー |
| 抽象度 | 比較的抽象的・概念的 | 具体的・技術的 |
| 主な内容 | 画面設計、機能仕様、操作フロー | プログラム構造、DB設計、アルゴリズム |
| 成果物 | 画面設計書、機能仕様書、業務フロー図 | モジュール設計書、DB定義書、処理フロー図 |
| 技術要素 | 最小限（概念レベル） | 詳細（技術選定、コーディング規約） |
| 変更影響 | 大きい（要件変更に直結） | 限定的（実装方法の変更） |
この表から分かるように、基本設計と詳細設計は、視点・目的・対象者が明確に異なります。
役割の違い
基本設計の役割:
- ユーザー要件をシステム仕様に翻訳する
- システムの全体像を可視化し、関係者間で認識を統一する
- クライアントが意思決定できる材料を提供する
- 詳細設計・実装工程の指針となる仕様を定義する
詳細設計の役割:
- 基本設計を技術的に実現可能な形に落とし込む
- エンジニアが実装できるレベルまで具体化する
- プログラミングの効率性、保守性を考慮した構造を設計する
- 実装工程での迷いや手戻りを最小化する
基本設計は「ビジネス要件を満たすシステムの姿」を、詳細設計は「それを実現する技術的な方法」を定義します。
基本設計（外部設計）の詳細内容
基本設計の主な成果物
基本設計工程では、以下のような設計書を作成します。
画面設計書: ユーザーが操作する画面のレイアウト、表示項目、ボタンの配置、画面遷移を定義します。ワイヤーフレームやモックアップを使い、視覚的に分かりやすく表現します。
機能仕様書: システムが提供する機能の詳細を記述します。各機能の目的、入力項目、処理内容、出力結果、制約条件などを明確にします。
業務フロー図: システムを使った業務の流れを図示します。誰が、どのタイミングで、どの機能を使うかを可視化し、業務プロセス全体を俯瞰できるようにします。
データフロー図（概念レベル）: システム内でデータがどのように流れるかを概念的に示します。詳細なデータベース設計ではなく、主要なデータの流れを理解するためのものです。
インターフェース設計書: 外部システムとの連携方法、データのやり取りの仕様を定義します。API仕様の概要などもここで決定します。
基本設計で定義する内容の範囲
基本設計では、以下の内容を定義します。
機能要件
- システムが持つべき機能のリスト
- 各機能の概要と目的
- ユーザーが実行できる操作
非機能要件
- 性能要件（処理速度、同時アクセス数）
- セキュリティ要件（認証、権限管理）
- 可用性（稼働時間、バックアップ）
ユーザーインターフェース
- 画面構成とデザインの方向性
- 操作性・使いやすさの方針
- アクセシビリティへの配慮
基本設計では「実装方法」には踏み込まず、「何が必要か」に焦点を当てます。技術的な詳細は詳細設計で決定するため、基本設計の段階ではプログラミング言語やフレームワークの選定は行いません。
詳細設計（内部設計）の詳細内容
詳細設計の主な成果物
詳細設計工程では、実装に直結する技術的な設計書を作成します。
プログラム設計書（モジュール設計書）: システムを構成するプログラムの構造を定義します。どのようなクラスや関数を作成するか、それらがどう連携するかを詳細に記述します。
データベース設計書: テーブル構造、カラムのデータ型、主キー・外部キーの定義、インデックスの設定など、データベースの物理的な設計を行います。正規化の手順も含めて詳細に定義します。
処理フロー図（詳細レベル）: 各機能の処理手順を、実装レベルで詳細に図示します。条件分岐、ループ処理、エラーハンドリングなど、プログラミングの論理構造を明確にします。
インターフェース詳細設計書: APIの詳細仕様、リクエスト・レスポンスのデータ構造、エラーコードの定義など、システム間連携の技術的詳細を記述します。
テストケース設計書: 単体テストで確認すべき項目、テストデータ、期待される結果を定義します。実装と並行してテスト設計を進めることで、品質を確保します。
詳細設計で定義する内容の範囲
詳細設計では、エンジニアが実装を開始できるレベルまで詳細化します。
プログラム構造
- クラス設計、関数設計
- モジュール分割の方針
- 使用するデザインパターン
- コーディング規約
データ構造
- データベースのテーブル定義
- データ型、桁数、制約条件
- インデックスの設定方針
- データの正規化
アルゴリズム
- 処理の具体的な手順
- 計算ロジック
- 例外処理の方法
- パフォーマンス最適化の手法
技術選定
- 使用するプログラミング言語、フレームワーク
- ライブラリの選定
- 開発環境の構築手順
詳細設計では、エンジニアが「この設計書があれば実装できる」というレベルまで具体化することが目標です。
基本設計と詳細設計の実務上の違い
関与する人材と役割分担
基本設計に関与する人材
- プロジェクトマネージャー（PM）：全体の進行管理と意思決定
- システムエンジニア（SE）：設計の主担当
- クライアント/業務担当者：要件の確認とレビュー
- UIデザイナー：画面設計の支援
基本設計では、ビジネス要件を理解し、ユーザー視点で考えられる人材が中心となります。
詳細設計に関与する人材
- システムエンジニア（SE）：技術的な設計の主担当
- プログラマー/開発エンジニア：実装の視点からレビュー
- データベースエンジニア：DB設計の専門的支援
- アーキテクト：システム全体のアーキテクチャ設計
詳細設計では、技術的な知識が豊富なエンジニアが中心となり、実装の効率性・保守性を考慮した設計を行います。
変更による影響範囲の違い
基本設計の変更: 基本設計の変更は、システムの根幹に関わるため影響が大きくなります。機能の追加・削除、画面構成の大幅な変更などは、詳細設計・実装・テストすべてに影響し、工数とコストが大幅に増加します。
そのため、基本設計の段階で、クライアントと徹底的にレビューを行い、仕様を固めることが重要です。
詳細設計の変更: 詳細設計の変更は、実装方法の変更であるため、影響範囲は比較的限定的です。例えば、データベースのインデックス構造の変更や、プログラムのモジュール分割の見直しなどは、システムの外部仕様には影響しません。
ただし、詳細設計の段階でも変更は最小限に抑えるべきであり、基本設計との整合性を常に確認する必要があります。
工数と期間の目安
システム開発プロジェクト全体を100とした場合の一般的な工数配分は以下の通りです。
- 要件定義：10〜15%
- 基本設計：15〜20%
- 詳細設計：20〜25%
- 実装：30〜40%
- テスト：15〜20%
基本設計と詳細設計を合わせると、プロジェクト全体の35〜45%を占めます。設計工程にしっかりと時間を割くことが、後工程での手戻りを防ぎ、プロジェクト全体の成功につながります。
システム開発成功のための設計工程のポイント
基本設計を成功させるコツ
クライアントとの密なコミュニケーション: 基本設計は、クライアントの要望を正確に理解し、システム仕様に落とし込む工程です。定期的なレビューミーティングを設定し、認識のズレを早期に発見・修正します。
プロトタイプの活用: 画面のモックアップやプロトタイプを作成し、実際の操作イメージをクライアントと共有します。視覚的に確認することで、仕様の齟齬を防げます。
成果物の可読性: 基本設計書は、技術者でないクライアントも理解できる平易な言葉で記述します。専門用語は最小限にし、図表を多用して直感的に理解できるよう工夫します。
詳細設計を成功させるコツ
実装を見据えた設計: 詳細設計では、実装するエンジニアの視点を常に意識します。実装が難しい設計や、保守性の低い構造は避け、実現可能性とメンテナンス性を重視します。
設計レビューの実施: 複数のエンジニアで詳細設計をレビューし、論理的な矛盾や効率の悪い設計を洗い出します。早期に問題を発見することで、実装工程での手戻りを防げます。
設計書の詳細度の調整: 詳細設計は「詳細すぎても冗長」であり、「簡潔すぎても不十分」です。実装するエンジニアのスキルレベルに応じて、適切な詳細度を調整します。
基本設計と詳細設計の連携
基本設計と詳細設計の間で、情報の断絶が起きないよう注意が必要です。
トレーサビリティの確保: 基本設計の各機能仕様が、詳細設計のどのモジュールで実現されるかを明確にします。要件から設計、実装まで、一貫した追跡可能性（トレーサビリティ）を確保することで、変更時の影響範囲を正確に把握できます。
設計レビューの段階的実施: 基本設計完了時、詳細設計完了時、それぞれでレビューを実施します。各工程の完成度を確認してから次工程に進むことで、品質を段階的に高めます。
アジャイル開発における設計: 近年増えているアジャイル開発では、基本設計と詳細設計を厳密に分けず、反復（イテレーション）ごとに設計と実装を繰り返すケースもあります。しかし、どちらの視点（ユーザー視点か技術視点か）で議論しているかを意識することは、開発手法を問わず重要です。
まとめ：設計工程の理解がプロジェクト成功の鍵
基本設計と詳細設計は、システム開発において明確に異なる役割を持つ工程です。基本設計は「何をするか」をユーザー視点で定義し、詳細設計は「どう作るか」をエンジニア視点で具体化します。
この違いを正確に理解することで、プロジェクトの各工程で適切な意思決定ができ、開発の手戻りやコスト超過を防げます。DX推進やシステム開発に関わるビジネスパーソンにとって、設計工程の理解は不可欠なスキルです。
今日から実践できるアクションステップ:
- 現在進行中のプロジェクトで設計工程を確認する：基本設計と詳細設計が明確に分離されているか確認
- 設計書のレビューに参加する：各設計書の内容と成果物を実際に確認
- クライアントとエンジニアの橋渡し役を意識する：両者の視点の違いを理解し、コミュニケーションを円滑化
- 設計工程のチェックリストを作成する：各工程で確認すべき項目を標準化
- 過去のプロジェクトを振り返る：設計工程での問題点を分析し、改善策を立案
システム開発プロジェクトの品質は、設計工程の完成度で決まります。基本設計と詳細設計の違いを理解し、各工程に適切な時間とリソースを投入することで、プロジェクトの成功確率は大幅に高まります。
DXプロジェクトやシステム開発の推進、設計工程の品質向上について、より専門的なサポートが必要な場合は、お気軽にご相談ください。あなたの組織のシステム開発を、実践的なノウハウで全力支援します。
