「それは追加費用になります」と言われたとき、妥当かどうかを見分ける方法

Webサイトのリニューアルやシステム開発を発注していて、ある日突然「それは追加費用になります」と言われた経験はありませんか？
多くの発注担当者にとって、これはかなり動揺する瞬間だと思います。
悪意を持って請求されているのか、それとも本当に必要な費用なのか……慣れていないと判断がつきませんよね。

結論から言うと、追加費用が妥当かどうかを見分けるとき、最初に見るべき物差しは、当初の見積書や契約書に「どこまで注意事項（但し書き）が書かれていたか」です。
私はこれまで、発注側・受注側の両方の立場でこの手のもめ事を見てきましたが、判断はまずここから始まります。ただし、後述するように、但し書きだけでは決まらないケースもあります。

例えば「デザイン修正は何度でも承ります」と言っていたにもかかわらず、修正を重ねた途中で急に「追加費用です」と言い出すのは、率直に言って不当です。
逆に、慣れた制作会社であれば見積書に「デザイン修正は2回まで、それ以降は都度お見積り」といった但し書きを入れているはずです。この但し書きの有無と内容が、妥当性を判断する最初のチェックポイントになります。

なぜ追加費用を求められるのか──請負業は「時間の貸し借り」でできている

追加費用の話がこじれる背景には、Web制作やシステム開発が「請負業」であるという構造があります。
制作会社や私たちのような事務所は、内実としては「この機能には1日、この機能には3日」というように、スタッフの時間を各案件に割り当てて見積りを組んでいます。
つまり、社内の人員を時間貸ししているような形で仕事をしています。

なお、IT関連の契約には請負契約のほかに準委任契約などもあり、それぞれ責任の持ち方が異なります。詳しくは請負契約・準委任契約・派遣契約の違いをご覧ください。

たとえば、あるデザイナーが「8月第一週はX社のプロジェクト、第二週からはY社のプロジェクト」という予定を組んでいたとします。
ところがX社のデザイン修正が何度も重なり、想定より作業が長引くと、第二週から始めるはずだったY社の仕事にしわ寄せが生じます。
結果として、別のスタッフに応援を頼んだり、外部に一部を委託したりといった調整が必要になり、そのための費用まで含めて「追加費用」として扱われることがあります。

この構造は、建設業のように人日・人工の考え方に馴染みのある業種であれば理解が早いのですが、請負業の経験がない発注担当者には「スタッフが動くだけなのに、なぜコスト超過になるのか」がなかなか伝わりません。会社の規模の大小はあまり関係なく、この認識のズレは起きるものだと感じています。

デザインでもめるパターン

デザインは専門知識がなくても誰もが意見を言えるものなので、もっともリテイクが発生しやすい領域です。
私自身も駆け出しのころ、プロジェクトチームの中ではデザインの合意が取れていたのに、最終段階で社長の確認が入り「やっぱりこう変えてほしい」とひっくり返って、そこで追加費用をお願いしたことがあります。200〜300万円ほどの案件で、期間は約4か月と決して余裕のあるスケジュールではありませんでした。担当者レベルでの合意と、決裁者の合意は別物だと考えておいたほうがよいでしょう。

「デザイン修正1回」の重さを知っておく

ここで、発注する側にぜひ知っておいていただきたいことがあります。それは「デザイン修正1回」の重さは、内容によってまったく違うということです。

文言の差し替えといったテキスト修正であれば、1時間もかかりません。
しかし「なんとなく気に入らないので変えてほしい」というデザインの作り直しは、実質的に0から作るのと同じです。WebサイトのTOPページのデザインであれば、2〜3日かかることがほとんどです。
また、ページの一部分だけをガラッと変える場合も、その箇所だけを直せば済むわけではありません。全体の文字サイズやレイアウトのバランスを取り直す必要があり、そうした細かな調整をしていると1日や2日はすぐに経ってしまいます。

「1回」という言葉の印象よりも、実際の作業量はずっと大きいのです。ちなみに、修正回数の上限を2回か3回と設定している会社が多い印象ですが、これは案件の規模というより、その会社や担当者のデザインへのこだわりの強さによって変わってくる部分です。

システム開発でもめるパターン

システム開発も「追加費用」の話が起きやすい業務です。
システム開発が厄介なのは、実際に触ってみないと使い勝手が分からないという性質があることです。事前にどれだけ言葉や仕様書で確認していても、「実際にできたものを触ったら想定と違った」「もっとこうしたい」という要望が出てくるのは、残念ながらよくあることです。

