パッケージシステム導入時のデータモデル

パッケージシステムでは、多くの業種とその業務プロセスに対応できる、柔軟な標準機能が用意されています。そのためパッケージ導入プロジェクトでは、新規業務をこうした標準機能でどこまで対応できるか、Fit&Gap分析を行います。

たいていのプロジェクトでは、この分析時にプロセスモデル図を作成し、
・どのプロセスにどのパッケージ標準機能が対応するのか
・パッケージ標準機能が対応できない業務は、アドオンを導入するのか、追加開発するのか
を明らかにしていきます。

データ構造もFit&Gap分析が必要

一方、パッケージは機能だけではなく、データを格納する標準データ構造(テーブルなど)も用意しています。
機能をプロセスモデル図でFit&Gap分析するのと同じように、新規に管理すべきデータと標準データ構造をデータモデルで図化して分析すれば、より漏れ無く無駄の無いパッケージ導入ができるはずです。

ただ実際のパッケージ導入プロジェクトの多くで、プロセスモデル図は作られてもデータモデルはあまり作られないようです。
それで問題が起きなければいいのですが、そういったプロジェクトではテーブルやI/F設計の手戻りが発生したり、データの移行設計が見直されたりすることが多いように思えます。

データモデルに工数をかける価値

なぜパッケージ導入プロジェクトで、データモデルは作られないのでしょうか。
まず、パッケージ導入が短期間のシステム構築を目的としているため、データモデル作成の工数を懸念されるのかもしれません。既存システムからパッケージの移行設計をしなくてはいけないのに、データモデルまで作るのは負荷が高い、などなど。
ただ移行範囲全体を表すデータモデルが一枚あると、詳細な移行設計前に移行元と移行先の関係を確認でき、対象データの漏れや重複の確認ができます。移行設計の手戻りは移行作業の負荷とテストの精度にも影響を与えるので、早い段階で移行検討できるのは価値が高いでしょう。

モデリングコミュニティとしてのDAMA

データモデルが作られないのは、パッケージ導入の現場にデータモデルを読み書きできる人材が少ないこともあるでしょう。データモデラーはどうしても手組みシステム開発の現場にアサインされがちです。
またプロセスモデル図がプロセス間の関係を順に追って読めるのに対して、データモデルは記法による表現の違いが大きく、読むのにもある程度の学習が必要です。

もしこのエントリーを機にデータモデルを学びたいという方がいらっしゃったら、書籍を読んだりセミナーに参加したりするのに加えて、DAMA日本支部に入会されることをオススメします。実はDAMAには、メインフレームのシステム開発時代からデータモデルと格闘してきた、データモデラーの“猛者”たちが集っているからです。
特に、第10分科会「データモデリングの実践的検討会」では具体的なデータモデルをベースにノウハウの共有を行っていますから、パッケージ導入時のコツについて聞くことができるかもしれません。

データモデルのスコープを広げよう

小規模なシステムで,単独で稼働するようなものであればデータモデルはDB設計の前段と捉えてもそれほど問題にならないが,企業や政府のシステムは複雑で,多数のシステムから構成されているため,全体を見通すことが難しい。企業合併や買収もあると,システムがそこかしこで分断され,無理やりのデータ変換や,EXCEL等の利用も含めた人間系を介在させることで,なんとかやりくりしていることも多い。

また,多数のシステムのうちのいくつかは外部から購入したパッケージやクラウドサービスを利用しているのも普通であろう。これらは内部のデータ構造はブラックボックスであることも多く,当該組織に合わせて最適なデータモデルというわけにはいかないことも多いだろう。しかし,全て自前のカスタムシステムで組織全体のシステムを構築することは時間的にも,コストの面でも現実的ではない。いや,時間をかけてもビジネスの変化についていけないシステムを長期間かけて構築することになりかねず,出来上がったときは,既に陳腐化している恐れもある。パッケージやクラウドサービスを組み合わせて使うことを前提として考えるべきだろう。

では,その前提に立ち、システム群を全体最適な構造に再構成し、どう維持していくかという課題に対する答えが、システム群を横断するエンタープライズレベルのデータモデルである。注意してほしいのは、個々のシステム内に閉じているローカルなデータは対象とせず、システム間で共有、連携されるグローバルなデータにフォーカスすることである。

