第3部:ドキュメントスキル / 第1章:読み書きの基本

設計書・仕様書の読み方

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

📖 読了目安 約20分 対象:設計書を読む必要がある方

設計書の種類と役割

プロジェクトで使用される設計書はさまざまです。まずは主な設計書の種類と、それぞれどんなタイミングで使用されるのかを把握しましょう。

種類内容読むタイミング詳細
要件定義書何を作るか(システムの目的・機能)プロジェクト理解時要件定義書の読み方
基本設計書(外部設計書)画面・機能の設計実装前基本設計書の読み方
詳細設計書(内部設計書)プログラムの処理内容実装時基本設計書の読み方
画面設計書画面のレイアウト、項目、動作UI実装時画面設計書の読み方
処理設計書バックエンドの処理内容ロジック実装時処理設計書の読み方
クラス図クラスの構造と関係設計理解時クラス図の読み方
ER図データベースの構造DB操作時ER図の読み方
テーブル定義書テーブルの詳細仕様DB操作時テーブル定義書の読み方
API仕様書APIのエンドポイント、リクエスト、レスポンスAPI連携時API仕様書の読み方
処理フロー図処理の流れを図で表現ロジック理解時処理フロー図の読み方
状態遷移図オブジェクトの状態変化ステータス管理時状態遷移図の読み方
テスト仕様書テストの内容・手順テスト時試験仕様書の読み方
運用マニュアル運用時の手順運用・保守時-

ポイント

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

業務別:よく使う設計書

あなたの業務内容によって、必要になる設計書が異なります。以下の表を参考に、自分が最初に集中して学ぶべき設計書を特定しましょう。

業務内容よく使う設計書
フロントエンド実装画面設計書、API仕様書
バックエンド実装処理設計書、ER図、API仕様書
テスト実施テスト仕様書、画面設計書
データベース操作ER図、テーブル定義書
設計担当クラス図、ER図、画面設計書、処理設計書

設計書を読む前に

効率的に設計書を読むには、いきなり内容を読み始めるのではなく、事前準備が重要です。以下の2つを確認しましょう。

1. 目的を明確にする

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

2. 前提知識を確認する

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

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

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

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

よくある悩み

ドキュメントが何十ファイルもあって、どこに何が書いてあるか分からない。探すだけで時間がかかってしまう。

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

flowchart LR
    A[探したい情報] --> B{キーワードは
明確?} B -->|Yes| C[ファイル内検索
Ctrl+F] B -->|No| D[目次・索引から
当たりをつける] C --> E[該当箇所を確認] D --> E E --> F{見つかった?} F -->|No| G[先輩に聞く
「○○はどこに書いてありますか?」] 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画面設計書どんな入力項目があるか、入力チェックは何か
2API仕様書画面からどんなリクエストが送られるか
3処理設計書リクエストを受けてどんな処理をするか
4テーブル定義書どのテーブルにどんなデータが保存されるか

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

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

よくある悩み

ドキュメントの量が多すぎて、全体像が掴めない。どこから手をつけていいか分からない。

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

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

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

設計書の種類別ガイド

ここで紹介した基本的な読み方を踏まえた上で、各設計書の詳しい読み方は以下の個別ガイドを参照してください。

設計書内容リンク
要件定義書システムの目的、機能要件、非機能要件要件定義書の読み方
基本設計書・詳細設計書システム構成、画面遷移、処理詳細基本設計書の読み方
画面設計書レイアウト、項目定義、入力チェック、ボタン動作画面設計書の読み方
処理設計書API仕様、処理フロー、エラー処理、使用テーブル処理設計書の読み方
クラス図クラス構造、継承、関連、メソッドクラス図の読み方
ER図テーブル構造、リレーション、主キー・外部キーER図の読み方
テーブル定義書カラム定義、データ型、制約、インデックステーブル定義書の読み方
API仕様書エンドポイント、リクエスト、レスポンスAPI仕様書の読み方
処理フロー図フローチャート、シーケンス図、アクティビティ図処理フロー図の読み方
状態遷移図状態、遷移、トリガー、ステータス管理状態遷移図の読み方
テスト仕様書テスト観点、テストケース、期待結果試験仕様書の読み方

分からない部分の対処法

設計書を読んでいると、必ず分からないことが出てきます。そのときの対処法を3つのステップで紹介します。

1. 自分で調べる

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

2. 質問する

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

質問の準備

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

質問の例

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

3. 矛盾を見つけた場合

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

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

バージョンに注意

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

設計書は完璧ではない

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

メモを残す

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

まとめ

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