この投稿はアイスタイル Advent Calendar 2023 の23日目の記事です。
はじめに
アイスタイルの土佐です。
データ戦略推進室という部署で、日々データの利活用の推進を進めております。
データの利活用を進めるうえで、1つの重要な要素の一つに「データカタログ」というものがあります。
今回この記事では、データカタログとは何ぞや？と、データカタログを作成することの意義を簡単に説明してから、データカタログの充足を目指して取り組んだことについて書こうと思います。
まだまだ個人的に解決できていないことが多いのですが、データに関わる業務を行ったことがある人には何かしら共感できるポイントなどあるかと思います。
そういった中で、そのアプローチいいね、追加でこういったアプローチがよさそう
といった議論をして、少しでも悩みを減らして、よりスムーズなデータの利活用の推進に繋げられたらと思っております。
データカタログとは
・あのデータってどこにあるんだっけ？(データ検索性)
・このテーブルってなんのテーブルなんだっけ？(データの実態の確認のしやすさ)
・あのデータのモニタリングって出来るんだっけ？(データ網羅性)
・あのテーブルに追加情報を加えたテーブルが欲しい(データの再利用性)
etc...
データの利活用を進めていく中で誰しもが一度はこのような経験があると思います。
そういった情報を一元管理し、わかりやすく管理されているもの全般をデータカタログといいます。
データにはさまざまな形式がありますが、
この記事ではわかりやすく、データ = テーブルとして考えます。
データカタログの意義
前述したような疑問を、
データカタログがない場合どのようにする必要があるでしょうか？
・テーブル作成者に質問する
・利用されているツールから逆算して調べる
・テーブル作成者が残したドキュメントを探し当てて、自力で解決する
など、さまざまだと思いますが、どれも時間がかかります。
仮にドキュメントがあったとしても、作成者それぞれが定めたフォーマットでの記述がされており、テーブルごとによって記載されている情報がまちまちでドキュメントがあったとしても、結局作成者に聞きに行ったりというような不確実性もはらんでいます。
また、一度は解決されたとしても、次に同じような疑問、または新しいテーブルについて調べたいときに、また時間のかかる調査をしなければなりません。
これは、データ利活用を進めるうえで非常にコストになり得えます。
それを解決するのがデータカタログとなります。
データカタログの充足にあたり、どうすればよいのか？
これまでデータカタログの意味と、意義について簡単ですが説明してきましたが、
そのうえで何をしていったらよいのでしょうか？
これからは、自分の経験ベースで記述していこうと思います。
データカタログの充足を進めようと思ったきっかけ
まず、今の部署で仕事をしていくうえで、
「データの利活用を進めるうえで弊害となりえることがあるなぁ」
こう思ったことがきっかけでした。
なぜそう思ったのか？
自分の悩み
日々感じていた点と、「データカタログとは？」の章で上げたような悩みのポイントを要約すると、
① データ検索性
② データの実態の確認のしやすさ
③ データの再利用性
④ データ網羅性
のように絞れるかと思います。
例)
① 自分が見たいデータがすぐにどこにあるのかがわからない
② 使いたいテーブルの実態(各カラムの意味や、その型や、条件といった利用するにあたっての補足事項など)がわからず、テーブル作成者に聞きに行っていた。
③ 同じようなクエリを何回も繰り返し作成していた。
またそれによって、定義変更が起きた際に、その影響範囲の調査が難航する。
④ 自分たちが理解している、把握しているデータが何なのか自分でもわかっていない
それぞれの悩みポイントにおけるアプローチ例
ここでは、それぞれの悩みポイントの詳細と、それに対するアプローチを記します。
※ 大前提として、いきなり全社のデータを今回のアプローチで整理していくことは膨大なリソースがかかってしまうので、一旦範囲は自チームのものと限定しております。
① データ検索性
探したいデータやテーブルといったものを、まずどこで検索にかければよいのかわからない。
ということが問題でした。
時にはConfluenceという情報共有ツールで検索をしたり、
時にはGoogle Driveで検索にかけたり、
またチケット管理ツールであるJira(現在はBacklogを利用)で検索にかける。
このようにして何とか情報をかき集めていた状態でした。
僕らのチームでは、主に依頼ベースでのデータ抽出業務をメインにこなしております。
そのため、大きく分けて以下の3つの観点で検索にかけることが多いです。
- 抽出案件に関する情報
- 1で作成したテーブルやその関連情報
- 自分たちで管理しているテーブルなどの範囲
そのため上記の3点で、
それぞれの情報をどのツールで、どこで管理するか？これをルールとして定める
ことでクリアしようと考えました。
② データの実態の確認のしやすさ
データに関する例えばテーブル定義書などを見つけても、本当に欲しい情報があるのか？
それが見つけたドキュメント内で見つけやすい状態かどうか？
という点が課題でした。
例えば、
・せっかくテーブル定義書をみつけても、結局どんな意味のカラムなのかわからなかった。
・テーブルによって記載事項が全く違う、フォーマットが揃ってなくて頭の中でごっちゃになる。
・このテーブルはどうやって作られているのだろう？どこで使われているのだろう？
こういった経験がある方も多いかと思います。
なので、
・記述事項等を検討
・フォーマットの統一化
・仕様書、定義書作成の義務化
を行いました。
③ データの再利用性
再利用性という言葉には2つの側面があるかと思います。
1つ目は同じようなクエリはview化のように型化し、それを使いまわせる状態という点です。
日々クエリを書いていると同じようなクエリを書くというのは頻繁に起こり得ます。
これを簡略化できれば、再利用性の向上が望め、生産性の向上につなげられることができる、といった点です。
2つ目は同じ言葉の意味を持つデータは、必ず同じ参照元からのデータである必要があり、利用する人によって解釈が異なる状態ではないという点です。
(同じようなデータがあるとしても、それは言葉として区切るべきと考えます)
ここが異なるということは、同じ意味のデータなのに違うテーブルからのデータであって、本当の意味での再利用ではなくなってしまうためです。
これらを解消するために、データ辞書というツールを作成しました。
これによって、日々使われるデータをまずどういったデータなのか言葉からデータを紐づけることができ、さらにそのデータが参照するテーブルを記載、また更新していく仕組みがあることで、データ利用者はただそこを参照して利用すればよい、ということが可能になります。
④ データ網羅性
自社内のすべてのデータというのは、膨大な量になり得て、それをすべて把握している人は恐らくいないのではないかと思います。
少なくとも、自分たちが関わる、関わったことがあるデータだけは把握しとくことが大事だと考えます。
網羅するために2種類の考え方があるかと思います。
1つ目はビジネスサイドに基づくデータの網羅性です。
僕たちでいえば案件単位でのデータです。
自分たちが関わったことのある案件やPJT、それらに関連するデータは何か？という点となります。
2つ目はシステムサイドに基づくデータの網羅性です。
データの意味として切り分けたとき、どのようにデータが存在するか？という点となります。例えば、クチコミに関連するデータ、購入に関するデータ
こういった切り分けをしたときの網羅性について着眼したときの考え方です。
これらはすでに記述した2つの方法で解消できると思います。
1つ目は案件ごとのフォルダを作成し、そこに関連ドキュメント等を格納することです。
今まで案件を請け負った担当者がそれぞれで関連ドキュメントを管理するという状態でしたが、これによりそれぞれの案件ごとのフォルダ内を探せばその案件に関わるデータが取得できるようになります。
今後の話にはなりますがこれをさらに、例えばチームごとのフォルダを用意することで、どのチームでどういったデータが使われるのかを網羅できる、そんなこともできるかと思います。
2つ目はデータ辞書です。
データ辞書では、データごとにどんな言葉なのか？をカテゴリとして用意しているので、関連データをすぐに把握することができます。
おわりに
この記事では、データカタログとは？といった部分から、データカタログがあることの意義
そしてデータの利活用を進めるうえでの悩みポイント、そしてその悩みに対するアプローチの方法を述べました。
独自で作成したデータ辞書や、それぞれのアプローチ方法に関しては簡単な言葉での説明となってしまったので、別記事でそれぞれ詳細に説明できればと思います。
本記事を通して、少しでもデータカタログに関する考え方の理解につながったり、悩みポイントの共感を得たり、悩みを解決するためのアプローチについての議論の足掛かりになれば幸いです。