「これも追加でお願い」が積み重なる前に、決めておくべきこと

開発が進む中で、「これも追加でお願いできますか」という小さな追加依頼を、その都度伝えてしまうことがあります。1つ1つは小さな依頼でも、積み重なると、予算やスケジュールに大きな影響を与えることがあります。この記事では、こうした追加依頼が積み重なる前に、決めておくべきことを解説します。

この記事で分かること

追加依頼の積み重なりは、いわゆる「スコープクリープ」と呼ばれる現象で、多くの発注者が経験する問題です。開発の現場では、契約時に決めた「対応範囲（スコープ）」が、開発が進むうちに少しずつ膨らんでいき、気づいたときには当初の予算や納期では収まらなくなっている、という事態がしばしば起こります。この記事では、この問題を防ぐために、事前に決めておくべきことを紹介します。

結論を先に示すと、押さえておきたいポイントは次の3つです。

• 契約時点で、対応範囲（スコープ）を明確にしておく
• 追加依頼が出たら、都度、費用と期間への影響を確認する
• 追加依頼を、まとめて検討するタイミングを決めておく

なぜ「小さな追加依頼」は積み重なりやすいのか

スコープクリープが起こりやすい最大の理由は、1件あたりの依頼が小さく見えることです。「ボタンの色をもう少し目立たせてほしい」「この項目を1つ追加してほしい」「検索条件をもう1種類増やしてほしい」——どれも単体で見れば、数十分から数時間程度の作業に思えます。開発会社側も、関係性を大事にしたい気持ちから、多少の追加であれば無償で対応してくれることもあります。

しかし、次のような構造があるため、小さな依頼は静かに積み重なっていきます。

• 依頼する側は、1件ごとの負荷を過小評価しやすい。画面上の見た目の変更に見えても、裏側のデータ構造やテスト範囲まで影響することがあり、発注者からは工数の実態が見えにくい。
• 「前回も無償でやってもらえたから」という前例が、次の依頼のハードルを下げる。1回目は好意で対応してもらえても、それが積み重なると、開発会社側の負担は無視できない規模になる。
• 依頼のタイミングが分散する。週に1件ずつ小出しに依頼が来ると、開発会社は都度スケジュールを組み直す必要があり、まとめて対応するより非効率になりやすい。
• 「これくらいならお願いしても大丈夫」という感覚に、明確な基準がない。対応範囲が契約書に明記されていないと、発注者自身も「これは追加なのか、当初の範囲内なのか」を判断できない。

この結果、開発会社が終盤になって「これまでの追加対応をまとめると、当初の見積もりの3割増の工数がかかっています」と伝えてきて、初めて事態の大きさに気づく、というケースが少なくありません。

ポイント1：契約時点で、対応範囲（スコープ）を明確にしておく

追加依頼が積み重なる根本的な原因は、当初の契約で「どこまでが契約に含まれる範囲か」が明確に定義されていないことです。契約時点で、仕様書や要件定義書に、対応する機能の範囲を具体的に明記しておくことで、「これは契約に含まれているか、含まれていないか」を、後から判断しやすくなります。

契約書で確認すべき条項については、別記事で詳しく解説していますが、対応範囲の明確化は、その中でも特に重要なポイントです。

「明確な対応範囲」とは、具体的に何を書くことか

対応範囲を明確にするといっても、抽象的な言葉だけでは不十分です。実務では、次のような粒度で書かれているかどうかが目安になります。

• 画面・機能の一覧が具体的に列挙されているか（例:「予約一覧画面」「予約詳細画面」「管理者向け承認画面」など、画面単位・機能単位で名前がついているか）
• 各機能について「やること」と「やらないこと」の両方が書かれているか（例:「決済機能はクレジットカード決済のみ対応。コンビニ決済・後払いは対象外」など）
• 対応するデバイス・環境が明記されているか（例:「スマートフォン向けのレスポンシブ対応のみ。タブレット専用レイアウトは含まない」）
• 想定データ量・利用者数の前提が書かれているか（例:「想定ユーザー数100名程度までを前提とした設計」など、前提を超えた場合の扱いが読み取れるか）

これらが書かれていない見積もりや仕様書は、後から「言った・言わない」の水掛け論になりやすい状態だといえます。

スコープが曖昧なまま発注してしまう典型パターン

