移行を「個別案件」で終わらせない：Migration Factoryで実現する大規模モダナイゼーション

Migration Factoryとは何か

基幹システムの刷新やクラウド移行に着手した企業の多くは、最初の1件を「プロジェクト」として扱います。専任チームを組み、方式を検討し、移行し、稼働を確認して解散する。これ自体は間違いではありません。問題は、対象が1件では終わらないことです。

移行すべきアプリケーションが数十本、数百本ある状況で同じやり方を繰り返すと、案件ごとに方式がばらつき、品質基準が担当者によって変わり、前回の教訓は引き継がれません。3件目でも1件目と同じ調査に同じ時間をかけている——多くの現場で実際に起きていることです。

Migration Factoryは、この構造を変えるための考え方です。移行を単発のプロジェクトの連続としてではなく、標準化されたパターン・共有プラットフォーム・繰り返し可能なプロセス・蓄積されるナレッジを備えた「継続的な機能」として設計します。工場という比喩は、画一的な大量生産を意味するのではありません。同じ工程を何度も通す前提で、工程そのものを改善し続けるという意味です。

重要なのは、これが製品名でもツール名でもないという点です。移行自動化ツールを導入すればMigration Factoryになる、というものではありません。土台になるのは次の4つです。

なぜこのモデルが重要になるのか

Migration Factoryという発想が広まった背景には、いくつかの現実的な事情があります。

対象がひとつではない

メインフレームやオンプレミス環境から移すべき資産は、たいてい単独では存在しません。相互に呼び合い、同じデータを参照し、同じバッチ枠を共有しています。1本ずつ個別に判断していくと、全体としての整合性が失われます。

期限が同時に来る

ハードウェアやミドルウェアの保守終了、データセンター契約の満了、クラウド利用方針の変更——これらは個別案件の都合と関係なく、同じ時期に重なります。「順番に片付ける」だけでは間に合わない状況が生まれます。

ばらつきがコストになる

案件ごとに構成が異なると、運用の手順も監視の設定もバラバラになります。移行が終わった瞬間から、今度は「移行後の多様性」が保守コストとして跳ね返ってきます。

ナレッジが残らない

もっとも見えにくい損失がこれです。移行の判断根拠、つまずいた箇所、対処法は、プロジェクト終了とともに散逸します。次のチームは同じ落とし穴を再発見することになります。

Migration Factoryを構成する6つの要素

運用モデルとして成立させるには、次の6つの機能が揃っている必要があります。どれか一つが欠けると、他が機能しても全体としては個別案件の集合に戻ってしまいます。

AIをどこに置くか

この6要素のうち、AIがもっとも効果を発揮するのは01（可視化）と04（品質ゲート）です。ソースコードの分類、依存関係の抽出、失われたドキュメントの再構成、テストケースの生成——いずれも従来は人手で長期間かけていた領域で、所要時間を大きく圧縮できます。

一方で、AIが単独で結論を出せない領域も明確です。レガシー資産に埋め込まれているのはロジックだけではなく、業務上の例外処理と、そうなった経緯だからです。「この分岐は特定の取引先向けの運用ルール」「この丸め処理は会計方針に由来する」といった判断は、静的解析の出力からは復元できません。

チーム設計と責任範囲

Migration Factoryでは、案件ごとに人を集めるのではなく、継続する役割とウェーブごとに編成される役割を分けて考えます。日本のプロジェクトで特に重要なのは、責任範囲を文書で明示しておくことです。曖昧なまま進むと、品質ゲートで判断が止まります。

Migration Factoryの標準的な役割分担（組織規模に応じて兼任も想定）

役割	主な責任	継続性
ポートフォリオオーナー	全体の優先順位、ウェーブ順序の承認、経営への報告	継続
マイグレーションアーキテクト	移行パターンの定義、方式の妥当性判断、例外の裁定	継続
プラットフォームチーム	ランディングゾーン、CI/CD、監視、共通基盤の提供と改善	継続
ウェーブチーム	担当ウェーブの設計・実装・テスト・切替	ウェーブ単位
アプリケーションオーナー	業務仕様の確認、例外ルールの説明、受入判断	業務単位
QA・セキュリティ	品質ゲートの基準策定と検証、セキュリティ要件の担保	継続
FinOps	コスト可視化、方式比較への費用の入力、稼働後の最適化	継続
運用・SRE	監視設計、切替時の一次対応、安定稼働の確認	継続
PM・ブリッジSE	進捗と論点の管理、日本語での合意形成、オフショア側との橋渡し	継続

標準プロセス（リファレンス）

ウェーブごとに通る標準工程です。順序を毎回変えないことが、比較可能な進捗管理とナレッジ蓄積の前提になります。オレンジの工程は、通過できなければ次に進まない判断ポイントです。

多国籍環境での運用

オフショアやニアショアを含む体制で運用する場合、進め方の前提が地域によって異なることを織り込んでおく必要があります。

日本：合意形成と証跡を重視する進め方

• コミュニケーション：結論だけでなく、判断に至った過程と検討した代替案を含めて共有する。
• 報告：定例での文書ベースの報告。課題は発生時点で早めに共有し、解決後にまとめて報告しない。
• 意思決定：合意形成に時間をかけるぶん、決定後の変更は少ない。前提として計画に織り込む。
• 品質ゲート：証跡の粒度を細かく設計する。テスト結果は「合格」だけでなく、比較対象と条件を残す。
• 訴求点：安定稼働、業務を止めないこと、リハーサルと切戻しの備え、日本語での対応体制。