データモデルとDB設計は密接な関係があるが(混同されている場合も多い),パッケージやクラウドサービス,継続使用可能なレガシーシステムを活かしつつ,アドホックでなく,アーキテクチャとしての連携を成功させる鍵は、システム群を横断するデータモデルである。DB設計のスコープは個々のシステムだが,エンタープライズレベルにスコープを広げたデータモデルが必要とされているのである。ただし、DB設計だけに引き継がれるのではなく、連携データのフォーマットやメタデータ定義、コード定義につながるのである。

DMBOK2では,DMBOK1にはなかった幾つかの章があるが,その1つとして「第8章 データ統合と相互運用性」がある。ここでは直接、データモデルに言及しておらず、テクニカルなデータ連携アーキテクチャに関する記述がメインだが、それだけではデータ統合はできない。 データHUB,EAI,ESB等が取り上げられているが,こうしたテクニカルなプラットフォームだけでは,個々のパーツ(システムやサービス)を全体最適の観点でつなぎあわせることはできない。

データモデルの適用スコープをここまで広げ,複数のシステムが会話する共通語としてデータモデルとメタデータ定義を行い,それに基づいて,個々のシステムが会話,連携できるようにすることがポイントである。アイテムや顧客についてはエンタープライズレベルのデータモデルに合わせてることで、複数のシステムが無理なく連携可能となる。

種々の事情があり,制約も多いため,安易な批判は避けたいが,特別給付金の電子受付と個々の自治体のシステムがうまく連携できなかったのも,こうした複数システムのスコープでモデルを作成できなかったことも関係しているのではないかとも思えるのである。

標準の作成と定着化について

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

世の中にはDMBOK以外に、「プロジェクトマネジメント知識体系ガイド(PMBOK):PMI」、「ビジネスアナリシス知識体系ガイド(BABOK):IIBA」、「ITアーキテクチャの知識体系(ITABoK):Iasa」、などなど、知識体系ガイド(BOK)が多くあります。

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

そもそも標準化、もしくは標準文書の作成は必要なのでしょうか・・・。

多くの会社が標準文書は作成したものの、その後、活用されなくなり、形骸化して使われなくなってしまい、また何年か後に、新たに別の標準文書が作成され、また使われなくなり・・・と繰り返される場合があります。

当初は、ビジネスや業務を実施する上で、課題・リスクがあり、その原因を分析・評価した結果、マネジメント(プロジェクト、データマネジメント等)に問題があり、その解決策として、これまで実施していなかった、また属人的に実施していた「マネジメント活動」の実施、もしくは強化を図る事を考えられた事と思います。

そして、その手段の一つとして標準文書を作成し、それを基にビジネス活動を行うことによって、ビジネスを成功に導くことが目的・目標であったはずです。

上記のような理由があれば、標準文書の作成は必要性になりますし、その改善活動等が定着化・浸透してしまえば、ビジネス上の課題・リスクは無くなるため、標準文書を活用しなくてもよい場合もありますが、新しい人が増えた場合に維持していくのは難しいと思います。
また、標準文書を作成しても活用されないのは、標準文書の問題ではなく、定着化、浸透の仕方に問題がある場合が多いです。

よって、標準化、もしくは標準文書の作成は必要です。

  • 新たな取組みをする場合は、その取組みを文書化し、共通認識を図るために標準化、標準文書は必要です。
  • 属人的な活動に問題があり、ビジネスや業務に課題・リスクがあるため、業務を標準的、均一的に行うことによって、業務の品質向上、リスク軽減を図る施策の一つとして必要になります。
  • よって、ビジネスや業務を実施する上での「課題・リスク」を解決する手段の一つとして有効です。

何故、DMBOK、PMBOK等の知識体系があるのに、会社や組織の標準文書を作る必要があるのでしょうか・・・。

