この内容は古いバージョンです。最新バージョンを表示するには、戻るボタンを押してください。
バージョン:4
ページ更新者:atom
更新日時:2026-06-11 07:10:02

タイトル: 基本設計
SEOタイトル: ソフトウェア基本設計 (外部設計) 完全ガイド

この記事の要点
  • 基本設計 (外部設計) は、要件定義の「何を作るか」を「どう実現するか (外側から見える形)」に落とし込む工程
  • 主成果物: システム構成図 / 画面設計 (ワイヤー/モック) / 画面遷移図 / 機能仕様書 / データ設計 (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 図 / テーブル定義書エンティティ, 属性, 主キー, 外部キー, 制約
APIAPI 設計書 (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: 危険信号。プロトタイプを早期に見せ、レビューを実施するプロセスを契約に組み込む。後で「言った言わない」を防ぐ。