個人・複業でサービスを立ち上げる場合、次のようなパターンでスコープが曖昧になりがちです。

• アイデアの説明を口頭・チャットのやり取りだけで済ませてしまい、開発会社側が作成した見積もりの前提を、発注者側が細部まで確認していなかった。
• 「だいたいこんな感じのアプリ」というイメージだけで発注し、機能の詳細を開発会社側の解釈に委ねてしまった。
• 見積もり金額だけを見て契約を決め、見積もりの根拠になっている「対応範囲」の記載を読み込んでいなかった。

これらのパターンに共通するのは、契約前の段階で、発注者自身が「自分は何を作ってほしいのか」を具体的な言葉や絵に落とし込めていない、という点です。初回相談を実りあるものにするための準備については、手書きワイヤーフレームの作り方を解説した別記事も参考になります。

ポイント2：追加依頼が出たら、都度、費用と期間への影響を確認する

開発が進む中で、「これも追加してほしい」という要望が出てきた場合、その都度、それが追加費用や、スケジュールの延長につながるかどうかを、開発会社に確認することをおすすめします。

保守費用に含まれる範囲との線引きが曖昧なまま追加依頼を重ねると、想定外の費用感になりやすいため、契約している保守費用がどこまでをカバーするのかも合わせて確認しておくと安心です。保守費用に含まれる範囲の考え方も参考にしてください。

「小さな追加だから、大丈夫だろう」と思い込んで、確認せずに依頼を重ねてしまうと、後になって、まとめて多額の追加費用を請求される、あるいは、スケジュールが大幅に遅れる、という事態につながることがあります。

確認するときの、具体的な聞き方

追加依頼を伝える際は、次のような聞き方をすると、開発会社側も答えやすくなります。

• 「この追加は、当初の見積もりの範囲内で対応できますか。それとも追加費用が発生しますか」
• 「追加費用が発生する場合、概算でどれくらいの工数（時間）がかかりますか」
• 「この追加を入れると、リリース予定日にどれくらい影響がありますか」
• 「今すぐ対応が必要ですか。それとも、次回のまとめタイミングで検討してもよいですか」

このように、費用・期間・緊急度の3点を毎回確認する習慣をつけておくと、依頼のたびに「これは本当に今必要か」を発注者自身も見直すきっかけになります。

「無償対応」に頼りすぎるリスク

開発会社によっては、関係維持のために、小さな追加を無償で対応してくれることがあります。これは発注者にとって一時的にはありがたいことですが、次のようなリスクも抱えています。

• 無償対応が続くと、開発会社側の採算が合わなくなり、プロジェクトの後半で品質やスピードが落ちる可能性がある。
• 「今回も無償でやってもらえるはず」という期待が発注者側に生まれ、依頼の歯止めが効かなくなる。
• 無償対応の範囲が記録されていないと、後から「どこまでが契約内で、どこからが好意による対応だったか」が分からなくなり、トラブルの火種になる。

小さな追加であっても、口頭だけで済ませず、チャットやメールなど記録が残る形で「この対応は無償で行う」ということを、双方で確認しておくことをおすすめします。

ポイント3：追加依頼を、まとめて検討するタイミングを決めておく

追加依頼が発生するたびに、その場で即座に対応してもらうのではなく、「週に1回、その週に出た追加依頼をまとめて確認する」というように、検討するタイミングをあらかじめ決めておくことも、有効な対策です。

このタイミングを設けることで、その場の思いつきで追加依頼を重ねることを防ぎ、本当に必要な追加依頼かどうかを、落ち着いて判断できます。

まとめて検討する運用の作り方

実務では、次のような運用にすると回しやすくなります。

1. 追加依頼が出たら、いったんメモ・チケットとして記録しておく（Slack、スプレッドシート、タスク管理ツールなど、形式は問わない）
2. 週次や隔週など、一定の間隔で「追加依頼レビュー」の時間を開発会社と設ける
3. レビューの場で、記録した依頼を一覧化し、優先度・費用・期間への影響をまとめて確認する
4. 「今回対応する」「次回以降に見送る」「対応しない」の3択で、その場で判断する

このサイクルを回すことで、依頼が場当たり的に処理されることを防ぎ、発注者・開発会社の双方が、全体の進行状況を見ながら意思決定できるようになります。特に個人・複業で開発を発注している場合、開発会社との定例ミーティングの頻度が少ないことも多いため、あらかじめ「追加依頼はこのタイミングでまとめて話す」というルールを最初の打ち合わせで共有しておくと、後々のやり取りがスムーズになります。

