大規模システム開発における移行・切り替え計画の要点

本記事では、大規模システム開発の特徴とマネジメントの難しさに関する、自身の取り組みをお伝えします。

１．はじめに

大規模システム開発において、「データ移行」「業務切り替え」「システム切り替え」は、プロジェクト終盤の作業として扱われがちでが、これらはプロジェクト全体の成否を左右する計画テーマであり、終盤になってから詳細化しても間に合わないケースが少なくありません。本稿では、特に公共系システムを前提に、「年末年始を使った切り替え計画の難しさ」、「移行リハーサルの設計ポイント」、「現行ドキュメント不備やデータ多様化への対応」、「実際に経験した移行トラブルとその教訓」を整理します。

２．データ移行・業務切り替え・システム切り替えは「終盤作業」ではない

まずは、3点を整理します。

①「データ移行」とは、旧システムに蓄積されたデータを、新システムで利用可能な形式で移行する作業を指します。対象はマスタデータやトランザクションデータなどで、件数や内容、移行後のデータが業務処理に支障なく利用できるかという観点で品質を管理します。
②「業務切り替え」とは、業務そのものを旧システムから新システムへ移行することを意味します。ユーザが実施する業務手順や業務上の運用ルール、各種帳票の出力タイミング、申請フローなどを対象に、業務が止まらないことを前提に品質を管理する取り組みです。
③「システム切り替え」とは、業務の稼働主体を旧システムから新システムへ移す一連のプロセスを指します。アプリケーションの切り替えに加え、データ移行の正当性確認や、外部インターフェース（I/F）の切り替え、運用体制の整備などを含みます。業務を止めることなく、あるいは許容範囲内に抑えつつ、新システムへ移行できるかを判断・実行する工程です。

上記の3点は、業務影響や外部システムとの連携条件を踏まえた切り替え方法の選定が必要となるため、プロジェクト初期から検討を開始する必要があります。

切り替え方式や判断基準を後回しにすると、終盤で調整が困難となり、無理な切り替えや判断の先送りにつながります。このように、データ移行・業務切り替え・システム切り替えはいずれも、後工程で詳細化する作業ではなく、早い段階から設計・合意しておくべきテーマです。そのため、これらを「終盤作業」として扱うのではなく、プロジェクト初期から計画に組み込むことが重要となります。

３．年末年始を前提とした切り替え計画の難しさ

３－１．公共系システム特有の制約

公共系システムにおいては、切り替え時期の検討にあたり、単に「利用者が少ない期間」を選べばよいわけではありません。これらの領域では月次・年次の業務サイクルが定まっており、その処理の途中でシステムを切り替えることは、困難なケースが多くなります。

また、法令や制度改正の影響を受けやすいという特性もあります。特定の月・年度をまたぐ処理では、「旧制度前提の処理」と「新制度前提の処理」が混在しないように、切り替えの時期を管理する必要があります。

さらに考慮すべきことは、業務を完全に止められる期間が極めて限られているという点です。通常運用では、当日処理や翌営業日処理が前提となる業務が多く、数日単位での業務停止や大規模な制約を設けることは現実的ではありません。このような制約を踏まえると、「業務処理の節目にあたること」、かつ「比較的まとまった非稼働期間を確保できること」の両方を満たす必要があります。結果、年末年始やゴールデンウィークにシステム切り替えが集中しやすくなります。

切り替え可能な期間が業務制約によって厳しく限定されるため「いつ切り替えるか」と「その期間内に何を完了させるか」を同時に成立させる必要があり、切り替え計画の自由度が低くなる点が、この領域における難しさの一つです。

３－２．「失敗時の立て直し期間」を確保できるという前提

年末年始やゴールデンウィークが選ばれる理由は、単に「業務量が少ない」「利用者がいない」からではありません。むしろ重要なのは、切り替えが想定どおりに進まなかった場合でも、立て直しの余地を確保できる点にあります。

具体的には、これらの期間では、「切り替え作業 → 確認 → 問題発覚 → 修正」、さらに必要に応じて旧システムへの切戻しといった一連の対応を、業務再開までの間に実施できる時間的余裕を確保しやすくなります。年末年始やゴールデンウィークでは、業務再開までに数日～1週間程度の猶予があり、問題調査、原因特定、対応方針の検討・実施に時間を割くことができます。

