仕様変更の管理方法 変更管理表テンプレートと変更要求フロー

仕様変更の管理とは、合意済みの仕様を変える依頼を1件ずつ記録し、影響を調べ、決められた人が判定してから反映する手順のことです。 必要な道具は2つだけで、1件ごとの内容を書く「変更要求書」と、全件を一覧にする「変更管理表（台帳）」です。

この記事では、その2つのテンプレートをMarkdownとタブ区切りで載せ、架空の変更3件を起票から判定まで記入した例を示します。受付からクローズまでのフロー、影響調査の書き方、変更か不具合かの切り分け、規模別の承認者の基準、依頼者への回答文例までを1本にまとめました。

確認環境：Mermaid のコードは @mermaid-js/mermaid-cli 11.14.0 で描画できることを確かめました。台帳の集計式は LibreOffice Calc 24.2（ヘッドレス実行）で再計算し、工数と費用の計算は Python 3.11 でも検算しています。

仕様変更の管理の早見表

変更要求のフロー（受付からクローズまで）

全体の流れをMermaidのフローチャートで示します。

flowchart TD
    A["1. 起票<br>変更要求書を書く"] --> B["2. 受付<br>番号を採り台帳に登録"]
    B --> C{"切り分け<br>変更・不具合・仕様確認"}
    C -->|"不具合"| X["不具合管理へ"]
    C -->|"仕様確認"| Y["質問票で回答"]
    C -->|"変更"| D["3. 影響調査<br>工数・日程・費用・品質・成果物"]
    D --> E{"4. 判定<br>規模に応じた承認者"}
    E -->|"承認"| F["5. 反映<br>設計書・コード・テストを更新"]
    E -->|"保留"| G["次回の判定へ持ち越し"]
    E -->|"却下"| H["理由を回答"]
    G --> E
    F --> I["確認<br>依頼者が結果を確かめる"]
    I --> J["6. クローズ<br>台帳を更新"]
    H --> J

このフローで大切なのは2点です。1つ目は、口頭やチャットで受けた依頼も必ず起票してから動くこと。 記録のない変更は、あとで「いつ・誰が・なぜ」をたどれなくなります。2つ目は、影響調査の前に切り分けること。 不具合や仕様の確認は扱う手順が違うので、入口で分けておくと台帳がすっきりします。

状態遷移

台帳の「状態」欄に入れる値と、その移り変わりです。

stateDiagram-v2
    state "起票" as s1
    state "受付済み" as s2
    state "影響調査中" as s3
    state "判定待ち" as s4
    state "承認" as s5
    state "保留" as s6
    state "却下" as s7
    state "反映中" as s8
    state "確認待ち" as s9
    state "クローズ" as s10
    [*] --> s1
    s1 --> s2: 番号を採る
    s2 --> s3: 変更と切り分け
    s2 --> s10: 不具合・仕様確認へ移す
    s3 --> s4: 調査結果を記入
    s4 --> s5: 承認者が承認
    s4 --> s6: 情報が足りない
    s4 --> s7: 見送り
    s6 --> s4: 再提出
    s5 --> s8: 作業を開始
    s8 --> s9: 反映が完了
    s9 --> s8: 差し戻し
    s9 --> s10: 依頼者が確認
    s7 --> s10: 理由を回答
    s10 --> [*]

変更・不具合・仕様確認の判定早見表

受付で最初に行うのが切り分けです。基準は「合意済みの仕様書にどう書いてあるか」の1点です。

仕様確認の結果、すでに作ったものを直す必要が出た場合は、その時点で変更要求として起票し直します。入口の種類と出口の扱いが変わることを台帳の備考に書いておくと、経緯をたどれます。

変更要求書のテンプレート

1件につき1枚を使います。上半分を依頼者が、下半分を調査と判定の担当が書きます。

表計算ソフトや文書に貼る場合のタブ区切りです。

