データ基盤リプレイスが繰り返し失敗する原因は、技術選定の問題ではなく「現行システムの負債を新基盤に持ち込む構造」にあります。2年がかりのリプレイスプロジェクトが頓挫した。あるいは完了したのに結局使われない。もっと辛いのは、その反省を踏まえた2回目のリプレイスもまた失敗する――。本記事では、リプレイスが「2回失敗する」構造的メカニズムを解き明かし、段階的移行（ストラングラーフィグ・パターン）による突破口を示します。
データ基盤リプレイスの失敗率が異常に高い理由
業界調査によると、大規模データ基盤の移行プロジェクトの50〜70%が当初の計画通りに完了していません。遅延、予算超過、スコープの縮小、最悪の場合は中止。なぜこれほど失敗率が高いのでしょうか。
最大の原因は、リプレイスが「技術的な作業」として認識されていることです。実際には、リプレイスは「組織の暗黙知を可視化し、移植する作業」であり、その難易度は技術選定の比ではありません。
| フェーズ | 計画時の想定 | 実際に起きること | 根本原因 |
|---|---|---|---|
| 要件定義 | 現行機能を棚卸しして3ヶ月で完了 | ドキュメントがなく、棚卸しに6ヶ月以上 | 暗黙知のドキュメント化不足 |
| 開発・移行 | 新技術で効率的に再構築 | 「現行踏襲」要求で旧設計をそのまま再現 | 思考停止の「現行踏襲」 |
| 並行運用 | 1ヶ月の検証期間で切り替え | 差異の検証に3ヶ月以上、二重コスト | 二重運用コストの過小評価 |
| 完了判定 | 全機能移行で一気に切替 | 追加要件が膨張し、完了が見えない | ステークホルダーの「ついでに」要求 |
「2回失敗する」構造的メカニズム
メカニズム1: 現行の暗黙知がドキュメント化されていない
現行基盤には、長年の運用で蓄積された暗黙的なビジネスロジックが埋まっています。「月末のバッチで売上を再計算するときは、キャンセル分を○○条件で除外する」「このテーブルのNULLは”未取得”と”該当なし”の2種類の意味がある」。こうした暗黙知は、担当者の頭の中にだけ存在し、ドキュメントには書かれていません。新基盤への移行時にこれらが欠落し、「数字が合わない」という致命的な問題を引き起こします。
メカニズム2: 「現行踏襲」という名の思考停止
リプレイスの目的は本来、旧基盤の課題を解決することです。しかし実際のプロジェクトでは「まず現行と同じものを新基盤で動かす」が金科玉条になり、新技術のメリットを一切活かせない設計が出来上がります。Snowflakeに移行したのにオンプレミス時代のバッチ設計をそのまま再現する、BigQueryを導入したのにストアドプロシージャを大量に移植する。技術は変わっても設計思想が変わらなければ、同じ問題が再発するのは必然です。
メカニズム3: 移行期間中の「二重運用」コストの過小評価
旧基盤と新基盤を並行運用する期間のコスト・工数は、ほぼ確実に過小評価されます。「両方のシステムを維持する運用負荷」「データの整合性検証にかかる工数」「ユーザーが2つのシステムを行き来する混乱」。これらが計画に含まれておらず、プロジェクト中盤でリソースが枯渇します。
メカニズム4: ステークホルダーの「ついでに」要求
リプレイスプロジェクトは、関係部門にとって「長年溜めていた要望を通す千載一遇のチャンス」です。「ついでにこのレポートも新基盤で作り直して」「ついでにリアルタイム連携もできるようにして」。一つひとつは合理的に見える要求が積み重なり、スコープは当初の2倍に膨張します。
【2回失敗するループ構造】
旧基盤の限界を認識
|
v
リプレイス決定 --> 現行踏襲 + 追加要件
|
v
スコープ肥大化
|
v
遅延・品質低下・予算超過
|
v
妥協して「完了」宣言
|
v
新基盤にも負債が蓄積
|
v
「次こそは」2回目のリプレイス決定
|
v
(同じ構造で再び失敗)1回目と2回目の失敗パターンの違い
1回目の失敗は「技術選定が悪かった」と総括されがちです。2回目は「プロジェクトマネジメントが弱かった」と総括されがちです。しかし本質は同じで、「現行基盤の問題の構造的理解なしにリプレイスを始めている」点にあります。
| 比較項目 | 1回目の失敗 | 2回目の失敗 |
|---|---|---|
| 失敗の認識 | 「技術選定を間違えた」 | 「PMが弱かった」 |
| 実際の原因 | 現行基盤の暗黙知を把握せず移行を開始 | 前回と同じ構造で再び移行を開始 |
| よくある対策 | 「次は別の技術（例: Snowflake）にしよう」 | 「次はPMOを強化しよう」 |
| 対策が効かない理由 | 技術を変えても設計思想が同じなら結果は同じ | 管理を強化してもスコープ膨張の構造は変わらない |
解決策――「ストラングラーフィグ・パターン」によるリプレイス
一括リプレイス（ビッグバン方式）の代わりに、段階的に旧システムを絞め殺す「ストラングラーフィグ・パターン」を採用します。ストラングラーフィグ（絞め殺しの木）は、宿主の木に巻きついて徐々に置き換えていく植物に由来する名前です。
Step 1: 現行基盤の全体像を可視化する
リプレイスを始める前に、まず現行基盤のデータリネージ（データの流れ）を可視化します。どのソースからどんなデータが流入し、どのパイプラインで加工され、どのレポートに使われているかを全体像として把握します。この作業にはdbt + データカタログ（Datahub、Amundsen等）の導入が有効です。暗黙知のヒアリングも並行して実施し、ビジネスロジックのドキュメント化を進めます。
Step 2: 影響範囲の小さい部分から新基盤に移行する
全体を一括で移行するのではなく、影響範囲が小さく、依存関係が少ないパイプラインから新基盤に移行します。特に新規のユースケースは最初から新基盤で構築します。旧基盤のデータを新基盤にレプリケーションし、新規の分析ニーズはすべて新基盤で対応する、という二段構えが効果的です。
Step 3: 移行と改善を同時に行わない
「まず同じものを新基盤で動かす」→「動いてから改善する」の2ステップを厳守します。移行フェーズで改善も同時にやろうとすると、「数字が合わない原因が移行の問題なのか改善の問題なのか切り分けられない」状態に陥ります。退屈に見えますが、この分離が成功の鍵です。
Step 4: 撤退基準を事前に設定する
各マイルストーンにGo/No-Goの判断基準を設定します。「Phase 1の移行でデータ整合性が95%を下回った場合は、原因究明完了まで次のPhaseに進まない」「累積コストが予算の120%を超えた場合はスコープを再定義する」。撤退基準がなければ、プロジェクトはズルズルと延命されます。
【ストラングラーフィグ・パターンの段階的移行】
Phase 0: 現行基盤の可視化・暗黙知のドキュメント化
|
v
Phase 1: 新規ユースケースを新基盤で構築
| 旧基盤 [==================] 100%
| 新基盤 [==] 10%
v
Phase 2: 影響の小さいパイプラインを移行
| 旧基盤 [==============] 70%
| 新基盤 [========] 40%
v
Phase 3: コアパイプラインを段階的に移行
| 旧基盤 [======] 30%
| 新基盤 [================] 80%
v
Phase 4: 旧基盤の完全停止
旧基盤 [] 0%
新基盤 [==================] 100%
※ 各Phase間にGo/No-Go判定ゲートを設置リプレイスに成功した企業の共通点
事例1: ECプラットフォーム――段階的移行で12ヶ月完了
年商500億円規模のECプラットフォームは、オンプレミスのDWHからSnowflakeへの移行を段階的に実施しました。まず新規の広告分析ダッシュボードをSnowflake上で構築し、そこで得た知見を基にコアの売上分析パイプラインを3ヶ月かけて移行。最終的に旧DWHの完全停止まで12ヶ月で完了しました。成功の鍵は「Phase 0で2ヶ月かけて現行の全パイプラインをdbtでモデル化した」ことでした。
事例2: 金融機関――3回目の挑戦でストラングラーフィグを採用
地方銀行グループのシステム子会社は、2回のビッグバン型リプレイスの失敗を経て、3回目はストラングラーフィグ・パターンを採用しました。まず規制報告用のレポーティング基盤（影響範囲が明確で検証しやすい）から移行を開始。各規制レポートの数値を旧基盤と新基盤で照合し、100%一致を確認してから次へ進むアプローチで、18ヶ月かけて段階的に完了しました。「急がば回れ」が組織の合言葉になったそうです。
まとめ――リプレイスは「技術プロジェクト」ではなく「組織変革プロジェクト」
- データ基盤リプレイスの失敗の本質は技術選定ではなく、現行基盤の暗黙知の把握不足にある
- 「現行踏襲」「ついでに要求」「二重運用の過小評価」が失敗の構造を作る
- ビッグバン型リプレイスではなく、ストラングラーフィグ・パターンによる段階的移行が有効
- 「移行」と「改善」を分離し、まず同じものを新基盤で動かしてから改善する
- 各マイルストーンにGo/No-Go判定を設定し、撤退基準を事前に合意する
DE-STKでは、データ基盤の移行戦略策定から段階的実行まで、リプレイスプロジェクトを成功に導く支援を提供しています。「何度やっても上手くいかない」とお悩みの際は、構造的な問題の診断からお手伝いします。