標準化の進め方について

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

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

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

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

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

・スコープの絞り込み

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

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