データマネジメントなき「デジタル庁」は”いつか来た道”

「デジタル庁」は救世主になるか?

長期に渡った安倍政権から菅首相にバトンが渡され、その政権の目玉政策として「デジタル庁」が注目を集めています。
デジタル、つまりはデータの存在が日本のビジネスパーソンだけでなく、一般の生活者や子どもたちにも広く耳目に触れるようになること自体は非常に良い傾向ではないかと感じますが、本当にお題目として謳われている行政サービスや国民の利便性の向上、既存規制の改革などに効果を発揮することができるのか?
その際に注意しなければならない点があることを私は指摘しておきたいと思います。

かつても「e-Japan構想」などのITによる行政改革の試みは多額の予算が投じられ、「政府エンタープライズ・アーキテクチャー(EA)」といった取り組みが何度も行われてきました。
ただ、それらがどのようなメリットをもたらしたというのか。
国民や民間事業者、行政職員の皆さんですら、そのメリットを実感できていないのではないでしょうか。

それはなぜかというと答えは簡単で、「電子化することが目的化した」という一点に尽きます。
既存の法令、制度、ルール、組織などを是として、そのままプロセスを電子化するだけでは帳票単位にシステムが濫立するだけです。
その帳票ごとにバラバラなデータが生み出され、活用できないばかりか、たとえば、住所変更の手続きを役所ごとに利用者に強いることになります。

デジタル庁においても「デジタル化すること」が目的になってしまえば、これまで何度も踏んでいた轍を踏み、無駄なプロセスを温存してデジタル化、要は電子化することに再度血道を上げることになるでしょう。
一時期ブームになった”オープンデータ”の政府の動きも「オープンデータ化すること」が目的化し、誰からも使われないオープンデータの数だけが競われ、価値あるデータの提供につながらない残念な結果に終わるでしょう。

データマネジメントを大前提とした「デジタル庁」に

では、真に行政サービスの向上や規制の改革などに資する「デジタル庁」にするためにはどうするか?
今度こそ、「データを中核に捉え、行政サービスのお客様である国民や民間事業者を主役としたデータマネジメントを、府省横断的に徹底すること」ではないかと思います。

これまで複雑に築き上げてしまった既存の巨大システムに存在するデータと向き合うには相当の困難を伴うことは間違いありませんが、ここにメスを入れない限り”いつか来た道”を通ることになることは必定です。
「デジタル庁の役割は行政データマネジメント」といった覚悟で取り組んでほしいと願います。

DAMA日本支部 企画担当理事
JDMC事務局長 兼 理事
株式会社リアライズ 代表取締役社長
大西 浩史

データ活用の成功を導く「データリーダーシップ」

