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

システム開発において、詳細設計は実装フェーズの「設計図」となる極めて重要な工程です。このセクションでは、まず基本設計と詳細設計の明確な違い、そして詳細設計が担う役割について解説します。

 

基本設計と詳細設計の位置づけ

システム開発は、多くの場合「要件定義」「基本設計」「詳細設計」「実装」「テスト」「リリース」というプロセス（ウォーターフォールモデル）で進められます。

 

 

基本設計が「何を作るか」を顧客と合意する工程であるのに対し、詳細設計は「どう作るか」を開発チーム内部（主にプログラマー）に示す工程であると明確に区別されます。

 

詳細設計の目的と役割

詳細設計の最大の目的は、「誰が読んでも（実装担当者が異なっても）、同じ品質のプログラムを実装できること」にあります。

 

基本設計書だけでは、機能を実現するための具体的な処理ロジックやデータの構造、モジュール間の連携方法などが不明瞭です。詳細設計では、これらの曖昧さを排除し、実装担当者が迷うことなくコーディング作業に着手できるように、必要な情報をすべて文書化（成果物化）します。

 

また、詳細設計は後続のテスト工程における重要なインプットです。単体テストや結合テストのテストケースは、詳細設計書に基づいて作成されます。設計が曖昧であれば、適切なテストケースが作成できず、品質担保が困難になります。

 

成果物作成の意義と工程全体への影響

詳細設計の成果物（ドキュメント）作成を省略したり、品質が低いまま進めたりすると、プロジェクト全体に深刻な影響を及ぼします。

 

実装（コーディング）フェーズへの影響:

• 設計が曖昧なため、プログラマーのスキルや解釈によって実装内容にバラつき（属人性）が生じます。
• 実装担当者が「どう作るべきか」をその都度設計者に確認する必要が生じ、多大なコミュニケーションコストと手戻りが発生します。
• 最悪の場合、基本設計の要件を満たせないロジックが実装され、後工程で大規模な修正が必要になります。

 

テストフェーズへの影響:

• 「正しい仕様」が定義されていないため、テストケースの作成が困難になります。
• テスト観点が漏れ、バグが検出されずにリリースされてしまうリスクが高まります。

 

保守・運用フェーズへの影響:

• 仕様変更や不具合修正の際、ソースコードを直接解読するしかなく、影響範囲の特定や修正作業に膨大な時間がかかります。
• 担当者の退職や異動により、システムの仕様が属人化する原因となります。

 

詳細設計の成果物を正確に作成することは、単なるドキュメント作業ではなく、プロジェクトの品質、コスト、納期（QCD）を担保するための根幹的な活動なのです。

 

詳細設計の成果物一覧

詳細設計フェーズで作成される成果物は多岐にわたりますが、ここでは代表的なもの、非機能要件に関するもの、そしてそれらの関連性について整理します。

 

代表的な成果物（画面設計書・テーブル定義書・IF設計書など）

プロジェクトの特性（Web系、業務系、組み込み系など）によって重点は異なりますが、一般的に以下の成果物が作成されます。

 

1. 画面設計書（詳細）:

• 目的: 画面上の各コンポーネント（ボタン、テキストボックス等）の動作や、画面遷移、入力チェック（バリデーション）ルール、エラーメッセージなど、動的な仕様を定義します。
• 補足: 基本設計では「画面レイアウト（見た目）」を定義しますが、詳細設計では「画面の振る舞い（ロジック）」を定義します。

 

2. テーブル定義書（物理設計）:

• 目的: データベースに格納するデータの構造を物理的に定義します。
• 記載項目: テーブル名、カラム名、データ型、桁数、制約（主キー、外部キー、NOT NULLなど）、インデックス、初期値、備考（用途）など。

 

3. CRUD図（マトリクス）:

• 目的: システムの各機能（画面）が、どのテーブルに対して「Create（作成）」「Read（参照）」「Update（更新）」「Delete（削除）」のどの操作を行うかを一覧化します。
• 補足: これにより、機能とデータの関連性が明確になり、処理漏れや不要な処理の検出に役立ちます。

 

4. クラス図（詳細）:

• 目的:（オブジェクト指向開発の場合）システムを構成するクラス間の関係性、各クラスが持つ属性（プロパティ）や操作（メソッド）を詳細に定義します。

 

5. シーケンス図:

• 目的: ある機能を実現するために、オブジェクトやモジュール間でどのようなメッセージ（処理要求）が、どのような順序でやり取りされるかを時系列で定義します。
• 補足: 複雑なロジックや外部システム連携の仕様を明確にするために用いられます。

 

