「デジタル化」で改革ができるか?

9月1日にデジタル庁が発足され、平井卓也デジタル相の会見はじめ、華々しくメディアでも取り上げられています。
報道のされ方含めて、誰もが「徹底的にデジタル化を進める」と繰り返していますが、この認識に私は大いに違和感を覚えます。

アナログ(紙)のデジタル化(電子化)についていえば、職員のExcelだろうが、多額な国家予算が投じられ、ほぼ使われていないような行政手続きシステムだろうが、既にデジタル化(電子化)されている状態になっているのです。
問題は今やデジタル化することではなく、各行政手続きごとに縦割りの状態で構築され、メインフレーム時代の古いアーキテクチャーを見直すことなく長年場当たり的な増改築が繰り返されてきたシステムの中で”データがサイロ化”し、意味や粒度、整合性が合わない状態で分断されていることが最大の問題なのです。
適切に管理されないままに増大化の一途を遂げるデータは、複数の「系」のシステムをまたがってつなぐことができないため、手続きのたびに本人確認や同じ情報の入力を強いられ、デジタル化(電子化)すればするほど、人手のかかる照合・確認対象のデータや利活用することができないデータがさらに無尽蔵に増えていくことを強く危惧しています。

デジタル化(電子化)という手段が今後も引き続き目的化し、新たな「器(システム)」の開発・導入が進んで濫立化することにより、その結果、使えないデータがさらに増えてしまう。
この悪循環を断ち切るためには、「器(システム)」ではなく、その「中身(データ)」と向き合い、これをいかに最短距離で整備すれば利活用できるようになるかを実地にアセスメントし、それを改善していくための地道な活動計画を策定・実行していくことに他なりません。
どうしても目に見えやすい「器」をどう作るかに衆目が集まりがちになりますが、その「中身」と真摯に向き合わないと、政府が標榜する「Once,Only原則(国民・事業者が役所に一度提出した情報を他の役所が二度と求めてはならない)」などは夢のまた夢になります。

データマネジメントの普及・啓発団体であるDAMA日本支部にとっても、私が事務局長を務める(一社)日本データマネジメント・コンソーシアム[JDMC]としても、こうした問題意識をもっと世に問い、情報発信していくことが重い責務なのではないかと、デジタル庁の一連の報道を見ていて再認識した次第です。

DAMA日本支部 企画担当理事
日本データマネジメント・コンソーシアム[JDMC] 発起人 兼 事務局長
大 西 浩 史

データマネジメント成熟度評価を考える(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コーディネータ、認定心理士)

データプロファイリング

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

DMBOK2での記述

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

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

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

 「第5章 データモデリングとデザイン」では、ツールの節で「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日本支部 会員メンバ宛)

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

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

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

IT組織の中でのデータマネジメントの位置付けについて

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

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

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

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

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

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

IPAが提供する「i コンピテンシ ディクショナリ」(以降、iCD)は、企業において、

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

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

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

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

2014年7月31日にいiCDの試用版を公開し、パブリックコメントや産業界における実証実験などを踏まえ、2015年6月に正式版を公開されています。

以下、参照下さい。

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

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

出典: iCD  タスクディクショナリ タスク構成図 から引用。

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

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

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

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

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

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

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

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

以上

サブジェクトエリアを考える

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

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

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

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

まず,サブジェクトエリアの分割基準についてだが,理論的裏付けは難しいものの,ベスト・プラクティス,あるいはリファレンスとなるべきモデルはありそうである。残念ながら日本語訳は出ていないが,アメリカのデータモデラーであれば,まず絶対に読んでいる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以下といった経験を共有できた。数はけっこうバラつきが多いが,これはどこまでサブタイプを設定するかにもよるかと思う。あまりにも多い場合はさらに細分化した単位にサブジェクトエリアを分割するほうが良いだろう。

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

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

データドリブン経営とデータマネジメントの関係性

はじめに

今回はデータマネジメントとデータドリブン経営の関係性を考察してみたいと思います。

皆さんはデータマネジメントとデータドリブン経営にはどのような関係性があると考えますでしょうか。何となく関係がありそうではあるが、どう説明してよいか迷うなぁ。という感想を多くの方が抱くのではないかと想像しています。

今回ブログ執筆の機会をいただきましたので、皆さんと一緒に考えるひとつのきっかけになればと思い、どのような関係性があるかを私なりに考えてみました。

データマネジメントフレームワークとしてのDAMAホイール図

考えるに際し、まず最初にデータマネジメントに求められる知識領域を定めたDAMAホイール図をご紹介します。

(図1)

この図1はDMBOK2の第1章に記載されているデータマネジメントの知識領域を定義する「DAMAホイール図」と呼ばれる図です。


