はじめに
こんにちは。株式会社LegalOn Technologies データマネジメントチームでアナリティクスエンジニアをしております、須賀です。
この記事は、datatech-jp Advent Calendar 2024 *1 の19日目の記事として執筆されました。
想定読者
- ダッシュボード作成に関与する依頼者・開発者
データを活用するすべての方々
作成済みのダッシュボードや登録済みのメタデータを利用し、自発的にデータ活用している方
プロダクトを開発するエンジニア
集計目的を満たす上で、データの仕様に問題がないか質問を受けたことのある方
ダッシュボードを利用・開発時によく発生する課題
ダッシュボードの利用者・開発者の方で、以下のような経験をされた方は多いのではないでしょうか？
利用者の方
- ダッシュボード上の数値がどんな集計定義で可視化されているのか分からない
- 必要なデータが、既に分析可能な状態になっているのか分からない
- ダッシュボード作成依頼フォームを頑張って入力したが、アドホックな分析で十分と返答され、記載時間の多くが無駄になってしまった
ダッシュボード開発者の方
- 既存のダッシュボード作成依頼フォームがあるが、その経路に沿わずに依頼が行われた
- テーブル定義書などのドキュメントを見ても、集計目的に沿った集計ができるのか判断が難しい
- ドキュメントベースでダッシュボードを作成した結果、条件が間違っていることが後になって判明した
上記は実際に弊社で生じた課題を簡単にまとめた内容になります。
弊社ではBIツールとしてLookerを利用していますが、ダッシュボード作成時の既存運用に課題が生じていたため、新しくフローを見直すことになりました。
その上でダッシュボード作成時に必要になる集計項目や定義などのビジネスメタデータと、その集計に必要なデータを収集するためのオペレーションに関して紹介します。
中長期的には記載された情報をメタデータとして管理し、信頼できる唯一の情報源(single source of truth、SSOT)として運用することで、社内のデータ利用者が自走してデータ活用を推し進める状態作りに繋げていく想定です。
メタデータとは
メタデータの最も一般的な定義は「データに関するデータ」ですが、DMBOK上ではメタデータがどこで発生するかの関連でカテゴリを考えると良い、と言及されています。
またメタデータ自体は以下の3つのカテゴリに分類されます。
- ビジネスメタデータ
- 主にデータの内容と状態に重点をおいており、データガバナンスに必要な詳細を含む。
- テクニカルメタデータ
- データの技術的詳細、格納するシステム、システム内やシステム間でテクニカルメタデータを移動するプロセスに関する情報を提供する。
- オペレーショナルメタデータ
- データの処理とアクセスの詳細を表す。
本記事では主にビジネスメタデータの収集に関するオペレーションをご紹介します。
ダッシュボード作成に必要な項目になるため、集計項目や定義の情報がメインになります。
例えば 契約書の閲覧数 のようなKPIがあった場合、以下の分類になると考えられます。
- ビジネスメタデータ：集計項目・集計定義
- テクニカルメタデータ：参照データ
| 集計項目 | 集計定義 | 参照データ |
|---|---|---|
| 契約書の閲覧数 | 契約書閲覧履歴のうち削除済み締結版契約書のみを除外 | ドキュメントのTypeを利用し、DELETEDになっているものを除外する |
※ 契約書情報にはセキュリティレベルが高い情報も含まれるため、それらはLooker上から集計できず、別の環境を提供しています。
またCSの方は業務上、顧客名を閲覧できる必要がありますが、権限のない方はマスキングされるなどの対応も行なっています。
以下の記事内容とも近しいですが、弊社ではPolicy Tagを活用しています。
Looker上で組閣✖️カラムレベルで権限制御を行える状態を構築した話 - okodooooooon
これまでのダッシュボード作成フロー
弊社ではBIツールとしてLookerを採用し、日々のモニタリングや分析の一環として利用しています。
Looker上でBigQueryの課金状況をモニタリングする記事も紹介しておりますので、興味ある方は合わせてご確認ください。
私は2024年の4月に入社しましたが、ちょうどAI法務プラットフォーム「LegalOn Cloud」のリリースタイミングで必要なKPIの可視化に取り組んできました。
この際、スプレッドシートを利用して集計項目を集約していましたが、運用上いくつか課題がありました。まずは過去のダッシュボード作成フローを簡単に記述します。
PdM以外の方がダッシュボード作成依頼を行うケースもありますが、プロダクトのKPI定義を行うのはPdMであるためここでは割愛します。
PdM・PEMとは
弊社にはプロダクトマネジメント領域でPdMとPEMという役職が存在します。正式名称はそれぞれ以下の通りです。
- PdM(Product Manager)
- PEM(Product Engineering Manager)
過去の運用フロー上、PEMは登場していませんが新しいフローの中で登場します。前職では存在しないロールで私自身は馴染みが薄かったですが、開発のデリバリーをマネジメントするロールになります。
弊社の記事宣伝になりますが、以下でも紹介されておりますので興味ある方はご覧ください。
PdMとエンジニアを繋ぎ、チームの成果を最大化する開発のキーマン「PEM（Product Engineering Manager）」とは？｜LegalOn Now
上記のフローを回す上で発生した課題
実際に運用を回していく中で、各フローでそれぞれ以下のような課題が発生しました。
そこでフローを見直すと共に、メタデータ収集をセットで考えることにしました。
新しいダッシュボード作成フロー
変更後のオペレーションは下記の通りです。
なお、PdMとPEMが先に会話した後に集計項目を記載した方が良いかもしれませんが、そこは各チームに任せて細かく関知はしていません。
これまで発生していた課題に対するアプローチ
上述したそれぞれの課題に対して、以下のように解決を図りました。
アドホックな分析かどうか事前にslackのワークフローを利用して確認
ダッシュボードの作成依頼が発生した後に、アドホックな分析が必要と分かるケースがありました。
PdM側でも依頼フォーマットを記載する工数が掛かってしまうため、簡易フォームを作成し、ある程度事前に判断できるようにしています。
スレッドで確認を行い問題ないと判断できたら、データマネジメントチームで承認を行います。
この承認はデータマネジメントチームでしか実行することができません。
ボタンを押すと後述するNotionDBへのリンクが誘導されます。
詳細は割愛しますが、Zappierを利用してJiraのチケットも一緒に発行しています。
集計に必要な項目はプロダクト側のエンジニアが確認
データマネジメントチームではプロダクト側の仕様把握が難しく、集計項目に紐づくデータの確認コストが高くなっていました。
そこでプロダクト側のエンジニアが集計対象のデータを記載し、データマネジメントチームでの確認コストを下げることにしました。
NotionDBとテンプレートを利用することで、管理の分散を防ぐことも狙いです。
NotionDBをビジネスメタデータの管理に利用する
冒頭の課題に挙げた集計項目・定義の管理用スプレッドシートが分散してしまった課題の解決策として、NotionDBを利用することにしました。
フォーマットが合わない場合は、事前に相談をするslackのスレッドで認識を合わせる想定です。
集計項目・定義記載用テンプレートの紹介
記載内容は載せることはできないため、フォーマット自体の簡単な紹介になります。
集計定義自体を管理するNotionDBから新規ボタンを押下すると、テンプレートが呼び出されます。
スクショ上では割愛していますが、それぞれの内容を記載する上で誰が・何を記載する必要があるのかのサンプルが展開され、初めて記載する方でも迷わないようにしています。
まとめ・今後の展望
実際に運用を開始して1ヶ月ほどですが、これまで発生していた以下の事例を既に防止することはできています。
集計できるとPdMは想定していたが、実際には必要なデータが存在しなかった。
ただし、まだ新しいオペレーションでPEMの方も慣れていないために質問も多く発生しています。
オペレーションに関するよくある質問集も記載していますが、内容の拡充が必要です。
既に社内では、メタデータを管理するデータカタログツールであるOpenMetadataを運用しています。
現時点ではOpenMetadata上で実際にどうメタデータを見せるか、dbtのymlファイルにどう落とし込むかなどの細かい検証・整理はできておりません。
また弊社ではデータコントラクトの導入はできていませんが、まずは集計定義を固めることを重視しました。
データコントラクトとは、データ生産者が所有するデータについて、消費者に対する責任をどこまで取れるかを表明する方法（生産者と消費者間の契約）になります。
以前datatech-jpで行われた事例共有会に資料が添付されておりますので、興味ある方はご覧ください。
集計定義を固めることで、定義自体の変更やデータ活用の推進に合わせて、データコントラクト周りの課題が発生すると考えています。
今回のオペレーション変更に伴い、プロダクト側のエンジニアとデータ利活用に関するコミュニケーションハードルを下げることで、データコントラクトの導入も進めやすくなればという狙いもありました。
上記もOpenMetadata上で確認できるようにすることで、データの利用者が自走して、安心してデータ活用を進めることのできる状態づくりに繋げていければと考えています。
謝辞
データマネジメントチームの皆さんはドキュメントレビューやディスカッションに付き合って頂き、深く感謝いたします。特にマネージャーのwakabasanは壁打ちから社内への展開まで、細部までフォローアップいただき大変助かりました。
仲間募集
LegalOn Technologies では現在、アナリティクスエンジニアの募集を行っております。
ご興味をお持ちの方は、以下の求人一覧をご確認ください。
TECH-D-101- Analytics Engineer - 株式会社LegalOn Technologies
*1: datatech-jp とはデータエンジニアリング、データ活用についての知見を共有したり、交流するためのコミュニティです。
時々輪読会の企画が案内され、私自身も何度か参加して他の方と議論する場として利用しています。
詳細はこちらをご覧ください。 https://datatech-jp.github.io /
