追加機能の発注を後出しにすると起きる摩擦｜仕様変更管理表を使う進め方 2026

「思っていたより、追加費用がかさんでしまった」。追加機能を発注したあとに仕様変更が重なり、こうした戸惑いを感じている方は少なくありません。私は産業カウンセラーとして、フリーランスや外注先とのやり取りに疲れてしまった方のご相談を受けることが多いのですが、実は発注する側にも同じような疲弊が起きています。追加機能の発注と仕様変更は、進め方を知っているかどうかで、費用も、相手との関係も、大きく変わってきます。今日は、その進め方を一緒に整理していきましょう。

大丈夫です。仕様変更そのものは特別なトラブルではありません。むしろ、開発や制作の現場ではごく普通に起きることです。問題は「起きること」ではなく「起きたときにどう扱うか」を決めていないことにあります。この記事では、追加機能の発注でなぜ摩擦が生まれるのか、その構造を丁寧に解きほぐしながら、仕様変更管理表という具体的な道具を使った進め方までお伝えします。

追加機能の発注で仕様変更が起きるのは珍しくない

まず知っておいていただきたいのは、仕様変更はシステム開発や制作案件において、ごく一般的な現象だということです。

仕様変更は、システム開発においてほぼ不可避のものです。実際、ある調査によると、システム開発プロジェクトの約80%で当初の仕様から何らかの変更が発生しているとされています。

出典: note.com

つまり、10件のプロジェクトのうち8件で、当初の想定から何かしらの変更が生じているということです。これは開発側の見積もりが甘いから起きるのではなく、発注者自身が「実際に動くものを見て初めて気づく」ことが多いためです。頭の中でイメージしていた完成形と、実際に形になったものとの間には、どうしてもズレが生まれます。

このズレに気づいたとき、「じゃあ、ここも直してほしい」「この機能も追加してほしい」という声が自然に出てくるのは、発注者として当然の反応です。問題は、この声を「思いついたそのタイミングで、口頭や雑なメッセージで伝えてしまう」ことにあります。これが後出しの追加依頼となり、外注先との間に摩擦を生む最大の原因になります。

追加機能の発注が「後出し」になりやすい理由

追加機能の発注が後出しになる背景には、いくつかの共通した心理があります。

一つ目は、最初の要件定義の段階では「何が必要か」を発注者自身が完全には把握できていないことです。特にシステムやアプリのような形のないものを発注する場合、実際に触ってみるまで、何が足りないかに気づけないのは自然なことです。

二つ目は、予算の都合上、最初は最小限の機能に絞って発注し、後から必要な機能を追加していくという進め方をとる方が多いことです。これ自体は決して悪い戦略ではありません。ただし、その場合は「後から追加が発生する前提」であることを、発注時点で外注先と共有しておく必要があります。

三つ目は、社内やチーム内の意思決定が遅れることです。上司や他部署からの要望が後になって届き、それを受けて発注者が外注先に追加を依頼するというケースも多くあります。この場合、発注者自身も板挟みになりやすく、精神的な負担が大きくなりがちです。

仕様変更でなぜ追加費用が発生するのか

追加機能の発注や仕様変更で最も気になるのが、費用の話でしょう。ここでは、なぜ追加費用が発生するのか、その構造を具体的に見ていきます。

最終的に請求額は「500万円 + 追加費用200万円 = 700万円」となり、当初見積もりの1.4倍になりました。発注者は「こんなに増えるとは思っていなかった」と困惑しますが、ベンダー側は「仕様変更に対応した分を請求しています」と説明します。

出典: syusodo.co.jp

このケースは大規模なシステム開発の例ですが、小規模な制作案件やフリーランスへの発注でも、同じ構造の摩擦が起きます。当初の見積もりの1.4倍というのは決して珍しい数字ではなく、仕様変更を管理せずに進めると、これくらいの上振れは十分に起こり得ます。

原因1：最初の見積もりに「変更対応の余白」がない

見積もりというのは、決まった仕様に対してかかる工数を積算したものです。仕様変更が発生するということは、その積算の前提が崩れるということです。多くの外注先は、最初の見積もりに変更対応の余白を含めていません。そのため、変更が発生するたびに、追加の工数として別立てで請求されることになります。

これは外注先が悪意を持って請求しているわけではなく、当然の会計処理です。ただ、発注者側からすると「追加費用」という形で突然費用が積み上がっていくように見えてしまい、不信感につながりやすいのです。

原因2：手戻りのコストが二重にかかる