例としてPMBOKは、ビジネスの業界・業種を問わず、汎用的な知識体系となっており、ビル建設等のプロジェクトにも、ITのシステム開発プロジェクトにも、研究開発のプロジェクトにも特化しておらず、共通的、汎用的な知識体系となっています。
よって、ビジネスや業務を実施する上で、ある業界、業種、会社・組織に合った標準にする必要があります。

また、会社の課題、リスクを考えると、ある部分を詳しく定義、記載する必要があります。
それと、会社・組織には関係ない、必要ないプロセスやアクティビティもあります。最初は全ての範囲を実施するのではなく、段階的にステップを分けて、スモールスタートで順次拡張していくのであれば、最初から全てBOKと同じ範囲のもの全て作成する必要はありません。

よって、DMBOK、PMBOK等の知識体系があっても、会社や組織の標準文書の作成は必要になります。

会社や組織の標準文書作成時に、DMBOK、PMBOK等の知識体系を活用する理由は・・・。

これはDAMA日本支部会員の方々にはあらためて言う必要はありませんが(笑)、他の方にご説明される場合の参考として下さい。

専門領域の知識体系は、その専門領域の有識者のノウハウを結集していて、体系化されているため、全体を把握、俯瞰できることが重要になります。現在の自社の取り組みの評価をする際にもベンチマーク、リファレンスモデルとして活用できます。DMBOKですと、DAMA-DMBOKフレームワークやアクティビティで体系化されています。PMBOKでは知識エリアやプロセス群で体系化されています。

また各ガイドで使われている用語、定義を活用することにより、様々な人が共通な言葉でコミュニケーションが出来ることになり、それにより、コミュニケーションも早くなり、円滑にでき、そのメリットは大変重要になります。

それと、各BOKは、バージョンアップされる事が多いため、世の中の動向や実績に追従したノウハウを習得できると思います。

但し、これはあくまで私見ではありますが、各知識体系やその業界の標準は、ある程度業界内で定着した後に、体系化され、まとめられている場合もあります。そういった場合は、ある程度古い(語弊がありますが)やり方になっている可能性もあり、現在の早いスピードで動いている世の中では、見直し・拡張が必要な場合もあると考えます。これも、前述の会社や組織の標準文書作成の必要性の一つと思っています。

よって、まだマネジメント等の取り組みがなされていなければ、専門領域の基礎知識として活用し、知識体系がバージョンアップされることで、最新の知識体系も取り入れることができます。また、実際に実施されている業務の取組みの方が進んでいれば、そこは前述の会社や組織の標準の中で拡張すればいいと思います。

今後、標準化・標準文書作成を検討するにあたって・・・。

  • 標準化・標準文書の作成は、ビジネス・業務の課題・リスクを十分整理した上で、その目的・目標を明確にして検討・作成が必要になります。
  • 標準文書が活用されなくなるのは、標準化や標準文書を作成する事がよくないのではなく、その目的・目標がはっきりしていないから。目的・目標に合った、範囲や内容の標準化、文書とする必要があります。
  • BOK等の専門領域の知識体系は、全体網羅でき、体系化され、また共通の言葉・用語で会話できるため有用です。
  • 標準化、標準文書作成だけで終わるのではなく、定着化や浸透の施策が必要であり、重要です。作成した後の取り組みが不可欠になります。

以上

データモデリングから始めませんか?

 DMBOKガイド第1版ではデータモデリングは「データ開発」の一部でしたが、第2版では新たに「データモデリングとデザイン」という章が設けられました。
 果たして、日本の企業での中でどれ位、データモデリングが行われているでしょうか?残念ながら、あまり多くないというのが私の印象です。或いは、データベース設計のためにのみ使われ、開発後に維持されていないことが多いとも思います。あるSIerの中では、「最近は全く新規でのシステム開発ということが殆どないので、データモデリングを習っても実践する場がなくなった」と言われていました。
 新規のデータベース設計がなくても、業務分析しかり、現行システムのデータ構造の逆解析など色々と用途があるのに勿体ない話です。
 例の「2025年の崖」への対策としてレガシーからの脱却を図るということであれば、先ずはデータモデリングを用いた分析から取り掛かってはいかがでしょうか。

 私は受託開発を行う際の分析と、その開発のための方法を探っていた中でデータモデリングに辿り着いたので、その視点からデータマネジメントにおけるデータモデリングについて少し考察してみます。

