同じシステムの移行を3社に見積もってもらったら、金額が2倍、3倍と違っていた。稟議で「なぜこの金額なのか」と聞かれても、どの見積についても答えられない。レガシーシステムの移行は、この見積の段階で止まることが少なくありません。
マイグレーションの見積は、ソースコードの行数などの規模を土台に、難易度の見立てを上乗せして決まります。各社の差の大半は、この上乗せ分から生まれます。では、その差は見積書のどこに入っていて、どうすれば金額の理由を説明できる見積が取れるのか。発注側の立場から整理します。規模別の金額の目安はシステムマイグレーションの費用相場にまとめてあります。
見積を決める規模と難易度
マイグレーションの見積は、対象システムの規模を基本に算出します。規模の指標として最もよく使われるのがステップ数、つまりソースコードの行数です。これに画面数、バッチ処理の本数、外部システムとの連携数、移行するデータの量を加えたものが、見積の土台になります。
ただし、行数が同じでも見積は同じにはなりません。行数は作業量の目安にはなりますが、1行を移すのにかかる手間はシステムごとに違うからです。同じ10万行のシステムでも、見積が数倍違うことは珍しくありません。差を生むのは難易度の要因です。
設計書が残っていて、処理が画面ごとに整理され、外部連携もないシステムなら、規模に応じた工数でほぼ収まります。一方で、20年の改修を重ねて1本の処理が数千行に膨らみ、帳票に古い独自部品を使い、会計システムや取引先システムとの連携が何系統もあり、しかも移行と同時にWeb化もしたい。こうしたシステムでは、同じ行数でも工数が何倍にもなります。
難易度に影響する要因は、大きく5つあります。
- 仕様書・設計書の有無。残っていなければ、現行調査の工数が増えます
- 処理の複雑さ。条件分岐が深く、1本の処理が長く、機能同士の依存が多いほど、変換後に確かめる箇所が増えます
- 特殊部品や古いライブラリ。移行先に同等品がなければ、個別に作り直す部分が出ます
- 仕様変更の有無。Web化や画面刷新を同時に行うと、新しい仕様を決める設計工程が加わります
- 新旧比較とテストの難しさ。本番データに個人情報が含まれていれば、その部分を加工したテストデータが必要になり、外部連携先に検証環境がなければ代わりの仕組みを用意する工数が加わります。正しい結果を判断できる人がいるかどうかも影響します
行数から機械的に出せるのは土台の部分だけで、上乗せ分は、どの要因をどの程度重く見るかという見立てで決まります。その見立てはベンダーごとに違い、材料が資料と聞き取りだけなのか、実際のコードまで見ているのかによっても変わります。
難易度要因の見立てが難しいことは、発注側の企業調査にも出ています。IPAのDX白書2023によると、レガシーシステムの課題として「ブラックボックス化によりレガシーシステムの解析が困難」を挙げた日本企業は31.8%、「レガシーシステムが肥大化し、移行の影響度を想定できない」は24.2%でした。2022年度に日本企業538社が回答した複数回答の結果です。
見積書の内訳の読み方
見積書は、現行調査・解析、変換・実装、テスト・検証、移行・切替、プロジェクト管理の工程ごとに分かれているのが一般的です。工程ごとに、どの難易度要因が工数を押し上げるかを対応させると次の表になります。
| 工程 | 工数を押し上げる主な要因 | 見積書で確認したいこと |
|---|---|---|
| 現行調査・解析 | 仕様書の不在、処理の複雑さ、仕様を知る人の不在 | 調査の方法(人手かツールか)と、調査結果が納品されるか |
| 変換・実装 | 処理の複雑さ、特殊部品、仕様変更 | 個別実装の範囲と、仕様変更の分が分けて書かれているか |
| テスト・検証 | 新旧比較の難しさ、外部連携、テストデータの有無 | テストの範囲と方法、全体に占める比率 |
| 移行・切替 | データ移行の量、外部連携、切替可能な日程 | データ移行とリハーサルが含まれているか |
| プロジェクト管理 | 全体の工数に比例 | 全体に対する比率が明示されているか |
ここで気をつけたいのが、リスク分の上乗せです。見積の時点でわからないことが多いほど、ベンダーは不確実性を金額に織り込みます。上乗せ分が「予備費」として独立していれば見えますが、多くは現行調査の工数やプロジェクト管理費、あるいは各工程の工数そのものに分散して入っています。行数に係数を掛けて算出した見積では、係数の中に不確実性がまとめて入っているため、外からはまず見えません。
複数の見積を比べるときは、3つの項目を確認します。
1つ目は対象範囲の定義です。画面数・バッチ数・帳票数・データ移行の有無が、各社で同じ前提になっているかを確かめます。
2つ目はテスト・検証の比率と方法です。マイグレーションでは新旧の動作を突き合わせるテストに全体の4〜5割の工数がかかるのが普通です。ここが極端に薄い見積では、新旧の差異を確かめきれないまま本番切替を迎えるおそれがあります。工程ごとの比重はシステムマイグレーションの期間で解説しています。
3つ目は前提条件と除外事項です。「お客様側で実施」「別途見積」と書かれた項目は、見積額の外側にある作業です。安く見える見積ほど、この欄が長くなりがちです。
推定による見積と実測による見積
従来の見積は、人が資料と聞き取りをもとに規模を推定するところから始まります。開発時の設計書や保守ベンダーへの確認、画面・帳票の一覧から行数や画面数を集め、過去の類似案件から求めた係数を掛けて工数を出す。移行を専業とするベンダーでも、概算は調査シートの記入内容から算出し、正式な見積は移行性の検証を行った後に出すのが一般的です。概算は目安にとどまり、正確な見積にはプログラム資産そのものの分析が必要だという説明も、各社に共通しています。
この方法の弱点は、概算の段階では中身を見ていないことです。行数はわかっても、複雑さや特殊部品、業務上の判断が必要な箇所の数はわかりません。そのため概算の幅が大きくなり、正式な見積が出るまでにも時間がかかります。
当社では、中身を見る作業を概算の前に持ってきています。無料診断の段階でNDA(秘密保持契約)を締結のうえソースコードの一部をお預かりし、AIが解析して規模と複雑さを実測し、その結果をもとに概算を出します。数えるのは、対象ファイル数と行数、画面数、バッチ数、外部連携の系統数、処理の複雑度の分布、そしてコードに書かれていない業務上の判断が必要な箇所の件数です。解析結果は診断レポートにまとめ、本番移行の概算費用と、次の工程である事前検証(PoC)の費用をあわせてご提示します。
※実案件のものではなく、当社で作成したサンプル資料です。
実測から出した概算は、金額の理由を要因ごとに説明できます。複雑度の高いファイルが154本あるのでテストの工数をこれだけ見込んでいる、独自部品が5件あるのでこの部分は個別実装になる、要確認事項が23件あるので概算にこれだけの幅を持たせている、という形です。稟議で「なぜこの金額か」と問われたときも、行数に係数を掛けた数字と違い、要因ごとに答えられます。
解析の結果は、現行システムの棚卸しそのものでもあります。使われていない機能を移行対象から外す判断や、他社の見積を読むときの物差しとしても使えるため、社内検討の材料としてだけでも診断をご利用いただけます。
PoCによる見積の確定
概算は幅を持った数字です。当社では、その幅を狭めて本番移行の見積を確定させる工程としてPoCを置いています。代表的な機能をいくつか選んで実際にAIで変換し、変換済みのコードとレポートを納品する有償の工程です。
PoCで確かめるのは、実際に動作するコードへ変換できるか、主要な機能が新旧で同じ結果を返すかです。あわせて、AIだけでは変換が難しい範囲がどこにどれだけあるか、本番移行に残るリスクは何かを洗い出し、本番全体の期間と費用を見積もれるだけの材料が揃ったかを判断します。
代表機能は、診断の実測をもとに選びます。解析で複雑度が高いとわかった処理、独自部品を使っている帳票、外部連携を含むバッチといった、難しいところをあえて対象にします。難しい機能で変換とテストにかかる工数がわかれば、それより易しい残りの機能は上限を見込めるためです。簡単な画面を変換して動くことを見せるだけのPoCでは、本番の見積は確定しません。
PoCの結果をもとに、本番移行の期間と費用を確定します。代表機能で得た変換とテストの実績が、残りの機能の見積の根拠になります。PoCの費用は本番発注時に移行費用から控除します。結果を見て中止を判断された場合も、変換済みコードとレポートはお手元に残ります。システム構成によっては、PoCを省略して本番移行から始めることも可能です。
当社が手がけた約25万行の基幹システム移行も、PoCから本番移行へ段階的に進めたプロジェクトでした。結果として、従来手法の見積と比べて金額・工期を約60%削減して完了しています。
見積を依頼するときに用意するもの
見積の精度は、お客様側でご用意いただける情報によっても変わります。仕様書は必須ではありません。ソースコードから仕様を読み取れることは仕様書がないシステムの移行で解説したとおりです。代わりに揃えておきたいのは次のものです。
- ソースコード一式へのアクセス。無料診断の段階では一部で構いません
- データベースの定義。テーブル構成がわかる情報で、個人情報を含む実データは初期段階では不要です
- 稼働環境の情報。OS、ミドルウェア、言語やフレームワークのバージョン
- 主要な機能と例外的な処理を説明できる担当者
- 新旧の動作を比較するためのテスト環境。PoC以降に必要になります
- 業務上の正解を判断できる人。コードに書かれていない挙動を再現するか直すかを決める役割です
前半の3つはAIの解析に必要な材料で、後半の3つは人の協力です。業務上の正解の判断だけは、実際の業務を担っておられるお客様にしかできません。判断していただける方が決まっていないと、テストで見つかった差異の扱いが決まらず、その機能の作業が止まります。そのため、この体制の有無は見積の精度だけでなく、移行そのものの成否にも影響します。お客様側にお願いする協力の範囲は、よくあるご質問でもお答えしています。
ソースコードを社外に渡すことに不安がある場合は、ソースコードを生成AIに渡して大丈夫かで確認しておきたい点を整理しています。当社では無料診断の段階からNDAを締結し、お預かりしたコードがAIモデルの学習に使われない形で運用しています。
相見積もりで金額が数倍違うときの見方
相見積もりで金額が数倍違う場合、どこかが不当に高いというより、次の3つのどれかが違っていると考えるのが正確です。
不確実性の扱いの違い：
ソースコードを見ないまま見積を出す場合、わからない部分はリスク分として金額に上乗せされます。診断で不明点を減らしてから見積を出すベンダーと、係数で織り込むベンダーでは、同じシステムでも金額が変わります。高い見積はリスク分が大きいだけのこともあり、その場合は診断やPoCを挟めば下がる余地があります。
移行方式の違い：
プログラムをほぼそのまま新しい環境に載せ替えるリホストはコードをほとんど書き換えないため、新しい言語やフレームワークに書き換えるリライトより工数が小さく、そのぶん古いコードが残ります。同じリライトでも、人手で書き換えるかAIで変換するかで工数は大きく変わります。方式が揃っていない見積は、金額を並べても比較になりません。
範囲の違い：
安い見積では、テストの深さ、データ移行、ドキュメントの納品、移行後の保守のどれかが範囲から外れていることがあります。外れていた作業が必要になれば、後から追加の見積が出てきます。
見比べるときは、まず前提と範囲を揃え、次に工程ごとの比率を比べ、最後に根拠の示し方を比べてください。「実績に基づく係数」としか説明のない見積では、前提が外れたときにどの工程の費用が増えるのかを、発注前に確かめられません。金額の理由を要因ごとに説明できるかどうかは、見積の確度を測る目安になります。
まとめ
お手元の見積書を見直す場合は、最初に各社の前提条件と除外事項の欄を並べ、対象範囲が揃っているかを確かめてください。範囲を揃えても差が残る場合は、テスト・検証の比率と、リスク分をどの工程に含めているかを各社に質問すると、見立ての違いがどこにあるかがわかります。
これから見積を取る段階であれば、行数の推定ではなくソースコードの実測をもとに概算を出し、PoCで確定させる進め方を選ぶと、稟議で金額の根拠を説明しやすくなります。
DEN-NOのAIマイグレーションサービスの無料診断では、NDAを締結のうえシステム概要とソースコードの一部をお預かりし、対象ファイル数や複雑度の分布、要確認事項の件数といった実測値を診断レポートにまとめ、本番移行の概算費用とPoC費用を添えてご提示します。お手元にある他社の見積と前提を突き合わせる材料としてもお使いいただけます。仕様書・設計書がお手元になくても、そのままご相談ください。
よくある質問
Q. 概算の見積と確定した見積は、どう違うのですか？
概算は幅を持った目安で、予算取りや社内検討に使う数字です。当社では、無料診断でAIがソースコードを解析した結果をもとに概算を出し、PoCで代表機能を実際に変換した実績をもとに本番移行の見積を確定します。
Q. 仕様書がなくても見積は出せますか？
可能です。当社の見積はソースコードの解析をもとにするため、仕様書・設計書は必須ではありません。コードに書かれていない業務上の判断が必要な箇所は要確認事項として件数を数え、その分の幅を概算に持たせます。
Q. PoCを省略して本番移行から始められますか？
システム構成によっては可能です。無料診断の解析結果をもとに、PoCが必要かどうかをあわせてご提案します。
Q. 見積の検討材料として、解析だけを依頼することはできますか？
無料診断は社内検討の材料としてだけでもご利用いただけます。解析結果を仕様書・設計書としてまとめるアセスメントを単体でご依頼いただくことも可能で、費用は規模と目的により数十万円から数百万円の範囲です。詳しくはソースコードからAIで仕様書を作るをご覧ください。
