モダナイゼーションベンダーの選び方｜8つの評価基準と評価シート

📌 この記事の要約
レガシーシステム刷新の成否は、どのモダナイゼーションベンダーを選ぶかで大きく左右されます。本記事では、依頼先の4タイプを比較したうえで、8つの評価基準と、そのまま使える評価シートを紹介します。あわせて、見積もりに潜む危険信号や、選定結果を稟議資料にまとめる方法も解説します。

モダナイゼーションベンダーは、価格や「自動変換率」の高さだけで選ぶべきではありません。見るべきポイントは、次の3つです。

1. 現行システム調査（アセスメント）の深さ
2. 新システムが旧システムと同じ動作をすること（現行踏襲）を、テストでどう保証するか
3. プロジェクト終了後に、社内へナレッジを移転できるか

マイグレーションの失敗は、「コードを変換できなかった」ことが原因になるケースはまれです。多くは、隠れた仕様の見落とし、新旧比較テストの不足、そして新システムが再びブラックボックス化することから生じます。

本記事は、複数のシステム移行ベンダーを比較検討している情報システム部門の責任者、CIO、購買部門の方に向けて、評価基準・評価シート・RFP項目・選定の5ステップをまとめたものです。モダナイゼーションとマイグレーションの違いを先に整理したい方は、モダナイゼーションとマイグレーションの違いもあわせてご覧ください。

モダナイゼーションのベンダー選びが成否を分ける理由

モダナイゼーションにおけるベンダーは、単に「コードを書く会社」ではありません。自社でも全体を把握しきれなくなったシステムを読み解き直す、重要なパートナーです。ベンダー選びを誤ると、スケジュールの遅延にとどまらず、脱却したかったはずの問題そのものを再生産しかねません。

まずは、レガシー刷新がなかなか進まない背景から確認しましょう。

レガシー刷新が進まない本当の理由：「丸投げ」が生むブラックボックスの再生産

レバテックの調査（2025年8月公表、n=516）によると、レガシーシステムが引き起こしている問題として、45.0%が「システム機能のブラックボックス化」を挙げています。また、保守・運用における課題では、53.5%が「エンジニア不足」と回答しました。

同社代表は、多重下請け構造やベンダーへの丸投げによって社内に開発ノウハウが蓄積されず、属人化やブラックボックス化を招いていると指摘しています（出典：@IT「レガシー刷新、進まぬ現実」）。

つまり、従来と同じ発想でベンダーを選べば、新システムも10年後には再びブラックボックスになるおそれがあります。本記事で「ナレッジ移転」を評価基準に加えているのは、そのためです。

さらに、ベンダー選定に使える時間そのものも限られつつあります。

「2035年の崖」：メインフレーム撤退でベンダー選定に使える時間は限られている

富士通は、2030年度にメインフレームの販売を終了し、2035年度にサポートを終了すると発表しています。日立製作所も、2017年にメインフレームの筐体製造から撤退しました（出典：ITmedia エンタープライズ）。

大規模なマイグレーションは、調査・設計・テスト・本番移行まで含めると複数年に及ぶことも珍しくありません。2035年から逆算すると、ベンダー選定に着手すべき時期は、多くの企業が想定しているより早く訪れます。需要が集中すれば、優れたベンダーから先に予約が埋まっていくでしょう。

こうした状況のなかで、ベンダー選びには典型的な失敗パターンがあります。

ベンダー選びでよくある3つの失敗パターン

1. 「自動変換率○%」だけで選んでしまう
   自動変換率は、構文エラーなく変換できたコードの割合を示すにすぎません。新システムが業務どおりに動くことを証明するものではありません。
2. 見積もりがコード変換までしか含んでいない
   画面・帳票・外部インターフェースなど、変換後に生じる動作差異への対応が「追加費用」として後から発生します。
3. 業務部門が選定に参加していない
   受け入れテストの段階で初めて「旧システムと違う」と判明し、調整が長引いて納期が遅れます。