データマネジメントにどこから手を付けるか?

データマネジメントはDMBOKガイドの目次を見てもわかる通り、非常に多岐に渡る活動やスキルから成っています。データマネジメントに取り組むきっかけも色々でしょうし、これまでの環境や現在の要求事項に応えるために取り組みの優先順位が決まることもあるでしょう。それでも敢えて取り組みのための順序を考えるならば、次のようではないかと私は考えます。
 最初に必要なことは、実際の活動母体となる組織作りでしょう。本格的な専任の部署でも、ワーキンググループのようなものでも構いませんが、業務とITの両方の視点が必要なので、一人きりで始めるより、できれば数人で始めたいです。例えば利活用のためのPoCに向けて作られたWGとかでも良いです。そして、更に可能であれば経営者のコミットメントが欲しいところです。

 次に取り組むのにはデータモデリングが良いのでは考えています。データをマネジメントすると言うのだから、そのデータがどんな構造をしていて、何処にあるのかが明らかになっている必要があります。

データモデリングとデータカタログ作成

 どんなデータが何処にあり、どういった関係かを明らかにするための手段には、次のものがあります。一つには、データモデリングを行い、業務に必要なデータ、あるいは現在運用されているデータとその関係を明らかにしていく方法です。
 それだけでは、実際のシステムにて、何処にそのデータが存在するのかわかりません。そのためには、ツールの力を使ってデータカタログ作成を行うことと、その過程で実際に格納されているデータのプロファイリングを行うことが必要です 。

 順序については、置かれている環境(人のスキルも含めて)によって異なりますが、可能であれば、1)データモデリングにより業務におけるデータ構造をあきらかにする。2)プロファイリングを伴ったデータカタログ作成を行う。といった順で進めることが良いと思います。
 データモデリングは飛ばしてデータカタログだけ作るのではダメか?という方もあるでしょう。データカタログ作成により、存在する項目は明らかになり、似通った項目の統合もある程度進めることができると思います。
 しかしながら、データ項目間の関係を明らかにすることは難しいです。また、実装の都合が強く反映されている場合もあります。たとえ参照整合性制約があっても、その関係をパッと目で見て取ることができません。開発時に、表形式のデータベース設計書のみを作れば良いか、データモデルを書くべきなのかということも議論されますが、データモデルを書く方が良いと考えます 。

 データカタログ作成より、できればデータモデリングを先に行うことをお薦めします。メタデータを明らかしていく上で、項目の名称以外に意味を定義する必要がありますが、それには関係を問いながら掘り下げていくことができるデータモデリングが有効です。もちろん、事情によってはともかく現状のデータの在り方を明らかにするために、ツールによってデータカタログを作成し、その後に解析を行うために部分的にデータモデリングを併用するという方法もあります。そのためには、いずれにせよデータモデリングを実践できるスキルを持った人が必要になります。

 データモデリングは誤解されていることが多く、RDBの項目定義と同等のものを 単に箱と線で書かれたER図を作っていくことがデータモデリングだと思われていて、IE法やIDEF1Xなどの表記ばかりが取り沙汰されます。しかしながら、そこにはビジネスを解析するための方法論があります。
 データベース設計を目指すだけでなくデータを起点にビジネスを解析することができます。ある企業にて作成支援をし、作成したモデルを別のモデラーたちが初見でどれ位に現状のビジネス課題を出せるかという実験をしたところ、依頼した企業の業務側の人が驚くほど正確に課題が出されてきました。モデル上でモデラーにとって気持ち悪い記述のところには、何らかの無理がかかっていることが読み取れるというだけのことですが、モデリングの威力を知って貰うには良い機会でした。
 それが可能なように、あるビジネスをなるべく同じ視点で解析し、同じモデルが書けるようになるための方法論が必要です。

 ここで一つだけ、私のお気に入りのモデリング手法を紹介しておきます。佐藤正美さんが考案したTMと呼ばれる手法です(私は「T之字」と読んでいます)。

 もちろん、 企業によって事情が大きく異なると思います。データカタログを作る中で殆ど意味の定義も問題なくできる企業もあれば、データプロファイリングも並行しないと意味がとれないような場合もあります。また、モデリングを先行させ、データカタログを作りながらプロファイリングを進める方が良いという企業が多いのではないでしょうか。いずれにせよ、有意義なモデルを作れるデータモデラーを確保できているか、という点が課題になります 。

 私の次回分では、データモデラーのお噺にしようかと思います。