今年の3月に、データマネジメントの国際カンファレンスEnterprise Data World(EDW)が実施された(https://edw2020.dataversity.net/)。今年のセッション毎のテーマを眺めてみると、「データリーダーシップ」をテーマとするセッションが多い。海外でもDXはキーワードとなっているが、それよりも上位である(下表、「EDWセッションの分類」を参照)。

データリーダーシップは組織の機能

そもそもデータリーダーシップとはなにか。
CDO(Chief Data Officer)のような社内のデータ責任者を思い浮かべる方もいるだろうが、そうした特定の人物は指していない。
データマネジメントとデータガバナンスのあるべき姿(ビジョン)や目的を明確にし、そこに至るステップを戦略として策定すること。
または、そうして策定されたビジョン・目的と戦略を見直すことが、データリーダーシップである。

DMBOK第2版でも、データマネジメントのリーダーシップについて述べている箇所がいくつかある。
第1章「データマネジメント」では、データマネジメントの原則として
「効果的なデータマネジメントにはリーダー(※原文では”leadership”)のコミットが必要(Effective data management requires leadership commitment)」
「管理スキルだけでなく、ビジョンや目的が必要」
と述べている (DMBOK 第2版日本語版 P46) 。
また、第17章「データマネジメントと組織の変革」では、米国の専門家ジョン・コッターのリーダーシップ論を紹介しながら、リーダーシップとは変革を実現するための能力で、合理的で魅力的な将来像であるビジョンを描き、どうしたらビジョンを達成できるかという筋道である戦略を作成することだと紹介している (DMBOK 第2版日本語版 P636 図117) 。

データの価値を収益・コスト・リスクで評価する

ビジョンと戦略を作成するだけなら既存の「データ戦略」(またはデータマネジメント戦略/データガバナンス戦略)となにが違うのか。

データリーダーシップの提唱者の一人、Anthony J. Algmin氏によれば、データの価値とはつまるところ収益の増加・コストの減少・リスクの管理の3つのどれかだと言う。

データの価値とは、「データを使い何をするのか」と「そのデータ無しで何ができるか」の差分によって具体化される。
収益の増加、コストの減少、リスクの管理によって価値は測定される
これら3つは、実際にデータの価値を生む「唯一の」方法である。

“Data Leadership: Stop Talking About Data and Start Making an Impact!” https://algmin.com/book/

データ戦略の目的は企業によって様々だが、究極的にはデータの価値によってビジネスに貢献することを目指す。
つまりAlgmin氏の上記意見に拠れば、データ戦略の目的とは収益の増加・コストの減少・リスク管理というビジネス視点で具体化・定量化されたものになる。
また彼は、こうして目的が定量化・具体化されれば、目的に対して現在どこまで達成できたのか測定し、問題点があれば特定して改善し続けることができるとも言っている。

すなわち「データリーダーシップ」とは、
・データ戦略の目的を、ビジネス視点で具体化・定量化する
・定量化された指標に基づき、戦略自体が定期的に評価され、見直される
のふたつを前提条件としている点が、通常の「データ戦略」との違いとして位置づけられる。

データリーダーシップで変化に対応し、無駄を省く

ではEDWに参加しているような海外の企業や組織は、目的の具体化・定量化とそれに基づく改善活動をどれだけ実施できているのか。
あまりできなくて悩んでいるからこそ、「データリーダーシップ」をテーマにしたセッションが増えているのではないだろうか。

たとえば、ビジネス環境が急速に変化して戦略自体を見直すべき状況になっていても、目的を定量化できていないので測定できず、変化に気づかないまま、もはや無駄かもしれない施策を継続する。また、施策実行の結果得られる収益を、そのために費やしたコストが上回っていても気づけない。そんな企業が多いのではないだろうか。

海外では、2010年代前半からデータ戦略の策定に取り組む企業が増えた。それから10年近く経つが、戦略立案と推進で成功したという事例は、それほど多くはない。
一方、日本は最近になってデータ戦略策定に取り組む企業が増えてきたところだ。
もし貴社もそうした企業なら、今からできるだけ目的の具体化・定量化に取り組んでみてはどうだろう。
目的の定義に時間がかかるかもしれないが、変化に対応し、無駄な作業を省くことで、最終的にはデータ活用成功の近道になるかもしれない。

ワインのデータモデル

DAMA日本支部データモデル分科会では、データモデルについてであれば、DMBOKの枠にとらわれずに様々な話題を取り上げて議論・情報共有をしています。今年度は具体的なモデルについて、それぞれの考え方を議論・共有するという取り組みもしています。

さて、このblogではお題をワインとデータモデルとしてみました。ワインは歴史が長いだけあって、バリエーションが非常に多いです。データモデルのちょっとした題材に使えそうです。このモデルの拡張といったお題も、そのうち分科会で取り上げてみるかもしれません。興味を持たれた方はぜひ分科会への参加をご検討ください。DAMA会員であれば、どなたも参加できます。

ワインの基本要素としては、ブドウの種類、色(赤、白、ロゼ)、発泡性かどうか、場所といったことになるかと思います。

オールドワールド(フランス、イタリア、スペイン等)は地名(地方、村、畑など)がまず書かれて、ブドウの品種は書かれていなかったりしますが、ニューワールド(カルフォルニア、オーストラリア、チリ等)は、ブドウの品種がまず書かれるパターンがかつては主流でした。

イタリアワイン キャンティクラシコ(これは伝統的なキャンティ地域という意味)

また、オールドワールドでは、複数のぶどう品種を組み合わせることも多いのですが、ニューワールドでは単一品種で勝負したワインが主流です。カルフォルニアワインが有名になったきっかけはカベルネ・ソーヴィニヨンですし、今、コスパの良さで人気のチリカベはチリのカベルネ・ソーヴィニヨンの略語です。

こちらはイタリアのワイン一族(サッシカイア)がチリで作っているワイン
ピノ・ノワールというブドウ品種名が記載されています。 これはフランス、ブルゴーニュ原産です。

カベルネ・ソーヴィニヨンはフランスのボルドーが原産ですが、ボルドーではカベルネ・ソーヴィニヨンは単独でワインを作るのではなく、メルローという品種と組み合わせることが圧倒的に多いです。

さて、これらを念頭においてデータモデルにしてみます。

中心となるデータはワインですので、まず、これをエンティティとします。「ワイン」エンティティのインスタンスですが、同じ名前のワインでも作り手、ヴィンテージが違うとものすごく値段が違うので、それごとにインスタンスを作成することにします。主キーは「ワインコード」としてみましたが、これだと粒度がわからないので、「ワイン名」+「ヴィンテージ(ブドウを収穫した年)」*「作り手コード」を代替キーとします。シャンパーニュは原則としてヴィンテージは入らないので、その場合はNV(ノン・ヴィンテージ)と設定することにします。

「ブドウ品種」エンティティの主キーは「ブドウ品種名」とします。インスタンスはカベルネ・ソービニヨン、メルロー、シャルドネ、ソービニヨン・ブランなど。いま、日本で売っているワインの大部分はここであげた4品種から作られたものですね。

ワインによっては複数のワイン品種から作られますので、データモデルでは、「ワイン」エンティティと「ブドウ品種」エンティティはn:nの関連があることになります。n:nを1:nにするために交差エンティティ(関連エンティティという呼び方もあります)をモデルに追加しましょう。ここでは「ワインブドウ品種」というエンティティ名とします。「ワインブドウ品種」エンティティの主キーは、「ワインコード」+「ブドウ品種コード」の複合キーとするのが普通かと思います。

交差エンティティによってn:nを2つの1:nに変換しましたが、この2つにはどのような違いがあるでしょう?

「ワイン」のインスタンスなしで、「ワインブドウ品種」のインスタンスはありえません。

一方、ブドウ品種はワインに向くものと生食に向くものがありますので、「ブドウ品種」のインスタンスをワインに使われるものに限定しない限り。「ワインブドウ品種」に対応しない「ブドウ品種」のインスタンスがあり得ます。こういったことは「ブドウ品種」エンティティに、その定義を書いておくことで明確になります。

そう考えると、2つの1:nの関連には違いが出てきます。

カーディナリティを厳密に書くと、1:1..nと1:0..nとなります。

サンプルに掲げたER図にはそれ以外の要素もあります。「地方」エンティティに再帰リレーションシップがあることや、格付が「地方」と「ワイン」の両方にあるところ、「ワイン分類」の「バランス分類コード」とは何を意味しているのかなど。これを発展させてワインの販売管理のモデルを考えてみるなどは次回のお楽しみにとっておきます。

標準化の進め方について

前回の私のブログ「標準の作成と定着化について」では、会社や組織にデータマネジメント等を推進、定着化させるための一つの手段として、その専門領域の知識体系(BOK)(データマネジメント知識体系ガイド(DAMA―DMBOK)等)を活用した標準化、定着化の考え方、進め方の概要を記載しました。

その際には、多くの会社で、会社・組織の標準として規定されており、データマネジメントと「マネジメント」部分の名前が同じ、プロジェクトマネジメントの標準化を例として、考え方や、進め方を記載しました。

今回は、その具体的な進め方の例を記載します。

進め方として、大きく、以下の3つのステップに分かれます。

<進め方>

  • ステップ1:標準文書作成
  • ステップ2:試行実施(個別案件への適用にて試行)
  • ステップ3:全社本格展開

ここで重要な事は、標準文書を作成しただけで満足せず、 標準文書を作成 した後の、会社、現場でより定着するための取組みが大変重要になります。 標準文書を作成しただけで、みんなが活用してくれない、存在さえ知らない人が多い・・・・と嘆いておられる方もいるのではないでしょうか。 その場合は、標準文書作成時での経営層、現場の方の巻き込み、作成後のアフターフォローが不十分な事が原因と思われます。標準化についても、通常の業務、プロジェクトと同様、上記のステップの全体を網羅した計画をきちんと立て、計画通りに実施し、運用後も引き続き、ウォッチ、支援、活動していくような仕組み作りが大変重要になります。

実際に進めていくには、ステップ毎に詳細なタスクがあり、その詳細タスク毎に進める事になります。

ステップ毎の詳細タスクの例は、以下のようになります。

<ステップ1:標準文書作成>

  1. 標準化チーム立上げ
  2. 現状分析(課題の洗い出し・整理、対策立案)
  3. 標準文書作成、レビュー
  4. 標準文書完成

<ステップ2:試行実施(特定案件への適用にて試行)>

  1. 個別案件への適用計画作成
  2. 試行実施(個別案件への適用実施)
  3. 個別案件適用結果の評価とフィードバック(標準文書ブラッシュアップ)

<フェーズ3:全社本格展開>

  1. 全社への適用計画作成
  2. 本格適用アナウンス
  3. 現場への標準文書説明会実施
  4. 本格適用
  5. 定期的な標準文書の教育計画作成・教育実施
  6. 現場適用支援
  7. 本格適用結果の評価とフィードバック(標準文書ブラッシュアップ)
    ※継続的な改善(プロセス改善・標準文書改善・・・PDCAサイクル)

そもそも標準文書はどのような目次構成なのでしょうか・・・。

DAMA―DMBOKは、以下の目次になりますね。

※引用:データマネジメント知識体系ガイド第二版

簡単ですが、標準文書の目次構成の例を、以下に記載します。

上記はあくまで例ですので、会社、組織に合わせて、必要な目次、構成、順番等、決めていく必要があります。上記の例では、本取組みを行う、背景や目的、今回作成した標準文書の必要性、対象となる適用範囲、本標準を進めていく上での参画者・役割をきちんと定義することで、よりマネジメントの実施と本標準の活用につながります。

次回は、標準化における、計画時や標準文書作成時、適用・運用時のポイント・コツを記載できればと思います。

以上

データモデラーのお噺

 前回の私のブログでは、データマネジメントの入り口の提案として、データモデリングをお薦めしました。その際に、データモデリングするに当たっては、有意義なモデルを作れるデータモデラーを確保できるかという点が課題になると述べました。
 それでは、そのデータモデラーの確保について考えてみましょう。皆さんの会社、或いは組織では、データモデラーは確保されていますでしょうか?

 例えば開発案件において、事前にデータモデリングによる現行仕様の、或いは業務の可視化が行われているかと言うと、残念ながら過去に見た多くの例では、殆ど行われていませんでした。
 データモデリングが行われていないところでは、必要だとは聞いていても、それまで行わないで何とかなっているからというのが大きな理由で実施されていません。実際にできていた場合との直接的な比較がないため、隠れた大きな損失に気付かないのです。
 そして決定的な理由は、実際にできる人が居なかったことにより、実践できないままだったのだろうと思います。取り組もうとはしたが、結果的に断念したという話を聞いたことも、少なくありません。

習得の過程

 なにごともそうですが、技術の習得には次のような過程が必要です。

 教育を受けるだけでは、頑張っても2段階目の「基本的な内容がわかる」までであり、実際に「自分で問題無く使える」ようには、なかなかなれません。

 そのような中で、例えば改善の意欲のある若者が、自分が担当するプロジェクトの中で活用してみようとすると、マネージャから「そんなやり方でうまくいくのか?実績や経験があるのか?これで問題が起きたら責任取れるのか?」などと抵抗されてしまうと心が折れてしまいます。そうではなく、既にできている人からの支援を受けながら、繰り返して実践することが必要です。

 前回ブログ冒頭にて日本のどれ位の企業で、データモデリングが行われているのか、という話題を上げました。しかしながら、この点についての答えを持っていません。周辺のモデラーと呼ばれる人たちに聞いても、多くないのでは?という返事しか得られません。

 色々な企業の方と話をする中で、自社にデータモデラーと呼ばれる人は居ない、或いは、かつては居たけど今は居ない、更には、居るのかわからないという声が多く聞かれます。
 前回、データマネジメントに着手する組織を立ち上げられたら、まずはデータカタログの構築に先駆けてデータモデリングを実施するようにお薦めしました。しかしながら、データモデラーが社内に見つからない中、どうすれば良いのでしょうか?

データモデラーの確保

 自社内にデータモデラーが居ないのであれば、呼んで来るか、作るしかありません。
 ●呼んで来るとしたら、何処からでしょうか?
 ●作るとしたらどうやって?
という疑問が出てきます。

 私の勤務先に依頼すれば出てくるかと言われれば、私の他には3人だけしか居ません。親会社である、あのDX企業でも、今では1人だけしか知りません。
 さて、世の中ではどうかというと、このDAMA日本支部の理事にも数名のデータモデラーが居ますし、データモデリングに関する分科会も開催されています。なので、どこに居るか探して確保するとか、社内で育てるのに支援してくれる人を見つけたいなら、相談していただくのも一つかと思います。ただし、特定の誰かを推薦するという立場にある訳でもなく、紹介した人の能力に責任を持てる立場にもありません。

 DAMAのイベントであるADMCでも、スポンサーの方によるライトニングトークの中で「優秀なデータモデラーを絶賛募集中」と宣伝されている企業もありました。

 データに関して、何処にあるのか、どんなデータが有るのかを知っておくためにはデータマネジメントを行う必要があります。そのデータマネジメントを行う重要なピースであるデータモデリングを実践する人が見つからないというのは皮肉な状況にあると思います。

 できることなら、データモデラーが集う場があり、データモデラーを探す企業の人が、適切なモデラーを見つけられるようになればと思っています。いわゆるギルド的な感じのものができると良いのかも知れません。
 場といっても、特にこんな状況なので、オンラインでの場作りを試してみたいと考えています。
 そんな場を一緒に作ろうというモデラーの方、それ以前にでもデータモデラーを探していますという方、モデラーの育成をしたいという方は是非ご連絡ください。よろしくお願いします。

コロナ時代のデータリテラシー

コロナ問題が浮上してから半年以上が経過していますが、相変わらず「感染者数」中心の報道が続いているようです。流行当初からニュースなどでは感染者数ばかりが重視され、死者数や重症者数があまり報じられていませんでした。もう少しきちんと「データ」に立脚して判断すべきなのではないかと思っていましたが、そもそも感染者数や死者数、重症者数の定義が曖昧のようです。(この点は、6月の総会で林会長からも指摘がありました。)

データがあふれている現在、データの読み書き算盤能力と言われるデータリテラシーが疎かにされているような気がしました。そこで、データリテラシーという言葉がふと頭に浮かびネットを覗いてみました。

するとDataversityのサイトの「The Importance of Data Literacy」(https://www.dataversity.net/the-importance-of-data-literacy/#)という記事が目に留まりました。

その中で、MITメディアラボのRahul Bhargava氏とMITデータフェミニズムラボのCatherine D’ignazio氏によるデータリテラシーの定義として、以下の4つが挙げられています。

  • read(読む)
  • work with(使う)
  • analyze(分析する)
  • argue with(データを使って議論する)

Qlik社のMorrow氏によれば「データリテラシーを身に付けていればフェークニュースなど存在しない」ということだそうです。

何れにしても、データを正しく取得し、自らの頭で考え、行動することが、以前にも増して求められているのだと思います。

同ページの「Data Literacy」のリンク先を開くと、元米国国務長官コリン・パウエル氏の「40-70ルール」というルールが載っており(彼の地では有名らしい)、「必要なデータのうち40%に満たないデータで判断するのは無謀だが、70%以上のデータが得られるまで待っているとチャンスを逃す」という説明がありました。まさに、リーダーの決断の難しさを良く表していると思います。今回のコロナ禍でも、支援金をいつ/どのように出すのか、緊急事態宣言をいつ出すのか/出さないのか、同じく何時終了するのか、またGoToキャンペーンの是非などを巡って、様々な議論があり、政治的決断の難しさが顕わになりました。

必要なデータとは何なのか、これまた難しい問題だと思いますが、全てをまな板の上に載せた議論をしたいものです(これもまた、また、難しいことではあると思いますが)

データリテラシーはフロントからバックまで組織の全ての部署で必要となります。いわゆる「データの民主化」が求められるということです。そのためには、データマネジメントがやはり重要になってきます。コロナ禍の今だからこそ基本に立ち返り、データマネジメントに関わる叡智を養いたいものです。

これまでも人類は様々な感染症に苦しめられてきましたが、今回のコロナ禍は、人・モノ・カネ・情報、全てが高度にグローバル化された社会に生じた、現代人にとって未曾有の出来事であると思います。この禍を転じて福と為すべく、この混乱の中から画期的なイノベーションが生まれることを期待しています。

以上

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・スコープの絞り込み

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

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

「DAMA日本支部 第9分科会=DMBOK勉強会=の紹介」

DAMA日本支部ではいくつかの分科会活動を行っている。そのうち筆者が担当しているのが第9分科会である。今回はこの場をお借りして簡単に第9分科会の紹介をさせていただきたい。既に当分科会に参加いただいている方やDAMA日本支部の総会に参加いただいた方には既知の情報ばかりになってしまうことをご容赦願いたい。

第9分科会はDMBOKの勉強会

DAMA日本支部のホームページでは「DMBOKに関する研究会」とも紹介されているが、簡単に言えば単なる勉強会である。概ね以下の方針で運営している。
・開催頻度・時間: 3か月に2回程度、各回は概ね90分
・開催場所:    都内+リモート接続 但し今年度からはリモート接続のみ
・内容:      毎回DMBOKの1章分を代表者が説明しディスカッション
・説明担当者:   分科会参加者のボランティア
DMBOK2は全17章あるので、全章の勉強を完了するのには2年以上を要する。

第9分科会は広く浅く 説明担当はボランティア

他の分科会が一つのテーマを掘り下げているのに対して、当分科会はその全く反対であり、DMBOK全体を広く浅く理解しようというアプローチである。
説明担当者もその道の専門家を招くわけでもなく、分科会参加メンバーが自分の得意分野もしくは自分の興味のある分野を自ら勉強して担当する。説明担当者は完全なるボランティアであり、自分で説明資料も作成するので、それなりの負担にはなる。説明担当者にはならずに、ディスカッションに加わるだけの参加方法も可能としている。だが、説明担当になることで、その章に関する理解がより深まるというメリットもあり、多くの参加者が説明担当に挑戦している。

既に2周りして3周目!

 1周目 DMBOK 第1版 2015.10~2017.07
 2周目 DMBOK 第2版 2017.12~2020.04

実はこの分科会の歴史は短くない。2015年の10月にDMBOK第1版の勉強会が始まり、2017年5月には第1版全章の勉強会が完了した。その後第2版の英語版が発売され、2017年12月からは第2版の勉強会として再開、本年4月に全17章の勉強会を完了したところである。この途中には第2版の日本語版も発売されている。これでこの分科会の活動は一旦終了したが、その後も継続の要望が強くその継続方法に関しては大きく以下の3つの意見に分かれた
 1) データ管理って何?というレベルの、より入門クラスの分科会にする
 2) 2周目の内容をもう1周する
 3) 各章をより深堀したディスカッションが行える分科会にする