このように「切り替えそのものの実施」だけでなく、「切り替え後に問題が起きた場合の立て直し」までを含めた時間確保が、年末年始やゴールデンウィークを前提とした計画が採用される大きな理由です。一方で、この期間内に切り替え作業・検証・不具合対応・場合によっては切戻しまでをすべて完結させる必要があるため、作業時間と対応時間の設計を誤ると、リカバリが間に合わないリスクが高まります。余裕がある期間ではあるものの、その余裕の使い方を誤ると取り返しがつかないという点が、計画上の難しさとなります。

３－３．数年前から計画すべき理由

プロジェクト立ち上げ前の段階から、切り替えのチャンスが限られている場合は、これを「候補日」として捉えるのではなく、数年前から「切り替え前提期間」として押さえ、全体ロードマップに組み込むことが必要です。

なぜならこうした切り替え作業は、多くの企業で同じように余裕を持てる期間に行われるため、ベンダや外部接続先、関連システム側の作業枠や要員の確保が難しくなるためです。実際には、切り替え時期の検討を開始した時点で、接続先や外部ベンダ側の作業枠が埋まっているケースも少なくありません。

さらに問題となるのは、切り替えが想定どおりに進まなかった場合です。本来であれば、問題発生時に修正や切戻しを判断・実施できる期間が確保されていることを前提に計画すべきところ、切り替え時期が後追いで決まると、「失敗時に立て直す余地がほとんど残されていない計画」になりがちです。年末年始やゴールデンウィークを前提とした切り替え計画では、切り替え作業そのものだけでなく、切り替え後に想定外の事態が発生した場合の対応時間まで含めて押さえておくことが重要になります。

4．データ移行・業務切り替え・システム切り替え計画の作り方

データ移行・業務切り替え・システム切り替えは、ひとまとめに議論されがちですが、対象が不明確なまま計画を進めると、「当日になって初めて必要な作業が見つかる」「想定外の接続先が判明する」「そこまでやると思っていなかった」という認識齟齬が発生する事態を招きます。このようなリスクを防ぐためには、切り替え計画の初期段階において、切り替え対象の洗い出しと整理をしておくことが不可欠です。

４－１．切り替え対象の洗い出し（データ・業務・接続先）

１）データの切り替え対象

どのデータを切り替え時点で新システムへ移行するかを整理します。

・マスタデータ
・トランザクションデータ
・履歴データ

といった分類だけでなく、切り替え時点で「必須」のデータ、新システム側では参照しないが、問い合わせ対応で必要なデータといった利用目的の違いも整理します。

特に公共系のシステムでは、年度切り替えをまたぐデータや、法令改正の前後で意味や取り扱いが変わる項目が存在します。このため、データごとに「移行対象」「参照方法（新システム/旧システム）」「保存期間」といった観点で整理し、移行方針を明確化することが重要です。

２）業務切り替えの対象

どの業務が、いつ新システムへ切り替わるのかを検討します。

・通常業務（入力・照会・申請）
・月次・年次処理
・例外対応や問い合わせ対応

気をつけるべきは、「新システムが稼働している」ことと「その業務が新システムで行われる」ことは、必ずしも一致しない点です。例えば、切り替え後でも一部業務は旧システムを参照し続け、切り替え直後は暫定手順で対応する。そして、問い合わせ対応は旧システムを保持するといったケースも現実的によく見られます。

そのため、切り替え計画では、「切り替え日以降に新システムで行う業務」と「切り替え日以降もしばらく旧システムで対応する業務」を意図的に分けて整理する必要があります。

３）接続先・外部システムの切り替え対象

接続先や外部システムとの関係を洗い出します。

この洗い出しでは、

・切り替え当日に接続先も切り替える必要があるもの
・切り替え前後で並行稼働が必要なもの
・一定期間、旧接続を維持するもの

を区別します。この整理が曖昧なままだと、外部側の準備が間に合わない、切り替え当日に調整不能な問題が発生するといったリスクを抱えることになります。

