投稿者: 稲見 浩一

　これまで、主に 主にデータモデリングについて取り上げてきましたが、今回は関係深いものの一つとして、データプロファイリングについて紹介したいと思います。以前にも、少し触れていますが、もう少し詳しく見てみましょう。

DMBOK2での記述

　DMBOK2の中でも、 何箇所かで取り上げられているので見てみましょう。最も大きく取り上げているのは「第13章　データ品質」の中です。1.3節の本質的な概念の9番目に「1.3.9 データプロファイリング」として登場します。
　定義としては「データを検査し、品質を評価するために行われるデータ分析の一形式である」とされています。統計的手法を活用して、収集したデータの真の構造、コンテンツ、品質を洗い出すとあり、データのコンテンツと構造のパターンを識別するために利用できる統計処理結果を生成します。

NULL数	NULLが存在することを検出し、許容可能かどうかを検査できるようにする。
最大値・最小値	マイナス値などの異常値を検出する。
最大長・最小長	特定の桁数要件を持つフィールドの外れ値や異常値を検出する。
個々のコラムに存在する値の分布度数	値の妥当性を評価できるようにする。（トランザクション内の国コード分布、値の発生頻度検査、初期値が設定されているレコードの割合など）。
データタイプとフォーマット	フォーマット要件への不適合レベル、想定外のフォーマット（小数点以下の桁数、スペースの混入、サンプル値など）を検出する。

　この表に見られるのは、主に一つのテーブルの各項目ごとの分析となっていますが、この他にもテーブル内での書く項目間の関連や、テーブル間での関連を分析することがあり、DMBOK2ではクロスカラム分析と記載されています。

　「第５章 データモデリングとデザイン」では、ツールの節で「3.3 データプロファイリングツール」として紹介され、ツールによってデータの中身を調べ、既存のメタデータと照らし合わせて検証したり、既存のデータ関連生成物の不備を特定したりするのに役立つことがかかれていました。例として、従業員に複数の職位がある場合をあげていました。
　DMBOK2では、データプロファイリングが何らかの形で、第5、8、10、11、12、13、14、15、17の各章に登場しています。

ツールの利用に関して

データの中身の検証は、データプロファイリングという名前で紹介される以前から実施されてきました。私の場合、初期としてはシステムの再構築におけるデータ移行を目的として始めた記憶があります。特に最初に行ったのは、いわゆる「区分値」の調査でした。再構築に伴い「区分」も見直され、統合や新設、再編を行うことがありますが、その対応をマッピングするために、現在実際に使われてきた値を調べることを目的としていました。
　このために、多くはレプリケーションのデータベースでSQLでGROUP BY句を使って、区分値の種類と、実際に使われている数を出していました。

SELECT 区分値, COUNT（*） FROM 表 GROUP BY 区分値;

こんな感じで、必要な数のSQL文を実行していけばそれなりに機能しますが、テーブル数、項目数が多いと大変です。現在では、データ品質やデータカタログ関連のツールで、プロファイリングの機能が搭載され、簡単に正確に、度々検証することができるようになっています。
　区分値だけでなく、コード系などでもXXX-XX-XXXとか、XX-99-9999などのようなものが混じって居たり、過去の経緯で色々と乱れているものも発見できたりします。
　システム再構築の際のデータ移行だけに使うのではペイしないかも知れませんが、その後のデータ品質とガバナンスに繰り返し使うことを合わせて導入するのが良いかと思います。

データモデリングと関連して

　データモデリングを行ったら、できればデータプロファイリングも実施して、区分値によるサブセットの検証を実施して欲しいです。ナンバーコードに埋め込まれた有意味のコードも確認できます。
　データモデリングによってサブセット分析を行い、区分による業務の差異をサブセットとして切り出せますが、定義書にかかれている区分値と実際のデータベースに入っている区分値では実際には少し異なることがあります。 　定義書によれば、1、2、3の値が定義されていても、実際には3は使用されておらず、一方で4とか5とか、場合によっては99みたいな値が勝手に作られていることが少なくないようです。
　この場合、3に相当するサビセットは実際には不要で、4と5に関するものを詳細に調査する必要があります。また、99のような値が設定されている場合は、その値をプログラム中でどのように扱っているかまで、確認する必要がありそうです。

