業務委託でエンジニアに開発を依頼していると、プロジェクトの途中で「この機能も追加でお願いしたい」「仕様を少し変えたい」という要望は必ずと言ってよいほど出てきます。社内の関係者から次々と寄せられる要望に応えようと、つい軽い気持ちで口頭で変更を伝えてしまった——という発注担当者は少なくありません。
ところが、その口頭での依頼が後から想定外の追加費用請求につながり、エンジニアと気まずい関係になってしまうことがあります。「ちょっとした変更のつもりだった」「お金を払っているのだから対応してもらえると思っていた」という発注側の感覚と、「当初の契約範囲を超える作業だった」というエンジニア側の認識がすれ違うと、双方に不満が残ります。
ここで誤解してほしくないのは、変更そのものが悪いわけではないという点です。開発を進めながら要件が変わっていくのは自然なことで、むしろ良いプロダクトを作るためには変更が必要な場面もあります。問題なのは、変更を「管理しないまま進めてしまうこと」です。発注側に根強くある「お金を払っているのだから多少の追加は当然」という思い込みが、エンジニアとの信頼関係を静かに損なっていきます。
業務委託の業務内容変更は、変更依頼書の作成 → 影響評価 → 費用・納期の合意 → 契約変更という決まった手順に乗せれば、費用トラブルを防ぎながらスムーズに進められます。手順を踏むことは堅苦しい手続きを増やすことではなく、発注側が安心して変更を依頼でき、エンジニアも納得して対応できる状態をつくるための仕組みです。
本記事では、業務委託エンジニアへの業務内容変更を、トラブルなく進めるための具体的な手順と、口頭依頼を避けるためのコミュニケーション設計を、発注担当者の視点で解説します。
業務委託の業務内容変更でトラブルが起きる本当の理由
業務委託の業務内容変更がトラブルに発展するのは、担当者個人のミスというより、変更を扱う仕組みそのものが整っていないことに原因があります。まずは、なぜトラブルが起きるのかを構造から理解しておきましょう。
業務委託で最も多いトラブルは「業務範囲の認識違い」
業務委託で発生するトラブルの典型例が「業務範囲の認識違い」です。発注側は「このくらいは当然やってもらえる範囲」と考え、エンジニア側は「これは契約に含まれていない追加作業」と考える。この線引きのズレが、費用や納期をめぐる対立の火種になります。
認識違いが起きやすいのは、契約書に業務範囲が具体的に書かれていない場合や、プロジェクトの進行中に当初想定していなかった作業が次々と発生する場合です。最初は小さなズレでも、それが積み重なると「想定外の追加費用を請求された」「頼んだはずの作業をやってもらえない」という大きな不満につながります。
スコープクリープとは何か
業務範囲がなし崩し的に少しずつ広がっていく現象を「スコープクリープ」と呼びます。「クリープ（creep）」は「じわじわ忍び寄る」という意味で、一つひとつは小さな変更でも、それが積み重なることで当初の業務範囲を大きく超えてしまう状態を指します。
スコープクリープの厄介なところは、明確な決定の瞬間がないまま進行することです。「これくらいなら」と一つ追加し、また「ついでにこれも」ともう一つ追加する。個々の追加は小さいため誰も問題視しませんが、気づいたときには当初の見積もりと実際の作業量が大きくかけ離れています。スコープクリープの仕組みや現場での判断基準については、スコープ・スコープクリープとは？プロジェクト現場での判断基準と対策でも詳しく解説しています。
発注側が陥りがちな2つの誤解
スコープクリープを招く背景には、発注側がもちやすい2つの誤解があります。
ひとつめは「お金を払っているのだから、多少の追加は当然対応してもらえる」という誤解です。業務委託契約は、あらかじめ合意した業務範囲に対して報酬を定めるものです。報酬は「契約範囲の作業」への対価であり、範囲を超えた追加作業まで自動的にカバーするものではありません。
ふたつめは「小さな変更なら口頭で伝えれば十分」という誤解です。小さな変更ほど書面に残さず口頭で済ませがちですが、口頭の依頼は「言った・言わない」の食い違いを生みやすく、費用の合意も曖昧なまま作業が進んでしまいます。
この2つの誤解を放置したまま変更を重ねると、エンジニア側は無償に近い形で追加作業を抱え込み、発注側は後から請求を受けて「話が違う」と感じる。双方にとって不幸な結果になります。トラブルを防ぐ第一歩は、この誤解を解き、変更を正式なプロセスに乗せることだと理解することです。
業務内容の変更には当事者双方の「合意」が必要
業務内容を変更する手順に入る前に、押さえておきたい前提があります。それは「締結済みの契約は、一方の意思だけでは変更できない」というルールです。
契約内容は一方的に変更できない
一度締結した業務委託契約の内容は、発注側・受託側のどちらか一方が「変えたい」と思っても、それだけで変更できるものではありません。契約の変更には、当事者双方の合意が必要です。
これは発注側にとって重要なポイントです。「発注している側だから、業務内容は自由に指示できる」というものではなく、当初の契約範囲を超える変更は「お願いして合意を取るもの」と考える必要があります。逆に言えば、エンジニア側も勝手に作業内容を変えることはできません。変更は双方が納得して初めて成立する、という対等な関係が前提になっています。
当初の業務範囲を超える作業は追加費用の対象になり得る
当初契約で合意した報酬は、その時点で想定していた業務範囲を前提に決められています。したがって、その前提を超える作業をエンジニアに依頼する場合、追加の報酬が発生し得ます。
ここで注意したいのは、追加作業を依頼したからといって、後から自動的に追加報酬が認められるわけではないという点です。「追加作業について、いくらで対応するという合意が成立していた」と確認できなければ、追加費用の請求は難しくなります。これは一見、発注側に有利に思えるかもしれませんが、実際には逆です。費用の合意が曖昧なまま作業を進めると、エンジニア側は「請求できるか分からない作業」を抱えて不信感を募らせ、発注側も後から想定外の請求を受けるリスクを抱えることになります。書面で合意を残すことは、発注側・受託側の双方を守る手続きなのです。
フリーランス保護新法による一方的な変更・追加要請の制限
2024年11月1日に施行された「特定受託事業者に係る取引の適正化等に関する法律（フリーランス・事業者間取引適正化等法）」（以下、フリーランス保護新法）も、業務内容の変更に関わってきます（政府広報オンライン）。
この法律では、フリーランスに業務を委託する発注事業者に対して、契約期間が1か月以上の業務委託において一定の禁止行為が定められています。その一つが「不当な給付内容の変更・やり直し」です。これは、フリーランス側に責任がないにもかかわらず、発注側が費用を負担しないまま仕事内容を変更させたり、やり直しをさせたりして、フリーランスの利益を不当に害する行為を指します（公正取引委員会 フリーランス法特設サイト）。
つまり「追加費用を払わずに業務内容を変えてもらう」という進め方は、契約上のトラブルになるだけでなく、法律違反として問われる可能性があるということです。変更を正式な手順に乗せ、費用を含めて合意することは、コンプライアンスの観点からも欠かせない対応になっています。
業務委託エンジニアへの業務内容変更の正しい手順
ここからは、業務内容の変更を費用トラブルなく進めるための具体的な手順を、5つのステップに分けて解説します。各ステップで「誰が・何を・どの書面で行うか」を意識すると、自社のプロジェクトにそのまま当てはめやすくなります。
ステップ1｜社内の変更要望を整理し「変更依頼書」にまとめる
最初のステップは、社内から出てきた変更要望を、発注窓口の担当者が一度整理することです。
プロジェクトが進むと、社内のさまざまな関係者から「この機能も欲しい」「ここの仕様を変えたい」という声が上がります。これらをそのままエンジニアに流してしまうと、要望が断片的に伝わり、優先順位もつかないまま作業だけが膨らみます。そこで、寄せられた要望を窓口担当が受け止め、「変更の背景」「具体的に何を変えたいのか」「いつまでに必要か」を整理した「変更依頼書」にまとめます。
変更依頼書は法的な契約文書ではなく、社内とエンジニアの間で変更内容の認識をそろえるための運用ツールです。この段階で要望を文書化しておくことで、以降のステップがスムーズに進みます。
ステップ2｜エンジニアに影響評価を依頼する
変更依頼書ができたら、それをエンジニアに渡し、変更が及ぼす影響を評価してもらいます。
発注側だけでは「この変更にどれだけの工数がかかるか」「既存のスケジュールにどう影響するか」を正確に判断できません。エンジニアに、追加で必要となる工数、納期への影響、想定される追加費用を見積もってもらいます。
このステップを飛ばして「とりあえず進めてほしい」と作業を始めてしまうと、後から費用や納期の話が出てきて折り合いがつかなくなります。影響評価は、変更を判断するための材料を集める工程だと位置づけてください。
ステップ3｜費用・納期・優先順位を協議し合意する
影響評価の結果が出たら、その内容をもとに費用・納期・優先順位を協議します。
ここで重要なのは、変更が「当初スコープの範囲内」なのか「範囲外の追加作業」なのかを線引きすることです。範囲内であれば追加費用は発生しませんが、範囲外であれば追加費用や納期の延長について合意する必要があります。
あわせて確認したいのが、変更によって既存のタスクにしわ寄せが及ばないかという点です。新しい作業を追加すれば、その分だけ他の作業に使える時間は減ります。「この変更を入れる代わりに、別の機能のリリースを後ろ倒しにする」といった優先順位の調整も、この段階で双方が納得して決めておきます。
ステップ4｜変更内容を契約変更として正式化する
費用・納期・優先順位について合意できたら、その内容を契約変更として正式な書面にします。
ステップ1で作成した変更依頼書は社内・エンジニア間の合意形成のための運用文書であり、それ自体に契約としての拘束力はありません。合意した変更を確実なものにするため、変更契約書または覚書を作成して締結します。変更箇所が少なければ覚書、大規模な変更であれば新規の契約書を作り直すという判断になりますが、いずれにせよ「書面で締結する」ことが欠かせません。
ステップ5｜変更履歴を記録し、関係者に共有する
最後のステップは、変更の経緯と内容を記録し、関係者に共有することです。
「いつ、どのような変更を、どういう理由で行ったか」「費用と納期はどう変わったか」を一覧にして残しておくと、後から「この機能はいつ決まったのか」「なぜこの費用になっているのか」という疑問が出たときにすぐ確認できます。
特に、プロジェクトに途中から関わるメンバーや、社内の決裁者に経緯を説明する場面では、変更履歴があるかどうかで説明のしやすさが大きく変わります。変更を正式化したら記録に残すところまでをワンセットにすることで、後の認識ズレを防げます。
変更依頼書・変更契約書の書き方
手順の中で登場した「変更依頼書」と「変更契約書・覚書」は、役割が異なる2種類の書面です。それぞれに何を書けばよいかを具体的に見ていきましょう。
変更依頼書に書くべき項目
変更依頼書は、社内とエンジニアの間で変更内容の認識をそろえるための運用文書です。決まった書式があるわけではありませんが、次の項目を盛り込んでおくと過不足なく伝わります。
- 変更の背景: なぜこの変更が必要になったのか（例: ユーザーからの要望、社内方針の変更など）
- 変更内容: 具体的に何を、どう変えたいのか。曖昧な表現を避け、エンジニアが作業をイメージできる粒度で書く
- 希望納期: いつまでに対応してほしいか
- 影響評価欄: エンジニアが追加工数・納期影響・追加費用を記入するための欄
最後の影響評価欄を設けておくと、変更依頼書をそのままエンジニアとのやり取りに使えます。発注側が前半を記入して渡し、エンジニアが影響評価欄を埋めて返す、という流れにすると、一つの書面で手順のステップ1からステップ3までをカバーできます。
変更契約書・覚書の書き方
変更契約書・覚書は、合意した変更内容に法的な拘束力をもたせる正式文書です。次の要素を必ず盛り込みます。
- 原契約の特定: どの契約を変更するのかを明確にする。当初の業務委託契約の契約名・締結日・当事者などを記載して特定する
- 変更条項: 当初の契約のどの条項を、どのように変更するのかを具体的に書く。業務範囲・報酬・納期など、変更する項目をもれなく記載する
- 効力発生日: 変更内容がいつから有効になるのかを明記する
- 収入印紙: 業務委託契約が請負契約に該当する場合など、変更契約書・覚書も課税文書として収入印紙が必要になることがあります。記載された契約金額によって印紙税額が変わるため、契約の性質と金額に応じて要否と金額を確認します
覚書で足りるケースと新規契約書を作り直すケースの判断基準
変更を文書化する際、「覚書で足りるのか、契約書を作り直すべきか」で迷うことがあります。判断の目安は変更の規模です。
変更箇所が限定的で、当初契約の一部条項を修正する程度であれば、覚書で対応できます。覚書は、原契約を活かしたまま変更点だけを追記・修正する形の文書です。
一方、変更の範囲が広く、業務範囲や報酬体系が大きく変わって当初契約の全体像が変わってしまうような場合は、覚書を重ねるよりも新規の契約書を作り直したほうが、契約内容が分かりやすくなります。覚書が何枚も積み重なると、最終的にどの条件が有効なのかを追うのが難しくなるためです。「現時点での契約内容を一目で把握できる状態を保てるか」を基準に判断するとよいでしょう。
口頭依頼によるトラブルを防ぐコミュニケーション設計
ここまでの手順を知っていても、現場では「ちょっとした変更だから口頭で伝えれば早い」となりがちです。手順の知識を「現場で実際に守られる仕組み」に変えるには、コミュニケーションの設計が欠かせません。
なぜ口頭の変更依頼はトラブルになるのか
口頭での変更依頼が危険なのは、3つの理由があります。
ひとつめは「言った・言わない」の食い違いです。口頭でのやり取りは記録に残らないため、後から「そう頼んだはずだ」「そんな依頼は受けていない」という対立が起きやすくなります。
ふたつめは費用合意の欠落です。口頭で「これもお願い」と伝えるとき、費用の話まで丁寧にする発注担当者は多くありません。費用が曖昧なまま作業が進み、後から請求段階で初めて金額が表面化します。
みっつめは追加作業の無償化です。費用合意のないまま作業が進むと、エンジニア側は「請求しづらい」と感じ、追加作業を無償で抱え込みがちになります。これはエンジニアの不満を蓄積させ、信頼関係を静かに損なっていきます。
変更要望の窓口を一本化する
口頭依頼を防ぐ第一の工夫は、変更要望の窓口を一本化することです。
社内の複数の関係者がそれぞれ直接エンジニアに要望を伝えると、要望が断片的に流れ、変更依頼書を介さないまま作業が始まってしまいます。「エンジニアへの依頼は必ず窓口担当を通す」というルールを社内で徹底し、窓口担当が要望を受け止めて変更依頼書に整理してから渡す形にします。窓口を一本化するだけで、口頭での場当たり的な依頼の多くを防げます。
「変更依頼として扱う」を即座に伝える習慣
要望が出てきた時点で、その場で「これは変更依頼として扱います」と伝える習慣をつけることも有効です。
打ち合わせや雑談の中で「ついでにこれもできる？」という話が出たとき、その場で「では変更依頼書にまとめて、影響評価をお願いします」と返す。こうすると、変更が口頭のまま流れることがなくなり、自然と書面化のプロセスに乗ります。重要なのは、変更を断ることではなく、「変更は正式な手順で扱う」という共通認識をその場で確認することです。
定例ミーティングで変更とスコープを確認する
週次などの定例ミーティングの場で、その期間に発生した変更要望と現在のスコープを確認する時間を設けると、変更管理が習慣として定着します。
定例の中で「今週こういう変更要望が出たが、変更依頼として進めるか」「現時点のスコープと当初契約のズレはないか」を双方で確認すれば、スコープクリープが進行する前に気づけます。変更管理は一度の手続きで終わるものではなく、プロジェクトを通じて継続的に行うものだと捉えることが大切です。
まとめ｜変更管理を仕組み化し、エンジニアとの信頼関係を守る
業務委託の業務内容変更は、プロジェクトを進めるうえで避けられないものです。重要なのは、変更そのものをなくすことではなく、変更を「管理されない状態」のまま進めないことです。
本記事で解説した進め方を、あらためて整理します。
- トラブルの原因を理解する: 業務委託トラブルの多くは「業務範囲の認識違い」から生まれ、スコープクリープと発注側の2つの誤解（「追加は当然」「口頭で十分」）がそれを加速させます
- 変更には双方の合意が必要: 契約は一方的に変更できず、当初範囲を超える作業は追加費用の対象になり得ます。フリーランス保護新法でも、費用負担のない一方的な業務内容変更は禁止行為とされています
- 5つのステップで進める: 変更依頼書の作成 → 影響評価の依頼 → 費用・納期・優先順位の協議 → 変更契約書・覚書による正式化 → 変更履歴の記録、という手順に乗せます
- 2種類の書面を使い分ける: 社内・エンジニア間の合意形成には変更依頼書を、法的な拘束力をもたせるには変更契約書・覚書を使います
- コミュニケーションを設計する: 窓口の一本化、変更依頼として扱う習慣、定例での確認によって、手順を現場で守られる仕組みに変えます
変更管理を仕組みとして導入することは、堅苦しい手続きを増やすことではありません。発注側にとっては想定外の費用請求を防ぐことにつながり、エンジニアにとっては正当な対価のもとで安心して作業できる環境につながります。透明な変更管理は、費用トラブルの予防とエンジニアとの良好な関係の双方を支える土台になります。
業務委託エンジニアのマネジメント全般について、コミュニケーション設計・品質管理・チーム運営まで体系的に学びたい方には、「業務委託エンジニアのマネジメント実践ガイド」のお役立ち資料も用意しています。あわせて参考にしてみてください。
