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

11月10日に開かれたADMC(Asian Data Management Conference)2020は、成功裏に終了できました。ありがとうございました。お申し込みは300名を超え、瞬間視聴者は200名に迫り、大変なご好評を頂きました。

さて、このADMCカンファレンスのタイトルでもある「」世界各国におけるDXの取り組みとデータマネジメント」について、前回に続き、つらつらお話ししたいと思います。

ご存知のように、Digital Transformationとは、DigitalizationとTransformationの2つの変化が同時に起こることを意味します。ところが現在世の中に広まっているDXのイメージにはその2点が含まれているのでしょうか。いきなりDXに予算を付ける前に、少し立ち止まって考えて見ることも必要だと思います。

まず、Digitalizationとは、増大するデジタル情報を如何に効率的に処理して、ビジネス価値に結び付けることを意味します。ちなみに、https://en.wikipedia.org/wiki/Digital_transformation では、以下のように定義されています。

「Digitalization (of industries and organizations) 
Unlike digitization, digitalization is the ‘organizational process’ or ‘business process’ of the technologically-induced change within industries, organizations, markets and branches.

日本語訳:デジタル化とは異なり、デジタルライゼーションとは、業界、組織、市場、支店内で技術的に引き起こされた変化の「組織プロセス」または「ビジネスプロセス」」

これを見ると、Digitalizationには既に「Transformationを意味する変化」という言葉が含まれていることがわかります。実は以下が、https://www.etymonline.com/word/digitalizeに掲載されている語源です。

ではDigitalの語源は、https://www.etymonline.com/word/digital?ref=etymonline_crossreferenceに以下のように示されています。

元々「指先」という意味だったんですね。指で数える、10以下の整数にする、それが0と1に置き換える(デジタル情報化)ということになったということですね。当然ですが、この時点では「変化」という意味合いは全く含まれていません。最近になってITと絡めたマーケティング的な意味合いになってきたということでしょうか。

このブログでは、デジタル化に伴う変化については別途取り上げることとし、デジタル情報に話を絞ります。

デジタル情報とは、もちろんコンピュータが処理可能なデータのことを指します。画像や音声情報でも全てデジタル化され処理されます。ここでデータを処理することと、データを管理することは全く異なります。管理されていないデータを処理してしまうと、そこからどんな品質のアウトプットが出てくるのかわからない。

一方で、データはコンピュータで処理するためにディスクなどに保存されているのだから、管理されているではないか、という方もいます。つまりPDFやMS Officeファイルがフォルダーに保存されている、データがデータベースに保存されている。フォルダーは階層構造で名前が付けられて分類されているし、データベースでも個々のデータが入る場所が決まっているではないか。

本当にこの状態でデータが管理されていることになるでしょうか。何かを管理するということは、それらをビジネスに役立てることができるということです。いや、もちろん今でも業務に役立っていると言われるでしょう。ファイルをコピペして修正しあっという間に業務文書が作れるではないかと言われるでしょう。その通りです。紙がなくなっただけましだということです。

ただ、より大きなビジネス価値を生み出すためには、管理方法も進化しなければなりません。価値の増大にはレベルがあります。例えば、「社内日常業務の効率化」は属人的な作業からより共通化した業務プロセスに進化するするでしょう。今までのITはこのレベルの達成を狙っていたことは事実です。つまり業務効率化のコストセーブの分が、IT予算よりも大きいことが予算獲得のキーでした。

基本的に情報は基本的に階層構造では分類できません。情報と情報を関連付けることしかできません。一方で情報を構成する最小単位にまで分解(データ化)すれば、データモデルに落とし込むことができます。ただデータモデルは階層構造ではなく、ネットワーク構造です。

何を言いたいかと言うと、デジタル化された対象(ファイル、情報、データ)を処理したり分析するためには、前提として「関連付け」が行われなければならないということです。もちろんこの関連付け自体がデジタル処理でもあります。

ここで重要なのはデジタル化された情報や、分解されたデータの定義です。よくものの定義はその関連性においてのみ意味をもつということが言われます。逆に言えば、定義と関連性は一対ということになります。

次回はこのTransformationについてお話ししたいと思います。

データ品質管理の具体的な成果物(その2)

前回私が担当したブログでは、第8分科会で整理しているDQワークシートの概要をご紹介しました。今回は、その中でも「ビジネスニーズ整理ワークシート」にフォーカスしてご紹介したいと思います。
(※DQワークシートはこちらよりダウンロードいただけます)

実は、第8分科会でワークシートの議論を進める中で、最も時間がかかったのがこの「ビジネスニーズ整理ワークシート」です。

ビジネス要件を品質要件に落としていく部分は、DMBOK1の記述でも抽象度が高く、様々な議論がありましたが、何かしら軸になる整理の仕方が必要ということで、「5W1H」の観点をベースに据えて定義すべき項目を整理しています。

ビジネスニーズ整理ワークシート