3つに共通するのは、ベンダーを「変換の成果」で評価し、「結果を保証する力」で評価していない点です。具体的な評価基準に入る前に、まずは依頼先のタイプを整理しておきましょう。

モダナイゼーション・システム移行の依頼先は4タイプ｜特徴と向いているケース

「どんな案件にも最適なベンダー」は存在しません。大切なのは、プロジェクトの規模・目的・フェーズに合ったタイプを選ぶことです。主な依頼先は、次の4タイプに分けられます。

大手SIer

• 強み：大規模なミッションクリティカルシステムの実績、プロジェクト全体への責任対応力、財務的な信頼性
• 注意点：費用が高くなりやすく、多重下請け構造によって実際の担当者とユーザー企業の距離が遠くなりがちです。
• 向いているケース：金融の勘定系、公共系、超大規模なメインフレーム移行

コンサルティングファーム

• 強み：戦略・ロードマップ策定、将来アーキテクチャの設計、組織の変革マネジメント
• 注意点：実装は外部に委託されることが多いため、誰がコードを書き、誰がテストするのかを確認する必要があります。
• 向いているケース：刷新の方向性がまだ定まっていない構想段階

移行ツール・専門ベンダー

• 強み：COBOLやPL/Iなど特定言語向けの自動変換ツールを持ち、変換スピードが速い
• 注意点：保証範囲の確認が欠かせません。変換だけを保証するのか、業務上の動作まで保証するのかを明確にしましょう。
• 向いているケース：ツールが得意とする言語でのリホスト・リライト

オフショア開発会社（ベトナムなど）

• 強み：コード解析・変換・テストといった工数のかかる工程に、豊富な人材を投入できます。コスト競争力があり、体制も拡張しやすいのが特長です。
• 注意点：品質はブリッジSE（BrSE）の日本語力と品質管理体制に左右されます。認証や具体的なプロセスの確認が必要です。
• 向いているケース：コストを抑えながら品質も確保したい中堅〜大企業。特にテスト量が多い案件

4タイプの違いを一覧にすると、次のとおりです。

比較項目	大手SIer	コンサル	専門ベンダー	オフショア
費用	高い	高い	中程度	低〜中程度
上流工程（戦略・現行調査）	◎	◎	△	○（会社による）
実行力（変換・テスト）	○	△	◎（対応言語内）	◎
範囲・契約の柔軟性	△	○	△	◎
主なリスク	多重下請け・高コスト	実装は外部委託	保証範囲が限定的	言語・品質管理

実際には、上流工程をコンサルやSIerに任せ、変換・テストを専門ベンダーやオフショアに委託する組み合わせも多く見られます。どの体制を選ぶにしても、次に紹介する8つの評価基準が、モダナイゼーションベンダーを比べる共通の物差しになります。

モダナイゼーションベンダーを見極める8つの評価基準

ここでは8つの評価基準を、ベンダーに確認すべき質問とあわせて紹介します。②④⑤⑧は、一般的なベンダー比較では見落とされがちですが、プロジェクトのリスクを最も大きく左右する基準です。

① 類似案件の実績（業種・規模・言語スタック）と第三者認証

「マイグレーションの実績は何件か」だけを聞いても、判断材料にはなりません。業種、規模（コード行数・人月）、移行元と移行先の言語という3つの軸で、自社に近い案件があるかを確認しましょう。クラウド移行を100件手がけた会社でも、COBOLからJavaへの移行が得意とは限りません。

あわせて、CMMI（プロセス成熟度）、ISO/IEC 27001やプライバシーマーク（情報セキュリティ）といった第三者認証も確認します。

確認すべき質問：「当社のシステムに最も規模と言語が近い事例を、人月とフェーズごとの期間を含めて教えてください」

② 現行システム調査（アセスメント）の深さ

最も重要でありながら、最も比較されていない基準です。見積もりや計画の精度は、ベンダーが現行システムをどこまで理解しているかで決まります。

