MDMとデータ・ガバナンスの動向(7) 〜 データ・ガバナンス(DG)方法論の提言②
伊阪コンサルティング事務所 伊阪哲雄
スニール・ソワールのDG方法論モデル(IBMが提唱するDG統合プロセス)について本稿にでは前回の続き、スニール・ソワールのDG方法論(IBM DG統合プロセス)ステップ概要を記述する。
6.スニール・ソワールのDG方法論(IBM DG統合プロセス)ステップ概要
0)啓発
データ管理に関わる社内関係者、即ち、関連役員、業務部門、IT部門、CDO、データスチワードなどのキーマンを対象に、以下の項目につていの問題提起と啓発活動を行う。
①同業先進企業のDG導入状況と効果
②データ管理に関する発生している問題・課題
③上記問題・課題に関わる対処に消耗される無駄な時間とその解消により予測される効果・効率
④広く企業経営の視点からの統合的ガバナンス(コーポレート・ガバナンス)の必要性
⑤コーポレート・ガバナンスの中核であるDG導入の意義と価値
⑥その他
実際には役員レベルから開始し、徐々に下位の部門に展開する。容易な仕事ではないが、忍耐強く、全社的な合意形成のために継続する必要ある。社内的にDG意識が醸成されるまで、一回/年の実施が望ましい。また新入社員および役職昇進者向けに年度初めなどに研修をすべきである。社内人材で啓発活動は大変難しいので、原則的にはD Gに詳しいコンサルタントの助けを借りるべきである。
1)必須ステップ：業務問題の定義
業務遂行上の問題をあらかじめ定義し、その問題を解決するために、どのようなDGを実施するか、その取り組み範囲を決めなければならない。DGへの取り組みに失敗するのは、業務問題の特定が不十分であった場合であることが非常に多い。業務問題は各業種に固有なものと、あらゆる組織に関わるものに大別される。例えば製造業においては「正確な部品表データベースの確立」、小売業においては「顧客データベースの整備と利用」が問題になる。一方、「失敗プロジェクトの監査」や「リスク管理のためにデータ品質を改善」といった問題もある。業務問題の定義や取り組む範囲の決定および変更は当然のことながら、業務部門が関与すべき事項である。
2)必要ステップ：役員支援者の確保
DGの実施においてスポンサーの確保は必須である。中核となる業務部門の担当役員や責任者、あるいは情報システム部門の担当役員や責任者から、DGの実施に向けた投資を確約してもらわなければならない。
スポンサーの確保は容易ではないが、業務の事例を引き合いに出し、そこにDGが短期的に効果があると説明、取り組みの価値を認めてもらうことである。例えば、「顧客データベースの品質」が問題であるなら、DGの一環として実際される顧客世帯名寄せなどに焦点を当てて現実的な効果を示し、説得を試みる。DGは長期の取り組みであるが、始めるためにはスポンサー候補を納得させる分かりやすい説明をしなければならない。スポンサーを確保するとともに、DGに関する責任者の任命も欠かせない。どのような人を責任者にするかについては、企業や団体によって変わってくる。中核となる事業部門長が兼務する場合もあれば、CIO（最高情報責任者）が兼務することもある。金融機関ではCRO（最高リスク責任者）ないし、直属の部下が担当することもある。いずれにせよ、企業や団体のデータ責任者にはDGの取り組みについて意思決定や変更ができる権限を与えるべきである。
3)必要ステップ：成熟度評価の実施
DGの成熟度を評価し、その結果に基づいて本番の取り組む内容の決定を考慮した提案になっている必要がある。成熟度を評価するのは、何にどのように取り組んでいくべきか、その目安を見出すためである。
「なるほど顧客世帯の名寄せは必要だ。投資しよう。」とスポンサーが決めてくれたからといって、名寄せにだけ注目した取り組みをしようとしても、なかなかうまくいかない。DGは「人・プロセス・技術のオーケストレーション」である。どんな楽団員（関係者や担当者）がいて、それぞれの演奏能力（データに関するスキル）がどうなのかを知っておかないと演奏会を開くことはできない。IBMDG統合プロセスにおいては、DGの成熟度モデルが定義されており、組織の成熟度に影響を与える項目が11カテゴリーに抽出されている（図1）。DGの狙いは業務に貢献し「価値創造」をすることと、「リスク管理」である。そうした成果をもたらす中核の取り組みとして「データ品質管理」「情報ライフサイクル管理」「情報セキュリティとプライバシー」があり、さらにこれらを支援する「データ・アーキテクチャ」「類別とメタデータ」「監査情報記録と報告」といった取り組みがある。以上の項目は主にプロセスと技術に関わるものだが、成果をもたらすもの（イネイブラー）として、「組織構造と気付き」「方針」「スチュワードシップ」を忘れてはならない。DG方針を立て、組織を組立て、データスチュワードと呼ばれる担当者を任命して、ようやく取り組みを進めることが可能になる。
多様な成熟モデルが存在するが、表1の五段階モデルを紹介する。
| レベル | DG管理状態 |
| 成熟度1 初期 | プロセスは通常場当たり的であり環境は不安定である。 むしろ証明されたプロセスの利用より、成功は組織内での個人の能力ないし適性を反映している。 組織は利用できる製品とサービスをしばしば生成する一方、予算とプロジェクト・スケジュールの超過が頻繁に発生する。 |
| 成熟度2 管理 | プロジェクトは繰り返し順調に遂行可能である。 組織内の全プロセスに対してプロセスが繰り返されない。基本的なプロジェクト管理はコストとスケジュールの追跡を支援できる。 プロジェクト実施が順調に言っている場合、プロジェクトは文書化された計画に従い実行され管理される。 コストと見積り時間を超過する危険を内包する。 |
| 成熟度3 定義完了 | 組織の標準プロセス群は、組織横断的に一貫性の確立のために活用される。 プロジェクトについての標準とプロセス記述と手続は、特別なプロジェクトないし組織の部門に合うように、組織の標準プロセス群から個別に適用される。 |
| 成熟度4 量的管理 | 組織はプロセスと維持の両方について量的品質のゴールを設定する。 選択された副プロセスは、全体のプロセス実行に極めて貢献し、統計的で他の計量的技術を利用で制御される。 |
| 成熟度5 最適化 | 組織についての量的プロセス改善目的が手堅く確立され、業務目的の変更を反映さるために継続的に改定されることになり、プロセス改善管理の基準として活用される。 |
表1.データ管理成熟度モデル
図2に示す通り11種のDG成熟度アセスメント項目が選定されている。特長的な点は現状を公平に把握し、一年ないし最大一年半で実現可能な目標設定を行い、そのためのギャップ分析の基礎資料にすることが目的である。
図2. データ・ガバナンス成熟度アセスメントの事例
4)必要ステップ：全体ロードマップの作成
11アセスメント項目に関する現状から望ましい将来状態へ橋渡しをする実現可能で価値のあるロードマップを作ることができる（図2）。このアプローチは面倒に見えるかもしれないが、DGの取り組みにあたっては、短期間で成果を出すとともに、中長期にわたって組織に貢献していく体制を作ることが欠かせない。11アセスメント項目についてのロードマップは、こうした包括的な取り組みを進めるためのものである。
5)必要ステップ：組織構造の原案立案
DGのオペレーションを担う組織の構造を検討する。米国では過去5年以上の経験から、DG組織は3階層形式が最も機能すると指摘されている。最上位層はDG委員会で、 重要な機能的かつ業務リーダーから構成され、そのリーダーは大企業資産としてデータを信頼している。第二層はDG作業グループで、そのグループは非常に頻繫にミーティングを持つ中間管理者から構成される。第三層はデータスチワード職務コミュニティから構成され、日々のデータ品質に対し責任を持つ。3階層形式の一例を第5回の「7.DG、DGPOとデータスチュワード組織事例」で示した図を参照頂きたい。
6)必要ステップ：製品ロードマップ作成と中核DGツール群整備
図3に示すようなDGソフトウェア・ツール・モデル構造図をスニール・ソワールが提唱している。3)ステップで述べた「人・プロセス・技術のオーケストレーション」の思想をベースに全体ロードマップに従い、最初に担当する人材を想定し、次にDG製品ロードマップを作成する。投入可能な人材スキルとDGツールは密接な関係にあり、双方を十分に考慮し、DG製品ロードマップを作成する。留意点としては、例えば既に導入されているETL製品がDG製品として活用できることもあり、導入済の製品と機能を注意深く調べるべきである。当然、DG製品は決して安価ではないため、自社に必要な機能を考慮し、手組で対処する場合も十分存在する。
図3の1.から8.の中核DGツールと9.から14.の広義DGツールとに分類できる。本ステップでは中核DGツールの整備(選定と導入)を行う。理由は以降のステップを実行する際には各種ソフトウェア・ツールが整備状況が作業効率に大きな影響を与えるためである。
図3. データ・ガバナンス・ソフトウェア・ツール・モデル構造図
各カテゴリーのソフトウェアの機能概要と代表的ベンダーは表1.に示す通りである。
| カテゴリー | 機能概要 | 代表的ベンダー*(ABC順) | |
| 中 核 デ ｜ タ ・ ガ バ ナ ン ス ・ ツ ｜ ル | 1)データ統合 | 3種の技術(大量データ移動/データ複製/データの見える化) | IBM, Infomatica, Inforteria, SAP, SAS, Talend |
| 2)データ・プロファイリング | データを理解するプロセスで、システム内の所在と他のデータとの関係の明確化する機能 | Collibra, Global ID, IBM, Infomatica, SAP, SAS, Syncsort, Talend | |
| 3)データ品質管理(DQM) | データの品質と完全性を測定し、改善する方法並びに名寄せを含む統制機能 | Global ID, IBM, Infomatica, SAP, SAS, Syncsort, Talend | |
| 4)データ辞書(業務用語集) | 重要用語のリポジ通りで業務とIT横断し共通の定義をまとめる辞書機能 | ASG, Collibra, IBM, Infomatica, Orchestra Networks, SAP, SAS | |
| 5)メタデータ管理 | 名前、場所、値、桁数、形式などの関係するデータの特徴を記述されたデータ管理機能 | ASG, Collibra, Global ID, IBM, Infomatica, SAP, SAS | |
| 6)情報方針管理 | データ管理実務を当局などからの厳しい監視に従うための情報方針管理機能 | Collibra | |
| 7)マスターデータ管理:EAIツール/ MDM/ ETL | 複数のデータドメインを統合し、A single version of truth(事実に従うユニークなバージョン)を確立する機能 | IBM, Infomatica, Inforteria, Oracle, Orchestra Networks, SAP, SAS, Talend | |
| 8)データ管理(RDM) | データでシステム共通に参照されるデータの管理 | Collibra, IBM, Infomatica, Orchestra Networks, SAS | |
| 広 義 のデ ｜ タ ・ ガバナ ン ス ・ ツ ｜ル | 9)データ・モデリング | 企業内データモデルの作成と管理機能 | IBM, Orchestra Networks, SAP |
| 10)データウェアハウス・データマート | データウェアハウスとデータマート | EMC, HP, IBM, Oracle, SAP, Teradata | |
| 11)解析・レポーティング | データの解析とレポーティングを支援する機能 | ASG, Infomatica, Inforteria, SAP, SAS, Tableau | |
| 12)業務処理管理(BPM） | 業務処理を調整する全体論的な管理機能 | Collibra, IBM, Infomatica | |
| 13)データ・セキュリティとプライバシー | データ・セキュリティとプライバシー確保、具体的にはデータ・マスキング/データ暗号化/データのトークン化**/データ監視機能 | IBM, Infomatica | |
| 14)情報ライフサイクル管理 | 情報の作成から廃棄に至るプロセスの一連を管理する機能 | Collibra, IBM, Infomatica, SAP |
*：北米と西欧市場のベンダーで、国内参入ないし日本語化されていないベンダーも含む。
**:トークン化(Tokenization)とは機密データを差しさわりのないデータに置き換え、必要に応じて機密データに戻すことができる機能
表2.中核および広義のDGツール
各ソフトウェアについては問い合わせを頂ければ、回答するので、遠慮なくお問い合わせをお願いしたい。
7)必要ステップ：データ辞書策定とデータ理解
業務用語の効果的管理は、同一記述言語で組織を貫通する言葉の定着の確実性を担保できる。データ辞書ないし業務用語は重要な専門用語の定義リポジ通りであり、組織の技術と業務サイドの間の一貫性と合意を得るために用いられる。事例としては、
❏どのように顧客を定義するか？
❏顧客のだれが購入したか？
❏だれが購入を検討したか？
❏過去の社員がまだなお社員としてカテゴリーされているか？
❏パートナ通りセーラは同義か？
❏ディーラーとディス通りビューターは同義か？
これらの疑問は共通データ辞書を構築することにより回答可能となる。一度共通データ辞書が導入されると、業務専門用語はメタデータを介して、技術的専門用語に結びつき、また組織は一つの共通理解を持つことを確実するために、データ辞書は組織間の横断を可能となる基盤になる。
今日では単独の適用プログラムはほとんど無い。むしろ、ソフトウェアが扱うメタデータは、企業内に分散され、多少統合されるか、少なくとも互いに関係を持っている業務とデータベースと共に個別システムないし統合システムからなっている。ストレージに対する業務エンティティの断片化により、リレーショナル・データベース・モデルは実際には事態を悪化させているが、いかに全てが関係しているのか？DGチームは企業内を横断する重要なデータ関係を発見する必要がある。情報システム内の機密データの所在と同様に、データ発見は単純で見出すのが難しい関係を含むことも多い。
8)必要ステップ：メタデータ・リポジ通りの作成
メタデータはデータについてのデータである。①データ技術的名称、②業務名称、③場所、④認知された重要性、⑤大企業内の他のデータ遺産に対する関係の五者のようなメタデータは、全データの特性に関する情報である。DGプログラムは、発見フェーズでデータ辞書と多くの技術的メタデータからの多様な業務メタデータを生成する。多様なプロジェクト間で共有され機能させるため、このメタデータをリポジ通りに収納され、継続的に管理される必要がある。
9)必要ステップ：広義のDGツール整備
「6)必要ステップ：製品ロードマップ作成と中核DGツール群整備」で検討された製品ロードマップに従い、
本ステップでは図3に示す9.から14.の広義DGツールを表2.を参考に吟味し、その整備(選定と導入)を行う。各カテゴリーのソフトウェアの機能概要と代表的ベンダーは表2.に示す通りである。
10)必要ステップ：評価基準の定義
DGは経過を測定・追跡する強固な評価基準を有する必要がある。DGチームは何時、何を測定し、効率改善を行うべきかを評価しなければならない。結果としてDGチームは、プログラムの現状パフォーマンスを測定するいくつかの重要な重要業績評価指標(KPI: Key Performance Indicators)を選定しなければならない。例えば、銀行では業種別全体的信用リスクのアセスメントを要望している。このような場合、DGプログラムは、KPIとして、リスク管理情報品質の追跡のために、ヌルの標準業界分類コードの割合を選択する場合もある。
上記は初期に要求される9ステップである。少なくとも4個の追加ステップ(マスターDGと解析ガバナンス・セキュリティとプライバシーと情報ライフサイクル・ガバナンス の4者)を選択する必要がある。
マスターDGの下位のステップが求められる業務を介して処理される付加ステップをDGプロジェクトにより暫時選定する。短期的なDG成熟度評価とロードマップの定義を行う必要がある。短期的効果を確実にするために業務とITを同調するDG組織のいくつかのレベルがあるべきである。特にもし「顧客」はマスターデータ・ドメインの一つであれば、「顧客」のような業務専門用語は定義するのは自明である。DG組織はデータ・ソースと決定的なデータ・エレメントの存在を理解する必要がある。発見プロセスからの業務定義と技術的メタデータは、メタデータ・リポジ通り内に取り込む必要がある。最終的にDG組織は、顧客重複排除とかマスターDGプログラムの現状効率測定などのKPIを確立する必要がある。
DGに対し選択された追加トラックをベースに要求されるステップの重点レベルは、変化するであろう。事例として、追加トラックないし選択されたトラックをベースにステップ「7)必要ステップ：データ辞書策定とデータ理解」が別々に以下に適用されるかをレビューしてみよう。マスターDGトラックは標的に対するソースのマッピングを容易にする重要なデータ・エレメントの理解を含むであろう。解析ガバナンス・トラックは、キーレポートと重要なデータ・エレメント間の関係の理解を含むであろう。セキュリティとプライバシ・トラックは、細心の注意を要するデータの収納場所の理解を含むであろう。最終的には情報ライフサイクル・ガバナンス・トラックは、プロジェクトの遂行についての先駆者として、顧客のような業務オブジェクトの位置付けについて大企業での理解を可能にするであろう。
後続の章でこれらのトピックスの深く詳細に討議する。それで本章の残り部分でいくつかの事例疑問と潜在的中心領域をカバーする。IBMDG統合プロセス内での付加トラックの短い記述は以下の通りである。
11)追加ステップ：マスターデータの統制
大企業内の最も価値のある情報—顧客と製品と材料とベンダーと仕入先について業務の決定的なデータ—はマスターデータとして共通に知られている。その重要性にも関わらずマスターデータは、大企業の隅から隅までの業務プロセスとシステムと適用業務を横断的にしばしば複製され、ばらまかられる。業務リーダーはマスターデータ品質の管理による業務目的の達成に対する原則と方針とプロセスと業務ルールと評価基準を定義し、それらのマスターデータの統制は進行中の実習である。
マスターデータについての取り組みは大半の組織を混乱させる傾向にあるが、課題の確信的な原因と解決する業務支援者の正しい水準を得るのは容易ではない。結果としてマスターデータ・イニシアティブに関する投資の正当化は重要である。例えば、同一世帯に複数の郵送を送付する銀行のような組織の考察してみると、世帯のシングル・ビューを作るために銀行の顧客データ をクレンジングし、この銀行は短期的な投資回収を確立できる。DGプログラムの大多数が、データスチワード職務とデータ品質とマスターデータとコンプライアンスの周辺の課題を処理するのが肝心な点である。
12)追加ステップ：解析の統制
競合企業観察のために大企業はデータウェアハウスの構築に莫大な投資をしてきている。しかしながらこれらの投資は常に結果をもたらしてはきていない。結果として、業務は解析の投資を益々吟味している。解析基盤についての投資と業務ユーザーの上手く整合するための方針と手続の設定として、“解析ガバナンス”の付加ステップと定義する。DG組織に以下の疑問を問いかける必要がある。
❏各業務領域に何人のデータ利用者がいるか？
❏各業務領域にいくつのレポートを作成するか？
❏これらのレポートからユーザーは価値を引き出しているか？
❏一ケ゚月当たりいくつのレポートの実行をしているか？
❏新レポートを作成するためにどれくらいの時間を要するか？
❏新レポートを作成するためにどれくらいの費用を必要とするか？
❏ユーザーに自身でレポートを作成できるように育成しているか？
多くの組織はユーザーを教育し、ビジネス・インテリジェンスを啓発し、レポートを開発するためにビジネス・インテリジェンス・コンプテンシ・センタ(Business Intelligence Competency Center：BICC)の設置を必要としている。
13)追加ステップ：セキュリティとプライバシーの管理
国内ではまだなじみが余りない職制であるが、CISO（最高情報セキュリティ責任者）ないし相当する責任者を任命し、プライバシーやセキュリティを管理していく場合、DGが当然求められる。米国の医療機関は健康情報のプライバシーとセキュリティを守る規制を遵守しなければならない。DGのチームはその際に重要な役を実行する。例えば、患者のカルテが混ざらないようにする、同一患者の重複カルテを排除する、といったことを確実に成し遂げる方針と手続を用意し、実行し、管理しなければならない。マイナンバー制度の導入が始まったこともあり、日本企業にとっても重要課題である。次のような質問を投げかける必要があるだろう。
❏細心の注意を要するデータはどこにあるか？
❏プライバシー規制に沿うための非生産環境(開発とテストとトレーニング)における組織は組織の細心の注意を要するデータにマスクをかけているか？
❏給与と顧客リストのような個人データへのアクセスから、データベース監査のコントロールはDBAのような特権ユーザーがアクセスするのを妨げについて適切な状態にあるか？
14)追加ステップ：情報ライフサイクルの統制
典型的な大企業内ではデータの80%以上の非構造コンテンツが作られる。DGから情報ガバナンスに組織が移行する時、組織はこの非構造コンテンツのガバナンスを考慮から開始する。
情報のライフサイクルは作成と既存の廃棄から排除によるデータ創造と廃止で開始される。DG組織情報ライフサイクルについての以下の課題と対処しなければならない。
❏デジタル化された紙のドキュメントについてのどのような方針であるか？
❏紙のドキュメントと電子ドキュメントと電子メールの記録管理方針は何か？(言い換えれば、記録としてどの記録を維持し、その管理期間はどれくらいか？)
❏記憶保存費用を削減と効率改善のために、いかに構造データを管理しているか？
❏方針と管理の共通のフレームワークの基で構造と非構造データを共に適正な管理をしているか？
これらの付加トラックの後、DG統合プロセス最後にもう一つステップがある。
15)必要ステップ：結果の測定
評価基準を常に監視し、DG組織は継続的改善を確実にしなければならない。ステップ10では、DGチームが評価基準を設定する。このステップではDGチームがITと業務からの上級利害関係者にこれらの評価基準に対しての進捗のレポートを作成する。全体のDG統合プロセスは継続的な繰り返しを実施する必要がある。本プロセスにおいて結果を測定し、DGプログラムの継続的な保証について役員支援者にフィードバックする必要がある。
7.データ・ガバナンス導入・実施における関係者と機能分担
DG実務はデータスチワードにより行われる。David Plotkin著の「Data Stewardship」(総ページ数223)に極めて詳細かつ明快にデータスチワード機能(スキル、求められる機能・役割など)が記載されている。同書の精読をお勧めする。
文字数制約から詳細には言及できないが、データ統合、MDM、DGなどの推進、ソフトウェア選定とSI事業者選定などに関して、具体的な関心がある方は、遠慮なく問い合わせ(isaka@isaka.com)をお願いしたい。
参考文献：
日経コンピュータ2013.12.12日号と26日号
Data Governance Tools, Sunil Soares著, 2015, MC Press Online LLC
Data Stewardship、David Plotkin著, 2014,Morgan Kaufmann Publishers
Copyright©2017 Isaka Consulting Office, All rights reserved.
─ 伊阪哲雄プロフィール ──────────────────────
データ・マネジメントを専門とするITコンサルタント。1970年に外資系大手コンピュータ・メーカーに入社して以来、一貫してデータ・モデリング/設計やデータ・クレンジング、データ統合、マスターデータ管理、データ・ガバナンス、人材育成に関わる支援を行ってきた。特に通信業界、医薬業界や、金融業界のデータ・マネジメントに詳しい。米国のデータ管理系コンサルタントと幅広い交友関係があり、米国など海外の事情にも通じ、例えば米MDM Instituteが主催するカンファレンスに頻繁に参加している。