詳細設計書の読み方

詳細設計書は、システムの内部仕様を定義したドキュメントです。「どう作るか」「具体的にどう実装するか」を記述します。

詳細設計書とは

別名

詳細設計書は、現場によって以下のような呼び方をされることがあります。

• 内部設計書
• 詳細設計
• DD（Detail Design）
• プログラム設計書

役割

flowchart LR
    A[要件定義書] --> B[基本設計書]
    B -->|何を作るか| C[詳細設計書]
    C -->|どう作るか| D[実装]

詳細設計書は、基本設計書と実装の間に位置し、開発者が実装するために必要な具体的な情報を記載します。

基本設計書との違い

詳細設計書の構成要素

詳細設計書は、複数のドキュメントで構成されることが多いです。

【実践】詳細設計書サンプルと読み方

ここからは、詳細設計書に含まれる代表的なドキュメントのサンプルを使って、具体的な読み方を解説します。

サンプル1：画面項目定義書

画面項目定義書は、画面上の各項目の仕様を定義します。

【サンプル】会員登録画面 項目定義書

この設計書から読み取るべきこと

flowchart TD
    A[項目定義書] --> B{何を確認する？}
    B --> C[入力項目の数と種類]
    B --> D[必須チェックの対象]
    B --> E[桁数・形式の制約]
    B --> F[バリデーションルール]

    C --> G[画面のHTML構造を決める]
    D --> H[必須チェック処理を実装]
    E --> I[入力制限を実装]
    F --> J[エラーメッセージを準備]

【実践】この設計書から実装を考える

ステップ1：HTMLの構造を考える

<!-- 項目定義書の「種別」を見てinputタイプを決める -->
<input type="text" id="userId" maxlength="20" required>      <!-- No.1 -->
<input type="password" id="password" maxlength="20" required> <!-- No.2 -->
<input type="email" id="email" maxlength="256" required>      <!-- No.6 -->
<input type="date" id="birthDate">                            <!-- No.8 -->
<input type="checkbox" id="agree" required>                   <!-- No.10 -->

ステップ2：バリデーションを考える

詳しくは 画面設計書の読み方 を参照してください。

サンプル2：API仕様書（IF仕様書）

API仕様書は、APIのリクエストとレスポンスを定義します。

【サンプル】会員登録API仕様書

■ 基本情報

■ リクエストパラメータ

■ リクエスト例

{
  "userId": "yamada123",
  "password": "Pass1234",
  "lastName": "山田",
  "firstName": "太郎",
  "email": "yamada@example.com",
  "phone": "09012345678",
  "birthDate": "1990-01-15",
  "gender": "MALE"
}

■ レスポンス（正常時：201 Created）

{
  "id": 12345,
  "userId": "yamada123",
  "createdAt": "2025-01-15T10:30:00+09:00"
}

■ エラーレスポンス

【実践】この設計書から実装を考える

ステップ1：リクエストクラスを作る

// API仕様書の「リクエストパラメータ」から作成
public class UserRegistrationRequest {
    @NotBlank
    @Size(min = 1, max = 20)
    private String userId;

    @NotBlank
    @Size(min = 8, max = 20)
    private String password;

    @NotBlank
    @Size(min = 1, max = 50)
    private String lastName;

    @NotBlank
    @Size(min = 1, max = 50)
    private String firstName;

    @NotBlank
    @Email
    @Size(max = 256)
    private String email;

    @Size(max = 15)
    private String phone;  // 必須でない

    private String birthDate;  // 必須でない

    private String gender;  // 必須でない
}

ステップ2：レスポンスクラスを作る

// API仕様書の「レスポンス」から作成
public class UserRegistrationResponse {
    private Long id;
    private String userId;
    private String createdAt;
}

ステップ3：エラーハンドリングを考える

// API仕様書の「エラーレスポンス」から作成
public class ApiError {
    private String errorCode;
    private String message;
}