検討を重ねた結果、2周目の途中から参加したメンバーも多く、また復習もしたいという意見もあったため「2) 2周目の内容をもう1周する」に決定した。2020年7月に3周目のキックオフを行い、今月2020年9月から各章の勉強会を再開する。

今がチャンス!?

これからDMBOKを勉強したいという方、今まさに3周目が始まろうとしているので、今がチャンスと言える。リモート接続のみの開催となったので、ある意味参加しやすいのではないかと思われる。これを機にDAMA日本支部の会員になり、第9分科会に参加してみては?

新分科会について

新分科会として「 データ管理って何?というレベルの、より入門クラスの分科会 」と「各章をより深堀したディスカッションが行える分科会」の要望がなくなったわけではない。会員の方で我こそはと思う方は、分科会リーダーとなり、新たな分科会を開始してみるのも良いと思われる。

== おことわり ==
第9分科会の資料だけいただけないか?という問い合わせをいただくことがありますが、説明資料は著作物の引用が多い関係で配布できませんのでご了承ください。

BIのマスターはメンテされない!

マスター登録を業務(例えば受注ー出荷ー請求ー入金)のためのマスターと分析のためのマスターに分けて考えてみる。

前者に必要なマスター(製造業では商品、取引先、出荷先、請求先等)の登録を間違えると、誤った商品を誤った場所に出荷し誤った請求先に誤った請求額で請求することになり、修正の遡りで多大な対応が必要となる。誤りが繰り返されれば取引先の信用を失うことにもつながり、誤ったマスターはすぐに修正されるべくフィードバックがかかる。

