はじめに

システム移行は、ITエンジニアにとって一大イベントです。ハードウェアの保守期限切れ、OSやミドルウェアのサポート終了、クラウドへの移行、組織再編に伴うシステム統合など、移行が必要になる理由はさまざまですが、いずれにも共通するのは「失敗が許されない一発勝負」という緊張感ではないでしょうか。
テストやリハーサルと違い、本番移行はやり直しがききません。年末年始やゴールデンウィークといった限られた停止期間の中で完遂できなければ、翌営業日にシステムが使えず、顧客の業務が止まってしまいます。だからこそ、想定外の問題が起きる前提で、緻密な計画と備えが求められます。
本記事では、システム移行を確実に進めるために注意すべきポイントを、ITILのサービストランジション（Service Transition）のプラクティスに沿って整理します。あわせて、IPAの非機能要求グレードや、移行失敗の事例も引用しながら、「自分の現場ではどうだろうか」と振り返っていただける内容を目指します。

第1章：「移行」と「移植」は違う～transition と transformation～

まず、本題に入る前に言葉の整理をしておきましょう。日本語で「移行」とまとめて呼んでしまいがちですが、英語にすると transition（トランジション） と transformation（トランスフォーメーション） という2つの概念が存在します。この2つを混同すると、移行プロジェクトの目的やリスクの見積もりを誤ってしまいます。

transition（移行・移植） とは、サービスや構成要素を、ある環境から別の環境へ「移し、稼働させる」活動を指します。ITILにおいてサービストランジションは、サービスデザインで設計したITサービスを稼働環境へ移動・導入し、ユーザが速やかに利用できるようにする一連のライフサイクル段階と位置づけられています。本記事の中心テーマであり、サーバの入れ替えやデータの移送、リリース、切り替えといった「移す」作業がこれにあたります。

一方の transformation（変革・変容） は、単に移すだけでなく、業務プロセスやアーキテクチャそのものを作り変えることを指します。たとえばオンプレミスの基幹システムを廃止してクラウドへ刷新するようなケースでは、データを移すだけでなく業務のやり方も変わります。
ここで重要なのは、まず、本題に入る前に言葉の整理をしておきましょう。日本語で「移行」とまとめて呼んでしまいがちですが、英語にすると transition（トランジション） と transformation（トランスフォーメーション） という2つの概念が存在します。この2つを混同すると、移行プロジェクトの目的やリスクの見積もりを誤ってしまいます。
transition（移行・移植） とは、サービスや構成要素を、ある環境から別の環境へ「移し、稼働させる」活動を指します。ITILにおいてサービストランジションは、サービスデザインで設計したITサービスを稼働環境へ移動・導入し、ユーザが速やかに利用できるようにする一連のライフサイクル段階と位置づけられています。本記事の中心テーマであり、サーバの入れ替えやデータの移送、リリース、切り替えといった「移す」作業がこれにあたります。
一方の transformation（変革・変容） は、単に移すだけでなく、業務プロセスやアーキテクチャそのものを作り変えることを指します。たとえばオンプレミスの基幹システムを廃止してクラウド型ERPへ刷新するようなケースでは、データを移すだけでなく業務のやり方も変わります。
ここで重要なのは、「transitionのつもりが、transformationだった」というギャップが失敗を招くという点です。後ほど紹介するTSB銀行の事例は、まさに「データを移すだけ」のはずが、システムのアップグレードを同時に行う大規模な変革になっていたために破綻しました。自分のプロジェクトが「ただ移すだけ」なのか「作り変えるのか」を、関係者全員で正しく認識することが、すべての出発点です。「transitionのつもりが、実はtransformationだった」というギャップが失敗を招くという点です。後ほど紹介するTSB銀行の事例は、まさに「データを移すだけ」のはずが、システムのアップグレードを同時に行う大規模な変革になっていたために破綻しました。自分のプロジェクトが「ただ移すだけ」なのか「作り変えるのか」を、関係者全員で正しく認識することが、すべての出発点です。

第2章：ITILサービストランジションが教える移行の全体像

移行に深く関わるITILのプラクティス（プロセス）を整理すると、主に次のものが挙げられます。

