カンファレンス~海外事例紹介の価値とは

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日本支部 会員メンバ宛)

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

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

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

メタデータ管理の勘所 (その2)

前回は、データ定義を統合的に管理する辞書(リポジトリ)をつくり、育てていくことの必要性を述べた。
今回はその進め方・アプローチについて述べたい。

■ メタデータ管理の進め方:DMBOKの記載

DMBOK2には次のような記載がある
「多くの場合、メタデータ管理がデータマネジメント全体を改善する出発点となる。」(DMBOK2 1章 2.5.5項)

メタデータ管理は「出発点」という性格を持つがゆえ、どこから着手し、どのレベルを目指すべきか、に迷うことが多い。
また残念ながらDMBOKには、他のBody Of Knowlegde本と同様、「何をすべきか」は書いてあるものの、「どうやるか」は具体的にはあまり書かれていない。

12章 メタデータ管理の2項には、
(メタデータに関する)  戦略の策定 → 要件の把握 → アーキテクチャの定義 → 作成と維持   → クエリ・レポート・分析
という枠組みのみが示されている。

要は、要件に応じてメタデータを管理する仕組み(アーキテクチャ)を作り、そこにメタデータを入れ、維持しましょう、という至極当然の記載でしかない。

結局、データマネジメントやメタデータ管理のような活動には、このタスクを順に進めさえすれば良い、という王道は存在しないともいえる。個々の企業の目的や課題、成熟度を考慮しつつ、自らが進め方を決めていくしかないのではと思う

但しその進め方を決めるための観点は幾つか存在する。ここではその観点を挙げてみるとしよう。

■観点1:業務用語から攻めるか システム項目から攻めるか

業務用語から攻めるというのは、例えば業務ドメインのエキスパートをアサインし、業務用語集の整理・作成から始めるような方式である。
システム項目から攻めるというのは、例えばDB定義やIF定義からデータ項目を収集し、その項目定義を進める方式である。

当然のことながら、どちらかが常に優れているわけではなく、ある程度の比率で両方やるべきである。が、どちらに力を入れるかは各企業の状況による。

= 業務用語から攻める場合 =

この場合、業務エキスパートに用語集を作成した上で、仕組みとしては一般的にはポータルサイトのような多数メンバが容易にアクセスできる場所にそれを公開していく。
この方式の利点は、なんといっても業務のドメインエキスパートの主体的な参画とその知見が得られることである。またナレッジマネジメント・知識の共有という別の効果も得ることができる。

留意点としては、業務エキスパート側だけにまかせておくと、どこまでの情報を対象にし・どのような記載とすべきかという点が迷走してしまうことが多い。

例を挙げておこう。
「配送先地区コード: 配送業務の観点で、都道府県を複数の地区ごとに分類したコード。例:東京城南地区)
このようなデータ項目名とその定義情報は有用である。

しかしながら
「東京城南地区: XX区とYY区とXX区の一部を含む。配送作業における注意点として、、、」
これは値そのものであり、メタデータ管理的には不要である。また付随する業務ノウハウの記述も残念ながら不要である。

業務エキスパートに対し、メタデータ管理的に何が必要/何が不要という基準を伝え、誘導するのは難しい場合も多い。
業務ノウハウの記述も、ナレッジ共有という目的に対しては有益な場合もあり、それも明確な一線を引くことの難易度を上げる。

対応策としては、先に結論めいた話になってしまうが、ある程度 システム項目の整備を先行させた上で、業務用語集側にどのような項目を記載して欲しいかを提示する、対応がとれるものは業務用語とシステム項目とのマッピングを管理していく、という方式がよいと筆者は考えている。

ある程度システム項目に軸足をおくことで、業務用語集をメタデータ管理の目的に沿ったものに誘導することが出来るのである。

= システム項目から攻める場合 =

この場合、多くのケースでは既存のDBのテーブル・IFファイルや設計書、モデリングツール等からデータ項目情報を抽出・とりまとめ、データ項目の定義を整理していく。
抽出は手動で実施することもあれば、ツールを導入し半自動的に集約をかける仕組みを構築する場合もある。

この方式の利点は、ある程度までは機械的に進めることができることである。
散財しているデータ定義を一か所に集めて整理する、これだけでも十分に価値を生む成果物ではあり、データ活用・分析対象のデータを探すための手がかりとして利用できる。

留意点は多数あり、以下のような点が挙げられる。

・物理データ項目の意味判別

物理的なデータ項目を、意味を持つ論理的な項目(とその定義)に紐づけていく必要がある。
設計資料にデータ定義が丁寧に書かれている場合はよいが、そうでない場合はデータの値や画面表示のラベルを手掛かりにするなど、定義情報の獲得に苦労することが多い。
また基本的にシステムは、ある限られた領域の業務を満足するために作られているため、領域をまたがってユニークとなるように項目定義がされていることは稀である。「注文日」という項目は販売管理システムであれば受注の日付であろうし、調達管理であれば発注の日付であろう、がそのようなコンテキストは省略された項目名になっていることが多い。

・スコープの絞り込み

基本的に収集するデータ項目数はかなり多量になるため。対象の絞り込みが必要となる。どのように絞り込むかについても方針が必要となってくる。

これらはメタデータ管理そのものの課題でもあり、対応策については次回以降に述べるとしよう。
(次回に続く)