新型コロナウイルスとオープンデータ

今回のコロナ禍の中、オープンデータの活用が目を引く機会が増えてきているように思われます。(下図<東洋経済オンライン>は、皆さんも良くご覧になっているのではないでしょうか。)そこで、オープンデータの現況について調べてみました。

私が、オープンデータを知った契機は、某ソリューション会社にてデータの利活用状況について動向調査をしていた時でした。米国のDATA.GOVを覗いたところ、そこに、当時(2013年)のオバマ大統領のメッセージとして「参加型の民主主義をより一層推進するためにこのサイトを立ち上げた~云々」といった内容が高らかに謳われており、妙に感心したことを覚えています。

日本では、2011年の東日本大震災発生時に、それまで電子政府の取組みを進めていたにもかかわらず、緊急事態に即応する行政のデータがなかなか提供できない中、Google/Twitter社による携帯電話やSNS等からのいわゆるビッグデータ活用した取組みが大きな話題を呼びました。

その後、公共データ等を集約して二次利用可能な形に整備して提供できるような体制が求められ、2012年に「電子行政オープンデータ戦略」が策定され、推進されてきました。 それから大分時が経過しましたが、日本のオープンデータの現状は、どうでしょうか?

The Open Data Barometer ホームページより

WWW財団による、Open Data Barometer によると、2018年の世界の上位は、上の表のようになっています。
日本はニュージーランドと並んで6位にランクされています。
意外(?)とも思えますが、実際の状況はどうでしょうか。

1.政府の状況

当初、データ公開中心の取組みであった「オープンデータ1.0」から、2016年には、データの利活用を前提とした「課題解決型のオープンデータ」の実現を目指す「オープンデータ2.0」にステップアップし進められてきました。(政府の取組みについての詳細は、「オープンデータへの取組み」参照。)

「オープンデータ2.0」構想のもと、2017年5月には、「オープンデータ基本指針」が策定されました。オープンデータの意義や定義とともに、行政手続きや情報システムの企画・設計段階からオープンデータ・バイ・デザインの考え方を取り入れることを前提として、基本ルールが以下のように定められています。

行政保有のデータは公開を原則とし、二次利用も積極的に促進すること、公開環境として容易に検索・利用できるウェブサイトを利用すること、データの形式はWWWの創設者Tim Berbers-Lee が提唱した「5つ星」の指標を参考にする、オープンデータのメタ情報をデータカタログサイト「DATA.GO.JP」に登録し、公開することなど。 また、公開・活用を促す仕組みとして、官民でデータの公開・活用の在り方を対話する「オープンデータ官民ラウンドテーブル」が2018年1月から開催されています。

2.地方自治体の状況

政府のみならず、2016年の「官民データ活用推進基本法」により、都道府県での推進計画策定が義務付けられたこともあり、また「オープン&ビッグデータ活用・地方創生推進機構」等の活動にもより、一応全都道府県でサイトが立ち上げられています(左図のように全都道府県にサイトが設置)。

市町村では、推進計画の策定は努力義務にとどまっていますが、鯖江市横浜市などがいち早くポータルサイトを立ち上げました。
2020年までに地方公共団体のオープンデータ取組率を100%にすることを目標としていましたが、2019年9月17日現在で37%(652/1,788自治体)に留まっています。

3.民間との連携

様々な事業体や地方自治体の利活用事例やアクティビティは、「オープンデータ100」として、政府CIOポータルに掲載されています。(2020年5月現在、事例64、アクティビティ6)

こうした取組みを推進していくために、シビックテック(Civic Tech=市民+テクノロジー)という、市民自身がテクノロジーを活用して社会や地域の課題解決を目指す、一種の運動が進められています。Code for JapanやCode for XX(XXは事業者や自治体等の名称)という活動により、行政・市民・企業の三者による地域づくりへの試みが各地にて行われています。