第一に、移行の計画立案およびサポート（Transition Planning and Support） です。これは移行に必要なリソースを調整し、サービス中断のリスクを識別・管理・コントロールする活動です。移行の方針、役割と責任、標準、成功基準を定義し、移行の準備が整っているか（レディネス）を確認したうえで、構成のベースラインを取得します。本記事で後述する「移行計画・スケジュール・体制」は、まさにこのプラクティスの中核です。
第二に、変更実現 です。移行は本番環境への大きな変更そのものですから、影響を評価し、適切にスケジューリングされているかを確認する必要があります。重大な変更は変更委員会の審議を経て承認されます。
第三に、リリース管理および展開管理 です。本番環境への展開が円滑に行われることを保証します。一括（ビッグバン）か段階的かといった展開方式の選択もここに含まれます。
第四に、サービス資産管理および構成管理（CMDB） です。新しいサービスの構成要素を把握し、依存関係を明らかにして、移行後の運用・保守を容易にします。
第五に、サービスの妥当性確認およびテスト です。移行したサービスが期待された価値を生むかを検証します。後述する失敗事例のほとんどは、このテストの不足に起因していると言っても過言ではありません。
そして最後に、ナレッジ管理 です。移行で得た知見をサービスナレッジ管理システム（SKMS）に蓄積し、次の移行や運用に活かします。これは前回のブログでも触れた「次に活かせるかどうかで価値が決まる」という考え方と共通します。これらのプラクティスは独立して存在するのではなく、相互に作用して移行という一大イベントを支えています。

第3章：移行計画とスケジュールに盛り込むべきこと～IPA非機能要求グレード「移行性」を手がかりに～

ITILが「計画立案とサポートが重要だ」と説いても、では具体的に何を計画書に書けばよいのでしょうか。ここで参考になるのが、IPA（情報処理推進機構）が公開している 非機能要求グレード です。非機能要件を「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6大項目で整理したツールで、発注者と受注者の認識齟齬を防ぐ定番として広く使われています。

このうち大項目「移行性」には、現行システムからの移行方針を記載します。IPAの解説によれば、移行性の要件として少なくとも次の観点を示す必要があるとされています。

スケジュール（移行時期） については、移行作業計画から本稼働までの期間を定めます。半年以上に及ぶ場合は、工程を明示したマスタースケジュールとして示すことが望まれます。特に計画停止を伴う場合はユーザへの影響が大きいため、例外発生時の切り戻し時間や事前バックアップの時間まで考慮した、十分なフィージビリティ（実現可能性）の確認が求められます。

移行方式（段階移行） については、一括移行・段階移行・並行運用・パイロット移行といった方式の選択を行います。拠点ごと、機能ごとの段階移行や、一部ユーザに先行解放するカナリアリリースなど、システム特性に応じた方式を選びます。一括移行は短期間で済む反面トラブル時の影響が大きく、段階移行や並行運用はリスクを局所化できる反面コストと手間がかかる、というトレードオフを理解しておく必要があります。

移行対象（機器・データ） については、ハードウェアだけでなく、ソフトウェア、アプリケーション、利用サービスなどを含めてレイヤごとに方針を定めます。変更するレイヤだけでなく、あえて変更しないレイヤとその理由も明示することで、移行の全体像が明らかになります。

移行データ量 は、見積もりを左右する極めて重要な要素です。冒頭で紹介した「データ移行で大失敗した9つの原因」を語る現場経験者も、足りなかった視点として「各テーブルの項目数と、移行データ件数」を挙げています。項目数が多ければ要件確認・設計・開発・テストのすべての工数が増えますし、データ件数が多ければ想定外データの混入確率が上がり、処理速度のチューニングも必要になり、大量データゆえの想定外も発生します。データ量を軽視した見積もりは、ほぼ確実に破綻します。

そして忘れてはならないのが 切り戻し（切戻し）計画 です。IPAの非機能要求グレードでも、移行失敗時に旧システムへ復帰する手順を定めることが求められています。「移行作業中に不具合が出たら旧システムに戻す」という手順は多くの現場で用意されますが、問題は本番稼働の後に不具合が顕在化したときです。後述する全銀システムの事例では、まさにこの「稼働後の切り戻しは現実的に困難」という壁が立ちはだかりました。
加えて、自治体システムの標準化やガバメントクラウド移行のように、データの権利の帰属、対象データ項目・形式、関係者の役割分担まで仕様として明示すべきケースもあります。移行計画書には、スケジュール・体制・移行対象データ・移行データ量に加え、これらの合意事項を漏れなく盛り込みましょう。

第4章：体制とテスト～失敗事例が教える「やってはいけない」～

ここまで「何を計画すべきか」を述べてきましたが、ここでは国内外の代表的な移行失敗事例を取り上げ教訓を抽出します。

事例1：英国TSB銀行の移行障害（2018年・欧州）

英国のTSB銀行は2018年4月、親会社であるスペインのサバデル銀行のシステムへ約500万人の顧客口座を移行しました。ところが稼働直後にシステムがクラッシュし、190万人もの顧客が口座にアクセスできなくなり、他人の口座が見えてしまうといった事態まで発生しました。最終的にTSBは約3億3000万ポンドの損失を被り、英金融規制当局（FCAおよびPRA）から約4865万ポンドの制裁金を科されました。
調査報告書が指摘した問題点は、システム移行の「やってはいけない」教訓が詰まっています。データを移行すると同時にシステムをアップグレードする「移植と変革の同時実行」、リスクを十分理解しないままの「ビッグバン移行」、本番相当の負荷をかけたフルボリュームテストの欠如（2つのデータセンターのうち1つは負荷テストすらされていなかった）、そして主要ITベンダ（親会社系列のSabis）の能力を第三者として適切に評価しなかったガバナンスの欠如です。
これはまさに第1章で述べた「transition のつもりが transformation だった」失敗であり、ITILの妥当性確認・テストのプラクティスと、ベンダ管理を含む変更管理のガバナンスが機能しなかった事例と言えます。

