システム設計書の基本｜読み方・更新方法・差分確認

「設計書のページ数が多く、どこから読めばよいか分からない」

「プログラムは修正したが、どの設計書まで更新すべきだろう」

システム開発・保守では、設計書を読む仕事と書く仕事の両方があります。新人SEや若手SEのうちは、資料の量と用語の多さに圧倒され、上から順番に読んでも全体像をつかめないことがあります。

設計書は、単に仕様を記録した文書ではありません。関係者が同じ前提で開発・テスト・運用を行うための基準です。プログラムと設計書が一致していなければ、次の改修や障害調査で誤った判断につながります。

私も銀行システムの開発・保守に25年以上携わるなかで、設計書の小さな不整合が、大きな手戻りにつながる場面を見てきました。反対に、変更理由と影響範囲が整理された設計書は、レビューや引き継ぎを大きく助けてくれます。

この記事では、システム設計書の基本を次の3つに分けて解説します。

1. 目的と処理の流れを押さえて読む
2. 変更理由と関連資料を含めて更新する
3. 差分を意図と照らし合わせて確認する

設計書は「業務・処理・データ」のつながりで理解する

一つの設計書だけでシステム全体を理解できるとは限りません。業務要件、画面・API、処理ロジック、データ、外部連携が、複数の資料へ分かれて記載されているからです。

資料の種類	主に確認すること
業務要件・要件定義	誰が、何のために使う機能か
基本設計	画面、帳票、外部IF、業務ルール
詳細設計	処理順序、分岐、編集、エラー処理
データベース設計	テーブル、項目、キー、制約
運用設計	監視、ジョブ、障害時対応、保管

分からない記述があったら、その場で推測せず、上位資料や関連設計書へ戻ります。設計書同士の関係を意識すると、個別の項目が何のために存在するか理解しやすくなります。

1．目的と処理の流れを押さえて読む

設計書を最初から細部まで読むと、情報量が多くなりがちです。まず、資料の目的、対象範囲、前提条件を確認し、その後で処理の流れを追います。

目次・改訂履歴・用語を先に確認する

• 目次：どの情報がどこに記載されているか
• 改訂履歴：いつ、なぜ、どこが変更されたか
• 対象範囲：この資料に含む機能と含まない機能
• 用語・略語：プロジェクト固有の意味
• 関連資料：前提となる上位・下位資料

改訂履歴を見ると、現在の仕様がどの変更案件で追加されたか分かることがあります。背景を知ると、単なる項目の暗記ではなく、設計意図を理解できます。

正常系から異常系へ処理を追う

1. 入力は何か
2. どの条件で処理が分岐するか
3. どのデータを参照・更新するか
4. 外部システムへ何を送受信するか
5. 正常時に何を返すか
6. エラー時に何を記録し、どう終了するか

文章だけで理解しづらい場合は、処理の入口と出口、主な分岐を簡単にメモします。すべてを書き写すのではなく、理解のために情報を絞るのがポイントです。

不明点は「記載なし」と「理解不足」を分ける

設計書に書かれていないのか、別の資料に書かれているのか、自分が読み取れていないのかを区別します。質問するときは、確認した資料とページ、分からない点、自分の解釈を添えます。

「画面設計書の入力チェック欄と詳細設計書の分岐を確認しましたが、未入力時のエラーコードが見つかりません。共通エラー定義を使用する認識でよいでしょうか」

2．変更理由と関連資料を含めて更新する

設計書を更新するときは、修正したページだけでなく、同じ仕様を記載している関連資料も確認します。画面項目を一つ追加するだけでも、画面設計、入力チェック、データ項目、メッセージ、テスト仕様などへ影響する可能性があります。

変更前に影響範囲を洗い出す

変更内容	関連資料の例
画面項目の追加	画面一覧、項目定義、入力チェック、DB設計、テスト仕様
API項目の変更	IF仕様、電文定義、呼出元・呼出先設計、エラー定義
テーブル項目の追加	ER図、テーブル定義、CRUD、移行設計、運用手順
バッチ条件の変更	処理設計、ジョブネット、運用時刻、監視設計

