基本設計と詳細設計の違いとは？システム開発における役割と実践的な進め方

システム開発の現場で「基本設計と詳細設計の違いが分からない」「どこまでが基本設計の範囲なのか曖昧」といった悩みを抱えている方は少なくありません。実際、多くの開発現場では、この2つの設計工程の境界線が不明確なまま進められているケースが散見されます。

しかし、基本設計と詳細設計には明確な違いがあり、それぞれが果たすべき役割も異なります。この違いを正しく理解することで、手戻りの削減、開発効率の向上、品質の安定化といった効果を得られるでしょう。

本記事では基本設計と詳細設計の本質的な違いを解説します。さらに、それぞれの工程で作成すべき成果物、実践的な進め方、よくある誤解についても詳しく説明していきます。

基本設計と詳細設計の本質的な違い｜視点と抽象度から理解する

基本設計と詳細設計の最も重要な違いは、「誰の視点で」「どの程度の抽象度で」設計を行うかという点にあります。

ユーザー視点か、開発者視点か

基本設計はユーザー視点でシステムの振る舞いを定義します。つまり、「システムがユーザーに対してどのようなサービスを提供するか」を設計する工程です。画面のレイアウトや操作の流れ、出力される帳票の形式など、ユーザーが直接触れる部分を中心に設計を進めていきます。

一方、詳細設計は開発者視点でプログラムの内部構造を定義します。「基本設計で定めた機能をどのようなロジックで実現するか」を設計する工程であり、プログラマーが実装する際に必要となる技術的な詳細を決定していきます。

抽象度の違いが生む設計の深度

基本設計では、システム全体を俯瞰した抽象度の高い設計を行います。たとえば「顧客情報を登録する」という機能について、どのような項目を入力し、どのような確認を行い、どのようにデータを保存するかという大まかな流れを決定します。

詳細設計では、その抽象的な設計を具体的なプログラム構造に落とし込みます。入力チェックのアルゴリズム、データベースへのアクセス方法、エラー処理の詳細など、実装に必要なすべての技術的事項を定義していきます。

このように、基本設計と詳細設計は「視点」と「抽象度」という2つの軸で明確に区別されます。この違いを理解することで、各工程で何を設計すべきかが明確になり、効率的な開発が可能になるのです。

システム開発における設計工程の位置づけ｜V字モデルで理解する流れ

システム開発の全体像を理解することで、基本設計と詳細設計の位置づけがより明確になります。一般的なウォーターフォール型開発では、以下のような工程で進められます。

開発工程の全体像

要件定義：システムに求められる機能や性能を明確化
基本設計（外部設計）：ユーザー視点でシステムの振る舞いを設計
詳細設計（内部設計）：開発者視点でプログラムの構造を設計
プログラミング：設計書に基づいてコードを実装
単体テスト：個々のプログラムが正しく動作するか確認
結合テスト：複数のプログラムを組み合わせて動作確認
システムテスト：システム全体が要件を満たしているか確認
運用テスト：実際の運用環境で問題なく動作するか確認

（イメージ図：出典元：https://webrage.jp/techblog/v_shaped_mode/）

この流れを図式化したものが「V字モデル」です。左側の下降線が設計・開発工程、右側の上昇線がテスト工程を表し、各設計工程と対応するテスト工程が向かい合う形になっています。

基本設計と詳細設計の橋渡し

要件定義で決められた「何を作るか」を、基本設計では「どのように見せるか」に変換し、詳細設計では「どのように作るか」に変換します。この段階的な詳細化により、抽象的な要求から具体的なプログラムへと着実に落とし込んでいくことができます。

特に重要なのは、基本設計が要件定義とプログラミングの間を橋渡しする役割を果たしている点です。要件定義の内容をそのままプログラマーに渡しても、実装方法が不明確なため開発は進みません。基本設計と詳細設計という2段階の設計を経ることで、要件を実装可能なレベルまで具体化できるのです。

基本設計（外部設計）の成果物と実践的な作成方法

基本設計では、ユーザーから見たシステムの振る舞いを定義する各種設計書を作成します。ここでは、主要な成果物とその作成時のポイントを解説します。

機能一覧・機能仕様書

システムが提供するすべての機能を一覧化し、各機能の概要を記述します。

機能一覧・機能仕様書作成のポイントは以下の通りです。

機能IDを付与し、後工程での追跡を容易にする
機能の優先度を明記し、開発順序の判断材料とする
関連する画面や帳票との紐付けを明確にする

画面設計書・画面遷移図

ユーザーが操作する画面のレイアウトと、画面間の遷移を定義します。

画面設計書・画面遷移図作成のポイントは次の通りです。

実際の画面イメージに近いモックアップを作成する
入力項目の必須/任意、文字数制限などを明記する
エラー時の表示内容も含めて設計する
画面遷移図では、すべての遷移パターンを網羅する