十分なアセスメントでは、ソースコードだけでなく、DB、バッチ、外部インターフェース、モジュール間の依存関係、コードに埋もれた業務ロジックまで把握します。優れたモダナイゼーションベンダーは、正式な見積もりの前に、リスク一覧・影響範囲・移行順序の提案といった具体的な調査結果を提示してくれます。

確認すべき質問：「見積もりの前に、何を調査し、どのような資料を納品していただけますか？」

評価すべき領域の詳細は、レガシーシステムアセスメント｜評価7領域と報告書の中身で解説しています。

🟡 ベンダー比較の前に、自社システムの現状を可視化しませんか？

HBLABのAI診断ツールなら、ソースコードをもとに技術構成・リスク・移行の難易度を短時間で可視化できます。ベンダーを比較する際の「物差し」として、まずは無償でお試しください。

👉 無償AI診断を試してみる

③ 移行方式（リホスト・リライト・リビルド等）の提案根拠

移行方式には、インフラだけを移すリホスト、言語を変換するリライト、作り直すリビルドなどがあり、部分ごとに組み合わせることもあります。優れたシステム移行ベンダーは、どのシステムにも同じ方式を提案することはありません。

調査結果・事業目標・予算をふまえて、なぜその方式なのかを説明できるかを評価しましょう。各方式の概要は、マイグレーションの手法と種類をご参照ください。

確認すべき質問：「当社のシステムのうち、どこをリライトし、どこをリビルドすべきか、その理由もあわせて教えてください」

④ テストと現行踏襲の保証方法

マイグレーションでは、テストが最も工数のかかる工程の一つです。だからこそ問うべきは「テストをするかどうか」ではなく、「新システムが旧システムと同じ動作をすることを、どう証明するのか」です。

ベンダーが次の仕組みを持っているかを確認しましょう。

• 現新比較テスト：同じ入力データを新旧システムで処理し、結果を突き合わせる
• 網羅範囲が明確に定義された回帰テスト
• 業務部門と最初に合意した受け入れ基準
• 資格（ISTQBなど）を持つQAチーム

確認すべき質問：「保証範囲はどこまでですか？画面・帳票・外部インターフェースも含まれますか？」

⑤ AI活用の実効性と品質ゲート

「AIマイグレーション」を打ち出すモダナイゼーションベンダーは増えています。AIは現行調査やドキュメント作成、コード変換の期間短縮に大きく貢献します。一方で、AIは「一見正しいが業務ロジックが誤っている」コードを生成することもあります（ハルシネーション）。

評価の際は、次の3点を具体的に確認しましょう。

1. AIが担う範囲と、人が責任を持つ範囲はどこか
2. AIの出力をどう検証しているか（レビュー、自動テスト、次工程へ進む前の品質ゲート）
3. 工数削減の効果を実績値で示せるか、それとも宣伝文句にとどまるか

確認すべき質問：「AIを活用した事例について、フェーズごとの工数削減率と、出力の検証方法を教えてください」

⑥ プロジェクト体制・コミュニケーション・セキュリティ

PMは誰か、窓口は誰か、報告の頻度、要件変更の管理方法を確認します。オフショアベンダーの場合は、ブリッジSEの日本語力や相互レビューの仕組みもあわせて確認しましょう。

セキュリティ面では、ソースコードやデータをどこで扱うのか、誰がアクセスできるのか、本番データをマスキングするのかを確認します。

確認すべき質問：「実際に当社を担当される方はどなたですか？契約前にお会いできますか？」

⑦ 見積もりの透明性と費用範囲（TCOで比較）

良い見積もりは、調査・設計・変換・テスト・本番移行といったフェーズごとに内訳が分かれ、前提条件が明記されています。他社より極端に安い見積もりには、どの作業が省かれているのかを確認しましょう。

また、初期費用だけでなく、移行後の保守・運用費を含めた5年間のTCO（総保有コスト）で比較することをおすすめします。

