Team+を導入しておおよそ半年経ったので振り返る

はじめに

こんにちはgenimuraです。
今回は、Findy Team+ を6月頃から導入検討をして、9月から正式導入を開始し、開発チーム全体に運用を開始するところまでが完了したので、その振り返りをします。

前提: エンジニア組織概要

現在エンジニアが18名います。

導入したチームの内訳

Web、ネイティブアプリで開発を行っています。
Webチームのみ複数のチームが存在します。

Web1チーム: DXの開発系がメイン
Web2チーム: イベントの賑やかしプロダクトの開発系がメイン
ネイティブチーム: カメラを使ったプロダクトの開発系がメイン

前提: Team+を導入するに至った経緯

きっかけは、Findyを採用媒体として使っていて、開発生産性の高い企業 というタグがついている企業を見つけたことで、Awardsがあることを知り、Team+という存在を知ることになりました。
それまでは開発生産性という観点は意識していなかったのですが、改めて自分たちの健康診断という考え方で、まずは生産性を可視化してみるのにいい機会になるのでは？と考え、導入にいたりました。

導入後の使い方

基本的にTeam+は前述の通り、健康診断的に利用するのが良いと思っています。
そのため、PDCAサイクルを回していく使い方をしております。

下記をループするように活用

1. 現状の把握
2. ボトルネックの特定
3. 改善アクションを決定
4. アクション分析
5. フィードバック

導入初期について振り返ってみます。

現状の把握

導入初期は一部のチームのみに導入を行いました。
Web1チームの話をメインにしていこうと思います。
まずは現状把握ということで、サイクルタイム分析(コミットからマージされるまでの時間を可視化)やレビュー分析(誰がレビューを依頼し、誰がレビューをしているかを可視化)を行いました。

導入前の1年間を分析し、サイクルタイム・レビュー分析は下記の通りになりました。

ここで分かることは大きく分けて3つでした。

1. レビューのタイミングにムラがある
2. 変更行数が多い
3. コミットからオープンまでの時間が長い(営業時間ベースで3日に1回)

これらのことを踏まえて、ボトルネックの特定を行いました。

また、Web1チームでは1週間に1回分析担当を決めて数値分析をして定例で報告・相談を行うようにしました。

ボトルネックの特定

明らかになったことをもとにさらに分析をしてみました。

レビューのタイミングにムラがある

レビュー分析をさらに見てみると、以下のようなことがわかりました。

1. 特定の人にレビューが集中している
2. レビューの依頼がされていないPR(プルリクエスト)が多い

これらのことを踏まえて、レビューのタイミングにムラがある理由は、

1. レビューをしている人が忙しい(別のタスクをしている？)
2. レビューの依頼がそもそもない

ということが考えられました。

変更行数が多い

変更行数が多い理由は、明確にPRの粒度が大きいことが原因ですね。

コミットからオープンまでの時間が長い(営業時間ベースで3日に1回)

これらも変更行数が多いことと関連していて、取り組んでいるタスクの粒度が大きいことが原因だと考えました。
タスク・PRの粒度が大きいことでさらにレビュアーの負荷が高くなり悪循環が生じていると考えました。

ボトルネックのまとめ

問題点は下記の通りです。

• レビュアーの負荷が高い
• レビュー依頼が仕組みかされていない
• タスク・PRの粒度が大きい

改善アクションを決定

ある程度可視化を終えて、ボトルネックが特定出来たので、改善アクションを決定しました。
半年間で実施した内容に関して記載していきます。

レビュアーの負荷が高い→2人Approveにしたらマージ出来るように

目的は、レビューが出来る人を増やし、レビュアーの負荷を分散させることです。
短期的に見ると負荷の高いレビュアーの負荷軽減には繋がらないですが、長期的に見てレビューが出来る人数を増やすことができれば、レビュアーの負荷軽減に繋がると考えました。

レビュー依頼が仕組みかされていない→レビュアーのデフォルトで設定、Slackへの通知を設定

そもそもレビューされていないPRが多いので、レビューされずにマージされないための仕組みを明確にしました。
また、SlackへのGithubの通知を設定することをルールとしました。
この他にも、AIによる自動レビューを導入しました。(Codium Agentの導入)
自動でレビューしてくれるだけでなく、PRの中身も詳細に記述してくれます。(Descriptionを詳細化してくれる)

