DMBOK第2版 第2章 「データ取扱倫理」は読む価値があるのか!?

DMBOK第2版では第1版からいくつかの章が追加されているが、その中の一つで際立っているのが「第2章 データ取扱倫理」である。この章は、データセキュリティ以前にデータマネジメントを行う上で守るべき倫理的概念や、非倫理的データの扱いの例が説明されており、 GDPR (General Data Protection Regulation: EU一般データ保護規則) をはじめとする各国の関連する法律にも言及している。
知識領域でもなく、新しい概念でもない、他とは異彩を放つ第2章。この章が追加された意義は何なのか、筆者の考えを述べたい。

第2章は データマネジメント会員規約?

いきなり話が変わるが、例えば皆さんが何らかのクラブ有料会員になる時にどのようなステップを踏むであろう? 通常は

 1.クラブ有料会員の概要を説明資料等で理解する
 2.会員申請し承認を得る。
  その際に「会員規約を読み、同意するサインを行う」
 3.会員として参加する

であろう。ところで皆さんは「同意するサインを行う」際にちゃんと会員規約を読んでいるであろうか?
多くの人は何も読まずにサイン(チェックボックスにチェック)してしまうのではないだろうか?

ところがこれが会員規約ではなく、数百億円の契約書の「契約条件」の場合はどうであろうか?おそらく目を皿のようにして確認するのではないか?

筆者はDMBOK 第2版 の「第2章 データ取扱倫理」はデータマネジメントにおける「会員規約」もしくは「契約条件」にあたるものと理解している。すなわち

 1.第1章でデータマネジメント概要を理解する
 2.第2章でデータマネジメントの「会員規約/契約条件」を理解する
 3.その上で、第3章以降のデータマネジメントを実践する

第2章を読む必要性

筆者の理解が正しいとすると、追加になったこの第2章を読む必要はあるのだろうか?それは以下のように考える

 1) データマネジメントを学びたい、DMBOKを理解したい
  → 第2章は無理して読む必要はない。
   先に第3章以降の興味のある章を読むべし≒「会員規約」
 2) データマネジメント組織を創りDMBOKベースでデータマネジメントを
  実践したい
  →第2章はしっかり読むべし≒「契約条件」

このように考えると、この章が最終章ではなく、第2章に位置付けられている意味も理解できる気がする。

それでも第2章は興味深い

上記の 1) の場合は「無理して読む必要はない」と言いながら、ひとこと付け加えさせていただくと、この章に書いてあることが決して面白くないという意味ではない。むしろ、この章にはデータマネジメントにとどまらず、一般的な話として興味深い内容が盛りだくさんとも言える。特に「3.4 非倫理的なデータ取扱業務のリスク」に関しては、非倫理的なデータ取扱の例が記載されており、自分自身が「あの時はデータに騙されてしまった!」や、逆に「あの時は、ちょっと悪さをして騙そうとしてしまったなあ」といった苦い思い出が蘇ってきたりもする。
この話はまた機会があればお伝えしたいと思う。

DXと用語の定義

DXについて多くが語られています。DXを進めて行くとはどういうことなんでしょう。いろいろなレポートを読んでも今まで今一つ腹落ちしませんでした。それが急にDXを推進することになった会社のガイドを見て、さらに先日のADMCの講演を聞いてストンと腹落ちしました。

DXの推進にはいくつかのステップがあるがDX1.0が大事である、すなわちそれは、顧客の価値を再定義し、デジタルソリューションの適用範囲を定め、全体を管理するKPIを設定する。データはこのデジタルソリューションとKPIに使われる。

デジタルソリューションとは何か?CJさんによればPython codeを書いて未来を予測できること(人達)。大量データを瞬時に読込み・組み換えとかもありますね。生産計画とかに使えそうです。

この次は何か。それは繋がること。今までの責任分界点を超えて繋がること。これにより今まで絵空事だった例えばグローバルSCMの最適化、なんてことがスコープに入ってくる。責任分界点を超えるとは、法人の中では機能組織の間でしょうし、製造・販売が分かれていればそれは法人間を超えて繋がることだと思います。

その時、何が起こるのか。今までは責任分界の中で自分最適で自分のシステムと仕事をしていれば良かったけど、今度は責任分界を超えてより大きな責任分界で最適化するために異なるシステムのデータを繋いでいく必要が生じる。今までは人間系で悠長に(月次?週次?日次?)翻訳しながら回していたけど、デジタルソリューションはリアルタイムにトランザクション毎に処理して行く?のでこのままだとデータが衝突してしまう。

残念ながら各所のシステムはこの意味で標準化されていないのです。世の中には標準化されている(いわゆるワンインスタンス)企業も数多あるとは思いますが、これが現実だ。データとデータをマッピングしながらデジタルソリューションを適用していかなければならない。CJさんとホバーマンさんの講演は一つ一つ私の胸に刺さりました。

デジタルソリューションから見て責任分界を再編することは、かつてBPRで多くの企業が討ち死にしたことを思い起こします。でもそれは例えばSCMの神の手を得るために必要なことだと思うけど、大丈夫かな?

DXと騒いでいるけど、多少未来が予測できるようになるかも知れないが、やるべきであったのに今までやれなかったことをやり通すことも、大きな割合を占めているように感じます。

やっぱり先ずは業務用語集とデータディクショナリーで今流に言えばデータカタログからかな。

デジタル・トランスフォーメーション(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図にはそれ以外の要素もあります。「地方」エンティティに再帰リレーションシップがあることや、格付が「地方」と「ワイン」の両方にあるところ、「ワイン分類」の「バランス分類コード」とは何を意味しているのかなど。これを発展させてワインの販売管理のモデルを考えてみるなどは次回のお楽しみにとっておきます。