ログの品質向上から始める「データドリブン文化」の定着にむけた取り組み

背景

私は現在、海外旅行予約アプリ「NEWT（ニュート）」を開発する検索体験チームに所属し、カスタマーの予約体験を最大化することをミッションに日々開発を行っています。

検索体験チームでは、カスタマー体験を高めるためのあたらしい取り組みをログデータを分析しながら次々と展開しています。

ログデータにはGoogle Analytics（GA）やDBデータ、APIリクエストログなどがあり、それらをBigQueryに集約しつつ、RedashやGAの探索レポートで可視化しています。しかし、この半年間で施策開発のスピードが向上する一方、リリース後の効果測定が十分に行えないという課題が浮き彫りになってきました。

リリース後にログの不備が発覚するケースも多く、このような状況では振り返りに必要なデータが不足し、即座に取り組みの本質的な効果が見えにくくなることもありました。また、ログの修正作業に時間を割く必要が生じ、新機能の開発時間が削られるといった課題も浮上していました。

こうした課題を解決するために、私たちプロダクト開発チームでは、ログの品質向上に向き合うことになりました🔥

ログの品質をあげるための取り組み

1. 役割の明確化とタスクの自動化で、タスク漏れを防止

ログの不備が発生する原因を整理すると、以下の4点にまとめられました。

分析要件が曖昧で、認識の齟齬が生じている

ログ設計が要件を満たしていない

実装ミスやタイポによる誤ったログ収集

Google Analytics (GA) / Google Tag Manager (GTM) の設定ミスや反映不備

これらの課題に対応するため、検索体験チームでは各フローでの役割と責任範囲を明確にしました。

また、各フェーズにレビュアーを設定し、タスクが自動でチケット化される仕組みを導入することで、タスク漏れを防止しています。

ㅤ	タスク	作成者	レビュー依頼先
1	分析要件	PdM	有識者
2	ログ設計	エンジニアによる持ち回り	PdM、有識者
3	ログ実装	各PFのエンジニア	セルフQAで発火を確認
4	GAの設定	エンジニアによる持ち回り	-
5	GTMの設定	有識者	有識者
6	GTMリリース	有識者	-

成果

これらの取り組みによって、次のような成果が得られました🙆🏻‍♂️

分析要件作成者とログ設計者による相互レビュー

フローを整理し、役割を明確に定義することで、各フローのアウトプットの質が向上しました。特に、分析要件とログ設計の担当者を分けたことで、互いに抜け漏れを確認し合える体制が整い、施策の上流工程で不備を防げるようになりました。

ログ設計をエンジニアが担当し、プラットフォーム間の差異を削減

さらに、ログ設計をPdMからエンジニアが担当するようになったことで、より実装に即した堅牢なログ仕様を構築することができました。

たとえば、「配列を文字列で送信する際にソートを行うかどうか」「値が取得できない場合に空文字・NULL・undefinedのどれを使用するか」のような細かな仕様が、プラットフォーム全体 (iOS・Android・Web)で統一が図れるようになりました。

こうした細かい差異が残ったままリリースされると、リリース後の分析時にそれらを考慮して集計する必要が生じ、非効率になるので、大幅な時間短縮に繋がりました😎

2. リリース前にチェックポイントを設置

品質向上のための重要な取り組みとして、リリース前に開発環境での探索レポート作成プロセスを導入しました。

これまでは、リリース後にGAの探索レポートを使って施策の分析を行っていましたが、この方法では不具合の発見が後手に回り、修正コストが膨らむケースがありました。

そこで、リリース前に手が空いたエンジニアに「イベントの発火確認チケット」をアサインし以下のチェックを行うプロセスを確立しました。

GAのdebug viewでのイベントの発火タイミングや値の検証

探索レポートで要件が設計通りに算出されるかの検証

成果

この取り組みにより、タイポや設定ミス、計測漏れなどの技術的な不具合を早期に発見できるようになりました。

「データドリブンな文化」を定着させるための取り組み

これまで説明してきた品質向上の取り組みにより、より信頼性の高いログを整備することができてきました。

しかし、ログを正しく収集できるようになっても、振り返りが後回しになっては意味がありません。データドリブンの施策をチームで進めていくには、チーム全体がログを大事にする文化の定着が必要です。