　こういった議論も第10分科会で展開していこうかと思います。

　データマネジメントを始めるのに、「データモデリングから始めませんか？」というお話をし、その次に「データモデラーのお噺」と続けました。

　では、 データモデラーが居れば、或いは獲得すれば、すぐにデータマネジメントが始められるのでしょうか？その前にもう少しやっておきたいことがあります。
　データマネジメント自体が、業務部門の人とIT部門の人が一緒になって行う企業活動であることはDMBOKに記載されています。

　ここでは、データマネジメントに始まり、情報システムの開発（もちろん再構築を含みます）に至る話を書いていきます。

企業とITベンダー（古いスタイル）

　 これまで少なくない企業で、情報システム部門、或いは情報システム子会社が次のような形での発注を行い、システムを構築して来ました。ITベンダーも様々ですが、こちらでは主にシステムインテグレータ（SIer）を指しています。

• 企業内では、業務部門からの要望を情報システム部門が取りまとめ、これらを要求事項としてITベンダーに発注を行っていました。
• ITベンダーでは、これらから対象となる業務の単位を一つの機能として設計し、機能ごとにプログラムを作成します。
• この際、主に「業務フロー」が用いられ、ビジネスレベルでのデータモデリングが行われることは稀なようです。
• ITベンダーから、二次受け、三次受け、など多重請負が様々な問題を起こしてきたことは知られています。
• 発注した企業側は、完成したシステムの納品を受け、受け入れテストとして、実際の業務が行えるかという視点で検証を行います。この時点で、データがどうなるかという点においては、過去のデータが継続して使えるか以上の関心が持たれることは少なかったようです。
• 実際には、納品時点で機能が足りない、仕様に齟齬がある、移行したはずのデータに問題が発生するなどの不具合を沢山見てきました。

実際には、このようにIT部門が要望を纏めて発注を行ってくる形態の場合でも、データモデリングを行い、既存システムがあるならデータプロファイリングを行うなど、業務上の情報の構造と実際のデータによる可視化を進めれば問題は相当に小さくなり、いわゆる凝集度が高く結合度が低い、改修が容易なシステム構築を行うことは可能です。しかしながら、その場合でもIT部門だけではなく、業務部門の方の協力が必要です。
　それでも、複数のシステム間の問題を解決するためには、データマネジメントによる全体の調整が必要です。

企業とITベンダー（新しいスタイル）

　企業内でデータマナジメントを実践するには、何らかの形でそれを推進する組織が必要です。

専任かバーチャルかなど、その形は企業により、その段階により様々になると思いますが、業務部門の人、つまり業務のエキスパートの方と、情報システム部門の人からなる組織を形成します。
　ここでデータ要件の定義やアーキテクチャの定義から、データ品質のマネジメントや、データ統合やBIなどを担っていきます。これまでITベンダーに依存してきた多くのことを自社内で担っていくことになります。
　これまでに持っていなかったスキルが必要になる部分や、先ずは組織化を行っていく部分については、外部コンサルからの支援を受けて実現するのが有効です。プログラム開発のパワーが不足する部分は、外部プログラマを利用する形になります。
　既存のシステムの維持なども含めて、もちろん一気にこの形に変更するのは難しいと思います。しかしながら、一部からでもこちらの形に変えていかないと、これまでと状況が変わりません。
　まずは、現在依頼しているITベンダーに対して、このような形に変革していくこと、この外部パワー部分を担えるなら役割を変えていくことを検討してみましょう。現行のITベンダーでは、特に組織化の支援が担えないような場合は、その部分に別途専門のコンサルを導入することが必要となります。
　データの発生源となる部署、データを利用する部署、情報部門システムから人を出して検討を始めるグループを作るような形で始めても良いでしょう。最初は、情報システムが主導する形になることが多いでしょう。或いは利活用の要求が先行する場合なら、その対象の業務部門が中心となって進めた方が良いかも知れません。

　ともかく、実際に活動を始めるにはどうしたら良いのか、自社でできていることは何で、何が必要なのかわからないという方、DAMA日本支部に参加して、いろいろな分科会に参加してみてはいかがでしょうか？

