はじめに
こんにちは。
レバレジーズデータ戦略室、データアーキテクトの浅見です。
データ分析基盤の構築に携わる中で、私たちは日々様々な課題に直面します。
その中でも「データ定義」に関する問題は、多くのデータアーキテクトやデータエンジニアにとって頭を悩ませるポイントではないでしょうか。
私も過去に携わったデータ分析基盤の構築において、そのデータ定義の壁に何度かぶつかりました。
本記事では、私が実際に経験したデータ定義の決定プロセスに焦点を当て、その具体的な課題と、それらをどのように乗り越えていったのか、実践的なアプローチを交えながらお話ししたいと思います。
データ定義に悩む方や、社内のデータガバナンス推進に課題を感じている方の参考になれば幸いです。
データ定義を決める上で困った点
データ分析基盤を構築する際、データ定義を決める上で以下の問題に直面しました。
データ定義が不揃い
データ分析基盤を構築する際、まず直面するのが「データ定義がバラバラ」という状態です。
これは、私が関わった複数のプロジェクトで共通して見られた光景でした。
例えば、SES事業において「売上」という指標を可視化しようとした際、各組織で以下のように認識が異なっていました。
- 営業部A： エンジニアの参画が決定した時点で、契約書に明記された取引企業から弊社への支払単価
- 営業部B： エンジニアの参画が決定した時点で、契約書に明記された取引企業から弊社への支払単価のうち、特定の条件を適用した後の金額
- マーケティング部：毎月の稼働終了時点で、稼働実績に対する取引企業から弊社への支払単価
このように、同じ「売上」という言葉でも、組織や文脈によって意味合いが異なり、また各組織で使用されているデータ定義がどのような背景のもとで採用されたのか不明瞭な状態だったため、まずはどのデータ定義を「正しい売上」とするのかを決定すること自体が最初の大きな壁となりました。
さらに厄介なのは、既存システムに蓄積されているデータが、どの定義に基づいて格納されているかが不明瞭なケースです。実際にクエリを書いてみて初めて「あれ、この指標のデータは正しくシステムに蓄積されていなさそうだな」と気づくことも少なくありませんでした。これは、システムのバリデーションルールが不明瞭であったり、入力プロセスに抜け漏れがあったりするなど、データソース側の問題に起因することが多かったです。
こうした「定義の曖昧さ」は、データの信頼性を損ない、最終的にはビジネスの意思決定を誤らせるリスクがあります。
関係者の多さ
データ定義の課題をさらに複雑にするのが、関係者の多さです。
事業全体のデータ定義を統一しようとすると、関わる部門や担当者が非常に多くなり、合意形成に多くの時間を費やします。
最終的なデータ定義を決定するまでに以下のような状況が頻繁に発生しました。
「うちの部署ではこの指標はこういう意味で使ってるんだけど…」
→各部署がそれぞれのKPIや業務に最適化されたデータ定義に固執し、全体の共通認識を形成することが難しいケース。
「その定義だと、このシステムではデータが取れないな…」
→ 技術的な制約や既存システムの仕様、また属人的なデータ蓄積漏れによって、理想的なデータ定義の実装が困難なケース。
上記のような状況では、ビジネスサイドはビジネスの言葉、開発サイドは技術の言葉、そして各部門はそれぞれの専門用語を使うため、まさに「異なる言語を話している」状態でした。この「言葉の壁」が、共通理解と合意形成を困難にさせる要因となります。
最終的な合意を得るまでに、何度も会議を重ね、根気強く背景を説明し、時には各部署の利害関係を調整する必要がありました。これは、技術的な設計・実装のスキル以上に、コミュニケーション能力やファシリテーション能力が求められる場面でした。
システム制約とデータ未蓄積
データ定義を理想的に設計しても、システムのバリデーションやデータ蓄積設計の都合上、必要なデータが思い通りに取得できないことがあります。
これは、既存システムがデータ分析で使われることを考慮していない場合に特に顕著です。
具体的には、以下のような問題に直面しました。
- 正しいバリデーションが行われていないことによる情報の欠落
- 例えば、各KPIの実績を正しく取得したいのに、システム上では特定のKPIを遷移しなくても次のKPIに進めてしまうため、実績を正しく計測できない。
- 既存データ蓄積設計の限界
- そもそも特定のデータ項目を記録する仕組みがない、あるいは記録されていても分析しやすい形で取り出せない構造になっている。
これらの問題は、データ定義の議論段階では見えにくく、実際にデータの抽出作業を進めて初めて顕在化することが多いです。
困難を乗り越えるための実践的アプローチ
こうしたデータ定義に関する問題を解消するために、私が実践したことをいくつかご紹介します。
1. 定義の整理
まずは、現状把握から始めました。
既存データ定義の洗い出しとマッピング
各部署で使われている「同じ指標名」でも、その背景にある計算ロジックやデータソースを徹底的に解読し、スプレッドシートを使用してマッピングしていきました。
「売上」であればキャプチャのような形式で、取得元テーブルや取得条件を明確に可視化します。
既存データ定義を踏まえた最新データ定義の決定
データの理解が深い営業組織のリーダー複数名とミーティングを何度も実施し、「なぜその定義を使っているのか？」「その定義がビジネスプロセスとどう結びついているのか？ 」を掘り下げて理解することで、その背景を把握しました。
また、今まで各部署で使用されていたデータ定義では考慮しきれていなかった新たな観点も、ビジネスプロセスと照らし合わせることで見つけることができました。
データ定義をまとめたドキュメントの作成
最終的には、関係者間で合意された「共通の定義をまとめたドキュメント」を作成しました。これにより、各データ項目の正式名称・ビジネス上の指標定義・集計定義・定義の背景・責任者などを一元的に管理し、社内で同じ定義で意思決定するための土台を作成しました。
2. 関係者との合意形成
データ定義の合意形成は、関係者が多ければ多いほど時間がかかります。
今回は、合意形成のフローを明確にし、事前に「誰と議論するか」を決めておくことが重要だと考えています。
あるプロジェクトでは、以下のように3段階の承認フローを設け、少人数での集中的な議論をできるように調整しました。これにより、スムーズに定義を決定することができました。
一次承認者：早期の考慮漏れ検知
まず、データ定義の初期段階では、事業およびデータへの理解が最も深い現場の社員（営業部・マーケティング部からそれぞれ1〜2名）を一次承認者として選定し、議論を行いました。
少人数で集中的にすり合わせを行うことで、以下を実現することができました。
- 詳細な議論の実現
- 大人数では難しい、きめ細やかな議論が可能となり、データ定義における具体的な考慮漏れや、現場の細かなニーズを早い段階で検知できました。
- 現場ニーズの把握
- 実際に日々データに触れ、業務を行っている社員から直接意見を聞くことで、システム上のデータと実際のビジネスプロセスとの乖離を埋めることができました。
- 認識齟齬の早期解消
- 定義の曖昧さから生じる初期の認識齟齬を、プロジェクトの早い段階で解消できたため、手戻りのリスクを大幅に削減できました。
二次承認者：ダブルチェックによる定義の精度向上
一次承認者との議論を経て、ある程度の定義の骨子が固まった段階で、次に別の視点を持つ事業・データ理解の深い社員（一次承認者と同様に各部署から1〜2名）を二次承認者として選定し、すり合わせを行いました。
これは、一次承認で見落とした点がないか、あるいは新たな視点からの改善点がないかをダブルチェックしてもらう目的があり、実際に異なるメンバーの視点を取り入れることで、より堅牢で多角的なデータ定義を構築することができました。
※補足： プロジェクトの特性やQCD（品質・コスト・納期）の優先順位によっては、この二次承認プロセスを割愛することもあります。例えば、納期を最優先する場合などには、迅速な意思決定のために、一次承認から直接最終承認へ進んでも問題ないです。
最終承認者：事業全体に浸透するための事業部長の承認
そして、一次・二次承認を経てブラッシュアップされたデータ定義案を、事業方針の意思決定を行う事業部長（1名）に最終承認者として確認してもらいました。
この段階で事業部長の承認を得ることで以下のメリットがあります。
- 事業戦略との整合性
- データ定義が事業戦略や目標と齟齬がないかを確認してもらうことで、データを活用した意思決定を正しく実施できるようにしました。
- 組織全体への浸透の裏付け
- 事業部長という組織トップからの承認を得ることで、そのデータ定義が「公式な定義」として、各部門へスムーズに浸透することができるようになります。
このように、少人数での議論と段階的な承認フローを組み合わせることで、関係者の多いプロジェクトにおいても、データ定義の合意形成を円滑に進め、その後のデータ活用の基盤をより強固なものにすることができました。
3. システム制約とデータ未蓄積の問題解決
システムの制約に直面した際は、理想を実現することが困難なケースが多いため、現実的な落としどころを見つけることが重要になります。
現状把握
まず、現在のシステムで取得できるデータの範囲と限界を徹底的に洗い出し、明確に可視化しました。「システム上、このデータはここまでしか取得できません」という事実をわかりやすく整理し、関係者に共有することで各部門間で共通認識を形成しました。
代替データの検討と定義
理想的なデータが直接取得できない場合でも、代替となるデータや既存データを加工することで、それに近い情報を得られないかを検討しました。例えば、直接的な流入経路が不明でも、活動履歴や案件履歴などから推測できる範囲で定義するなどしました。
ただし代替データを用いることによって分析の精度は落ちてしまうため、長期的にはシステム改修を行うことで適切にデータ蓄積される仕組みを作ることが重要だと考えています。
おわりに
今回複数の事業においてデータ定義の再設計を行うにあたって、このデータ定義の合意形成のプロセスは、技術的なスキル以上に、人とのコミュニケーションや問題解決能力、根気強さが試されると感じました。
データ定義を決定する過程は大変ですが、データ定義を正しく揃えることによって、組織全体でデータを正しく活用した分析を促進させることができるため、とても有意義なことだと思っています。
組織がさらに大きくなる前に現在の社員間で共通認識を揃えられるように基盤を整えていきます。
この記事が、データ定義の課題に直面している皆さんの助けになれば幸いです。
