「統制語彙」とデータモデルに関する話題(10/21(木) 10分科会を踏まえて)

10月21日(木)に開催された月次の第10分科会で話題となった「統制語彙」とデータモデルの果たす役割に関するディスカッションを取り掛かりに、今回のブログ題材として取上げる。

この回の勉強会では、4月迄に行われた第12分科会話題とDMBoK2第9章「ドキュメントとコンテンツ管理」記述内容を材料にする形で、分科会メンバ國澤氏からの話題説明および考え方を解説する形で議論が進められた(題目:「統制語彙とデータモデル」、分科会参加者14名、ZOOMオンライン方式)。

今回の話題は、概念データモデリングのアプローチが「統制語彙」(Controlled Vocabularies)を整備するために役に立つというDMBoK2の説明要素を、議論の糸口として始められた。また、同時に統制語彙を取り囲む語彙集合の位置付けとしてフォークソノミ周辺語彙を関係付けた説明があった。単にER図だけでなく用語定義等の説明情報を含めてこその本来の「データモデル」であることも話題要素となった。尚、DMBoK2第5章における概念データモデル・アプローチの基本的考え方は、エンティティ定義と意味の明確化をモデル作成上の主要要素としている点を確認しておくと議論として分かり易い。

ここで確認のためにDMBoK2(日本語版)p.173での概念モデルの説明を引用する。「概念データモデルには、関連する概念の集合体としてデータ要件の概念が取り込まれる。ここには、特定の領域や業務機能に関する基本的で重要なビジネスエンティティのみが含まれ、各エンティティの説明とエンティティ間のリレーションシップが含まれる」とある。IE表記法を用いたリレーショナル概念データモデルの例として、学校、学生、応募書類の関係をモデル化した例をこの回でも議論題材として取上げた(図1)。

図1に表される動詞句表記が必須であるかどうかについては、モデラーの立場による議論の余地があるものの、このような概念モデルを関係者間で確認し作成する中で、出現する語彙(主にエンティティ名となる語彙等)の表す意味合いが共有・図式化され、統制語彙(の候補)として用語整理する上でモデリングの役割が発揮されるという流れである。更に、この概念モデルの表す意味関係を変えずにエンティティの主キー属性を検討し、他の属性項目を加えてゆくことで次段階としての論理データモデルに落とし込むのがデータモデル詳細化の進め方となる(DMBoK2 日本語版、p.175、図48参照)。その実装に向けたモデル整備過程ではリレーショナルモデルの正規化といった要素の考慮等が必要とされるが、ここでは語彙論議から外れるためその詳細は割愛する。

当日の議論には出ていないが、筆者の立場としては、このような手続きにより統制語彙候補を抽出した後で、最終的に統制語彙としての採用要否の検討要素として、オントロジの考え方が必要になるという点をここで加えておきたい。例えば、図1の例では、「学生」という語はオントロジ視点を通せば「ロール」概念として位置付くものであり、論理モデル化でのモデル表現の仕方に影響が出ることになる(いわゆる海外で取上げられることの多いパーティモデルは、この視点での立場を取っている)。更に、用語を利用する部門によっては、同じ用語の意味使いに差異が生まれることが実務上存在する点を考慮する際には、統制語彙レイヤ(≑共通語彙)と部門用語レイヤ(部門ビューともいえる)のような階層化視点での用語整理実施という語彙設計も必要であろう。これは語彙の方言、いわば多元的フォークソノミの話題として深掘り検討すべき内容と考えられる。

DMBoK2第9章では、統制語彙の実用的な例として図書館情報分野で利用されるダブリンコア(Dublin Core)の語彙が紹介されている。日本でのこの語彙の利用状況は、国立国会図書館のダブリンコアメタデータ記述(DC-NDL)Webページで知ることができる(こちらを参照)。

統制語彙の考え方に関連した第二の話題としてここで次の補足をしたい。IPA(情報処理推進機構)の推進するIMI情報共有基盤事業(Infrastructure for Multilayer Interoperability)について簡単に触れる。これは、電子行政分野におけるオープンな利用環境整備に向けたアクションプランの一環で、データに用いる文字や用語を共通化し、情報の共有や活用を円滑に行うための基盤構築プロジェクトとして2013年を起点として計画・推進されている(※2)。これは、共通語彙基盤および文字情報基盤の2要素からなり、この中の共通語彙基盤の内容が今回の話題に関係する話題として参照できる。

