皆さんは普段からアプリケーションのパフォーマンスを気にしながら開発や運用を行っているでしょうか。気にしているという方は日々の監視や、いざパフォーマンスが落ちたときの対応などはどのように行っているでしょうか。パフォーマンスを監視、改善するためのチームがあり、短中期的な目標を掲げて日々アプリケーションやインフラ、開発環境などの改善に努めています1。本記事ではそんなチームを作った経緯や実際にやってきたことをご紹介します。遅いものはなんでも速くしたい私が入社して1年ほど経ちますが、毎日のように新しい機能がバンバンリリースされている裏側で、ある程度アプリケーションのパフォーマンスが犠牲にされているケースを垣間見ることがありました。各種サービスを取り巻く開発環境やCI、デプロイなど「速度」に関する改善点はいくつも見られ何かと「あー遅いな」と思うシーンがありました。その一方で同じように遅いと感じているエンジニアが沢山いて「直したいけど手を付けられていない」という状況であることを把握しました。改善を行ってきた方も沢山いましたがアプリケーションの成長に追いついていないようでした。パフォーマンス改善は組織的に継続する必要ありたまたま所属していたチームのタスクとしてパフォーマンス改善を行う機会があり、監視する環境を整えたり、いくつか改善をしました。時間は限られており、その中でできることも限られていました。そこでもっと多くのエンジニアが参加して知見を共有しながら改善していく体制が作られるといいんじゃないかって考えはじめました。メンバーは全員兼務、気になっている人が気になっていることを改善するチームを作ると言ってもあまり大げさな話ではなく、今まで改善を行ってきた方や、共通の問題意識を持っている方、パフォーマンス改善に興味のある方などを巻き込むべく下記のような投稿をしたぐらいです。いう部屋を作って情報共有や議論する場を設けました2。発足した当初の活動内容はパフォーマンス確認したり遅い箇所(特定のページや動作)の報告したり改善したところ/しようとしているところ共有したりエンジニア全体向けのレポート書いたりなど、何をやるかは基本的にその人の自由で、「何かやったらみんなで共有し合おう」ぐらいのゆるふわな感じでした。現在はすこしだけちゃんとしていて、Q単位の目標をざっくりと決めて、週次で報告会を開いています。基本的にやることはいままで通り個々の自由です。(本業の)チームによってはこのための工数を確保して、本腰を入れてやってたりもします。やっていること現在やっていることを簡単にご紹介します。よってプロダクション環境をざっくりと監視しています。Rendering」の4つの項目の推移を見ることができるので重宝しています3。版でない限り制限があります。