推測するな、計測しろ!!! 感覚に頼らない体験改善へ

はじめに

はじめまして。
プロダクトマネジメント部の仙石です。

私たちは最近、アプリの体験改善プロジェクトに取り組みました。
本記事では、その中で生じた課題と、チームの意思決定を変えたテーマについてシェアします。

エンジニアの方はもちろん、非エンジニアの開発関係者の方にも分かりやすく解説します！

体感による評価の限界

体験改善を進める中で、私たちはある課題に直面していました。
「良い・悪い」の判断が、非常に感覚的になりがちだったということです。

たとえばパフォーマンスについて「なんか重い……」という声が上がっても、それが端末/ネットワークの問題なのか、アプリ自体の問題なのか、体感だけでは切り分けられません。
改善を実施した後も「なんとなくよくなった気がする」といった主観に頼る状態では、ボトルネックの特定や次に着手すべき優先順位の決定が困難になります。

推測するな、計測しろ！

この感覚頼りの議論から脱却するため、チームではあるテーマを掲げました。
それが「推測するな、計測しろ！（Don't guess, Measure!）」です。

私たちはこのテーマを元に、まずは正しく計測できる環境作りに取り組むことにしました。
すでに社内で利用していた監視・分析プラットフォーム「Datadog」をアプリでも活用し、詳細な計測ができるようにしました。

https://www.datadoghq.com/ja/

具体的には以下のような項目を計測可能にして、客観的な数値を共通言語としてチーム全体の目線を揃えることを目指しました。

• ユーザーがどの画面を見たか
• 画面表示までに「何ミリ秒」かかったか
• どのデータ取得処理が「何回」実行されているか
• データ取得に「何ミリ秒」かかっているのか

※値はデモ用に変換しております

この事実を可視化したことで、チームの議論は変わりました。

• 「パフォーマンスが悪い箇所はわかった。このAPI自体を速くするべきか、データの取得方法を変えるべきか？」
• 「ここは遷移の頻度が多い画面だから、ここから最優先で改善を進めるべきだ」

など数値に基づいた建設的な議論と、迷いのない優先順位づけができるようになりました。

おわりに

今回お伝えしたかったのは技術やツールの選定そのものではなく、「推測するな、計測しろ！」というテーマをチームの共通目標として掲げたことです。

実はこの言葉には元ネタがあります。
ソフトウェアエンジニアのRob Pike氏が1989年に記したエッセイ『Cプログラミングに関する覚書』に登場するルールです。

ルール1：プログラムのどこで時間を消費するかを知ることはできない。ボトルネックは驚くべき箇所で起こる。したがって、どこがボトルネックか証明するまでは、推測でスピードハックを入れようとしてはならない。

ルール2：計測すべし（Measure.）。計測するまでは速度のための調整をしてはならない。

これはプログラミングの文脈で語られた格言ですが、プロダクト開発に関わるメンバーが知っておくべき考え方だと思っています。

「ユーザーはここを使いにくく感じているはず」「この機能を追加すれば喜ばれるはず」といった推測だけで進めると、本当に解決すべき課題からズレてしまいます。企画やデザイン、マーケティングなど、どの領域においても「まずはデータを計測し、事実に基づいて議論する」という姿勢が、チームを一丸とし、正しい方向へ導いてくれます。

皆さんのチームでも、ぜひ「推測するな、計測しろ！」をテーマにしてみてください！