DAMA日本支部 公式ブログ

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

DMBOK2での記述

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

　この表に見られるのは、主に一つのテーブルの各項目ごとの分析となっていますが、この他にもテーブル内での書く項目間の関連や、テーブル間での関連を分析することがあり、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分科会で展開していこうかと思います。

DAMA日本支部では毎年11月にカンファレンスを実施しています
(参考 https://www.dama-japan.org/ADMC2020.html )

我々はその名の通り、国際組織 DAMA-International(以下DAMA-I)の日本支部であることから、 毎年 DAMA-Iや、カンファレンスEnterprise Data World(以下EDW)での関係を活かし 、海外スピーカーを招聘しています。

いま今年の海外スピーカーの調整で様々な議論をしていることもあり、 海外事例として我々は何が聞きたいのだろう？ 何が価値だろうか？ ということを改めて自問しているところです。

しばしば言われる事として、データマネジメント領域においては、 米国・欧州が日本よりも数年先に進んでおり、先進事例が聞けるという意見があります。

個人の所感として、ある面では当たっていると思います。
特に少し前まではこの差は顕著に感じました。

2010年代前半においては、日本ではデータマネジメントという言葉もごく一部しか流通して おらず、その反面 米国・欧州ではEDWのようなデータマネジメントを主題にした 大規模なカンファレンスが行われており、筆者が10年程前に初めてEDWに参加した時はそのギャップの大きさに驚愕したのを記憶しています。
(EDWは今年でなんと26周年！とのことです)

ただデータマネジメントに関わる日本の状況も刻々と変化しています。

デジタル・DX・データ活用などの文脈に基づき、データの重要性は既に市民権を確立しつつあります。
なぜデータが重要か、というそもそもの説明にゼロベースからの多大な苦労が必要な時代ではなくなりつつあります。
（※ もちろん各現場レベルでは、依然苦労していることと思われますが・・・全体の傾向としてです。）

DMBOKは知識のベースラインとして確立され、DAMA-J,JDMCを中心としそれ以外以外にもデータマネジメントについて語られる場も増えてきました。

従い、海外からの単なる「新しい概念の導入」という価値は相対的に縮小しています。

ただ、その背景をふまえても、自分は以下の価値が大きいのではと考えています。

(1) 事業会社主体の取り組み事例の多さ

データの課題は、ビジネスとITの両面にまたがるものです。
IT技術だけで取り組めるものではない、というのは周知の事実でしょう。

国内外の大きな違いとして、IT技術者の所在・所属があります。。
日米の比較になりますが、日本ではSIerをはじめとするIT企業にIT技術者の多くが所属していますが、
米国では事業会社自体に多くが所属しています。（「ソフトを他人に作らせる日本、自分で作る米国」というタイトルの書籍があります）

話を聞いていると、高いスキルをもったIT技術者が事業会社の中でビジネス側メンバと一体になって、自社のビジネス・データの課題に取り組んだ事例が数多くあります。

もちろん日本でもよい事例はありますが、事例の母集団の量にかなりの差があるように感じています。
日本はまだまだビジネス課題とITの推進主体が切り分かれているのではないでしょうか。

この多くの事例の中から特に優れたものを紹介できればと考えています。

(2) 細分化された専門をもつコンサルタントの存在

欧米では様々な守備範囲のコンサルタントが存在しており、例えばデータ品質改善、データモデリングなど様々な専門性を打ち出しています。
またどんなにニッチに思える領域や製品群にも、その導入を支援しているコンサルが一定数存在します。
日本にもマスタデータ統合支援やデータ統合等のサービスを主として手掛けている会社・個人はいますが、母集団数にはかなり差があるように感じています

これらの方々に理論だけでなく、理論と実際の両面で講義して頂くことで日本にとっても価値が高いものが聞けるのではと考えています。

ということで、国内外それぞれのデータマネジメントの状況と傾向を鑑みたうえで、 より価値の高い講演とは何か、ということを今後も検討していきます。
このような話を聞きたいというご意見があれば是非DAMA日本支部までお寄せください。

またDAMA -I・各支部の状況も変化しております。
中国やインドなど新しい国の支部の成長も着目すべき事であり、日本からのデータマネジメントに関する情報発信の必要性も感じている次第ですがこの点については別の機会に記載することとします。

（DAMA日本支部 会員メンバ宛）

当ブログはこれまで主に理事メンバが執筆を行っていましたが、今後 DAMA会員の方からも執筆記事を募集する運びとなりました。

テーマはデータマネジメントに関することなら自由とします。
アウトプットすることで、この領域の深い理解にもつながると思いますので、奮ってのご参加をお待ちしています。
ご興味のある方は以下執筆ルールをご一読の上、連絡をおねがいします。

〇 執筆ルール
・テーマはデータマネジメントに関することなら自由とします。文字数は他のブログを参考にお願いします(あまり長すぎないように）
・製品やサービスおよび企業の宣伝・アピールはお控えください。
・自身の氏名・所属社名の記載は任意です
・執筆希望者は、ブログのテーマ案と公開の目標時期を担当理事 吉村までご連絡お願いします。
   (t.yoshimura(at)dama-japan.org  * (at)を@アットマークに変更ください）

ＩＴ組織、ＩＴ人材育成の中でのデータマネジメントの位置付けについて、今回は、記載したいと思います。

データマネジメントの活動は、ＤＭＢＯＫ（データマネジメント知識体系ガイド）に定義されていますが、企業や事業活動の中で、データマネジメントがどこに位置付けられるのか、考えてみました。また、人材育成面で、データマネジメントについて、定義されているものがあるか考えてみました。

企業や事業活動の中で、当たり前のように、データマネジメントが位置付けられていれば、もっともっと、よりデータマネジメントが認知され、価値が上がり、育成にも力を入れ、みなさんがより活動しやすくなるのではと思っております。

今回は一例です。データマネジメントは、ＩＴに関わる組織、人、のみに関係するのではなく、企業全体での事業活動・取組みがデータマネジメントと思いますので、ＩＴに特化した話をすべきではないと思っていますが、まずは、ＩＴ組織・活動の一例を記載したいと思います。

「i コンピテンシ ディクショナリ」というものをご存知でしょうか。ご存知の方も多いと思いますが、紹介したいと思います。

「i コンピテンシ ディクショナリ」とは、ＩＰＡ（独立行政法人　情報処理推進機構）のＩＴ人材育成事業の取り組みの一つで、人材育成の枠組みになります。

ＩＰＡが提供する「i コンピテンシ ディクショナリ」（以降、ｉＣＤ）は、企業において、

• ＩＴを利活用するビジネスに求められる業務（タスク）
• それを支えるＩＴ人材の能力や素養（スキル）

を「タスクディクショナリ」、「スキルディクショナリ」として体系化したものになります。

「タスクディクショナリ」、「スキルディクショナリ」、それぞれ辞書のように参照できる形で構成立ててまとめられており、「タスクディクショナリ」は、タスク３階層と評価項目の計４階層で構成。「スキルディクショナリ」はスキル３階層と知識項目の計４階層で構成されています。

実際に、ＩＴ組織（ＩＴ部門、ＳＩ会社、ＩＴ関連会社等）の新規立上げ時の組織や業務の定義、また、事業・業務運営中の際も、改革・改善検討、役割整理の参照モデルとして「タスクディクショナリ」が使われていたり、人材育成時のスキルの棚卸し、定義、また人材評価の仕組みを策定する上での参照モデルとして、「スキルディクショナリ」が使われており、企業は経営戦略などの目的に応じた人材育成に利用することができます。

２０１４年７月３１日にいｉＣＤの試用版を公開し、パブリックコメントや産業界における実証実験などを踏まえ、２０１５年６月に正式版を公開されています。

以下、参照下さい。

https://www.ipa.go.jp/jinzai/hrd/i_competency_dictionary/icd.html

ｉＣＤ２０１８から新たに「タスクディクショナリ」に、「データマネジメント」のタスク追加がされました。
オレンジ色の線で四角に囲っている部分です。

出典： ｉＣＤ　 タスクディクショナリ　タスク構成図　から引用。

ｉＣＤのタスクディクショナリの「データマネジメント」タスクには、以下が定義されています。

• データガバナンス
• データセキュリティ管理
• データ品質管理

ｉＣＤでは、上記の図の左の方には、戦略、企画、開発等のタスクが定義されていまずので、データマネジメントに関するタスクはその中にもあり、位置付けられています。（データ設計等）

当然、ｉＣＤと、皆さんが活用されているＤＭＢＯＫは、別の目的で作られたものであり、カバーする範囲もカテゴライズも、異なりますが、 企業においてＩＴを利活用するビジネスに求められる業務（タスク）の中で、データマネジメントが定義されているのか、また、どこに位置付けられているのか、参考にして頂ければと思います。

「スキルディクショナリ」には、スキル、職種が定義されており、データマネジメントに関するスキル、職種も探して頂ければ、参考になると思います。

ｉＣＤは、以下、オフィシャルサイトもありますのでご参考までに。

https://icd.ipa.go.jp/icd/

「タスクディクショナリ」、「スキルディクショナリ」 は上記サイトからダウンロード可能です。

以上

大規模なデータモデリングを行う場合，データモデルをいくつかに分割して作成するのが一般的である。この部分図を，データモデリングツールではサブジェクトエリア（ERwin），あるいはサブモデル（ER/Studio）と呼んでいる。以下，このBlogではサブジェクトエリアという用語を使用する。

データモデリング分科会で，このサブジェクトエリアはどういった単位で作成すべきか，あるいは，その単位には理論的な裏付けがあるのだろうかという問題提起があり，これについて分科会でディスカッションを行った。

大規模システムの設計・開発では，いくつかのサブシステムに分割し，それぞれのサブシステムごとに設計・開発が行われるのが普通だが，大規模データモデルも同様に分割してモデリングすることが妥当と思われる。しかし，時々，模造紙を何枚も張り合わせた，ものすごく巨大なデータモデルを見ることがある。さぞかし，維持管理が大変だろうと思われるが，分割したら分割されたサブジェクトエリア間の関連がわかりにくくなるという問題もあるのか、あるいはサブジェクトエリアにデータモデルを分割するという概念に馴染みがないのかもしれない。

問題提起された課題は以下が代表的なものである。
１　サブジェクトエリアび分割の基準や理論的裏付けはあるのか？
２　サブジェクトエリアに書かれるエンティティ数はどのくらいが妥当か？
３　サブジェクトエリア間で，重複して描かれるエンティティがあっても良いのか？それとも，サブジェクトエリア間でエンティティは排他であるべきか？

まず，サブジェクトエリアの分割基準についてだが，理論的裏付けは難しいものの，ベスト・プラクティス，あるいはリファレンスとなるべきモデルはありそうである。残念ながら日本語訳は出ていないが，アメリカのデータモデラーであれば，まず絶対に読んでいるData Model Resource Book（L. Silverston）のVol.1では，
People and Organization
Products
Ordering Products
Shipments
Work Effort
Invoicing
Accounting and Budgeting
Human Resources
といったサブジェクトをあげている。サブジェクトエリアを考えるうえで，かなり拠り所になるかと思う。ちなみにアメリカでは業界団体，あるいはIBMやOracle，テラデータといったベンダーが提供しているデータモデルも，これに類似したサブジェクトエリアを設定している。理論的裏付けはともかく，かなり類似しているように感じている。これらのサブジェクトエリアは，図書分類に似ているという指摘もあった。分割範囲が大分類から細分化していく点も図書分類に類似している。

次にサブジェクトエリア単位のエンティティ数について。これは分科会で数10から，最大100以下といった経験を共有できた。数はけっこうバラつきが多いが，これはどこまでサブタイプを設定するかにもよるかと思う。あまりにも多い場合はさらに細分化した単位にサブジェクトエリアを分割するほうが良いだろう。

サブジェクトエリア間でエンティティが重複して良いのかについて。サブジェクトエリアを図書分類のように考えると，１つのエンティティが複数のサブジェクトエリアに所属するということはあり得ない。しかし，厳密に重複なしとすると，いろいろと支障が出てしまう。例えば，製品の担当者の関連，製品と売上の関連といったものは，図書分類的なサブジェクトエリアでは表現できない。こうした関連を表すためのアプローチの１つとしては，あるサブジェクトエリアのデータモデル図に，そこに属するエンティティと関連がある周辺サブジェクトエリアのエンティティも参考として書き加えるというテクニックがある。みもう１つは業務視点（たとえば受注業務）でデータモデル図を作成することである。これを組み合わせるとサブジェクトエリアを縦軸と横軸で表すことになり，ビジネスルール等をデータモデルで表現することができる。（全てのビジネスルールではないが，データ構造で表現できるビジネスルール），ただ，この縦軸・横軸の組み合わせをサブジェクトエリアとして考えるべきではという問いかけもあった。

参考となるサブジェクトエリアを，それぞれの企業にあてはめ，そこに独自部分をモデリングしていくと，出来上がるデータモデルの品質やモデリングにかかる時間の点で大きなメリットがあると信じている。このテーマについては今後もより具体的、実践的に議論を深めていきたいと考えており，データモデリング分科会では再度，取り上げていきたいテーマである。