システムリプレイス（既存システムの刷新・置き換え）を成功させるための考え方と実践ポイントをまとめる。
目次
1. 基本原則
| 原則 | 内容 |
|---|---|
| 目的を先に決める | 「古いから替える」ではなく、解決したい課題（保守コスト、性能、拡張性、セキュリティ、人材確保など）を明文化する |
| ビッグバンを避ける | 一括切替はリスクが集中する。段階的に移行できる設計を優先する |
| 現行仕様は「コードが正」 | ドキュメントは古いことが多い。実際の挙動・データを根拠にする |
| いつでも戻れる状態を保つ | 各ステップにロールバック手段を用意する |
| 計測できないものは比較できない | 移行前に現行の性能・品質指標を取得しておく |
2. よくある失敗パターン
- 現行踏襲（As-Is完全再現）の罠：不要な機能・バグまで再現し、コストだけ増える
- スコープの膨張：リプレイスに便乗して新機能を大量に追加し、完了しなくなる
- 暗黙仕様の見落とし：バッチの実行順、丸め処理、文字コード、締め処理など、誰も把握していない挙動が切替後に発覚する
- データ移行の過小評価：データ品質の悪さ（不整合、重複、想定外の値）で移行が遅延する
- 長期間の二重開発：現行側の改修が止まらず、新システムが追いつかない
- 業務部門の不在：情シス・開発だけで進め、受入テストで大量の手戻りが出る
3. フェーズ別のポイント
3.1 構想・企画
- リプレイスの目的・成功指標（KPI） を定義する
- 例：運用コスト30%削減、障害件数半減、リリース頻度向上
- 選択肢を比較する：リプレイス / リファクタリング / リホスト（基盤のみ移行）/ SaaS置き換え / 現状維持
- 投資対効果とやらない場合のリスク（EOL、属人化、セキュリティ）を整理する
- 経営層・業務部門の合意を取り、オーナーを明確化する
3.2 現状分析（As-Is）
- 機能棚卸し：機能一覧を作り、利用実績（アクセスログ、実行ログ）で使われていない機能を洗い出す
- インターフェース棚卸し：外部連携先、ファイル連携、API、DBリンク、バッチを全て洗い出す
- データ分析：テーブル数・件数・データ品質・保持期間を把握する
- 非機能要件の実測：レスポンスタイム、スループット、ピーク負荷、バッチ処理時間
- 暗黙仕様の掘り起こし：現行担当者・利用部門へのヒアリング、コードリーディング
3.3 要件定義（To-Be）
- 機能を 「移行する／廃止する／改善する／新規」 に分類する
- 現行踏襲の範囲を明確にし、「現行どおり」という曖昧な要件を禁止する
- 新機能の追加は最小限にし、リプレイス完了後のフェーズに回す
- 非機能要件は現行の実測値をベースラインに数値で定める
3.4 移行方式の選定
| 方式 | 概要 | 向いているケース |
|---|---|---|
| ストラングラーパターン | 機能単位で少しずつ新システムへ置き換え、最終的に旧システムを撤去 | Webシステム、API化しやすい構成 |
| 段階移行（拠点・部門・機能別） | 対象範囲を分けて順次切替 | 拠点や事業部ごとに独立性が高い |
| 並行稼働 | 新旧を同時に動かし結果を突き合わせる | 会計・給与など正確性が最重要 |
| 一括移行（ビッグバン） | 一度に全面切替 | 規模が小さい、または分割が不可能な場合のみ |
段階移行を実現する技術要素
- ルーティング層（API Gateway、リバースプロキシ）で新旧の振り分け
- フィーチャーフラグによる切替制御
- 新旧データの同期（CDC：Change Data Capture、双方向同期など）
- 腐敗防止層（Anti-Corruption Layer）で旧システムのモデルが新システムに侵食するのを防ぐ
3.5 設計・開発
- 旧システムの設計をそのまま写さず、ドメインを再整理する
- 旧システムとの互換が必要な部分は境界に閉じ込める
- 自動テストを早期に整備する（特に回帰テスト・比較テスト）
- 現行システム側の改修は凍結 or 最小化し、改修が入る場合は新システムへの反映ルールを決める
3.6 データ移行
- 早期に着手する（最もスケジュールリスクが高い領域）
- データクレンジングの方針と責任者（業務側）を決める
- 移行ツール・スクリプトは何度でも再実行できるように作る（冪等性）
- 移行リハーサルを複数回実施し、所要時間と手順を確定させる
- 検証方法を定義する
- 件数照合
- 金額・数量などの合計値照合
- サンプリングによる項目単位の突合
- 移行対象外データ（過去データ）の参照手段を用意する（アーカイブ、参照専用環境など）
3.7 テスト
- 現新比較テスト：同じ入力を新旧に与え、出力（画面、帳票、ファイル、DB）を自動比較する
- 本番データ（マスキング済み）でのテスト：テストデータでは出ないパターンを検出する
- 性能テスト：現行のピーク時を再現した負荷で実施する
- 外部連携テスト：連携先を巻き込んだ結合テストを計画的に行う
- 業務部門による受入テスト（UAT）：実業務シナリオで確認する
- 切替リハーサル：本番手順書どおりに通しで実施する
3.8 切替（カットオーバー）
- 判定基準（Go / No-Go） を事前に合意する
- 切替手順書をタイムライン形式で作り、担当者・所要時間・確認項目を明記する
- ロールバック手順と判断期限を決めておく（「何時までに問題が解消しなければ戻す」）
- 業務影響の少ない時期・時間帯を選ぶ（繁忙期・月末締めを避ける）
- 段階移行ではカナリアリリース（一部ユーザーから順次）を活用する
3.9 安定化・旧システム撤去
- 切替後はハイパーケア期間を設け、問い合わせ・障害対応体制を厚くする
- KPIを計測し、構想段階の目標に対する達成度を評価する
- 旧システムの撤去計画を立てる（ライセンス解約、データアーカイブ、サーバ廃棄）
- 撤去しないと二重運用コストが残り続ける
- 得られた知見（暗黙仕様、移行の課題）をドキュメント化する
4. 体制・プロジェクト管理
- 業務部門をプロジェクトに組み込む：要件確認、データクレンジング、受入テストに責任を持ってもらう
- 現行システムの有識者を確保する：退職・異動リスクがあれば早期に知識移転を行う
- 意思決定者を明確にする：スコープ追加・削除の判断を迅速に行える体制にする
- 小さく区切ってリリースし、進捗を「完成した機能」で測る
- リスク管理表を作り、データ移行・外部連携・性能を重点的に監視する
5. チェックリスト
計画時
- リプレイスの目的とKPIが明文化されている
- リプレイス以外の選択肢と比較済み
- 機能・IF・データの棚卸しが完了している
- 廃止機能が業務部門と合意されている
- 移行方式（段階／並行／一括）が決まっている
- 現行の非機能指標を実測済み
開発・テスト時
- 現行システムの改修凍結ルールがある
- 現新比較テストが自動化されている
- データ移行リハーサルを複数回実施した
- 外部連携先と結合テストを実施した
- 性能テストを本番相当の負荷で実施した
切替時
- Go / No-Go判定基準が合意されている
- 切替手順書とロールバック手順書がある
- 切替リハーサルを実施した
- ハイパーケア体制が組まれている
- 旧システムの撤去計画がある
6. まとめ
- 目的を明確にし、スコープを絞る
- 現状を実データ・実挙動で把握する
- 段階的に移行し、常に戻れる状態を保つ
- データ移行とテストに最も時間をかける
- 業務部門を巻き込み、旧システムの撤去まで完遂する