既存システム改修の見積金額は何で決まるのか
- 2 日前
- 読了時間: 12分
既存システムの改修を依頼したとき、「画面を少し変えるだけなのに、なぜこの金額になるのだろう」と感じることがあります。改修の見積は、完成後の見た目だけでは決まりません。その変更を実現するために、既存システムのどこまでを調べ、どこまで影響を確認し、どこまで責任を持つ必要があるかによって大きく変わります。
はじめに：「何を変えるか」だけでは、改修費用は決まらない
新しいシステムを一から作る場合と違い、既存システムの改修には、すでに動いているものを壊さずに変更する難しさがあります。
たとえば、
「管理画面に項目を1つ追加したい」
という依頼でも、その項目がデータベース、外部API、バッチ処理、CSV出力などでも利用されていれば、確認すべき範囲は画面1か所では済みません。
反対に、変更する機能が複数あっても、現行仕様や対象範囲、試験条件が整理されていれば、必要な作業を比較的明確に見積もれることもあります。
つまり、改修後の見た目の大きさと、開発に必要な作業量は必ずしも比例しません。
既存システム改修を外注するときの進め方全般については、既存システムの改修を外注するときに失敗しないためのポイントでも解説しています。
本記事では、その中でも特に、**「改修の見積金額が何によって決まるのか」**に絞って整理します。
結論：改修見積では「変更する部分」だけでなく、その周辺まで見る
既存システム改修の見積を考えるときは、次の7つの要素に分けると分かりやすくなります。
今回変更する機能
現行システムを理解するための調査
変更による影響範囲の確認
データや外部サービスとの関係
試験
本番リリースと開発会社が負う責任範囲
見積時点で残っている不確実な要素
重要なのは、プログラムを書く時間だけが改修費用ではないということです。
すでに利用されているシステムでは、「新しい動きを作ること」と同時に、「それまで正常に動いていた部分を壊していないこと」も確認する必要があります。
そのため、同じ「1機能の改修」でも、既存システムの状態によって必要な作業量は変わります。
見積金額を左右する7つの要素
1. どこまでを今回の改修対象にするか
最初に影響するのは、当然ながら変更する範囲です。
ただし、「会員情報を変更できるようにする」といった機能名だけでは、見積に必要な範囲が確定しないことがあります。
たとえば、
画面だけを変えるのか
データベースも変更するのか
APIも変更するのか
既存データの更新が必要なのか
設計から依頼するのか
本番リリースまで依頼するのか
によって、必要な作業は変わります。
そのため見積では、機能名だけでなく「どこまで対応すれば今回の改修は完了なのか」まで確認することが重要です。
2. 現行システムがどこまで把握できているか
既存システムでは、改修前の調査量が見積へ大きく影響します。
設計書があり、ソースコードの場所やビルド方法、データベース構成、開発・試験環境まで分かっているシステムであれば、改修対象へ比較的早くたどり着けます。
一方で、
仕様書がない
以前の開発会社へ確認できない
どの処理がどこから呼ばれているのか分からない
ソースコードと実際の本番環境が一致しているか分からない
という状態では、まず現状を確認しなければ安全に変更できません。
この場合、見積に含まれるのは単なる実装費だけではなく、改修できる状態まで現行システムを理解するための作業でもあります。
仕様書がない場合に何を調べるのかについては、仕様書がない既存システムでも改修を依頼できる？最初に行う調査とはで詳しく解説しています。
3. 変更箇所からどこまで影響が広がるか
画面上では小さな変更でも、内部では複数の機能が同じデータや処理を利用していることがあります。
たとえば会員情報の項目を変更するだけでも、
会員登録
管理画面
API
検索
CSV出力
メール送信
バッチ処理
などが同じ項目を参照していれば、それぞれへの影響確認が必要です。
既存システム改修では、「変更する場所」だけでなく、「その場所とつながっている処理」を探す仕事があります。
この影響範囲が広いほど、設計・実装だけでなく試験範囲も広がります。
4. データや外部サービスへの影響があるか
データベースの項目追加や形式変更、既存データの変換、大量データの更新が必要な場合は、その分だけ考慮事項が増えます。
外部API、決済サービス、認証サービスなどと接続している場合も同様です。
自社システムだけを変更すれば完結するのか、それとも外部サービスとの接続部分まで確認する必要があるのかで、調査・設計・試験の範囲は変わります。
特に外部APIが関係する場合は、
APIを何回呼ぶ必要があるか
どのタイミングで呼ぶか
失敗した場合にどうするか
API側の利用回数制限があるか
一時的な障害時にどう扱うか
といった点まで設計対象になることがあります。
5. どこまで試験し、何をもって完了とするか
既存システム改修では、追加・変更した機能が動くことだけ確認すればよいとは限りません。
変更したことで、今まで動いていた別の機能へ影響していないかも確認する必要があります。
そのため、同じ実装内容でも、
「変更箇所だけ確認すればよい」
という案件と、
「関連機能まで含めて試験し、試験結果も納品してほしい」
という案件では必要な作業量が変わります。
見積を比較するときは、実装費だけではなく、どこまでの試験が含まれているのかを見ることが重要です。
6. リリースや本番作業をどこまで任せるか
プログラムを修正して納品するところまでなのか、本番環境への反映まで依頼するのかによっても見積は変わります。
本番リリースを含める場合には、
反映手順
バックアップ
問題発生時の切り戻し方法
実施時間帯
リリース後の確認
他社や社内担当者との調整
なども考える必要があります。
業務を止められないシステムや、複数の会社が関係するシステムでは、技術作業そのものより事前準備や調整に時間がかかる場合もあります。
どこからどこまで開発会社が責任を持つのかは、見積金額を比較するうえで重要な条件です。
7. 未確定事項と納期条件がどれくらいあるか
「詳細は開発しながら決めたい」「現行仕様は分からないが、来月までに完成させたい」
という案件では、見積時点で不確実な要素が多くなります。
不確実な部分まで含めて固定金額を出す場合、開発会社はそのリスクを考慮する必要があります。
一方、分からない部分を先に調査してから本開発を見積もれば、対象範囲を明確にしやすくなります。
分からないことが多いほど必ず高くなる、という意味ではありません。分からないものを誰が、いつ、どこまで確認するのかを決めることが重要です。
「タグを1つ表示するだけ」でも、大きな改修になることがある
筆者が既存システムの開発でよく経験してきたのが、完成後の画面だけを見ると非常に小さな変更なのに、実際には多くの設計と処理が必要になるケースです。
たとえば、
「ある条件を満たしているユーザーにだけ、一覧画面でタグを1つ表示したい」
という要望があったとします。
完成後の違いは、画面上に小さなタグが1つ増えるだけです。
しかし、そのタグを表示する条件が自社データだけでは判断できず、複数の外部APIから現在の状態を取得しなければならないとすると、話は大きく変わります。
さらに、それが詳細画面ではなく一覧画面であれば、一覧に表示されるデータの件数分だけ同じ判定処理が必要になる可能性があります。
仮に50件表示する一覧で、1行の判定に複数の外部APIが必要なら、画面を1回表示するだけで多数のAPIリクエストが発生する設計になりかねません。
そこで今度は、
一覧表示のたびにAPIを呼ぶのか
結果を一定時間保存して再利用するのか
バックグラウンドで定期的に状態を取得するのか
どの程度の新しさの情報が必要なのか
外部APIの「1分間に何回まで」といった利用制限に収まるか
自社サーバーやデータベースへの負荷は問題ないか
といった設計が必要になります。
しかも、表示条件となる状態が常に変化するのであれば、一度取得して終わりにはできません。どの程度の頻度で情報を更新すれば業務上十分なのかまで決める必要があります。
結果として、ユーザーから見える変更は「タグが1個増えた」だけでも、その裏側ではAPI連携、キャッシュ、定期更新、性能、外部サービスの利用制限まで考えることになります。
このように、既存システム改修では、完成後に何が見えるかではなく、その表示結果を正しく作り続けるために何が必要かが見積金額を左右します。
見積を比較するときは、合計金額だけを見ない
2社から見積を取り、一方が200万円、もう一方が300万円だったとします。
これだけでは、どちらが高いのか判断できません。
比較したいのは、
改修対象
現行調査
設計
試験
本番リリース
納品物
対象外
前提条件
仕様変更時の扱い
が、それぞれどこまで含まれているかです。
安く見える見積でも、試験やリリースが含まれていなければ、後から別途費用が必要になるかもしれません。
逆に金額が高く見えても、現行調査から設計、実装、試験、本番反映まで含まれているのであれば、単純比較はできません。
既存システム改修の見積では、「金額の差」より先に「何が含まれた見積なのか」を揃えて比較することをおすすめします。
当社では「対象外」と「前提条件」も見積の重要な一部と考える
既存システム改修では、「何をやるか」だけを書いた見積では、発注後に認識差が生じやすくなります。
そのためプレイリーソリューションズでは、対象範囲を整理するときに、同時に今回の見積に含まれないものと、見積成立の前提となる条件も明確にします。
たとえば、
既存システムに元から存在する不具合の修正は含むのか
外部サービスそのものの障害対応は含むのか
他社が管理するシステムの変更は誰が担当するのか
本番データの修正は対象か
開発・試験環境は誰が準備するのか
必要なAPIアカウントや権限は誰が用意するのか
仕様変更が発生した場合はどの時点で再見積するのか
といった条件です。
発注側から見ると、「対象外」が多く書かれている見積は、一見すると消極的に見えるかもしれません。
しかし実際には、対象外が明確であるほど、提示された金額で何を任せられるのかを判断しやすくなります。
特に既存システムでは、開発会社が作ったことのない領域や、他社サービス、過去から存在する不具合などが混在しています。
「改修一式」という言葉だけでそれらをすべて含めてしまうのではなく、今回責任を持つ範囲と、持たない範囲を見積段階で見える状態にすることが重要です。
すべての既存システム改修が大掛かりになるわけではない
ここまで読むと、「既存システムの改修は何をしても高くなるのでは」と感じるかもしれません。
もちろん、そうではありません。
たとえば、
改修対象が独立している
仕様書とソースコードが揃っている
変更箇所と影響範囲が明確
外部サービスへの影響がない
試験範囲を限定できる
開発・試験環境がすでに利用できる
といった案件であれば、比較的小さな範囲として切り出せることがあります。
また、軽微な文言変更や設定値変更など、技術的な影響がほとんどない作業まで、毎回大規模な調査が必要なわけではありません。
重要なのは、既存システムだから一律に高くすることではなく、今回の変更によって確認すべき範囲を見極めることです。
逆に、見た目が小さな変更だからという理由だけで、調査・試験・影響確認を省略するのも安全ではありません。
現行仕様が分からない場合は、いきなり本開発の金額を決めなくてもよい
既存システムの状態が分からない場合でも、改修相談そのものができないわけではありません。
現行仕様がほとんど見えていないのであれば、最初から本開発全体の固定金額を決めるより、まず現行ソースや資料を確認し、改修対象と影響範囲を整理してから本開発を見積もる方法があります。
調査そのものについては、仕様書がない既存システムでも改修を依頼できる？最初に行う調査とはをご覧ください。
また、以前の開発会社へ確認できない、保守会社がいなくなっているといったケースについては、開発会社がいなくなった既存システムでも、別会社へ改修を依頼できるのかで、引継ぎ時の考え方を解説しています。
見積依頼前に整理しておくとよい情報
すべてを完璧にそろえてから相談する必要はありません。
ただし、次の情報が分かっているほど、開発会社は見積の前提条件を整理しやすくなります。
確認すること | 分かる範囲で伝えたい内容 |
今回変えたいこと | 現在の問題と、改修後にどうなってほしいか |
対象システム | Webシステム、管理画面、API、バッチなど |
現行資料 | 仕様書、画面資料、DB定義、構成図などの有無 |
ソースコード | リポジトリの有無、現在ビルドできるか |
外部連携 | API、決済、認証、他社システムとの接続 |
データ | 既存データ変更・移行・一括更新の有無 |
試験 | どこまで確認してほしいか、受入条件 |
リリース | 本番反映まで依頼するか、停止可能時間など |
希望時期 | 希望納期と、その日付に制約がある理由 |
分からないこと | 仕様不明箇所、以前の開発会社へ確認できるか |
ここで大切なのは、分からない情報を無理に埋めないことです。
「ここは分からない」と伝えること自体が、見積に必要な情報になります。
その部分を追加ヒアリングで確認するのか、資料やソースコードを調査すれば分かるのか、別途技術調査が必要なのかを開発会社と整理できます。
まとめ：見た目の変更量ではなく、変更を成立させるための範囲を見る
既存システム改修の見積金額は、変更する画面や機能の数だけでは決まりません。
特に重要なのは、現行システムがどこまで把握できているか、変更の影響範囲がどこまで広がるか、外部システムやデータへどのような影響があるか、どこまで試験・リリースを行い、誰がどこまで責任を持つかです。
「小さな変更なのに高い」と感じたときは、その完成画面だけを見るのではなく、その結果を安全に実現し、運用し続けるために何が必要なのかを確認してみてください。
また、複数の見積を比較するときは、合計金額だけではなく、対象範囲、対象外、前提条件、試験、リリースまで同じ条件で比較できているかを見ることが重要です。
プレイリーソリューションズでは、既存Webシステムの改修について、現行システムの調査・技術確認から、要件整理、設計、実装、試験、リリースまでご相談いただけます。
「改修したい内容は決まっているが、影響範囲が分からない」「提示された見積金額の理由を整理できていない」といった段階でもご相談ください。
