ETLは生産性が高いと言われるが必ずしもそうではない。スクラッチ開発よりも弱い部分がある。
率直に言うと、ETLは新規のアプリ作成は生産性が高い。一方、以下の特性から修正には弱い。
- 小さい単位でUTができない。
- テストの自動化が困難。
- デバッグが困難。
- 修正時の差分コンペアが困難。
- リファクタリングやテストファースト（TDD）での修正が困難。
下記にウィークポイントの詳細と対策を記載する。
スクラッチ開発の場合の修正とテスト
アジャイル開発ではUT自動化やリファクタリングの技術を武器に修正しながらアプリを洗練化する。UTはクラス単位で可能なので、手軽にテストができる。次にテストは自動化されており、修正後のテストは瞬殺でOKかNGか判断できる。不具合が特定できない場合は、ブレークポイントを使ってデバッグができる。レビューではソースコードのコンペアで修正点のみ確認すればよい。
また、リファクタリングの手法で常に動く状態を維持しながらテストすれば、修正ミスにより動作しなくなりデバッグに多くの工数を使ってしまうリスクも防止できる。
スクラッチ開発で使うJava等のオブジェクト指向言語は上記のような手法で修正、テストできるように高い保守性を考慮して設計されている。
スクラッチ開発の修正とテスト
ETLの場合の修正とテスト
ETLの場合は、テストは入出力単位で行う必要がある。これが最も厄介な問題で、途中でエラー終了しないような整合性の取れたテストデータや出力先のDBを使える状態にしておかないとテストできない。この環境整備はロジックの修正以上に大変なことが多い。テスト用DBを他のメンバーと共有していてデータは容易に変えられない場合はメンバー間の調整が必要となる。
テストの自動化もできない製品が大半である。修正機能とは関係ない部分を誤って変更して不具合を作りこんでしまったとしても検知できない。検知するには、テストケースの全パターンをとおるようなテストデータのセットを用意しておき、維持する必要がある。これは不可能ではないがかなりのコストとなる。多くの場合は仕様変更でテストデータを修正するときに不整合となり破綻する。
ブレークポイントを使ったデバッグも可能な製品もあるが、Eclipse等の総合開発環境のような便利な機能が揃っておらず、私の知る限り、どうしても原因が特定できない場合等でないと利用されないことが多い。
修正点のコンペアも製品によってはGUI上で可能である。しかし、ソースコードのコンペアと比較して可読性が低い。特に、規模が大きくなるとコンペア結果のレビューに多くの工数を要するようになる。
オブジェクト指向で使う継承やインターフェースのような機能はないのでリファクタリングの手法も使えない。少量の修正でも、実行してテストするように作業すれば、常に動く状態を維持できなくはない。しかし、その度にコンパイル、デプロイ、テスト、検証に時間を要するので工数大となる。
ETLのウィークポイントとどう付き合うか？
ETLアプリケーションの開発プロセスを標準化し、シンプルな構成で作成するようにガイドすることで弱点をカバーできる。
例えば1つのETL処理では出力先は1つとなるようにして、データが複雑にならないようにする。こうすることで、UT、レビューの工数も削減できる。小さい単位で作成すると新規開発のボリュームが膨らむデメリットがある。
リリース後に多くの修正が発生する可能性がある場合は、特に小さくシンプルに作成する方が良い。
多くの場合、ETLアプリはXML形式等でフラットファイルに出力できる。このファイルを修正前後で比較することでコンペアができる。しかし、多くの場合は、日時等のコンペア不要な部分を削除しないと、大量に差分が出てしまう。置換用のスクリプトを作成すればコンペア＋レビューはできる。しかし、XML等ではロジックを追いながらレビューするようなことはできない。
リファクタリングやテストの自動化ができない問題については、自作ツールでコマンド化することで影響を小くする。