システム移行の歩き方（１）

過去何度か大規模から中規模のシステムの移転や再構築、マイグレーションなどでデータ移行、システム移行を度々行ってきたのでその設計や実施のノウハウをメモしておこうかと思い書いてみました。

結構適当に扱われる割に手を抜くと被害は甚大

毎度のパターンになるのですがシステム移行やデータ移行にはセオリーらしきものはありますが、概要設計や詳細設計、製造、各種テストのように定石がありません。（セオリーも定石も似たようなもんですけど）
定石がない、というよりされにくいのは具体的な作業のイメージがしにくい部分だから、というのもあります。
なんとなくぼんやり「そういう作業があるね」とスケジュールやWBS作成の時に作業項目が細分化されにくく、いつまでも大項目しか存在しないまま、いつまでも作業が誰にでも創造できるような作業の項目にブレークダウンするのが後回しになってしまいがちです。

後回しになるとどうなるか、というと旧システムが造り出しているデータがあたかも新システムに存在している状態が最初であるか如く動く前提のテストや作り方となってしまいます。データは空っぽの状態、またはコンバートされる前のデータしかないという状態があるというのに、その移行し終わった状態からスタートするような想定で作られているという矛盾に遭遇する現実が本番が始まる手前まで忘却され続けてしまいます。

そしてさらには、本番当日にろくにリハーサルもしないまま進めるとAという作業が終わってる前提のBの作業が先にスケジュールされていたり役割分担のスコープが不明瞭で作業の結合部分が「ここはあなたの作業範囲」「いや、ここはあなたでしょ」というギスギスが発生します。

本番当日に流量を調節しないせいで大規模キャンペーンなどと予定が競合したり、つまるところお互いの予定外でスムーズな移行ができず、予定通りのサービスインができないという悪夢が待っているのです。
こんな事になるなんて。となるわけです。

「作る事」「動かす事」は大勢が設計しているが「動かし始める事」「古いシステムを止める事」を設計する人が少ない。

なぜなら「新旧の両方を知っている」、というシステム移行設計者としては、最小限必要な条件がありますが、その条件を備えている人間が新システムの作り手に全て回ってしまっているという状態のまま移行設計が開始されてしまいます。そうなると必然的にシステム上の制約やプログラム上の制約という細かいところまでは知らない人間しか余っていない状態になる。大体上流工程設計者がそれに当たります。そういった上流工程の設計者のみで移行設計を考えると、前述の詳細設計、製造で起きている様々な制約を加味した移行計画にはなりません。

結局みんなやりたがらない。

どのタイミングで移行していいのかわからない。
0時に停止して6時に移行後のシステムを稼働したら、その間のバッチ処理などスキップした処理でデータは大丈夫なのか。次の日から動かしたほうがいいのか。遅れてでもリカバリしたほうがいいのか。それとも遅れてすらいけないのか。
そんな事を自信をもって大丈夫、と言える人がプロジェクトチームにはほぼいない、という事のほうが多いからです。
と、なるとやりたい人なんて皆無に近くなるんです。
移行設計者は貧乏くじにもなりかねない決められ方で指名される場合が多いです。（移行設計自体は貧乏くじもないんですけどね。）

ある程度目安になるポイントをまとめてみます。

全ての移行に通用するとは思いませんが、ある程度ポイントになる部分、気を付けたほうがいい部分、こういう考え方で移行を考えてみる、という事をこれまでの経験を踏まえてまとめてみようと思います。

具体的な内容は次回へ続きます。連載的な感じで書こうと思いますので、できれば目次のようなものは早いうちに書ければと思いますが、書きながら目次を作るようになるかもしれません。

移行よろしくね！って言われた担当者様達の一助になればと思います。
（続く）

（ちょっと使い方や文章がお粗末なので少しずつ加筆修正を繰り返しながら進めます）