基本設計・詳細設計 きほんせっけい・しょうさいせっけい

---

基本設計・詳細設計とは

基本設計（Basic Design） は、要件定義で決まった「何を作るか」をもとに、システムの外から見える動作・構造を定義する工程です。「外部設計」とも呼ばれ、発注者（ユーザー企業）も内容を確認・承認する重要なフェーズです。画面レイアウト・帳票の様式・機能一覧・データの流れ（DFD）・外部連携の仕様などを設計します。

詳細設計（Detailed Design） は、基本設計で決まった外部仕様をもとに、システムの内部（プログラムレベル）の設計を行う工程です。「内部設計」とも呼ばれ、主にエンジニアが対象の文書です。モジュール分割・処理ロジック・データベースのテーブル定義・API仕様・エラーハンドリングなどを詳細に記述します。

発注者にとって特に重要なのは基本設計のレビューです。基本設計の段階で「思っていた画面と違う」「この業務フローが実現できていない」といった問題を発見・修正しておかないと、詳細設計・開発が進んでから修正するとコストが数倍に膨らみます。

---

基本設計と詳細設計の違い

項目	基本設計（外部設計）	詳細設計（内部設計）
別称	概要設計・外部設計	機能設計・内部設計
視点	ユーザーから見えるシステムの動き	システム内部の実装方法
主な作成者	ベンダーのSE（発注者もレビュー参加）	ベンダーのエンジニア（主に内部作業）
発注者の関与	✅ 高い（画面・帳票・業務フローを確認）	△ 低い（技術仕様の確認は基本的にベンダー内）
主な成果物	画面設計書・帳票設計書・機能一覧・ER図概要	プログラム設計書・DB詳細定義・API仕様書
修正コスト	中（要件定義より高い・詳細設計より低い）	高（後戻りに大きなコストがかかる）

基本設計の主な成果物（発注者が確認すべきもの）

成果物	内容	発注者の確認ポイント
画面設計書	各画面の項目・ボタン・動作フロー	業務で必要な情報が表示されているか
帳票設計書	出力帳票のレイアウト・データ項目	既存の帳票・法定様式と合っているか
機能一覧	実装する機能のリスト	要件定義書の要件がすべて含まれているか
業務フロー図	システム導入後の業務の流れ	現場の実際の業務と一致しているか
外部連携設計書	他システムとのデータ連携仕様	既存システムとの整合性

---

歴史と背景

• 1960〜70年代：構造化プログラミングの発展とともに、設計工程を「外部設計→内部設計」に分ける考え方が体系化される
• 1970年代後半：ウォーターフォールモデルが提唱（ロイス, 1970年）。要件定義→基本設計→詳細設計→製造→テストの段階的な開発プロセスが標準化
• 1980年代：日本のSIerでも「外部設計書・内部設計書」の作成が標準工程として定着。企業システム開発の基本フレームワークに
• 2001年：アジャイルマニフェストの発表。「包括的なドキュメントよりも動くソフトウェア」の考え方が広まり、設計書の重厚長大化への反省が起きる
• 2010年代：スタートアップ・Web系企業でスプリントベースの設計（ユーザーストーリー＋スプリント計画）が普及。一方で大規模基幹系・公共系では基本設計・詳細設計書が引き続き必須
• 2020年代：「設計書をAIで生成する」ツールの登場。ただし要件の正確な理解・業務知識のインプットは依然として人間の役割

---

設計フェーズの全体像と発注者の関与ポイント

---

関連する規格・標準

規格・標準	内容
ISO/IEC/IEEE 12207	ソフトウェアライフサイクルプロセス。設計プロセスを定義
ISO/IEC 25010	ソフトウェア品質モデル。設計で考慮すべき品質特性を定義
IPA「ITシステム構築のコスト見積もり手法」	設計フェーズ別の工数・コスト見積もり手法の参考資料
V字モデル（V-Model）	設計フェーズとテストフェーズの対応関係を示す開発モデル

---

関連用語

• 要件定義書 — 基本設計のインプットとなる上流文書
• 受入テスト（UAT） — 基本設計書の内容が正しく実装されているかを確認するテスト
• 契約形態（請負・準委任・SES） — 設計フェーズの責任分担が契約形態によって異なる
• システムライフサイクル — 設計フェーズが全体のどこに位置するかを示す概念
• SLA（サービスレベル合意） — 基本設計で定めた性能・可用性要件がSLAの基準になる
• RFP（提案依頼書） — 設計の前段階で発行するシステム提案依頼書