はじめに
私は2022年6月に内定者バイトとしてJOIN、4月に23卒として新卒入社しました。ありがたいことに1年半で様々な経験をさせていただいています。
本記事では、これまでに主に力を入れて取り組んできた「開発者体験向上の取り組み」について紹介していきたいと思います。（主にストーリーを紹介するので、技術的なことは、TechBlogやSpeaker Deckで公開していますので是非ご覧ください。)
分散負荷試験基盤
こちらは内定者バイト時代に取り組んだものです。
詳細はTechBlogで公開していますので是非ご覧ください。
導入の背景
当時、私はECSからEKSへのリプレイスを担当しており、既存のECSで実行されているアプリケーションをEKSに移行する際のパフォーマンス確認およびチューニングを行っていました。
リリース前には、パフォーマンスを確認するために必ず負荷試験が必要です。しかし、私たちのチームでは、各々が異なる負荷試験ツールを使用しており、統一されていませんでした。これが要因で、負荷試験のノウハウがあまり蓄積されておらず、特に新規メンバーは負荷試験の実施が難しい状況でした。
私も同様に、手当たり次第に負荷試験に関する調査と実施に取り組んでいました。他のメンバーも同様の悩みを抱えているのではないかと考え、調査してみると、自社や他社で「分散負荷試験基盤」の事例が多く紹介されていました。そこで、先輩に、「これを作ればみんなが簡単にストレスなく負荷試験ができるのではないか」と提案し、ひとことで「いいね、やろう」と言っていただき作ることになりました。
導入後
導入後は、GitHub ActionsのWeb UI上から簡単に負荷試験を開始できるようになりました。さらに、様々なパラメータ（負荷試験実行時間、並列度など）をUI上から簡単に変更でき、試験結果を即座にDataDogダッシュボードで確認できるようになりました。
現在では、フロントエンドチーム、バックエンドチームを超えて、他の部署でも利用される基盤となっています。
Pull Request毎のPreview環境
こちらは今年の上期に取り組んだものです。
詳細は「ZOZO Kubernetes Night」で登壇した際に発表しています。YouTubeのアーカイブや私のSpeaker Deckをご覧ください。
導入の背景
私が担当しているプロダクトはリリースから10周年を迎え、溜まった技術負債を脱却すべく、インフラとアプリケーションのリプレイス中です。
具体的には、インフラはオンプレミスからAWSクラウド。アプリケーションはVBScript+jQueryからRails+Next.jsへFastlyのパスベースルーティングを使用して段階的にリプレイスしています。
特に、Webフロントエンドのリプレイスにおいて、レビューの際に旧環境のUIと比較することが多く、UIレビューに負担がかかっていました。
近年では、Vercelを利用したPull Request毎のPreview環境を使った開発が一般的になりつつあり、それもあってフロントエンドエンジニアから多くの要望が寄せられていました。その結果、Pull Request毎のPreview環境の開発と導入に至りました。
導入後
導入後は、フロントエンドエンジニアから「生産性が上がった」、「レビューの負担が軽減された」などの声をいただき、実際にフロントエンドチームが作成するPull Requestの半分がPreview環境を使用しています。
おわりに
ビジネスを拡大するために機能改善も大事ですが、働きやすい環境を自分たちで改善していくことも生産性向上のために大事だと思います！お時間があれば、ぜひ社内、チーム内のDeveloper Experience向上に取り組んでみてはいかがでしょうか？