こんにちは。ブランドソリューション開発本部フロントエンド部の御立田です。フロントエンド部の部長と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が巨大であること
- 日々発見される課題を認識し、常にアップデートする必要があること
対応策
次に問題点に沿って、行った取り組みをご紹介します。
レビュー環境への対応策
レビューする際に、開発作業とのスイッチングコストがかかっている状態でした。こちらをなるべくシームレスに行い、かつレビューすることへの心理的ハードルを下げることを目的としました。
レビュー会の開催
レビュー会と称して、毎日1時間チーム全員で集まる会を開くことにしました。Discordの音声チャンネルに集まり、その場で全員がレビューします。優先してほしいレビューの共有や、口頭での質問もそこで行います。
狙いとして、スケジュールに組み込むことでレビュー時間の確保。チームでレビューする強制力。また、その場で口頭相談できるコミュニケーションの向上があります。
チームからレビューのやりやすさが向上したとフィードバックがありましたし、数値としてもレビュー件数の向上が見られました。
PR単位でビルドの共有
WEARは2013年にリリースされたアプリで、巨大なプロジェクトになっていることもあり、ビルド時間がかなりかかってしまっている状態でした。その中で、PRごとに各レビュアーが手元でビルドして確認する必要があり、すぐにレビューに取りかかれない問題があります。この問題を解消するため、弊社では他チームにアプリを共有する際に、DeployGateを利用していたのでそちらをうまく活用し解決しました。
PR作成後、GitHub ActionsでDeployGateへビルドをアップロードし、そのURLをPRのコメントへ記載することで環境別のビルドをすぐインストールできる状態にしました。また、PRがマージ、クローズされた際にそのリンクを無効とする処理も行っています。
この結果、毎回レビュー時にかかっていたビルド時間を0にすることが出来たため、各々のPCに負荷を掛けることなくレビューする環境が整いました。
巨大なPRへの対応策
巨大なPRの場合、それだけでレビューにかかるコストが大幅に増加し、必然的にまとまった時間が必要となります。粒度を下げることで、レビュアーを拘束する時間を必要最低限にすることを目的としました。
サブタスクで粒度を下げる
弊社では案件管理にJiraを採用しており、普段からなるべく小さい範囲で課題チケットを作成するように心掛けていましたが、ブランチ運用上難しいパターンがありました。
ブランチ運用は、main、developの2つが基本となります。基本的に2週間に1回の定期リリースをしており、開発フェーズではdevelopに各々対応したチケットをマージします。その後、テストフェーズでQAチームに共有してテスト、リリースの流れとなっています。
細分化するチケットは、あくまでもそれ単体でdevelopにマージして問題ない単位としているため、必然的に大きくなる傾向がありました。
例えば、定期リリース2週間の期間内に終わらない案件（もしくはリリーススケジュールが先のもの）が進行していた際に、以前までは作業ブランチにすべて完了するまでコミットする。そしてその作業ブランチをdevelopに向けてPR作成というフローでした。
この時の問題として対応内容が大きければ大きいほど差分が膨らみ、仕様の理解が遅くなり、結果レビュアーの負担が大きくなりレビューの精度が低下するというものでした。
こちらを解消するために、Jiraのサブタスク機能を活用します。
1つのチケットをサブタスクとして実装者が細分化することで、より実戦的な粒度の小さいものに出来ます。実装者はそのタスクを完了させたら親のチケットに対してPRを作成します。最終は、親のチケットをdevelopに向けてPR作成します。その結果、実装者は普段の開発と同様一区切りついたタイミングでレビューをしてもらえ、フィードバックも早くなります。
また、細分化された作業が明らかになることでエンジニアの進捗管理にも役立ちました。
常にアップデートすることへの対応策
レビューでは非同期的なコミュニケーションが多くなりますが、仕組み化するための議論の場として、我々は同期的なコミュニケーションが大切だと考えました。週1回の実装相談会の実施、月1回のKPTの実施を定め、日々発見される課題をチーム全体の課題として認識しアップデートしていくことを目的としています。
細々とした課題が多くあったので、その中でも効果的だったものをいくつかご紹介します。
開発者リソースの再配分
Findy Teamsで数値を分析すると、ある時期あるメンバーのパフォーマンスの高低が見えてきました。こうして数値として見えることで、本人も気付かない部分を考察できます。なぜパフォーマンスが良かったのか、悪かったのかをメンバーと話し合うことで、数値と実感をすり合わせる作業をしました。
メンバーの得意な案件を担当にしたり、エンジニアリソースの再配置をすることで、開発メンバー数としては減ったものの数値は改善されてコストパフォーマンスの高い結果となりました。
また、Findy TeamsにはチームのフォローアップアラートをSlackで受け取る機能があり、その数値を元に仕事量の偏りがないよう調整しています。
PRテンプレートを充実させる
主に人によって違いが出ることを防ぎ、また書くものを迷わないようにするを目的としています。
一部抜粋し、以下に羅列します。
- JIRAのチケットリンクを必須で記載
- ブランチ名にもWEAR-****をprefixとして作成するルールにし、PRで作成したものに使用するブランチが一致するかをCIで自動的に確認
- 動画・画像キャプチャを必須で記載
- ひと目で対応箇所の認識、動作の確認が容易になり認識のズレを減らす
- テスト内容をレビュアーが再現できるもので表現する
- 「正しいこと」「問題ないこと」などの曖昧な表現をやめる
- レビュアーがテストに記載されたものをなぞれば再現できる表現にする
本質的なコードのレビュー以外の確認項目を減らし、コードレビューを集中して行うことができるようになりました。
意味のある単位でコミットをまとめる
コミットの単位を一時的なコミットではなく、そのコミット自体で1つの完結した意味あるものとするようにしました。
例えば、画面にボタンを追加するというPRがあるとして下記のようにコミットを積んでいきます。
- ボタンのUI作成
- クリックリスナーの設定
- クリックされたときの処理を実行
- ボタンの文言を定義
- コードフォーマットをかける
上記のように、コミットを分けることでコミット単位でのレビューが可能となり、よりレビュアーの理解する速度向上に役立ちます。
（状況によりコミット単位は変動します。難しい場合、この限りではなく、臨機応変に対応としています）
自動化できるものは自動化する
- Slack上にPRがOPENされたら通知する
- PRが作成されたら自動でレビュアーをアサインする
- ブランチが並行稼動するため、マージ先のブランチを間違えないようにPR Milestone Checkを導入し、対応PRを管理する
人が管理する必要のないものを自動化して時間を削減したり、ヒューマンエラー対策を行いました。
まとめ
本記事ではレビューを通じてチームのパフォーマンス向上を目指した取り組みについてご紹介しました。
1つ1つはそこまで大変な対応策ではありませんが、確実に実施していくことで数値の改善を達成できました。部として目標を定め、それに対応する施策をチームの共通目標にし、目指すべきところへ全員が参加して貢献することが大切です。コードレビューを通じてコミュニケーションも活発になり、チーム一丸となって進んでいると実感しています。
我々の取り組みが少しでも参考となれば幸いです。
最後までご覧いただきありがとうございました。WEARでは一緒にサービスを作り上げてくれるAndroidエンジニアを募集中です。
その他、各種エンジニアも募集しております。ご興味のある方はぜひご応募ください。
