Leverages データ戦略ブログ

インハウスデータ組織のあたまのなか

DMBOKに基づく「データマネジメント成熟度アセスメント」を実施してみた話

はじめに

こんにちは。レバレジーズのデータ戦略室の辰野です。いつの間にか5回目の投稿を迎えました。
今回は、私が2024年度上半期に注力した「DMBOKに基づくデータマネジメント成熟度アセスメントの実施」についてご紹介できればと思います。
レバレジーズでは初めての実施ということもありかなり苦労したので、これからデータマネジメント成熟度アセスメントを実施してみよう!と思われている方にとって、参考になれば幸いです。
※ベースとなるDMBOKに関する情報は、既に多くの記事が出ているかと思いますので本記事では割愛させていただきます

なぜやることになったのか

例えば、皆さまの周りでこんなことは起きていないでしょうか?
「テーブル定義書はあるけど、実際のテーブルと内容が違う…」
「この指標の定義を知りたいけど、どこを見ればいいのか分からない…」
「このツールの使い方がどこにまとまっているか分からない…」

悲しいことに、データ戦略室では頻繁に起きています。

これまでデータ戦略室では全社的なデータ活用を推進してきました。ですが、全社的に定められた共通認識およびルールがほとんどないため、このようなことが起きていました。
レバレジーズは事業の数が多く成長も速い環境であるため、事業毎に異なるデータを活用したビジネス課題の解決に注力してきたことが背景にあります。
さらに、その課題解決はルールがない状態でその時対応できる人が行っていることから、属人的な管理も多く発生してしまいました。
また、データマネジメントを専門的に行う組織はなく、データマネジメントにおいて「レバレジーズの現在地はどこか?」「理想形は何なのか?」と全員疑問に思っており、何から優先的に対応していくべきなのかの共通認識も取れてない状況でした。 そのため、事業の意思決定層から依頼される分析業務ばかりに時間を割き、データ戦略室内部で進めるべき課題に取り組む機会が少なくなっていました。
会社が大きくなるに伴いデータ活用者が増え続けている状況にも関わらず、このまま何もせず進んでいくと問題が起きることは明白であったため、データマネジメント成熟度アセスメントを実施して現状を把握し、ロードマップを引いてデータマネジメントを推進していくべきであるとの判断になり、プロジェクトとして発足することとなりました。

やったことと工夫した点

評価対象の絞り込み

最初に述べたように、レバレジーズでは初めての実施となり社内のノウハウがないため、再設計も考慮して今回は主要となる事業のみを対象として実施することにしました。
また、1つの事業の中でもサービスが分かれており、サービスごとにデータ活用度合いや情報を認識している担当者が異なるため、評価と今後の推進がしやすいように、さらにサービスごとで評価することにしました。

最初にやったこと

まずは、ベースとなるDMBOKと、DMBOKを要約した記事や他社の実施事例を読み込みました。
そこからWBSを作成し、プロジェクトを開始しました。

アセスメントの流れ

具体的なタスクと工夫した点

アセスメント内容の設計〜レベル判定までは、以下のように対応しました。

  1. データマネジメント領域ごとの評価物とレベルの基準を策定
    • DMBOKや解説記事にも11の領域ごとに評価物のイメージは記載されていますが、抽象的であるため、アセッサーが評価しやすいようにレバレジーズの実情に合わせて具体化する作業を行いました。
    • とはいえサービスや事業ごとで具体的に利用しているシステムやツールが異なったり、変動することもあるため、まずはベースとなる評価物を決め、そこからサービスごとに具体的なシステムやツール名に置き換えることにしました。
    • レベルの基準については、11の領域で共通となるベースの基準を定め、そこから各領域の評価物に当てはめ、レバレジーズ用に書き換えていきました。
      レベルの定義
  2. アセッサーの選定
    • どの組織までをアセッサーにするかは悩みましたが、組織の数が多く、広げすぎても評価したり策定したロードマップを遂行していくことが難しいと判断し、データ戦略室のメンバーのみに留めることにしました。
    • レバレジーズではデータエンジニアとデータアーキテクト、データアナリストの対応領域が一部跨っていたりするため、この評価物の責任範囲は誰になるか?をよく話し合い、アセッサーを決めていきました。
  3. レベルを判定するための質問を作成
    • 定めた各レベルの内容を判定するための質問を考えていきました。
    • 基本的に選択肢はあとで得点化しやすいように「はい・いいえ・わからない」のように段階的にし、また評価が終わってロードマップを策定した後にやるべきことを具体的にするために「はいと回答した人には対象物のリンクを入力させる」といった設計にしました。
    • 質問と選択肢のたたき案を考えて、プロジェクトメンバー内で話し合い、微調整していきました。
      質問と選択肢のイメージ
  4. アンケートの作成と実施
    • 何を使ってアンケートを行うか迷ったのですが、評価物や質問によって回答者にばらつきが出たことと、後で何か起きた時の修正しやすさ、結果の集計のしやすさ、またアセッサーの評価のしやすさを考えてスプレッドシートで行うことにしました。
    • アセッサーごとにタブを作成し、回答してほしい項目のみに色付けをするなどして、なるべくアセッサーに負担がかからないようにしました。
  5. レベルの判定定義を策定
    • アンケート実施中にレベルの判定定義を決めていきました。
    • 具体的な設計内容はこの後記載しますが、運用・保守性と他部署にも展開しやすいよう「簡単な計算式で出せる方法」を意識しました。
  6. 集計とレベル判定
    • 質問と選択肢ごとに点数化するためのマスタを作っておき、回答を集約して得点を出しました。
    • ここもレベルの判定定義の設計の一部であるため、併せて詳細を記載します。
  7. データ戦略室へ結果を共有
    • スプレッドシートで回答してもらったこともあり、スプレッドシートで簡単に可視化しました。
    • 「DMBOKピラミッド」*1を参考にフェーズごとでカテゴライズすることで「本来先にできていないといけないことが、どれくらいの状態なのか」を分かりやすくしました。

