標準化の進め方について

前回の私のブログ「標準の作成と定着化について」では、会社や組織にデータマネジメント等を推進、定着化させるための一つの手段として、その専門領域の知識体系(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ファイルや設計書、モデリングツール等からデータ項目情報を抽出・とりまとめ、データ項目の定義を整理していく。
抽出は手動で実施することもあれば、ツールを導入し半自動的に集約をかける仕組みを構築する場合もある。

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

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

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

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

・スコープの絞り込み

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データ品質管理の具体的な成果物

昨今、データ利活用によって新たな価値を創出することや、コロナ禍で対面での業務が難しくなりアフターコロナ、ウィズコロナのデジタル化された働き方が求められる中で、データ品質=「データが使える状態であること」がますます重要になってきています。

一方で、DMBOKでは、幅広く考え方やアクティビティが記載されているものの、成果物サンプルが少ないため、具体的なイメージが掴みづらい…という声を聞くことがあります。

データモデルなど、手法が確立している(統一されているわけではなくとも)分野はまだ良いとしても、一般的なシステム開発/運用で、あまり馴染みのないデータ品質管理はなかなかイメージがつきづらい分野の一つです。

DAMA日本支部:第8分科会(データ品質に関する研究会)では、実際に手を動かす一助となることを目指して、DMBOKに沿って進めるならどういう成果物を作って行けばよいのか議論しており、2019年に、DMBOK1に基づいた成果物として、データ品質管理を進めるためのワークシートを完成しました。
※下記のリンク先で公開しているので、ご興味のある方は是非ダウンロードいただければと思います。

http://www.dama-japan.org/PublishedMaterials.html

ワークシートの内容についてはDAMA日本支部の会員には総会などでも報告・共有していますが、公開資料としてももう少し解説があるとよいかなと考えており、この場を借りて、少しワークシートの概要を紹介したいと思います。

DQワークシートの概要

ワークシートは4つのシートで構成されています。DMBOK1アクティビティとワークシートの対応関係は下図の通りです。

図:DMBOK1アクティビティとワークシートの対応関係

DMBOK1アクティビティを踏まえて、各シートで記載すべき項目を定義しています。各シートに項目説明がありますのでそちらを参照ください。各シートの概要は下記の通りです。

①ビジネスニーズ整理ワークシート
ビジネスニーズを5W1Hの観点で纏める。ここでは、対象となるデータセットの特定には踏み込まずビジネス視点で必要な情報とその情報に求められる品質要件を纏める。

②DQ管理対象検討ワークシート
具体的に対象データセットを決めて、実データを見た上で、データ品質管理対象を絞り込む。

③DQチェック精緻化ワークシート
データ品質のチェック方法を精緻化して、チェック結果が意図したものになるかビジネス部門とIT部門で確認・合意する。

④検査・レポート運用整備ワークシート
モニタリングとアラート検知時の運用方法を決める。

今後のブラッシュアップ

現在のワークシートVer.1.0はDMBOK1に沿ったものなので、今後は、DMBOK2に沿って、ワークシートをブラッシュアップしていこうとしています。

また、ワークシートを使ってみて、良かった点、改善点などありましたら、フィードバックいただけると嬉しいです。今後に活かしていきたいと思います。どうぞ宜しくお願い致します。

DAMA日本支部の課題と今後

このブログでは主にデータマネジメントについてのお話が多いのですが、今回は趣向を変えて、当DAMA日本支部の運営のお話をしようと思います。
このブログを読んでくださる会員をはじめとしたみなさんにも、是非この機会に当会の運営や課題について知っていただければと思っています。

日本支部の歩み

2020年7月現在、DAMA日本支部の会員数は現在121名で、法人の会員は13社になっています。
設立時の会員数は100名弱だったのですが、2014年をピークに年々減少し、2017年には75名程度まで減少していました。しかしその後、2代目会長の林さんの下、お試し会員の募集やDMBOK2の日本語版の発刊、DMBOK概説セミナー開催などの積極的な対策を取り、データ活用機運の高まりとともに会員数も回復してきました。
DMBOK2も早々に売り切れて増刷されるなど、今後もデータマネジメントへの関心が高まっていくと思われ、当会もサステナブルな組織運営基盤を作っていく必要があると考えています。

今は任意団体

データマネジメントを日本にも普及・定着させようという意図のもとで設立されたDAMA日本支部ですが、残念ながら未だに任意団体でしかなく、協賛や後援いただいているJDMC様やUMTP様のように一般社団法人やNPOではありません。
任意団体でもできることはたくさんありますし、当面の問題にはなっていないのですが、法人格を持っていないといろいろ不都合なこともありまするようです。
例えば、任意団体では法人としての銀行口座が作れないために会長名義で口座作成せざるを得ず、会長交代時には名義変更が必要になります。
その他にも商標登録しにくいとか、法人によっては任意団体では社内申請が行いにくいなどの弊害もあるようです。
理事会でも一般社団法人化を進めようという話になっていますが、素人が進めるには中々にハードルが高く、遅々として進められていないのが実情です。

これから

CDMPの日本での普及、DMBOK3の日本語化など、これからもパワーを要する課題は山積です。
これまでは、データマネジメントの普及に情熱や志のある現在理事のボランティアシップで支えられてきましたが、いつまでもそこに頼っていては先細りになりかねません。なんといっても理事は現在13名ですが、設立から10年近く経ち、50歳台未満は数名のみと高齢化が進んでいます(失笑) 。
また、広く参加していただくことを目的に当会は会費も低廉に抑えているので、年間予算も十分にあるわけではなく、人を雇って業務依頼するということも困難です。
こういった背景を含めて、待ったなしで今後の運営を検討し、サステナブルな組織にして、 データマネジメントを普及するための DAMA日本支部という組織を成長させていく仕組みが必要だと感じています。

運営を手伝ってあげようというご危篤な方、こうしたらいいのではというご意見のある方、管理担当(admin@dama-japan.org)まで、是非ご連絡をいただけたらと思います。お待ちしています。

アフターコロナ時代だからこそ高まるデータマネジメントの重要性

コロナは我々の行動スタイルを変えてしまった

新型コロナウィルスは、我々のビジネス上や日常生活上の行動を根底から覆してしまいました。ワクチンが開発された後であっても、「仕事をすること=オフィスに行くこと」ではなくなり、これまでのノーマルでは「何はなくとも、定期的にお客様へ訪問営業すること」でしたが、ニューノーマルでは「本当に重要な商談以外は対面ではなく、リモートで済ませたい」となるでしょう。また、「賑わって混雑しているお店でショッピングを楽しむ」というノーマルな日常生活が、ニューノーマルでは「何かあったら怖いので、できるだけ”密”を避けて短時間で済ませたい」という行動を取る人が必ず一定層は残ると思いませんか。

このように、我々の行動が“密”を避け、“疎”を求めるようになると、これまで企業が対人・対面(リアル)で当たり前のようにできていたことができなくなり、自社のお客様とのリレーションシップをよりオンラインで、つまりデータを通じて良好に維持し、他社に奪われないように強固にしなければならない、と気付くと思います。では、ひとたび目を転じて、自社のリアルおよびオンラインにおけるお一人おひとりのお客様とのタッチポイントで発生しているデータが現状どのようになっているか?

多くの企業では、自社の様々なシステムにお客様に関するデータが散在し、相互につながっていなかったり、いちいち個別のシステムの中のデータを調べなければどのような対応履歴があったかを把握できない、そんな状態になっていませんか。お客様やお客様が買ってくださった商品などに関わる基軸データが社内の様々なシステムに分散し、「つながっていないので、行動履歴がバラバラになってしまっている」、「整合性や精度に難があるので、信頼できない」、「社内のどのシステムにどのデータが存在し、それらがどのように連携しているのかが可視化できていない」といった現状に直面する会社がほとんどだと思います。

改めて、データマネジメントの重要性が否応なく高まる

これまでマーケティング、営業・販売、設計・製造、デリバリー、アフターサポートなど、個別部門の業務処理の「電子化」を目的として構築されてきたシステムの中のデータを活用しようとすると、それらを「“疎”を求める自社のお客様との関係性を良好に維持するために活用できる状態」に再編成し直すための取り組み、すなわち、全社的なデータマネジメントが必要不可欠となります。

「情報(データ)は、ヒト、モノ、カネと並ぶ第4の経営資源である」といわれて久しく、昨今では「データは次のオイル」などと喧伝されるようになりました。また、巷ではデジタルトランスフォーメンション(DX)、つまりデジタル(=データ)による自社の事業変革の必要性が叫ばれ、AIやIoTなどの情報技術の進化と浸透によりネットだけでなくリアルの世界でも、ヒトやモノのあらゆる動きが「行動データ」で取得していくことが可能になりましたが、いくら膨大な「行動データ」が取得できたとしても、それらが自社の大切なお客様や商品としっかりつながっていない限り、活用することは決してできません。

データを真のオイルに変えるためには、「それを活用可能な状態に精錬するためのプロセスや体制」や「自社内外のデータ資源の可視化と整備」が重要になることは論を待たず、お客様とのリアルな接点が「疎」に傾倒するアフターコロナ時代だからこそ、データマネジメントの重要さが改めて認識されるでしょう。視界不良な環境であればあるほど、正しいファクト(=データ)に基づいた意思決定を行うべきは、国においても企業においても変わらず、データマネジメントに真摯に向き合う企業、そうした経営者やリーダーがいる企業こそがアフターコロナ時代でもお客様への価値を弛まずに提供し続けられるものと確信します。

DAMA Japan 企画担当理事/株式会社リアライズ 代表取締役社長 大西 浩史

DAMA-JとJDMC

国内のデータマネジメントを推進する団体は、企業や企業のユーザ向け研究会を除いて、DAMA-JとJDMC(Japan Data Management Consortium)がある。JUAS(Japan Users  Association of Information Systems)の中にもデータマネジメントの研究会があるが、JUAS自体はデータマネジメントに特化した団体ではないので、ここではDAMA-JとJDMCについて述べる。

JDMCは2011年4月に設立され、現在9年目を迎え、会員数200を超える団体となっている。私はJDMC設立からJDMCの研究会活動他に参加しており、DAMA-Jでの活動より長く携わってきた。
近年、JDMCのメンバやデータマネジメントを勉強しようとするメンバから、DAMA-JとJDMCはどこが違って、どちらに参加した方がよいのかと相談を受ける機会が多い。私見になるが、DAMA-JとJDMCの違い(棲み分け)について、今回は述べていく。

DAMA-JはDAMA Internationalでの活動を日本で推進することが主な活動となる。具体的には、DMBOK(DATA MANAGEMNT BODY OF KNOWLEDGE)の普及が主要活動としてあげられる。また、毎年ADMC(Asian Data Management Conference)を1日のカンファレンスとして開催し、海外からのデータマネジメント有識者やDAMA-Iからメンバを招聘して海外の事例も含め紹介している。
まとめると、DMBOKの普及、海外からのデータマネジメント有識者を招いての講演の提供はDAMA-Jの主要活動であり、これはJDMCの活動にはない。

JDMCは、企業、行政機関、大学など広い範囲のデータマネジメントに関わるメンバが参画されている。JDMCが主催するデータマネジメント2019では、1日のカンファレンスに1000名を超える参加者があった。2020年はコロナ対策として、急遽Webによる開催に変更したが、2019年の参加者を超えるメンバが参加された。
JDMCでは、毎年、データマネジメントにおいて、他の模範となる活動を実践している企業・機関などの中から優秀なものを選定しデータマネジメント賞を送呈している。JDMCの定例セミナーで、データマネジメント賞を受賞した団体からの推進活動の内容も聞くことができる。
また、青山学院や横浜国立大学で、学生に向けたデータマネジメントに関する講義も各大学教授からの依頼により、JDMCの有志メンバが講師となって開催されている。

上記以外にJDMCの最大の特徴は、研究会活動の充実にあると思っている。「デジタルマーケティング」、「MDMとデータガバナンス」、「AIとIOT」など特化した分野での研究会活動があり、この他に私が所属する「データマネジメントの基礎と価値」の研究会では、研究会メンバで合宿も含めて多くの議論の時間を費やし、データマネジメント概説書(JDMC版)を作成し、発刊に至っている。
データマネジメントに関わるメンバ(初心者を含む)が抱える課題をできる範囲で共有し、メンバと議論して気づきを得る場を提供しているのが、JDMCの特徴と思う。

DAMA-Jは有識者が多く、データマネジメントの初心者には参加は敷居が高いという声をよく聞く。ある程度のデータマネジメントの知識がないと、また、DMBOKを読んでいないとDAMA-Jに個人会員として入るには躊躇われるという声である。

DAMA-Jでは、この声に応えるため、「DMBOKに関する研究会」も立ち上がり、各章を1回の研究会の中で説明と議論を行う場が提供されている。
また、DAMA-J会員以外にもDMBOKの紹介を行う機会やデータマネジメントの概説を行う機会が企画されている。

私見だが、データマネジメント推進するメンバは、DMBOK(現在はDMBOK2)を読んでおくことは、必須であると思う。日本語版も出ているので、まずは購入いただき、読んでいただきたい。ただ、600頁を超える大書であるので、重要ポイントなどの概説を聞いて、読み込んでいく支援をDAMA-Jとしてはさらに行っていく必要があると考えている。

冒頭の「DAMA-JとJDMCはどちらに参加した方がよいのか」という質問に答えるとDAMA-J、JDMCともに参加し、DAMA-JではDMBOKの知識の習得と海外のデータマネジメントの推進事例の把握、JDMCでは自分のデータマネジメントに関する悩みにあった研究会に参画し、メンバとの議論による気づきの発見を行っていただきたい。

今までは、DAMA-JとJDMCでの交流はあまりなかったが、今後は国内でのデータマネジメントの推進をさらに加速するために手を組みあうべきと思う。一つの例として思っているのは、JDMCでDAMA-JからDMBOKの紹介や講義が行えないかである。DAMA-JとJDMCが共存してその相乗効果をあげられるよう、微力ではあるが努力していきたい。

以上

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

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

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

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

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

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

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

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

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

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

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