ただし、ここには重要な分かれ目があります。
緊急性のない「あったらいいな」程度の新規機能であれば、追加費用を取って対応するかどうかは発注側・受注側で話し合って決めればよい話です。
多くの場合、「それはこのプロジェクトが終わった後、予算に余裕があればやりましょう」という話に落ち着きます。

一方で「これがないとそもそもシステムとして動かない・意味がない」という機能が抜け落ちていた場合は、話が変わってきます。
発注担当者は「何が必要か分からないからこそ」制作会社に依頼しているわけですから、「言われた通りには作りましたが、これがないと動きません。追加費用です」というのは、受注側の落ち度と見なされることが多いはずです。

なお、追加費用の金額は「当初見積もりの何割」という比率ではなく、追加で何日分の作業（人日）が必要になるかで決まります。ここで覚えておいていただきたいのは、同じ機能でも、最初から見積もりに含まれていた場合より、途中で追加した場合のほうが高くなりやすいということです。すでに完成した部分との整合性を取り直す作業が発生しますし、急いで人を確保するための費用が上乗せされることもあるためです。

判断の分かれ目を整理する

ここまでの内容を、判断基準として整理すると次のようになります。但し書きの有無で決まるケースもあれば、要望の性質や要件定義の丁寧さで判断が分かれるケースもあります。

ケース	妥当性	見るべきポイント
見積書に明記された回数を超えたデザイン修正	妥当なことが多い	修正回数・条件の但し書きの有無
但し書きなく「何度でも承ります」と言っていたのに途中で追加請求	不当な可能性が高い	当初の説明・見積書の文言
緊急性のない新規機能の追加要望	話し合いの余地あり	要望の緊急性・当初の作業範囲との関係
システムとして動作するために不可欠な機能の欠落	追加費用を求めにくい（受注側の落ち度）	要件定義時のヒアリングの精度

見積書・契約書のどこを確認すればいいか

見積書・契約書のどこを確認すればいいか

ここからは、契約前に確認しておきたい具体的なポイントを挙げていきます。手元に見積書があれば、突き合わせながら読んでみてください。

見積書に書かれているべきこと

まず前提として、見積書に何もかも詰め込む必要はありません。見積書に求められるのは、要望に対する詳細で正確な金額と、その金額でどこまで実現できるのかという但し書きの2点です。この2つが揃っていれば、見積書としては十分だと私は考えています。

要望に対応した金額の内訳

• 見積書のどこを見るか：伝えた要望が、どの項目にいくらで反映されているかを1つずつ照合する
• 書かれていないと何が起きるか：「その作業は含まれていません」と後から言われても反論できない

修正回数の上限と、その対象範囲

• 見積書のどこを見るか：「デザイン修正は2回まで」といった但し書き。あわせて、その回数がデザイン・原稿・システムのどれに対するものかを確認する
• 書かれていないと何が起きるか：「何度でも直してもらえる」と思って依頼を重ねた末に、突然追加請求される

作業範囲外の依頼が発生した場合の単価

• 見積書のどこを見るか：人日単価・時間単価の記載
• 書かれていないと何が起きるか：追加費用の金額が妥当かどうか、判断する基準そのものがなくなる

項目が具体的に何を指しているか

• 見積書のどこを見るか：「ページ作成」のような漠然とした項目名がないか
• 書かれていないと何が起きるか：相手がこちらの要望を正しく理解しているかどうかを確認できない

最後の項目について補足すると、漠然とした項目が並ぶ見積書は、率直に言って不安を感じてしまいます。
以前、更新システムから投稿する通常のページと、個別に作り込む特殊なページが、同じ工数・同じ金額で計上されていたことがありました。作業内容にはかなりの隔たりがあるはずなので問い合わせてみたところ、営業担当者の勘違いだったことが分かりました。

見積書は、窓口の担当者とこちらの認識が揃っているかどうかを試せる貴重な資料です。「出てきた金額が予算に合っていればOK」ではなく、「こちらの要望がきちんと伝わっているか」を測るために使ってみてください。

見積書の外で確認しておきたいこと

一方で、見積書に書き切れない事柄もあります。以下は、契約書や打ち合わせの場で確認しておきたい項目です。

仕様変更が発生したときの手続き

• 誰が承認し、どこに記録するのかを決めておく
• 決めていないと：「言った・言わない」の水掛け論になり、追加費用の話が感情的なもめ事に発展する