仕様変更で厄介なのは、追加した機能の分だけ費用がかかるのではなく、すでに作った部分をやり直す「手戻り」のコストが発生することです。例えば、後から入力フォームの項目を追加したいと依頼した場合、そのフォームを使っている他の画面や、データベースの設計、テストの項目まで見直しが必要になることがあります。

このため、見た目には小さな追加依頼であっても、実際の作業量は想定以上に膨らむことがあります。私自身、初めて外注をお願いしたとき、この手戻りの概念を知らずに「ちょっとしたお願い」のつもりで追加を依頼し、想像していた金額の何倍もの見積もりが返ってきて驚いた経験があります。悪意があったわけではなく、単純に私の理解が足りなかったのです。

原因3：口頭やチャットでの依頼が「言った言わない」を生む

追加依頼を口頭やチャットの雑談的なやり取りで伝えてしまうと、後から「そんな依頼をした覚えがない」「それは含まれている前提だと思っていた」という食い違いが起きやすくなります。文書として残していない依頼は、外注先にとっても対応の優先度をつけにくく、結果的に対応漏れや、逆に想定外の追加請求につながることがあります。

追加機能の発注で失敗しないための進め方

ここからは、追加機能を発注する際に、摩擦や追加費用のトラブルを避けるための具体的な進め方をお伝えします。

進め方1：最初の発注時に「スコープ」を明文化する

スコープとは、今回の発注でどこまでを実施するかという業務範囲のことです。発注書や契約書に「今回の対応範囲」を具体的に書き出しておくことが、後々のトラブルを防ぐ最も基本的な対策になります。

例えば、Webサイト制作であれば「トップページ、会社概要ページ、お問い合わせページの3ページを、指定のデザインカンプに基づいて実装する」といったように、対象物・ページ数・機能の有無を具体的に書きます。逆に「〇〇のような機能があれば嬉しい」という曖昧な要望は、スコープに含めるかどうかを事前にはっきりさせておく必要があります。

進め方2：仕様変更が起きた際のルールを契約時に決めておく

スコープを明文化しても、仕様変更が全く起きないわけではありません。大切なのは、変更が起きたときにどう扱うかのルールを、あらかじめ決めておくことです。

具体的には、次のような項目を契約書や発注書に盛り込んでおくと安心です。

・仕様変更の申請方法（書面またはチャットの専用スレッドなど） ・変更内容の見積もりを何営業日以内に提示するか ・変更による納期への影響をどう扱うか ・軽微な変更（誤字修正など）は無償対応とする範囲

これらを事前に決めておくことで、実際に変更が発生したときに、感情的な言い争いにならず、淡々と手続きを進めることができます。

進め方3：仕様変更管理表を使って可視化する

私がカウンセリングの中でもお伝えしている、実務的で効果の高い方法が「仕様変更管理表」の活用です。これは特別なツールを使わなくても、表計算ソフト一つで作れる簡単な管理表です。

管理表には、次のような列を用意します。

・依頼日 ・依頼内容 ・依頼者（誰が言い出したか） ・追加費用の見積もり ・納期への影響 ・承認者のサイン（メールでの承認でも可） ・対応状況（未着手・対応中・完了）

追加機能を依頼するたびに、この表に1行ずつ記録していきます。口頭やチャットでの依頼であっても、必ずこの表に転記してから正式に依頼するというルールにするだけで、「言った言わない」の食い違いはほぼなくなります。

💡 実務上のポイント：納期が固定されている場合は、仕様変更の範囲を限定するか、追加のリソース（人員など）を投入するための費用を発注者が負担する必要があります。

出典: note.com

この指摘の通り、納期を変えずに追加機能を詰め込もうとすると、どこかにしわ寄せが行きます。仕様変更管理表を使うことで、「この追加を入れると納期はどう変わるか」を、発注者と外注先の双方が同じ表を見ながら合意できるようになります。感覚での交渉ではなく、記録に基づいた話し合いができることが、この管理表の一番の価値です。

進め方4：追加依頼はまとめて出す

思いついたタイミングでその都度追加を依頼すると、外注先の作業が何度も中断され、そのたびに調整コストがかかります。可能であれば、追加の要望はいったん自分の中でリストアップし、週に1回など決まったタイミングでまとめて外注先に伝えるようにすると、双方にとって負担が少なくなります。

急ぎの修正が必要な場合は個別に伝える必要がありますが、「あったらいいな」程度の要望は、まとめて出す習慣をつけることをおすすめします。

追加機能の発注にかかる費用相場

追加機能の発注にあたって気になるのが、実際にどれくらいの費用がかかるのかという点です。ここでは目安となる相場感をお伝えします。