重要なのは何が正解かを決定することではなく、切り替え計画の前提条件を定義し、関係対象を洗い出すことで、「切り替え作業の全体像」、「想定に含めるべき影響範囲」、「後続工程で詰めるべき論点」が初めて見えるようになります。

４－２．作業順序と依存関係の整理

切り替え対象を洗い出した後は、各作業をどの順序で実施するのか、どの作業がどの作業に依存しているのかを整理します。例えば「データ移行が完了していないと業務確認ができない」、「外部接続が切り替わらないと一部機能が検証できない」といったケースは珍しくありません。そのため、切り替え計画を時系列ではなく、「この作業が終わらないと次に進めない」という依存関係を明確にします。特に公共系システムでは、移行データが揃わないと月次処理の確認ができない、外部機関との連携切り替えが完了しないと業務が成立しないなど、業務完了条件となる依存関係が発生しやすくなります。

４－３．切り替え判断まで含めた計画

切り替え計画では、作業をどう進めるかと並行して、どの状態であれば切り替え可能と判断できるかを明確にしておく必要があります。

判断に必要な情報の整理として、移行リハーサル結果、業務確認結果、外部インターフェース（I/F）先の疎通状況なども重要ですが、問題が発生した時に、どのような状態となった場合、もしくはその兆候が見えた場合に、誰がどのように意思決定するのかを事前に定義しておくことが重要です。

５．移行リハーサルの設計と実行

移行リハーサルでは、作業手順をなぞるためのイベントではなく、本当に移行ができるのかを検証する工程です。本番と同じ手順で実施し、問題なく完了することを確認するというイメージを持たれるかもしれませんが、移行リハーサルの本来の目的は、

・作業手順の抜け漏れを見つける
・想定外の条件で作業が止まるポイントを洗い出す
・判断が必要な箇所を明確にする

といった、うまくいかない前提での検証にあります。そのため、リハーサルにおいては「成功したかどうか」以上に、「何が原因でどこの作業工程で詰まるのか」を確認の主眼におくことが、圧倒的に重要です。

■大まかな観点
・作業者が想定どおりに動けるか
・判断が必要な作業が特定のメンバーに依存していないか

■データ観点
・データ状態が完全ではないケースが存在しないか
・想定外のデータが混在していないか
・移行件数が想定どおりか
・データが実業務で利用可能な状態か
・不整合・例外データがどの程度発生するか

■時間的観点
・各作業に実際どれくらい時間がかかるか
・想定時間とどの程度乖離があるか
・想定外発生時にどれだけ時間が延びるか、次の作業までのリミットがあるのか

■環境観点
・外部接続が想定どおり切り替わるか
・環境依存で問題が発生しないか
・同時実行時の干渉がないか

リハーサルを通して、作業の簡素化や追加工数を取る必要があるのか、ツールの改修が必要なのか、どこまでを許容範囲とするか、を確認しておくことが重要です。

６．【経験談】移行データ不備が総合試験を直撃し、大幅遅延を招いたケース

公共系システムのプロジェクトにおいて、移行データを用いた総合試験の段階で、「移行データ作成の遅延」や「データ不備の多発」により、試験の開始が大幅に遅延しました。

特に移行方式、移行環境、移行フローの検討不足が、全体の遅延要因となりました。

■主な遅延要因

項目	内容	影響
移行方式の検討不足	移行方式・移行環境・移行フローの設計が不十分	当初は並行処理を前提に本番移行期間内での完了を見込んでいたが、実際には環境制約により処理が直列化し、移行処理時間が想定の約3倍に膨らんだ。その結果、本番移行期間内に処理が収まらない計画であったことが、リハーサル段階で初めて判明した
環境上の問題	移行環境にPCを利用したため、ディスク容量の制約から、テーブルごとに順次処理する必要があった	並行作業ができず、処理が直列化して大幅に非効率化した

こうした要因により、当初想定していた移行計画では対応しきれずに見直しが必要となりました。まずは、移行環境をPCからサーバへ変更し、スペックを適正化。次に、移行方式を再設計するとともに、移行フローを整備しました。移行リハーサルは、4回実施し、手順、性能、品質の改善を段階的に進め、計画した本番移行期間内に完了することが確認されました。

