要件変更管理のやり方｜Excel・CSVの差分比較と変更履歴の残し方

結論：要件の変更管理は「差分の検出」と「変更の承認」を分ける

要件定義書の版管理で最初に整えるべきものは、高価なシステムよりも比較できるデータ構造です。要件に変わらないIDを振り、旧版と新版のCSVを保存すれば、追加・削除・変更の候補を検出できます。しかし、**値が変わった事実**と、**その変更を採用してよいか**は別問題です。担当者・影響先・承認者を人が確認する運用を残してください。

変更管理に必要な7つの項目

要件一覧は最低限、要件ID、要件名、要件詳細、ステータス、担当者、優先度、版番号を列として保持します。承認記録には別途、変更理由、申請者、影響範囲、承認者、承認日を持たせます。版番号はファイルに、要件IDは個々の要件に付けると意味が異なるため、混同しないようにします。

Excelで比較する前に旧版を凍結する

例として、2026年11月1日承認済みの要件一覧を「承認済みベースライン」とし、同月10日の最新版を比較します。元ファイルを上書きすると、後から「何が変わったのか」を再現できません。旧版のファイル名、保存場所、承認者、ハッシュや版番号など、誰でも同じ旧版を特定できる情報を残します。ファイルの命名は「プロジェクト名_要件一覧_v1.2_承認済.csv」のようにします。

追加・削除・変更を同じIDで突き合わせる

旧版に要件 R-010「通知はメールのみ」、R-020「申請者が履歴を見る」があり、新版では R-010「メールとアプリ内通知」、R-030「管理者がCSVを出力」に変わったと仮定します。この場合、R-010は変更、R-020は削除候補、R-030は追加です。これは説明用の架空の要件であり、製品の実測結果ではありません。 行番号で比較してしまうと並べ替えがすべて変更に見えるため、**一意の要件ID**で結合します。同じIDが2行ある、空欄がある、旧版にだけ存在する場合は、勝手に解釈せずエラー・要確認として扱います。

Excel関数だけで確認する場合の注意点

小規模ならXLOOKUPやCOUNTIFを使って旧版IDの存在と主要列の値を確認できます。ただし、要件名だけをキーにすると改題が削除と追加に誤判定されます。関数が比較している対象列、全角・半角、前後の空白、改行コード、数式と表示値の違いを先に決めてください。Excelの列数が増えるほど、担当者・ステータス・期限などの差を見落としやすいため、変更列を一覧化できる形が望ましいです。

CSVの比較前処理で誤検出を減らす

UTF-8などの文字コード、列見出し、引用符、日付形式を合わせます。比較前に空白を削る場合、削ってよい列と、空白自体に意味がある列を区別します。順番が変わっただけの行や、表記ゆれによる差を、直ちに業務仕様変更と見なさないことが重要です。

変更管理票に残す具体例

上のR-010の変更であれば、「変更ID＝CHG-004」「要件ID＝R-010」「旧値＝メールのみ」「新値＝メールとアプリ内通知」「理由＝ユーザー通知経路の追加」「影響＝UI、配信処理、通知設定、テスト」「申請者＝業務担当」「承認者＝責任者」「判定＝要承認」と記録します。 影響は申請時点の仮説であり、開発・テスト担当の確認で更新します。差分を列挙しただけで承認済みにしないことが、障害や手戻りを防ぐ基本です。

変更の影響を5方向で確認する

変更ごとに、①業務手順と利用者、②画面・入力項目、③データ項目・連携・帳票、④権限・通知・セキュリティ、⑤テスト・運用マニュアルを点検します。たとえば通知経路を増やす変更は、単に画面ラベルを直すだけでは終わりません。通知先設定、エラー時の再送、既存利用者への扱い、個人情報の表示範囲に影響する可能性があります。

レビュー会議前に作る差分サマリー

承認者向けには「追加件数、削除候補件数、変更件数、重要変更の概要、未確認ID、影響確認の担当者、承認待ち件数」を一枚にまとめます。件数の合計が合うか、削除候補を本当に削除するのか、承認済みの内容を最新版へ取り込んだかを記録し、決定事項と宿題を分けます。

比較手段は件数と再現性で選ぶ

数件の要件変更ならExcelの比較表で十分な場合があります。毎週複数の版を比較し、変更列を追跡したいなら、同じルールで繰り返せるCSV差分ツールを検討します。AIで変更理由を推測させると便利な場面もありますが、根拠のない推測を実際の変更理由や承認と混ぜてはいけません。 自社ツールのReqDeltaにはブラウザ上でCSV/TSVの旧版と新版を比較する無料デモがあります。データの機密区分やブラウザの実行環境を確認したうえで試してください。実装仕様や買い切り版の提供範囲は製品ページで確認できます。

よくある失敗と対処

「同じ要件IDを振り直す」場合は正確な差分を追えません。「最新版だけ保存する」場合は監査・障害対応で元の意思決定に戻れません。「差分検出＝承認済み」と扱う場合は業務責任者の判断が消えます。「削除を取り消しと同義にする」場合は実装済み・廃止済み・未着手の扱いを誤るため、状態を分けます。

まとめ：まず小さな一覧で比較ルールを固める

最初から大規模な要件管理ツールへ移すのではなく、10〜30件の架空の要件でID重複、追加、削除、変更、承認の各ケースを確認します。差分と変更理由を分離でき、別の担当者が同じ結果を再現できれば、本番の要件変更管理へ広げる土台になります。

導入・購入前の最終確認

• 自分の用途と必要機能が一致しているか
• 無料期間終了後を含む総コストを確認したか
• データ・アカウントの扱いを確認したか
• 解約・返品・移行条件を公式情報で確認したか