開発生産性の改善から1年経過したチームで考えていること

こんにちは。エンジニアの保立(@purunkaoru) です。

僕のチームでは、開発生産性の改善に取り組んでから1年経過しました。開発生産性の改善系の記事やノウハウは世間によく出ていますが、1年経過した今、開発生産性に対してEMの立場で何を考えているかを言語化します。

チームメンバーの構成は、執筆時で以下の通りです。

フロントエンド: 5名
サーバーサイド: 9名
モバイルアプリ: 3名
EM（保立）: 1名

弊社では、Findy Team+ を導入し、開発生産性を見えるようにしています。まずはFindy Team+の画面を見ながら、改善結果を見ていきます。

直近1年間
直近2年間

直近2年で見ると、後半1年で生産性が改善されており、その改善が一定維持できていることがわかります。

ちなみに、このサイクルタイム分析について、数値的な目標を今まで一度も掲げてきませんでした。どうしても指標に対する数値目標を掲げてしまうと、それに対するハックが進んでしまい、本質的な改善にならないと感じていたからです。チーム内では、開発に時間がかかる・レビューに時間がかかると誰かが感じた時に、Findy Team+の定量的な数値を見てチームに改善を促すコミュニケーションを取るケースが多かったです。

また、Four Keysの分析（Findy Team+でいうDevOps分析）は、botでリリースPRを作っているせいか、うまく集計できないので分析対象から外しています。社内には、Four Keysの分析をOKRに組み込んでいるチームもあります。

それでは、ここから本題に入り、開発生産性の改善が進んでから1年経過して、何をチェックしているか記載していきます。

1. チーム別のアウトプット量の推移や負荷の確認

エンジニアチームとして、アウトプットの量の推移を確認することは不可欠です。アウトカムとしてのKPI（サブKPI）への貢献もチーム全体で把握していますが、開発に関わるアウトプット量の変化にも注目しています。

アウトプットの量は「1人あたりのプルリクエスト数」と「1プルリクエストあたりの平均変更行数」で測っています。以下の画像の棒グラフ（薄い色の方）で示されている「1人あたりのプルリクエスト数」は、昨年に比べて約20%増加していることが分かります。

一方で、「1プルリクエストあたりの平均変更行数」に関しては、別の画面で確認する必要がありますが、月ごとの推移を1画面で見る方法を見つけられなかったため、ここでは画像の提供は省略します。僕のチームの平均変更行数は、月ごとにばらつきはありますが、過去と比べて増加または減少した傾向は見られませんでした。

ここから読み取れることは2つあります。

1つ目は、チーム全体のアウトプット量が増加していること。これは、要件定義や設計のコミュニケーションが整備され、スムーズになったこと、またエンジニア自身の技術力やレビュー能力の向上が背景にあります。

2つ目は、12月にプルリクエスト数が急増しており、稼働時間が多い状況になったこと。主な要因は体制変更にありました。新しいチーム体制での見積もり精度が落ち、稼働が厳しくなってしまいました。11月末にはプルリクエスト数が増加する傾向にありましたが、対応が12月初旬まで遅れたことは、データチェックの不足や閾値設定の不備が原因です。以降、プルリクエストの数の増減にはこまめに目を光らせるようになりました。

このように、定量的なデータを活用して、チームの生産性と負荷のバランスを定量的な指標をもとに管理しています。

2. サイクルタイム分析による開発サイクルの確認

開発サイクルの改善を行ってから1年が経過し、サイクルは成熟しており、サイクルタイムの増減は限定的です。サイクルタイムに大きな変動が生じる主な要因には、大規模な機能のリリース、メンバーの交代、チーム体制の変更、施策の追加や削除などがあります。これらの要因は、開発サイクルが改善されるか、逆に悪化するかを事前に予測できます。

たとえば、2024年4月から新しいメンバーが加わり、全エンジニアにメンターを配置する制度も導入しました。これにより、教育やMTGに費やす時間が増えました。このような新しい施策を実施したにもかかわらず、サイクルタイムや1人あたりのプルリクエスト数に変化が見られない場合、新たに増えた教育や会議の時間を考慮せずに見積もりを行い、チームメンバーが無理してタスクを完了させている可能性が考えられます。

そのため、新しい施策を導入する際には、いつごろから数値が改善するか、あるいは悪化するかを予測し、実際にその通りになっているかを後から確認するようにしています。

3. 十分な質のアウトプットが出せる量を超えてアウトプットをしていないかの確認

多くのサービスや機能を一人で担当することは効率が悪くなるとされています。エンジニアの世界でも、「チームトポロジー」などの書籍を通じて、シンプルで効率的な組織構造の重要性が説かれています。