事例2：データ移行に共通する「準備不足」（普遍的教訓）

個別の大規模事例だけでなく、規模を問わず繰り返されるのが「準備不足」による失敗です。移行データのフォーマット変換を確認せずデータ不整合が発生する、テスト環境で十分な移行テストを行わない、バックアップが適切でない―こうした典型的なミスはと十分なテスト、そして確実なバックアップさえあれば避けられる可能性が高いです。

特に、現行システムと新システムでデータ構造が大きく異なる場合のマッピング作業は、移行タスクの中でも最も重要かつ時間のかかる工程です。ここを間違えると、後続でどれだけ正確に作業しても意味がありません。例外パターンを最初にチェックリスト化し、担当者の経験やスキルに依存しない仕組みにしておくことが肝要です。

これらの事例から導かれる体制面の教訓を整理すると、次のようになります。スキルマップを整備して作業ペアの品質を安定させること、現行システムの業務仕様を理解した人材を確保すること、ベンダ任せにせず自社担当者も新旧のギャップ把握に同席すること、そして「何が正か」をベンダと明確に合意することです。これらはIPA「 移行性」が求める体制要件であり、ITILの計画立案・サポートが担保すべき領域でもあります。

第5章：ITILの周辺プラクティスで移行をさらに堅牢にする

サービストランジションの中核プラクティスに加え、ITILの他の考え方を取り入れることで、移行はさらに堅牢になります。

可用性管理とSLA の観点は、移行の停止時間設計に直結します。担当システムが24時間365日のミッションクリティカルなものか、平日日中のみ稼働するものかによって、許容できる停止時間（=移行に使える時間）は大きく異なります。SLAで定めた可用性目標と整合した移行ウィンドウを設計しなければなりません。

サービス継続管理（BCP） の観点では、移行失敗時の事業継続をあらかじめ計画します。切り戻しはもちろん、切り戻しすら間に合わない場合に「どの業務を優先して復旧させるか」「利用者が代替行動を取れる状態を作れているか」まで踏み込んで備えることが、社会インフラ級のシステムでは求められます。

リスク管理 の観点では、移行のリスクを事前に洗い出し、フィージビリティを確認します。TSBがビッグバン移行のリスクを十分理解しないまま突き進んだのとは対照的に、リスクを定量的に評価し、段階移行やパイロット移行でリスクを局所化する判断が重要です。

そして 継続的改善（CSI） の観点です。移行は一度きりに見えても、リハーサルの結果や、過去の他システムの移行で得た知見を蓄積し、次に活かすサイクルを回すことで、組織としての移行成熟度が高まっていきます。

おわりに

システム移行は、「ただ移すだけ」に見えて、実は計画・体制・テスト・切り戻し・ナレッジのすべてが問われる総合格闘技のような仕事です。本記事では、まず transition（移植）と transformation（変革）の違いを押さえ、ITILサービストランジションのプラクティスに沿って移行の全体像を整理しました。そのうえで、IPA非機能要求グレード「移行性」を手がかりに、移行計画に盛り込むべきスケジュール・体制・移行対象データ・移行データ量・切り戻しを具体化し、実際の失敗事例から教訓を抽出しました。

これらの事例に共通するのは、「障害は必ず発生する」という前提に立ち、十分なテストと現実的な切り戻し、そして組織としての体制を備えていたかどうか、という一点です。移行作業の前に、ぜひご自身の担当システムの移行計画を見返してみてください。移行データ量の見積もりは妥当か、本番稼働後でも切り戻せるか、フルボリュームのテストはできているか――確認すべきことは、決して少なくないはずです。

確実な移行が、発注側と受注側、そして何よりエンドユーザーにとっての価値につながることを願っています。

参考文献

独立行政法人情報処理推進機構（IPA）「非機能要求グレード2018」 https://www.ipa.go.jp/digital/hikinou/ent03-b.html

NTTデータ技術ブログ（Zenn）「非機能要求グレードの歩き方 Vol.18 D移行性」https://zenn.dev/nttdata_tech/articles/0ac5abb945b200

Computer Weekly「TSB hit with huge fine after IT migration disaster」（2022）https://www.computerweekly.com/news/252528519/TSB-hit-with-huge-fine-after-IT-migration-disaster

Slaughter and May / Panorama Consulting「4 Lessons Learned From The TSB Software Failure」https://www.panorama-consulting.com/tsb-software-failure/

IT Process Wiki「ITIL Service Transition」 https://wiki.en.it-processmaps.com/index.php/ITIL_Service_Transition