追加依頼が発生したときの、優先順位のつけ方

追加依頼が出た場合、それが「今回のリリースに、必ず必要か」「次回以降の改修で対応してもよいか」を、都度判断することをおすすめします。すべての追加依頼を、今すぐ対応しようとすると、予算やスケジュールへの影響が大きくなります。

機能に優先順位をつける考え方については、予算300万円で何を作るかを扱った別記事でも詳しく解説しています。

優先順位を判断するための、簡単な基準

すべての追加依頼を同じ重みで扱うと、判断が難しくなります。次のような基準で分類すると、優先順位をつけやすくなります。

• サービスの中核機能に関わるか、それとも周辺的な便利機能か——例えば予約サービスであれば、「予約ができる」「決済ができる」は中核機能。「予約履歴をCSVでダウンロードできる」は周辺機能に位置づけられる場合が多い。
• 今のユーザー・利用者から、実際に要望が上がっているか、それとも発注者の想像による要望か——実際の利用者の声に基づく要望は優先度が上がりやすい。
• リリースを遅らせてでも今すぐ入れる価値があるか、後から追加しても支障がないか——後からでも機能追加できる設計であれば、初回リリースでは見送るという判断もできる。
• 対応にかかる工数と、得られる効果が見合っているか——工数が小さくても効果が限定的な依頼は、まとめて後回しにする候補になる。

これらの基準を、発注者だけで判断するのではなく、開発会社にも意見を聞きながら整理すると、より現実的な優先順位付けができます。開発会社は技術的な難易度や、他の機能への影響を踏まえた視点を持っているため、発注者だけでは見えない負荷やリスクを指摘してもらえることがあります。

開発会社側からも、確認を求められることがある

誠実な開発会社であれば、追加依頼が出た際に、「これは追加費用が発生しますが、進めてよいですか」と、確認を求めてくることが一般的です。この確認がなく、追加依頼をそのまま無条件に対応してしまう開発会社の場合、後から想定外の請求が発生するリスクがあるため、注意が必要です。

開発会社からの確認がない場合に、想定される2つのパターン

開発会社が追加費用の確認をしないまま対応を進める場合、背景には大きく2つのパターンが考えられます。

1つは、開発会社が「このくらいの追加であれば、当初の見積もりの範囲内でカバーできる」と判断して、あえて確認を省略しているパターンです。この場合は、特に問題になることは少ないですが、発注者としても「この対応は追加費用が発生していないか」を、念のため確認しておくと安心です。

もう1つは、開発会社が費用感をその場では計算せず、後でまとめて請求しようと考えているパターンです。この場合、プロジェクトの終盤になって、想定外の金額をまとめて請求されるリスクがあります。追加依頼のたびに、「これは追加費用が発生しますか」と発注者側から確認する習慣をつけておくことで、このリスクを避けやすくなります。

追加依頼を、そもそも減らすための工夫

追加依頼が発生する背景には、当初の要件定義が十分でなかった、という原因も考えられます。開発を始める前の要件定義の段階で、できるだけ具体的にイメージを固めておくことで、後からの追加依頼を減らすことができます。

手書きワイヤーフレームの作成など、初回相談の段階でイメージを具体化する工夫については、別記事で詳しく解説しています。

要件定義の段階でできる、具体的な工夫

追加依頼を未然に減らすには、次のような工夫が有効です。

• 「使う場面」を具体的に洗い出す。誰が、いつ、どのような状況でその機能を使うのかを、できるだけ具体的にイメージし、書き出しておく。
• 画面のラフスケッチを作ってみる。文章だけでは伝わりにくい部分も、簡単な手書きの絵にすることで、発注者と開発会社の間でイメージのズレを減らせる。
• 「これは入れない」というリストも作る。「入れたい機能」だけでなく、「今回は入れない機能」も明記しておくと、後から「これも入っていると思っていた」という誤解を防げる。
• 似たようなサービス・アプリを参考として提示する。「このアプリのこの画面のような操作感にしたい」と具体例を示すことで、認識のズレを事前に減らせる。

こうした準備を経て要件定義を固めておくと、開発が始まってから「実はこの機能も必要だった」と気づく頻度そのものを減らすことができます。

