新システムへの移行イベントを疎かにするとプロジェクトがカオス確定
移行イベントって計画できていますか？
システム開発のプロジェクトに携わると、プロジェクトの大小関係なく『移行』という言葉を耳にします。そして大概の場合、開発スケジュールはきちんと管理されていても、移行のスケジュールは精度が落ちていたり、管理が滞っていたり、そもそも担当を用意していなくて、慌てて開発メンバを引っぺがして急遽移行イベント担当にさせて１ヶ月以内に移行アプリケーションを作れと指示され、担当者が家に帰れないような状況を見た経験があります。当事者になってしまうと、大変な苦しい思いをしないといけなくなり、不幸なエンジニアライフを送ってしまいがちです。
当事者の方は逃げるプロジェクトから準備をしておくことをオススメします。理不尽なプロジェクトに身をおいてもメリットは一つもありません。エンジニアに逃げられる前に発注元や開発元はプロジェクト計画の見直しを検討するべきです。
2017年現在ではビジネスのあらゆるシーンでシステム化されており、新システムの構築時には必ずといって良いほど移行イベントが発生します。また、既存システムの業務機能を追加する（商品注文管理システムに経理管理機能を上乗せする）など、新システムでなくても大きい開発案件では移行という問題に出くわすことも多いでしょう。そして、移行は以下に大きく２つの観点で検討する必要があります。
| データ移行 | 旧システムで使用しているデータを新システムでも継続して使用できることを保証する。大概の場合はユーザ情報や商品情報などマスタ系のデータを引継ぐことが多い。新旧でデータ構造が異なるケースがほとんどであるため、履歴系のトランザクションデータも移行する必要が発生するとデータ量も増加し、難易度が急激にアップする |
| システム移行 | 旧システムを停止させ新システムへの稼動を円滑に行い、業務・サービスを継続することを保証する。旧システムを止めるタイミングが深夜となり、短時間で新システムを稼動させる一大イベントとなる。旧システムと新システムが並行で稼動すると、イベントが分散されて長期戦となり、エンジニアが疲弊する要因となる。またクライアント側にアプリケーションを配信するシステムだと拠点毎にシステム移行が発生し、全国エンジニアが出張して現地サポートが発生する |
新システムを稼動させるのに今あるデータを捨てられないなら移行する必要があると、プロジェクトを俯瞰で見れば誰でもわかりそうな気がしていしますが、なぜ移行は疎かにされがちなのでしょうか？
私のつたない経験では以下のような理由が当てはまりそうな気がしてます。
・業務機能開発ばかり焦点が当たり、移行の存在を認識している人が誰もいない
・依頼発注元が移行イベントが高難易度なイベントであることを理解していない（開発を請け負う側が移行を誰が担当するのか確認していない）ため、予算が割かれていない
・移行を対応できる高スキルエンジニアがプロジェクトに参画していない
・旧システムの仕様や内部構造を把握できていうる人が参画していない or 旧システムからの支援が得られない
プロジェクトの途中で移行の存在を認知するケースが最悪で、慌てて人材を確保しようと奔放しますが、十分な期間をかけて精査することができずにスキルに不安がある人が担当になったり、要員を追加できずに開発要員が割当たることとなり、移行も開発も進捗遅れが頻発してプロジェクトが炎上することになります。
データ移行には旧システムと新システムの両方に精通する必要がありますが…
移行というと、大方データ移行の方にフォーカスが当たる事が多いようです。システム移行も重要なのですが、リリース計画と重複する要素が高いため、一発切替方式か並行稼動方式なのかを決定した後は、直前になってタイムチャートを作成して切替の準備を突貫工事で行います。直前で大きな課題があると、リリース延伸のリスクは高いものの大概は対策前進で突破してしまいます。昨今ではＷＥＢ系システムが主流になるため、事前にクライアントへインストール儀式が不要となり、システム移行の敷居も低いように考えられます。ブラウザ依存の不具合が多数発生するため、システムテストの工数が高くなることも多いので、プロジェクトリスクが低くなるということではありません。
データ移行は旧システムから新システムへデータを移すためのＳＱＬを準備したり、複雑な判定ロジックが必要となる場合は、移行用のアプリケーションを作成するケースも散見されます。また新システムのバッチ処理やファイルアップロードを流用して、開発コストをうまく使おうというケースもありますが、移行時のデータ量は商用サービスのデータ緒元量を遥かに超えていて、オーバフローが発生したり、エラー時に全件ロールバックする仕様のため、移行時のエラーデータを解消していないとバッチ処理が流せなかったり、そもそも処理時間が長時間して移行が間に合わないというリスクもあるため、ラッピング処理を施したりデータ分割したりする必要がないか十分な検証が必要です。
上記の状態まで移行の準備が進めばまだ良いほうなのですが、そもそも旧システムのデータをどうやって新システムへデータを投入するかを移行設計できるエンジニアがいないことが問題です。旧システムと新システムとで同じベンダー会社に任せられれば、内部での情報伝達がうまく機能しやすいので苦労は少ないのですが、新システムではもっと低価格のベンダー会社へお願いするケースも多く、ほとんどの場合は新旧でベンダー会社が違います。契約上、旧システムの内部構造を新システム側へ開示できないといった状況になるとかなり悲惨な状態になります。
旧システムにどんな情報があるのか分からないのに、新システムを稼動させるために必要な情報を新システムの移行担当エンジニアは模索しないといけません。新システムでは同じことなのに表現が異なるため、情報の源泉を探し当てられないということが発生し、似た日本語だから同じ情報（ログインＩＤとユーザＩＤは旧システムで意味が違う）だと勘違いして、いざ移行しようとすると移行データの源泉が誤っている事が発覚するなど、まるで考古学の発掘作業にも似た感覚で旧システムのデータ仕様を掘り当てなければいけません。ものすごいリスクを抱えて、結果工数が積み上がってしまい、新システムのリリース延伸につながってしまうこともあります。
では、旧システムと新システムの両方の仕様を押さえたエンジニアを新システム側で用意できるのかというと、私は無茶な要求だと考えます。では、どうするかというと旧システムのデータ情報の一部をあきらめ、本当にサービスに必要な情報だけを移行する方針として、全体のスコープを狭めるか、旧システム側のデータ移行担当を有償で依頼して、データ構造を把握できるコミュニケーションパスを開拓するかのどちらかだと思います。新システム側のエンジニアにとっては、いずれなくなる旧システムの仕様を理解したところで、先に活かせることができないため、必要な情報だけが開示されれば良いのです。
移行時のミスを後遺症にさせないように
移行イベントでの失敗やトラブルは、サービス稼動後に全部発覚すればまだ良いほうで、数ヶ月後、１年後といったように時限爆弾として発覚してバッチ処理がエラーでストップしたり、データが読み捨てられてて金額集計結果が新システム稼動後からずっと誤っていたことが発覚するなど、無視できないリスクが潜んでいます。開発スケジュールと連携してシナリオ試験時には旧システムからの移行データを使用して試験をするなど十分に検証できる計画を立てるように心がけていきたいですね。
また、新システムでサービスを稼動させるために、旧システムのデータはどこまで必要なのでしょうか？思い切って履歴データはＣＳＶ形式でもっておき、新システムへはエンドユーザが求める情報に限定して新システムへ移行するなど、断捨離する気持ちでスコープの縮小を行い、できるだけ移行方式を単純化できれば、エンジニアが徹夜する機会も減ることにつながると思います。