検索体験チームでは以下のような取り組みを行ってきました。

1. Redashを活用した施策モニタリング

従来、施策リリース後の分析は、PdMが任意参加の全体ミーティングで報告する形式にとどまっていました。この方法では、施策の振り返りが個人に頼ったものになり、チーム全体での改善に繋げにくいという課題がありました。

そこで、チーム全体で施策の進捗や影響を共有し、次のアクションに活かせるよう、Redashを活用して定期的な施策のモニタリングを行う仕組みを導入しました。

取り組み前：PdMがGAの探索レポートを用いて分析 ⇒ 全体会議で報告

取り組み後：エンジニアがRedashでグラフ化 ⇒ 週1でモニタリング

成果

この新しいモニタリング体制により、施策の影響や効果を視覚的に把握しやすくなり、チーム全体での振り返りが定着しました。

チーム全体での施策振り返りが定着

Redashによるデータの視覚化を通じて、施策の効果をチーム全員が共有できるようになりました。

これにより、各メンバーが施策の成果を「自分ごと」として捉え、次の施策や改善点をチーム全体で議論・共有できる雰囲気になりました。

データ遷移のモニタリングで異常検知が可能に

従来の単発的な探索レポートでは瞬間的な分析に限られていましたが、Redashを活用することでデータの推移から異常の兆候を早期に発見できるようになりました。

2. ログ設計・ログ分析の担当を持ち回り制に変更

データドリブンな意思決定を実現するには、ログの設計から分析まで、チーム全体が関われる環境づくりが重要です。そこで、これまで特定の有識者が担当していたログの設計と分析を、施策ごとの持ち回り制に変更しました。

この変更により、各メンバーがログと向き合う機会が増え、自然とログへの理解が深まっていきました。同時に、知見を共有する必要性も生まれ、ドキュメント整備も現在進行系で進んでいます。

成果

「とりあえずログを入れておく」から「分析を見据えたログ設計」へと、チームの意識が大きく変化しました。

施策の企画段階から「どのようなデータで効果を検証するか」を議論するようになり、より効果的なPDCAサイクルを回せるようになりました。

まとめ

検索体験チームでは、ログを活用した施策の効果検証と改善プロセスの推進に向けて、ログ設計や分析フローの見直しを行い、データドリブンな文化の定着に努めてきました。チーム全体でモニタリング体制やリリース前のチェックポイントを導入したことで、施策の振り返りが効率化され、改善点の発見もスムーズになりました。

また、持ち回り制や標準化されたドキュメントの整備により、チームメンバー全員がデータに基づく意思決定に積極的に関わり、施策を「自分ごと」として捉える意識が根付き始めました。エンジニアも主体的にKPIやミッションに責任を持ち、「こんな施策をやると良さそう」といったアイデアが様々に生まれています🔥

今後は、この文化や取り組みを検索体験チームにとどまらず、プロダクトチーム全体に展開して行く予定です。

「NEWT Tech Talk vol.12」のお知らせ

令和トラベルでは、定期的に技術や組織に関する情報発信を目的として、「NEWT Tech Talk」を毎月開催しております！

11月開催は『TypeScriptによるBackend開発 ~開発効率化と運用改善のくふう~』と題して、TypeScriptを採用したBackend開発における、開発効率化や運用改善のための取り組みをご紹介する予定です。オンライン・オフラインのハイブリット開催となりますので、ご興味のある方はぜひご参加ください！

TypeScriptによるBackend開発 ~開発効率化と運用改善のくふう~ (2024/11/28 19:30〜)

# オフライン（現地）参加枠を増枠しました！おかげさまで、たくさんのみなさまにご興味を持っていただき、オフライン（現地）参加枠が満席となりましたので、【5枠限定】で増枠をいたしました！まだまだ募集中ですので、ぜひご参加くださいませ！ # 📍 イベント概要 NEWT Tech Talkは、技術的な知見を共有しあうことを目的とした勉強会です。前回に引き続き、弊社オフィスとオンラインのハイブリッド形式で開催します。今月は、「TypeScriptによるBackend開発 -開発効率化と運用改善のくふう-」と題して、LT形式で発表を行います！令和トラベルではBacke...