本記事は、クリスマスに向けデータに関する想いや技術をぶっちゃける Advent Calendar 2022 1日目の記事です。
自己紹介
はじめまして、今回カレンダーを企画させていただきましたSinkCapitalの櫻井と申します！
クラウドインフラエンジニアを中心としてデータ分析などデータに係る業務を行っています。
現在仕事としてはデータギルドSinkCapitalの代表としてギルド運営に関わるとともに、
実際のワーカーとして様々な会社様のお手伝いをさせていただいています。
元々アカペラサークルにはいってたこともありカラオケが大好きなので、
お好きな方がいらっしゃれば是非一緒に行きましょう！！
アドベントカレンダーのきっかけ
今回データ領域の様々な組織・ロールの方との議論を生みたいう思いから企画させていただきました。
というのもデータの領域はまだまだできて新しい領域であり、
また会社・組織によって色が大きく異なるので、
様々な角度から議論していくことが重要ではないかと感じたためです。
またデータはイメージと裏腹に泥臭さも多く存在する領域だと思っており、
個人的にそのあたりの色んな話を聞いてみたいというのもあります！
そのため記事を読んだ後に「確かに！」や「私はちょっと違うと思ってて...」など、
様々な意見をコメント欄に書いていただけると幸いです！
--- では以下本編です ---
前提：本記事における「データ定義管理」とは
データ定義というと様々な種類が考えられますが、
本記事では主に業務に関するビジネスメタデータを指しており、
以下のような分析業務上用いられる「このデータは何を意味するかの情報」を指しています。
- 例１：start_dateはサイト閲覧開始時刻を指している
- 例２：active_flgは課金中のユーザーのみtrueとなる
そしてデータ定義管理は「このデータは何を意味するかの情報」の管理になるので、
「データは何を意味するか分かる状態にする」＝データ定義管理すると考えています。
データ定義管理って難しい
この問題はデータの仕事をされている方誰もが感じる大きな問題だと思っています。
僕は新卒から6年ほど様々な企業でデータ定義管理の方法を見てきたのですが、
未だにデータ定義管理の正しい形は自分の中で解が出せていません。
ただぼんやりとこんな感じが良いのではという方針が見えて来たので、
今回の記事ではその内容について書いていこうと思います。
今までの事例
まずこれまで見てきたデータ定義管理方法についてまとめようと思います。
今まで見てきたデータ管理の方法
今まで見てきたデータ定義管理方法について以下に並べてみました。
「詳しい人に聞く」などデータ定義管理と呼べるか微妙なものもありますが、
「定義を知れる」という意味では目的を果たせているので並べて記載させていただいています。
- 詳しい人に聞く ： あの人・あのチームに聞けばわかる
- 網羅的にデータ定義をまとめる
- Google SheetやGoogle ドキュメントにまとめていく
- GithubにまとめてData CatalogやGithub Pagesでの公開
- 特定のデータに関してまとめる
- 過去のSQLをまとめる
- QA・過去やり取りをまとめる
各方法のメリデメ
それぞれのメリデメと実際に利用して感じた所感を以下の表にまとめてみました。
| 手法 | メリット | デメリット | 櫻井所感 |
|---|---|---|---|
| 詳しい人に聞く | すぐ始められる データ定義の情報量が多く質が高い |
質問回数に比例して運用コストが増える | どの組織でも存在。質問が多くなりすぎると破綻しやすい。 |
| 網羅的にデータ定義をまとめる | 検索性が高い 網羅性が高い |
運用コストがデータ定義の種類に応じて増える データ定義の情報量が少ない 管理が難しく散在しやすい |
維持が難しくフロー設計を間違えると過去の遺産になりやすい。 |
| 特定のデータに関してまとめる | データ定義の情報量が多く質が高い 用途例がわかる 運用コストが低い |
開発コストが高い 情報があったりなかったりする |
利用頻度の高いものをまとめた記事はとても重宝される。どの粒度でどの情報を記事にするかはまとめる人のセンスに影響する。 |
| 過去のSQLをまとめる | 検索性が高い 用途例がわかる 開発・運用コストが低い |
データ定義の情報量が少ない 情報があったりなかったりする |
転用もしやすく役立つ一方、データ定義が正確に確認できないので少し不安は残る事が多い。「ここでこう書いてるから多分コレでだせそう」までがすぐわかるイメージ |
| QA・過去やり取りをまとめる | 検索性が高い 用途例がわかる 用途があえばデータ定義の情報量は多い 開発・運用コストが低い |
情報があったりなかったりする 情報が散在 |
知りたい情報のQAや過去やり取り当たると絶対的安心感がある。 |
自分がやってきたこと
そんな中利用者としてどうしていたかでいうと、
自分でデータ定義を調べる際は以下のようなフローで調べることが多かった気がします。
特徴として最終的に出したいもの＝利用用途（予約数・購入数など）から探し始めることが多く、
逆にカラム名などからデータ定義を調べ始めるケースは比較的少なかった気がします。
というのも分析要件時点でカラムがわかっているケースは少なく、
逆に過去事例などから利用カラムがわかった時点で使い方なども載っていることが多かったためです。
データ定義より利用用途が重要？
そういった経験から感じた事として以下のようなものがあります。
- 利用用途からデータ定義を探すケースが多い
- 「網羅的にデータ定義をまとめる」は利用回数の割に開発・運用コストがかかる
- 網羅性が必要になるシーンはそこまで多くない（みんなが興味のある用途で十分）
つまり「みんなが興味のある用途において利用用途から探せるもの」があれば、
実際の現場としてはうまく回っていくのではないかと考えています。
QA・問い合わせを綺麗に残すだけでいけるのでは
そのため例えば以下のようなルールで利用用途から検索できる知見を貯めていけば、
業務に必要なデータ定義情報は溜まっていくのではないかと考えています。
- データ抽出依頼や問い合わせは後ほど検索できる状態で出してもらう
- フォーマットに沿って必要な情報を書いてもらう
- それらの検索ができるツールを用いる（slackやJIRA)
- 抽出依頼で作成したSQLなどが終える状態にしておく(リンクを貼るなど)
- 定期的によく来る抽出依頼・問い合わせ内容を整理した記事を作成する
過去調査した ≒ みんなが興味のある用途
上の内容は「過去のSQLをまとめる」と「QA・過去やり取りをまとめる」をメインで行い、
必要に応じて「特定のデータに関してまとめる」事を行うことを想定しています。
共通するデメリットにある通り情報の網羅性欠如（情報があったりなかったりする）が目立ちますが、
依頼や問い合わせがあった情報から埋めることで、
網羅性はないがみんなが興味のある用途はだいたいある状態を作ることを考えています。
ただ小さな規模だとうまく行かない？
この方法のデメリットとしてあるのが知見量によって運用コストが下がっていく仕組みのため、
小さな規模だとコストが下がるまでに時間がかかることが上げられます。
そういった際は一度網羅的にまとめるコストが下がるため、
最初にまとめてしまう方法のほうがメリットがある可能性があります。
- 規模が大きい
- データ定義から利用用途を探すのが難しい
- データ定義を網羅的にまとめるコストが大きい
- 規模が小さい
- データ定義から利用用途を探すのが比較的容易
- データ定義を網羅的にまとめるコストが小さい
まとめ
今回現時点でデータ定義管理方法について日々思っていることを書いてみました。
実際の現場でもJIRAなどを用いて「利用用途・データ定義・SQL」が一箇所に残るようにして、
擬似的に上記のようなQA・問い合わせを綺麗に残す環境を作っているので、
その中で感じたことがあれば別の機会に記事にしていければと思っています。
「これは違うんじゃない？」などいろんなツッコミを入れてもらえると幸いです！
最後まで読んでいただき誠にありがとうございました！