変更依頼書の書き方|追加要望の範囲・納期・工数への影響を整理する記入例

変更依頼書は、追加要望をそのまま作業へ足すための文書ではありません。現在の合意と変更希望の差分を示し、成果物・データ・納期・工数などへの影響を確認して、変更するかどうかを判断するための文書です。

大切なのは、「変更依頼を受けた」ことと「変更が承認された」ことを分けることです。口頭で「これも追加してほしい」と言われても、その時点で正式に仕事の範囲が変わったとは限りません。この記事では、完全な架空ケースを使い、依頼から影響確認、判断、実施へ進む順番を説明します。

完成例|部署別集計を追加する変更依頼書

次は、社内向け「月次備品使用実績レポート」の作成途中に、部署別集計の追加要望が出た場合の完成例です。会社、人物、部署、データ、判断はすべて架空です。

変更依頼書

依頼日:10月3日
依頼者:レポート利用部門の担当者
判断者:レポート作成責任者

1. 現在の合意内容

9月分の備品使用実績を4カテゴリ別に集計し、8月との差を表にする。提出期限は10月5日15:00。集計と前月比較までを対象とし、部署別分析、原因分析、改善提案は対象外とする。

2. 変更したい内容

4カテゴリ別の集計に加えて、部署別の使用量も集計したい。

比較 内容
変更前 カテゴリ別集計+8月との比較
変更後候補 カテゴリ別集計+8月との比較+部署別集計

3. 変更理由

関係者から、部署ごとの使用傾向も確認したいという要望が出たため。

4. 変更によるメリット・目的

部署ごとの使用量を確認できる状態にする。部署間の差が生じた原因の分析や改善提案までを今回実施するかは、別途判断する。

5. 影響範囲

  • 成果物:部署別集計の表が1つ増える
  • 対象データ:9月データには部署情報がある。8月データは部署情報が一部不足している
  • 作業手順:部署名の確認、部署別集計、元データとの照合が追加で必要
  • 担当者:現在の作成担当者が対応できるか確認が必要
  • 納期:現在の10月5日15:00を維持できるか確認が必要
  • 関連資料:レポートの表構成と説明文に変更が必要
  • 後続作業:関係者への配布前に、部署別集計の対象と不足データの扱いを確認する必要がある

6. 納期・工数への影響

部署情報の確認、追加集計、照合作業が増える。現期限を維持できるかは未確認。実測や見積もりの根拠がないため、追加時間や延長日数はこの時点では数値化しない。

7. 対応案

案 変更範囲 期限への影響 不明点
案A 当初範囲のまま提出し、部署別集計は別作業にする 10月5日15:00の提出を維持する 部署別集計をいつ、誰が行うか
案B 9月分だけ部署別集計を追加し、8月比較はカテゴリ別のみとする 現期限を維持できるか最終確認する 9月の部署情報に欠損がないか
案C 9月・8月とも部署別比較を追加する 期限の見直しが必要か確認する 8月の不足情報を補えるか、補完確認を誰が行うか

8. 未確認事項

  • 8月データの部署情報を補えるか
  • 現期限を維持できるか
  • 部署別比較を今回の提出で必須とするか
  • 対象にする部署と、兼務者などの集計ルールをどうするか

9. 判断結果

判断:案Bを条件付き承認
条件:9月分だけ部署別集計を追加し、8月の部署別比較は行わない。9月データの部署情報を確認したうえで、期限は10月5日15:00を維持する。欠損が見つかり期限維持が難しい場合は、着手範囲を再確認する。
判断日:10月3日

この判断結果も架空です。「承認」「条件付き承認」「保留」「今回は実施しない」などの選択肢は記録例であり、すべての職場に共通する正式なステータス体系ではありません。

今回の架空ケース

当初の仕事は、9月分の備品使用実績を4カテゴリに分け、8月との差を表にすることです。提出期限は10月5日15:00で、原因分析や改善提案、部署別分析は対象外でした。

作業途中で「カテゴリ別だけでなく、部署別の集計も追加してほしい」という要望が出ます。しかし、まだ対象部署、元データの状態、過去月との比較方法、期限への影響、判断者が確定していません。この段階は変更要望を受けた状態であって、変更済み・承認済みではありません。

そこで、変更前後の差分、影響、複数の対応案、未確認事項を1枚に整理し、レポート作成責任者が案Bを条件付き承認した、という流れにしています。

