システム開発で「これは追加費用です」と言われるのはどこからか｜開発会社の判断軸

「これは追加費用です」と言われるのは、どこからか

結論から言うと、開発会社が追加費用かどうかを判断するときに見ているのは、主に次の3つです。要望の内容そのものより、当初の合意からどれだけ外に出たかで決まります。

• 画面が増えたか —— 最もはっきり分かる基準
• 当初合意した機能リストに入っていたか —— 大項目の解釈が広がっていないか
• 元々の予算に、他を削って充当する余地があるか

判断軸1：画面が増えたか

「機能が追加されたかどうか」を判断するとき、いちばん分かりやすいのは画面です。新しい画面が1枚増えれば、設計・実装・テストがそれぞれ発生します。発注側から見ても、増えた画面は目に見えるので認識を合わせやすい基準です。

判断軸2：当初の機能リストにあったか（解釈の余地に注意）

次に見るのが、当初合意した機能リストに入っていたかどうかです。ここで問題になりやすいのは、大項目の解釈が人によって広がることです。

たとえば「ユーザー管理」という一項目に、CSVのインポート・エクスポート、二要素認証、パスワードポリシーまで含まれていると解釈されることがあります。発注側は「ユーザー管理と書いてあるのだから含まれるはず」と考え、開発会社は見積もり時にそこまで想定していない。この食い違いが「聞いていない」「含まれていると思っていた」という形で表に出ます。

実際の相談では、こちらが出した開発工数や金額と照らし合わせながら、追加に値するかどうかを話し合って決めます。

判断軸3：元々の予算に余地があるか

同じ要望でも、案件の規模によって答えが変わります。詳しくは次の章で説明しますが、予算が小さいほど融通が利かなくなります。

追加費用にならないのはどんなときか

すべての要望が追加費用になるわけではありません。追加費用なしで対応することが多いのは、こちらが提案した画面や機能を発注側がレビューして、より良い方法が見つかったときです。

画面設計や機能の提案は開発側が行うことが多く、その内容を確認してもらう中でより良い形が見つかった場合は、追加ではなく「ブラッシュアップ」として喜んで対応します。提案が良くなること自体は、開発会社にとっても望ましいからです。

もう一つは「好み」に近い修正です。AとB、どちらのデザインが良いかといった種類のもので、1〜2回の修正であれば対応できます。ただし延々と続けたくなる場合もあるので、そのときは「一度ユーザーさんに実際に使ってもらってから判断しましょう」とお伝えしています。使う人の反応が入ると、判断の基準が好みから事実に変わります。

なぜ予算が小さいほど融通が利かないのか

ここが発注側から見えにくい部分です。理由は、FUNBREWの見積もりにはバッファー（予備工数）を積んでいないことがほとんどだからです。

バッファーは嘘の工数になりがちです。余っても発注側に返るわけではなく、そのまま開発会社のものになります。そうであれば、最初から積まずに、必要になった時点で相談する方が誠実だと考えています。

その代わり、出した見積もりには予備や遊びがありません。100万円以下の案件では、他の機能を削って新しい要望に充当するという技が使えないことになります。規模の大きい案件なら「この機能を後回しにして、代わりにこちらを入れましょう」という組み替えができますが、小さい案件にはその余白がそもそも無いのです。

「小さい案件の方が融通が利きそう」という直感とは逆になります。予算が小さいほど、最初に決めた範囲が効いてきます。

要望が増える前提で、どう進めているか

そもそも要望は増えるものだと考えて進めています。要件定義の段階ですべてを見通すことは難しく、作られたものを見て初めて気づくことがあるからです。

ではどうするかというと、フェーズを分ける・優先順位を決めるという提案をすることがほとんどです。すべてを最初のリリースに詰め込まず、順番を決めておけば、後から出てきた要望を次のフェーズに載せる判断ができます。バッファーを積む代わりに、順番で吸収する考え方です。

たまに「いろいろと検討したいから、各機能で余裕を見ておいてほしい」と最初に言ってくださる発注者もいます。その場合はそのつもりで見積もるので、進め方としてはやりやすく、工数が余れば追加の提案をすることもあります。

同じ機能を触り続けているなら、契約の形を変える

定例ミーティングで同じ機能をひたすら調整し続けている状態が見えてきたときは、請負契約から準委任契約への切り替えを提案することがあります。決めきってから作る前提の請負より、動かしながら決める形の方が実態に合っているからです。契約形態の違いはシステム開発の契約形態｜請負と準委任の違いで解説しています。

揉めたケースと、揉めずに済んだケースの違い

揉めずに済んだのは、最初の段階で分かりやすくお断りできた場合がほとんどです。断る理由のほとんどは予算や納期の不足で、その時点で正直に伝えられていれば、後から食い違いが表面化することはありません。

逆に、ある程度の予算を組んでもらっていても、要望が増え続けた結果、揉めるところまで行かなくても今後のお取引が難しくなることはあります。また、専門家の意見を取り入れてもらえない状態は後々トラブルになりやすいため、その場合は「お手伝いしづらい」と正直にお伝えすることがあります。

なお「発注側が遠慮して言い出せなかった問題」に心当たりはほとんどありません。むしろ謙虚な発注者ほどこちらから積極的に提案するようにしていますし、本来必要なシステムを引き出すために、意見を言いにくい空気を作らないよう努めています。言いにくいことほど早く言ってもらった方が、結果として安く済みます。

まとめ：追加費用でつまずかないために

• 分かれ目は「画面が増えたか」「当初合意した機能リストにあったか」の2つ
• 「ユーザー管理」のような大項目は解釈が広がりやすい。着手前に中身を書き出しておく
• 提案のブラッシュアップと、1〜2回の好みの修正は追加費用にならないことが多い
• バッファーを積まない見積もりでは、予算が小さいほど組み替えの余地が無くなる
• 要望が増える前提なら、フェーズ分けと優先順位で吸収する。同じ機能を触り続けるなら準委任への切り替えも選択肢

相談の段階で予算・納期・機能をどう伝えればよいかはシステム開発の相談メールには何を書けばいいかで、機能リストの作り方は要件定義のやり方で解説しています。

いま進行中の案件で追加費用の話が出て判断に迷っている場合も、お問い合わせからご相談いただけます。