帳票設計書

システムから出力される帳票のレイアウトと出力条件を定義します。

帳票設計書作成のポイントは次のとおりです。

実際の帳票サンプルを作成し、ユーザーに確認を取る
出力タイミング（日次/月次など）を明確にする
印刷時のレイアウト崩れを考慮した設計を行う

インターフェース設計書

他システムとの連携方法を定義します。

インターフェース設計書を作る際のポイントは以下の通りです。

データの送受信タイミングを明確にする
連携エラー時のリカバリ方法を定義する
データフォーマットは実例を用いて説明する

データベース論理設計（ER図・テーブル定義書）

データの論理的な構造を定義します。

データベース倫理設計については以下のポイントを参考に制作しましょう。

業務の観点から必要なエンティティを抽出する
正規化を行いつつ、パフォーマンスも考慮する
各項目の業務的な意味を明確に記述する

詳細設計（内部設計）の成果物と実践的な作成方法

詳細設計では、基本設計で定めた機能をプログラムとして実装するための技術的な設計を行います。主要な成果物とその作成方法を見ていきましょう。

プログラム構造図・クラス図

プログラムの全体構造と、各モジュール間の関係を定義します。

プログラム構造図やクラス図を作成する際は、以下のポイントを意識して設計を進めましょう。

機能の凝集度を高め、結合度を低くする設計を心がける
共通処理は別モジュールとして切り出す
将来の拡張性を考慮した構造にする

処理フロー図・アクティビティ図

各機能の処理の流れを詳細に記述します。

処理フロー図やアクティビティ図の作成では、次の要素を確実に盛り込むことが重要です。

正常系だけでなく、異常系の処理も漏れなく記述する
分岐条件は具体的な値を用いて明確にする
ループ処理の終了条件を明記する

シーケンス図

オブジェクト間のメッセージのやり取りを時系列で表現します。

シーケンス図を効果的に作成するために、以下の観点から設計内容を整理していきましょう。

画面からデータベースまでの一連の流れを記述する
非同期処理がある場合は、その旨を明記する
エラー発生時の処理も含めて記述する

データベース物理設計

論理設計を基に、実際のデータベース上での実装方法を定義します。

データベース物理設計においては、パフォーマンスと保守性のバランスを考慮しながら、次の点に注意して設計を進めましょう。

インデックスの設定を検討し、パフォーマンスを最適化する
データ型やサイズは実際の使用状況を考慮して決定する
パーティショニングなど、大量データへの対策を検討する

API仕様書

プログラム間のインターフェースを詳細に定義します。

API仕様書の作成では、利用者が迷わずに実装できるよう、以下の情報を明確に記載することが大切です。

入力パラメータと戻り値を詳細に記述する
エラーコードとその意味を一覧化する
使用例（サンプルコード）を添付する

詳細設計の成果物は、プログラマーが迷わずに実装できるレベルまで具体化することが求められます。曖昧な表現を避け、実装時の判断に迷う余地を残さないよう心がけましょう。

基本設計と詳細設計の具体的な違い｜比較表で整理する

ここまでの内容を踏まえ、基本設計と詳細設計の違いを比較表で整理してみましょう。

比較項目	基本設計（外部設計）	詳細設計（内部設計）
設計の視点	ユーザー視点（What）	開発者視点（How）
抽象度	高い（概念的）	低い（具体的）
主な関係者	ユーザー、業務担当者	プログラマー、開発者
設計の焦点	システムの振る舞い、見た目	プログラムの内部構造
成果物の例	画面設計書、帳票設計書、ER図	クラス図、シーケンス図、処理フロー
使用する表記法	日本語中心、業務用語	UML、疑似コード、技術用語
レビュー参加者	ユーザー、業務部門	開発チーム、アーキテクト
変更の影響範囲	ユーザー業務への影響大	実装方法の変更に留まる
必要なスキル	業務知識、コミュニケーション力	プログラミング知識、設計技法

この表から分かるように、基本設計と詳細設計は補完関係にあります。基本設計で「何を作るか」を明確にし、詳細設計で「どう作るか」を決定することで、要件から実装までをスムーズにつなげることができるのです。

よくある誤解と落とし穴｜現場で起きがちな問題への対処法

基本設計と詳細設計の境界線について、現場ではさまざまな誤解や問題が生じています。ここでは、よくある誤解とその対処法を解説します。

誤解1：基本設計で技術的な詳細まで決めてしまう

基本設計の段階で、データベースのインデックス設計やプログラムの内部ロジックまで決めてしまうケースがあります。これは、基本設計の本来の目的から逸脱しており、さまざまな問題を引き起こします。

この誤解により、以下のような問題が生じることがあります。