確認すべき質問：「この見積もりには、変換後の動作差異への対応と、本番稼働後のサポートが含まれていますか？」

⑧ ナレッジ移転と移行後の保守体制（ベンダーロックインを防ぐ）

前述の調査が示すとおり、丸投げはブラックボックス化の根本原因です。ベンダーが設計書、新旧ロジックの対応表、運用ノウハウを社内チームに引き継いでくれるかを評価しましょう。

優れたベンダーは、プロジェクト後に自社に過度に依存させない（ベンダーロックインを防ぐ）一方で、必要に応じて保守を担う選択肢も用意しています。

確認すべき質問：「本番稼働後、当社の社内チームにはどのような資料が引き継がれますか？」

8つの基準は、数値化して同じ物差しで比較してこそ役に立ちます。次に、そのまま使える評価シートを紹介します。

【そのまま使える】ベンダー評価シートと提案依頼書（RFP）の項目

重み付けスコアリング表のつくり方

プロジェクトの目的に応じて各基準に重みを設定し、1〜5点で採点して加重合計を算出します。以下は、リスク低減を重視する基幹システム刷新の例です。

#	評価基準	重み	A社	B社	C社
①	類似案件の実績・認証	10%
②	現行調査（アセスメント）の深さ	20%
③	移行方式の提案根拠	10%
④	テストと現行踏襲の保証	20%
⑤	AI活用と品質ゲート	10%
⑥	体制・コミュニケーション・セキュリティ	10%
⑦	見積もりの透明性・TCO	10%
⑧	ナレッジ移転・保守	10%
	加重合計スコア	100%

コストを重視する場合は⑦の重みを上げても構いません。ただし、②と④の重みは15%を下回らないようにしましょう。この2つは、納期遅延や予算超過のリスクに最も大きく影響する基準だからです。

RFP（提案依頼書）に必ず入れたい10項目

各社に同じ前提で提案してもらうために、RFPには次の項目を盛り込みましょう。

1. 刷新の目的（保守コスト削減、EOL対応、AI・データ活用の基盤づくりなど）
2. 現行システムの概要（言語、コード行数、DB、バッチ、外部インターフェース）
3. 移行範囲と、対象外とする範囲
4. 移行方式への要望（またはベンダーに理由付きで提案を求める旨）
5. 現行調査の範囲・方法と納品物
6. テスト方法、受け入れ基準、保証範囲
7. AIの活用範囲と検証方法
8. プロジェクト体制、報告方法、変更管理
9. セキュリティ要件（データの取り扱い場所、アクセス権限）
10. 本番稼働後のサポート、ナレッジ移転、保守条件

提案説明会でベンダーに聞くべき質問リスト

• 当社のシステムに最も近い事例は何ですか？規模と人月は？
• 正式な見積もりの前に、何を調査しますか？
• 保証範囲はどこまでですか？現行踏襲をどう証明しますか？
• 現新比較テストはどのように実施しますか？
• AIはどのフェーズで使い、出力は誰が確認しますか？
• この案件で最も大きなリスクは何だとお考えですか？
• 動作差異が見つかった場合、その対応費用は見積もりに含まれますか？
• 実際に当社を担当されるのはどなたですか？
• 本番稼働後、どのような資料を引き継いでいただけますか？
• 小規模な調査やPoCから始めることは可能ですか？

評価シートを使えば、モダナイゼーションベンダーを公平に比較できます。ただし、一度見かけただけで再検討すべき「危険信号」もあります。

見積もり・提案書で見抜くべき4つの危険信号

提案書や見積もりに次のような特徴が見られる場合は、そのシステム移行ベンダーを慎重に再検討しましょう。

「自動変換率○%」だけを強調している

自動変換率が高くても、システムが正しく動くとは限りません。提案が変換率の話に終始し、テストや保証に触れていない場合、そのベンダーは「コードの成果」で成功を測っており、「業務の成果」では測っていない可能性があります。

テスト工数が極端に少ない／現新比較の記載がない

