この記事の要点

基本設計 (外部設計) は、要件定義の「何を作るか」を「どう実現するか (外側から見える形)」に落とし込む工程 主成果物: システム構成図 / 画面設計 (ワイヤー/モック) / 画面遷移図 / 機能仕様書 / データ設計 (ER 図) / API 仕様 / 帳票・バッチ仕様 非機能要件もここで明確化: 性能 (SLA), 可用性, セキュリティ, 運用, 拡張性 ウォーターフォール: 基本設計後にレビュー&承認 → 詳細設計へ。Agile: 「Just enough design」で同等内容を反復で漸進的に作る ツール例: 画面 = Figma / Whimsical、業務フロー = Lucidchart / draw.io、データ = dbdiagram.io / Mermaid、API = OpenAPI (Swagger)

基本設計とは

システム開発工程のうち、要件定義の次・詳細設計の前に位置するフェーズ。「外側から見て何ができるか」を確定させる工程で、外部設計とも呼ばれます。経営層・業務部門・エンドユーザーが理解できる粒度で書かれ、承認の対象になります。

工程	担当	関心事
企画 / 要件定義	ビジネス側 + PM	「何のために何を作る」
基本設計 (外部設計)	SE + アーキテクト	「ユーザーから見てどう動くか」
詳細設計 (内部設計)	SE + 開発リーダー	「コードとしてどう実装するか」
製造 (実装)	プログラマー	「実際にコードを書く」
テスト	テスター + SE	「設計通り動くか」

基本設計の主な成果物

カテゴリ	成果物	記述内容
システム全体	システム構成図 / アーキテクチャ図	サーバ・ネットワーク・ミドル構成、コンテナ・クラウドリソース
機能	機能一覧 / 機能仕様書	機能 ID, 名称, 概要, 入出力, 業務ルール
画面	画面一覧 / 画面設計書 (ワイヤー/モック)	レイアウト, 項目仕様, バリデーション, 操作仕様
画面遷移	画面遷移図	画面間の遷移条件, 戻る/進む, 認証要否
業務フロー	業務フロー図 (BPMN / 業務ユースケース)	ユーザ操作 + システム処理の時系列
データ	ER 図 / テーブル定義書	エンティティ, 属性, 主キー, 外部キー, 制約
API	API 設計書 (OpenAPI)	パス, メソッド, パラメータ, レスポンス, 認可
バッチ	バッチ一覧 / バッチ処理設計書	起動契機, 入出力, 処理概要, 異常時挙動
帳票	帳票一覧 / 帳票レイアウト	項目, 計算ロジック, 出力形式 (PDF / Excel)
外部 I/F	外部システム連携仕様	連携方式, データフォーマット, タイミング, 障害時挙動
非機能	非機能要件定義書	性能, 可用性, セキュリティ, 運用, 拡張性

画面設計の進め方

1. 画面一覧で全画面を洗い出し (ログイン / 一覧 / 詳細 / 登録 / 編集 / 削除 / 検索 / エラー / メッセージ / 印刷など)
2. 各画面のワイヤーフレームを Figma / Whimsical で作成
3. 項目ごとに入力規則・バリデーション・初期値を「画面項目定義表」で明文化
4. 操作 (ボタン押下時の挙動・遷移先・呼ぶ API) を画面仕様書に記述
5. 業務側とモックレビュー → 修正 → 承認
6. UI ガイドラインに沿ったデザインカンプを作成

画面項目定義表のサンプル

No	項目名	型	桁数	必須	初期値	バリデーション	備考
1	顧客 ID	数値	10	○	—	半角数字のみ	編集モード時は readonly
2	氏名	文字列	50	○	—	1-50 文字	姓名スペース区切り
3	メールアドレス	文字列	200	○	—	RFC5322 形式	重複チェックあり
4	生年月日	日付	—	—	—	1900-01-01 以降	カレンダーピッカー
5	ステータス	列挙	—	○	有効	有効 / 無効 / 一時停止	ラジオボタン

データ設計 (ER 図)

業務エンティティを抽出し、属性 / 主キー / 外部キーを定義します。簡易には Mermaid で記述できます:

