ここ、1、２年くらい、いろいろなお客さん、社内の誰かが作った現行システムの調査、分析を行ってます。
開発を行うよりも、ソース見て、設計書見て、「不具合？」「なにこれ？」「へ〜〜そういうこと」ということが多く、びっくりと発見を繰り返しながら
・今の状態を極力可視化する
・設計書とソースの差異を洗い出す
・問題点を出す
・解決の方向性を示す
というのも意識して、実施しています。
今回は、タイトルのとおりETL。。。の分析。
今までETLツールを実際に扱ったこと無い（HULFTはあるが、設計はしたこと無い)という状態でしたが、基本、データを加工するだけなので、見方さえ覚えれば、なんとかなるもんなんだと。
さて、実際に解析して気づいたのですが、こういうことがあると調査がとまどるな〜〜ということがあります。
・意味のないカラムや項目が紛れている（なんであるのかな・・・調べたのに使ってない）
・意図通りに動いているのか判断できない条件文（バグかな？？）
では、どうやって乗り越えるのか。
世の中にはたいそう便利なリバースエンジニアリングツールが多くあるのは知っております。しかし、実際にそのツールを使って分析しているお客さんにいまだあったことはございません。
個人的には、実際のソースはツールを利用すれば、見えるのだが、本当に知りたいのは、
「なんでこんなことしているんだろね」
「今をベースもしくは新しく作りなおすには何を気にしないといけない？」
といったことを知りたいものかと。
それを起点に考えると、いくら現在のシステム状態を見せても「で？？」と聞かれるのが落ちなんでしょうね。
では、私は何をしているか・・・。
と、言っても画期的なことをしているわけじゃないです。
やっていることは３点
・ER図の作成（ETLの元、先のシステムのDBの）
・ETLの処理のマッピングを人がわかるレベルで記載
（ツールでうまく出しているのもあるが、I,P,Oで記載）
・ETLのJOBの関連性を記載して、時系列で表現する
と、いうことです。
要は、点ではなく、線や面で表現して、ユーザが利用している業務の言葉や、表現、流れに以下に近づけて、今の業務の問題点を炙りだしてもらうか。次の新システムの考えをイメージしてもらうか・・・が勝負かと。
地道な作業ですが、データの移行などの肝となる作業なので、早く、正確にやらんとなと。。
