コネヒト開発者ブログ

コネヒト開発者ブログ

Re:データ民主化の実現とRedash 〜よりデータを活用するための命名規則をどうするか〜

こんにちは!PHPなんかを書いている金城 (@o0h_)です。
先日、弊社某部長に薦められて「かくかくしかじか」を読みました。 これが非常に良かった。 個人的には、2巻の「ふーん」「いいじゃない」「え マジすか」「マジだよ」「ハイ 次の人」のシーンが好きだな〜と思いました。

かくかくしかじか

かくかくしかじか

やはり、信頼できる人のレコメンドや想いというのは・・"一旦素直に受け止めてみる"のが良いものだ、と改めて思った経験でした。

ありがとうございました。

さて、先日のエントリーで弊社におけるRedashの導入と活用(展開)についての取り組みに関して紹介がありました。

tech.connehito.com

相変わらず「どうしたら最高の効率・効用を社内にもたらせるのか」を考える日々ですが、その後また社内での運用について考えた部分があるので紹介です。

クエリ/ダッシュボードの命名規則について。

f:id:o0h:20140315123316j:plain

tl;dr

  • 命名規則大事。「情報を再活用できる」ことを意識する
  • クエリが乱立する前提で運用方法を考える
  • どんな規則が必要かは、組織の様態やRedashの活用目的に応じて考える
  • 規則に沿うことのメリットを提示する
  • 誰かがメンテナンスを行ってキレイな世界を担保する

創造的なデータ活用組織への道程

個人的には、コネヒトにおけるRedashの導入目的は以下のような進展を辿ると捉えています。

  1. データに自由にアクセスできる
    ・・・各人が自由にデータソースへのアクセスが可能(実行環境等)
  2. (簡単なクエリなら)自分で実行できる・データを引き出せる
    ・・・SQL等の基礎的なリテラシーが備わっている
  3. やや高度なクエリも、助けを借りながら実行できる状態
    ・・・各種データの配置や適切なデータソースの選択が行えて、分析のためのアイディアを自発的に持ち合わせている
  4. 必要なデータは「誰かが書いている」状態
    ・・・組織やサービスの成長のために必要なメトリクスが、既に何かしらの形で発掘されている
  5. 作成されているデータから学びを得られる状態
    ・・・自身のアイディアを超えて、セレンディピティ的に着想を得られる

1のフェーズは、先の永井のエントリーでご紹介させていただいたとおりで、既に十分なレベルで環境を整えられていると思います。
2,3についてもまた、Redashで自主的に気になったデータを引き出しているメンバーが増えていることから成功していると見ています。

自由と規律

組織内に「データを出してみる」人が増えたことによって、新たに問題が生じてきました。自由にクエリやダッシュボードを作成できることで、登録内容が乱立してきたのです。
「他人のクエリを読んだり、再活用できる」点はRedashの長所の一つです。それなのに、クエリなどが散らかって「何があるかわからない」「探すためのキーワードもわからない」という状況は損失であると感じます。

こうした問題に対処するための良い手立てはないでしょうか。

プラクティスから学ぶ

まずは「他社だって絶対に同じ問題を抱えているでしょ」ということで調べるところから。
とりわけ id:ariarijp さんの記事と、エウレカさんの事例は非常に参考にさせていただきました。

ariarijp.hatenablog.com

medium.com

ここで指摘されている クエリが乱立する前提で運用方法を考える というのは、とても大事なポイントだなと感じます。
組織の規模やデータ活用のフェーズに応じて「どのくらい・どう乱立するか」が異なってくるはずなので、現状に即しながら「自分の組織でデータの活用が良い感じにストレッチしていく」ための支援が欠かせないでしょう。
改めて、「今のコネヒトのチームはどういう状態で、次にどのレベルを目指していきたいか」を整理してみました。

発散から活用へ

現状としては、先に述べたように「クエリを書く人が増えてきた」という状態にあります。*1
ここからもう一歩踏み込んで、「データの活用効率が上がる」という姿を目指したいのです。それによって、個々人の知識・知見が交差し、コラボレーションを生むようにデータ活用に近付きたいなと。

ルール作りによる活用の支援

では、実際にどのようなルールがあれば「自分に関わるデータが見つかる」状態を作れるでしょうか。
とてもシンプルな解法ですが、これは「命名規則を設ける」ことにしました。

分析対象による分類

  • 関心事のドメインを単位としてprefixをつけさせよう
  • 細かすぎると破綻しそう。大体の場合、組織構成(部署やチーム)と同じくらいの粒度になりそう

という内容です。

prefixは、基本的に「大分類」と「小分類」の組み合わせと定めています。

例えば