一方で、より深刻な問題として顕在化したのが、元データの不備です。現行システムには仕様外のデータが多く含まれていて、それを十分に洗い出さないままデータベースを設定しており、不備のあるデータによりアプリケーションがアボートする事象が多発することになりました。

「仕様外データ」は、入力チェックでは想定していない値、これまでの運用で例外的に登録された値、廃止になったコードなどを含むもので、データ確認の際に、正常データだけでなく、こうした例外データをどう扱うかを事前に整理しておく必要があります。

■データ不備発見後の対応

対応内容	詳細
机上検証の実施	初回移行後、仕様外データや不整合の有無を確認
移行プログラムの修正	不備を踏まえて変換処理を修正
再リハーサルの実施	再度移行データ作成のリハーサルを実施
総合試験でのトラブル摘出	AP側の総合試験を通じて問題を顕在化
移行仕様の再検討	約100件のデータ移行仕様を見直し

机上検証は、実データ・仕様書・ログを突き合わせて問題点を切り分ける作業であり、原因の見える化に有効です。また、約100件の移行仕様再検討は、単なる修正ではなく、マッピング定義・変換条件・例外処理のあり方を含めた見直しであったため、実質的には移行設計の再構築に近い対応でした。総合試験でトラブルを摘出できたことは、問題の早期発見という意味では有効でしたが、移行品質が不十分なまま試験工程に進んだことで、結果として試験計画を圧迫することになりました。このように、移行方式や環境面の不備に加え、元データの品質確認不足とマッピング検討不足が重なったことで、総合試験に直接的な影響が出ました。

このことから、移行とは「データを正しく使える状態に整える作業」であることを再認識させられました。移行計画は、性能・品質・手順のいずれか一つでも欠けると、大きな影響が出るため、移行準備の甘さが総合試験の遅延に直結してしまうことを肝に命じました。

７．本番移行後に「正しく移行された」と説明できるか

本番移行後、必ず問われるのは、正しくデータが移行されたのかという点です。移行作業は、単にデータを本番環境へ投入すれば終わりではなく、移行前と移行後で件数や内容に差異がないことを、客観的に説明できる状態にしておく必要があります。そこで本プロジェクトでは、プルーフリスト（件数・内容突合表）を作成し、移行結果の確認と客観的な説明が行える形を整えました。

■プルーフリストを作成したことで得られた効果

効果	内容
移行結果の可視化	どの処理で、どのテーブルが、何件移行されたかを一覧で把握
不備の早期発見	不備データ件数や件数差異を確認することで、移行漏れや変換不整合を早期に発見
説明責任の確保	本番移行後に「正しく移行された」と説明するための根拠資料
確認作業の効率化	テーブル単位、処理単位で確認できるため、目視や個別照合よりも効率的
トラブル時の切り分け	どの処理で問題が発生したかを追跡しやすく、原因調査に役立つ

プルーフリストは、テキストファイルとして出力する比較的シンプルな成果物です。データ移行処理毎に、移行元テーブル名と件数、移行後テーブル名と件数、不備データ件数、移行結果（OK／NG）を一覧で記載することで、定量的に確認できるようにしています。

■プルーフリストのイメージ

プルーフリストによって、「どのデータを、何件どう移行したのか」を具体的に示すことができます。本番移行後に、結果の妥当性を照会された際に件数突合の根拠を残しておくことは重要です。

８．おわりに

移行リハーサルは「本番手順をなぞる場」ではなく、想定外のエラーをあぶり出し、判断の必要なポイントや作業上のボトルネックを事前に見つけるための重要な機会です。さらに、本番移行後には「正しく移行された」と説明することが求められるため、件数や内容を突合するプルーフリストのような証跡整備も欠かせません。データ移行・業務切り替え・システム切り替えは、後から何とかするのではなく、初期段階から計画に織り込み、関係者全員で前提条件を共有して進めることが成功の鍵です。本稿が、同様の課題を抱えるプロジェクトにおいて、切り替え計画や移行リハーサルを検討する際の一助となれば幸いです。