　前回の私のブログでは、データマネジメントの入り口の提案として、データモデリングをお薦めしました。その際に、データモデリングするに当たっては、有意義なモデルを作れるデータモデラーを確保できるかという点が課題になると述べました。
　それでは、そのデータモデラーの確保について考えてみましょう。皆さんの会社、或いは組織では、データモデラーは確保されていますでしょうか？

　例えば開発案件において、事前にデータモデリングによる現行仕様の、或いは業務の可視化が行われているかと言うと、残念ながら過去に見た多くの例では、殆ど行われていませんでした。
　データモデリングが行われていないところでは、必要だとは聞いていても、それまで行わないで何とかなっているからというのが大きな理由で実施されていません。実際にできていた場合との直接的な比較がないため、隠れた大きな損失に気付かないのです。
　そして決定的な理由は、実際にできる人が居なかったことにより、実践できないままだったのだろうと思います。取り組もうとはしたが、結果的に断念したという話を聞いたことも、少なくありません。

習得の過程

　なにごともそうですが、技術の習得には次のような過程が必要です。

　教育を受けるだけでは、頑張っても2段階目の「基本的な内容がわかる」までであり、実際に「自分で問題無く使える」ようには、なかなかなれません。

　そのような中で、例えば改善の意欲のある若者が、自分が担当するプロジェクトの中で活用してみようとすると、マネージャから「そんなやり方でうまくいくのか？実績や経験があるのか？これで問題が起きたら責任取れるのか？」などと抵抗されてしまうと心が折れてしまいます。そうではなく、既にできている人からの支援を受けながら、繰り返して実践することが必要です。

　前回ブログ冒頭にて日本のどれ位の企業で、データモデリングが行われているのか、という話題を上げました。しかしながら、この点についての答えを持っていません。周辺のモデラーと呼ばれる人たちに聞いても、多くないのでは？という返事しか得られません。

　色々な企業の方と話をする中で、自社にデータモデラーと呼ばれる人は居ない、或いは、かつては居たけど今は居ない、更には、居るのかわからないという声が多く聞かれます。
　前回、データマネジメントに着手する組織を立ち上げられたら、まずはデータカタログの構築に先駆けてデータモデリングを実施するようにお薦めしました。しかしながら、データモデラーが社内に見つからない中、どうすれば良いのでしょうか？

データモデラーの確保

　自社内にデータモデラーが居ないのであれば、呼んで来るか、作るしかありません。
　●呼んで来るとしたら、何処からでしょうか？
　●作るとしたらどうやって？
という疑問が出てきます。

　私の勤務先に依頼すれば出てくるかと言われれば、私の他には3人だけしか居ません。親会社である、あのDX企業でも、今では１人だけしか知りません。
　さて、世の中ではどうかというと、このDAMA日本支部の理事にも数名のデータモデラーが居ますし、データモデリングに関する分科会も開催されています。なので、どこに居るか探して確保するとか、社内で育てるのに支援してくれる人を見つけたいなら、相談していただくのも一つかと思います。ただし、特定の誰かを推薦するという立場にある訳でもなく、紹介した人の能力に責任を持てる立場にもありません。

　DAMAのイベントであるADMCでも、スポンサーの方によるライトニングトークの中で「優秀なデータモデラーを絶賛募集中」と宣伝されている企業もありました。

　データに関して、何処にあるのか、どんなデータが有るのかを知っておくためにはデータマネジメントを行う必要があります。そのデータマネジメントを行う重要なピースであるデータモデリングを実践する人が見つからないというのは皮肉な状況にあると思います。

　できることなら、データモデラーが集う場があり、データモデラーを探す企業の人が、適切なモデラーを見つけられるようになればと思っています。いわゆるギルド的な感じのものができると良いのかも知れません。
　場といっても、特にこんな状況なので、オンラインでの場作りを試してみたいと考えています。
　そんな場を一緒に作ろうというモデラーの方、それ以前にでもデータモデラーを探していますという方、モデラーの育成をしたいという方は是非ご連絡ください。よろしくお願いします。