こんにちは、Sansanの杉原です。BtoBサービスのSansanのブラウザアプリケーションのエンジニア兼プロダクトマネージャーをしています。
今回はブラウザアプリのパフォーマンスにおける速度（*1）で苦い経験をしたエンジニアが、プロダクトマネージャーになって速度とどう向き合っているかを紹介したいと思います。 まず結論から言うと私がプロダクトマネージャーとして速度と向き合う時の取り組みはシンプルに次の３つです。
- 定期的に計測する
- 効果が高いところから始める
- 速度目標を設定する
以降ではなぜ速度に向き合うようになったのか、また向き合う時に気をつけていることをお話します。 私の経験がBtoBサービスなどで速度改善に取り組む皆さんの何らかの気づきになれば幸いです。
なぜ速度に向き合うようになったか
それはエンジニアとして参加したプロジェクトの苦い経験がきっかけでした。
そのプロジェクトは外部連携も含めて非常に多くの機能を取り込み、かつビジネス的にも大きく期待されたプロジェクトでした。 その期待に答えるため、エンジニアとして機能を必死に実装しました。また、さまざまな問題もありましたがチームで乗り越えて何とかリリースにまでこぎつけました。
しかし、そのプロジェクトで私は大きな失敗を２つしました。 その１つがレスポンス速度に比重を置けなかったことでした（*2）。
案の定、リリースしてすぐに社内外から遅いという声が聞こえてきました。 せっかく苦労して多くの機能を実現したのに聞こえてくるのは遅いという声ばかり。盛り込んだ多くの機能は使ってもらえてるかすらわかりません。 これは私にとってはとても苦い思い出になりました。 しかし、この経験で私は速度は機能であること（*3）を学びました。 そして、この学びがSansanの速度に向き合うきっかけになりました。
どうやって速度に向き合っているのか
冒頭でも説明したようにやっていることはシンプルな３つです。
- 定期的に計測する
- 効果が高いところから始める
- 速度目標を設定する
定期的に計測する
私が定期的に計測するで大切にしているのは以下です。
- 定期的に行うこと
- 複数のパーセンタイルに注目すること
- 全体だけでなく、テナント単位で見ること
まず「定期的に行うこと」です。
Sansanでは毎週リリースがあります。 そして有難いことに日々新たなお客様が使い始めてくれます。その上で、既存のお客様も含めてたくさんの名刺をスキャンしてくれてデータ量も増えています。 それにより、リリース時には問題なくても時間がたつにつれて速度が遅くなってしまうことがあります。 そのため、定期的（１週間〜２週間に１度）に各エンドポイントの速度を測定するようにしています（*4）。
次に「複数のパーセンタイルに注目すること」です。
まずは典型的なユーザの待ち時間である中央値（50パーセンタイル）です。これは説明するまでもありませんね。 そして、99パーセンタイルです。これは100リクエストあった場合に99リクエストはこの値以内で処理されたことを表しています。 なぜ、この数値を重視しているかと言えば、通常はデータ量の増加に比例して速度は遅くなります（*5）。 そして、データ量が多いお客様はとはすなわちSansanをよく使ってくれているお客様であることが多いからです。 また最大値で行わない理由は、残りの1%は例外的かつ非常にコストがかかることが多いためです。 これが99パーセンタイルに注目している理由になります。
また、「全体だけでなく、テナント単位で見ること」も大切にしています。
Sansanでは様々な規模の企業にご利用いただいています。ひとつの企業で多くのアカウントをご利用いただいていると、データ量が多くなりがちです。 そのため、ほかのお客様においては問題なくても、そのような企業においては速度が非常に遅いというパターンが多くあります。 テナント単位で見ることで規模による速度劣化を見逃さないようにしています。 また、この場合においてもパーセンタイルは重要視しています。 なぜなら、BtoBサービスであるために、参照権限を制限して使われる場合が多々あるからです。 すなわち参照できるデータ量が多い（≒ 速度が遅い）ということは管理者やマネージャーの可能性があり、そのテナントにおけるキーマンであることが多いと言えます。 また、最大値で見ないことよる漏れもテナント単位でも99パーセンタイル確認することで防ぐことができます。
効果の高いところから始める
次に定期的に計測することで発見した問題について、対応する優先度を決めていきます。 2007年にサービスを開始したSansanには非常に多くの機能があり、そして今もなお進化の途中です。 よって、既存のすべての機能をチューニングするという施策は現実的ではありません。
そのため、本当はすべてをもっと早くしたいのですが、私は次の基準で対応の優先度を選んでいます。
- 処理量（リクエスト数）
- ユーザーにとって重要な速度か
- 機能利用を強く疎外するほど速度が劣化しているか
「処理量（リクエスト数）」に関しては、言うまでもないですね。たくさんのユーザが使ってくれている機能から始めます。 この時、自動的に実行される処理などには注意します。
次の「ユーザーにとって重要な速度か」は、例えば１つのUIに複数のエンドポイントがあれば体験のボトルネックになっているエンドポイントからチューニングするべきです。 例えば、UIの工夫によってバックエンドで動いている処理であれば少しぐらい遅くてもユーザは気づきません。
最後は「機能利用を強く疎外するほど速度が劣化しているか」です。 これは遅ければ使われないという苦い経験から施行錯誤して考えたルールになっています。 ルール自体は一番定性的な判断になってしまうのですが、シンプルな速度比較に加えて、NPS（*6）やフロントメンバーやコミュニティの声を大切にしています。 なぜなら機能利用における必要な速度とは、利用頻度やユースケースにおいても異なり速度比較だけでは測りきれないときがあるからです。
そして、この優先度で選んだ速度課題を定期的にプロダクトBacklog（*7）に載せています。 この速度課題は他の機能追加と同様に機能として優先度を比較し開発に着手されます。
速度目標を設定する
既存機能を速くすることも大事ですが、機能追加や改善の際に新しく遅い機能を作らないことも大切です。 そのため、私がプロジェクトを開始するときには、速度目標を設定するようにしています。 目標のポイントは次の通りです。
- 中央値だけでなく、99パーセンタイルに対しても目標を設定する
- 目標が達成できそうかをプロジェクトの早いタイミングでエンジニアと会話する
- 目標が達成できたかを評価する
まず、「中央値だけでなく、99パーセンタイルに対しても目標を設定する」です。 こちらは計測と同様の理由になります。
次に「目標が達成できそうかをプロジェクトの早いタイミングでエンジニアと会話する」です。 これは 速度も機能であるため、他の機能と同様に作り込む必要があります。そのため、速度は最後にテストするのでは遅いと考えています。 これにより、早いタイミングでエンジニアと会話し課題を洗い出すことで、遅くなる原因になるUI設計などを防ぐことができます。 実際にUI設計を変更することで処理時間が大幅に減少することは多くあります。 また、計画においては、事前に速度改善のための施策やテストをする時間を確保することができます。 そして実装においても、エンジニアは速度が悪化するようなコードを避けてくれます。
最後に「目標が達成できたかを評価する」です。 当たり前ですが、目標は達成できたかを評価するべきです。 目標を設定すればリリース前に目標に対してエンジニアは速度テストを行ってくれます。 しかし、すべてのパターンで行えるわけではありません。また、結果は自分たちの施策が目標に対して過不足がなかったのかも含めて次の改善へのヒントにもなります。 そのため、リリース後にはしっかりと計測してエンジニアに結果を伝えるようにしています。
まとめ
「速度に向き合う」をテーマに私が行っている次の３つのプロセスを紹介しました。
- 定期的に計測する
- 効果が高いところから始める
- 速度目標を設定する
「一定の基準でアラートを出してすべてやった方が効率的だ」、「Amazonのようにすべて99.9パーセンタイルで評価すれば良い」など様々な意見があると思います。 それも一つの方法だと思います。 しかし、プロダクトの進化も止めずに既存の機能の改善を進めていく現在のSansanにおいては、一律で行うよりも優先度の高いものに注力する方が多くのユーザに対して高い価値を提供できるのではないかと考えています。
今後もよりユーザ価値高いプロダクトになっていくために、このプロセスの改善も含めて速度に向き合っていこうと思います。
▼本文内でご紹介した記事
*1:この記事ではレスポンス速度（主にサーバーサイド）のことを指します
*2: 残りの１つはまたの別の機会に
*3:だからこの記事もとても好きです。
「うわっ…弊社のサービス、遅すぎ…？」を New Relic で劇的に速くした話 - Sansan Builders Box
*4:タイムアウトなどの緊急性の高い問題に対してはより高頻度にチェックしています。
*5:一部の例外はあります。この例外が曲者だったりするのですが。
*6:Net Promoter Score のこと。NPSへの取り組みはこちらで。 NPS®をプロダクト改善に活かす - Sansan Builders Box
*7:開発におけるTODOリストようなもの。プロダクトBacklogへの取り組みはこちらで。 プロダクトバックログ一本化の裏側 - Sansan Builders Box