DMBOK2は17章構成で記述されており、各種のフレームワークを定義していますが、データマネジメント知識領域をもっとも良く表している図がこのDAMAホイール図です。

DAMAホイール図は中心にデータガバナンスが置かれ、各知識領域は成熟したデータマネジメントに必要な機能を示しています。

このホイール(Wheel)という言葉ですが日本語に訳すと「車輪」にあたりますが、 タイヤに例えると次のようなイメージ(図2)になるのではと思います。

(図2)

 

データドリブン経営とデータマネジメントの関係

次にデータドリブン経営という言葉をみていきたいと思います。

データドリブン経営とはシンプルに言えば従来型のKKD(勘と経験と度胸)に頼った意思決定から、データに基づいた経営的な意思決定にシフトすることと、定義できるのではと考えます。

また、データドリブン(DataDriven)を日本語に訳すと「データ駆動」にあたりますが、データを動力源(燃料)として、いかに迅速に経営的な意思決定を行うことができるかが 多くの企業の関心ごとにもなっています。

このデータドリブン経営をビジネスゴールに向かって進む車の運転に例えた場合、 その安全・安心・快適なドライブを下支えする車輪の位置づけとして、DAMAホイール (=データマネジメントの知識定義)が存在するのではと考えます。(図3)

普段、車の運転をしている際は目にすることがないため、ホイールの存在を意識することは稀ですが、非常に重要な役割を担っていることは車を例にすると想像いただけるのではないかと思います。

(図3)安全・安心・快適なドライブを下支えする車輪


現在、コロナ禍で私たちを取り巻く環境は急激かつ大きく変化してきています。このビジネス変化のスピードに追随してドライブしていくためにも、足元を支える車輪としてのDAMAホイールの内容を理解することはきっと皆さんのお役に立つものと考えます。

皆さんの所属する企業、または提案先、支援先の顧客は期待するスピードでデータドリブン経営を実現できておりますでしょうか。また、その足元を支えるデータマネジメントに関する取り組みはどのような状況でしょうか。

経営から思ったようなスピードが出ていない。間違った意思決定をしていないか不安だという言葉が聞こえたら、一度、DAMAホイール図を参考に自社の取り組みを点検いただくのも一案かもしれません。

ひょっとしたら、(図4)のようにデータマネジメントに関する考慮が欠けていて、多角形の車輪で走っていることに起因し、データドリブン経営が思うようなスピードで進んでいないのかもしれません。

(図4)



おわりに

データマネジメント知識領域を抑え、自社のデータドリブン経営のスピードを阻害している要因(車輪の不備部分)を見つけ、地道に1つずつ改善を積み上げていける企業こそが、真にデータドリブン経営を実践する企業に進化できるのではないかと私は考えます。

DMBOK2の11の知識領域にどういった内容があるのか俯瞰して学びたい皆さん、ぜひ、DAMA-Jの活動を体験してみてください。

一緒に意見交換できることを楽しみにしております。

デジタル・トランスフォーメーション(DX)とデータ・マネジメント(DM)③

今回は、Transformationのお話です。
またまた英語の語源からですが、Transformationは、Trans+Formの合成語です。
https://www.etymonline.com/word/transform#etymonline_v_16881 には、以下のように書かれています。
mid-14c., “change the form of” (transitive), from Old French transformer (14c.), from Latin transformare “change in shape, metamorphose,” from trans “across, beyond” (see trans-) + formare “to form” (see form (v.)). Intransitive sense “undergo a change of form” is from 1590s. Related: Transformedtransforming.
要は、Formを変えること、Formとは形や様式ということです。

ちなみに、語源という意味では、Dataの成り立ちは以下です。

つまりラテン語で与えるもの、もしくは与えられるものであり、事実や既成のものという意味ですね。ちなみに、Dataの単数形がDatumですから、DataはPeopleのように複数形として扱うのが正式とのことです(英語圏でも随分議論がありますが)

はい、失礼しました。Transformation話でしたが、DMBOKでこのことにかなり迫っているのが、第17章のChange Management(変革管理)です。2018年のADMCでも取り上げましたが、この章では以下がポイントだと思っています。