後者に必要なマスターは分析の観点から新たに付加される商品や取引先などの分類とその属性や、様々な組織で生成されるデータを統合するためのマッピングマスター等がある。しばしば分析のプロジェクトは熱く燃え上がり(この軸でも管理したい!より細かく管理したい!)苦労してマスターを登録し素晴らしいアウトプットを見てうれしくなるが、それは往々にしてその時の担当者の視点に留まっていて、時が経ち担当者が変わり後任のマスター登録が回らなくなりアウトプット実績が他の基準となる資料と合わなくなっていく。

担当者の上司も変わる頃には、実績がおかしいことが話題になり、ベンダーの甘い誘惑に負けて最新のツールは何でも安く・早く・上手くできるように思え、また新たな管理視点を入れた最新のBI導入プロジェクトが立ち上がって行く。

なんてこと、皆さんの周りで起こっていませんか?

分析のためのマスターはメンテされない。どうすれば良いのか?決定打はなさそうだが、いくつかポイントを挙げてみる。

1.マスター登録の業務設計が成されていない。不十分。

誰が、どういうトリガーで、何のマスターを登録するのか、この業務設計がキチンとできているか?突っ走る分析担当者にこの重要性を認識してもらうのが中々大変。

2.管理の目的が組織全体で共有されているか?

