プロジェクトの成功要因 - 山本大の日記
先日の日記の通り、最近システム開発のリリースを無事完了しました。
今日は、そのシステムでのデータ移行の話。
移行不可能？
このプロジェクト、
業務はさほど難しいことはなく、本来は難易度の高いシステムではありませんでしたが、
旧システムのDB設計の悪さと、長年の保守による継ぎ接ぎによって、データコンバートが抜群に難しいという特徴がありました。
当初、誰もが「データコンバートは不可能」と言っていました。
つながりのないデータ
このシステムの移行についてはじめに驚愕したのは、
旧システムのデータ上「請求テーブル」と「入金テーブル」の紐付けを行うキーがどこにも存在しないことです。
そのくせ、請求と入金の一覧や、消しこみのチェック業務は存在していました。
この1つの例だけで、移行が絶望的だと直感しました。
無いキーを生み出すことはできないからです。
他にもたくさんの問題を抱えていましたが、この問題が一番でした。
不可能を可能に。
このコンバートの中心になるチームは苦悩しました。
結局、このデータコンバートするための方法として決断したのは、
「過去のすべての取引履歴の日付を追って、新システムのモジュールを通してやり直す」という方法でした。
取引履歴に日付と時刻まで記録されていたため、
1からさかのぼって、日時順に新システムのモジュールで取引を行ったことにすればよいのです。
つまり、取引履歴からのREDOです。
最も手間がかかり、最も整合性を合わせるのが難しい方法ではあります。
なにせ、保守で頻繁にデータの書き換えを行っているのです、
データコンバートの設計を行っている最中にもドンドン不整パターンは増えていました。
しかし、結論としてこの方法しかありませんでした。
これを早々に決断し、完遂させたサブチームには畏敬の念を感じます。
デイリーなデータコンバート実施の効力
難しい移行をサブチーム任せにしていましたが
実は私は、DBアーキテクトという位置づけで働いていました。
そのため、移行の枠組みを整える必要がありました。
上述のような、難易度の高い移行を行うにあたって
について上手く行った仕組みは、以下の2つでした。
1つ目は、各業務チームが自由に移行プログラムを編集し、チェックインできる環境
2つ目が、毎日移行を自動的に実施する環境、すなわちデイリーデータコンバートです。
プログラムの
「デイリービルド」は、通常でも行いますが
「デイリーデータコンバート」は始めてです。
しかし、これは功を奏しました。
データコンバートについて毎日毎日、何度も何度も検証し、
開発中のシステムもそのデータを利用して検証できるという体制は、
とても実装・検証がしやすいというメリットがありました。
デイリーなテストコードの実行と共に、
デイリーなデータコンバートの実行はお勧めで、
今後もこれに取り組んで行こうと思います。