このワークシートでは、下記の要素を整理していきます。

  1. ビジネスニーズ(Why/What)
  2. 業務プロセス(Where/When)
  3. 業務プロセス関連組織/担当者(Who)
  4. 情報要求(What)
  5. データ品質要件(How)

今回は、 1.ビジネスニーズ、4.情報要求、5.データ品質要件に触れて、メインの流れをご説明していきます。

ビジネスニーズ(Why/What)

まず、背景、目的とビジネス観点での要求事項を明らかにします。実現したいことを理解する上で、背景や目的が重要なのはもちろんですが、では、要求事項はどの程度まで明らかにすれば良いのでしょうか。

ワークシートのサンプルでは下記のように定義しています(一部抜粋)。

  • 背景:改正派遣法の遵守
  • 目的:客先に派遣する社員に対するキャリア形成制度を維持すること
  • 要求事項:新入社員は3年連続で技術系の研修(8h/年)を受講しなければならない
    →技術系の研修で8h/年を満たしていない該当年次者が居ないこと

要求事項をデータ品質要件につなげていくためには、ここで、必要な情報の「範囲」と「粒度」をある程度明らかにする必要があります。サンプルの要求事項からは下記が読み取れると思います。

  • 範囲:
    • 入社3年目までの社員
    • 年間の研修時間
  • 粒度:
    • 社員個人
    • 研修の分類(技術系など)×時間数(h)

このくらいまで定義できれば、求められる情報が具体的にイメージできるかと思います。

情報要求(What)

要求事項を満たすために必要な情報を整理します。最終的にはデータ品質管理はカラムをベースに実施していくことになるので、一つの要求事項を満たすために必要な情報について項目をイメージしながら分解し、定義していきます。上記のように情報の範囲と粒度を意識すると、定義しやすいと思います。サンプルでは下記のように定義しています(一部抜粋)。

  • 受講者個人を特定できること
    • 社員の年次が正しいこと
    • 研修が技術系/ヒューマン系のいずれかがわかること
    • 受講年度単位の研修時間がわかること

この段階では、特定のデータセットに引きずられないように、業務的に必要な情報の定義にとどめます。要求に適したデータセットを探すのは後続のワークシートで実施します。

データ品質要件(How)

1つの情報要求に対して、データ品質評価軸(正確性、完全性、・・など)を当てて、データ品質の観点から求められることを洗い出します。後で実データを見てから追加することもできるので、まずは、机上で重要なポイントを定義します。

例)情報要求:受講者個人を特定できること
    →【完全性】 社員を識別する項目に抜け、モレがないこと

この他にもこのワークシートで定義すべき項目はありますが、大きくは上記のような流れで進めます。

終わりに

先日の第8分科会では、この「ビジネスニーズ整理ワークシート」を利用して、少し別の角度から、データ整備の進め方について検討されている方々とお話しすることができました。 実プロジェクトで活用されている事例も出てきており、 私達のアウトプットがデータマネジメントに取り組まれる方々の活動に、具体的に寄与できるのは非常に喜ばしいことだと改めて感じています。

半径2メートル雑感2題

ここ最近の出来事で感じた半径2メートルでの出来事の雑感を書いてみようと思います。

ADMCの字幕付け
今回のADMC2020は、初めてのZoomウェビナーでの開催です。
現在、企画担当理事を中心に鋭意準備をしています。
今回は外国人スピーカーは招聘せず、スピーカーからビデオを事前にいただき。理事で分担して日本語字幕を付けて流す形にしましたので、英語の苦手な方も視聴しやすい形になっていると思います。
とは言え、私は英語がサッパリなので英語堪能な林会長の補助として、会長が翻訳した内容の校正のお手伝いを行いました。担当は欧州・イタリア代表のNinoさんの分担でした。
内容は是非ご参加いただいて視聴いただきたいのですが、欧州では国を超えての活動や交流、研究成果の共有などが活発なようで、アジアとは随分様相が違うなぁと感じた次第。
言語の壁はありますが、今後はAsian Data Management Conference の名に恥じないカンファレンスにしていきたいものです。
近隣の中国、韓国をはじめとして、東南アジアの各国とも連携強化していきたいですね。(その前に英語をなんとかしないとですが…)

ITモダナイゼーションとデータ
縁があって、最近ITモダナイゼーションの仕事をしています。
メインフレームからのOPEN化が主な業務ですが、なかなかに難しく、過去に作りこまれた謎解きに追われています。
そういった中、データの移行や更改などは二の次になっていて、プログラム資産の移行が主題になることが多いなと改めて感じています。
もちろん、言語変換やリビルドはテストも含めて工数もかかりますので、どうしてもそちらがメインテーマになってしまい、データ整備が劣後してしまうのは致し方ないのかもしれません。
しかし、データを見ると様々な過去の残滓が残っていて非効率なことも多々あるので、この際一気にきれいにしてしまおう!とすると追加の費用がかかり、かつプログラムへのインパクトが少なくないということで、データは現在のまま、そーっと新環境にもっていこう、という結論になってしまい勝ちなようです。
システム更改の時期になってしまってから何とかしようとしても、現状ではそれをなんとかするソリューションは無いように思います。
なので、いざシステム更改の時に一番大事な資産であるデータが置いてきぼりにならないように、日頃から少しずつデータマネジメントを進めておく必要があるなぁと今更ながらに感じています。