このプロジェクトでは、行政分野でのデータ流通相互運用性向上を目指す中で、コア語彙およびドメイン語彙からなる語彙データベース(DB)構築が取組まれている。分科会で議論した概念データモデル作成のアプローチとは異なる方式で共通語彙の整備が行われ、2019年2月時点でコア語彙バージョン2.4.2が公開され(現時点最新)、ここでの共通語彙群の位置付けは、図2のように表現されている。

この図2での語彙階層は、以下のように説明されている。

(1)コア語彙: 分野を超えて使われる共通性のある用語(【人】【氏名】など)の集合

(2)ドメイン語彙: コア語彙の概念を継承して定義した、分野固有の用語の集合

(3)応用語彙: 現場の必要に応じ,既存の語彙を継承した独自の 語彙を定義する必要が出てくるが,これを応用語彙と呼ぶ。応用語彙は,将来,分野に共通な語彙を洗い出すなどによりドメイン 語彙へと整理されていくことを想定している。

IMI共通語彙基盤の中で定義する語彙範囲は(1)と(2)であり、現時点コア語彙(1)のうちクラス語彙約60、プロパティ語彙約250が定義されている。(2)は今後の応用分野の開発の中で(3)と共に定義してゆく領域として扱われるものと説明され、プロジェクトWebページでは現在(1)項目の共通語彙が定義公開されている。

概念モデルアプローチから抽出されるのは主にエンティティ名に関する語彙(用語)になり得ることは冒頭からの議論紹介の中で記述したが、こちらのアプローチでは、クラス語(ほぼエンティティに対応)に加えてプロパティ語(リレーショナルモデルでは属性項目に相当)が定義されている点に違いがある。これはLOD(Linked Open Data)トリブル表現からの設計アプローチでは、エンティティ(≑クラス)、属性(≑プロパティ)、インスタンス/オカレンスが区別されない形となる集合的用語認識から始まる結果、当然現れる現象といえる。このようなモデルでオントロジ言語利用(OWL:Web Ontology Language)の必要性発生とも関係している。実際、(1)で定義された語彙の実装は、XMLおよびRDF定義形式で提供されている(この語彙定義は、同プロジェクトWebサイトからダウンロードできる)。

ここで見たように、語彙定義、そして相互利用のための共通化を目的として整理する語彙種別や内容範囲に違いが現れるということは、統制語彙や共通語彙という呼び名とその整備アプローチに加えて、語彙定義を行う目的と適用方法および範囲を先だって明確化する必要があることを示唆している。更に、これに加え、複合語、部門用語、方言的使い方を設計上考慮するという点も含むべきであると筆者は考える。この辺りは、DMBoK2 日本語版pp.339-343、「1.3.2.4 用語管理」~「1.3.2.9 オントロジ」の説明内容に着目すると、より分かり易いものとなる。

このようにして整備した語彙群を共有化し、管理実現を可能にするには、参照データ、メタデータとしての管理機能群を提供することが実装の要点となる。これらについてはDMBoK2第10章「参照データとマスタデータ」、第12章「メタデータ管理」の各章に関連する考え方や情報が取上げられており、更なる興味のある方はこれらの章を参考することにしたい。その際、語彙の統制管理(開発過程での利用を含む)とビジネス利用者から見た利用語彙/用語の運営とは区別するものと捉える方が分かりやすいと考える。それは、前者は技術メタデータ用語管理、データディクショナリ管理の領域話題として扱われ、後者はグローサリー(用語辞書、ビジネス用語集、メタデータ管理の一部)の提供話題として分けて説明される傾向が高いからである。これはまた、メタモデルの作成方針とも関係する。参考に、データディクショナリとビジネス用語を分けて管理するための概念メタモデル図を図3に例示する。

またDMBoK2の上記各章中に記述されているように、語彙/用語の整理および利用検討に当たっては、同音異義語、異音同義語、同意語(シソーラス)、複合語といった見方による整理が必要である。これに加え筆者は、基本語彙の辞書だけでなく、先に述べた利用者ビュー(部門ビュー)階層の設定、用語読み仮名(英文字)の活用といった考慮点を追加することが有効であると考えている。

