- バックエンドエンジニア
- アナリスト
- 内部統制(J-SOX)
- Other occupations (8)
- Development
- Business
- Other
こんにちは。ブランドソリューション開発本部フロントエンド部の御立田です。フロントエンド部の部長とWEAR Androidのブロック長を兼任しており、普段は部署全体の管理・リスクマネジメントや、Android開発における設計などを行っております。
本記事では、運用改善によるチームパフォーマンス向上のための取り組みについてご紹介します。なお、フロントエンド部WEAR Androidブロックで実施した内容となっており、一部アプリ開発向けの施策ですのであらかじめご了承ください。
はじめに
ある時、本部長から「生産性を3倍にしてください」と通達がありました。いきなり3倍という数値を目の当たりにすると尻込みしますが、いま思えばこれが推進力の一端になったと思います。そしてより具体的な部の目標として、「1プルリクあたりの平均マージ・クローズ時間 24時間以内」を掲げ、改善の取り組みを開始しました。
生産性に対する課題感
Pull Request(以下PR)におけるレビューにとても時間がかかっていることはあきらかで、いかにPRにおけるレビューを効率よく行えるかが課題としてありました。しかしながら、生産性に課題があると感じていたものの、具体的にボトルネックがどこにあるか数値として把握していたわけではありません。
レビューをしなくてはいけないという意識はチーム内に浸透していたものの、案件の対応に追われまとまった時間が取れず、なかなかレビューに取り掛かれない。なぜそのような状態になってしまうのか、この状態から抜け出すにはどうしたらいいのか、が手探りな状態でした。幸運なことに弊社ではFindy Teamsが既に導入済みでしたので、こちらを駆使して数値の分析からはじめることにしました。
改善結果
まずは取り組みを説明する前に、結果をご覧ください。
(改善前:2021/10/01〜2021/11/30 改善後:2022/07/01〜2022/08/31)
サイクルタイム平均値
スタッツ
いかがでしょうか、目に見えて数値が改善されています。嬉しいことに「1プルリクあたりの平均マージ・クローズ時間 24時間以内」という目標に肉薄した数値まで改善しています。
数値分析
まず、Findy Teams上で直近2か月分(改善前:2021/10/01〜2021/11/30)の数値を見ることにしました。
問題点の推測
数値から以下の問題点が推測できます。
- PR作成数が少なく、作成までに時間がかかっているのは、1つのPRでの変更が多いためではないか?
- レビュー完了までに時間がかかっているのは、変更が大きくレビュアーに負担が掛かっているからではないか?
- マージするまでに時間がかかっているのは、変更が大きいが故に指摘が多くなるためではないか?
次にチーム内でレビューに対しての問題点を話し合いました。
- レビューに時間がかかるため、まとまった時間を取るのが難しい
- レビューするブランチを手元でビルドすると時間がかかる
- 複雑な仕様の場合、仕様を理解するまでに時間がかかる
その結果、上記のような「レビュアーに優しくないPR」が作成されているのが問題ではないか、という意見があがりました。
問題点の認識
大切なのは「レビュアーに優しいPR」を作成すること、という目的をチームで共有し、現在は何がレビュアーにとって優しくないのかをまとめました。
- レビュー環境が整っていないこと
- PRが巨大であること
- 日々発見される課題を認識し、常にアップデートする必要があること
対応策
次に問題点に沿って、行った取り組みをご紹介します。
続きはこちら