より詳しく知りたい方は下記をご覧ください。
地方におけるオープンデータの取組状況について」(2019.10.16)内閣官房情報通信技術総合戦略室
オープンデータを活用したアプリケーション等に関する調査研究報告書」(2019.06.21)

4.新型コロナウイルス対策とオープンデータ

今回の新型コロナ対策として、東京都でいち早く(3月3日)「新型コロナウイルス感染症対策サイト」(下図)がシビックテックによりオープンソースとして立ち上げられ、その後全国80サイトに波及しているそうです。

内閣官房IT総合戦略室、総務省、経産省は3月9日、新型コロナウイルス感染症対策にまつわるテレワークやeラーニングなどの支援サービスを無償/期間限定で提供する情報をまとめたWebサイト「#民間支援情報ナビ/VS COVID-19」を公開しました。企業やシビックテック各団体と連携し、オープンデータを活用した情報検索サイトが構築され、各種支援サービスの検索が可能となっています。

また、緊急事態宣言発令にあたって、病床数不足が挙げられていましたが、全国の病床の使用率を一覧化したダッシュボードも公開されています。これも鯖江市のシビックテック Code for Sabaeの福野泰介さんらにより開発されています。
行政側で公開されているデータは、まだまだPDF等の機械に判読不能の「一つ星」データですが、これをより機械判読性を高めたデータ形式で公開できるよう促すべく、シビックテックの有志が協同して「オープンデータ項目定義書」を作成したりという動きも出てきています。

これに関する総務省の資料は下記を参照してください。
新型コロナウイルス感染症対策サイトのためのデータ公開について(2020.03.21)

5.所感

上記のように、新型コロナウイルス問題をきっかけとして、オープンデータに関しても様々な試みが行われています。日本各地で民間と連携して色々な取組みが行われていることを知り、その進展に期待を持ちたいと思いました。ただし、取組み事態は結構なのですが、今回顕わになってきたのは、ITインフラに関する様々な脆弱性です。
 いちいち上げると情けなくなってくるのでそれは止めますが、根本的には、データ利活用の仕組みや考え方が根付いていないことが大きな原因の一つのように思われます。昨今DX(Digital Transformation)が叫ばれていますが、個人的には、デジタルインフラの大きな中心の一つはデータインフラであり、ITに係る全ての関係者にデータリテラシーが求められているのではないかと思っています。
 今こそ、ラジカルにデータマネジメントを熟慮し実現していかなければならない時代だと痛感されます。

以上

低品質データのロスは国家予算を超える!?

データ量は年間20億バイト!

DMBOKではいくつか数字の事例を用いて事象を説明することがある。つい読み流してしまうが、極端な例もある。

DMBOK第1版では、「1.1 データ:エンタープライズ資産」に以下の記述がある。
「カリフォルニア大学バークレー校の研究者達は、世界では毎年10億バイトから20億バイトのデータが生成されていると試算されており、情報の海で溺れそうになることも珍しくない」
20億か、大変だ〜。と一瞬思うが20億バイトは2GBである。これなら世界で1年ではなく、私のPCで1日に生成することもある量である。ネット検索して出典*1を見つけたが、そこにも同じ記述があったので、DAMAのミスではなさそうだ。それにしても 20億バイトは何かの勘違いか?
なお、出典*2によるとDMBOK 第1版が発売された2009年の世界のデータ量は800Exaバイトとあり桁が11個も違う。また出典*3のように2025年には、175Zettaバイトという予想もあるようだ。

低品質データの損失は300兆円以上!