Webサイトへのちょっとした機能追加（フォームの項目追加、簡単な表示切り替えなど）であれば、1万円から5万円程度が目安です。一方、会員機能やAPIとの連携、決済機能の追加など、システム的に規模の大きい追加になると、10万円から50万円以上になることもあります。

費用の内訳としては、実装にかかる工数だけでなく、次のような要素が含まれます。

・要件のヒアリングや仕様の再確認にかかる時間 ・既存部分の手戻り対応 ・追加後のテスト工数 ・ドキュメントの更新

こうした内訳を意識せずに「この機能を足すだけなのに、なぜこんなに高いのか」と感じてしまう方も多いのですが、見た目以上に工数がかかる背景を理解しておくと、外注先とのやり取りがスムーズになります。

仲介会社を通す場合と直接依頼する場合の費用差

追加機能の発注を、制作会社や開発会社を通じて依頼する場合と、フリーランスへ直接依頼する場合とでは、費用の構造が異なります。

仲介会社やエージェント経由で依頼すると、実際に作業する人への報酬に加えて、仲介手数料や管理費が上乗せされます。この上乗せ分は案件の規模にもよりますが、20%から40%程度になることも珍しくありません。つまり、同じ作業内容であっても、間に会社を挟むかどうかで、支払う総額に大きな差が生まれる可能性があります。

一方、フリーランスへ直接依頼する場合は、この中間マージンが発生しないため、同じ予算でより多くの作業を依頼できる、あるいは同じ作業内容をより低い費用で依頼できる可能性があります。手数料0%で発注者と受注者を直接つなぐ仕組みを使えば、仲介コストがそのまま浮く分、追加機能の予算にも余裕が生まれやすくなります。

ただし、直接依頼には注意点もあります。仲介会社が担っていた進行管理や品質チェックの役割を、発注者自身がある程度担う必要が出てくるという点です。このため、直接依頼をする場合こそ、先ほどお伝えした仕様変更管理表のような仕組みを自分たちで用意しておくことが、より重要になります。

メリットとデメリットを整理する

追加機能の発注や仕様変更の進め方について、メリットとデメリットを整理しておきましょう。

仕様変更管理表を導入するメリットは、まず費用の透明性が上がることです。何にいくらかかっているのかが記録として残るため、後から振り返ったときに納得感があります。また、外注先との信頼関係が保たれやすいことも大きなメリットです。感情的な言い争いではなく、記録に基づいた冷静な話し合いができるようになります。

一方でデメリットとしては、管理表を作成し、毎回記入する手間がかかることが挙げられます。特に小規模な依頼が多い場合、いちいち記録するのは面倒に感じるかもしれません。ただし、この手間は「言った言わない」のトラブルが起きたときにかかる精神的な負担や、修正のためのやり取りにかかる時間と比べれば、はるかに小さいものです。

私自身、外注をお願いする中で、最初は「そこまで細かく記録しなくても」と思っていた時期がありました。ですが、ある案件で「そんな依頼はしていない」と行き違いが起きたことをきっかけに、簡単な記録を残す習慣に変えました。それからは、追加の依頼をするたびに気持ちが軽くなったのを覚えています。記録があるというだけで、安心して依頼できるようになるのです。

よくある失敗例

追加機能の発注でよくある失敗例を二つご紹介します。

一つ目は、「ついでにこれもお願いできますか」という軽い言い方で追加を依頼し続けた結果、気づけば当初の見積もりの何倍もの作業量になっていたケースです。一つひとつは小さな依頼でも、積み重なると大きな負担になります。小さな依頼であっても、必ず記録に残し、費用感を都度確認する習慣が大切です。

二つ目は、外注先を変更する際に、以前の依頼内容や仕様変更の履歴が引き継がれず、新しい外注先が同じ手戻りを繰り返してしまったケースです。仕様変更管理表のような記録があれば、外注先が変わっても、これまでの経緯をスムーズに共有できます。

外注先選びで意識したいポイント

追加機能の発注や仕様変更にきちんと対応してくれる外注先を選ぶには、いくつかのポイントがあります。

まず、契約段階で仕様変更のルールについて質問したときに、明確に答えてくれるかどうかを見てください。「そのときに相談しましょう」と曖昧にする相手より、「変更が発生した場合はこういう手順で進めます」と具体的に説明できる相手のほうが、後々のトラブルが少ない傾向にあります。