(以上)

※1  DMBoK2 第5章p.174 「図46 リレーショナル概念モデル」を引用

※2 詳細はIPA/IMIページを参照。 https://imi.go.jp/ (2021年10月27日時点)

※3 出典: 情報処理学会デジタルプラクティス Vol.9 No.1 (Jan. 2018)

      IMI共通語彙基盤 p.35 図1 共通語彙の3層構造

※4 以下の資料を参考に筆者作成:

  The Joint C3 Information Exchange Data Model, Metamodel

(JC3IEDM Metamodel)   V. 3.1.4, Feb. 2012,

Multilateral Interoperability Programme(MIP)

[投稿者]中岡 実(インフオラボ游悠 代表/データマネジメントコンサルタント、ITコーディネータ、PMP、認定心理士)

データマネジメント成熟度評価を考える(8/25 10分科会話題より)

8月25日(水)に月次の第10分科会(ZOOM方式)が開催され、筆者が以下の題目で説明を行いました(参加者19名)。この記事ではその話題概要と、出された質問の回答に補足する内容を記します。

題目:「データマネジメント成熟度評価/データモデル評価の考え方」

この分科会で議論したように、データマネジメント(DM)成熟度評価の実施/適用を考えるに当たっては、以下の3点を意識した計画が必要です。(当日の資料については筆者の運営するWebページからダウンロードできます。興味ある方は参照下さい(※1))。 

  1. 目的設定および結果の使用方法の明確化 
  2. 評価スコープの設定(対象部門、システム領域、時間的スパン)
  3. 参加者(成熟度評価実施者、実務側の関係者)を含めた中での意図・内容理解のためのコミュニケーション実施

企業としてのDM活動は、言うまでも無く個人の努力のみで成立させるものでなく、組織的活動により成果(例えば高品質なデータを提供する)を生み、長期的に維持する環境を築く事と捉えられます。企業のマネージャレベルの方との話として筆者がDM成熟度の話題を出すと、案外簡単に「自社のレベルはゼロかな。」或いは「うちは1だね。」のような答えが返ってきます。恐らくそのマネージャ感覚は正しいと推察されますが、そのままで済ませていると何時まで経ってもDM環境は改善せず時間が過ぎ去ることになります。現場でデータを扱う方々やシステム関係者は何となく日々の問合せに追われ続け、時によっては何らかのトラブル対応に大部分の時間を費やさざるを得ない状況も生まれます。

それでは、成熟度アセスメントの使い道は一体何なのでしょうか?その考え方の第一の要点「項目1」を図1に纏めました。

現在状況で十分に要望を満たせている場合を除き、自社のDM環境を何とか将来を見据えて改善したいという思いを形にするには、それを企業内公式化する必要があります。このための手段として利用するという考えがあります。DMBoK2 第3章「データガバナンス」のコンテキスト図(同図14)で、入力として成熟度アセスメントが記載されているのはそれを意図するといえます。現状を知り、将来に渡る改善/改革目標への道筋を立て、そのためのプログラム/プロジェクト予算化・リソース確保を確実にするという流れです。従って、この段階のアセスメント(査定)は、余り細かな問題点や対策を突き回すというよりは、中期的な視点での課題とその改善の方向性を見出し、そのための予算化の必要性を経営者/オーナーに理解してもらうために利用すると考えることです。実際の予算額見積りやプロジェクト化は次の段階として検討されることもあるでしょう。

この公式化を納得性のあるものとするためには、目指すDM環境に関して何らかの根拠が要求されます。このためにDM成熟度フレームワーク(DMMF)を参照する事が一つの有力な考え方です。DMMFは有識者により、有効な企業内DM環境のための必要要素を整理したもので、ゼロからDM構想を練り上げることなく時間の大きな節約につながります。この意味である程度の客観性を供えたものとして使用できます。そして冒頭で取上げた三要素の中の「項目2」を検討する材料とできます。但し、DMMFは理想的環境構築(レベル5或いは6)を前提とした幅広い視野で構成されている点に注意が必要で、ピンからキリまでを取上げたものといえます。つまりDMMFを与えられたものとしてそのまま利用するのではなく、自社の当面の目標として、どういう要素をどの程度までに実現するかという身の丈を踏まえた見方を通じ、批判的に参照することが大切です(様々なリソース(人・費用・時間)に余裕のある大企業視点で見るのか、成果第一の形から取組むか等を見極める点も含める)。こういった利用視点を「テーラリング」と呼んでパッケージの「カスタマイズ」と区別することがあります。

