はじめに
移行とは、このIT業界のなかでも非常に難易度の高い、インパクトのでかい仕事です。
それは、
- 現行調査
- 移行計画策定
- 移行プログラム作成
- 実施詳細手順
- 移行の実施（←本投稿はここで感じた移行手順の反省点）
まで様々なプロセスが必要であり、それぞれが失敗すれば、移行そのものが悪い方向に行ってしまう点にもあります。
私が本投稿で話をしたいのは、いざ移行をしようと思ったとあるシステムの移行に手こずり
- こういうのバッドパターンだな。
と。
私が虫の目で移行手順をみて、
感じたことを悪と改善点の視点から綴ります。
移行7つの悪習（移行手順編）
あえて
- 手順はシンプルに。
といったプログラミングの原則的なものではなく、
- 手順は作業に落ちるよう詳細に書く
といった移行手順のノウハウもかきません。
もっと感覚に落ちるよう事象からバッドケースを綴ってやりがちなミスを重点に記載しました。
※手順のNoは、移行という特性から数多くの手順のうちの1つですよという意味で記載しており、その数値に意味はありません。
ただ、膨大な作業の1つに欠陥があると、大きな障害になることを示しています
1. “謎“の変換定義が手順のなかにある
【移行手順書】
手順78:hogehogeFugaFuga78.sqlのWHERE句を消してから、SQLを実行する
なっ。なぜやるんだ！この手順！
【悪】
- トレースできない。わけわからなくなる。仕組みが複雑になるだけ。
【改善点】
- 例の変換定義を作成するくらいなら、ファイルを別で作成するなり対応
- 状況により変化する変換定義が多少あるのは仕方ないが、重要なものであれば変換定義は手順の核として関係者全員に認識させること
2. 個々の関連がなぞ。思想がない。
【移行手順書】
手順102:ジョブAを2回実行する
手順103:ジョブBを1回実行した後、ジョブAを再度実行する
手順103:ジョブCを1回実行する
手順104:ジョブBを1回実行した後、ジョブAを再度実行する
心の声：4回目のジョブAでエラーがおきたら、なにを疑えば良いんだろ。。。
【悪】
- 暫定対応に暫定対応が重なり、もはやなにがなんだかよくわからない。対応した人のみ知る人依存
- 担当者が休んだときに、エラーがおきたら誰も対応できない
【改善点】
- 自分のためにも、必ず絵にすること。思想をもって設計すること
- 今回の例であれば、データフローの整理を行っておくこと
3. 手順がざっくりすぎる
【移行手順書】
手順115:一回目と同じ
心の声：なんですかそれ。しかも微妙に手順が違う。
【悪】
- 「１回目と同じ。」で少しでも手順が違うのはNG。
- なんとなく同じ流れのものは、同じとはいわない。
【改善点】
- ほとんど同じであっても違うところがあるのなら、差異の全洗い出しが最低限必要。表などにすると良い。
4. データフローがわからない
【移行手順書】
手順35:テーブルAをテーブルBに移送する
手順109:テーブルBをテーブルCと名前を変える
手順111:テーブルCをテーブルDと結合して、テーブルEを作成する
手順135:テーブルEの項目Xの存在チェックする
チェックエラー。。。どこのなにが悪いんだー！！
【悪】
- データの流れがわからない。
- 絵がかけないなら、それは理解できていないに等しい
- 仕組みが酷くても絵はかける。ただ、ぐちゃぐちゃなだけ。
【改善点】
- データの流れを絵で書くこと。
- 要件も大切だが、要件を伝えるだけでは、記憶に残りずらい点にも注意すること
5. 利用するSQL・JOBなどプログラムを編集して使いまわす（ファイルが同一）
【移行手順書】
手順32:hogehogeFugaFuga78.sqlのSQLを実行する
手順78:hogehogeFugaFuga78.sqlのWHERE句を消してから、SQLを実行する
心の声1：手順32のソースコードがなにか、どうやってトレースするんだろ。
手順103:ジョブCを1回実行する
手順105:ジョブCのパラメータをhogehogeと修正して、ジョブCを再実行
心の声2：手順103で実行したパラメータ誤りしてたら、どうやってトレースするんだろ
【悪】
- SVNやgitのデータを上書きしてコミットして世代管理で実行LOGを残していた（ブランチ管理はしていない）
- 実行したものがなにかわからなくなってくる。トレースできない。
- 仕組み（経緯？）をしらない人間にはトレース不能！
【改善点】
- パラメータの一部が違うだけなら、バインドパラメータ等にすること
- パラメータが大きく違うなら、それはジョブ（プログラムであればプログラムファイル）を分けること
6. 他システムを信用しきった貧弱なソースコード
【移行手順書】
手順55：ベンダー1からデータを受け取り、テーブルAに入れる
手順56：テーブルAとテーブルBを結合して、テーブルCを作成する
心の声：手順55で作成したテーブルAのチェックしなくて大丈夫だろうか。
もしテーブルCがテーブルAの不正データで膨れ上がったらどうするんだろ。必要な集約しているかな。
【悪】
- 他ベンダーの仕様を鵜呑みにしない。
【改善点】
- 出来る限りチェックするなど、安全性を担保する処理を加えて自システムを不正データから守る
- 同じソースコードでも不正データに強いソースをつくるべき。
- エラー検知はまた別のこと。不正データを綺麗に完璧に書き換える方法があるならそれでもよいと思う
7. 重い処理があるのに「重い処理だから分散処理できない」というのはまた別問題
【移行手順書】
手順200:ジョブPは遅く、リソースを消費するため、完了するまで待機
心の声：DBのリソースはスカスカですが。。。そもそもハッシュ分散すればリソースが上手く活用できるのでは。
【悪】
- 移行は時間ないのに、リソースがバカみたいに余っている。
- リソースについて理解が浅いのに、手順がそれに引きずられる
【改善点】
- DBリソースのボトルネックを考慮したうえでヒント句による処理が適切かの判断が必要。
- ボトルネックになりやすいDBリソースについて深く理解してリソースを最大限活かすように移行すること。