こんにちは、バクラクの請求書受取・仕訳チームでソフトウェアエンジニアをしている id:wataru_lx です。 年末は毎年そばを打っており、今年は十割そばに挑戦します！成功したことはありません。
この記事はLayerXテックアドカレ（概念）の48日目の記事です。昨日は@coco_tyw さんの「VeeValidate v4 の破壊的変更を互換コンポーネントで乗り切った話」をお届けしました。明日は id:sadayoshi_tada さんが担当します。
ありがたいことに、利用されるお客様やシステムで処理する請求書の数も日々増加しており、それに伴いパフォーマンスに関するお問い合わせも増えています。これを受け、私たちはパフォーマンス改善をOKRに掲げ、具体的な取り組みを進めてきました。 パフォーマンス改善は終わりがない旅のようでまだ始まったばかりですが、今回はその改善プロセスついて紹介します。
1. OKRの設定
まずは目標を明確にし、進捗を追跡することが重要だと考えました。
多くの方法がありますが、バクラクではOKRを採用しているので、チームOKRの一部にパフォーマンス改善に関する項目を追加することにしました。これにより、具体的な目標設定と、OKRをトラックすることでその達成度を定期的に評価するようになります。また、定期的な振り返りも仕組み化されているとなお良いですね。
パフォーマンス改善、と一言でいってもかなり幅広く、優先度をつけて実行していく必要があります。 どの体験から改善していくかは、DevOps チームと一緒にCUJ(Critical User Journey)を定義するところから始めました。
その具体的な取り組みについては id:sadayoshi_tada さんの記事をご参照ください。
2. 計測する
「推測するな、計測せよ」という言葉がありますが、現状の課題を把握するためもまずきちんと計測することから始めました。また、改善結果の振り返りを行う際にも計測していないと定量的な評価はできません。
もともと計測自体は行われているものの、メトリクスの収集に関して不十分な箇所があり、これを機に整えました。
バクラクではサービスの監視にDatadogを使用しており、Application Performance Monitoring(以下APM)やログ管理にも利用しております。
具体的には以下のような実装をし、必要なメトリクスが収集されるようにしました。
- ログに不足していた項目の追加
- レイテンシの単位が一部ブレていたので統一
- APMが導入されていなかったコンポーネントにも導入
- SQLTraceにお客様を識別するIDの追加
- Trace情報のサービス間伝搬
そしてそのメトリクスを元に、前述したCUJに基づいたフォーカスしたいお客様体験に関するDatadogのダッシュボードを作成しました。今後の改善、振り返りのサイクルの中で何度も見ていくことになります。
また、バックエンドのAPIやDBのフォーマンスだけでなく、フロントエンドからみたパフォーマンスも計測の対象としました。
お客様の体験を改善するには、フロントエンドからみたパフォーマンスのほうがより実態に近いと考えたからです。そのためダッシュボードにはDatadog Real User Monitoring(以下RUM)で収集したメトリクスなど、 フロントエンド側のメトリクスも含めています。
3. 改善
計測した結果をもとに、改善できそうな箇所を見つけて実装していきます。改善案を考える際にはDatadogのAPMそのTrace情報も役立ちました。例えば時間がかかっている処理やSQLクエリの特定や、お客様ごとの特定の処理のレイテンシなどをかんたんに見ることができます。
今回の主題ではないため詳細には書きませんが、以下のような改善を実装していきました。
- レスポンスのgzip圧縮
- SQLのクエリを最適化
- 時間がかかっている処理の並列化
- 画面描画に必要ない情報のフェッチを必要なタイミングまで遅らせる
- JSのbundleサイズ削減
4. 振り返り
出して終わりではなく、結果を見て振り返ることも大切です。リリース前後で関係者で集まってダッシュボードのメトリクスをチェックし、どれくらい改善したかの評価を行い、ネクストアクションを決めました。
また、どのバージョンでどのような改善施策がリリースされるのかと、リリース前後のメトリクスをスナップショットとして記録しました。リリース後すぐに振り返りを実施することが理想ですが、記録しておくことであとから振り返ることも可能になります。
この「改善」、「振り返り」のサイクルを複数回実行することで目標達成にむけて進捗していき、今年の第3四半期（Q3）の終わりには、この期間中の改善結果のサマリを作成しました。普段振り返りに参加していないメンバーやチーム内外への成果の共有が容易になりますし、OKRの達成度をトラックする上でも四半期ごとなどのまとまった単位でも結果をまとめておくことは有効です。
5. さらなる改善に向けて
ここまで全お客様を対象とした目標値に対する改善を行ってきましたが、実はお客様によってパフォーマンスが大きく異なることが計測の結果わかっています。請求書受取・仕訳では複雑なフィルター機能などもサポートしているため、お客様の利用方法によっても体験に差が出る可能性がありますし、全体だけを見ていると個別のお客様の問題を見落としてしまうかもしれません。
計測を行った結果、特定のお客様でRUMのLong Task*1のメトリクスの数値が悪いことに気が付きました。お客様環境でどのような問題が起きているのかを特定するためにDatadogのSession Replayを導入して録画された画面操作などを見てみましたが具体的な問題特定には至りませんでした。
そこで、直接お客様のもとへ行き、日次や月次の業務でのバクラクの請求書受取・仕訳の利用方法やペインポイントについてヒアリングをしたり実際の画面操作を見せてもらうことを予定をしています。
個々のお客様に対する解像度を上げることで、より具体的かつ効果的な改善策を見つけ出すことがねらいです。前述したDatadogのダッシュボードにも、全体だけではなくベンチマークとしている個別のお客様だけで絞り込んだメトリクスも表示しています。
また、これらの学びは他のお客様にも適用可能であり、最終的には全体的なお客様体験の向上に繋がると信じています。
おわりに
バクラクの請求書受取・仕訳チームが直面しているパフォーマンスの課題にどのように取り組んでいるかを紹介しました。私たちの取り組みは、目標設定（OKR）の明確化から始まり、実際のパフォーマンス計測、データに基づく改善策の実施、そしてその結果の振り返りという一連のサイクルを実施してきました。
パフォーマンス改善の旅はまだ始まったばかりですが、この継続的な改善プロセスを通じてよりお客様のハタラクをバクラクにしていきます！
LayerXではお客様のハタラクをバクラクにするプロダクトを一緒に開発する仲間を大募集中です！LayerX Casual Night というプロダクトやチーム、技術の話をゆる〜く行うイベントも開催しておりますので、興味を持たれた方はぜひご参加ください！次回は2024/1/30(火)開催で、日本酒 Nightです。
*1:ブラウザのメインスレッドを占有するような実行時間が長いタスク
