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コーディネータ、認定心理士)

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

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の分科会でメタデータ管理がテーマの時に「メタデータ管理のアーキテクチャには、集中型、分散型、ハイブリッド型、双方向がある」と説明を受け、私は「どこかで聞いたことがあるな?」と思いました。
調べてみると同じような概念がDMBOKの各所にありました。
どこにその記述があるか? 全て解説を加えたいところですが、相当量になってしまいますので、今回は解説なしで項目だけ紹介してみます。

第3章 データガバナンス
データガバナンスのオペレーティングモデルタイプには以下の3種類があると説明されています。

  • 中央型 (集中型?)
  • 複製型 (分散型?)
  • 連邦型 (ハイブリッド型?)


第6章 データストレージとオペレーション
データベースアーキテクチャの種類には以下の3種類があると説明されています。

  • 集中型データベース
  • 分散型データベース
  • 連邦型データベース


第10章 参照データとマスターデータ
参照データとマスターデータの統合の基本的なアーキテクチャアプローチとして、以下の3種類があると説明されています。「集中」「分散」「ハイブリッド」とは異なるように聞こえますが、発想は類似しています。

  • レジストリ      (発想は分散型です)
  • トランザクションハブ (集中型です)
  • 統合アプローチ    (上記2つのハイブリッドと説明されています)


第12章 メタデータ管理
メタデータアーキテクチャの種類として、以下の4種類があると説明されています。

  • 集中型メタデータアーキテクチャ
  • 分散型メタデータアーキテクチャ
  • ハイブリッド型メタデータアーキテクチャ
  • 双方向メタデータアーキテクチャ


第16章 データマネジメント組織と役割期待
データマネジメントのオペレーティングモデルとして以下の5種類が説明されています。ネットワーク型と連邦型も広い意味でハイブリッド型と言って良いと思います。

  • 地方分権型オペレーティングモデル (分散型)
  • ネットワーク型オペレーティングモデル
  • 中央集権型オペレーティングモデル (集中型)
  • ハイブリッド型オペレーティングモデル
  • 連邦型オペレーティングモデル

本日は説明しませんが、どの集中型、分散型にも概ね同じようなメリットとデメリットがあり、その折衷案がハイブリッド型というのも概ね同じようです。

「だからどうした?」という話かもしれませんが、皆さんが今後DMBOK2 を読む際にちょっと頭の片隅に置いていただいても良いかと思います。

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

はじめに

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

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

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

データマネジメントフレームワークとしての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排出量について考えると、物流、工場の生産、拠点の電力消費、グリーン調達など、企業全体で出そうとすると、多くの部門に関連する指標になります。

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

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

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

データ品質分科会を続けてきて…

 品質分科会は2013年から開催されていて、DAMA-Jでは最も古い分科会です。よくもまぁ飽きもせず7年もやってきたものだと我ながら感心しています。

 ただ、参加されている方は一部の方ですし、新規入会の方も多くなってきましたので、期変わりのこの時期に改めてこれまでの経緯を含めて、ご紹介をしたいと思います。

 品質分科会は、もともとは第4分科会「意思決定に寄与するデータモデル研究会」の派生分科会として発足しました。                   第4分科会は、経営層が意思決定をするに当たってデータを活用するために必要なデータモデルとは何か?ということを議論・研究する分科会でしたが、そもそも経営層がデータを活用して意思決定をすることが少ない、データ活用するためのデータモデル整備に投資をすることに理解を示さないなどの点が問題で、どのように理解してもらうかというような議論をしていました。

 それはそれで重要な議論ですが、そこに一足飛びに進むことは日本の現状では難しいだろうとの思いもあり、それならまずは経営層にデータ品質問題の認知をしてもらい、品質改善マネジメントからデータマネジメントの機運を作っていけないかということで、データ品質分科会を発足させていただきました。

 品質分科会で、まず最初に取り組んだのは、DMBOKのデータ品質の章を読み込んで、具体的な内容と対比して理解することでした。 DMBOK1のたかだか60ページの読み込みでしたが、抽象的な表現が多いDMBOKの記述は難解で、参加者に一定の理解が得られるのに実に丸3年かかってしまいました。その頃は成果物を産まない地味な分科会ということで不人気分科会でして、2-3名の参加での開催も少なくありませんでした。

 しかし、それでも続けたおかげで記載内容の意味が整理され、各アクティビティで実施すべきことがはっきり見えてきたのだと思いますし、その後のDQワークシートのまとめにも大いに役に立ちました。

 DQワークシートについては、2020-08-03の井桁さんの記事に概要が記載されていますのでここでは割愛しますが、DMBOK2の内容反映まで含めてやはり4年かかってしまったもののデータ品質マネジメントを行う上では初めての具体的資料ができたのではないかと思っています。今後は、このワークシートの使い方を平易にまとめた資料が作れれば良いなと考えています。

 と、これまでの分科会活動を振り返って思うところは、DMBOKはさらっと読めば答えが得られるというものではなくて、活用するには十分な理解や解釈が必要だ、ということです。

 DMBOKで使われる用語やレトリックに含まれる意味は多岐に渡り、具体的な事例でどうしたら良いかと考えた時に有識者でさえ「ケース・バイ・ケース」という回答になることも多いようです。 しかし、それでガッカリしてはいけません。DMBOKで語られていることの本質的でシンプルな意味を解釈し理解できていれば、具体的な課題にぶち当たった時に、その理解を軸にどうすれば良いかの応用が効くと思います。

 このスピードが求められる時代、すぐに役に立つ何かを求められがちですが、しっかりとした知識体系をわが物とするためには「急がば回れ」でDMBOKをしっかり読まれること、読んだ解釈を多くの方と議論して理解することが重要なことだと思います。 DAMAの分科会は、今後もそういったことができる数少ない場でありたいと考えています。