変更依頼書に書く9項目

  1. 現在の合意内容
  2. 変更したい内容
  3. 変更理由
  4. 変更によるメリット・目的
  5. 影響範囲
  6. 納期・工数への影響
  7. 対応案
  8. 未確認事項
  9. 判断結果

必要に応じて、依頼者、判断者、依頼日、判断日を補います。項目を増やすこと自体が目的ではありません。判断に必要な差分と影響が追える範囲に絞ります。

1. 現在の合意内容を書く

変更点を示すには、変更前の基準が必要です。成果物、対象、期限、今回しないことを短く書きます。今回なら「9月分」「4カテゴリ」「8月との差」「10月5日15:00」「部署別分析は対象外」が基準です。

仕事を始める前に対象・対象外・完了条件を整理する方法は、スコープとは?仕事の対象・対象外・完了条件の決め方で確認できます。スコープの記事は開始前の境界を決めるもの、今回の変更依頼書は決めた後に変更希望が出たときの差分と影響を判断するものです。

2. 変更したい内容を差分で書く

「部署別も追加する」のように、何が増えるのかを現在の合意と対比します。

  • 変更前:カテゴリ別集計+前月比較
  • 変更後候補:カテゴリ別集計+前月比較+部署別集計

ここでは「変更後」と確定形で書かず、「変更後候補」としています。影響確認と判断が終わる前に、承認済みの変更として扱わないためです。対象部署、集計単位、比較対象月など、読み手によって解釈が変わる点も具体化します。

3. 変更理由と目的を分ける

変更理由は、変更希望が生じた背景です。目的・期待する状態は、変更によって何を確認できるようにしたいかです。

項目 今回の記載
変更理由 関係者から部署別の使用状況を確認したいという要望が出た
期待する状態 部署ごとの使用量を確認できる

「必要だから」だけでは、背景や判断材料が分かりません。一方、要望が出たという事実だけで、変更の効果があると決まるわけでもありません。原因分析や改善提案まで必要なら、それも今回の変更範囲に含めるか別途判断します。

4. 影響範囲を確認する

変更希望が出たら、次の観点から影響の有無を確認します。

  • 成果物
  • 対象データ
  • 作業手順
  • 担当者
  • 納期
  • 関連資料
  • 後続作業

変更があれば、必ずすべてに影響するわけではありません。「影響なし」と確認できた項目は、その結果を残せます。今回の例では、表、対象データ、照合手順、納期などを確認しますが、現在の担当者を変えない可能性もあります。

元データに部署情報がなければ、集計方法だけ決めても作業できません。9月と8月でデータの持ち方が異なる場合は、同じ条件で比較できるかも確認します。不足情報を推測で埋めず、補完可否を未確認事項として残します。

5. 納期・工数への影響を確認する

追加作業には、対象確認、集計、照合、表の追加、説明文の修正などが考えられます。ただし、変更があれば必ず納期が延びる、必ず工数が増えるとは断定できません。既存データや作業方法によっては、現在の期限内で対応できる場合もあります。

根拠がないまま具体的な追加時間、延長日数、増加率を置かず、作業を分解して担当者へ確認します。見積もり前なら「追加確認が必要」「作業量が増える可能性がある」「期限維持可否を確認する」と記録します。

6. 対応案を複数作る

追加要望に対して、全面対応するか断るかの二択にしないことが大切です。今回なら、当初範囲を守って別作業にする案、今月分だけ追加する案、前月分まで比較して期限を見直す案があります。

各案は、変更範囲、期限への影響、不明点を同じ軸で比べます。判断者は、必要性と実行条件を見ながら、承認、条件付き承認、保留、今回は実施しない、といった判断を選べます。選択肢の名称や正式な承認方法は職場のルールに合わせてください。

7. 未確認事項を残す

変更依頼書を完成させるために、不明点をもっともらしく埋める必要はありません。判断前に確認することと、判断後の実施前に確認することを分けて残します。

今回の未確認事項は、8月データの部署情報を補えるか、現期限を維持できるか、部署別比較を今回必須とするか、対象部署をどう定義するか、です。「要確認」と書くことで、判断に使った前提と残っている不確実性を見分けられます。

8. 判断者と判断結果を記録する

依頼内容だけで終えると、結局どの案になったのかが分かりません。誰が、いつ、どの案を、どの条件で判断したかを記録します。

