Garoon開発チームのぱくとま (@pakutoma) です。
Garoon開発チームを紹介する全5回の記事も今回が4回目です！
前回：GaroonのFour Keysを改善するHanamiチームの紹介
今回は、Garoonのパフォーマンスを改善する新チーム、Nozomiチームを紹介します！
Garoonをストレスなく使ってもらうためのチーム
Nozomiチームは、Garoonのパフォーマンス改善に取り組むチームです。 Garoonをたくさんの人にストレスなく使ってもらうことを目標としています！
Garoonは、数万人規模の大企業でも活用していただいています。 数万人のお客さまが毎朝一斉にメールチェックをしたり、一日のスケジュールを確認したりする時間帯がGaroonのピークタイムになります。 そんな時にGaroonがもっとサクサク動作するようになれば、チームワークがもっともっと良くなるはずですよね！
いつでもストレスなく動くGaroonが提供できることを目指して、Nozomiチームは日々パフォーマンス改善に取り組んでいます。
出来たてほやほやのチームです
Nozomiチームは、まだ活動開始から3ヶ月、メンバーも2人しかいない出来たてほやほやのチームです！ 先日やっと一つ目のプロジェクトを終えられた、そんな立ち上げ真っただ中の段階です。
まだ走りはじめたばかりのチームですので、チーム紹介の場をお借りしてNozomiチームを立ち上げた時の話をさせてもらおうと思います。
Nozomiチームは今年で新卒入社二年目の私ぱくとまと、私が元々所属していたYukimiチームの先輩である赤間の2人で活動しているチームです。 チームの始まりは、性能問題に苦しめられた私が「性能チームを作りたいです！」とGaroonチーム全体に呼びかけたことでした。
初めて関わったプロジェクトで性能問題に苦しむ
2022年の11月末ごろ、私が所属するYukimiチームが抱えるGaroonのPHP 8.1移行プロジェクトは大詰めを迎えていました。修正が全て終わり、あとはリリースするだけというある日、事件が起こりました。
プロダクトの性能検証で測定値の劣化が確認され、リリース基準に達しないことからリリースが中止になったのです。性能検証との長い戦いが始まりました。 当時のGaroonの性能検証は、リリース候補バージョンに大規模な負荷テストを実行し、その負荷テストにパスする仮想ユーザー数を過去のバージョンと比較するというものでした。
この仕組みは製品の許容ユーザー数を見積もるためには適していますが、性能劣化の原因を探るためにはあまり役に立ちません。遅いリクエストが分かるだけで、そのリクエストのパラメータや呼び出すメソッド、時間のかかる処理などがこの性能検証からは分からないためです。それに、性能検証に利用するデータやシナリオはブラックボックス化しており、チームの誰も分からない状態でした。
性能検証をパスするための1ヶ月ほど、目隠しで宝探しをするような気分で性能劣化の原因を探していました。見つかった原因はPHP 8.1から出るようになったログが大量にファイルに書き込まれていることだったのですが、良い性能検証の仕組みがあればもっと早く気がつけていたはずです。
性能問題を扱うチームがない！チームを作ろう！
年が明けた2023年1月、性能検証の仕組みに疑問を持った私はチームをまたいで多くのメンバーと話し、性能に関する課題を集めました。その結果、次のような課題を知ることができました。
現状の性能検証に不満があるメンバーは少なくないこと。 それを改善出来ないのは、性能について詳しい人が少なく、性能問題を扱うチームも存在しないので良い仕組みを作れないためであること。
何より、性能問題を扱うチームがないことは性能検証だけでなく、Garoonの性能問題の解決が難しいことや、大規模ユーザーの受け入れが難しいことにもつながっていること。
これは大きな課題だ！と思いました。性能問題を扱うチームが出来れば、Garoonがもっと良くなるに違いありません！
そんなわけで、性能チームを作りたい！という気持ちを人材マネージャーと興味のありそうなメンバーに共有しました。
ここからチームの立ち上げに向けて動き出しました。CIパイプラインの移行や新人の受け入れ、インターンシップの面接などをこなしながら準備を進め、7月にNozomiチームを立ち上げることができました。
まずはノウハウを蓄積する
Nozomiチームを立ち上げて最初にぶつかった壁が、タスクの優先順位でした。性能に関する課題はたくさんあるのにメンバーは2人だけです。取り組むこと・取り組まないことを決めないとタスクに押しつぶされてしまいます！
タスクの優先順位決めと一言で言っても、メンバーそれぞれで優先したいことは違いますし、他のチームから求められる役割もあります。2ヶ月かけて議論した結論が以下のものです。
「Garoonの性能問題のうち、短期的な解決が難しいものを数ヶ月かけて解決する」
Nozomiチームでは、短期的な性能問題の対応や長期的な仕組み作りは一旦扱わないことにしたのです。 なぜなら今Nozomiチームに必要なことは問題の解決そのものではなく、そのためのノウハウを貯めることだったからです。
短期的な性能問題の対応をするにはNozomiチームのリソースが足りませんし、長期的な仕組み作りに必要な性能に関するノウハウもNozomiチームにはまだ足りません。現在のリソースでノウハウを蓄積するには、数ヶ月で解決するサイズの問題が最適でした。
最初のプロジェクトが完了
Nozomiチームのタスクの進め方を模索するために、スケジュールアプリのある機能のパフォーマンス改善に取り組みました。
プロジェクトを始める際に『詳解システム・パフォーマンス』をメンバーで読み、内容について話し合って「性能劣化の真の原因を見つけてから改善すること」をプロジェクトの目標として決めました。
この目標は、一つのデータから問題らしいものを見つけてすぐに改善に取り組むのではなく、データから立てた仮説に対して複数のデータからそれが真の原因であることを検証してから改善に取り組むというものです。仮説の検証には時間がかかりますが、検証せずに実装するより早く問題が修正できることも多いです。また、意味のない改善や最適化によってリソースを無駄にしたり、コードを複雑にしてしまうことが避けられます。
決めた目標を元にプロジェクトを進めたところ、この機能のレイテンシを60倍も高速化できました。効果が大きい上に技術的にも面白い改善だったので、詳細はまたInside Outに投稿します！
今後のNozomiチーム
タスクの優先順位も決まり、一つ目のプロジェクトの完了も経験したNozomiチームですが、まだまだやりたいことはたくさんあります。
Nozomiチームの喫緊の課題はノウハウとリソースです。短期的にはGaroonの性能問題に向き合いつつノウハウを蓄積し、長期的にはリソースに余裕を作ってGaroonの性能が機能追加や修正のたびに上がっていくようなカルチャーや仕組み作りを目指しています！
改善を続けていくGaroonとNozomiチームをよろしくお願いします！