内容 prefix
メディア(mamari.jp)の編集チーム MEDIA_Editorial:
メディアのソーシャルメディアチーム MEDIA_Social:
QAアプリ(ママリ)のコミュニティ運営チーム QA_Community:
QAアプリのグロースチーム QA_Growth:
営業部のディレクチョンチーム SALES_Direction:
QAアプリのマーケティング関連 QA_Marketing:
開発部SRE DEV_Sre:

といった具合です。*2
その他に、「Redash自体の活用関連」など、各セクションの業務とは異なる物はMISC: としてまとめることにしました。

成果物に関する分類

また、Redashを利用していく上で「何のためのものか」といった内容だけでなく、よりメタな情報についても需要が生じます。
メタ的な情報を示すために、#ハッシュタグ 風の表記も取り入れることにしました。

意味 サイン
作成途中 #WIP
定点観測用データ #KPI
mixpanelやGoogle Analyticsといった
データソース
#mixpanel
#GoogleAnalytics
QueryResult用の中間データ #Source
データソースやビジュアライズの
使い方の参考用
#Sample

などです。

example

このようなルールで縛ると、以下のようなクエリやダッシュボードの命名が仕上がります。

  • MEDIA_Editorial:閲覧数上位記事(週間) #GoogleAnalytics
  • QA_Growth:質問投稿数(日別) #KPI #mixpanel
  • QA_Marketing:有料獲得ユーザー数
  • MISC_Redash:ファネルチャート #Sample

これらが、コネヒト社内で取り決めたルールです。

ルール定着のための支援

これによって、少しずつクエリやダッシュボードの整理整頓を進めていくための足がかりができました。
これを定着させるために、

  • いつでも参照しやすくする
  • 命名規則に沿うことでの「便利さ」を高める

という工夫が欠かせないと考えています。
その実現のために、Redash上に「はじめに」というダッシュボードを作成しました。

f:id:o0h:20180522222132p:plain

まず、最上部にルールが示されています。
最低限のルールだけベタ書きし、細々とした内容は各々リンクを貼ることで見た目をコンパクトにしています。

中段左には、「大分類」「小分類」の索引を設けています。
ドロップダウンで「大分類」「小分類」を選択すると、一覧が表示されるようになっています。
この分類はGoogle Spreadsheetに登録しつつtableを組むことで、とても手軽な管理をしています。

中段右には、prefixごとの「(クエリ)一覧テーブル」を用意しています。
これは、Redash自体のqueriesテーブルを参照したクエリを用意することで実現しています。 実際に利用しているSQL文は以下の通りです。

これらを用意して意識付けを行いつつ、分類の「意味」を濃くしていきます。*3
例えば「アプリのグロースを担う人間なら、まず最初に QA_Growth のクエリ一覧を開き、そこを起点に分析活動を開始」という流れが当たり前になる!というのが今描く理想です。

浸透のためには(人力で)もう1歩が必要

とはいっても、一朝一夕で確実なルール移行が達成される・・というものではないと思います。
エンジニアだと「命名規則」は慣れ親しんだようなものですが、それ以外では通常業務で厳しく命名を意識している!!という部門も少ないでしょう。

先に紹介した id:ariarijp さんの記事では、redashman + Pythonによる自動チェックまで提案されていました。めちゃくちゃカッコいい・・
コネヒトでは、まだ命名規則の運用を始めたばかりということもあり、ひとまずはadmin権限を持つ人による手動運用を行っています。何気な〜くRedashを開いたときに、気になった新着クエリ/ダッシュボードのリネームを行う、というとても単純なやり方です。
まだまだ分類ルールも未完成なので、その作業のを通じ、実際に作成されていくクエリやダッシュボードを眺めて「さて、どうしていこうかな!」を考えて行きたいなと思っています。

まとめ

最後まで読んでいただき、ありがとうございます。

先日の Redash meetupに永井が参加していたので感想を聞いたところ、「どこもやっぱり同じような問題(クエリ乱立問題)には悩んでいるみたいだね〜」ということでした。

個人的には、「どんな人達がいて、どんな文化があり」「データの活用レベルがどんな状況にあるか」に応じて最適なやり方をデザインするのが幸せだと思っています。(そして、インターネット上にプラクティスがまだ少ない!)
この記事を読んだ読んでくださった皆さんの「ウチはこんな風にしているぜ!!」話を、ぜひ聞いてみたいです!

*1:非エンジニアへのSQL講座や、Slackの「#デーア分析なんでも質問チャンネル」の設置、face-to-faceでのハンズオンの実施といった支援が実を結んでいると見ます。

*2:実際に儲けている区分けとは、異なりますが・・あくまでイメージです。

*3:「はじめに」ダッシュボードには、これ以外に「日毎の作成されたクエリ数」「同ダッシュボード数」などのCounterも表示して、「データ活用している感」を盛り上げるような要素も盛り入れています🎉