今回の架空例では、レポート作成責任者が案Bを条件付き承認し、9月分だけ部署別集計を追加します。8月の部署別比較は実施せず、期限は10月5日15:00を維持します。ただし、9月データの確認結果によって期限維持が難しい場合は、勝手に進めず範囲を再確認します。

変更依頼を受けてもすぐ着手しない

変更依頼を提出したことは、変更してよいという承認ではありません。また、口頭で要望を受けたことも、正式に仕事の範囲が変わったことを意味しません。

影響確認と判断が終わる前に、変更作業へ着手しません。承認された範囲と条件だけを実施対象にします。

基本の順番は、次のとおりです。

  1. 依頼:何を変えたいか、理由と目的を記録する
  2. 影響確認:成果物、データ、手順、担当、納期、関連資料、後続作業を確認する
  3. 判断:対応案と未確認事項を見て、判断者が可否や条件を決める
  4. 実施:承認された範囲と条件に沿って作業する

変更依頼書を提出したあとも、判断結果が「保留」や「今回は実施しない」になることはあります。職場に正式な決裁・承認方法がある場合は、そのルールを優先してください。

小さな変更もすべて記録するのか

表の列幅、誤字、意味が変わらない表記統一など、軽微な修正は職場の運用によって簡易対応できる場合があります。すべての修正に正式な変更依頼書が必要とは限りません。

一方で、対象範囲、納期、成果物、判断基準、担当、外部への提出条件が変わる場合は、変更内容と判断を残す価値が高くなります。変更の大きさだけでなく、後から合意内容を確認する必要があるかで判断します。

レビュー依頼・スコープ・マニュアル更新との違い

文書・作業 中心となる役割
スコープ整理 仕事を始める前に、対象・対象外・成果物・完了条件を決める
変更依頼書 決めた後に変更希望が出たとき、差分と影響を整理して変更可否を判断する
レビュー依頼 作成済み成果物の誤り、抜け、分かりやすさなどを確認してもらう
業務マニュアル更新 実施が決まった変更を、既存文書へ反映し、旧版・周知まで扱う

たとえば、「表の見出しが分かりにくい」は既存成果物へのレビュー指摘です。「新しく部署別集計も追加してほしい」は、合意済みの範囲を変える変更依頼の候補です。ただし、職場によって文書名や運用名は異なり、レビュー指摘と変更依頼を必ず別文書にしなければならないわけではありません。

作成済み資料について確認箇所・期限・回答方法を伝える場合は、レビュー依頼メールの書き方を参照してください。変更依頼書は変更可否を決める前に使い、変更決定後に定常手順や関連資料を直す段階では、業務マニュアルの更新方法へ進みます。変更判断の回答が来ない場合の再確認は、催促・リマインドメールの書き方と役割が異なります。

コピーして使える変更依頼書テンプレート

次のひな形をコピーし、職場の承認方法や対象業務に合わせて調整してください。

【変更対象】
現在の合意内容:

【変更希望】
変更したい内容:
変更前:
変更後候補:

【変更理由】
理由:

【期待する状態】
変更後に確認したいこと:

【影響】
成果物:
対象データ:
作業手順:
担当:
納期:
関連資料:
後続作業:

【納期・工数への影響】
追加で必要な確認・作業:
期限維持可否:

【対応案】
案A:
案B:
案C:

【未確認事項】

【判断】
判断者:
判断結果:
条件:
判断日:

提出前に、現在の合意、変更前後の差分、理由と期待する状態、影響、複数の対応案、未確認事項を確認します。判断後は、承認された案と条件だけを実施対象にします。

まとめ

変更依頼書は、追加要望を無条件に受け入れるための文書ではありません。現在の合意と変更希望の差分を示し、影響と対応案を確認して、判断できる状態を作る文書です。

  1. 現在の合意内容を基準にする
  2. 変更したい内容を差分で示す
  3. 変更理由と期待する状態を分ける
  4. 成果物、データ、手順、担当、納期、関連資料、後続作業への影響を確認する
  5. 根拠のない工数や延長日数を作らず、対応案を複数比べる
  6. 未確認事項を残し、判断者・判断結果・条件を記録する

変更依頼の提出=変更の承認ではありません。依頼、影響確認、判断、実施の順に進み、職場に正式な承認手順がある場合はそのルールを優先してください。

タイトルとURLをコピーしました