同様に、一人が多数のプルリクエストやチケットを抱えると、対応を忘れてしまったり、ひとつひとつの作業に対する注意力が散漫になることがあります。チームによっては、レビュー待ち状態やテスト待ち状態のプルリクが放置されてしまう事象があると思います。

例えばメンバークラスのエンジニアが、タスク管理と開発の両方を行う役割に移行した場合を考えてみます。当然、タスク管理の責任が増えるため、割り当てられるチケット数やプルリクの数は自然と減少すべきです。しかし、変更前と同じ量を割り当ててしまうケースがよくあります。また、チームメンバーが増えた場合も、タスク管理の工数は増えますが、チームの増減を考慮せずにチケットを割り当てがちです。そのため、各人の役割に応じたタスク量を適切に考慮し、負荷を調整することが必要です。

現在、負荷量は「1日あたりのプルリク数」×「コミットからマージまでの日数」という計算式で把握しています。単純な「1日あたりのプルリク数」や「チケット消化数」では、プルリクやチケットの内容による重さを正確に反映できません。そのため、軽いプルリクはコミットからマージまでの時間が短く、重いプルリクは時間がかかると見込んで、この計算式を採用しました。

この計算式で算出される負荷の量を、各メンバーが理想的に対応できる数値と比較し、適切かどうかをチェックしています。自分自身の場合、集中的にプレイヤーとして活動できる時期は「18」が上限ですが、10名程度を管理していた際は「6」が限界でした。ただし、個人の生活リズムやその他の業務負荷により、「コミットからマージまでの日数」は変わるため、他人と比べるよりも過去の自分自身と比較して閾値を設定しています。

上記の例だと、「1日あたりのプルリク数」は、52PR / 20営業日 = 2.6PR/営業日となります。「コミットからマージまでの日数」は、(2.5時間 + 8.5時間) / 8時間 = 1.4時間弱となります。（「8時間」は、1日あたりの稼働時間です）負荷量（「1日あたりのプルリク数」 * 「コミットからマージまでの日数」）は、2.6 * 1.4 = 約3.6 となります。安全ですね。

この指標は改善が必要かなと思いつつ、ひとりひとりの負荷をアクティビティベースに定量的に確認する術が無く、今はこの方法で管理しています。

4. 新しいメンバーが機能しているか・無理していないかの確認

オンボーディング施策の一環として、新たにチームに参画したメンバーが機能しているか・無理していないかも確認しています。これは、主に業務時間で見ていますが、徐々にやれることが増えているかという点で、プルリク数・プルリクに対するコメント数・レビュー数などでも確認しています。

特に多いのが、急激に頑張ろうとしてプルリク数とレビュー数が急激に伸びているケースです。このケースでは、1プルリクあたりに対するレビューコメント数も多くなる傾向があり、レビュワー・レビュイーともに疲弊するケースがあります。こういった場合は、目標を落として、その分ペアプロをしたり、レビューコメント数が少なくなるための施策を一緒に考えます。

5. サービスの障害に関する確認

最後に、Findy Team+から離れた場で開発生産性に関して確認している数値について説明します。

サービスの障害を未然に防ぐため、自動テストだけでなく、エンジニアによる手動テストやプロダクトマネージャー、QA、CS担当者の手動テストも行っています。これらのテストにかかる期間や発見されたバグの数を記録し、各々の閾値を設定しています。もちろん障害の発生件数も確認していますが、障害発生前の手戻りやバグ検出に伴う工数も管理し、減少させる努力を続けています。これらの数値は品質管理の文脈で語られることが多いですが、結合テストや受入テストの工程の工数が減ると開発生産性は上がるので、今回の記事にも取り入れました。

この取り組みは、今期から始めたばかりですが、既に一定の成果が見られ、良い施策であったと感じています。

まとめ

数値化による生産性の管理は、チームのパフォーマンスや成長を明確に追跡することができ、またチームの負荷も把握することができます。これにより、客観的なデータに基づいて意思決定や評価を行うことができます。一方で、一度数値化してしまうと、数値を良くすることに目を向けすぎて、本質的な改善にならないケースもあります。そのため、前提を疑いながらウォッチしていくことが大切だと考えています。

今回記載した開発生産性の改善から1年経過したチームで考えていること・見ていることについて、参考になれば嬉しいです。メドピアの開発者ブログでは、技術的なことやチームマネジメントなど、参考になりそうなことを発信しているので、是非ブックマークをしていただけると嬉しいです。

メドピアでは一緒に働く仲間を募集しています。ご応募をお待ちしております！

■募集ポジションはこちら medpeer.co.jp

■エンジニア紹介ページはこちら engineer.medpeer.co.jp

■メドピア公式YouTube　 www.youtube.com