項目  記入内容
番号  
起票日 
依頼者 
件名  
現在の仕様   
変更したい内容 
理由・目的   
希望時期    
優先度 
種別  
影響：工数（人日）   
影響：日程   
影響：費用（円）    
影響：品質   
影響する成果物 
代わりの案   
判定  
判定理由    
判定日・承認者 
反映先 
クローズ日   

影響調査の書き方

影響調査は、工数・日程・費用・品質・影響する成果物の5つの観点で書きます。承認者が知りたいのは「受け入れると何がどれだけ動くか」なので、数字と成果物の名前で具体的に示します。

影響する成果物の一覧表

成果物は一覧表にして、直すものに○、直さないものに「―」を付けます。「―」も書くことで、確かめたうえで影響がないと判断したことが伝わります。

工程ごとにまとめ直すと、設計1.0人日（要件定義書・基本設計書・詳細設計書・テーブル定義書）、実装2.5人日（ソースコードと単体テスト）、テスト2.0人日（結合テスト）、文書0.5人日（操作説明書）となり、合計は同じ6.0人日です。

調査で見落としやすい箇所

記入例：架空の変更3件を起票から判定まで

題材は、社内の図書貸出システムです。小・中・大の3件を、起票から判定までたどります。費用は1人日40,000円と仮定して計算しています。

CR-001：貸出期間の延長機能を追加（中規模・承認）

CR-002：返却期限の通知メールの文面を変更（小規模・承認）

CR-003：蔵書検索に表紙画像を表示（大規模・保留）

3件を並べると、規模によって調査の深さと承認者が変わることがわかります。CR-002のような小さな変更まで会議にかけると判定が滞るので、次の基準表で扱いを分けます。

規模別の承認者の基準表

基準は立ち上げのときに発注側と受注側で合意し、計画書に載せておきます。次の数値は一例です。

工数・日程・費用のうち、いちばん大きい区分に合わせるのが原則です。工数が0.5人日でもリリース日が動くなら「大」として扱います。

変更管理表（台帳）のテンプレート

全件を1行ずつ並べた一覧です。変更要求書の内容から、状況の把握に必要な項目だけを抜き出します。

番号  起票日 件名  依頼者 種別  優先度 状態  工数(人日)  費用(円)   日程への影響(営業日) 判定  判定日 承認者 反映先 クローズ日
CR-001  2026-10-01  貸出期間の延長機能を追加    利用部門 佐藤 変更  中   クローズ    6   240000  3   承認  2026-10-06  発注側担当 鈴木    リリース1.1 2026-10-28
CR-002  2026-10-05  返却期限の通知メールの文面を変更    利用部門 佐藤 変更  低   クローズ    0.5 20000   0   承認  2026-10-05  PM 田中   リリース1.0 2026-10-09
CR-003  2026-10-08  蔵書検索に表紙画像を表示    利用部門 高橋 変更  中   保留  16  640000  10  保留  2026-10-15  変更管理会議  次期で再判定  

日程への影響の欄には、希望どおりの時期に入れた場合に動く営業日数を書いています。CR-001は反映先をリリース1.1にしたため、初回リリース日は動いていません。

台帳の集計式

タブ区切りをA1に貼ると、データは2行目から4行目に入ります。次の数式で、件数と累計を出せます（結果は LibreOffice Calc 24.2 で再計算した値）。

承認した変更の工数の累計は、定例で毎回見せる数字にします。 小さな変更も積み重なると大きくなるため、累計が予備の工数に近づいたら、以降の変更の優先度を発注側と一緒に見直すきっかけになります。

回答文例

依頼者への返事は、判定の結果・理由・次に起きることの3点を入れると伝わりやすくなります。

受付の連絡

件名：【変更要求 CR-001】受付のご連絡

佐藤様

「貸出期間の延長機能を追加」のご依頼を、番号 CR-001 として受け付けました。
これから影響調査を行い、10月6日の定例で結果をご報告します。
調査にあたり、次の1点を教えてください。
・延長できる回数は1回まででよいでしょうか。