ユーザーレビューで技術的な議論に終始してしまう
詳細設計で再検討が必要になり、手戻りが発生する
基本設計書が技術者以外には理解困難になる

この問題を解決するためには、基本設計では「What（何を）」に焦点を当て、「How（どのように）」は詳細設計に委ねることが大切です。技術的な制約がある場合は、別途技術検討書として整理することをお勧めします。

誤解2：詳細設計を省略してプログラミングに進む

「基本設計があれば実装できる」と考え、詳細設計を省略するケースもよく見られます。しかし、これは品質低下や開発効率の悪化を招きます。

詳細設計を省略することで、次のような問題が発生します。

プログラマーごとに実装方法がバラバラになる
複雑な処理でバグが多発する
保守性の低いコードが量産される

これらの問題を防ぐために、規模の小さい機能であっても、最低限の処理フローは作成しましょう。特に、エラー処理や例外処理については、詳細設計で明確に定義することが重要です。

誤解3：基本設計と詳細設計を同時並行で進める

工期短縮のため、基本設計と詳細設計を並行して進めようとするプロジェクトもあります。しかし、これは本末転倒な進め方といえます。

同時並行で進めることにより、以下の問題が生じやすくなります。

基本設計の変更が詳細設計に大きく影響する
設計の一貫性が保てなくなる
結果的に手戻りが増え、工期が延びる

適切な進め方としては、基本設計の主要部分が固まってから詳細設計に着手することが重要です。ただし、技術的な実現可能性の検証（プロトタイピング）は、基本設計と並行して行うことが有効です。

これらの誤解を避けるためには、プロジェクト開始時に基本設計と詳細設計の役割分担を明確にし、チーム全体で認識を統一することが重要です。

設計品質を高める実践的なテクニック｜手戻りを防ぐ5つのポイント

長年の開発経験から、設計品質を高め、手戻りを防ぐための実践的なテクニックをご紹介します。

1. トレーサビリティの確保

要件定義から基本設計、詳細設計、そしてプログラムまで、一貫した追跡可能性（トレーサビリティ）を確保することが重要です。

トレーサビリティを確保するために、以下の方法で実践していきましょう。

要件には要件ID、機能には機能ID、プログラムにはプログラムIDを付与
各設計書で参照元のIDを明記する
変更が発生した際の影響範囲を即座に把握できる仕組みを作る

2. 段階的なレビューの実施

設計書が完成してから一括レビューするのではなく、段階的にレビューを実施します。

効果的なレビューを行うには、次のような段階的なアプローチが有効です。

基本設計では画面デザインが固まった時点で一度レビュー
詳細設計では重要な処理フローから順次レビュー
レビュー指摘事項はその場で修正方針を決定

3. プロトタイピングの活用

特に画面設計において、静的な設計書だけでは伝わりにくい部分があります。簡易的なプロトタイプを作成することで、認識のずれを防げます。

プロトタイピングを効果的に活用するために、以下の手法を取り入れてみましょう。

HTML/CSSで簡易的な画面モックアップを作成
画面遷移が体験できるプロトタイプツールを活用
ユーザビリティテストを実施し、フィードバックを設計に反映

4. 設計パターンの標準化

よく使われる設計パターンを標準化し、テンプレート化することで、設計品質の均一化と効率化を図ります。

設計パターンの標準化においては、次の要素を整備することが重要です。

CRUD処理の標準的な設計パターンを定義
エラー処理の共通ルールを策定
設計書のテンプレートを整備し、記述レベルを統一

5. 非機能要件の明確化

性能や可用性といった非機能要件は、後工程で問題になりやすい部分です。基本設計の段階で明確にしておきましょう。

非機能要件を明確化する際は、以下の項目を具体的に定義していきます。

レスポンスタイムの目標値を画面ごとに設定
同時接続数やデータ量の想定値を明記
障害時の復旧目標時間（RTO）を定義

これらのテクニックを実践することで、設計品質が向上し、後工程での手戻りを大幅に削減できます。

設計書は今後より重要に

本記事では基本設計と詳細設計の違いを視点と抽象度から解説しました。近年、AI技術の発展により設計書から自動的にコードを生成する時代が到来しています。

CodeAGIは、Excel等の設計書をアップロードするだけでプログラムコードを自動生成する革新的なAIサービスです。とある大手システムインテグレーターNTTドコモソリューションズでは大幅な生産性向上を実現。人間が3日かかる作業を2分で完了させます。

このようなAI時代において、エンジニアは単純なコーディングから解放され、設計やアーキテクチャなど創造的な業務に集中できるようになります。つまり、設計書の品質が成果物に直結する時代となり、設計能力こそがエンジニアの核心的価値となるのです。

CodeAGIの詳細はこちら

一覧を見る