6. モジュール仕様書（または機能仕様書）:

• 目的: プログラムを構成する個々のモジュール（関数やメソッド）の仕様を定義します。
• 記載項目: モジュール名、機能概要、入力（引数）、出力（戻り値）、処理ロジック（アルゴリズム）、呼び出す他モジュール、例外処理など。

 

7. インタフェース（IF）設計書:

• 目的: システム内部のモジュール間、または外部システムとの間でやり取りされるデータの形式（フォーマット）や連携方式（API、ファイル連携など）を定義します。
• 補足: 連携先の仕様と齟齬がないよう、厳密に定義する必要があります。

 

非機能要件に関する成果物（性能設計書・運用設計書など）

「機能」以外の品質特性（非機能要件）についても、詳細設計で具体化する必要があります。

 

1. 性能設計書:

• 目的: 基本設計で定められた性能要件（例：応答時間3秒以内）を実現するための、具体的な設計（インデックス設計、クエリの最適化方針、キャッシング戦略など）を定義します。

 

2. 運用設計書:

• 目的: システムリリース後の安定運用のための設計を定義します。
• 記載項目: 監視設計（ログ出力内容、監視項目）、バッチ処理設計、バックアップ・リストア手順、障害時対応フローなど。

 

3. セキュリティ設計書:

• 目的: セキュリティ要件（例：不正アクセス防止、データ暗号化）を実現するための具体的な実装方針（認証方式、アクセス制御、暗号化アルゴリズムなど）を定義します。

 

ドキュメント間の関連性と整合性

これらの成果物は独立して存在するのではなく、密接に関連しています。

 

「画面設計書」での入力チェックロジックは、「モジュール仕様書」のバリデーション処理に反映されます。

「CRUD図」で定義された操作は、「テーブル定義書」のデータ構造と、「モジュール仕様書」のデータベースアクセス処理の整合性を取るために使用されます。

「シーケンス図」での処理の流れは、「クラス図」の定義に基づき、「モジュール仕様書」で具体化されます。

 

設計の初期段階で、どの成果物で何をどこまで定義するかを明確にし、成果物間のトレーサビリティ（追跡可能性）を確保することが、設計漏れや仕様の不整合を防ぐ鍵となります。

 

粒度・責務の考え方と品質管理のポイント

詳細設計の品質を左右するのが「粒度」の問題です。どこまで細かく記述すべきかは、プロジェクトの特性やチームのスキルレベルによって異なります。

 

粒度が粗すぎる場合:

実装者の解釈に依存し、品質がバラつきます。レビューでの指摘も困難になります。

 

粒度が細かすぎる場合:

設計書の作成コストが増大します。また、ソースコードを見れば分かるような自明なことまで記述すると、逆に可読性が低下し、メンテナンスの負担が増えます。

 

適切な粒度を見極めるポイント:

実装者が迷う点か？:複雑なビジネスロジック、例外処理、計算式などは詳細に記述します。

チームの標準か？: 経験豊富なチームであれば粒度は粗く、オフショア開発や若手中心の場合は粒度を細かく（＝設計書の記述を厚く）します。

変更頻度は高いか？:変更が多い箇所は、設計書と実装の二重メンテナンスを避けるため、ソースコード側（コメント含む）に詳細を寄せ、設計書は概要に留める判断もあり得ます。

 

品質管理の観点では、設計書間の「整合性レビュー」と「実装可能性レビュー」（本当にこの設計で実装できるか、性能要件を満たせるか）を徹底することが不可欠です。

 

成果物一覧サンプル（表形式）

プロジェクトで作成する成果物を一覧化し、その目的と作成単位（全体、機能ごと、画面ごと等）を定義することは、作業の標準化に有効です。

 

 
 

詳細設計の成果物を作成する上で注意すべきポイント3選

質の高い詳細設計書は、開発スピードを上げ、バグを未然に防ぎます。作成時に意識すべき3つの重要ポイントを解説します。

 

実装者が迷わない「具体性」を持たせる

詳細設計のゴールは、設計書を見たエンジニアが「プログラミングを迷いなく進められる」状態にすることです。例えば、「データを登録する」と記述するだけでなく、「どのテーブルのどのカラムに、どのような型で保存するのか」まで具体化します。条件分岐やエラー時の挙動（ログ出力やメッセージ内容）を細かく定義しておくことで、実装時の解釈のズレによるバグを防ぐことができます。

 