管理するデータが生成されるタイミングで同時に分析のための分類が登録されないと後から付与するのは初回はともかくメンテが大変。そのためには管理の目的が組織全体で共有されていることが大事。

3.利用されるコードセット(リファレンスデータ)の標準コード

利用されるコードセットの標準コードが定義され運用されているとマッピングの回数を減らすことができる。標準コード類は後から導入できない。先に合意しておいてデータ生成組織が運用する現地コードの属性として追加していくとか、システム更新の機会をとらえて導入するとかが必要。

結局、できる限り管理対象のデータが生成される上流で管理のためのマスターが登録されないとだめかなぁ・・・。

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

デジタル・トランスフォメーション(DX)とは、デジタル(データ)とトランスフォメーション(変革)を組み合わせたものである。当然そこではデータ・マネジメント(DM)の要素がコアとなるはずだが、世の中そのようには理解されていないらしい。

ここではまず、2019年に経産省から発表されたDXレポート、DXガイドラインの内容について吟味してからDXとDMの関係に迫りたい。

DXレポート(2019年9月/57ページ)
~ITシステム「2025年の崖」の克服とDXの本格的な展開~

  1.  検討の背景と議論のスコープ
  2.  DXの推進に関する現状と課題
    1.  DXを実行する上での経営戦略における現状と課題
    2.  既存システムの現状と課題
    3.  ユーザ企業における経営層・各部門・人材等の課題
    4.  ユーザ企業とベンダー企業との関係
    5.  情報サービス産業の抱える課題
    6.  DXを推進しない場合の影響 (2025年の崖)
  3. 対応策の検討
    1.  「DX推進システムガイドライン」の策定
    2.  「見える化」指標、診断スキームの構築
    3.  DX実現に向けたITシステム構築におけるコスト・リスク低減のための対応策
    4.  ユーザ企業・ベンダー企業の目指すべき姿と双方の新たな関係
    5.  DX人材の育成・確保
    6.  ITシステム刷新の見通し明確化
  4. 今後の検討の方向性
  5. 終わりに