参照するDMMFの種類によって成熟度レベルの段階(図2)、判断基準、ドメイン/コンポーネントの内容は大きく異なります。従って、全ての要素を統合して考えるよりは、一つを軸に、不足する内容について他を参照して補うという考え方が適していると考えられます。CMMI/DMMは全体項目数が多く判定に厳格性があり、運用操作性主体で腰を据えた取組みが必要です。EDMC/DCAMはDMMよりも項目は少なく機能性重視視点を持ちます。DMBoK2はDMMFというよりは技術的構成要素を主体にした解説と対応策アクティビティ検討の材料という意味合いが強く、DMMFとして使うには評価項目の具体化等ブレークダウンが必要です。例えばDMBoK2で取上げている第10章「リファレンスおよびマスタデータ」項目はCMMI/DMMでは具体的プロセス領域として明示されていません。

要点「項目3」については、DM成熟度評価の計画・実行・結果の評価/共有という各段階で必要な内容です。計画段階では、実施目的・意義の周知、実施者教育およびインタビュー対象となる部署の理解獲得、経営者関与の明確化が主体です。実行段階ではインタビュー円滑化、スムースな査定文書類取得と分析・状況の共有が含まれます。結果共有の段階では、業務関係者の課題認識確認、今後の時間軸イメージの共有、経営者/スポンサーの納得性の獲得といったことが対象です。特に成熟度評価結果から、今後の改善/改革に向けたロードマップ作りと目標・期待効果設定が、関係者の理解を得た上で相当程度具体化することで、予算化/プロジェクト化という次段階への道筋作りに繋がります。この進展への第1段階は、パイロット的な小規模範囲のプロジェクト的試みから始めることになるかも知れません。

また、成熟度評価手続きをどのようなメンバで行うかといった考慮点もあります。評価を方法論に慣れた専門家に委ねる考え方もありますが、結果の理解を深めた上で次のステップに進めるという意味では社内担当者が主体で実施する方が望ましいといえます。また、評価報告書に対する信頼性を経営者がどのような価値観で見るかも必要な考慮事項です。外部の戦略コンサル会社の意見を重視する形なら、やはり外部専門家活用を重視、一方、社内有識者の進言を大切にする経営者向けでは、社内関係者を積極的に活用するという考え方になるでしょう(但し、成熟度評価の意味合い・方法を理解した上で実施)。第三者視点で実施するといっても、会計監査のように法規制で決められている評価姿勢と異なり、DM成熟度評価は厳密性・正確性・規則準拠性等よりも、ある程度の曖昧さが残っていても関係者の納得性を得ることを重視して進めるべきものと筆者は考えます。

最後に、先に書いたようにDMMFは、具体的な対策の考え方の参考書として見ることもできます。特にDMBoK2の知識領域のプロセス説明は、そのような視点で書かれていると理解すると分かり易いでしょう(但し、書かれていること全てが、自社にとっての絶対的な正解とは限らない点に注意)。いずれにしてもDMに関わる各領域/ドメインを参考にして個別的に理解するだけでなく、領域同士の関係を意識して読み取ることが大切です。この例として、分科会説明で取上げた、Abu Dhabi政府データマネジメント標準(V1.0)を元にした見方を紹介します)。

