LayerX エンジニアブログ

LayerX の エンジニアブログです。

プロダクト開発チームとDevOpsチームでのプロダクト課題改善の取り組み

こんにちは!バクラク事業部 Platform Engineering 部 DevOps チームの id:sadayoshi_tada (@tada_infra)です。趣味でボディビルディングの大会に出ているのですが、フィジークという部門で今年初めて入賞することができました。来年は更に良い成績を目指してデカい男になりたいです 💪

この記事は SRE Advent Calendar 2023 5日目の記事です。4日目は@egmcさんのIaC、あるいはインフラ抽象化レイヤー導入時に考えたらいいんじゃないかと思うことを雑多に書くという記事でした。本記事では、私とプロダクト開発チームで行った、プロダクトの課題改善の取り組みについてお話を書いていきます。

qiita.com

DevOpsチームのプロダクト開発チームとの関わり方

本題に入る前に DevOps チームとプロダクト開発チームの関わり方を紹介します。バクラク事業部では支出管理をなめらかに一本化するSaaS「バクラク」を開発しており、2021年1月に最初のプロダクト「バクラク請求書受取・仕訳」を提供開始以降、「バクラク申請」、「バクラク電子帳簿保存」、「バクラク経費精算」、「バクラクビジネスカード」、「バクラク請求書発行」など、合計6プロダクトを提供しています。

bakuraku.jp

これまではアドホックに課題を一緒に解決する動きをしてきたのですが、サービスがスケールしていくに伴ってそれぞれのプロダクトで様々な課題が出てきました。 プロダクト開発チームとのコミュニケーションを密にして連携を深めていくため、プロダクト毎に担当者を置き各プロダクトごとの課題に取り組むようにしていくことにしました(Embeded SRE の動きのイメージです)。

バクラク請求書受取・仕訳チームとの取り組み紹介

私はバクラク請求書受取・仕訳チームと共に課題にあたっており、この記事では課題の中でもシステムのレイテンシー改善を一緒に対応した時の取り組みを紹介します。

CUJ を使った課題の精査

まず、プロダクト開発チームと課題についての精査をしていきました。課題に対してどういう方針であたっていくかの1つの指標として、Critical User Journey (以下、CUJ)を使って考えていくことを提案しました。というのもパフォーマンス課題改善を図る中でお客様の体験が変わる変化を起こせないと良くないと思い、お客様にとっての重要な体験にフォーカスした取り組みを進められるよう CUJ を開発チームに進言して方針として採用されました。

CUJ の検討においては開発チームとPdMを交えて話し合いを行ったのですが、下記の記事を参照させていただきつつ事前にプロダクトの機能の中でお客様にとって重要な体験をリストアップし、選別していきました。

medium.com

プロダクト開発チームと PdM と一緒に重要な体験を列挙した際のイメージ

プロダクトの機能ごとに重要な体験を列挙し、重点的に課題改善を取り組むものを赤丸のオブジェクトで投票して選別しました。

上記の話し合いを経て日々のお客様の業務からバクラク請求書受取・仕訳がどのように使われていて、この機能の体験が悪いとバクラクを届けきれてない、といったコミュニケーションができたことが良かったです。そして、付箋紙でリストアップ機能の中から参加者が重要と思う体験の機能を選び、レイテンシー改善を図っていくことにしました。

改善アクション前の目標値検討

実際の改善活動を行う前に目標値検討をプロダクト開発チームと行い、フロントエンドとバックエンドそれぞれで目標値を掲げて対応していくことにしました。

フロントエンドの目標検討イメージ

フロントエンドでは直近のメトリクス推移から目標値を99%タイルで特定パスのLCPを4秒台にすることを目指していくことにしました。

バックエンドの目標検討イメージ

バックエンドでは直近のメトリクス推移から目標値を99%タイルでレイテンシーを3秒以内に収めることを目指すことにしました。

改善アクションと実施後の振り返り

目標値を定めたので、具体の改善アクションに移していきました。改善のアクションがどのリリースで反映されているか、反映される前後のレイテンシーの状況を記録して定期的に振返りできるようにし、次の改善計画に使っています。

振り返りのイメージ

改善後の結果サマリ

最後に直近行った、フロントエンドの改善とバックエンドの改善の結果について簡単にまとめます。フロントエンドは特定パスのLCPを短くしていく動きをしていたのですが、 99%タイルで改善前39.9秒かかっていたのが改善後21.06秒になり、10秒以上の短縮につながりました。

改善前

改善後

また、バックエンドの方はリリース前後のレイテンシーを比較で見た時(赤の点線がリリース前で青の実線がリリース後です)、最大約1秒ほどのレイテンシー改善が見られました。

バックエンドリリース前後のレイテンシー比較

99%タイルで改善前3.91秒かかっていたのが、改善後2.66秒に改善しました。

加えてバックエンドの DB では Amazon Aurora MySQL 互換を使っているのですが、Aurora AutoScaling がお客様の業務でアクセスが集中するタイミングに必要なスケールアウトが間に合ってなくてレイテンシーが劣化してる動きを観測しました。そこで Schedule AutoScaling でスケールアウトの調整を行ってバックエンドのレイテンシー劣化を改善することができました。

まとめ

私とプロダクト開発チームで行った、プロダクトの課題改善に関するお話を書きました。引続き共に改善に取り組み、1つずつ積み上げてお客様へバクラクな体験を届けていきます。まだ取り組み中のこともあるため、それらは整えたらまた別の記事として書きたいと思います。

最後に

弊社では共に世の中をバクラクにしてくれる仲間を絶賛募集中です!もし気になることや話したいトピックなどがありましたらカジュアルにお話しましょう〜LayerX Casual Night というお酒を飲みながらカジュアル面談よりカジュアルにゆる~く話せるイベントも開催しておりますので、ぜひご参加ください🍻

jobs.layerx.co.jp

また、個別のカジュアル面談のページもありまして、最初は面談だけでOK等であれば下記のリンク先から応募いただけると幸いです!

jobs.layerx.co.jp