システム開発の追加費用はどこで決まるか｜仕様変更でもめない発注側の進め方

その主張が通るかどうかは、いま決まる話ではありません。追加費用の勝負は、請求が来た日ではなく、その作業を頼んだ日に終わっています。

現場の誰かが「ここ、こうしてもらえますか」と言った日です。そのやり取りが記録に残っていて、当初の要件のどこに当たるかを示せるなら、話し合いになります。会議の口頭だけで、議事録にも一行も残っていないなら、材料がありません。

そこは契約書と経緯次第で、法律の専門家の領域です。私が話せるのは、そうなる前の運用のほうになります。

実務で見ていると、揉める案件のほとんどは金額の大小ではなく、判定できる資料がないことで長引きます。相手も、こちらが納得しない請求を出したいわけではない。双方が別の記憶を持っている状態が、いちばん高くつきます。

そこが積み上がります。ベンダーは、小さい変更のたびに見積を出すと関係が悪くなると考えるので、たいていは飲みます。飲んだ分は請求されませんが、消えるわけでもありません。

見積に含まれていた余裕の部分です。テストの期間や、想定外の対応に備えて積んでいる工数が先に削られます。それが尽きた時点で、二つのどちらかが起こります。「間に合いません」と言われるか、まとめて追加見積が出てくるか。

来ます。無料で飲んでもらった小さい変更は、終盤に納期か金額のどちらかで返ってきます。だから、金額が発生しない変更でも記録は残してください。「これは今回は費用なしで対応」と一行書いておく。相手にとっても、後から説明できる材料になります。

変更の内容、依頼した日、依頼した人、費用が発生するかどうか、この四つで足ります。表計算ソフト1枚で構いません。ベンダー側の課題管理表とは別に、発注側の手元に置いてください。

順番に照らします。

見積の除外項目と「別途協議」は、追加費用の入り口になりやすい箇所です。契約の時点で気付いていても、そこを詰めると金額が上がるので、双方が触れずに進むことがあります。

全部は分からなくて構いません。一つだけ聞いてください。「この変更で、影響範囲の調査にどれだけかかっていますか」。小さな変更でも、影響範囲の調査と再テストで工数の大半が消えることがあります。そこが金額の中心なら、作業の内容としては妥当です。逆に、新規開発と同じ単価で機能追加分だけが積まれているなら、既存の設計を作り直しているということなので、理由を聞く必要があります。

名前が変わるだけで、増える理由は同じです。請負なら追加見積、準委任なら期間の延長という形で出てきます。

準委任のほうが気付きにくい面はあります。請負なら追加見積という書類が出るので、社内で議論になる。準委任は月額が続くだけなので、増えていることが数字に現れません。

見るのは金額ではなく月数です。当初計画していた終了時期と、いまの見通しの差を毎月確認してください。1か月延びるたびに、体制の人数分の費用が増えています。

よくある選び方です。ただ、金額の差は会社の効率の差ではなく、範囲の差であることが多い。安い見積は、安く作るのではなく、少なく見積もっています。

渡した要件が同じでも、読み方は分かれます。データ移行をどこまでやるか、既存システムとの連携を何本作るか、テストは誰がどこまでやるか。この三つの読み方で、見積は倍近く変わります。

比較するときは金額の合計ではなく、この三つを各社にどう見積もったかを聞いてください。安い会社が、移行は発注側で実施する前提で出していることがあります。前提が違えば、比較になりません。

あとから発注側で移行作業を抱えるか、追加で頼むかになります。追加で頼むと、当初の差額を超えることもあります。見積の比べ方はPM代行の費用相場にも書きましたが、判断の基準は同じで、金額ではなく前提のほうを見ます。

止まりません。動くものを見て初めて分かることがあるので、変更が出ること自体は正常です。問題は、出るたびに個別に処理していることのほうです。

変更の判断を月に1回か2回に固定します。出てきた変更はいったん一覧に溜めて、その日にまとめて判断する。入れるもの、次のリリースに回すもの、やらないものに分けます。

単価が下がります。変更を1件ずつ入れると、そのたびに影響範囲の調査と再テストが発生します。まとめて入れれば、その作業が1回で済む。同じ内容でも、費用が変わります。

言われます。ただ、待たせない代わりに払っているのが、いまの追加費用です。

それと、一覧に溜めると、変更の3割前後は実際にはやらないまま消えます。急ぎだと言われた変更が、翌月には不要になっている。個別に処理していると、この分まで作ってしまいます。

例外の扱いを先に決めておきます。業務が止まる不具合と、法令や取引先の都合で期日が動かせないものだけは、その場で判断する。それ以外は次の判断日に回す。この二つ以外を例外にすると、例外が通常になります。

発注側です。ベンダーの管理表に載せると、ベンダーが対応できる変更が中心になります。この線引きはベンダーコントロールのコツに書いたとおりで、変更の窓口を1か所にすることと合わせて効きます。

説明が難しくなるのは、当初の予算に変更用の枠がないときです。1円も動かない前提で承認を取っていると、追加はすべて計画の失敗として扱われます。

開発の予算とは別に、変更のための枠を確保しておきます。枠として承認を取っておけば、変更が出たときの説明が「計画外の支出」ではなく「想定していた範囲での使用」になります。

割合の目安は、要件の固まり具合とプロジェクトの規模で変わるので、一律には言えません。決め方としては、要件定義の終了時点で残っている未決事項の件数を見て、社内で合意するのが実務的です。

そうです。逆に言うと、枠を薄くしたいなら、要件定義の段階で決める件数を増やすしかありません。何を決めておくべきかは要件定義で発注側がやることに書きました。

変更の一覧を作ることからです。過去の議事録とメールから、これまでに依頼した変更を拾い出して、費用が発生したもの、無料で対応してもらったもの、まだ返事がないものに分ける。ここまで作れば、次の追加見積が来たときに、こちらの資料で照らせます。

この拾い出しは手間がかかる作業ですが、議事録やメールから変更依頼らしき箇所を抜き出して一覧に整える部分は、いまはAIに寄せられます。判断は人が出すとして、材料をそろえる時間は短くできます。

今月分から、判断の日を決めてください。変更を溜める場所と、決める日と、決める人。この三つが揃った時点で、追加費用の出方は変わります。関係者が遅れの理由を別々に説明し始めているなら、費用の話より先にプロジェクト炎上の立て直しの手順です。順番を間違えると、金額だけ確定して工程が動きません。