設計書・仕様書の読み方

業務で使用する設計書や仕様書を効率的に読むスキルを学びます。

設計書の種類と役割

ポイント：担当する業務によって、よく見る設計書が異なります。自分の業務に関係する設計書から優先して読み方を覚えましょう。

業務別：よく使う設計書

設計書を読む前に

1. 目的を明確にする

• なぜこの設計書を読むのか
• どの部分を理解する必要があるか
• いつまでに理解する必要があるか

2. 前提知識を確認する

• システムの全体像は把握しているか
• 関連する用語は理解しているか
• 分からない用語はメモしておく

初心者がつまずきやすいポイント

設計書を読み始めると、多くの初心者が同じような壁にぶつかります。ここではよくある悩みと、その解決方法を紹介します。

「大量のドキュメントから必要な部分が見つからない」

解決策：目次・索引・検索を活用する

flowchart LR
    A[探したい情報] --> B{キーワードは<br>明確?}
    B -->|Yes| C[ファイル内検索<br>Ctrl+F]
    B -->|No| D[目次・索引から<br>当たりをつける]
    C --> E[該当箇所を確認]
    D --> E
    E --> F{見つかった?}
    F -->|No| G[先輩に聞く<br>「○○はどこに書いてありますか？」]
    F -->|Yes| H[内容を確認]

1. まず全体像を把握する

   • ドキュメント一覧があれば目を通す
   • 各ドキュメントの「役割」を理解する（上の表を参考に）
   • 「このドキュメントには何が書いてあるか」を一言で説明できるようになる

2. キーワード検索を活用する

   • 探したい機能名、画面名、テーブル名で検索
   • ファイル横断検索ができるツールがあれば活用
   • 検索でヒットしない場合は、別の言い回しを試す

3. 先輩に「どこを見ればいいか」を聞く

   • 闇雲に探すより、詳しい人に聞いた方が早い
   • 「○○の仕様はどのドキュメントに書いてありますか？」と聞く
   • 一度教えてもらったら、次からは自分で見つけられるようにメモする

「読んでも頭に入らない・覚えられない」

解決策：「覚える」のではなく「引き出しを作る」

1. アウトプットしながら読む

   • 読むだけでなく、自分の言葉でメモを書く
   • 図を自分で書き直してみる
   • 誰かに説明するつもりで読む

2. 実際のコードや画面と照らし合わせる

   • 設計書だけ読んでも抽象的で分かりにくい
   • 動いているシステムを触りながら設計書を読む
   • 「この画面のこの部分は、設計書のここに書いてある」と対応づける

3. 必要になったときに読む

   • 事前にすべて読んで覚えようとしない
   • 実装するときに該当箇所を読む
   • 「使う → 読む → 理解する」のサイクルを回す

❌ 全部読んで覚えてから実装しよう
⭕ 実装しながら必要な部分を読んで理解しよう

「複数のドキュメントのつながりがイメージできない」

解決策：「データの流れ」で考える

ドキュメント間の関係は、データがどう流れるかで考えると分かりやすくなります。

flowchart LR
    subgraph ユーザー操作
        A[画面]
    end
    subgraph フロントエンド
        B[画面設計書]
    end
    subgraph バックエンド
        C[処理設計書]
        D[API仕様書]
    end
    subgraph データベース
        E[ER図]
        F[テーブル定義書]
    end

    A -->|入力| B
    B -->|リクエスト| D
    D -->|処理| C
    C -->|SQL| E
    E --- F
    C -->|レスポンス| D
    D -->|表示| B
    B -->|出力| A

具体例：ユーザー登録機能を理解する場合

このように、1つの機能を軸にして複数のドキュメントを横断的に読むと、つながりが見えてきます。

「膨大なドキュメントの内容をどう把握すればいいか分からない」

解決策：段階的に深掘りする

flowchart TD
    A[レベル1: 概要だけ] --> B[レベル2: 担当範囲]
    B --> C[レベル3: 詳細]

    A1[「どんなドキュメントがあるか」を知る<br>各ドキュメントの役割を1行で言えるようになる]
    B1[「自分が実装する部分」を理解する<br>担当機能に関連する箇所を読み込む]
    C1[「実装に必要な詳細」を調べる<br>具体的な仕様、制約、例外処理を確認]

    A --- A1
    B --- B1
    C --- C1

レベル1：概要（30分〜1時間）

• どんなドキュメントがあるか一覧を確認
• 各ドキュメントをパラパラめくって雰囲気を掴む
• 「〇〇を知りたいときは△△を見る」というマップを頭に作る

レベル2：担当範囲（数時間〜1日）

• 自分が担当する機能に関係する部分を特定
• その部分をしっかり読み込む
• 分からない部分は印をつけて後で確認

レベル3：詳細（必要に応じて）

• 実装中に分からないことが出てきたら都度確認
• エッジケースや例外処理の仕様を調べる
• 関連する他の機能との整合性を確認

設計書の読み方（共通）

1. 全体像を先に把握する

いきなり詳細を読まず、まず全体を把握します。

• 目次を確認：どんな内容が書かれているか
• 図を先に見る：システム構成図、画面遷移図など
• 概要部分を読む：各章の冒頭の説明

2. 自分の担当範囲を特定する

• どこからどこまでが自分の作業範囲か
• 関連する機能はどこに書いてあるか
• 前後の工程との関係は何か

3. 詳細を読み込む

• 自分の担当範囲を重点的に読む
• 処理の流れを追う
• 入力と出力を確認する

4. 疑問点をメモする

• 分からない部分に印をつける
• 質問事項をまとめる
• 矛盾点があれば記録する

flowchart TD
    A[1. 全体像を把握] --> B[2. 担当範囲を特定]
    B --> C[3. 詳細を読み込む]
    C --> D[4. 疑問点をメモ]
    D --> E{不明点あり?}
    E -->|Yes| F[質問・確認]
    E -->|No| G[実装開始]
    F --> G

設計書の種類別ガイド

各設計書の詳しい読み方は、以下の個別ガイドを参照してください。

分からない部分の対処法

1. 自分で調べる

• 用語集を確認
• 関連する設計書を読む
• システムを実際に動かして確認

2. 質問する

すぐに質問せず、まず以下を整理してから質問します。

質問の準備

• どの設計書のどの部分か
• 何が分からないか
• 自分なりの解釈（「〇〇という理解で合っていますか？」）

質問の例

基本設計書の3.2章「ユーザー登録機能」について質問があります。
入力チェックの「メールアドレスの重複チェック」ですが、
これはリアルタイムでチェックするのか、登録ボタン押下時に
チェックするのか、どちらでしょうか？

3. 矛盾を見つけた場合

• 勝手に解釈して進めない
• 必ず確認してから作業する
• 確認結果を記録に残す

設計書を読むときの注意点

バージョンに注意

• 最新版を読んでいるか確認
• 古いバージョンを見ていないか注意
• 更新日時を確認する習慣をつける

設計書は完璧ではない

• 設計書にも誤りや不足がある
• 疑問に思ったら確認する
• 「設計書に書いてあったから」は言い訳にならない

メモを残す

• 自分の理解を書き込む（コピーに）
• 確認した結果を記録する
• 後で見返せるようにする

まとめ

• 設計書は全体像から詳細への順番で読む
• 自分の担当範囲を特定して重点的に読む
• 分からない部分は整理してから質問する
• バージョンに注意し、矛盾があれば確認する
• 詳しい読み方は各設計書の個別ガイドを参照