設計書は何を書き、何を書かないか｜要件定義・基本設計・詳細設計・テスト（UAT）の工程別ガイド

「設計書、全部書いていませんか？」各工程で"何を書き、何を書かないか"を決めないと、二重管理と形骸化で品質はむしろ落ちます。要件定義・基本設計・詳細設計・テスト（UAT）の工程別に、クラウド/IaC時代の設計書の書き分けを、二次請けの実務目線で整理します。

01「設計書、全部書いていませんか？」

設計書が形骸化する原因は、たいてい「各工程で何を書き、何を書かないかを決めていない」ことにあります。要件定義でAWSサービス名を決め始め、詳細設計でパラメータをExcelに手写経し、テスト仕様書に実装の内部を再掲する——気づけば分厚いのに使えない成果物ができあがります。

特にクラウド／IaC時代は、詳細をコードが持つようになりました。それなのに従来どおり全パラメータを紙で二重管理すると、コードと設計書がずれ、どちらが正か分からなくなります。

以下、指定の4工程——要件定義／基本設計／詳細設計／テスト（UAT含む）——で「書くこと／書かないこと」を具体化します。

02早見表 — 工程ごとに「問い」が違う

まず全体像を一枚に。各工程は「答えるべき問い」が違い、それが書く・書かないの境界になります。

03要件定義 — 「満たすこと」を数値と合意で固める

要件定義の問いは What（何を満たすか）。ここで技術を決めたくなりますが、仕事は「実現すべきこと」を数値と合意で固めることです。

書く：

• 業務要件（実現したい業務・機能一覧レベル）／スコープ（対象と対象外を明確に）
• 非機能要件——可用性（稼働率目標）・性能・拡張性・セキュリティ・運用・移行・コンプラ/規制
• SLA目標・RTO/RPO を数値で（「99.9%」「復旧4時間」まで書く）
• 前提・制約（既存環境、予算上限、期限、社内標準）／体制・役割／成功基準（何をもって完了か）

書かない（＝基本設計へ持ち越す）：

• AWSサービス名レベルの選定（RDSかAuroraか、はまだ）
• パラメータ、IPアドレス、IAMポリシー、画面/テーブル定義
• 「どう作るか」の実装方針

04基本設計 — 「顧客と合意する方式」を決め切る

基本設計の問いは How方針（どう実現するか）。顧客が判断できる粒度で方式を決め、合意する層です。パラメータの海に潜る前に、"方式"を決め切るのが役割。

書く：

• 全体構成図（アーキテクチャ）と機能一覧、外部インターフェース
• 方式設計——可用性方式（Multi-AZ/冗長化）、バックアップ/DR方式、ネットワーク構成方針、認証/権限方式、監視/ログ/運用方式
• AWSサービス選定とその根拠（なぜAuroraか、なぜFargateか——サービス対応表の観点で）
• 命名規則・タグ設計・アカウント構造の方針（マルチアカウント戦略と接続）、セキュリティ設計方針、責任分界

書かない（＝詳細設計へ持ち越す）：

• 全パラメータ（インスタンスタイプの最終値、SGルールの全行）
• IAMポリシーのJSON、サブネットCIDRの全ビット割り当て（方針は書く、全ては詳細へ）
• IaCコードそのもの

05詳細設計 — IaC時代は「コードが実体、紙は意図」

詳細設計の問いは How実体（実装できる粒度）。従来はここでパラメータシート——インスタンス、ストレージ、CIDR、SGルール、IAMロール、タグ、スケーリング閾値、監視項目/閾値、バックアップ世代/保持——を全部書きました。ですが、ここがクラウド/IaC時代の最大の変化点です。

書く（IaC時代の詳細設計書）：

• パラメータの「なぜその値か」＝意図・根拠・トレードオフ（例：なぜこのインスタンスサイズか、なぜこの保持世代か）
• 変更履歴・レビュー観点、要件へのトレーサビリティ
• パラメータ一覧が要るなら terraform-docs 等でコードから生成（手作業台帳にしない）

書かない：

• コードから生成できるパラメータの手作業台帳（＝二重管理）
• コードの内容そのものの紙への転記

06テスト（UAT含む） — 「設計しただけ」を証明に変える

テストの問いは 検証（満たしたか）。要件定義で決めた数値に、実測で答え合わせをする工程です。クラウドの可用性やDRは、"設計しただけ"では証明になりません。

書く：

• テスト方針と種別（単体／結合／システム／性能／障害／セキュリティ／UAT）
• 要件トレーサビリティ付きテストケース（要件番号 → テストID）と合否基準
• 非機能テスト——フェイルオーバー試験（実際にAZ/インスタンスを落とす）、DRリストア試験、負荷/性能、移行リハーサル・切替手順の検証
• UATシナリオ（業務観点・ユーザーの言葉で。技術検証と混ぜない）

書かない：

• 実装内部の再掲
• 機械で自動検証できるもの——構文/ポリシー/セキュリティはCI（tfsec/Checkov/OPA）に寄せ、テスト仕様書に人手確認として重複させない

074工程を貫く3つの原則

工程ごとの「書く/書かない」を支えるのは、次の3原則です。

• ① トレーサビリティ：要件→基本→詳細→テストが一本の線でつながること。要件番号が各工程・テストまで追えること。これが崩れると「何のための設計か」が消え、レビューも監査も通らなくなります。
• ② 二重管理をやめる：IaC時代はコードが正、紙は意図。生成できるもの（パラメータ表・構成図）は生成し、手写経しない。
• ③ 「書かない勇気」：早すぎる詳細（要件で技術）、遅すぎる方針（詳細で方式）、二重記載を避ける。各工程の抽象度を守る。

08まとめ — 抽象度を変え、詳細はコードへ

要件定義＝What、基本設計＝How方針、詳細設計＝How実体、テスト＝検証。各工程で抽象度を変え、書く・書かないを決める。そしてクラウド/IaC時代は、詳細をコードに寄せ、設計書は「意図」と「トレーサビリティ」を担う——これだけで、二重管理と形骸化の多くは消えます。

EMWは二次請けで、設計から構築・テスト・移行まで実務で回してきました（たとえばWindows S2D×Hyper-Vの設計判断）。設計書の型・成果物の再定義・レビュー基準づくりを、御社の工程に合わせて一緒に整えます。

09よくある質問（FAQ）