DX推進ガイドライン(2019年12月/10ページ)

  1.  はじめに
  2.  『デジタルトランスフォーメーションを推進するためのガイドライン』

 1)DX推進のための経営のあり方、仕組み

          • 経営戦略・ビジョンの提示》
          • 《経営トップのコミットメント
          • 《DX推進のための体制整備》
          • 投資等の意思決定のあり方》
          • 《DXにより実現すべきもの: スピーディーな変化への対応力》

 2)DXを実現する上で基盤となるITシステムの構築

体制・仕組み

          • 《全社的なITシステムの構築のための体制
          • 《全社的なITシステムの構築に向けたガバナンス
          • 《事業部門のオーナーシップと要件定義能力

実行プロセス

          • IT資産の分析・評価》
          • 《IT資産の仕分けとプランニング》
          • 《刷新後のITシステム:変化への追従力》

まず、DXレポートの2「 DXの推進に関する現状と課題 」は以下の図で概観できる。

DXレポート2.1概観

2-1:DXを活用する経営戦略がない。
2-2:既存システムがDX推進の足かせ
2-3:業務の見直しに対する反対勢力を押しきれない
2-4:ユーザ企業からベンダー企業への丸投げ
2-5:受託事業を中心とした
情報サービス産業ビジネス・モデル
はこのままでよいのか?