一番陥りやすいミスは以下のようなものでしょうか。
まず、変革は「人」から始まるということに真っ向から挑戦しるのが以下の発言です。
◆ DXには予算をいくら取ればいいのか計算しろ
◆ DXをやるにはまず組織を作らなければ
◆ DXをやってくれるITベンダーを連れてこい
◆ DXができるソフトウェアを調達しろ、予算は取ったから
◆ 日本をデジタル化するぞ、そう「デジタル庁をつくればいいのだ」(笑

次に斜めに構えている人が言う言葉として・・・
◆ DXなんてどうせまたITベンダーが作ったBuzz Wordだから、やっている振りだけしておこう
◆ うちの会社は昔からDXはやっているよ。PC入れたのも早かったしね
◆ うちの会社は伝統を大切にする、DXはうちには合わないよ
◆ 書類を全部ScanしてDX・・・という古いジョークは忘れましょ(汗

余談ですが、世の中には変わらなくてもいいことが不自然に変わることがあります。例えば、
◆コンビニでビニール袋をくれなくなった(特に日本ではこれが地球温暖化を防ぐのにほぼ何の役にも立たない。つまる単なる値上げ)
◆ そもそも日本の水道水は一番安全なのに、なぜかミネラルウォーターを買うようになった
◆ (ここは賛否両論ありますが)喫煙人口が激減したのに肺がんは減らない?? ただ・・・人に迷惑をかけてはいけないので非喫煙者の前では吸わないように(汗
◆ ゴミの分別が余計にコストがかかるって知ってました?

ちなみに上に上げた変革を起こすのには莫大なマーケティング戦略、洗脳、プロパガンダが必要でしたけど。 こんな変化を起こせるなら、Digital Transformationも簡単ですねー。

一方で、Backward Compatibilityという言葉があります。ITの方はよく知っていると思いますが、ソフトウェアのバージョンが上がっても、昔書いたソフトは依然としてそのまま走るということ。特にMicrosoftはこのコンセプトを重視してきました。Windowsのバージョンが上がっても昔のソフトはそのまま走る。

皆さんお気づきのように、いくら何でも20年前のソフトは走らないよねー。ただ世の中のTransformationはもっと遅く、Backward Compatibilityに従っているようです。JR(昔の国鉄・・・知ってました?)でSuicaがメジャーになった今も切符をまだ買えますよね。コンビニでスマホ決済ではなくて現金でモノが買えますよね。

私に真面目にTransformationとは何かを言わせると、それは「脱皮」だと思います。昆虫などは一生の内にでも脱皮しますが、 生物は何世代にもわたって進化します。多くの場合は、Backward Compatibilityは保たれないようです。つまり、いったん蝶になった幼虫のようには生きられないし、人間はもう水の中では呼吸できないですよね。

DMBOKの第17章でも、人々に変革についてきてほしいのなら、戻り道をふさぐことだと書いてあります。つまりBackward Compatibilityへの道を断つということですね。

でも駅で切符が買えなくたったらどうしたらいいかわからないなー。

ESGとデータマネジメント

昨今、ESG(環境(Environment)、社会(Social)、ガバナンス(Governance))への取り組みを強化する企業が増えてきています。

今まで、ESGとデータマネジメントはあまりつなげて捉えていなかったのですが、先日、ESGへの取り組みはデータ活用とも言える、という話を耳にする機会があり、認識を新たにしました。ということで、今回はESGとデータマネジメントについて書いてみたいと思います。

まず、ESGへの取り組みが強化されている背景ですが、機関投資家にESG投資という考え方が浸透してきたことがあります。これは、財務情報だけでなく、ESGへの取り組みも考慮した投資の方法で、企業の財務利益とESG活動を相反するものとして捉えていないことが特徴です。ESGに取り組んでいる企業の方が、中長期的な業績が良くなる&リスクが低いという考え方をとっています。

では、こうしたESG投資の際に、投資家はどのようなデータを活用しているのか。ここでは、投資家へのデータ公開の媒体の一つである統合報告書を見てみたいと思います。

統合報告書は、企業が、財務資本だけでなく、知的資本、人間資本、社会関係資本、自然資本といった非財務の資本も含めて、どのように長期的に価値を創造していくかを説明するもので、非財務の指標の例としては、下記のようなものがあります。

CO2排出量
社外取締役比率
女性取締役比率
離職率
、、、

上記はごくごく一部ですが、すぐにデータとしてとれそうなものと、そうでないものがあるのではないでしょうか。さらに、すぐにデータがとれそうな部門とそうでない部門があるかもしれません。

CO2排出量について考えると、物流、工場の生産、拠点の電力消費、グリーン調達など、企業全体で出そうとすると、多くの部門に関連する指標になります。

実態を表す、一貫性のある品質の高いデータを元にすることで、投資家もさることながら、自社の長期的な価値創造のためによりよい意思決定ができるようになるはずです。

部門横断でデータを収集・統合し、品質の高いデータをアウトプットする、、、データマネジメントの知識、技術が多いに役立つのではないかと思います。

最後に、従来、環境に関する活動は、利益とは反するが、企業の責任として実施すべき、という考えが一般的だったと思います。今更ですが、大分様相が変わってきており、良い方に動いているなと感じています。一過性のブームではなく、定着した考え方になっていくことを期待しています。