検収の条件と期間

• 何をもって完成とするか、確認にどれだけの期間を取るか
• 決めていないと：いつまでも検収が終わらず、支払いや保守開始のタイミングがずれ込む
  • 関連記事：請負契約における成果物の定義について

保守・運用と初期構築の切り分け

• 公開後の対応がどこまで初期費用に含まれるのか
• 決めていないと：公開直後の細かな修正依頼が、追加費用をめぐる火種になる

支給素材（原稿・画像）の提供期限と、遅れた場合の扱い

• こちら側が用意する素材の締め切りと、遅延したときにスケジュールや費用がどうなるか
• 決めていないと：発注側の遅れが原因でも、制作側のスケジュールが崩れて追加費用の話につながる

プロジェクトが中断・延期した場合の費用の扱い

• 途中で止まったとき、そこまでの作業分をどう精算するか
• 決めていないと：再開時に費用の認識が食い違う

公開作業をどこで行うか

• 依頼者側の専用環境で作業する必要があるか
• 決めていないと：開発者が「お客様の環境で作業する」と気づかないまま進み、公開直前に想定外の手間とトラブルが発生する

こうした事柄をすべて見積書に書き込むと、かえって読みにくくなります。私が信頼できると感じる制作会社は、見積書とは別に「私たちはこういう想定で見積もっていますが、認識は合っていますか？」と念押しするための別添資料を用意してくれます。資料の有無そのものが、要望を理解しようとしているかどうかの一つの目安になると思います。

なお、こうした「何をやって、何をやらないか」を整理する考え方は、プロジェクトマネジメントではスコープの定義と呼ばれています。興味のある方はあわせてご覧ください。

その場で使える質問の文例

ここまで読んで、「手元の見積書には何も書かれていなかった」と気づいた方もいるかもしれません。
但し書きがない場合、実はどちらの言い分にも決定的な根拠がない状態です。この場合、過去にさかのぼって白黒つけようとするよりも、次に挙げる質問で根拠を確認しながら、今後の進め方をその場で合意し直すほうが建設的だと思います。過去は取り返せなくても、これから先の取り決めは今から作れます。

実際に「追加費用です」と言われた場面では、感情的にならず、次のような聞き方をしてみるとよいと思います。

• 「この追加費用は、見積書のどの項目・条件に基づいていますか？」
• 「今回の修正・要望は、当初の作業範囲（スコープ）のどの部分から外れていますか？」
• 「もし今回の件を無償対応いただく場合、他の作業やスケジュールにどう影響しますか？」

いずれも、相手を疑うためではなく、費用の根拠を一緒に確めの質問です。

揉める前に防ぐ──最初のガイダンスと意思決定者の巻き込み

私自身、駆け出しの頃に依頼者からの要望をあまり吟味せずに開発業者へそのまま伝えてしまい、後になって不備が発覚して怒られた経験があります。
あるとき、クライアントからこう言われたことがありました。

いろいろとシステムでやりたいことはあるけれど、それで本当に大丈夫なのか、プロの視点が欲しいから依頼している。言われたことをそのまま作られるだけだとがっかりする

この一言は、今でも私の仕事のやり方の軸になっています。私たちSSAITSが掲げている「『ほんとは、こうしたかった』を形にする」という言葉も、ここから来ています。

この経験から言えるのは、プロジェクトの一番最初に、請負業の仕組みや追加費用が発生しうる条件について、発注側・受注側の双方できちんとガイダンスをしておくことの大切さです。
特に日本の中小企業では、現場担当者同士で合意していても、最後に社長の一存でひっくり返ることが少なくありません。だからこそ、キックオフの段階から意思決定者にも同席してもらい、要所要所で判断を仰げる体制を作っておくことが、手戻りや追加費用のトラブルを減らす一番の近道だと感じています。

判断に迷ったときの相談先

ここまでの基準に照らしても、いま起きていることが妥当なのかどうか、自分だけでは判断しきれないことはあると思います。専門用語が並んでいて読み解けない、そもそも何を聞けばいいのか分からない、というのも珍しいことではありません。

そんなときは、一度第三者の目を通してみるという方法もあります。SSAITSでは、お手元の見積書や現在の状況を客観的に拝見する「30分のセカンドオピニオン相談」を受け付けています。発注・受注両方の現場を知るプロジェクトマネージャーの視点から、フラットにお話しします。資料を拝見して、特に問題がなければ、メールにてその旨をお伝えします。