レガシーシステム刷新事例と移行戦略
刷新の出発点：現行資産の可視化と意思決定指標
レガシー刷新は「新しい技術を入れる」より前に、現行資産を正しく見積もる勝負です。初動で曖昧にすると後半で手戻りが雪だるまになります。まずは機能・データ・運用の棚卸しを1〜2週間で切り上げ、意思決定の軸を固定します。
- 機能棚卸し：使われていない画面・帳票を利用ログで可視化し、廃止候補を確定
- 依存分析：外部IF、バッチ、スケジューラ、権限、監査ログの連鎖を図示
- データ品質：主キー一意性、履歴の整合、参照整合、PIIの混在をサンプル検査
- 非機能指標：SLO（応答時間・可用性）、エラーバジェット、バッチ時間枠
- コスト構造：保守人件費/学習負債/ライセンス/HWを分離しTCOを算出
ここから「リホスト（IaaS移行）」「リプラットフォーム（PaaS化）」「リファクタ（一部改修）」「リプレイス（全面交換）」を比較します。ROIは運用削減と機会損失（発売遅延や障害）を含めて12〜24カ月で回収できるかが目安です。全面切替のリスクが高い場合、ストラングラーフィグパターン＋アンチコラプションレイヤーで、旧APIを汚染させずに新旧共存を設計します。設計判断はアーキテクチャ決定記録（ADR）で根拠を残し、後半で迷わないようにします。
移行戦略の型と切り替え手順
境界から分割する：読み取り優先と顧客価値の近い領域
最初の一手は「読み取り負荷が高く、書き込み副作用が小さい」領域です。検索、照会、ダッシュボード等を新アプリで先行提供し、APIゲートウェイでリクエストを振り分けます。業務ドメインはイベントストーミングで境界づけし、厄介なクロス集計はレポート専用の集約モデルに切り出します。
データ移行の実務：CDC、二重書き込み、リハーサル
データは一括移行だけでは足りません。変更データキャプチャ（CDC）で旧DBの更新をイベント化し、新DBへ継続反映します。書き込みは一時期「二重書き込み＋冪等キー」で両系に反映し、バックフィルで過去分を埋めます。移行リハは本番相当データで3回以上、件数・合計金額・ハッシュ値で整合チェック。切替直前は変更凍結期間を設け、当日の作業手順・担当・平均所要時間・中断時の復旧条件をプレイブック化します。
検証と安全な切替：コントラクトテスト、シャドウトラフィック
- 契約テストで旧IF仕様を固定し、後方互換の破壊を検知
- 本番リクエストを複製するシャドウトラフィックで新系の誤差を可視化
- ブルーグリーンで一括切替、クリティカル機能はカナリアで1〜5%から段階展開
- フィーチャーフラグで即時無効化を可能にし、ロールバックはデータの巻き戻し可否まで事前検証
実務ではドキュメント欠落や古いSQLの意図解釈がボトルネックになります。コード読解やテスト観点の洗い出しにChatGPTやClaude、ユニットテスト雛形の生成にCopilot、依存関係の要約やクエリ最適化の仮説検証にGeminiを補助で使うと初動が速くなります。AIの提案は必ずプロファイリングとベンチで裏取りするのが前提です。
身近な企業活用例：中堅小売での在庫遅延の解消
VB6＋オンプレOracleでPOS・EC・在庫を連携し、夜間バッチで在庫更新していました。セール日にはECが在庫切れを起こし、店舗とデータが乖離。全面リプレイスを志向してマイクロサービスを一気に導入しましたが、切替当夜にカート在庫が乱れ、深夜の手作業補正が連日発生。3週間で緊急是正が3回、顧客クレームと返品コストが増大しました。
方針を転換し、ストラングラーで在庫読み取りから分割。旧DBにCDCを導入し、在庫更新イベントを新在庫クエリサービスへ配信。まずECの在庫表示のみ新系に切替え、書き込みは旧系のまま。2週間のシャドウ運用で誤差0.2%まで収束させ、次に「家電カテゴリのみ二重書き込み」を開始。フィーチャーフラグでトグル可能にし、障害時は即時オフ。カナリア配信で段階拡大し、最終的にPOSの販促クーポン連携まで移行しました。
- 導入6カ月で夜間バッチ2時間→15分、在庫表示のSLO99.9%を達成
- 障害時の平均復旧時間：120分→30分
- 返品・キャンセル率：セール期で-28%
- 月間運用コスト：監視標準化と自動化で-20%
移行中は、ChatGPTでVB6の意図やレガシークエリの要約を得てレビューの起点にし、Copilotでテストスタブを生成、Claudeで業務フローの文章化、GeminiでAPI仕様の差分整理を実施。AI提案は必ずペアレビューと負荷試験で検証し、契約テストに落として再現性を確保しました。
現場で使えるチェックリストと落とし穴
- 非機能の引継ぎ：レポートの締め時間、監査ログ保持、ジョブ優先度を新系に明記
- ID・権限：旧系の部門ロールをRBACに写像、ゼロトラスト前提の分割
- バージョン互換：通貨・時区間・丸め規則を決定し、差異は変換層で吸収
- 監視とSLO：メトリクス名とアラート閾値を先に確定、エラーバジェットで展開速度を調整
- リハ計画：データ凍結期間、ロールバック条件、意思決定者の待機体制をプレイブック化
- 契約・ライセンス：監査要件、PII移送のDPA、使用許諾の移転可否を事前精査
- 文書化：ADR・API定義・運用Runbookをコード同居で継続メンテ
レガシー刷新は技術だけでなく、運用と業務の習慣を安全に更新する仕事です。受託開発ソリューション事業の現場では、発注側の制約や既存運用を尊重しつつ、段階移行・検証自動化・意思決定の可視化をセットで提供することで、無理のないスピードと納得感を両立させます。中長期で保守しやすい負債構造に変えることが、最終的なコスト最適化とチームの健全性につながります。