データがつながれば社会が変わる

 近年、データのつながりの拡大を肌身で感じることが多い。例えば、自宅PCによく検索した商品や類似の商品が、突如ポップアップされる。これは、自宅PCと商品サイトが検索履歴のデータでつながっているためである。また、スマフォを持って外出して地図情報から目的地の検索をかけると、近くのレストランやドラッグストアなどの広告が入り、ドラッグストアなどは検索すると割引チケットも入手できる。これは、自分のスマフォの位置情報とレストランやドラッグストアの地図情報を含むサイトがつながっているからである。
 このように、販促を目的とした情報のつながりは急速に拡大している。

マイナンバーは与えられたけれど

 マイナンバーは、2015年10月5日から、個人番号の指定が始まり、2016年1月からは、行政手続における個人番号の利用が開始された。https://ja.wikipedia.org/wiki/%E5%80%8B%E4%BA%BA%E7%95%AA%E5%8F%B7

 すでに5年近く経過しているが、このマイナンバーが、どれほどつながりをもっているだろうか?
市区町村の手続きにマイナンバーを使うことで、一部の書類提出は不要な経験はあったが、身近で 便利になった、よりよいサービスを受けた実感は全くない。どちらかというと、マイナンバーを人に知られないため極力提示しない、マイナンバーカードは持ち歩かず自宅に保管など、秘守の扱いに注力している。

 個人を特定するIDがなければ、データのつながりは初められない。個人のデータのつながりの出発点として、マイナンバーはなくてはならないものである。
 個人情報保護の観点があまりにも強いため、マイナンバーの利用拡大はなかなか進んでいないと感じる。マイナンバーがしっかり管理され、漏洩や悪用ができない環境であれば、生まれた赤ちゃんにマイナンバーを付与する手続きだけで出生届は不要となり、年齢も把握できる。また、親のマイナンバーとつなげれば戸籍や住民情報に自動で登録ができる。年齢も把握できるので、小学校入学時に自動的に案内を出すことも可能となる(すでにこのようになっている国もあると聞いている)。このように、マイナンバーを管理し、マイナンバーをつなげることで、役所の管理作業の大幅な軽減の他に個人へのサービスが拡がる期待が膨らむ。

製品に不具合が起きた。この製品を作った工場のラインはどこ?

 これがすぐに把握できる会社は、少ないだろう。工場で作られた製品は、多くは工場⇒倉庫⇒販売店舗⇒客 のような流れで客にわたる。個々の製品にマイナンバーのような製品を特定するIDが付与されていないため、工場での製品番号、倉庫で管理する番号、販売店舗の商品番号がその場所の特有な番号で管理されている。このため、逆に客に渡った製品が客⇒販売店舗⇒倉庫⇒工場を特定するのに、個々の番号の対照表から辿らなければならず、時間がかかる。一気通貫のシステムになっていないためである。

 工場でラインを特定するには、その製品がいつ、どのラインで、どの部品を使って組み立てられたかの情報も必要となる。本来、やりたいことは、同一な不具合が起きることが想定されるため、その工場ラインが特定できたら、そこで同時期に作った他の製品がどの客に渡っているかを知り、その購入客に不具合を知らせ、重大な不良であれば使用をやめるように一刻も早く伝えることである。

 このように製品が特定できるIDを付与し、つなげていかないと十分なサービスを客に提供できない。

個人やモノの特定ができれば、サービスが膨らむ

 個人やモノを特定するIDの必要性は、認識できた。このIDにより、データが迅速につながっていけるからである。現在、個人のPCやスマフォが個人を特定するものとして使われている。しかし、個人のPCやスマフォを換えてしまえば、そこで個人の特定は途絶えてしまう。
 マイナンバーが個人を特定できるIDとして付与されたことは、意義深い。データをつなげる準備はできたのだ。

 マイナンバーのセキュリティが守られる環境となれば、データがつながることでサービスの観点から夢は膨らむ。マイナンバーカード一つあれば、買い物、ホテルのチックイン、交通機関への乗車などは、このカードをタッチするだけでできる。また、急病で病院に運ばれた際に病歴や毎日飲んでいる薬などを瞬時で把握でき、適格な治療が受けられる等々。

 このような社会を早く実現するためにも、データをつなげていく活動にさらに
関心をもっていただき、そのような機会があれば実活動に注力していただきたいと思います。データをつなげる意識の醸成が加速すれば、未来は急速に変わっていくと信じます。

以上

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

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

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

かつても「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キャンペーンの是非などを巡って、様々な議論があり、政治的決断の難しさが顕わになりました。

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

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

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

以上