データ移行を成功させるためには、過去の失敗事例を糧にし、同じ過ちを繰り返さないことが有用と考えます。本記事では、私が移行失敗を防げなかった9つの原因を紹介します（脚色を加えたフィクションです）。
１）いい人すぎた（馬鹿丸出し）
これまで移行データを触ったことがなかった私は、きちんと移行すれば問題は発生しないと思っていました。きちんとの意味は、移行元から提供される仕様と、移行先で設計している仕様をマッピングするということです。
しかしながらバグの発生しないプログラムが存在しないのと同様に、きちんとの前提が揃っていることはまずありません。
- 移行データは仕様書通りではない
- 移行データも過去システムからの移行の寄せ集め
- 現行システム担当者だってデータの実態わかってない
- 新システムは設計真っ最中だから仕様は日々変わる
- よくわからなくたって移行の問題にされることがある
責任範囲を明確にし、問題が移行データの品質にあるのか、新システム側の設計やテストにあるのかを切り分けて取り組むことが大前提です。
もはや移行に限った話ではありませんが、似たお人好しに失敗してほしくないので最初に明記しました。
２）移行データ品質の評価が漏れていた
移行チームにアサインされた私は喜々として現行システムのテーブル定義書やER図を読み漁りました。サンプルデータをどこまで入手していたのか記憶が定かでないのですが、少なくとも要件定義や設計の段階では、移行データの現物を見て評価することはありませんでした。
また、データクレンジング作業や移行結果の検証の枠組みも不足していたため、本来データ移行の工程で向上していくはずのデータ品質が上がらないまま新システムに投入されてしまったのです。嘘のような本当の話です。
要件定義段階で移行データはサンプルデータを入手し、仕様書と異なる定義のものがどのくらい混じっているか評価すべきです。それをどこまで事前にクレンジングを行うか、改善した品質を移行プログラムやテストでどう検証するかが肝になります。
３）移行仕様の詰めが甘かった
現行システムのテーブル定義書と新システムの項目定義書を入手した私は、それらを左右に並べて移行用のマッピング定義書を作成しました。変換不要でそのまま移送すればいいもの、現行システムに項目がないため固定値をセットするものなど、項目ごとの移行対応を一つひとつ埋めて設計書としました。
移行元データが仕様書と異なる場合の対応や、移行先のデータが画面でどう見えて新システムの制御にどう使われるか、というところには一切踏み込みませんでした。こうして生のデータには太刀打ちできない移行プログラムができあがってしまいました。
プログラムにおいて想定外のパターンは存在してはなりません。nullやブランクの時どうするか、マイナスや小数点がつかない場合どうするか、など考慮事項は最初にチェックリスト化して担当者の経験やスキルに依存しないための対策はしておくべきです。
４）工数の見積もりが過小だった
コンサル出身で抜け漏れには敏感だった私は、移行対象が漏れてないかはこまめにチェックをしていました。現行システムの担当者から必要そうな移行データの話があがると、速やかに一覧に追加をしていきました。
工数の見積もりは、移行対象数と、既に見えている要件に基づいた難易度（大、中、小）による係数で行いました。根本的に足りなかったのは、各テーブルの項目数と、移行データ件数の視点です。
項目数が多ければ多いほど要件確認も、設計も、開発もテストも全て工数は増えます。また、データ件数が多いものについても注意が必要です。想定外データの可能性が多くなること、処理速度が出なくてチューニングが必要になること、大量データゆえの想定外が発生することなどです。
グループリーダーやPMに工数を評価する素養があったとしても、彼らはコスト内に収めることが常に念頭にあります（いち移行担当だとしてもコスト意識は必要ですが、やり切れるのに必要な工数を主張するのは移行担当の責務です）
５）アーキテクチャが貧弱だった
バッチプログラムの開発経験がなかった私は、実際に取り込みや変換を行う処理以外にどういう要素が必要になるかわかっていませんでした。
極端なことをいうと、個々の処理プログラムを起動させるシェルやバッチといった存在すら知らなかったのです。
データ移行の場合は、高度な制御アーキテクチャではなく泥臭いものばかりです。
受領した移行データが明らかにおかしな状態になっていないかチェックする（前回データとの差分をチェックするとか、文字化けしていないか、ヘッダやフッタがついているかなど）ことや、個々の処理結果を確認するためのログ出力（件数、結果、エラーデータ）などは、移行データに依存しないため、早い段階で有識者交えて検討し、決めておくべきです。
６）テストが甘かった
上流工程の積み残しも、本番リリース前にはすべて拾って解消する。本番リリースしても問題が発生しない状態まで品質を向上させるのが、テスト工程の役目です。
移行チームの計画をした際に、移行テストと2回の移行リハーサルを含めました。一般論としても違和感はないはずです。
工程としてどんなテストをして、発生したバグを解消して次に進むという流れは間違っていませんでした。しかし、テストを通過した状態のデータ品質の想像が圧倒的に足りませんでした。
そのためテスト項目として、異常終了しないことが最低限の基準で、それ以外のエラーデータの扱いや、件数・金額の現行との突合せ、新システムで参照・操作する上での不具合などを解決する視点が入っていませんでした。
品質を上げるためには移行チームだけではできないことも多いです。他チームを巻き込む必要はもちろんありますが、データ品質を担保する総合責任は移行チームが担い、そのためのテストを行うべきです。
７）処理速度を出すための考慮が足りなかった
データ移行は時間との戦いです。ゴールデンウィークやお盆などの長期休暇を使っても、決して余裕はありません。そのため極力人手を介する作業はなくすべきですし、移行プログラムの処理時間も敏感になる必要があります。
データベースに関する知識がなかった私は、開発段階でも数件程度のデータでテストを行いました。そのため、開発が終わった段階で、いざ大量の移行データを投入しようとした時に、一晩経っても処理が終わっていない、あるいは途中で異常終了して終わっている、という無残な事態に頻繁に遭遇しました。
バカなSQLを組まないことも重要ですが、適切にインデックスを貼ること、統計情報を最新にすること、表の再編成を行うことなども基本的な考慮事項としておさえておくべきです。
８）暫定的に切り抜ける手立てを知らなかった
データが多過ぎたら分割して扱う、一部データだけがおかしいならそこだけを修正して対応する、というのは冷静な状態なら誰にでも思いつくアイデアです。
経験とセンスに乏しいだけでなく、ゆでガエルのように現場にのぼせていた私は、大量データの移行処理が途中で異常終了してしまうことの解析に時間を要しました。一部データがおかしいにも関わらず、プログラムが直り切ってから再度移行をしていました。暫定的な対処をすることで少しでも早く他のテストが進められるのにも関わらず、です。
途中まででもエラーにならないことがわかれば移行データを取り込んだ段階でデータを分割して、エラーにならないデータだけで処理を進めることが可能です。
また、一部データの一部項目がおかしいならSQLでデータパッチを適用することも可能です。
手作業が増えるとその分だけ本番移行のリスクになるためバランスは重要ですが、全体のボトルネックになるくらいなら、暫定的な手段を講じることも有効です。
９）自分以外にNoと言える人がいないことに気づかなかった
失敗した直後に一生懸命ふりかえりを行いました。そのときは、上記のような原因を洗い出した横にもうひとつ、
- メンバーからのエスカレーションがなかった
- マネジメントやステコミからのNo Goがなかった
という問題点を挙げていました。ただ、今となってはいくら未経験、若手とはいえデータ移行をリードする自分が白旗を上げなければ誰も動けなかったのかなと思います。メンバーも様々な形でサインは出していたでしょう。しかしリーダーである私が成功のみを信じ失敗に目を向けなければ、メンバーも一緒についていくしかなかったのかもしれません。マネジメントやステアリングコミッティの判断とて、判断材料が適切に提示されていなければ判断のしようがないでしょう。
根拠は後で間に合うので自分に正直にNoは言いましょう。
おわりに
データ移行は様々な領域のしわ寄せが集まるところです。しかしながらただ既存データをそのまま移すだけという感覚も拭えず、若者や未経験のメンバーが担当することも少なくなかったように思います。同じような失敗をする人が一人でも減るようにこの記事を書きました。
私のような失敗をしなくていいように本も書きました
11月17日Kindle配信