専門知識を活かしたツールの場合、追加依頼が発生しやすい理由

専門分野の業務ロジックを含むツールの場合、開発を進める中で、「実際に動かしてみたら、この条件も考慮する必要があった」という新たな要件が見つかりやすい傾向があります。この場合の追加依頼は、当初の要件定義の不足というより、専門的な業務の複雑さに起因することが多いため、開発会社と相談しながら、優先順位をつけて対応することをおすすめします。

例えば、士業や特定業界の資格を持つ人が、自分の専門知識を活かした業務支援ツールを作る場合、業務のルールや例外処理が複雑で、開発会社側だけでは事前にすべてを把握しきれないことがあります。「通常のケースはこの計算式でよいが、この特殊な条件のときだけ別の計算になる」といった業務知識は、実際に画面を動かしながら発注者自身が気づき、追加で伝えるケースも少なくありません。

このようなケースでは、追加依頼そのものを完全にゼロにすることは難しいものの、次のような工夫で影響を小さくできます。

• 専門的な業務ルールについては、最初にできるだけ言語化し、簡単な一覧やフローチャートにして共有する
• 「例外パターンがまだ他にもあるかもしれない」という前提を、契約時点で開発会社と共有しておく
• 専門知識に関わる追加依頼は、通常の追加依頼よりも優先的にレビューし、業務が正しく成立するかどうかを重視して判断する

専門知識を伝える際の工夫については、別カテゴリの記事でも取り上げているため、専門分野のツールを開発する場合は、あわせて確認しておくとよいでしょう。

スコープクリープを防ぐためのチェックリスト

ここまでの内容を、発注者が使えるチェックリストの形にまとめます。契約前・開発中の各タイミングで、以下の項目を確認してみてください。

契約前に確認したいこと

• [ ] 見積もりや仕様書に、対応する画面・機能が具体的に列挙されているか
• [ ] 「やること」と「やらないこと」が、両方明記されているか
• [ ] 想定するユーザー数・データ量などの前提が書かれているか
• [ ] 契約書に、追加依頼が発生した場合の対応方法（費用の考え方、見積もりの取り直し方など）が記載されているか

開発中に確認したいこと

• [ ] 追加依頼を伝える前に、「これは今回のリリースに必須か」を自分の中で一度整理したか
• [ ] 追加依頼を伝えるときに、費用・期間・緊急度の3点を確認したか
• [ ] 追加依頼の内容と、開発会社からの回答を、記録が残る形（チャット・メールなど）で残しているか
• [ ] 追加依頼をまとめて検討するタイミング（週次レビューなど）を、開発会社と共有できているか

振り返りのタイミングで確認したいこと

• [ ] これまでに出した追加依頼の一覧を、費用・期間への影響とともに振り返ったか
• [ ] 「無償で対応してもらった依頼」がどれくらいあるか、把握できているか
• [ ] 次のフェーズ（リリース後の改修など）に持ち越す機能が、明確に整理されているか

このチェックリストは、プロジェクトの規模を問わず活用できます。特に個人・複業での発注は、専任の担当者がいないことが多いため、こうした確認項目をあらかじめリスト化しておくことで、確認漏れを防ぎやすくなります。

具体的な失敗パターンから学ぶ、スコープクリープの実例

抽象的な説明だけでは、自分のプロジェクトに当てはめて考えにくいこともあります。ここでは、個人・複業でのサービス立ち上げにおいて起こりやすい、具体的な失敗パターンを3つ紹介します。

失敗パターン1: 「見せながら決める」を繰り返してしまう

あるハンドメイド作品の販売サイトを立ち上げた発注者は、開発中の画面を見るたびに、「ここはこうしたい」「この色は違う気がする」と、その場で思いついた修正を伝えていました。1回の打ち合わせで平均5〜6件の細かい修正依頼が発生し、それが毎週続いた結果、当初2ヶ月の予定だった開発期間が4ヶ月に延びてしまいました。

このケースの問題は、修正依頼そのものが悪いわけではなく、「見せながらその場で決める」というプロセスを、当初のスケジュールに組み込んでいなかったことです。デザインの微調整が発生しやすいことが事前に分かっているなら、契約時点で「デザイン確認は3回まで、それ以降の大幅な変更は別途相談」といった取り決めをしておくべきでした。