*1 参考|「What is Data Management, actually? – DAMA-DMBOK Framework」2024/10/31

判定結果イメージ

レベル判定定義の詳細

レベル判定の方法としては、質問ごとに得点対象となるレベルを振り分け、そこから低・中・高で点数がつく形にしました。
今見ると簡易化できそうなところは多々ありますが、シミュレーション時にイメージ通りの結果が出たため、今回の定義で判定することにしました。

設計の詳細は下記です。

  • 前提
    • レベル0と、レベル1~5は別で判定する
    • レベル0は、過半数がYesと回答していることをクリア条件とする
    • レベル1~5は、低・中・高(ランクと呼ぶ)で点数をつけて判定する
      • 実質、レベル1~4の高は次レベルの低とイコールで、レベル5の高は最高地点とする
    • 手前のレベルをクリアして初めて、次のレベルの回答の得点が上乗せされる
  • 設計
    • 配点マスタの作成
      • すべての質問×レベル×ランクごとで、「満たしている」と判断したマスに1フラグがつく
      • 選択肢ごとに、そのレベル×ランク内で1フラグがつく場合、レベル内の下のランクにも1フラグをつける
      • 低・中・高では、実質それぞれ、0点・0.5点・1点の配点となる
        配点マスタイメージ
  • 処理1 - 質問×レベル×ランクごとの得点と回答者数の算出
    • その質問を回答する可能性のあった人数と、選択肢ごとの実際の回答数を取得する
    • 質問×レベル×ランクごとで、実際の得点を出す
      処理1イメージ
  • 処理2 - 判定点の算出
    • 領域×レベルごとで、実際の合計と満点だった場合の得点を出し、レベルごとにランクを判定する
      • レベル0では、0.5点以下つまり半数以上が1点の回答をしていない場合は一律レベル0と判定し、レベル1~4では1点=高、0.5点以下=低、その他=中とランク付けする
        処理2イメージ
  • 処理3 - 領域ごとの最終判定レベルの表示
    • 処理2から、領域ごとにレベルの判定と得点を出す

色々と記載しましたが、「簡単な計算式」を意識したので内容としては加算と乗算と除算しか行っていません。

反省点

先ほど記述した、具体的なタスクでの反省点について、2点お伝えしていこうと思います。

1点目:レベルの基準をベースに質問を設計しなかったこと

質問を考える際、最初はレベルごとに必要な質問を考えていきましたが、プロジェクトメンバー内で話し合ううちに「この質問は不要では?」「この聞き方はこう変えたら?」との議論が行われ修正していきました。ですが、そのあとに再度「レベルを判定するための質問に過不足がないか?」「他の領域とレベル感の統一があるか?」を確認しなかったため、アンケート回収後に「レベルを判定するための質問がない」といったことが発生し、追加の質問を行うことになってしまいました。

2点目:レベル判定定義を決める前に質問を決めてしまったこと

レベル判定しやすいように端的な選択肢にするということは意識できていましたが、前述したレベル判定定義の設計を先にしていなかったため、「この質問はこのレベルのときに何点となるか」が具体的になっておらず、例えば「レベル2を満たす回答をすると同時にレベル3を満たしてしまう」といったことが一部で発生してしまいました。

これからアセスメントを行われる方は、

  • 各レベルを判定させるための質問に不足がないか
  • 質問の選択肢ごとにどう配点するか

を事前に考えてから実施されることをおすすめします。

実施後の感想

結果を見て最初に浮かんだ感想としては「肌感通りだな」ということでした。 私がデータ戦略室の中では歴が長いほうということもあり、「このあたりは全くやったことがなかったから低く出ているな」や、「ここは直近、注力していたメンバーがいたから高く出たな」など、おおよそ想像通りでした。 想像通りではあったものの、実際に数値として可視化することで、これまで各自の頭の中にしかなかったイメージが全員の共通認識として持てたことはとても大きいと感じました。

また、特に初めて行うことは事細かに当時の思想のログを残しておくことが大事だと痛感しました。 例えば「これを評価物にしたのはなぜだったか?」「この質問の選択肢にしたのはなぜだったか?」を残しておくことで、今後別事業で展開するときや、プロジェクトメンバーが入れ替わったときに同じ議論が生まれずに済むようになると思っています。 なるべく実施期間中に書き残していたものの、実際に忘れてしまっていることも多く、今も思い出しながら追記しています。

これからやること

今回実施した事業については、判定結果をもとにロードマップを策定していきます。 基本的には土台となるフェーズのうち、レベル3未満の領域についてレベル3を目指していく動きをとっていく予定です。

優先対応イメージ
また、他の事業でも今回の設計をベースに実施予定なので、必要に応じて設計の見直しも行っていきたいと思います。

今後このプロジェクトが進んだり、2回目の開催で分かったことがあれば、また記事にしたいと思います。