erDiagram
    USER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_ITEM : contains
    PRODUCT ||--o{ ORDER_ITEM : "is in"

    USER {
        bigint id PK
        string email UK
        string name
        datetime created_at
    }
    ORDER {
        bigint id PK
        bigint user_id FK
        decimal total_amount
        string status
        datetime ordered_at
    }
    ORDER_ITEM {
        bigint id PK
        bigint order_id FK
        bigint product_id FK
        int quantity
        decimal unit_price
    }
    PRODUCT {
        bigint id PK
        string name
        decimal price
        int stock
    }

API 設計 (OpenAPI)

openapi: 3.0.3
info:
  title: Order API
  version: 1.0.0
paths:
  /api/v1/orders:
    get:
      summary: 注文一覧取得
      parameters:
        - name: status
          in: query
          schema: { type: string, enum: [pending, paid, shipped, canceled] }
        - name: page
          in: query
          schema: { type: integer, default: 1 }
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  total: { type: integer }
                  items:
                    type: array
                    items: { $ref: '#/components/schemas/Order' }
        '401': { description: 認証エラー }
    post:
      summary: 注文作成
      security:
        - bearerAuth: []
      requestBody:
        required: true
        content:
          application/json:
            schema: { $ref: '#/components/schemas/OrderCreate' }
      responses:
        '201': { description: Created }
        '400': { description: バリデーションエラー }

非機能要件

カテゴリ	項目	例
性能	応答時間 / スループット	「平均応答 500ms 以内、ピーク 1000 req/s」
可用性	SLA / RPO / RTO	「年間 99.9% (約 8.7h ダウン許容)、RPO 1h、RTO 4h」
セキュリティ	認証 / 認可 / 暗号化 / 監査	「OIDC, RBAC, TLS 1.2+, 操作ログ 1 年保管」
運用	監視 / バックアップ / リリース	「Datadog で監視, 日次フルバックアップ + 1h 差分」
拡張性	水平スケール / データ量増加	「ユーザー数 10 倍時にコンテナ追加で対応」
移行性	クラウド移行 / ベンダーロックイン回避	「OSS DB を採用, IaC で再構築可能に」
保守性	テストカバレッジ / ログ品質	「単体テストカバレッジ 70% 以上」

レビューと承認

基本設計書は業務側 (発注者) の承認が必要です。承認なしで詳細設計に進むと、後で「思っていたのと違う」となり手戻りが膨大になります。レビュー観点:

• 業務要件をすべて満たしているか
• 画面遷移に矛盾・欠落がないか
• 業務フロー上の例外ケースが網羅されているか
• 非機能要件が現実的か (予算・期間に対し)
• 外部システム連携の前提が崩れていないか

Agile での基本設計

ウォーターフォールでは「基本設計フェーズ」として独立しますが、Agile / スクラムでは 「Just enough design」の方針で:

• スプリント初期に最小限の設計を作り、コードでフィードバックしながら洗練
• 画面はモックで早期に出してユーザーに確認
• データモデルは段階的に拡張 (DB マイグレーションを前提)
• API は OpenAPI を仕様駆動で書き、契約テストで担保
• ADR (Architecture Decision Records) で重要な設計判断を記録

使われるツール

用途	ツール例
画面 (ワイヤー / モック)	Figma / Whimsical / Balsamiq / Adobe XD
業務フロー / 画面遷移	Lucidchart / draw.io / Miro / Mermaid
ER 図 / DB 設計	dbdiagram.io / A5:SQL / SchemaSpy / Mermaid
API 仕様	OpenAPI (Swagger UI) / Stoplight / Postman
システム構成	draw.io / Lucidchart / C4 Model (Structurizr)
ドキュメント管理	Confluence / Notion / GitHub Wiki

よくある落とし穴

• 業務側がレビューしないまま製造に進む → 後段で大量の仕様変更
• 非機能要件をスキップ → 本番リリース後に性能問題発覚
• 例外ケース・エラー画面の設計漏れ → 実装時にデザイナーを再招集する手戻り
• 外部連携の前提が変わる → 「相手システムは XML だと思っていたら JSON だった」など
• 画面設計と DB 設計の不整合 → 表示できない項目がある / 計算がそもそも不可能

FAQ

Q: 基本設計と詳細設計の境目は？
A: 業務側に説明できる粒度=基本設計、エンジニアにしか分からない粒度=詳細設計、と覚えると分かりやすい。クラス設計やシーケンス図は通常詳細設計。

Q: ドキュメントを書くだけで開発が遅い
A: 後段の手戻り防止が目的。テンプレートを整え、必要十分にとどめる。Agile なら「動くソフトウェア」を重視しドキュメントは最低限+ADR。

Q: 顧客が「基本設計はお任せします」と言う場合
A: 危険信号。プロトタイプを早期に見せ、レビューを実施するプロセスを契約に組み込む。後で「言った言わない」を防ぐ。