資料一覧やトレーサビリティ表がある場合は活用します。ない場合でも、機能名、項目名、テーブル名などで文書を横断検索すると、関連箇所を見つけやすくなります。

「何を」だけでなく「なぜ」を残す

改訂履歴には、変更日と変更箇所だけでなく、案件名や変更理由を記録します。数年後の担当者が見ても、意図をたどれる状態が理想です。

本文では、実装方法だけでなく、業務ルール、前提条件、例外条件を明確にします。特に「場合による」「必要に応じて」といった表現は、誰が何を基準に判断するのか具体化します。

設計書と実装を同じ変更単位で管理する

プログラムを先に直し、設計書を後でまとめて更新すると、変更漏れが起きやすくなります。設計、実装、テストの成果物を同じ課題番号や変更番号で関連付け、完了条件に設計書更新を含めます。

3．差分を意図と照らし合わせて確認する

差分確認は、変更箇所があることを確認するだけではありません。「必要な箇所がすべて変わり、変更不要な箇所は変わっていないか」を確認する作業です。

変更一覧と差分を対応付ける

• 変更要件ごとに対象資料と対象箇所を一覧化する
• 差分ツールや変更履歴で実際の修正箇所を確認する
• 一覧にあるのに差分がない箇所を確認する
• 一覧にない差分が混ざっていないか確認する

書式変更や自動更新による差分が大量に出ると、本来確認すべき変更が埋もれます。可能な限り、内容変更と書式変更を分けます。

前後関係と横並びも確認する

一行だけ修正しても、同じ条件を使う別の説明、表、図が古いまま残ることがあります。変更箇所の前後、同じ項目を記載した一覧、正常系と異常系の対応を確認します。

レビューでは、誤字脱字だけでなく、要件との一致、実装可能性、テスト可能性、運用への影響という観点で見ます。判断できない箇所は、曖昧なまま承認せず質問として残します。

設計書で避けたい3つの失敗

1．一つの設計書だけで判断する

上位資料や関連資料に前提が書かれている場合があります。資料間の関係を確認してから判断します。

2．プログラムに合わせて理由なく設計書を直す

実装が正しいとは限りません。要件、設計、実装のどこに誤りがあるかを確認し、承認された方針に従って更新します。

3．変更箇所だけを見て更新漏れを見逃す

同じ情報が表、図、別章、別資料へ重複している場合があります。影響範囲を一覧化し、横断的に確認します。

設計書確認メモのテンプレート

【変更の目的】
案件・課題番号：
変更理由：

【対象】
対象機能：
対象設計書・ページ：
関連する設計書：

【変更内容】
変更前：
変更後：
前提・例外条件：

【影響】
実装：
データ：
外部連携：
運用：
テスト：

【差分確認】
必要な差分：
意図しない差分：
未確認・質問事項：

若手SE向け設計書チェックリスト

• 目次、改訂履歴、対象範囲、関連資料を確認した
• 業務目的と正常系の処理の流れを説明できる
• 入力、分岐、データ、外部連携、出力、エラー処理を確認した
• 変更に関係する設計書を横断的に洗い出した
• 変更内容だけでなく変更理由を残した
• 変更一覧と実際の差分を対応付けた
• 意図しない差分と更新漏れを確認した

まとめ：設計書は読む・更新する・差分を見るまでが一つ

システム設計書は、開発・テスト・運用の共通基準です。情報を受け取る資料として読むだけでなく、変更後も正しい状態を保つことが重要です。

• 読むときは目的と処理の流れから全体像をつかむ
• 更新するときは変更理由と関連資料への影響を確認する
• 差分確認では必要な変更と意図しない変更の両方を見る

分からない記述に出会ったときは、確認した資料と自分の解釈を整理して相談しましょう。その積み重ねが、設計書を読み解く力と、変更を安全に進める力につながります。

現場で役立つ開発・保守の基本へ戻る