設計書間での「整合性」を徹底する

詳細設計では、画面設計、機能設計、データベース設計など、複数の成果物を並行して作成します。ここで注意すべきは「定義の不一致」です。画面設計書で「顧客名」となっている項目が、DB定義書では「ユーザー名」となっていたり、桁数制限が異なっていたりすると現場に混乱を招きます。各成果物を横断的に確認し、定義が統一されているかチェックすることが品質向上の鍵となります。

 

変更や拡張を前提とした「保守性」を意識する

ソフトウェアはリリースして終わりではなく、必ず機能追加や修正が発生します。特定のプログラムに依存しすぎた複雑な設計は、後の修正コストを増大させます。機能ごとに独立性を高め、どこを直せばどこに影響が出るかを明確にする「見通しの良い設計」を心がけることで、将来的なメンテナンスコストを劇的に抑えることが可能になります。

 

詳細設計を成功させるための進め方

品質の高い詳細設計書は、実装とテストの品質を直接左右します。ここでは、設計書の基本構成と、レビューで重視される観点について解説します。

 

基本構成と記載項目の例

全ての設計書に共通する「お作法」として、以下の要素を含めることが望まれます。

 

1. 表紙・改版履歴:

ドキュメント名、作成者、作成日、承認者。

改版履歴（いつ、誰が、何を、なぜ変更したか）は、変更管理の観点で必須です。

 

2. 概要・目的:

この設計書が「何を」定義しているのかを簡潔に記述します。

 

3. 前提条件・制約事項:

この設計が依存する他の仕様（例：特定のミドルウェアバージョン、外部APIの仕様）を明記します。

 

4. 関連ドキュメント:

インプットとなった基本設計書や、関連する他の詳細設計書へのリンクを記載します。

 

5. 設計詳細（本体）:

ここが成果物（テーブル定義書、モジュール仕様書など）の本体となります。

例（モジュール仕様書の場合）:

• 機能ID、機能名
• 処理概要（何をインプットとし、どのような処理を行い、何をアウトプットするか）
• 入力（引数）：項目名、データ型、制約
• 出力（戻り値）：項目名、データ型
• 処理ロジック：処理フローが分かる形式で記述。フローチャート、疑似コードなど
• 正常系処理
• 準正常系処理（例：対象データ0件の場合）
• 異常系処理（例外処理、エラーハンドリング）
• 使用テーブル、呼び出しモジュール

 

記述においては、「曖昧な表現を避ける」ことが鉄則です。「～など」「適宜」「よしなに」といった表現は、実装者の解釈に委ねることになり、設計の意図が伝わりません。

 

レビューで見られる観点と改善方法

設計書のレビューは、実装着手前に設計上の欠陥を検出する最後の砦です。レビュアー（主に上級SEやPM）は、以下の観点を重点的にチェックします。

 

観点1：要件充足性（インプットとの整合性）

チェック内容: 基本設計（または要件定義）で求められた機能・仕様が、漏れなく詳細設計に落とし込まれているか。

改善方法: 基本設計書の項目と詳細設計書の項目を紐付けるトレーサビリティ・マトリクスを作成し、対応漏れがないか機械的にチェックします。

 

観点2：内部整合性（ドキュメント間・内の整合性）

チェック内容: テーブル定義書のカラム名と、モジュール仕様書のSQLで使用しているカラム名が一致しているか。画面設計書の入力項目と、IF設計書のデータ項目に齟齬はないか。

改善方法: 共通で使用する用語やデータ項目は「共通定義書」として一元管理し、各設計書はそれを参照するようにします。

 

観点3：実装可能性と妥当性

チェック内容: この設計で本当に実装可能か。非現実的な処理（例：膨大なデータを全件検索するロジック）になっていないか。性能要件やセキュリティ要件が考慮されているか。

改善方法: 経験豊富なプログラマーやインフラ担当者にもレビューに参加してもらい、技術的な妥当性を評価します。

 

観点4：網羅性（異常系の考慮）

チェック内容: 正常系の処理だけでなく、入力エラー、データ不整合、タイムアウト、リソース枯渇といった「異常系」や「例外処理」が適切に設計されているか。

改善方法: 「もし～だったら」の観点で、起こりうる例外パターンを洗い出し、それぞれの対処法（エラーメッセージを返す、ログに出力する、処理を中断するなど）を明記します。

 

