「プログラムを修正したが、どの設計書まで更新すべきか分からない」
「変更箇所は直したのに、別の表が古いままだった」
設計書の更新は、修正したページの文章を直すだけではありません。要件、画面、データ、インターフェース、運用、テストなど、同じ変更に関係する資料を洗い出し、整合させる作業です。
変更理由を残さずに実装へ合わせると、将来の保守担当者は、なぜその仕様になったのか判断できません。また、実装側が誤っている場合に、設計書まで誤りへ合わせる危険があります。
長期運用される金融システムでは、設計書は次の改修や障害調査の基準になります。小さな変更でも、正しい情報を維持することが保守性につながります。
この記事では、変更要求から影響調査、更新、レビュー、完了確認までの実務手順を解説します。
設計書更新は「変更理由」と「影響範囲」から始める
最初に、何をなぜ変えるのか、変更しない範囲はどこかを明確にします。そのうえで、実装やテストに先行または同期して、関連資料を更新します。
設計書、プログラム、テスト仕様のどれを正とするかは案件ルールに従い、不一致があれば承認者へ確認します。
| 観点 | 確認内容 | 成果物 |
|---|---|---|
| 理由 | 要件・障害・法令・改善のどれか | 変更要求、課題番号 |
| 範囲 | 機能・データ・連携・運用・非対象 | 影響一覧 |
| 整合 | 上位・下位・横並び資料との一致 | 更新対象一覧 |
| 履歴 | 変更前後・理由・承認 | 改訂履歴、差分 |
| 検証 | 実装・テストで確認可能か | レビュー記録、テスト観点 |
設計書を更新する5ステップ
1．変更要求と正しい仕様を確認する
課題票、要件、問い合わせ、障害報告など、変更の起点を確認します。口頭依頼だけで更新せず、変更理由と承認者が分かる情報へ結び付けます。
現行設計と実装が違う場合は、どちらを直すべきかを確認します。実装が動いているから正しいとは限りません。
2．関連資料を影響一覧へ出す
変更する機能を中心に、画面、API、DB、バッチ、外部連携、運用、テストへ影響を広げます。同じ項目名やステータスを検索し、重複記載を探します。
更新不要と判断した資料も、理由を一覧へ残すとレビューで確認しやすくなります。
- 要件・業務フロー
- 基本設計・詳細設計
- 画面・帳票・メッセージ
- テーブル・コード定義
- インターフェース・ジョブ
- 運用手順・監視
- テスト仕様・移行手順
3．変更前・変更後・理由をセットで更新する
本文だけでなく、改訂履歴、図表、注記、サンプル、エラーコード一覧も確認します。変更理由は課題番号や要件番号へリンクできる形にします。
曖昧な表現を避け、入力条件、処理、結果を第三者が実装・テストできる粒度で書きます。
変更前：振込金額が上限を超えた場合はエラーとする。 変更後：1日累計振込金額が利用者別上限を超えた場合、E1234を表示し、取引データを登録しない。 変更理由：要件REQ-045の上限管理変更 関連更新：画面メッセージ、業務チェック、コード定義、テスト仕様
4．差分レビューで意図しない変更を除く
更新前後の差分を確認し、変更一覧と一致するかを見ます。自動書式変更や表の再配置が大量に混ざると、内容差分を見落としやすくなります。
レビューでは誤字だけでなく、要件との一致、実装可能性、テスト可能性、運用影響を確認します。
5．実装・テスト・リリース版との整合を確認する
レビュー後の最終版が、実装した仕様とテストした仕様に一致しているか確認します。修正途中の版や未承認版が共有フォルダに残る場合は、正式版を明確にします。
リリース後に設計書更新を回す運用では、期限と担当を明確にし、更新漏れを管理します。
設計書更新管理表のテンプレート
資料ごとの更新要否と完了状態を一覧で管理します。
【変更概要】 課題・要件番号： 変更理由： 変更対象・非対象： 【更新一覧】 資料名／章・ページ／更新要否／変更内容／担当／レビュー／状態 【整合確認】 要件： 実装： テスト： 運用： 【残課題】 未確定事項： リリース後更新： 正式版の保存場所：
設計書の更新漏れは、その場では動作に影響しなくても、次の改修や障害対応で大きなコストになります。
よくある失敗と改善方法
| 失敗 | 起こる問題 | 改善方法 |
|---|---|---|
| 変更ページだけを直す | 別表・別資料に古い定義が残る | 影響一覧で横断的に確認する |
| 理由なく実装へ合わせる | 誤実装を正式仕様にしてしまう | 要件・承認者へ正を確認する |
| 改訂履歴だけで完了する | 実装・テストとの不整合が残る | 最終版で三者の整合を確認する |
若手SE向けチェックリスト
- 変更理由と承認元を確認した
- 変更対象・非対象を明確にした
- 関連資料を影響一覧へ出した
- 変更前・変更後・理由を記載した
- 改訂履歴・図表・コード一覧も確認した
- 差分レビューで意図しない変更を除いた
- 要件・実装・テスト・正式版の整合を確認した
まとめ：設計書更新は将来の保守担当者への引き継ぎ
設計書の更新では、今回の変更を正しく反映するだけでなく、なぜ変えたか、どこへ影響したかを次の担当者が追えるようにします。
小さな変更ほど更新漏れが起きやすいため、影響一覧と差分レビューを使い、仕組みとして確認しましょう。
- 変更理由と正しい仕様を確認する
- 関連資料を影響一覧で洗い出す
- 差分と実装・テストの整合を確認する
コメント