目次
1. 基本設計とは
基本設計（外部設計）は、要件定義で決めた「何を実現するか」を、システムとして「どう見え、どう振る舞うか」 に落とし込む工程です。
| 工程 | 主な問い | 主な読み手 |
|---|---|---|
| 要件定義 | 何を実現するか（What） | 発注者・業務部門 |
| 基本設計 | 利用者・外部から見てどう動くか | 発注者・開発者の両方 |
| 詳細設計 | 内部でどう作るか（How） | 開発者 |
ポイント: 基本設計書は「発注者が合意できる」ことと「開発者が詳細設計に進める」ことの両方を満たす必要がある。どちらか一方に寄りすぎないこと。
2. 進め方の原則
2.1 要件とのトレーサビリティを確保する
- すべての設計項目に、対応する要件IDを紐づける（要件ID ⇔ 機能ID ⇔ 画面ID）
- トレーサビリティマトリクスを作り、要件の漏れと要件にない機能（過剰設計） の両方を検出する
- 要件が曖昧なまま設計を進めない。曖昧な点は「確認事項一覧」に起票し、期限と担当者を決める
2.2 全体から部分へ（トップダウン）
- システム全体構成・方式設計
- 機能一覧・業務フロー
- 画面・帳票・外部IF・データ
- 非機能・運用
いきなり画面レイアウトから入ると、機能の重複・抜けや整合性の崩れが起きやすい。
2.3 早く見せて早く合意する
- 画面はモックアップやプロトタイプで早期に見せる（文章だけのレビューは認識齟齬の温床）
- 成果物を一括で出さず、領域ごとに段階的にレビューする
- 合意事項は議事録に残し、設計書に反映した版数を明記する
2.4 「決めたこと」と「決めていないこと」を明確にする
- 未決事項・前提条件・制約条件を設計書内に明示する
- 「TBD」は放置しない。いつまでに誰が決めるかをセットで書く
3. 主な成果物と記載のポイント
3.1 システム方式設計（アーキテクチャ）
- システム構成図（サーバ、ネットワーク、外部システム、クラウドサービス）
- 採用技術（言語、フレームワーク、DB、ミドルウェア）と選定理由
- 処理方式（オンライン／バッチ／非同期、同期・非同期連携の使い分け）
- 認証・認可方式、セッション管理方式
- 共通方針（ログ出力、エラーハンドリング、トランザクション境界、文字コード、日時・タイムゾーン）
選定理由を書いておくと、後から「なぜこうなっているのか」で揉めない。ADR（Architecture Decision Record）形式での記録も有効。
3.2 機能設計
- 機能一覧（機能ID、機能名、概要、対応要件ID、利用者）
- 業務フロー図／システム化業務フロー（人の作業とシステム処理の境界を明確に）
- 機能ごとの入力・処理概要・出力
- 業務ルール・計算ロジック・状態遷移（ステータスの遷移図は特に重要）
3.3 画面設計
- 画面一覧・画面遷移図
- 画面レイアウト（ワイヤーフレーム）
- 項目定義：項目名、型、桁数、必須／任意、初期値、入力チェック、表示形式
- イベント定義：ボタン押下時の動作、エラー時の挙動
- 権限による表示・操作制御
- 共通UI規約（メッセージ表示位置、ボタン配置、日付形式、確認ダイアログの基準）
よくある漏れ: 0件時の表示、エラー時の入力値保持、二重送信防止、ページング・ソート、ブラウザバック時の挙動、長い文字列の表示崩れ
3.4 帳票設計
- 帳票一覧、レイアウト、項目定義
- 出力契機（オンライン／バッチ）、出力形式（PDF、CSV、Excel）
- 改ページ条件、合計・小計の算出ルール、ソート順
3.5 外部インターフェース設計
- 連携先一覧と連携方式（API、ファイル、DB連携、メッセージキュー）
- データ項目定義、フォーマット、文字コード、改行コード
- 連携タイミング・頻度、データ量
- 異常系：タイムアウト、リトライ方針、冪等性、障害時の再送・リカバリ手順
- 責任分界点（どこまでが自システムの責任か）
外部IFは相手先との調整に時間がかかるため、最優先で着手する。
3.6 データ設計
- 概念／論理データモデル（ER図）
- エンティティ一覧、主要項目、主キー・リレーション
- コード定義（区分値の一覧と意味）
- データ保持期間、削除・アーカイブ方針
- 個人情報・機密情報の識別と取り扱い（暗号化・マスキング対象）
3.7 メッセージ設計
- メッセージID、種別（情報／警告／エラー）、文言
- 利用者が次に何をすればよいか分かる文言にする
- 技術的な内部情報（スタックトレース等）を画面に出さない
3.8 非機能設計
IPA「非機能要求グレード」などを参考に、観点の漏れを防ぐ。
| 観点 | 設計内容の例 |
|---|---|
| 可用性 | 稼働時間、目標稼働率、冗長化、RPO/RTO |
| 性能・拡張性 | 応答時間目標、同時接続数、データ量の想定と増加見込み |
| 運用・保守性 | 監視項目、バックアップ、ジョブ運用、リリース方式 |
| 移行性 | 移行対象データ、移行方式、切替手順 |
| セキュリティ | 認証・認可、通信・保存データの暗号化、ログ監査、脆弱性対策 |
| システム環境 | 対応ブラウザ・OS・端末、法令・規制対応 |
数値で書く: 「高速に応答する」ではなく「主要画面は95%タイルで2秒以内」のように検証可能な形にする。
3.9 運用設計（概要）
- 運用体制、運用スケジュール
- バッチジョブ一覧・実行順序・依存関係
- 障害時の連絡フロー・一次切り分け
- 権限・アカウント管理の運用
4. 設計書の書き方
4.1 読み手を意識する
- 業務用語と技術用語を混在させない。用語集を作り、表記を統一する
- 発注者向けの説明は図・画面イメージ中心、開発者向けの定義は表形式で厳密に
4.2 一意に解釈できる書き方をする
- 「など」「適宜」「必要に応じて」を避ける
- 条件分岐は表（デシジョンテーブル）で書く
- 境界値を明確にする（「以上／超える」「以下／未満」を正確に）
4.3 同じことを二か所に書かない
- 共通ルールは共通設計書に一度だけ書き、各設計書からは参照する
- 重複記載は修正漏れによる矛盾の原因になる
4.4 テンプレートと命名規約を統一する
- ID体系（例：機能 F-001、画面 S-001、帳票 R-001、IF I-001）を最初に決める
- 設計書のテンプレート・記載レベルをチームで揃える（記載例を1本作ってから展開する）
4.5 変更管理を行う
- 版数管理と改訂履歴（変更箇所・理由・承認者）
- 合意後の変更は変更管理プロセスを通し、影響範囲（他設計書・スケジュール・費用）を評価する
5. レビューのポイント
5.1 レビューの進め方
- 目的別に分ける：業務妥当性（発注者）と実現性・整合性（開発者・アーキテクト）
- 量が多い場合は一度に全部見せず、分割して短いサイクルで回す
- 指摘は一覧化し、対応状況を追跡する。指摘の傾向は品質分析に使う
5.2 チェックリスト
- すべての要件が設計に反映されているか（トレーサビリティ）
- 要件にない機能が混入していないか
- 画面・帳票・IF・データ間で項目名・型・桁数が整合しているか
- 正常系だけでなく異常系・例外系が定義されているか
- 権限ごとの振る舞いが定義されているか
- 非機能要件が数値で定義され、検証可能か
- セキュリティ・個人情報の扱いが明確か
- 未決事項に期限と担当者がついているか
- 実現性（技術的・コスト的・スケジュール的）に無理がないか
- テスト（結合・総合テスト）の観点が導き出せる内容か
6. よくある失敗と対策
| 失敗 | 結果 | 対策 |
|---|---|---|
| 要件の曖昧さを残したまま設計 | 後工程で手戻り | 確認事項一覧で期限管理、合意を記録 |
| 正常系しか書いていない | 実装者ごとに異常時の挙動がばらつく | 異常系・境界値の記載をテンプレートで必須化 |
| 非機能を後回し | 性能・セキュリティ問題が終盤で発覚 | 方式設計の段階で非機能を確定 |
| 外部IFの調整が遅れる | 結合テストで不整合が多発 | 最優先で着手、IF仕様書を相手先と相互承認 |
| 詳細設計レベルまで書き込みすぎる | 工数超過・発注者が読めない | 「外から見える振る舞い」に絞る |
| 逆に粒度が粗すぎる | 詳細設計で解釈が割れる | 記載例を作り、粒度の基準を合わせる |
| 文章だけで画面を合意 | リリース直前に「イメージと違う」 | モックアップ・プロトタイプで早期確認 |
| 設計書が実装と乖離 | 保守時に設計書が信用されない | 変更管理を徹底、更新を完了条件に含める |
7. アジャイル・近年の開発での考え方
- ウォーターフォールでなくても「基本設計で決めるべきこと」（アーキテクチャ、共通方針、非機能、外部IF、データモデル）は早期に決める価値が高い
- 画面詳細などは、スプリントごとにユーザーストーリー＋受け入れ条件として段階的に詳細化してもよい
- 設計書はWikiやMarkdown、OpenAPI等のコードに近い形式で管理すると、変更追従しやすい
- 意思決定はADRで残すと、経緯が追跡できる
8. まとめ
- 要件と紐づける（トレーサビリティ）
- 全体から部分へ設計する
- 早く見せて早く合意する
- 異常系と非機能を後回しにしない
- 一意に解釈できる書き方をする
- 変更を管理し、設計書を生きた資料に保つ