「2025年の崖」という言葉があります。経産省が2018年に発表したDXレポートに出てくる言葉です。
この説明が本稿の主旨ではないため、詳しくは割愛しますが、企業が昔から運用している基幹システム、いわゆるレガシーシステムの保守人材やその基盤であるメインフレームの保守切れが起きるというものです。
そのため、日本の各社はレガシーマイグレーションといって、基幹システムの刷新に取り組んでいます。
基幹システム刷新プロジェクトは、例えば、メインフレームで動いていたシステムをERP（Enterprise Resource Planning）と呼ばれるパッケージに変えたり、スクラッチ（ゼロベースでシステムを築くこと）で作り変えたりします。
このプロジェクトで、地味に見えて実は重要なのが、「データ移行」という作業です。
基幹システムの刷新において、データ移行はトラブルが起きやすく、刷新の成否を左右する作業だと思います。
今回はまさにこの「データ移行」作業に途中から参画し、要件の整理からはじめ、最終的には数十万件のデータ移行を成功させたプロセスについてお話しいたします。
プロセス失敗に向かっていたデータ移行
失敗に向かっていたデータ移行
私が参画したプロジェクトは20年以上稼働しているレガシーシステムからの刷新プロジェクトでした。
スクラッチで刷新するということもあり、プロジェクトの主要メンバーは顧客側、ベンダー側両方とも、刷新後の機能をどうするかの検討に集中していました。既存機能の要件や新システムの要件定義や仕様の定義にかかりっきりの状態でした。
私が移行チームに参画したのは、スケジュール全体としては、単体テストまで進んでいたタイミングでしたが、データ移行の優先度は下げられており、移行対象のテーブルは整理されていたものの、移行元データの調査はされておらず、顧客側の移行チームも私以外は誰もいないという状況でした。
なお、このプロジェクトでは移行のリードは顧客側でやることになっており、ベンダーは顧客側の指示に基づいて作業をする、という役割分担でした。
整理する中でわかったことですが、いわゆるトランザクションデータは移行しないという方針だったため、データ移行が大したことないだろうと優先度が下げられていたのですが、しかし、マスタデータやユーザーデータなどの移行対象データはトータルで数十万件規模のものでした。
また、レガシーシステムらしく元データはデータ間での不整合が多く、新システムへのデータ変換はデータ一つに対しても数回の変換が必要になるようなものでした。
また、マスターデータ、ユーザーデータ共に、連携先システム側が主管するものが多く、連携先システムとデータ仕様面での整合、データ移行作業面での整合を取る必要もありました。
プロジェクト全体ではデータ移行を楽観視する空気がありましたが、このままでは、データ移行が失敗する可能性が非常に高い状態だと感じました。
特別なことはしない。ゼロからスコープを整理することでスケジュールを組み立てる
最初にやったことは、移行元となるデータを実際に収集し、データの内容を調査することでした。
これにより前述した数十万件という規模が把握でき、また対向先システムとどのようにデータや作業面で整合させるかという点を具体化できました。
データ移行要件定義をしっかりやりなおしたということになると思います。これにより、データ移行でやるべき作業をしっかりと定義することができました。
まずは現状を正しく把握することが、作業を設計する上での土台になります。
作業スコープを確定した後は変換方式をいつまでに整理すべきか、連携システムといつデータ移行のリハーサルを行うかなどのマイルストーンを決め、そこから逆算して、データ移行ツールの設計や実装、テストなどのスケジュールを組み立てることができました。
リソースの制約をプロセス管理でカバーする
スケジュールが整理された後は、実際にデータを作成する体制づくりに取り組みました。
メンバーは何とか2人確保できました。
しかし、大規模なデータ移行にもかかわらず、データ移行が十分にあるとはいえない2人だったこともあり、データ作成をしてもらったものの、そのデータには多くの問題があり、品質的にまずい状況でした。
そこで取り組んだのは、データ作成プロセスとチェックプロセスを標準化するということです。
これにより、誰が担当しても一定の移行データの品質を担保できるようになりました。
さらにプロセスそのものをモニタリングして、不備が見つかるたびにプロセスを修正するというサイクルを回したことで、確実に品質が向上していきました。
ステークホルダーマネジメントとして力を入れた「理解の合意形成」
移行データの品質が担保された後は、移行元データを主管する連携先システムの主管部署への説明・ヒアリング、調整という段階に入りました。
当プロジェクトのデータ移行においては、こちら側で、ああしてほしいこうしてほしいという指示をして、連携先システムの担当はそれに対応してもらうというやり方になっていました。
しかし、そのやり方では移行後、リリース後に、こちらのデータ移行チームが解散した後は運用が立ち行かなくなってしまいます。
そのため、「今回だけ作業をしてもらう」調整をするだけではなく、現行と次期でデータがどう変わるのかを理解してもらい、今後は各部署が自分たちでデータを管理していけるようにすることでした。
これは単なる作業依頼ではなく、移行後の運用主体である各部署を巻き込む、ステークホルダーマネジメントの一環だったと考えています。
移行担当としての仕事は、データを移すことだけではなく、その先で誰がどう運用していくかまで見据えて合意形成することだと考えています。
実はこの工程が一番大変だったのですが、説明に時間をかけたことは、後々の安定運用につながる価値のある投資だったと私は思っています。
そして、迎えたリリース
結果として、スケジュールを順守してデータ品質を担保し、数十万件規模のデータ移行を完了することができました。
サービスイン後も大きな問題なく安定して稼働を続けています。
冒頭で触れたように、データ移行は刷新プロジェクトの成否を左右するプロセスです。
要件が不十分な状態から始まりましたが、大きく3つのポイントを意識したことで最終的な安定稼働につなげることができました。
- データ調査に基づくデータ移行要件定義とスケジュール立案：事実を集めて作業スコープを明らかにし、マイルストーンから逆算して計画を立てたこと
- リソース・品質マネジメント：人員不足を個人の努力に頼らず、プロセスの標準化とプロセスの修正サイクルをまわすことで品質を積み上げたこと
- ステークホルダーマネジメント：関係部署に自律的に動いてもらうことを目的に据え、運用の当事者として巻き込んだこと
今回の経験は、要件が何もない状態であっても、またリソースが十分でない状態であっても、何をやるべきかを考え（情報を集め整理する）、愚直に実行すれば、プロジェクトを成功に導くことができるという大きな自信につながりました。
