はじめまして、食べログシステム本部のデータサイエンスチームでデータ利活用のリードをしている富田です。 2022年9月29(木)に緊急Ques 食べログの品質ダッシュボードという勉強会に食べログのエンジニア達が登壇し、私も登壇させていただきました。
勉強会の様子については本勉強会の発起人である荻野が書かれたレポートを参考いただくとして、本記事は私の発表である「品質ダッシュボード」と「データによる意思決定」の発表を文字起こししたものです。
他の方の発表では内部品質、および、外部品質の計測を目的にしたダッシュボードを作成したことが語られましたが、これらの活動を「データによる意思決定」プロセスの一応用例として捉え、データ利活用の立場から見たプロセスやツールの要所、および、成否を分けるポイントについてお話しさせていただきました。
本記事は、発表に興味があったものの参加できなかった方や、テキストで読みたい方向けに作成しています。発表スライド、YouTube動画やTogetterまとめを作成していますので、実際の講演や当時の反応を見たい方はこちらも合わせてご確認いただければ幸いです。
データの専門家から見た品質ダッシュボード
初めまして、富田といいます。2012年4月からカカクコムに入社し、以来ずっと食べログに携わっております。
入社後4年間はSRE的な役割を担うチームに所属しておりましたが、それ以降はデータ/機械学習全般に携わるようになっています。大学院時代は自然言語処理の研究をしておりまして、機械学習に詳しい人間だったのですが、今はその前段階のデータの整備や分析に主に携わっています。食べログ内のデータマネジメントとデータサイエンスちょっとわかる人と認識していただければ良いかと思います。
まず、今回の発表で私が話すことになった経緯についてお話しさせてください。
私が所属するデータサイエンスチームは「食べログのデータと科学的なアプローチの両方を用いて、食べログのあらゆる意思決定を支援する」をチームミッションとして掲げており、データによる意思決定を支援することが最も重要な活動となっています。
そのミッションを達成するための活動として、データの基盤の構築・運用、利活用のためのツールの管理、利活用の推進などを行なっております。
データサイエンスチームが提供する価値は、基本的に「社内メンバーがデータを利用する」ことで生まれます。そのため、「ダッシュボードの提供」や「社内プロジェクトへのデータ提供」といった取り組みを進めています。
今回の話は「ダッシュボードの提供」に関連した内容です。 食べログで行われているさまざまな活動の中で発生する意思決定があり、その意思決定のために何らかの指標をモニタリングしたいニーズがあります。 そのニーズを満たすために、何らかのモニタリングダッシュボードを作成される訳ですけど、そのためのデータとツールを提供することで、意思決定の精度向上に繋げてもらえるようにしています。
今回の「プロセス品質ダッシュボード」もこれに該当します。「DeveloperProductivityチーム」が「開発生産性向上の活動」をしていく上で、精度の高い意思決定を実現するべく「何らかの指標をモニタリングしたいニーズ」があります。我々のチームでは、こうしたニーズを満たす手段として本ダッシュボードを捉え、支援を行なっています。
今日の発表では、「プロセス品質ダッシュボード」を通じて、この活動はデータ利活用の立場からどのように捉えられるのか、 その中で、どういう仕組みが刺さるのか、についてお話しさせていただきたいと考えております。
今回の発表では、3つのことを持ち帰っていただきたいなと思っています。
一つ目は「品質ダッシュボード」による、開発生産性向上のための取り組みは「データによる意思決定」の一つであること。
二つ目は「データによる意思決定」の実現のために意思決定に必要なデータを継続的に更新し、可視化をする仕組みが必要であること。
三つ目は食べログでの「データによる意思決定」推進のために、データ基盤とBIを展開しており、「品質ダッシュボード」はその一応用先として構築されていることです。
品質ダッシュボードにはBigQueryとTableauを採用
最初に、食べログで採用しているツールについてお話させていただこうと思います。
食べログではデータ基盤としてBigQuery、BIとしてTableauを採用しています。
BigQueryはGoogle Cloud Platformのプロダクトの一つであり、アクセス解析ツール, DB, その他様々なデータをBigQueryにデータを転送し、配備しています。 現在、BigQueryで管理しているデータサイズは500TBを超えています。 BigQueryはスキャン量/ストレージ量に応じて従量課金される、インタラクティブなデータ分析ツールとして使用することが可能であり、数TBのデータ量であっても高速に集計を行うことができます。
BigQueryはWeb UIの画面を有していて、その画面からクエリを投入するか、他のツールから投入できるようになっていて、食べログではTableauからも投入できるようにしています。
Tableauについても紹介させていただきます。
Tabeauではデータソースと呼ばれる、さまざまな接続先から取得したデータを結合し、論理テーブルとして利用することができます。先ほどお話しした通り、BigQueryを接続先としてデータを取得しており、公開後は自動更新を設定することも可能です。
データソースから、マウスのドラッグ & ドロップやその他様々な操作によりグラフ、および、ダッシュボードを作れるようになります。
Tableauには、Tableau Desktopというデスクトップアプリケーションと、Tableau Onlineというクラウドサービスが存在しております。今までご紹介していたのは、Tableau Desktop内での操作なのですが、Tableau Onlineにパブリッシュすると、Tableau Online上で作成したダッシュボードを閲覧することができます。
このダッシュボードはURLで共有することができ、データの自動更新もサポートされます。閲覧回数などもウォッチすることができます。このようなダッシュボードの作成がエンジニアでなくても実現でき、私たちエンジニアも手軽に使うことができています。
「データによる意思決定」の視点から見える「開発生産性の改善活動」の6つのステップ
さて、開発生産性の改善活動は「データによる意思決定」の一種であると言えるのか。「データによる意思決定」の立場から、見ていくことにします。
Tabelauのページ[2]で紹介されている内容として、「データによる意思決定」は大きく6つのステップで進行するとされています。私の個人的な感覚としても、この流れに違和感はありません。
プロセス品質ダッシュボードの作成過程もこの作成の流れに沿っており、データによる意思決定と言えると考えております。こちらについて、作成過程と照らし合わせてみていくことにします。
ダッシュボードを作るまでに何が行われたのか
まずは、何を果たすべきか、どのように価値を実現するかについて議論をします。
プロセス品質ダッシュボードの構築を進めていたDeveloperProductivityチームでは、バリューストリームマップというものを作成しています。
これは、社内各所へのヒアリングを進めた上で、開発チームがどのように価値をもたらすのか整理すると共に、どういう改善をすれば開発生産性が上がるのかを整理し、DeveloperProductivityチームとしての果たすべき使命をミッションとして定義したものです。
どの指標を計測し、どのような方向に改善すべきかはバリューストリームマップやミッションから議論することができます。これを踏まえると、開発サイクル、あるいは、開発フェイズのリードタイムを計測し、そのリードタイムを短縮できれば良いことが見えてきます。
では次に、状況を正しく把握できるようにするために、開発サイクルや開発フェイズのリードタイムはどうやって測るべきか、または他にも計測すべきものはないかを調査します。
その中で、PRマージ数や開発チケットの開発からテストまでの日数などを集計することで計測が可能であることが期待できそうなことがわかってきます。そこで、必要なデータを収集し利用可能にします。
このステップ以外はDeveloper Productivityチームが内部で実施されましたが、このステップのみ、データサイエンスチーム側の対応になります。
GitHubのデータは加工できる状態で持っていなかったことから、APIを叩いてデータを取得し、利用可能な状態に整備する必要が出てきます。 毎日APIを叩き、データ基盤に連携し、BigQueryで日々利用できるように対応しました。
データが利用できるようになったので、BigQuery UI/エクセルやTableauを用いて集計と可視化を行い、本当に集計できるのか、集計したもので開発生産性を測れそうかを判断します。
知りたいことを知れるよう、集計の単位を変更したり、フィルタを用意したり、ダッシュボード内でグラフの並び替えを変更したりします。場合によって、思った通りの集計では実現できず、データの取り方を変更、データ取得を再度行うケースも考えられます。ここは試行錯誤の結果改善していくものと理解しています。
ダッシュボードを作ってからどう活用するのか
こうしてある程度、開発生産性を測れるようになったら、課題と解決策を特定します。開発生産性がどうなっているのか、例えば、開発サイクル全体が良くなっているのか悪くなっているのか、ある開発フェイズのリードタイムが良くなったり悪くなったりしていないかなどの状況把握を行い、ドリルダウンの分析やヒアリングを重ねていきます。
そして、前のステップでの結果を共有すると共に、最初のステップで考えていた目的から、どこを優先して解決するべきかについて議論/意思決定をし、具体的なアクションにつなげていきます。
データから読み取れることと現実の状況を踏まえ、取るべき施策を意思決定していきます。
たとえば「ここは簡単そうだけど改善したところで開発生産性への寄与度は小さそうだな」「ここは難しそうだけど開発生産性改善に強く効きそうだから取り組みたい」「リソースの関係ですぐには着手できなさそう」「いつまでにどこまでの改善を進めたい」など、さまざまな条件を考慮しつつ、「プロセス品質ダッシュボード」を活用した開発生産性向上活動を進めていきます。
ここまで「データによる意思決定」の効果的なステップになぞって説明しました。開発生産性の改善活動は「データによる意思決定」の一種であることをご理解いただけたかと思います。
データ基盤はデータの取得と集計のステップを短縮する
さて、ここまで見てきた「データによる意思決定」のプロセスにおいて、データ基盤は本当に必要なものなのでしょうか。実際、データ基盤は必須という訳ではありません。ですが、データ基盤に載せることで、ステップ2からステップ4までの期間を短縮することが可能です。
その理由は、大きく3つに分けて説明できると思います。
一つ目は欲しいデータは既に載っているケースが多く、定常的に最新化され使うことができる点です。データを利用可能にするというのは大変な作業です。開発が必要ですし、データの取得に数時間かかったりすることがあるため、データの利用・最新化には時間がかかります。データ基盤は、組織内で共通利用したいデータを利用可能にする目的で整備されているツールですので、利用価値が高いデータは、過去に要望が出ていてデータ基盤に載っていることが多く、思い立ったらすぐに調査をして、いろんな時間を節約できます。
二つ目は仮に欲しいデータがデータ基盤上になかったとしても、少ない開発量/短い開発リードタイムで追加が可能な点です。データ基盤では、データ取得・蓄積方法はノウハウ化されており、連携仕様や実装を流用することができます。GitHubはAPI連携でしたが、API連携は他にも実績があり、そのコードや設計などを流用することで、開発期間の短期化を実現しています。
三つ目は簡単に手早く分析ができる点です。多くのデータ基盤では、集計のために専用のクエリ言語を備えていることが多く、近年のデータ基盤ではSQLライクの言語であることが多いと考えています。 これは、エンジニアでなくても出来るほど簡単であり、分析を手早く行うことができます。
BIは可視化・合意形成のサイクル全体を短縮する
BIはどうでしょうか?「データによる意思決定」のプロセスにおいて、BIも必須というわけではありません。エクセルで十分なこともあるでしょう。
ですが、BIを併用することで、ステップ4からステップ6までの期間を短縮することが可能だと考えております。
その理由は、大きく3つに分けて説明できると思います。
一つ目は常に最新の情報からの可視化が行え、最新の情報からの判断を行いやすい点です。レポーティングを行う際、問題になりやすいこととして、データの新鮮度の問題があります。分析を進めていくうちに、時間が経過し、データが古くなって最新の状況とはかけ離れてしまったり、定期的に情報をアップデートしたく、定期的に更新を行うことはよくあります。一方、BIは直接データソースと接続できるツールであることが多く、更新を手軽に行えます。自動更新も設定可能であるため、 「共有前に更新」という工程なく、利用することが可能です。
二つ目は関係者間での共有のための機能が充実している点です。合意形成を進める中でインサイトの説明を行うためにグラフを共有する機会が何回も生じます。このような場合にURLを貼れば簡単に共有を行うことができ共有の負荷が軽減されます。BIツールにはコラボレーションの機能が備わっていることも多く、コメントでの報告やディスカッションも可能です。
三つ目は探索的な使い方が可能である点です。インサイトの特定のためには、課題がありそうな対象に絞り込んで分析/可視化をしたいです。 定型化されている分析であれば画面内の操作で完結することができます。
さらにステップ4から6は繰り返し実施されることが多い点にも注意が必要です。
具体的なアクションを取ることで初めて価値が生まれるので、繰り返し実施すればするほど、この取り組みに対する価値が大きくなっていきます。結果、繰り返し実施されるようになるため、工数・作業負荷が大きくなっていきます。
継続更新しやすく共有も容易なTableauなどのBIツールを採用する方が工数削減、運用負担軽減には良いはずだと考えています。
データドリブンな組織の構築は難しい
ここまで「品質ダッシュボード」による開発生産性向上のための取り組みは「データによる意思決定」の一つであることを見てきました。今回この活動は、私たちのチームと普段から関係の深いチームで行われたわけですが、意思決定は組織のさまざまなところで行われています。必然、「データによる意思決定」は、組織のさまざまなところで実現されなければなりません。一般に、「データによる意思決定」が定着している組織の実現は難しいとされています。例えば、Tableau社が開示していた例[2]を見てみても、世の中の事例を見ても30%ほどしか成功しないと言われています。
実際、食べログの事業部内でも「データによる意思決定」が定着しているとは言い難く、富田も様々な取り組みに関わってきたものの、成功率も十分に高いとは言えない状況が続いています。最後のセクションで、失敗事例、成功事例を見ていき、データによる意思決定の成否を分ける要因はなんなのかについて考えてみることにします。
食べログ社内での成功と失敗
いくつか食べログ内であった今までの失敗事例を挙げてみます。メディアで見ているさまざまな指標のダッシュボードを作ってみたことがあります。こちらは、初期のデータ基盤を構築したときに、データ基盤があるなら見てみたいと要望を受けて作ったものですが、どのように使っていくかは想定されていないものでありました。2ヶ月かけて構築したにも関わらず、依頼者を含め、誰にもみられることもなく終了しました。
他にもマーケティング/プロモーション施策用のダッシュボードを作ってみたことがあるのですが、作成したあと継続的に使われないケースが多いと感じます。データ基盤とTableauで作られるケースが何回かありましたが、継続施策だったはずが施策自体が短期で終了となり閲覧されなくなるというのは多いと思います。
一方、数多く携わっていく中で、成功事例と言って良いケースも出てきています。
まず一番の成功事例と言えるのは、食べログ内のとあるクロスファンクショナルチームのダッシュボードです。当初はデータ基盤とエクセルを用いて作成していて、のちに、データ基盤とTableauを用いて改善しました。PMがダッシュボードの仕様についてかなり細かく指示していて、PMが週次のチーム定例で実際に確認の時間をとって、サービスの状況についてコメントするために使っています。最初は食べログの1機能のダッシュボードから始まり、チームの拡大に合わせて他のダッシュボードを吸収合併し、ダッシュボードの閲覧回数が増加していきました。このダッシュボードを使いながら施策のリリースをしていく中でKGIがちゃんと向上しています。
他には、毛色の異なる他の成功事例として、経営レベルのダッシュボードも成功事例と言えるかと思います。アクセス解析ツール/データベースから直接抽出してエクセルで整形するレトロな方式でしたが、のちにデータ抽出をデータ基盤に差し替えています。毎週PM/部長以上の会議で報告に使われ、10年以上使われています。毎年指標が見直され、指標が悪化したら理由を求められるため、PMや部長はちゃんとみています。
ダッシュボードを習慣的に見るための仕組みと継続的な改善が鍵?
失敗事例と成功事例を比較してみると、失敗の要因は少しですけど見えてきます。ダッシュボードから定期的にインサイトを受けようとする組織的な仕組みを用意していなかったり、単純に役に立ってなかったり、継続的な改善が行われていないなどが失敗に至る要因になっているようです。いずれも、閲覧するきっかけを減らすことにつながるので、そういうことがまずいのではないかと考えています。
一方、ツールや開発工数を多くかけることはあまり成否には関係ないのではないかと考えています。当初エクセルで作成されたダッシュボードでも継続的に使われているケースは十分存在します。
ダッシュボードといえど一つのプロダクト、利用者がいないと成立しません。一般的にMVPと呼ばれる、必要最小限の機能を持つプロダクトとしてダッシュボードを作成して、実際に使ってみながら拡大していくように進めるのが良いかもしれません。
まとめ
では、まとめに入ります。
データサイエンスチームは「食べログのデータと科学的なアプローチの両方を用いて、食べログのあらゆる意思決定を支援する」ことをミッションとしたチームであり、そのバリューの出し方の一つとして、ダッシュボードを提供することによるモニタリング・分析の支援があります。今回の発表では、「プロセス品質ダッシュボード」を通じて、活動はデータ利活用の立場からどのように捉えられるのか、その中で、どういう仕組みが刺さるのか、についてお話しさせていただきました。
今回の発表では、3つのことを持ち帰っていただきたいなと思っています。
一つ目は「品質ダッシュボード」による、開発生産性向上のための取り組みは「データによる意思決定」の一つであること。
二つ目は「データによる意思決定」の実現のために意思決定に必要なデータを継続的に更新し、可視化をする仕組みが必要であること。
三つ目は食べログでの「データによる意思決定」推進のために、データ基盤とBIを展開しており、「品質ダッシュボード」はその一応用先として構築されていることです。
ご清聴ありがとうございました。
参考文献
[1]Ques公式サイト