段階的な移行

2008年7月7日

他の職業と同様に、ソフトウェア開発にも、普段は無視されがちだが、まさにまずいタイミングでしっぺ返しを食らう、忘れられがちな活動があります。その一つがデータ移行です。

ほとんどの新しいソフトウェアプロジェクトでは、どこか別の場所に存在していたデータが、稼働後に新しいシステムに移動される必要があります。システムのリプレースでは古いデータをすべて移動する必要があるかもしれませんし、新しい機能によって他のシステムからデータをロードする必要が生じるかもしれません。

この作業をあまり真剣に捉えないのはよくあることです。結局のところ、いくつかのデータを読み込み、少し加工して、新しいシステムにロードするだけです。さらに、コードは一度だけ実行すればよいので、特に高速化や見た目をきれいにする必要はありません。移行が完了したら、コードは安全に捨てることができます。

そしてもちろん、新しいシステムが稼働する直前に移行を実行するだけなので、プロジェクトの終盤まで心配する必要はありません。

私は読者のソフトウェアに関する文章に対するセンスを高く評価しているので、きっと皆さんのほろ苦い笑顔が想像できます。データ移行は、ホワイトボード上の抽象化という安全な場所から見ると簡単そうに見えますが、通常は、つまずく可能性のある厄介な詳細でいっぱいです。

既存のデータが多少乱雑であることは予想されるかもしれませんが、実際にはデータがどれほど汚れているかに皆が驚かされるのが常です。その結果、全体の作業は本来あるべき姿よりもはるかに複雑になることが多いのです。
使い捨ての単発コードであるため、移行コードはデザインペイオフラインを下回ると考えられ、人々は移行コードにあまり設計の労力をかけません。その想定は、特に前の箇条書きのようなケースでは間違っていることが多いです。
思ったよりも難しいことに膨れ上がってしまう活動を行うのは決して楽しいことではありませんが、リリース日の直前まで放置すると、トラブルに大きな契約ボーナスを与えるようなものです。

アジャイルの文脈でよく使う好きな言葉があります。「もしそれが苦痛なら、もっと頻繁に行え」。その表面的な非論理性が記憶に残りやすく、そこには真実があります。多くの困難な活動は、より頻繁に行うことで、はるかに簡単にすることができます。XPerは、この原則をテスト、統合、設計、計画に適用することで特に知られています。ですから、データ移行に適用しても驚くことではないでしょう。

私が初めてこれを見たのは、同僚のジョシュ・マッケンジーが、過去に2回の失敗を経験した中規模プロジェクト（1年間で10数人の開発者）で行ったときでした。彼は、2週間ごとのイテレーションごとにデータを移行することにしました。各イテレーションでチームは、構築中の新しい機能をサポートするために追加する必要があるデータを把握し、ライブシステムから追加のデータを移行するようにデータ移行システムを更新しました。

このようなことによくあるように、それは人々が恐れていたよりもはるかに不可能ではないことが判明し、結果としてリスクとストレスが軽減されたことで、この選択は価値あるものとなりました。彼らは明らかな利点を認め、それはリリース直前の慌ただしいパニックの欠如に帰着しました。

しかし、最も興味深いメリットは、彼らが予期していなかったものでした。段階的な移行によって、ドメインエキスパートとのコミュニケーションが大幅に改善されました。通常、ドメインエキスパートとユースケースについて話したい場合は、架空のシナリオを作成します。段階的なデータ移行を使用することで、チームは実際の例を使用する習慣を身につけ、それはドメインエキスパートが関連付けやすくなりました。さらに、開発によってドメインエキスパートが見ることができるビルドが提供されると、それにはライブデータのコピーが含まれていました。その結果、ドメインエキスパートは、最近遭遇した厄介なケースで新しいシステムがどのように機能するかを調査できました。特に興味深い困難な状況は、テスト環境に簡単にコピーできました。

コミュニケーションの改善がなくても、段階的な移行を行うだけの価値はあります。もしそうするなら、ドメインエキスパートと話すために実際のデータを利用する機会を活用する準備をしてください。