見積もりに占めるテストの割合が小さすぎる場合、その分の費用は受け入れ段階で「追加費用」として戻ってくる可能性が高いでしょう。

現行調査なしで一括見積もりを出してくる

調査をせずに出された一括見積もりは、まだ見えていないリスクがバッファとして上乗せされているか、最悪の場合、まったく考慮されていないことを意味します。

設計書・ドキュメントなど成果物の範囲が曖昧

設計書、ロジックの対応表、運用資料のうち何を納品するのかが明記されていない提案は、ブラックボックスを再生産するリスクが非常に高いと言えます。

これらの危険信号を見極めたうえで、選定を順序立てて進めていきましょう。

ベンダー選定から契約までの5ステップ

Step1 刷新の目的と移行範囲を整理する

保守コストの削減、EOLへの対応、人材不足の解消、AI・データ活用の基盤づくりなど、何を優先するかを明確にします。目的が異なれば、評価シートの重みも変わります。進め方の全体像は、レガシーシステム刷新の進め方で解説しています。

Step2 ロングリストからショートリストへ絞り込む

最初の5〜10社から、①実績と⑥体制・セキュリティを基準に3〜4社へ絞り込み、RFPを送付します。この社数であれば、評価チームに過度な負担をかけずに比較できます。

Step3 アセスメント・PoCで実力を見極める（スモールスタート）

いきなり大型契約を結ぶのではなく、1〜2社にシステムの一部を対象とした現行調査やPoCを依頼しましょう。調査報告書の質こそが、②と⑤を最も正確に評価する方法です。

Step4 評価結果を稟議・社内説得資料にまとめる

日本企業では、ベンダーの選定に複数階層の合意が必要です。稟議資料には、次の内容を盛り込むと説得力が高まります。

• 重み付け評価シートと、重みを設定した理由
• 各案の5年間TCO比較
• 主なリスクと、ベンダーによる対策（特にテストと現行踏襲の保証）
• 客観的な根拠としての調査・PoCの結果

数値と根拠がそろった資料があれば、経営層や業務部門から「なぜこの会社なのか」と問われた際にも、情報システム部門が明確に説明できます。

Step5 契約形態を選ぶ（請負・準委任・段階契約）

• 請負契約：範囲が明確に定まっている場合に適しています。
• 準委任契約：範囲が変わりうる調査・設計フェーズに適しています。
• 段階契約：調査は準委任で契約し、その結果をもとに変換・テストを請負で契約します。発注者・ベンダー双方のリスクを最もバランスよく抑えられる方法です。

オフショア（ベトナム）ベンダーを活用する際のポイント

国内IT人材の不足と人件費の上昇を背景に、モダナイゼーションでオフショアを検討する日本企業が増えています。アクセンチュアも、日本側がレガシー資産の分析と仕様定義を担い、オフショアチームが低コストかつスピーディーに構築するという役割分担を紹介しています（出典：アクセンチュア「モダナイゼーションにおける海外拠点活用」）。

オフショアが力を発揮する工程：解析・変換・テスト

ソースコード解析、コード変換、そして特にテストは、工数が大きく、標準化しやすい工程です。オフショアの人材力とコスト優位性が、最も高いROIを生む領域と言えます。

よくある懸念（日本語・品質・セキュリティ）と見極め方

懸念	確認方法
日本語・コミュニケーション	契約前にブリッジSEと面談し、日本語で書かれた成果物のサンプルを確認する
品質	CMMI・ISTQBなどの認証、具体的なレビューと品質ゲートのプロセス
セキュリティ	ISO/IEC 27001、プライバシーマーク、データの取り扱い場所とアクセス権限
プロジェクト管理	報告頻度、管理ツール、日本側の責任者

HBLABのモダナイゼーション・マイグレーション支援

HBLABは、ベトナムを拠点とするオフショア開発会社として、日本企業のレガシーシステム刷新を支援しています。ここでは、前述の8つの評価基準に対するHBLABの取り組みをご紹介します。