レビューで指摘を受けた箇所は、単に修正するだけでなく、なぜその指摘がなされたか（どの観点が欠けていたか）を理解し、他の箇所にも同様の問題がないか水平展開することが品質向上につながります。

 

成果物テンプレートと活用事例

詳細設計の品質と効率を両立させるためには、成果物テンプレートの活用が極めて有効です。

 

テンプレート活用による標準化の効果

プロジェクトごと、あるいは担当者ごとに設計書のフォーマットや記述粒度が異なると、多くの問題が発生します。

 

レビュー工数の増大（どこに何が書かれているか探す時間）

実装品質のバラつき（設計書の解読レベルが人による）

保守性の低下（過去のドキュメントが参考にならない）

 

テンプレートの整備・運用により、これらの課題を解決できます。

 

1. 品質の均一化:

「最低限記載すべき項目」がテンプレートで定義されているため、設計者のスキルによらず、記述漏れや観点漏れを防ぐことができます。

特に異常系処理や非機能要件など、見落とされがちな項目を必須化できます。

 

2. 作成効率の向上:

設計者はフォーマット（体裁）に悩む必要がなくなり、本来の「設計（中身）」に集中できます。

過去の類似プロジェクトの成果物を流用しやすくなり、作成時間が短縮されます。

 

3. レビュー・コミュニケーションの円滑化:

レビュアーは「いつもと同じフォーマット」で確認できるため、チェック効率が劇的に向上します。

実装者も、どのドキュメントを見れば必要な情報が得られるかが明確になります。

 

4. 属人化の排除とナレッジ蓄積:

テンプレートという「型」に沿って設計することで、設計ノウハウが組織の資産として蓄積されます。

 

Excel・Word・Confluenceなどの実践例

成果物管理に使用するツールは、プロジェクトの特性やチームの文化によって選択します。

 

Excel:

適した成果物:テーブル定義書、IF設計書（項目一覧）、CRUD図、テスト仕様書など、表（マトリクス）形式で管理する情報。

特徴:多くの開発者が使い慣れており、関数やフィルタ機能も利用できます。ただし、変更履歴の管理や同時編集には工夫が必要です。

 

Word:

適した成果物: モジュール仕様書、画面設計書（詳細）、運用設計書など、文章（ロジック）や図解を多く含むドキュメント。

特徴: 表現力が高く、詳細なロジックや背景を記述するのに適しています。変更履歴機能も標準で備わっています。

 

Confluence（またはその他Wikiツール）:

適した成果物: あらゆる設計書。特にチーム全体で頻繁に参照・更新する情報。

特徴: Webベースで情報共有が容易であり、ドキュメント間のハイパーリンクや強力な検索機能が強みです。テンプレート機能も充実しており、標準化と相性が良いです。同時編集も可能ですが、厳密な版管理（承認フロー）には工夫が必要な場合があります。

 

設計ツール（CASEツール、UMLモデリングツールなど）:

適した成果物: クラス図、シーケンス図、ER図など。

特徴: 図と定義情報を連携して管理でき、整合性を保ちやすいです。一部のツールでは、設計情報からコードを自動生成する機能もあります。

 

重要なのは、ツール導入自体が目的ではなく、チーム全員が迷わず使え、情報が最新に保たれ、後から追跡できる状態を維持することです。

 

まとめ｜成果物の標準化で品質と効率を高める

本記事では、詳細設計の目的から、具体的な成果物一覧、品質を高めるための作成ポイントまでを解説しました。

 

詳細設計の精度がプロジェクト成功を左右する

詳細設計は、要件を「実際に動くシステム」に落とし込むための最終設計図です。この段階での曖昧さや抜け漏れは、実装やテストのフェーズで必ず手戻りや不具合として表れ、プロジェクトの品質・コスト・納期（QCD）に大きな影響を与えます。

精度の高い詳細設計成果物は、実装担当者にとっての明確な指示書であり、テスト担当者にとっての品質保証の基盤ともなります。

 

成果物統一がもたらすチームの生産性向上

特にチームで開発を進める上で、「成果物の標準化（テンプレート化）」は必須の取り組みです。ドキュメントのフォーマットや粒度が統一されることで、設計者、実装者、レビュアー間の認識齟齬がなくなり、コミュニケーションコストが削減され、チーム全体の生産性が向上します。

 

詳細設計の成果物に関する標準化や、既存ドキュメントの品質レビューにお悩みの場合は、専門家の知見を活用することも有効な手段です。

自社の開発プロセスや成果物の品質管理に関して課題をお持ちでしたら、ぜひ一度ご相談ください。