図3は上記DM標準に記述されるDM領域要素の関係を、資料内容を参照して筆者が図解したものです。この標準はDMBoK1をベースにして作成したものですが、内容から見てDMBoK2を基準にして構成要素は大きく変わっていません。DMBoK2にない要素として、「データカタログ」、「オープンデータ」の2要素がありますが、前者は「メタデータ」および「データガバナンス」と関連付け、後者は「文書とコンテンツ管理」と連携することで分かり易くなりそうです。このようにDM構成要素の関連を図解することで、構築しようとするDM環境がどのように位置付いているかを理解する助けとなります。例えば、ここで特徴的なのは、「メタデータ/データカタログ」が要素フローの先頭にある点、「データ統合と相互運用性」がフローの最後尾にある点です。これによりメタデータの構築を軸とし、他システム/データ要素との連携は次の段階として捉えられていると推測できます(この要素関係は、筆者が整理したDM歩き方マップから見てDMBoK2の記述内容と大きく違っている点です)。目標とするDM環境をこういった要素関係の整理視点で描くことは、DM成熟度評価を計画/評価する上で役に立つものと筆者は捉えています。

尚、説明題目にある「データモデル評価」についてはDMBoK2 第5章 5.2で説明されているHobermanの説明を補足したものであり、誌面の都合上ここでは割愛します。

(以上)

※1 筆者のWebページ(インフオラボ游悠で検索)。Topページにある「游悠レポートページ」ボタンをクリックして移動。「游悠レポート2021-006」を参照。尚、当該資料でDMBoK2の内容を取上げた部分では、日本語版発行前に筆者作成したページについて「データマネジメント知識体系ガイド(第二版)」と用語表現が異なっている点に注意。

※2 図は何れも、8/25(水)第10分科会説明で用いた資料から抜粋。※1の資料を確認。

※3 この資料はDMBoK1を参考に作成し2016年に公開されたもので、Abu Dhabi政府に関連する50以上の団体/企業エンティティのDM環境構築の標準統制事項を規定している。この標準に従ったプロジェクトがこれまで進行・実現されていると同政府関連Webページでは紹介している。

[投稿者]中岡 実(インフオラボ游悠 代表/データマネジメントコンサルタント、ITコーディネータ、PMP、認定心理士)

DMBoK2の歩き方とデータガバナンスの位置付けを考える

筆者もDama-Jで設けられている各種分科会に参加している中で、最近新しく分科会参加してくる方々(主にベンダーやコンサルタント系)から出てくる参加理由として「仕事で出会うユーザ企業の人々が「データマネジメント知識体系ガイド(第2版)」(DMBoK2)を見ていて、自分たちもしっかり勉強しておく必要性を感じたため」という意見を聞くことが多くなっています。データをビジネス資産として扱おうという企業活動からすると、これは当然の流れであり筆者も喜ばしい傾向と捉えています。しかしDMBoK2そのものは知識領域を網羅的に解説した内容であり、初学者が手軽にその内容を理解するのに抵抗を感じるという読者意見も少なくありませんでした。

そこで今回の記事では、分科会活動へ参加する中で筆者が整理した、DMBoK2で説明しているデータマネジメントの全体像をビジュアルな形で理解を進めるための地図「データマネジメント歩き方マップ」について簡単に紹介し、一つの知識領域である「データガバナンス」の位置付けに目を通したいと考えます。(この「DM歩き方マップ」についてはEDW2020のビデオパック講演として筆者が紹介したものです(※1)。日本語版/英語版あり)

データマネジメントを具体的なものとして捉えるためには、それを構成する知識領域(機能構成)を個別に学習するだけでは不十分であり、それら知識領域の全体像(関連性)を理解する必要があるということが筆者の考え方です。この全体像を捉え、しかも個々の要素も見落とさずに眺めることができるようにしたいというのが筆者の目標であり、それを具体的に表現する形として作成したのが、この「DM歩き方マップ」でした(図1)。

図 1 DMBoK2 データマネジメント歩き方マップ 1.8版と知識領域対応図 (※2)

今やスマートフォン/PCの日常的利用の中で、地図を活用できることの便利さを否定する人は余りいないと思われます。それと同様にデータマネジメント(DM)という難題に取り組み、理解を共通化するためには、視覚的見方を可能とするDM地図が必要です。これを利用することでDMBoK2の知識領域(機能分野)の関連性理解を深めることができます。

(ここでは紙面の都合上、細かい議論には入りません)

