段階移行で実現したレガシー刷新：止められない業務を支えるシステム再構築のユースケース
はじめに：レガシー脱却の現場に求められる「止めずに変える」戦略
システム開発会社や受託開発パートナーが直面するなかでも、難易度が高いとされるプロジェクトの1つが「レガシー刷新」です。特に、日々の業務を絶え間なく続けなければならない物流や医療、金融といった業種では、現行システムの全面停止を前提としたリプレイスは不可能に近く、「止めずに変える」ことが唯一の現実解となります。
本記事では、物流業界の業務基幹システムに対して「段階移行（フェーズドマイグレーション）」というアプローチでリニューアルを進めた実例を紹介しながら、受託開発会社として求められる実践知や、設計・実装上の勘所を掘り下げていきます。
プロジェクト背景：止められない業務の現場での課題と制約
対象企業は全国規模で倉庫と配送センターを運営する中堅物流会社で、利用していた業務システムは15年以上前にPHP4＋MySQLで構築されたもの。以下のような深刻な課題を抱えていました：
- 独自仕様が蓄積されたスパゲッティコードで構成された業務ロジック
- ドキュメントが残っていない仕様やDB構成
- VPN＋物理サーバによるレガシーな運用構成
- 運用中に業務ロジックを含むSQL文がDBに直接保存されており、処理内容が不明
それにも関わらず、日々の出荷処理は完全自動化されており、20分の停止すら大きな業務影響を及ぼすため、従来型の「全面リプレイス＋一斉切替」は許されない状況でした。
要件定義と戦略立案：業務とシステムの分離を意識したフェーズ設計
受託開発チームでは、既存業務の洗い出しと技術的分析を通じて、3つの段階的なフェーズに分けた移行戦略を立案しました。重要だったのは「機能単位」ではなく「接続単位」「運用単位」「負荷単位」でフェーズを分けた点です。
フェーズ1：外部依存をAPI層で切り離す
- 他社サービス（配送伝票発行API、請求業務連携など）との連携部分を新APIゲートウェイで抽象化
- 新旧システムの双方がAPIゲートウェイ経由で外部連携する構造とし、段階移行後も一貫して利用可能な基盤を確保
- この時点では旧システム本体には手を加えず、外周部から再構築
フェーズ2：新UI＋BFF導入による漸進的置き換え
- 既存画面構成を踏襲しながらReactベースでモダンUIを再設計
- BFF（Backend for Frontend）レイヤーを挟み、旧DBと新DBの両方にアクセス可能な設計へ
- 読み込みは旧DB、書き込みは新DBに誘導し、夜間に差分同期を行うことで移行の整合性を確保
フェーズ3：バッチ処理と業務ルールの再設計・統合
- 日次・週次のバッチ処理（在庫引当や出荷分配）を再設計
- 各処理をステートレスなAPI化し、ジョブスケジューラー（Cloud Scheduler）で順次呼び出す構成に刷新
- 業務ルールを業務フローベースで明文化し、ドキュメントの整備と属人性の排除を並行実施
技術スタックとインフラ構成：レガシーとの共存とクラウドネイティブ化の両立
- フロントエンド：React＋Tailwind CSSによる構造化されたUIコンポーネント群
- API層：NestJS（GraphQL）＋Apollo Serverでクエリ設計とスキーマ管理を一元化
- DB構成：MySQLからPostgreSQLへ段階的に移行、一部スキーマは互換性維持
- インフラ：Google Cloud（Cloud Run, Cloud SQL, Pub/Sub）を利用しつつ、旧システムはオンプレ環境で併存運用
- 認証基盤：Firebase Auth（2FA＋IP制限あり）により管理者権限を分離
特筆すべきは、API層で旧システムのロジックや依存構造を包み込むことで、徐々にレガシー依存を減らす構成にできた点です。
UI/UX設計の工夫：現場主導の慣性維持と操作負担の最小化
- 旧UIのショートカットキー、フィールド配置を再現し、作業効率の低下を防止
- 入力ミス防止のためのリアルタイムバリデーションとUndo機能を実装
- 操作ログや自動保存による「意図せぬロスト」の最小化
- 現場スタッフとの週次レビューでプロトタイプ検証を繰り返し、確実な導入につなげた
移行後の定量・定性成果：段階移行が生んだ継続的改善
- 夜間バッチ処理の平均所要時間：3時間 → 45分へ短縮
- 月間トラブル発生件数：21件 → 2件以下に減少
- マスタ管理の内製化により、設定変更の開発依存度を70％削減
- 開発期間中も一度も業務停止が発生せず、運用継続率100％を達成
業務影響を最小限にとどめたうえで、改善効果を段階的に体感できた点は、現場からも高い評価を受けました。
開発パートナーとして評価された力：技術力＋戦略力＋対話力
このプロジェクトで評価されたのは、単なるモダナイゼーションの実装力ではありません。
- 現行業務に対する深い理解と、その可視化・分解スキル
- 「段階的に変えるための設計・交渉力」：非同期構成・フェーズ分割・UI互換対応など
- 現場・社内他部門・外部ベンダーとの対話を通じた折衝と調整能力
特に、ベンダーロック状態の旧配送APIとの仕様折衝、社内インフラチームとのGCP導入交渉などは、システム開発だけでなく「社内政治」に近い領域での関与も必要でした。
まとめ：段階移行は“変えない”設計から始まる
全面リプレイスではなく「少しずつ変える」段階移行という戦略は、今後のレガシー刷新における新たな主流となる可能性があります。
重要なのは、最新技術の導入ではなく「現場が受け入れられる設計」。そして、技術者視点ではなく「現場業務の継続性と変化許容性」を最優先に考えることが、受託開発パートナーとしての真の付加価値となります。
段階移行に挑むすべてのプロジェクトが、「止めずに、壊さずに、変えていく」未来に向けた一歩となることを願ってやみません。