タスク・PRの粒度が大きい→2時間で終わるタスクまで分割、PRは多いぐらいがちょうどいいと伝え続ける

これまで、タスクの粒度が、〇〇機能追加、のような機能の詳細が明らかになっていないままタスクに取り組んでいたことがありました。
そこで、各タスクに対して2時間ぐらいで終わる粒度まで細分化し、1タスク→1PRだとしてもPRの粒度として問題ないぐらいに分割を行いました。
また、これは意識的な問題でもありますが、PRの粒度に関してはしつこいぐらい細かくしてもらったほうがレビュアーの負荷が小さい、ということを永遠とチーム内で伝え続けました。

アクション分析(半年間の成果)

半年間で実施したアクションを振り返ります。

サイクルタイム、レビュー分析の数値を改善前、改善後で出してみました。

項目	改善前	改善後	短縮率	短縮倍率
合計値	55.1h	14.1h	74.4%	3.9倍
コミットからオープンまでの平均時間	26.7h	4.1h	84.6%	6.5倍
オープンからレビューまでの平均時間	12.3h	4.1h	66.7%	3.0倍
レビューからアプルーブまでの平均時間	10.8h	3.5h	67.6%	3.1倍
アプルーブからマージまでの平均時間	5.3h	2.4h	54.7%	2.2倍
平均変更行数	1702.4行	506.8行	70.2%	3.4倍

※短縮率、短縮倍率は下記のように計算。
短縮率 = (改善前 - 改善後) / 改善前
短縮倍率 = 改善前 / 改善後

一目瞭然で全ての項目が改善されています。素晴らしいです。
また、レビュアーは1番目に多いレビュアーと2番目に多いレビュアーの2人でおおよそ55:45の割合でレビューをすることが出来ました。

肌感ではありますが、これまでより、チームとしてのスピード感が出るようになったと思います。
また、軌道修正やマージのタイミングをコントロールしやすくなったので、より安定した開発が行えるようになったと思います。

フィードバック

半年間で行われたアクションに対してのフィードバックについて記載してきます。

レビュアーの負荷が高い→2人Approveにしたらマージ出来るように

最初、というか今でもまだ抵抗があると考えていますが、ジュニアメンバーでもレビューっていう観点で指摘をしていくのではなく、学びを得るという観点でPRを見てもらうように少しずつなってきたのかなと思います。
まだ、レビューに時間がかかるという点、作業が分断される点などは工夫の余地があると思っています。

レビュー依頼が仕組みかされていない→レビュアーのデフォルトで設定、Slackへの通知を設定

通知周りに関しては、紆余曲折がありました。
レビュアーをデフォルトにしても、見ない人は見ないので口頭で依頼、もしくはPRのコメントにメンションを付けて依頼等を行いました。
直近では、Github上にWeb1のチームを作ってそこに2人レビューがされるまで30分間隔で通知が行くようにして落ち着いています。

タスク・PRの粒度が大きい→2時間で終わるタスクまで分割、PRは多いぐらいがちょうどいいと伝え続ける

これは週のはじめにタスクの細分化を意識するように、またデイリーで今日終わらせるタスクを列挙してもらうなどの仕組みを入れました。
またPRが大きくなってしまっていた場合には、PRの中身から分割が出来なかったのか振り返りをしていきました。結果的に何も言わなくてもPRの粒度が小さくなっていきました。

苦労したこと

何のためにTeam+で分析をするのかという意味をチームメンバー全員に理解してもらうのが一番難しかったと思います。
これは何週もかけて同じことを言い続けてきました。
半年経ってやっと「数値分析をして、その数値をもとに改善アクションを設定し、アクションの結果を分析してまた次のアクションを設定し実行」というループがチーム内で自発的に起こるようになってきました。

まとめ

半年間でTeam+を導入してみて、その効果は大きいと思いました。
何より、明確なフィードバックをすることが出来るようになったこと、個人としての活動の集合が、チームとしての活動につながるところが可視化されたことが大きいと思っています。(チーム感が出る)
今年のAwards目指して頑張っていきたいと思います。