「帳票を1枚追加したいだけ」と伝えたのに、返ってきた見積もりが数百万円だった。似た経験をされた方は多いと思います。作業量から考えると高すぎる気がするけれど、根拠を説明できないので稟議も書けないし、値切る材料もない。そういう状態でこの記事にたどり着いた方に向けて書きます。
先にお伝えすると、小さな改修が割高になるのは担当会社が吹っかけているからではなく、構造的な理由があります。国の機関が公開している調査でも、開発の規模と工数は比例しないことが数字で示されています。ただし、だからといって言い値で払う必要はありません。この記事では、どこまで直してどこは触らないかの線引き、見積もりが膨らむ出どころ、そして追加費用が出たときに妥当かを見分ける方法を整理します。刷新するかどうかの判断や刷新の費用相場は別の記事に譲ります。
この記事のポイント
- 改修の範囲は機能単位ではなく、業務が変わるかどうかで線を引く
- 小さい改修ほど1行あたりは割高になる。これは感覚ではなく構造で説明できる
- リファクタリングは発注側から頼まない。成果物が見えない作業は発注書に落ちない
- 見積もりが膨らむ出どころは、影響範囲の調査・テスト・動作環境の3つに集約される
目次
レガシーシステムの改修はどこまでやるべきか
見積もりの中身を見る前に、範囲の話から始めます。改修の金額は「何をどこまで直すか」でほぼ決まるので、範囲が曖昧なまま相談すると、相手は安全側に広く見積もらざるを得ません。まずはこちらで線を引いてから渡すのが、結果的に一番効きます。
直すか作り直すかは残す年数で決める
最初に確認したいのは、そのシステムをあと何年使うつもりかです。ここが決まらないと、改修の妥当な金額も決まりません。
目安として、あと2〜3年で入れ替える予定があるなら、改修は「業務が止まらない最低限」に絞るのが合理的です。残り期間が短いのに作りを整えても、そのまま捨てることになります。逆に5年以上使うつもりなら、後の改修が楽になる直し方を選ぶ価値が出てきます。
判断が難しいのは、そもそも入れ替えるかどうかが決まっていない場合です。この状態で改修を続けると、毎年の支出は続くのに終わりが見えません。延命・部分改修・段階移行・全面刷新のどれを選ぶかは、基幹システムのリプレイスとは？進め方と発注側の判断基準で判断軸を整理していますので、先にそちらで方針を決めてから改修の範囲を決めると迷いが減ります。作り直した場合にいくらかかるかを並べて比べたいときは、基幹システム刷新の費用相場はいくら？内訳と見積もりの読み方もあわせて確認してください。
改修してよい範囲と触らない範囲
範囲を決めるとき、機能の数で考えると線が引けません。実務では「業務が変わるかどうか」で分けると判断しやすくなります。
| 種類 | 改修でやるか | 考え方 |
|---|---|---|
| 法改正や取引先の都合による変更 | やる | やらないと業務が止まる。優先度は最上位 |
| 今の業務のやり方に合わせる変更 | やる | 効果が見えやすく、範囲も限定しやすい |
| 使いにくさの解消・画面の刷新 | 慎重に | 効果が測りにくく、範囲が広がりやすい |
| 土台の作り替え・言語の変更 | やらない | 改修の枠を超える。刷新として別に検討する |
特に3つ目に注意してください。「使いにくいので直したい」という要望は現場から必ず出ますが、どこまで直せば満足なのかを事前に決められないため、範囲が膨らみやすい典型です。着手するなら「この画面のこの操作を、何クリックから何クリックにする」まで具体化してから渡してください。
4つ目は、そもそも改修の枠でやることではありません。土台を替えるなら、それは刷新の話です。改修の見積もりに土台の作り替えが混ざっていたら、範囲がずれているサインだと考えてください。
リファクタリングは発注側から頼まない
ここは一般的な記事と逆のことを書きます。技術的には、コードを整理して見通しをよくするリファクタリングには意味があります。ただし発注する側から「リファクタリングもお願いします」と頼むのは、私はおすすめしません。
理由は、成果物が見えないからです。リファクタリングは外から見た動きが変わらない作業なので、終わったときに何が良くなったのかを発注側が確認できません。検収の基準を作れず、費用の妥当性も判断できない。結果として「やったと言われれば信じるしかない」状態になります。
そうではなく、改修のついでに整えてもらう形にするのが現実的です。「今回触る範囲については、次に直しやすい形にして、設計書も更新してください」と依頼書に書く。これなら作業は改修に紐づいていて、成果物も設計書という形で残ります。整理そのものを目的にした発注は、社内に技術を判断できる人がいる場合に限ったほうが安全です。
部分改修を重ねると何が起きるか
もうひとつ知っておきたいのが、改修は重ねるほど次が高くなるという性質です。
毎回の改修で、その場では合理的な判断がされます。既存の作りを壊さないよう、例外処理を足す形で対応する。これを10年続けると、条件分岐が積み上がって、どの処理がどこに影響するのかが誰にも追えなくなります。すると次の改修では影響範囲の調査に時間がかかり、テストの範囲も広がります。同じ規模の改修でも、年を追うごとに見積もりが上がるのはこのためです。
だから改修を続けると決めた場合は、「毎回の改修で設計書を更新してもらう」ことを保守契約の作業範囲に入れておいてください。これをやるかどうかで、5年後の改修費用がまったく変わります。追加費用に見えますが、実際には将来の値上がりを抑える投資です。
レガシーシステムの改修見積もりをどう読むか
ここからは、実際に受け取った見積書の読み方です。総額を見て高いか安いかを判断する前に、なぜその金額になるのかの構造を知っておくと、聞くべきことがはっきりします。
小さい改修ほど1行あたりは高くなる
まず知っておきたいのが、開発の規模と工数は比例しないという事実です。IPAが公開しているソフトウェア開発分析データ集2022では、5,546件のプロジェクトを分析した結果として、規模と工数の関係は「平方根よりやや大きい程度（0.56乗）」と報告されています。
これを発注側の言葉に直すと、こうなります。規模が10分の1の改修でも、工数は10分の1にはならず、おおよそ3割弱にしかなりません。つまり1行あたりで見ると、小さい改修のほうが約2.7倍割高になる計算です。「帳票1枚なのに高い」という感覚は正しいのですが、それは相手が吹っかけているのではなく、小さい仕事ほど単位あたりのコストが上がるという構造です。
テストも同じです。同じ資料では、1000行あたり結合テスト50個・総合テスト15個という相場観が示されています。改修の規模を小さくしても、影響する範囲のテストは相応に必要なので、テスト工数は規模ほど素直には減りません。見積書でテストの割合が大きいのは、必ずしも水増しではないということです。
なお同じ資料では、開発プロダクトのうち改修・保守が5割弱を占めています。改修は例外的な仕事ではなく、開発現場の主流です。
見積もりが膨らむ3つの出どころ
では、どこで金額が積み上がるのか。経験上、出どころは3つに集約されます。
ひとつ目は影響範囲の調査です。設計書が残っていないシステムでは、直す前に「どこに影響するか」を調べる必要があります。ここは実装より時間がかかることも珍しくありません。ふたつ目はテストで、影響範囲が確定できないと安全側に広くテストすることになり、工数が伸びます。みっつ目が動作環境で、古い開発環境を用意し直したり、動作確認用のデータを作ったりする準備が要ります。
この3つはいずれも「直す作業そのもの」ではありません。だから発注側から見ると、実装以外の項目が大きく見えて割高に感じます。逆に言えば、この3つを減らせれば金額は下がります。特に影響範囲の調査は、先に単独で発注して結果を自社の資産として持っておくと、以降の改修すべてで効いてきます。調査をどこまでやれば足りるかは、レガシーシステムの解析はどこまで必要？費用と頼み方で整理しています。
発注書に書くと膨らみを抑えられること
見積もりを取る前に、依頼書へ次を書いておくと前提が揃い、各社の金額を比べられるようになります。
改修を依頼するときに書いておくこと
- 変更したい業務と、変更後にどうなっていればよいか（機能名ではなく業務で書く）
- 今回は触らない範囲（画面・帳票・連携先を名指しで）
- 影響範囲の調査を含むか、別途にするか
- テストは誰がどこまでやるか（業務側で確認する範囲を明記）
- 設計書の更新を成果物に含めるか
いちばん効くのは2つ目の「触らない範囲」です。何を直すかだけ伝えると、相手は関連しそうな箇所も安全側に含めます。触らない範囲を名指しで書くと、その分の調査とテストが見積もりから落ちます。
5つ目も忘れないでください。前の章で書いたとおり、設計書の更新を毎回入れておくと次回以降の調査費用が下がります。1回分だけ見れば追加費用ですが、3回目以降で回収できることが多い項目です。
追加費用が出たときの見分け方
着手後に追加費用の相談が来るのは、レガシーの改修では珍しくありません。問題は、それが妥当かどうかです。判断は「事前に分かり得たかどうか」で切り分けられます。
妥当な追加は、開けてみて初めて分かった事象です。設計書に載っていない処理が見つかった、他システムとの連携が想定より多かった、といったものが該当します。これは調査を尽くしても事前には出てこないので、受け入れる合理性があります。
一方で、こちらが依頼書に書いた前提が守られていない追加は別です。触らないと明記した範囲の作業が入っている、当初の見積書に「調査を含む」と書いてあったのに調査費用が別で来る、といったケースは前提の食い違いなので、金額の前に前提を確認してください。判断に迷うときは、見積もりの危険サインを見抜く60項目チェックシートで前提の抜けや責任範囲の曖昧さを点検すると、確認すべき箇所が絞れます。
レガシーシステムの改修についてよくある質問
- Q. 帳票を1枚追加するだけで数百万円は高すぎませんか？
- A. 高く見えますが、構造的な理由があります。開発の規模と工数は比例せず、IPAの調査では規模の0.56乗という関係が報告されています。規模が10分の1でも工数は3割弱にしかならないため、小さい改修ほど1行あたりは割高になります。ただし金額の妥当性は別問題なので、内訳で実装・調査・テストがどう積まれているかを確認してください。
- Q. 改修と刷新はどこで線を引けばよいですか？
- A. 土台（言語・稼働環境・データベース）を替えるなら刷新、業務の変更に合わせて中身を直すなら改修です。改修の見積もりに土台の作り替えが混ざっていたら範囲がずれています。また、あと何年使うかが決まっていないと判断できないので、先に残す年数を決めてください。
- Q. リファクタリングは頼んだほうがよいのでしょうか？
- A. 単独で頼むのはおすすめしません。外から見た動きが変わらない作業なので、発注側が成果を確認できず、検収の基準も作れないためです。代わりに「今回触る範囲は次に直しやすい形にして、設計書も更新する」と依頼書に書き、改修に紐づける形にしてください。
- Q. 毎年改修費が上がっていくのはなぜですか？
- A. 改修のたびに例外処理が積み上がり、影響範囲が追いにくくなるためです。同じ規模の改修でも、調査とテストの工数が年々増えます。抑えるには、改修のたびに設計書を更新してもらうことを保守契約の作業範囲に入れるのが有効です。
- Q. 追加費用を断ることはできますか？
- A. 中身によります。開けてみて初めて分かった事象なら受け入れる合理性がありますが、依頼書で触らないと明記した範囲の作業や、当初「調査を含む」としていた費用の別請求は前提の食い違いです。金額を交渉する前に、どちらに当たるかを整理してください。