グローバル：非同期での自律的な進行

• コミュニケーション：タイムゾーンをまたぐ前提で、意思決定に必要な情報を書面に集約する。
• 報告：ダッシュボードによる常時可視化。定例は例外と判断事項に絞る。
• 意思決定：権限委譲の範囲を事前に定義し、その範囲内では確認を挟まず進める。
• 品質ゲート：自動化された基準への準拠を重視。人手のレビューは例外時に限定する。
• 訴求点：ビジネス成果、拡張性、セキュリティとコンプライアンスの作り込み、測定可能なデリバリー。

韓国：実行速度と可視性の両立

• コミュニケーション：要点を先に、結論と次のアクションを明確に。
• 報告：進捗ダッシュボードによる短サイクルの可視化。
• 意思決定：短期間のPoCで方式を確定し、早期に本格展開へ移す傾向。
• 品質ゲート：自動化とDevSecOpsの組み込みを前提に、速度を落とさず統制を効かせる。
• 訴求点：運用安定性、コスト最適化、自動化、拡張性。

ベトナム：段階的な投資とナレッジ移管

• コミュニケーション：技術用語は英語のまま使いつつ、業務要件は現地語で確認する運用が現実的。
• 報告：コストと進捗を同じ画面で見られる形式が好まれる。
• 意思決定：既存資産を活かしながら段階的に投資する判断が多い。全面刷新を前提にしない。
• 品質ゲート：自動化を進めつつ、担当者への知識移転を工程に組み込む。
• 訴求点：予算に合った移行ロードマップ、既存システムの活用、チーム体制の柔軟な拡張。

測定すべき指標

Migration Factoryが機能しているかどうかは、感覚ではなく指標で確認します。以下は測定対象の例です。基準値は組織や資産の性質によって大きく異なるため、初回ウェーブの実績を基準線として設定するのが現実的です。

よくある失敗

1. 運用モデルを決める前にツールを買う

移行自動化ツールは、通すべき工程が定まっていて初めて効果を出します。プロセスもパターンも未定のまま導入すると、ツールに合わせて工程を歪める結果になり、かえって例外処理が増えます。先に決めるのは、誰が何を判断するかです。

2. カットオーバーの速さだけを最適化する

切替当日を短くすることに注力するあまり、安定化と旧環境の廃止が後回しになるケースです。旧環境が止まらなければコストは二重にかかり続けます。移行が「終わった」と言えるのは、廃止まで完了した時点です。

3. 安定していない工程を自動化する

手順が固まっていない作業を自動化すると、例外のたびに自動化そのものを修正することになり、保守負荷が増えます。手動で3回同じ手順を通せてから自動化する、という順序が現実的です。

4. FinOpsを最後に持ち込む

移行が完了してからコストを集計すると、タグ付けもアカウント設計も後追いになり、どのアプリがいくらかかっているのか分解できません。コストの可視化は、ランディングゾーンの標準として最初から組み込む必要があります。

5. チームごとに別々のデータを持つ

資産一覧をアーキテクトが、進捗をPMが、コストを財務が、それぞれ別の表で管理している状態です。数字が合わないため会議が突合作業に費やされ、判断が遅れます。単一の情報源を決めることは、ツール選定よりも先の合意事項です。

6. 本稼働後にプロジェクトを終了する

稼働開始をゴールに設定すると、最適化・廃止・プレイブック更新が実施されません。結果として、次のウェーブは前回と同じ工数を要します。学習を残さない移行は、何件やっても組織能力になりません。

BAPの役割

BAPは、レガシーシステムのモダナイゼーション、COBOLからJavaへのコード移行、クラウド移行、データベース移行を手がけています。Migration Factoryの文脈では、次のような形での関与が想定されます。

• 現状調査と資産の可視化：棚卸し、依存関係の整理、業務部門へのヒアリングによる仕様の再構成。
• PoCによる方式検証：本格展開の前に、変換方針・目標アーキテクチャ・テスト方式を実証し、工数と品質の見積り精度を上げる。
• ウェーブ単位での段階的移行：業務単位・データ単位での分割と実行。
• 開発とテスト：Java/Springによる開発、Web画面・帳票の再構築、データ移行、単体からユーザー受入テストまでのエンドツーエンドの品質保証。
• デリバリー体制：オフショア、オンサイト、ハイブリッド。日本語・英語・韓国語・ベトナム語での対応。
• 移行後の運用保守とナレッジ移管：安定稼働の支援と、顧客側チームへの引き継ぎ。

Migration Factoryを外部に丸ごと委託することは、本来の目的と矛盾します。再現可能な能力は、顧客側に残らなければ意味がないからです。BAPが担うのは、最初のウェーブで型をつくり、標準とプレイブックを整備し、運用できる状態で引き渡すところまでです。

まとめ

Migration Factoryは、新しいツールカテゴリではありません。移行を何度も繰り返すという前提を受け入れ、そのための工程・基盤・データ・体制を先に用意しておく、という運用上の選択です。

導入判断はシンプルです。移行対象が数本であれば、個別プロジェクトとして進めたほうが速く、安く終わります。数十本以上あり、期限が重なり、同じ判断を何度も繰り返す見通しがあるなら、標準化への初期投資が回収される可能性が高くなります。

そして、どちらを選ぶにしても最初にやることは変わりません。資産の棚卸しと依存関係の可視化です。規模と構造が見えて初めて、どのモデルが適切かを議論できます。