// エラーコードを定数化
public enum ErrorCode {
    E001("必須項目が未入力です"),
    E002("入力形式が正しくありません"),
    E101("指定されたユーザーIDは既に使用されています"),
    E102("指定されたメールアドレスは既に使用されています"),
    E999("システムエラーが発生しました");

    private final String message;
    // ...
}

詳しくは API仕様書の読み方 を参照してください。

サンプル3：テーブル定義書

テーブル定義書は、データベースのテーブル構造を定義します。

【サンプル】ユーザーテーブル定義

■ テーブル基本情報

■ カラム定義

■ インデックス

この設計書から読み取るべきこと

【実践】この設計書からエンティティを作る

@Entity
@Table(name = "m_user")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;  // No.1: PK, AUTO

    @Column(name = "user_id", nullable = false, length = 20)
    private String userId;  // No.2: NOT NULL, VARCHAR(20)

    @Column(name = "password_hash", nullable = false, length = 256)
    private String passwordHash;  // No.3

    @Column(name = "last_name", nullable = false, length = 50)
    private String lastName;  // No.4

    @Column(name = "first_name", nullable = false, length = 50)
    private String firstName;  // No.5

    @Column(nullable = false, length = 256)
    private String email;  // No.6

    @Column(length = 15)
    private String phone;  // No.7: NULL許可

    @Column(name = "birth_date")
    private LocalDate birthDate;  // No.8: NULL許可

    @Column(length = 10)
    private String gender;  // No.9: NULL許可

    @Column(nullable = false, length = 20)
    private String status = "ACTIVE";  // No.10: デフォルト値

    @Column(name = "created_at", nullable = false)
    private LocalDateTime createdAt;  // No.11

    @Column(name = "updated_at", nullable = false)
    private LocalDateTime updatedAt;  // No.12
}

詳しくは テーブル定義書の読み方 を参照してください。

設計書間の関係を理解する

詳細設計書は複数のドキュメントで構成され、それぞれが関連しています。

flowchart TD
    subgraph 基本設計
        A[画面遷移図]
        B[機能一覧]
        C[ER図]
    end

    subgraph 詳細設計
        D[画面項目定義書]
        E[API仕様書]
        F[テーブル定義書]
        G[処理フロー]
    end

    A --> D
    B --> E
    B --> G
    C --> F

    D -.->|項目が対応| E
    E -.->|カラムが対応| F

設計書を横断的に読む

1つの機能を実装するには、複数の設計書を横断的に読む必要があります。

【例】会員登録機能を実装する場合

詳細設計書を読む流れ

flowchart TD
    A[1. 自分の担当機能を特定] --> B[2. 関連する画面設計を読む]
    B --> C[3. API仕様書でI/Oを確認]
    C --> D[4. テーブル定義書でDB構造を確認]
    D --> E[5. 処理フローでロジックを確認]
    E --> F[6. 不明点をリストアップ]

読むときのチェックリスト

読む前に確認すること

• [ ] 自分の担当機能を明確にしたか
• [ ] 関連する設計書一式を入手したか
• [ ] 設計書のバージョンが最新か確認したか
• [ ] 不明点をメモする準備ができているか

読んだ後に確認すること

• [ ] 入力項目と出力項目を把握したか
• [ ] 必須項目とバリデーションを把握したか
• [ ] エラーパターンを把握したか
• [ ] DBのテーブル構造を把握したか
• [ ] 設計書間の矛盾はなかったか
• [ ] 不明点をリストアップしたか

設計書間の矛盾に注意

設計書間で矛盾がある場合は、確認してから作業します。

よくある疑問

1年目エンジニアとしての関わり方

関連ドキュメント

• 設計書・仕様書の読み方 - 設計書全般の読み方
• 基本設計書の読み方 - 基本設計書の読み方
• 画面設計書の読み方 - 画面設計の詳細
• 処理設計書の読み方 - 処理設計の詳細
• テーブル定義書の読み方 - DB設計の詳細
• API仕様書の読み方 - API設計の詳細