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