はじめに
この記事はアソビュー！ Advent Calendar 2024 の４日目（裏面）です。
こんにちは、アソビューでバックエンドエンジニアをしている長友です。
アソビューでは顧客の期待により迅速に対応するエンジニア組織構築を目的として、今期から”開発生産性向上”にフォーカスしています。
そして、そのアプローチの一環としてFindy Team+の導入・活用を始めました！
この記事ではFindy Team+を導入して数ヶ月間における活用とその効果ついてチーム単位・チーム横断レベルの両面において紹介していきたいと思います。
開発生産性を向上させる体制
開発生産性向上委員会の設置
エンジニア組織として全体の開発生産性を向上させるためにはチーム個別での取り組みの他に横の繋がりの推進も重要です。
そのため弊社では開発生産性向上委員会が設置され、各チームから1人ずつ開発生産性向上委員が選任されました。委員については育成の観点からも若手のメンバーが積極的に選任されました。
委員会では隔週で定例が実施されます。定例での取り組みは以下となります。
- 各チームでの取り組みの進捗を共有
- 各チームでの課題の共有と議論
- 中長期で生産性を向上させるための課題の議論と施策の検討
これら定例の内容を委員がチームに持ち帰って共有するといった流れです。
こうした体制でチーム個別・組織全体双方でFindy Team+の導入と生産性向上に取り組んでいくこととなりました。
チームにFindy Team+導入しての変化
私の所属するチームがFindy Team+を導入した時期は、新規プロダクト開発の1stリリースを終えてエンハンス期へと移り数ヶ月、スクラム開発も本格化させた頃となります。
Findy Team+や開発生産性に対する知見は全くないに等しかったため、『開発生産性の教科書』を参考に手探りでの導入となりました。
初期フェーズでは簡単なアクションでも数値は大きく改善する
導入にあたり、とりあえず改善に着手しやすい以下の指標を追ってみることしました。
- オープンからレビューまでの平均時間
- レビューからアプルーブまでの平均時間
これらを改善しようとした時、すぐにでもできるアクションを行うことだけでも大きく数値が改善することが分かりました。具体的には次のようなものです。
- 定期的にFindy Team+の数値をチームで見る(毎日がおすすめ)
- GitHubの通知を全員足並みを揃えて導入する
- Gitifyがおすすめ
プルリクエストのレビュー依頼が来たら通知が来るように全員で足並みを揃えて設定する、その効果が現れているか定常的に監視する、このような非常に簡単なアクションだけでも以下に示すように大幅な数値改善が見られました。
“えいや”で設定した高い目標の達成の為に一旦動いてみるとポジティブな改善が多く見られた
導入当初はとりあえずFindy Team+で計測された値を見る、すぐにできるアクションを実行するというところから始めましたが、その次のステップとして効果的とされる数指標に対して”えいや”で目標を設定してトライしてみるという試みを行いました。
なぜそのようにしたかと言うと、計測できる多種の指標の現状の数値について考察を深めることに時間を費やすより、一旦とりあえずでも改善の経験を積んだ方が今後解像度の高い手を打ちやすいと考えたからです。
そこで設定した目標は以下の通りです。
- 一人一日あたりのプルリク作成数 = 2件
- レビューからアプルーブまでの平均時間 = 21h
- 平均変更行数 = 200行
- レビュー依頼からレビューまでの平均時間 = 2h
「小さくたくさんプルリクエストを作る」ことを心掛け、それを元に設定したものとなります。
この目標設定とその達成に向けて動いていくことはこれまでの開発サイクルを考えるとドラスティックなものとなりましたが、そういった試みを短期間でも行ってみることの意義を信じてチーム一丸となり実施しました。
Findy Team+ではこの目標に対する達成率も期間指定で追うことができるため非常に便利です。
結果から言うと一部目標は高く設定しすぎて調整していくことになりましたが、以下のように定量面、定性面の双方でポジティブな変化を得られました。
定量面
目標設定前の時期と設定後の時期で「一人一日あたりのプルリク作成数」が横ばいなのが玉に瑕ですが、その他の指標は大幅に達成率を上げていることがわかります。
定性面
数値を改善するために出てきたアクションが生産性に対する本質的改善にも寄与するものが多かったです。具体的には以下などです。
- 200行に収まる改修内容とするために、それに直結するタスクの分解度により気を配る様になった
- プルリクエストのレビューに本当に必要なレビュワーをチームで定義し絞ることができた
- プルリクエストが小さくたくさんできる分、その依存関係を明らかにするためにJIRAチケットとプルリクエストを必ず結びつけるルールや、必要であればプルリクエストの依存ツリーを作成するルールなど、これまで徹底できてなかったことがルール化されていった
特にメンバーが2名増員して全体のプルリクエスト数が増えてきた中でも、1つのプルリクエストレビューに対する負荷が減ったことでレビュー周りの数値改善ができていたことが良かったと思います。
最初は開発の仕方の変化の大きさに戸惑いもありましたが、うまく実施していくためのコミュニケーションを絶えず行い、今では寧ろこの形が当たり前となりました。
そして、このおかげで後にエンジニア組織の目標として「変更のリードタイム」の改善が掲げられた際にも順応性高く取り組んでいくことができました。
変更のリードタイムを改善する為に動く 〜 ⅓にした取り組みの変化
Findy Team+を導入して2ヶ月ほど経った後、「変更のリードタイム」の改善を目標とすることがエンジニア組織全体として掲げられました。具体的には、7月8月の自チームの「変更のリードタイム」を11月、12月時点では2/3としていることでした。
7、8月時点の数値は以下となります。
既に「小さくたくさんプルリクエストを作る」を掲げて動いてきた私のチームでしたが、これはmasterブランチに向けたプルリクエストに限った話ではなく、案件ブランチに対する子プルリクエストであってもOKでした。
これからは「小さくたくさんすぐにリリースできるプルリクエストを作っていく」ことが求められるようになりました。
「リリースできる状態」のすり合わせ
重要なのは小さくリリースできる状態でプルリクエストを作ることです。ただしこの「リリースできる状態」の定義はチーム内でも意見が分かれるもので、これまでの開発フローからは以下の考え方が主流でした。
- ユーザーに明確に価値が届けられる状態
- 機能の部分部分において関連する自動テストやQAが終わっている状態
この従来の考え方は一定納得感のあるものですが以下の課題もありました。
- その状態になるまでは関連するコードはいつまでもリリースできない
- それまでに関連プルリクエスト間の依存関係が複雑化していく
- ビッグバンリリースになりがち
リリース戦略の変更の具体的な手順
結論としてはリリース戦略についてもある程度“えいや”で変えてみることにしました。具体的には以下のように実施しました。
- 新規機能関連コードのリリース基準緩和
- 新規機能関連コードについては、表で参照されなければ中途半端な状態でもリリースしてOKとしました。この手順により、コードを早く本番環境に統合することでリリース準備期間中のバグや依存関係の複雑化を防ぎました。
- 既存機能改修のリリース戦略
- 既存機能の改修については、Feature Flagの利用やAPI・ユースケースレベルでのバージョニングを行いました。これにより、機能が完全に完成していなくてもリリースできるようにし、新旧コードが共存し切り替えられる状態を維持しました。
- リリース前後のコミュニケーション徹底
- リリース戦略を変更する上で最も重要だったのは、チーム内で進め方に関するコミュニケーションを適宜図ることです。リリースのタイミングや対象の調整は常に共有し、関係者間の理解と合意を得てから実行するようにしました。
これによってマージを早めつつスムーズに開発するバランスを保つことができました。
このように小さくたくさんすぐにリリースできる体制へ移行していくことによる効果は比較的早く現れました。
中長期施策 〜 開発・設計の目線合わせ
当初の目標は2/3にすることでしたが、9月以降から現在までで1/3にまで改善することできました。
そのため途中からはcommitからmasterマージまでを3日以内 = 「変更のリードタイム = 72h」にするストレッチ目標を設定し、現在はその恒常的達成を目指しています。
この時期になると簡単にできるアクションは一通り実施できているため、中長期的な改善を見据えた「開発・設計」の目線合わせを行う施策を行うことにしました。
具体的には以下のような施策です。
- バックエンド・フロントエンドで開発ポリシーを策定
- プルリクエストレビューや提出前のチェックリストとして利用
- コーディング周りのドキュメント読み合わせ
- 本プロダクト特化のシステム構成図の整理
- UIとデータのマッピング説明会の実施
今後は設計思想の認識合わせとポリシー策定についても行う予定です。
これらの施策は既存メンバー同士では明文化されていなかった方針の認識合わせになり、新規メンバーに対しての共有にもなります。
これによってチームにおける再現性の向上を図り「レビューからアプルーブまでの平均時間」「一人一日あたりのプルリク作成数」の向上にも繋がると考えています。
おわりに
Findy Team+の導入による最大のメリットは数値化とそれに伴い課題意識が醸成されたことだと感じます。
今まで特定の事象や印象ベースでの議論がメインとなっていましたが、開発生産性に関する各種指標が数値化されたことで以下のサイクルが可能となりました。
①数値目標を立てる
↓
②目標と実測値の間のギャップが生じる
↓
③ギャップが課題と認識され、解決策の議論が換気される
このサイクルによって今までより積極的に議論が行われ、様々な施策も実施されるようになりました。
そして現在では全社的に初期改善フェーズを脱したチームが多いです。これからは目線合わせなどの施策によるチーム力向上や、DevOps観点での技術的アプローチによる課題解消など、中長期的視点で粘り強く実施する必要がある施策の検討・実施を強化していきたいと思います。
アソビューではより良いプロダクトを素早く世の中に届けられるよう、開発生産性向上の取り組みを強化しています。 我々と一緒に働くエンジニアも募集していますので、興味のある方はぜひお気軽にエントリーください！
