【翻訳】データディクショナリ：作り方の一例とベストプラクティス
以下はCarl Anderson氏のブログ記事 ”Data Dictionary: a how to and best practices” を和訳したものです。公開にあたっては著者の許可を得ています。
＊ ＊ ＊
データディクショナリとは、重要単語や指標とその定義のリスト、つまりビジネス用語集です。というとあまりにシンプルでつまらないものに思えるかもしれませんが、ビジネスに協調性をもたらし混乱を回避する効果は絶大です。実のところ、データディクショナリはデータチームがビジネスに提供できる成果物の中で最も価値のあるものの一つかもしれません。
たいていの事業ではチーム間で使い方や解釈の異なるコンセプトや用語、指標などが一つはあるものです。そして、そこから混乱が広がっていきます。データが何を示しているのか、取るべきアクションは何かということについて責任者の同意が得られないかもしれません。各チームからのレポートを比べたとき、同じデータソースから取ってきた同じ指標でも、ビジネスロジックの不整合のせいで数値が違っているかもしれません。チームどうしがそれぞれ自分たちの立場を守ろうとして何が正しい定義なのか議論になることさえあるかもしれませんし、ことによるとその原因はそれぞれの定義のほうが自分たちにとって数値が良く見えるせいかもしれません。
データディクショナリさえあれば、それは全スタッフが参照して認識を合わせるためのドキュメントとなり、新しいスタッフの受け入れが容易になり、またビジネスインテリジェンス（BI）チームにとっては指標を実装するための明確な要件定義が得られることになります。
生のデータベースのテーブルに関するドキュメントも重要ではあるのですが、ここでは話をわかりやすくするため、よりハイレベルのビジネス用語や指標についてのみ考えることにします。その事業全体として「ユーザー」、「収益」、「顧客獲得費用」をどう考えているでしょうか？「販売地域」、「平均発送時間」、「セッション」について全員が同じように理解しているでしょうか？たとえばカスタマーサービス担当者のようなジュニアの非技術職メンバーが、事業における自分の業務に関する箇所を読んで重要な用語を理解し、各指標のビジネスロジックを正確に把握できるようにすることが目標です。
この記事では、データディクショナリに関連するいくつかのベストプラクティスと、作成プロセスの一例について詳しく述べます。決してこのプロセスが唯一の正解というわけではありませんが、少なくとも私の場合は上手くいっています。ここでは、BIチームがこの作成プロセスを推進していると仮定します。私の考えでは、データディクショナリとBIツール内に実装される指標はともにBIチームが管理すべきだと思います。
1. 用語を洗い出す
最初のステップは用語を列挙したリストを作ることです。つまり、BIチームはその事業におけるコンセプトや指標（メジャー）、データがどんな切り口で見られているか（ディメンション）といったものの名前をリスト化したスプレッドシートを作成するのです。気が遠くなりそうに思えるかもしれませんが、各ビジネスチームをひとつひとつ回ってそのチームの標準レポートやダッシュボードのサンプルを見ていくというのがひとつのアプローチです。
そして、そこに出てくるグラフの軸ラベルや表の列名、データのピボットに使われているディメンションをすべて洗い出していきます。たとえば、（ある期間における）販売地域ごとの収益を示すレポートであれば２つの用語が出てくることになります: 「収益」と「販売地域」です。この段階では、用語の定義ではなく、その名前だけをリストアップしていきます。
チーム名、用語名、データ型、具体例、もしあればその用語が使われているレポートへのリンクをまとめたリストがここでのアウトプットになります。
その用語がディメンションかメジャーか（メジャーよりディメンションのほうが合意が得られていることが多いものです）を表す列や、データのソースを示す列も用意すると便利でしょう。
（ステップ１：定義抜きの用語リスト）
このリストをビジネス上の役割、例えば財務指標、マーケティング指標、カスタマーサービス指標などでグループに分けて整理します。多くのチームで使われる本当に汎用的なディメンション（「年」「商品ID」「国」など）は、取り出してひとつのグループにまとめたくなるかもしれません。
このリストは事前に予想していたほど長いものにはならない可能性もあります。各チームが追っている指標は自分たちの持っている少ない裁量で最適化できるものに限られ、比較的少数になる傾向があるからです。たとえば、オンラインマーケティングチームはキャンペーン、チャンネル、費用、セグメントなどの少数の切り口にフォーカスしているかもしれません。
ビジネスチームに出来上がったリストを（特に自分たちに関係する箇所はよく）見てもらい、足りない用語があれば追加するように頼みましょう。もし元からしっかりしたダッシュボードやレポートがあった場合、リストは既に充分なものになっているかもしれません。しかしそうでない場合、追加でリストに入れておきたいコンセプトがこのとき出てきます。
2. 用語を定義する
BIチームが定義を統一したり作成したりする作業に手を付けるのはここからです。
まず、既存のすべてのドキュメントからすべての定義を引いてきます。ここで言うドキュメントには社内Wikiや年次報告書のほか、SQLクエリやExcelマクロのような実際に動いているコードも含みます。定義は明確で曖昧性のないものでなければいけません。文章で書くよりも単純な式（たとえば ARPU = 全収益 / 登録者数）で表したほうが明快になるようならそちらを使いましょう。一部の用語については相互参照が必要になるにせよ、ほぼ全てのスタッフが定義を理解できるようにしておく必要があります。
次に、各チームと膝を突き合わせて、足りないところを埋めたり元の定義を改善したりするのを手伝ってもらいます（空欄にしておくよりは不正確でも何らかの定義からスタートするほうが進めやすいでしょう）。このとき、そのチーム内での合意が得られるまでに多少の協議が必要になるかもしれません。またその指標が現在どのように計算されているか調査が必要になるかもしれません。
ここが重要なところですが、「現在の定義は何ですか？」と聞くのではなく「どのように定義するべきですか？」と聞きましょう。もし現在の実装がそのチームにとって理想的な定義でないのなら、これが理想的な状態に変える絶好の機会です。例えば、前任者から複雑すぎる定義を引き継いでいたとしたら、それを単純化するチャンスです。そのようにして理想の定義が見つかると、今度はデータチームや技術チーム、あるいは元の定義の指標にコミットしている他のチームに対して新たなプレッシャーが発生します。
3. 齟齬を特定する
これが鍵となるステップです。ここからチーム間で定義が異なる用語を根絶していきましょう。
4. 共通化する
チーム間で違いのある用語について、関係するチームを同じ部屋に集めます（そして鍵をかけます）。そして、定義がどのように・なぜ違っているのか議論させましょう。
このミーティングでは次の２つのうちどちらかの結論を出すようにします：
・一方のチームが他のチームの定義を受け入れる。
・異なる定義があるのには正統な理由がある。この場合、片方または両方に新しい名前を付けることに合意する。
（第３の選択肢は両チームが同じ一般的な定義に修正することですが、その可能性は低いでしょう。）
名前は曖昧さや混乱を避けられるよう十分な長さのものにすべきです。もし通常の”ebitda”と区別して”community_adjusted_editba”とするほうがより適切ならば、そちらの長くて具体的な用語を使いましょう。目的は簡潔にすることではなく、混乱をなくすことです。
5. 承認を得る
各チームのリーダーに承認をもらいます。これは極めて重要です。BIチームが定義した用語にビジネスチームが密かに反対しているという状況は避けたいでしょう。もしそうなると、そのビジネスチームは独自のロジックをExcelで実装してしまい、話がふりだしに戻ってしまいます。ドメインエキスパートとして、またその指標に基づくビジネス上の意思決定者として、チームリーダーたちが完全に同意している必要があります。
Warby Parkerでは、共同CEOの協力を得てチームリーダーたちに定められた期限までに承認してもらうようにしました。チームリーダーたちは忙しく、またデータディクショナリはその価値が認められていたとしてもなお最優先事項には見えにくいものです。そのため、このようなトップダウンの後押しは極めて有効でした。
6. 公開する
データディクショナリを１ページのドキュメントとして全社から（したがって、BIツールの中からだけでなく）アクセスできるように公開します。ここに載っている定義は役員・アナリスト・意思決定者だけでなく全スタッフにとって広く理解しやすく受け入れやすいものになっていなければいけません。したがって、見つかりやすいことが肝心です。もしその会社でWikiをよく使っているなら、そこに公開しましょう。皆がそこにありそうだと思うような場所に置くのです。
概念上は、この中に含まれる用語は特定のシステムやデータソースに依存せず、したがって特定のBIツールに紐づくものではありません。しかし、そうして独立に作られた定義も可能であればBIツールに埋め込むと良いでしょう。そのような埋め込み機能をサポートしているツールなら、ディメンションやメジャーをマウスオーバーしたときに、その定義や例がポップアップで表示されるはずです。
同じ定義が複数の箇所で現れる可能性を考えると、データチームはデータディクショナリを単一のソースから自動生成する仕組みを整えるべきです。このソースとしてはデータベースのテーブルを使っても良いですし、あるいは手動で静的なテーブルを保守するよりもコードリポジトリを使ったほうが良いかもしれません。
例えば、Warby Parkerでは、データディクショナリは Jenkins のジョブで生成されていました。リポジトリが修正されると、ドキュメント（専用の内部向けウェブサイト、あるいはすべてのデータドキュメントを収めた「データブック」）が再生成されるようになっていたのです。
7. 保守する
重要な指標は比較的安定しているものの、やはりビジネス上の理由で指標の定義を変更しなければならないこともあります。そのような変更と新しい定義はビジネスチームから要請されるものです。しかし、その変更を実装し周知を行うにはデータチームの力が必要になります。
BIチームは変更をロールアウトする前にその影響を評価しなければいけません。例えば、古い定義と新しい定義の両方でその指標を表すグラフを用意して、数値がどのくらい変化するか予想を付けるなどします。
定義の変更はプロダクトのリリースと同じように扱います。つまり、事前に定義の変更を連絡し、何が予想されるかを知らせ、データディクショナリの末尾に変更履歴を付けるなどしてドキュメントに残します。
一部のシステムが同期されずに取り残されるようなことがないようにしましょう。自動生成が役に立つのはこのためです。
・ ・ ・
上述のプロセスに沿ってデータディクショナリを作成するのは簡単なことではありません。多くのメンバーとの対話や調整が必要になるため、数ヶ月かかると思われます。これは大規模な共同作業になります。BIチームによって推進・調整されますが、広汎な合意、協力、労力、そして少々のトップダウンによる強制も要求されます。
このプロセスを部分的に進めるやり方はおすすめしません。例えば、財務データディクショナリは後日来るものだと思って先にマーケティングデータディクショナリを完成させてはいけません。そうすると、（ステップ４の）チーム間での共通化の議論をすることが難しくなります。そしてまさにそのステップこそが本当の価値が生まれるところなのです。また、順次進めていくやりかたは後になるほど勢いを失っていくものです。目的を達成するためには、共通の期限にむけてチーム間で同時的な議論を行うことが必要なのです。
この記事が気に入ったらサポートをしてみませんか？