はじめまして！アスエネ株式会社の @umzo（うめぞう）です。フロントエンドエンジニアとして入社しましたが、現在はフルスタックにコミットしています。
アスエネでは「アスエネキャリア」という脱炭素・ESG人材の転職支援サービスの開発に携わり、エンジニアチーム（以下、キャリアEng.チーム）の取りまとめをしています。
私たちのチームでは、生産性の指標として以下の目標値を設定していました：
- オープンからマージまでの時間：8時間以内
- プルリク作成数：1人あたり6件/週
ここ半年の改善で、これらの目標を達成することができました。本記事ではその取り組みを共有します。皆さんのチーム運営の一助になれば幸いです。
アスエネキャリアとは？
まず簡単に、私が携わっているアスエネキャリアについて紹介します。
アスエネキャリアは、脱炭素・ESG人材の転職支援サービスです。持続可能な社会を目指し、脱炭素や気候変動、サスティナビリティに関心のある人々が、最適なキャリアを築けるようにサポートしています。
開発目標の達成状況
キャリアEng.チームは2024年5月頃に発足し、アスエネキャリアは2024年8月26日に正式リリース。現在は新機能開発と機能改善を行なっており、立ち上げてから約1年の比較的歴史の浅いチームです。
リリース当初は
- オープンからマージまでの時間：約30時間
- プルリク作成数：1人あたり平均で4〜5件/週
という状態でした。
しかし現在では、
- オープンからマージまでの時間：5.4時間（目標8時間以内）
- プルリク作成数：6.4件/週（目標6件/週、過去3週間の平均）
と高い水準を達成しています。
以下では、この目標を達成するに至った背景や経緯を紹介していきます。
キャリアEng.チームの良い点
チーム文化
1. ハドル/ペアプロの活用
とにかくハドルを活用したペアプロが多いです。発足して間もないこともあり新メンバーが入ることが多く、その際にはドキュメントでは伝わり切らない細かいニュアンスなどをペアプロで共有しています。1人で悩まず、チームで解決する文化が根付いています。
2. ドキュメント類の活用
ドキュメント更新が非常に活発です。主なドキュメントとしては、チームの約束事などが記載されたオンボード資料、設計方針、コーディング規約、運用フローなどがあります。
特にオンボード資料とコーディング規約は、週ごとの振り返りやメンバー間の議論を通じて定期的に更新されています。更新頻度は週1回以上あり、正確さとわかりやすさも重要ですが、何より「使われること」を重視して、誰でも更新できる仕組みにしています。
3. 開発者体験（DX）改善チケットの管理
誰でも思いついたときに起案できる仕組みを採用しています。起案は自由ですが、どのチケットに着手するかはチームの合意で決めるようにしています。これにより課題の見逃しを防止しています。
メンバーの特性
1. 高い課題意識とモチベーション
ドキュメント更新や頻繁なDX改善チケットの追加を積極的に行うなど、メンバー全員が高い課題意識とモチベーションを持っています。
2. プロダクト理解への意識
インプット会での議論が非常に活発です。インプットでよくある困りごととして、プロダクトに対する議論（ユーザーのどんな課題を解決したいのか）と仕様に対する議論が混在することがあります。この2つを明確に分けてインプットすることで、より効率的に議論をしています。
3. フルスタック志向
「FEだけどBEもやってみたい！」というメンバーが多いので、メンバーの要望に沿うようにアサインを調整しています。もともとフルスタックだったメンバーはほとんどいませんでしたが、現在はメンバーほぼ全員がフルスタック的に開発に取り組んでいます。このおかげで「バックエンドのAPI開発を待っているため、フロントエンドの手が空く」といった状況がなくなり、より効率的にプロダクト開発が進み、ユーザーに多くの価値を届けられるようになりました。
改善サイクル向上のための取り組み
素晴らしい文化とメンバーを持つキャリアEng.チーム（自画自賛）ですが、それでも目標を達成できていませんでした。そこで、すでに目標水準を達成している他チームへのヒアリングや、他チームのタスクチケットやPRを調査することで、自分たちとの違いを分析しました。
見えてきた課題
1. PR mergeまでの速さの意識
レビュー依頼のリマインドが遅く、approve後のmergeも遅いという課題がありました。
- レビュー依頼のリマインド
- 他チーム：2時間以内
- キャリアEng.チーム：4〜5時間
- approve後からmergeまでの速さ
- 他チーム：approveされてすぐ
- キャリアEng.チーム：平均6時間
2. 設計フローの不備
実装前に十分な設計が行われておらず、実装を進めてから設計の課題が発見されるという非効率なフローになっていました。
- 他チーム：BEはBE全員が、FEはFE全員が設計レビューに参加し、手戻りが少なく、設計の観点がインプットされた状態でレビューができる
- キャリアEng.チーム：設計フローの規約なし
具体的な改善策
これらの課題を踏まえ、以下の改善に取り組みました。
1. PR mergeまでの意識向上
Findy Team+などのツールを活用し、開発プロセスを可視化。定期的な振り返りで意識向上を図りました。
2. レビューフロー変更
- 変更前：approve後に気づかない、別タスクに移動している、すでに退勤しているなどでmergeが遅くなっていました（約6時間）
- 変更後：最終レビューワーがmergeする仕組みに変更
3. 設計フロー改善
設計の手順とアウトプットを明確化し、コードベースでレビューする仕組みを導入しました。
フロントエンドでは、UI構成を明確にするために、どのようにコンポーネントを分割するかを示す空のコンポーネントファイルを作成してcommitしています。バックエンドでは、APIエンドポイントの構造やドメインモデルの構造を表現するためのエンティティクラス、コントローラー、テストケースの雛形をcommitしています。コードベースでレビューしてもらう方法を採用しました。
これにより、レビュー者はより設計を明確に把握でき、設計時のドキュメント作成に必要な工数も削減できました。
まとめと振り返り
1. 目標達成のための主要な取り組み
開発プロセスの可視化とレビューフローの変更が、生産性の「爆上げ」に最も貢献しました。特に最終レビューワーがmergeする仕組みへの変更は、オープンからマージまでの時間を約30時間から5.4時間へと大幅に短縮する効果がありました。また、設計フローの改善により、実装前の段階でコードベースでの設計レビューを行うことで、手戻りを減らし、プルリク作成数の増加を実現できました。
2. 良い事例の活用の重要性
これらの改善は、すでに高いパフォーマンスを達成している他チームの良い事例を分析し、積極的に取り入れたことがきっかけでした。「守破離」の精神で、まずは効果が実証されている方法を取り入れ、その後チームに合わせて調整していくアプローチが効果的でした。
最後に
最後まで目を通していただき、ありがとうございました！
チーム改善は一朝一夕で完成するものではなく、継続的な気づきと修正の繰り返しです。私たちもまだまだ改善の余地があり、今後は以下のことにTryしていきます：
- 先ほど紹介した設計フロー改善はまだ試行錯誤の段階なので、フィードバックをもらいながら改善しています
- 不具合調査やユーザー対応などの一部運用業務が属人化している課題があります。これに対しては、運用ドキュメントの拡充を進めるとともに、運用に熟知したメンバーが積極的に他メンバーを巻き込んで対応することで、知識と経験の共有を図っています。
- テスト環境の整備やモンキーテストの導入も計画中で、安心して開発できる環境を整えていきたいです
皆さんのチーム運営にも、ぜひ参考にしていただければ幸いです。質問やご意見があれば、ぜひコメントでお聞かせください！また、今回の改善は、メンバーの協力があってこそ実現できたものです。「良いものを作りたい」という共通の想いを持ったチームメイトに、この場を借りて感謝を伝えたいと思います。
アスエネでは、技術的なチャレンジだけでなく、脱炭素やESGという社会的意義のある領域で、自分の強みを活かして成長できる環境を大切にしています。エンジニアリングを通じて社会課題の解決に貢献したい方、一緒に挑戦したいという方をお待ちしています。
現在、全職種で採用を強化中です！興味を持っていただけた方は、アスエネ採用サイトからご連絡いただくか、SNSでカジュアルにメッセージをいただいても大歓迎です。
これからも実践から得た学びや気づきを発信していきたいと思います！
Discussion