最後の2-6として「2025年の壁」が述べられている。
複雑化・老朽化・ブラックボックス化した既存システムが残存した場合・・・

経済損失は、2025年以降、最大12兆円/年(現在の約3倍)にのぼる可能性がある。

一方で、こうも書かれている。

【DXシナリオ】2025年までの間に、複雑化・ブラックボックス化した既存システムについて、廃棄や塩漬けにするもの等を仕分けしながら、必要なものについて刷新しつつ、DXを実現することにより、2030年実質GDP130兆円超の押上げを実現。

つまりレガシーな既存システムを温存した場合と、DXを実現した場合の差は、-60兆円(12兆円/年 x 5年)vs + GDP 130兆円というわけである(マイナスは主にITサイドであり、プラスはDXから生まれるビジネス価値なので単純に足し算はできない)。

この巨大な市場を誰が無視することができよう。いや皮肉を言う前に明確なことがある。レガシーシステムが今後5年間で仮にゼロになっとしても、その間に30兆円(60兆の半分)は経費が使われるということになる。さらに今後作られていくシステムも、作ったそばから陳腐化する。これはDXレポートでも指摘されている。しかし、ITシステムだけが問題なのだろうか。

次回は、企業の資産とはITシステムなのかDataなのかという点を議論したい。https://dama.data-gene.com/index.php/category/dx/