ETL/EAIツールでデータ連携処理を構築するベストプラクティスとは？(第2回)

こんにちは！アシストでデータ連携製品(DataSpider/DMExpress)を担当している市毛です。

私はETL/EAIツールのフィールド技術担当として、お客様が製品を最大限に活用できるように
ツール購入後の初期支援(製品トレーニング、スキルトランスファー支援、標準化支援等)を日々行っております。

そんな日々のお客様支援を通じて得られた「データ連携処理構築におけるベストプラクティス」を
私なりにまとめたものを連載でお届けしたいと思います。

1) データ連携処理開発にETL/EAIツールを利用するメリット
2) データ連携処理開発の躓きやすいポイント（←今回はココ）
3) データ連携処理開発プロセスのベストプラクティス

データ連携処理開発の躓きやすいポイント

データ連携の開発時によくある失敗例とはどんなことでしょうか？

例を6つ挙げてみます。

■データ連携開発時によくある失敗

１.データ連携開発着手が遅い
２.利害関係者間で対立
３.複数システムの仕様理解者がいない
４.ツールの検証が不十分
５.ツールの適用範囲があいまい
６.ツールの標準化が浸透していない

読者のみなさんの中には「あるある・・」と共感していただけるケースもあったのではないでしょうか？

この6つを大きくカテゴライズすると

「プロジェクト管理の問題」と「ツール適用の問題」

の2つに分けられます。

データ連携開発でよくある失敗例

ETL/EAIツールを提供する弊社としては
このうちの「ツール適用の問題」にフォーカスして
・ツール検証が不十分
・ツールの適用範囲があいまい
・ツールの標準化が浸透していない
の３つのポイントについてそれぞれ考察していきたいと思います。

ツール検証が不十分

よくある失敗事例がこちら。

「マニュアルベースでアダプタの機能について確認していた。
　しかし、実際に使用してみたところ、仕様的にアクセスできないデータがあることがわかった。」

企画/計画段階でのツール検証が不十分だったことにより

　→設計フェーズ以降に問題が発覚・・・
　→想定外のシステムアーキテクチャ等の見直しが必要となる・・・
　→スケジュールや工数に影響を及ぼす・・・

という失敗パターンです。

この問題に対して、考えられる解決策としては

・クリティカルな要件を整理して重要度付けを行う

・重要度に応じて可能な限り実環境で評価版検証する

ということが挙げられます。

ツールの適用範囲があいまい

よくある失敗事例がこちら。

「業務的なロジックをデータ連携処理に組み込んだため、
　業務に仕様変更があった場合の影響範囲が不明確になってしまった。」

「処理負荷の高くなる業務ロジックのため、連携性能が落ちてしまった。」

企画/計画段階、もしくはアーキテクチャ設計の初期段階で
ツールにどこまでを任せるのかを見極められないまま進めてしまったことで
このような問題が発生しがちです。

この問題に対して考えられる解決策としては

・データ連携機能に持たせる機能範囲の優先度をつける

・データ連携の標準的なパターン/適用範囲を明確化する

ということが挙げられます。

ツールの標準化が浸透していない

よくある失敗事例はこちら。

「複数のチームで開発したため標準化にばらつきがあり、開発生産性/保守性が落ちる。」

「複数のチームで同じような処理を重複して開発してしまう。」

設計フェーズ以降でよくある問題です。

特にプロジェクトの規模が大きいほど、この問題に対する影響度合いが高くなります。

システム構築に携わっている方であればお分かりのとおり
これはツールを利用したデータ連携システム構築に限った話ではなく
通常のシステム構築でもよくある問題です。

この問題に対して考えられる解決策としては

・ツールの特性を踏まえた標準化ルールを策定/運用する

・ツールにおける共通化の手法と制限事項を押さえる

・ツールを利用した構築TIPS集を用意する

「ツールの・・・」という言葉を省けば、前述の通りシステム構築全般の設計/開発の解決策と言えますね。