• ② アセスメント：HBLABのAI診断ツールが、ソース・DB・バッチを解析し、依存関係やリスクの特定、業務ロジックの抽出を行います。技術調査、評価、移行戦略、業務仕様の整理から、コード変換、単体テスト、結合テストまでを一貫してカバーし、開発過程で30種類以上のドキュメントを整備します。
• ④ テスト・保証：設計書から単体テストを生成し、ロジックカバレッジ100%・合格率100%を実現。回帰テストにも対応しています。HBLABはISTQB® Gold Partnerです。
• ⑤ AIと品質ゲート：AIプラットフォーム「Migurei」が、アセスメント→設計→移行→テストの全工程を統合。手作業と比べて工数を30〜50%削減し、調査・ドキュメント作成期間を40%短縮します。
• ①⑥ 実績・認証：CMMI レベル3、ISO/IEC 27001:2022、プライバシーマークを取得。ビジネスレベルの日本語を話すブリッジSEが窓口を務めます。

主な事例

事例	規模	工数・期間	内容・成果
Java Struts → Spring（販売契約管理システム）	約20万行	約150人月／9か月	調査1か月、実装4か月、テスト3か月、本番移行1か月
VB → ASP.NET（倉庫管理システム／AI活用）	約60万行	約200人月／1年	調査・設計工数を50〜60%削減、コード変換工数を40〜60%削減

VB6/VBA、Java Struts、COBOL/RPG、Lotus Notes、ネイティブアプリ→Flutterなど、移行パッケージの詳細はHBLABのモダナイゼーション支援サービスをご覧ください。

🟡 モダナイゼーションのベンダー選定でお悩みなら、まずは無料相談へ

現行システムの状況をお伺いし、最適な移行方式・進め方・概算スケジュールをご提案します。評価シートを使った比較検討のご相談も歓迎です。

👉 無料相談を申し込む

👉 まずは1分で試せる無償AI診断

よくある質問（FAQ）

Q1. モダナイゼーションの費用相場は？

費用は、規模（コード行数）、移行元・移行先の言語、移行方式によって大きく変わります。「単価」で比較するのではなく、現行調査を経た見積もりと5年間のTCOで比較することをおすすめします。調査なしの一括見積もりは、精度が低くなりがちです。

Q2. 相見積もりは何社に依頼すべき？

一般的には3〜4社が適切です。少なすぎると比較が難しく、多すぎると評価チームの負担が大きくなります。

Q3. 期間はどのくらいかかる？

規模によって異なります。たとえば約20万行のシステムでは、調査・実装・テスト・本番移行を含めて約9か月かかった事例があります。より大規模なシステムでは、複数年に及ぶこともあります。

Q4. オフショアのモダナイゼーションベンダーでも品質は担保できる？

認証を受けた品質管理プロセス（CMMI、ISTQBなど）、日本語が話せるブリッジSE、明確な新旧比較テストの仕組みがあれば、十分に担保できます。大型契約の前に、調査やPoCで確認しましょう。

Q5. AIを使ったマイグレーションは信頼できる？

AIは、現行調査・ドキュメント作成・コード変換の期間を大きく短縮します。ただし、信頼性は品質ゲートと、人による検証の責任体制に左右されます。AIの出力をどう検証しているのか、ベンダーに具体的に確認しましょう。

まとめ

モダナイゼーションベンダー選びは、価格や自動変換率だけで判断すべきではありません。4タイプの依頼先を比較し、8つの評価基準、特にアセスメントの深さ・テストによる現行踏襲の保証・ナレッジ移転を重視して評価しましょう。そのうえで、評価シート・RFP・PoCを活用すれば、根拠のある意思決定ができます。

比較検討の前に第三者の視点で現行システムを調査したい場合は、HBLABがお手伝いします。本記事の8つの基準を、モダナイゼーションベンダー選びの物差しとしてご活用ください。

🟡 モダナイゼーションのご相談はHBLABへ

👉 無料相談はこちら