失敗パターン2: 競合サービスを見て、機能を後から次々に追加してしまう

予約管理サービスを開発していた発注者は、開発の途中で競合サービスのウェブサイトを見て、「あのサービスにあるこの機能も、うちにも欲しい」と感じ、開発会社に次々と機能追加を依頼しました。結果として、当初の要件定義には無かった機能が、リリース前の2ヶ月間で10件近く追加され、見積もり金額が当初の1.5倍近くまで膨らみました。

このケースでは、「競合と同じ機能を持つこと」自体が目的化してしまい、「自分のサービスの利用者にとって、本当に必要な機能か」という判断基準が薄れていたことが問題でした。競合調査自体は有益ですが、気づいた機能はいったんメモしておき、初回リリースの後の改修フェーズで検討する、という運用にしていれば、当初のスケジュールと予算で初回リリースを迎えられた可能性があります。

失敗パターン3: 「ついで」の依頼を、無償対応に頼りすぎてしまう

士業向けの業務支援ツールを開発していた発注者は、開発会社との関係が良好だったこともあり、「ついでにこれもお願いできますか」という依頼を、開発会社が無償で対応してくれることに慣れてしまいました。開発会社側も当初は好意で対応していましたが、依頼の件数が増えるにつれて、開発会社の担当者の負荷が高まり、最終的には「これまでの無償対応をまとめると、当初の見積もりの2割相当の作業量になっています」と伝えられ、追加費用の支払いを求められることになりました。

このケースの教訓は、「無償で対応してもらえている」という状態が続いているときほど、意識的に依頼の頻度や規模を振り返る必要がある、という点です。開発会社が何も言わないからといって、負担がゼロというわけではありません。

発注者・開発会社、双方の視点で見るスコープクリープ

スコープクリープは、発注者だけの問題ではなく、開発会社側の対応の仕方によっても、影響の大きさが変わってきます。それぞれの立場から見た注意点を整理します。

発注者側が気をつけたいこと

• 追加依頼を伝える前に、一度時間を置いて「本当に今必要か」を考え直す
• 「思いついたらすぐ伝える」ではなく、「思いついたらメモしておき、まとめて伝える」に切り替える
• 開発会社からの見積もりや契約書に書かれている対応範囲を、契約前によく読み込んでおく
• 追加依頼によって発生した費用・期間の影響を、都度記録しておく

開発会社側に期待したいこと

• 追加依頼が出た際に、費用や期間への影響を、できるだけ早いタイミングで発注者に伝える
• 「無償で対応できる範囲」と「追加費用が必要な範囲」の基準を、契約時点で発注者と共有しておく
• 追加依頼が積み重なってきた場合、早めに「このままでは当初の予算・期間を超える可能性がある」と発注者に警告する
• 発注者が判断しやすいように、追加依頼を機能ごとに整理し、優先順位づけの材料を提供する

良い開発会社は、単に依頼されたことをこなすだけでなく、発注者が気づいていないリスクを先に指摘してくれます。逆に、追加依頼に何でも応じてくれる開発会社が、必ずしも良い開発会社とは限らない、という点も意識しておくとよいでしょう。

まとめ:小さな依頼の積み重ねを「見える化」することが最大の対策

スコープクリープは、誰か一人が悪いというより、「1件ごとの依頼が小さく見える」という構造そのものから生まれる問題です。だからこそ、個々の依頼が良いか悪いかを判断する以前に、依頼が積み重なっていく状況そのものを見える化する仕組みを作ることが、最も効果的な対策になります。

契約時点で対応範囲を明確にしておく、依頼のたびに費用と期間への影響を確認する、まとめて検討するタイミングを設ける——この3つは、いずれも「積み重なりに気づける状態を作る」という共通の目的を持っています。個人・複業でサービスを立ち上げる場合、専任のプロジェクトマネージャーがいないことがほとんどですから、発注者自身がこうした仕組みを最初から意識しておくことが、結果的に予算とスケジュールを守ることにつながります。

この記事の次に読みたい記事

追加依頼が積み重なる前の対策を理解したら、次は納期が遅れ始めたときの対応についても確認しておきましょう。あわせて次の記事も参考にしてください。

• 初めての発注でやりがちな失敗と、避け方
• 納期が遅れ始めたとき、発注者側がまず確認すべきこと
• 契約書で必ず確認したい条項（知的財産権・検収・保守）