DMBOK第2版の第1章の「2.5.3データ品質」には以下の記述がある。
「IBMは米国において低品質データのために費やしたコストは2016年で3.1兆ドルであったと推定している」
それは大きな損失だなあ〜。と一瞬思うが3.1兆ドルは300兆円以上である。300兆円と言えば国家予算並みではないかと思い、その2016年の国家予算(歳入)を調べてみた。出典*4によると
1位 米国 5.7兆ドル
2位 中国 3.2兆ドル
3位 日本 1.7兆ドル
とのことだ。米国の低品質データの損失は国家予算の半分以上! IBMも随分極端な推定をしたものだ、と思いながら一応調べてみたところ、IBMはとあるコンサルティングファームの推定(出典*5)を引用して、好んでこの値を使っているだけで、IBM自身で推定したものではないようだ。いずれにせよ 3.1兆ドルというのはちょっと大げさではないだろうか?
もっとも、低品質データの損失を正確に見積もることは、相当困難であろう。多くの論文等(出典*6)で「低品質データの損失により、収益の10%以上を失う可能性がある (Redman 2001)」というのを引用しているが、私としてはこちらの方がまだ納得できる気がする。

すいません、データ管理と直接関係のない話題となってしまいましたが、DMBOKも注意深く読んでみると色んな発見があるものだということがわかった、ということで今回はお許しください。

出典1
https://www.coursehero.com/file/p1bd5g3/Data-needs-to-be-thoughtfully-managed-because-it-controls-the-entire-life-of/

出典2
https://www.researchgate.net/figure/Global-growth-trend-of-data-volume-2006-2020-based-on-The-digital-universe-in-2020_fig1_274233315

出典3
https://www.forbes.com/sites/tomcoughlin/2018/11/27/175-zettabytes-by-2025/#62fb86165459

出典4
https://4knn.tv/government-budgets-by-country/

出典5
https://www.edq.com/blog/data-quality-failures-cost-us-3tn-a-year/

出典6
https://www.researchgate.net/publication/281269036_Classifying_costs_and_effects_of_poor_Data_Quality_-_examples_and_discussion など多数

データガバナンスとデータマネジメント

 ガバナンスが「統治」とか「統制」の意味を持つので例えば個人情報の扱いだとか、国、通貨等の標準コードの使用とかについてのルールを守らせることをガバナンスを効かせるという言い方をする。データガバナンスについて書かれたものには、データをマネジメントすることについて書かれたものも多く、ガバナンスに必要な要素が分かりにくくなっている。DMBOK2を見てみよう。この二つの言葉は以下のように表されている。

実際にデータに触れているのは?

 データガバナンスとは「正しいことを行う(Do the right things)」ことであり、データマネジメントとは「正しくことを行う(Do things right)」ことである(Ladley, 2012)。p607

 監査人は財務プロセスを統制するが実際には財務管理をしていないのと同様に、データガバナンスはデータが適切にマネジメントされるようにすることであって、データマネジメントを直接実施するわけではない。(図15参照)。p99

 データガバナンス:データを適切にマネジメントさせること

 データマネジメント:ゴールに到達するためにデータを管理すること p100

実際にデータを管理しているのはデータマネジメント側である。

データガバナンスは何故必要か

 正式なデータマネジメント機能を持っているかどうかにかかわらず、組織というものはデータに関する何らかの意思決定をしている。正式なデータガバナンス・プログラムが導入されれば、より明確な意図のもとに職務権限と統制を行使できるようになる。p94

データガバナンスは現場で行われているデータマネジメントを、組織の正式な取組に引き上げる。

データを資産として管理するための原則、ポリシー、プロセス、フレームワーク、評価指標を提供し、組織の各階層レベルでデータマネジメントプログラムを牽引する。 p98

 データアナリティクスからビジネスの価値を得る取組を見出したり、デジタルトランスフォーメーションに対応していくためには、その土台としてDAMAホイールに記載されている領域を中心としたデータマネジメントの実践が前提となる。実際行われてはいるが組織間でばらつきのあるデータマネジメントの取組みを一定のレベルまで引き上げ、さらにビジネスの目的に沿うレベルまで到達するには地道な取り組みと時間が必要だ。この取り組みをトップがコミットして組織横断で進めることがデータガバナンスである。

 DMBOK2では第3章でデータガバナンスについて包括的にまとめ、各章の後半ではそのデータマネジメント領域でのガバナンスの取組みに触れている。この総体がデータガバナンスということになる。ちょっとまとめづらい構成になっているけど第3章に加え、取り組み優先順位の高いデータマネジメント領域の章を合わせて是非読み進んでいただければと思います!