影響調査の結果の提示

件名：【変更要求 CR-001】影響調査の結果

佐藤様

CR-001 の影響調査の結果をお知らせします。

・工数：6.0人日（設計1.0、実装2.5、テスト2.0、文書0.5）
・費用：240,000円
・日程：初回リリースに含める場合、結合テストの開始が3営業日後ろへ動きます。
　　　　リリース1.1に含める場合、初回リリース日は変わりません。
・品質：貸出・返却の結合テスト12項目を再実施し、延長の8項目を追加します。
・代わりの案：窓口の担当者だけが延長できる形であれば、3.5人日で対応できます。

10月6日の定例で、対応の時期と範囲をご相談させてください。

承認の連絡

件名：【変更要求 CR-001】承認のご連絡

佐藤様

CR-001 は、10月6日の定例で承認されました。
・対応時期：リリース1.1
・内容：予約のない本に限り、利用者が画面から1回だけ14日間延長できる
反映が済みましたら、確認の手順を添えてご連絡します。

保留の連絡

件名：【変更要求 CR-003】判定結果のご連絡

高橋様

CR-003「蔵書検索に表紙画像を表示」は、10月15日の変更管理会議で保留となりました。
・理由：初回リリース日が10営業日後ろへ動くこと、画像の用意の方法が決まっていないこと
・今後：次期の計画で、画像の用意の方法とあわせてあらためて判定します
初回リリースは、現在の仕様（書名・著者・状態の表示）で進めます。

不具合として扱う場合の連絡

件名：【お問い合わせ】不具合として対応します

佐藤様

ご連絡いただいた「6冊目が借りられる」件は、要件定義書 3.1節（貸出上限5冊）と
異なる動きのため、仕様変更ではなく不具合として修正します。
追加の費用は発生しません。修正の予定は不具合管理表でお知らせします。

仕様確認として扱う場合の連絡

件名：【お問い合わせ】仕様の確認のお願い

高橋様

「貸出上限に達した利用者が予約できるか」は、現在の仕様書に記載がありませんでした。
次のどちらにするかを教えてください。
・案1：上限に達していても予約できる
・案2：上限に達している間は予約できない
現在の実装は案1です。案2をご希望の場合は、変更要求として影響を調査します。

変更管理を回し続けるコツ

よくある質問

Q. 変更管理表と変更要求書は、両方とも必要ですか？ A. 役割が違うので両方あると便利です。変更要求書は1件の詳しい記録、変更管理表は全件の状況を見渡す一覧です。件数が少ないうちは、変更管理表の列を増やして1つにまとめても運用できます。

Q. 影響調査の工数は誰が負担しますか？ A. 契約や取り決めによります。立ち上げのときに「何人日までの調査は通常の作業に含める」と決めておくと、調査のたびに相談せずに済みます。

Q. 急ぎの変更で、判定の会議を待てない場合はどうしますか？ A. 緊急時の手順を先に決めておきます。たとえば「PMと発注側担当がその場で承認し、次の定例で報告する」という形です。この場合も、起票と台帳への記録は省きません。

Q. 承認された変更を、あとで取り消したいと言われたら？ A. 取り消しも1件の変更として起票します。すでに行った作業の工数と、元に戻すための工数の両方を影響調査に書きます。

まとめ

• 仕様変更は、起票・受付・影響調査・判定・反映・クローズの6段階で管理する
• 入口で、変更・不具合・仕様確認を切り分ける。基準は合意済みの仕様書の記載
• 影響調査は、工数・日程・費用・品質・影響する成果物の5観点を数字と成果物名で書く
• 成果物の一覧表には、直さないものも「―」で載せると、確かめた範囲が伝わる
• 承認者は規模で分ける。小さな変更はPM、リリース日が動く変更は変更管理会議
• 台帳では、承認した工数の累計を数式で出し、定例で共有する
• 回答には、判定の結果・理由・次に起きることを入れる

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。