また、見積もりの内訳を細かく提示してくれるかどうかも重要な判断材料です。一式いくらという大まかな見積もりしか出さない相手より、工程ごとに費用を分けて説明してくれる相手のほうが、追加が発生したときの費用感も予測しやすくなります。

こうした観点は、業務委託契約書の作り方｜発注者向けテンプレート付きでも詳しく触れていますが、契約書の段階でスコープと変更ルールを明文化しておくことが、追加機能の発注をスムーズに進める土台になります。加えて、フリーランスを守る「下請法（取適法）」の知識｜発注書・契約書の必須項目チェックリストでは、発注書に必ず記載すべき項目がまとめられており、追加機能の発注時にも同じ考え方が役立ちます。

独自データの考察

20年この市場を見てきた立場から言えば、追加機能の発注でトラブルになる案件と、スムーズに進む案件との違いは、実は技術力の差よりも「記録を残す習慣があるかどうか」の差であることが圧倒的に多いという実感があります。優れたエンジニアやデザイナーであっても、依頼内容が曖昧なまま進めば手戻りは避けられませんし、逆に経験の浅い担当者であっても、依頼内容が明確に記録されていれば、大きなトラブルには発展しにくいものです。

長く付き合いが続く発注者と受注者の関係を運営者として見てきた限りでは、そうした関係を築けている人ほど、単発の作業依頼ではなく「この人になら安心して任せられる」という信頼関係の構築に時間を使っています。仕様変更管理表のような記録の仕組みは、単なる事務作業ではなく、その信頼関係を支える土台になっているのです。

もう一つ、運営者として観察してきたことがあります。中間マージンが発生しない直接取引の構造は、双方にとって得をする関係を生みやすいということです。発注者から見れば、同じ予算でより多くの追加機能を依頼できる余地が生まれます。受注する側から見れば、同じ作業量でも手取りが厚くなるため、無理な値下げ交渉に応じる必要が少なくなり、結果として仕事の質を落とさずに済みます。金額そのものよりも、この「手取りが厚くなる」という質の変化こそが、直接取引の本質的な価値だと感じています。

また、ソフトウェア作成者の年収・単価相場を見ても分かるように、開発や制作に関わる単価は年々変動しており、追加機能の発注にかかる費用感も、時期や案件の難易度によって幅があります。相場感を把握したうえで交渉に臨むことが、無理のない発注につながります。仕様変更というテーマは技術的な話に思われがちですが、実際にはコミュニケーションの設計の問題です。誰が、いつ、何を依頼し、それにいくらかかるのかを、感覚ではなく記録として共有する。そのシンプルな仕組みさえあれば、追加機能の発注は決して怖いものではありません。

もし、AIツールの導入や業務のデジタル化に関連した追加機能を検討されている場合は、AIコンサル・業務活用支援のお仕事で、業務の棚卸しから外注設計までを支援してくれる専門家に相談するという選択肢もあります。また、開発や制作そのものを依頼する場合は、アプリケーション開発のお仕事のように、具体的な開発領域に強みを持つ人材を見つけることが、後々の仕様変更を減らす一番の近道になることもあります。

最後にもう一度お伝えしたいのは、仕様変更や追加費用に不安を感じるのは、あなただけではないということです。多くの発注者が同じ悩みを抱え、そして仕組みを整えることで、その不安を減らしています。焦らず、一つずつ整えていきましょう。

よくある質問

Q. 追加機能の発注で仕様変更が起きた場合、追加費用は必ず発生しますか？

必ずではありません。軽微な修正は契約時に無償対応の範囲として決めておくことも可能です。ただし機能追加や手戻りを伴う変更は、多くの場合追加費用が発生します。契約時にルールを決めておくことが大切です。

Q. 仕様変更管理表はどのように作ればよいですか？

表計算ソフトで、依頼日・依頼内容・依頼者・見積もり・納期への影響・承認状況の列を用意するだけで作れます。専用ツールは不要で、依頼のたびに1行ずつ記録していく運用で十分機能します。

Q. 追加機能の発注をフリーランスに直接依頼するのは不安です。何に気をつければよいですか？

仲介会社の進行管理機能がない分、発注者自身が仕様変更管理表のような記録の仕組みを用意することが重要です。また契約書にスコープと変更ルールを明記しておくと、直接依頼でも安心して進められます。

Q. 追加機能の発注で外注先とトラブルになりやすいのはどんなケースですか？

口頭やチャットの雑談的なやり取りで追加を依頼し、記録に残していないケースです。「言った言わない」の食い違いを防ぐため、依頼内容は必ず文書や管理表に残す習慣をつけることをおすすめします。