図1は、機能分野の外部的関連性を表していますが、それに加えて各分野の直接の参照関係を表現したものが、参照関係図です(図2)。ここでは12の知識領域に加えて、他の5つの章を加えた合計17の章立ての内部関係性を表しています。参照関係は方向性(矢印の向き及び色使い)と関係の強さ(矢印線の太さ)で示しています。この図(DM歩き方マップ2)を参照することで、DMBoK2を読み解く上での章間の流れを離散的に推し量ることができます。

図 2 DMBoK2 各章の記事参照関係図(DM歩き方マップ2) (※2)

これらのマップ利用の例として、DMを考える読者の多くに感心の高いと考えられる、第3章「データガバナンス」を取り上げてみます。図1からデータガバナンス領域は各知識領域へ繋がる起点の話題であることが分かります。それと同時にDM活動を考える上での1.ビジネス戦略、2.EA(エンタープライズ・アーキテクチャ)戦略、3.データ戦略といったビジネス活動に直結する戦略領域の話題はDM活動に対する入力となっていることを確認できます。つまり企業活動の上で、DMを推進することは目的ではなく手段であると改めて視覚的に説明できます。ビジネス目標を達成する、データ資産化を実現するために何をしたら良いかと考えてゆくことが、DM活動の方向性であるといえます。それであるからこそ、スポンサー、経営者も本気で取り組むべき話題であると捉えることができます。

(少し話が逸れますが、2年位前のIT領域に関わる記事で大手企業(複数)役員が「CIOは貧乏くじ」という発言をしたのを取り上げていました。そういう企業ではいつまで経っても、システムトラブルが絶えることはなく、システム関係者こそ被害者意識を持ちながら鬱々とした日々の仕事生活を送っているだろうと想像したことを思い出しました。)

マップ2から見ると、データガバナンス領域(第3章/DG)の延長として第15章、16章、17章が構成されていることが確認できます。DGを多く参照しているのは、参照データとマスタデータ(第10章)、データ品質(第13章)で、他の章からの参照も幾つか存在します。第3章はデータ品質を高め・維持に関する組織立て、基本的プロセスの考え方を説明しています。これを踏まえて各機能領域での具体的なDG活動は、それぞれの領域内に含まれるという構成で読み進めることがDMBoK2データガバナンス理解の道筋となります。

DMBoK2でのDM知識領域解説は網羅的な形であり、一部を除いて余り役割階層的、また時間軸的な説明を区別したものとはなっていないと見ることができます。それが、DMBoK2を頭から順番に読了しようとして読者が躓く一つの要因であると、筆者には考えられます。DM歩き方マップで見る景色は、実際には時間軸(ロードマップ要素)、整合性を踏まえた関係者の役割軸を意識する必要があります。データガバナンス要素を含めて、DM活動は組織としての継続的で総合的な有機的活動とすることが必要です(図3)。個人の努力に依存する形では、決してDM活動の理想に到達できないものと筆者は捉えています。人材の流動化が益々想定される社会では、確固として継続的なデータマネジメント活動の意味が大きなものとなることでしょう。

図 3 DMBoK2 を基本にしたデータマネジメント知識領域全体像 (※2)

組織的活動としてのデータマネジメントを成功させるために、DMBoK2で議論されているエッセンスが広く多くの立場の方々に理解され、納得性のある当たり前の活動として実践されることを期待しています。

尚、本記事で紹介したDM歩き方マップ等に関心のある方は、筆者に照会頂ければ資料ご案内します。問合せ下さい。

(メール: minoru.nakaoka(a)infolabyouyou.com メール発信時は、(a)部分をアットマークに変更下さい)

※1 EDW(Enterprise Data World)カンファレス2020は、当初3月にカリフォルニア、サンディエゴ市で開催予定されていたが、コロナ窩話題により集合形式実施は中止された。その際、主催者からの照会によりビデオ録画形式での実施参加問合せを受け、筆者はビデオパック向けの講演参加を行った(60セッション強のセッション参加あり)。

演題 “Walking Map of DMBOK2 : A Bird’s-Eye View to the Data Management World”

※2 図は何れも筆者のEDW2020 ビデオ講演で利用したものを抜粋している。(日本語表現に訂正して掲載)

[投稿者]中岡 実(インフオラボ游悠 代表/データマネジメントコンサルタント、ITコーディネータ、PMP、認定心理士)