処理設計書の読み方

処理設計書は、バックエンドの処理ロジックを定義したドキュメントです。API実装やサーバーサイドの開発で必ず参照します。

処理設計書とは

役割

• 処理の目的と概要を定義
• 入出力データを定義
• 処理フロー（ロジック）を定義
• エラー処理を定義
• 使用するテーブルを定義

いつ使うか

処理設計書の構成

よくある構成要素

読み方の流れ

flowchart TD
    A[1. 基本情報で関連画面を確認] --> B[2. 処理概要で目的を理解]
    B --> C[3. 入出力を把握]
    C --> D[4. 処理フローを追う]
    D --> E[5. エラー処理を確認]
    E --> F[6. 使用テーブルを確認]
    F --> G[7. セキュリティ考慮事項を確認]

【サンプル】処理設計書の実例

画面設計書と対になる、処理（バックエンド）側の設計書サンプルです。

処理設計書サンプル：ユーザー登録API

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
処理設計書
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

■ 基本情報
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
処理ID      : API-001
処理名      : ユーザー登録API
関連画面    : SCR-001（ユーザー登録画面）
作成日      : 2024/01/15
更新日      : 2024/02/20
バージョン  : 1.2

■ 処理概要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
新規ユーザーの情報をデータベースに登録する。
メールアドレスの重複チェック、パスワードのハッシュ化を行う。

■ API仕様
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
エンドポイント  : POST /api/users
認証            : 不要
コンテンツタイプ: application/json

■ 入力パラメータ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

| No | パラメータ名 | 型 | 必須 | 説明 | 例 |
|----|-------------|------|------|------|-----|
| 1 | email | String | ○ | メールアドレス | "user@example.com" |
| 2 | password | String | ○ | パスワード | "Password123" |
| 3 | name | String | ○ | 氏名 | "山田太郎" |
| 4 | phone | String | - | 電話番号 | "03-1234-5678" |

【リクエストサンプル】
{
  "email": "user@example.com",
  "password": "Password123",
  "name": "山田太郎",
  "phone": "03-1234-5678"
}

■ 出力パラメータ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【成功時】HTTPステータス: 201 Created

| No | パラメータ名 | 型 | 説明 |
|----|-------------|------|------|
| 1 | user_id | Integer | 登録されたユーザーID |
| 2 | email | String | メールアドレス |
| 3 | name | String | 氏名 |
| 4 | created_at | DateTime | 登録日時 |

【レスポンスサンプル】
{
  "user_id": 12345,
  "email": "user@example.com",
  "name": "山田太郎",
  "created_at": "2024-01-15T10:30:00+09:00"
}

■ 処理フロー
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌─────────────────────────────────────────────────────────┐
│ 1. リクエスト受信                                         │
├─────────────────────────────────────────────────────────┤
│ 2. 入力バリデーション                                     │
│    - 必須チェック（email, password, name）                │
│    - 形式チェック（email形式、パスワード8文字以上）        │
├─────────────────────────────────────────────────────────┤
│ 3. メールアドレス重複チェック                             │
│    SELECT COUNT(*) FROM users WHERE email = ?            │
│    → 1件以上あれば重複エラー                             │
├─────────────────────────────────────────────────────────┤
│ 4. パスワードハッシュ化                                   │
│    bcrypt(password, salt_rounds=10)                      │
├─────────────────────────────────────────────────────────┤
│ 5. ユーザー情報登録                                       │
│    INSERT INTO users (email, password_hash, name, phone, │
│                       created_at, updated_at)            │
│    VALUES (?, ?, ?, ?, NOW(), NOW())                     │
├─────────────────────────────────────────────────────────┤
│ 6. レスポンス返却                                         │
│    登録されたuser_idを含むJSONを返す                      │
└─────────────────────────────────────────────────────────┘

flowchart TD
    A[リクエスト受信] --> B{入力バリデーション}
    B -->|NG| C[400 Bad Request]
    B -->|OK| D{メール重複チェック}
    D -->|重複あり| E[409 Conflict]
    D -->|重複なし| F[パスワードハッシュ化]
    F --> G[DBに登録]
    G -->|成功| H[201 Created]
    G -->|失敗| I[500 Internal Server Error]

■ エラー処理
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

| HTTPステータス | エラーコード | 発生条件 | エラーメッセージ |
|---------------|-------------|---------|-----------------|
| 400 | INVALID_EMAIL | メール形式不正 | メールアドレスの形式が正しくありません |
| 400 | INVALID_PASSWORD | パスワード要件未達 | パスワードは8文字以上で入力してください |
| 400 | MISSING_REQUIRED | 必須項目未入力 | {項目名}を入力してください |
| 409 | EMAIL_EXISTS | メール重複 | このメールアドレスは既に登録されています |
| 500 | INTERNAL_ERROR | システムエラー | システムエラーが発生しました |

【エラーレスポンスサンプル】
{
  "error": {
    "code": "EMAIL_EXISTS",
    "message": "このメールアドレスは既に登録されています"
  }
}

■ 使用テーブル
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【usersテーブル】

| カラム名 | 型 | NULL | 説明 |
|---------|------|------|------|
| user_id | INT | × | 主キー（自動採番） |
| email | VARCHAR(256) | × | メールアドレス（ユニーク） |
| password_hash | VARCHAR(256) | × | パスワード（ハッシュ済） |
| name | VARCHAR(100) | × | 氏名 |
| phone | VARCHAR(15) | ○ | 電話番号 |
| created_at | DATETIME | × | 作成日時 |
| updated_at | DATETIME | × | 更新日時 |

■ セキュリティ考慮事項
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- パスワードは平文で保存しない（bcryptでハッシュ化）
- SQLインジェクション対策（プレースホルダー使用）
- レスポンスにpasswordを含めない

■ 備考
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- v1.1 phone項目追加
- v1.2 パスワード要件変更（英数字混合必須）

読むときのチェックポイント

画面設計書と処理設計書の対応関係

flowchart LR
    subgraph 画面設計書
        A1[入力項目] --> A2[入力チェック]
        A2 --> A3[ボタン動作]
    end
    subgraph 処理設計書
        B1[入力パラメータ] --> B2[入力バリデーション]
        B2 --> B3[処理フロー]
    end
    A1 -.->|対応| B1
    A2 -.->|一部対応| B2
    A3 -.->|API呼び出し| B3

フロントとバックエンドのバリデーション役割分担

ポイント：セキュリティ上、バックエンド側でも必ずバリデーションを行います。フロント側は「ユーザビリティ向上」、バックエンド側は「セキュリティ担保」の役割です。

処理設計書でよくある落とし穴

質問例：処理設計書について確認するとき

処理設計書API-001について確認させてください。

処理フローのステップ3「メールアドレス重複チェック」について、
大文字小文字を区別するかどうか教えてください。

例えば、以下は同一ユーザーとして扱いますか？
- User@example.com
- user@example.com

関連ドキュメント

• 設計書・仕様書の読み方 - 設計書全般の読み方
• 画面設計書の読み方 - 対になるフロントエンド側の設計書
• ER図の読み方 - データベース構造の読み方