Findy Teamsの指標を使ってチームの生産性を改善しよう

チームマネジメント

株式会社アンドパッドのアカウント基盤チームで認証基盤に関するエンジニアリングをしているid:shiba_yu36です。最近はチームのテックリードロールも担っています。

現在アンドパッドではFindy Teamsを導入し*1、生産性の可視化を行っています。自分は生産性向上のためのチーム改善に興味が強いため、2021/10に入社してからアカウント基盤チームのFindy Teams指標を観察し、チームのボトルネックを見極め、チームの生産性改善をしてきました。結果として、Findy Teamsの平均プルリク クローズ時間の指標が、チームに入った2021/10当時は120時間だったのが、現在は23時間ほどまで改善しました。今回はその様子について書きたいと思います。チーム改善の流れの一例として、参考にしてもらえればと思います。

チーム改善の全体的な流れ

自分は以下のステップでチーム改善をすることが多いです。システムのパフォーマンスチューニングと流れが近いですね。

  • 定量的にチームの生産性を表せる指標を探す
  • 指標の現在の状況を知り、どこまで改善できると良いかの目標を立てる
  • 指標とチームの様子の両方を観察し、ボトルネックを見つけ、改善する

今回もFindy Teamsを使いながら、このステップで改善しています。

Findy Teamsで定量的にチームの生産性を表せる指標を探す

Findy Teamsではプルリク作成数や平均プルリククローズ時間、コミット数など様々な指標が可視化されています。まずはこの中から、定量的にチームの生産性を表せる指標を探します。

自分がチームの生産性として参考にする指標を決めるときは、以下の2点を重視しています。

この2点から、Findy Teamsでは「平均プルリク クローズ時間」に着目し改善していくことにしました。この指標は、4指標における「変更のリードタイム」の一部*2であり、かつFindy Teamsのチームレポート > タイムラインで時系列データを確認できます。

指標の現在の状況を知り、どこまで改善できると良いかの目標を立てる

着目する指標が決まりました。次は指標の現在の状況を知り、どこまで改善できると良いかの目標を立てます。現実と理想の両方を知り、そのギャップを知ることで改善しやすくするためです。

現在の状況は https://findy-teams.com/analytics/timeline *3を確認すれば一目でわかります。自分のチームの指標を見ると、平均プルリク クローズ時間が120時間を超えており、プルリクエストを作ってからマージするまで5日ほどかかっていることが分かりました。 f:id:shiba_yu36:20220105165231p:plain

さらにどこまで改善すべきかを考えます。これはエリート DevOps チームであることを Four Keys プロジェクトで確認するに生産性4指標の目安が書かれているので、そちらを参照すると良いでしょう。特に以下の画像が参考になります。

エリート DevOps チームであることを Four Keys プロジェクトで確認する

この画像で、Elite/High/Medium/Lowなチームにおいて4指標が大体どの範囲にあるかを知ることができます。これによると、以下のことが分かります。

  • Lead time for changesは1st commit〜リリースまでの時間である
  • Eliteなら1日以内、Highなら1週間以内、Mediumなら1ヶ月以内、Lowならそれ以上である

さらにLead time for changesは、「1st commit〜プルリク作成」 + 「プルリク作成〜マージ」 + 「マージ〜リリース」と分解できます。「プルリク作成〜マージ」はFindy Teamsにおける「平均プルリク クローズ時間」に相当します。

現在の「平均プルリク クローズ時間」が120時間以上ということは、少なくとも「1st commit〜リリース」は1週間は超えており、現在のチームはMediumな状態です。そこで目安として、Highな状態であると言える状態を目指そうと考えました。

Highなチームなら「1st commit〜リリース」が1週間以内なので、「平均プルリク クローズ時間」はそれよりは大分短くなる必要があります。これまでの自分の開発経験から「1st commit〜リリース」が1週間以内なチームとなるためには、「平均プルリク クローズ時間」は少なくとも48時間以内、できれば24時間以内でないと厳しいことがわかっていました。そこで「平均プルリク クローズ時間」が少なくとも48時間以内、できれば24時間以内を目標としました。

指標とチームの様子の両方を観察し、ボトルネックを見つけ、改善する

これまでで、現在と目標が大体決まりました。

  • 現在：「平均プルリク クローズ時間」が120時間
  • 目標：「平均プルリク クローズ時間」が少なくとも48時間以内、できれば24時間以内

あとはチームのボトルネックを見つけ、改善するだけです。指標だけを見ているとチームのボトルネックが何かを判断することが難しいので、ここからはチームで何が起きているかの観察もしながら改善していきます。

チーム状況を観察しながら、この数ヶ月で次のような改善をしました。

  • 重要なタスクに集中できる環境を作るため、既存基盤のメンテナンスガイドラインを作る
  • コードレビュー依頼があったら、すぐにレビューに取り掛かれる仕組みを作る
  • 困った時に素早く相談できるようにペアを作り、手戻りが少なくなるように

重要なタスクに集中できる環境を作るため、既存基盤のメンテナンスガイドラインを作る

まずチームを観察していて最初に気づいたのは、Work In Progress(WIP)状態のタスクがチーム規模に対して非常に多いということでした。チームとしては、ユーザー体験の改善や会社内のDX改善のために、Auth0を使った認証基盤のリアーキテクチャを最重要と考えています。一方で既存の認証基盤に対するバグ報告や改善要望が、他チームやテストチームからたくさん寄せられていました。結果、既存の認証基盤のメンテナンスのタスクをチームの手に余る量こなしており、最重要と考えている認証基盤のリアーキテクチャが進まない状況になってしまっていました。

WIPなタスクの量がチームのキャパを超えていることは、指標にも現れていました。WIPタスク数が多いと、その分「開きっぱなしのプルリク」の数も増え、「平均プルリク クローズ時間」が遅くなっていきます。Findy Teamsで「平均プルリク クローズ時間」が非常に長いことが確認できており、やはりWIP状態のタスクが多すぎる状況になっている可能性が高いと感じました。

そこでまず、チームが今最重要と考えているAuth0を使った認証基盤に集中できる環境を作るため、既存基盤のメンテナンスガイドラインを作ることにしました。提案内容はこちら。

# 既存認証の機能追加・メンテナンスのガイドラインを設けたい

## 目的や課題意識

  • 背景：アカウント基盤チームでは、既存の認証の調査・バグフィックス・機能追加を行いながら、認証をAuth0によってリアーキテクチャするプロジェクトを進行させている
  • 課題：既存認証の調査・バグフィックスなどのコストが重く、この調子で進めてしまうとAuth0での認証リアーキテクチャプロジェクトの進行がズルズル遅れてしまう可能性がある
  • 既存の認証のメンテナンスをどこまでやるかのガイドラインを決め、Auth0リアーキテクチャを素早く進行したい
    • Auth0での認証リアーキテクチャが素早く進むことはANDPADのユーザーへの価値提供にも大きくつながると考えている。なぜならリアーキテクチャにより、ユーザーの認証体験の向上、ユーザーへの新しい認証機能の提供スピード向上、セキュリティリスクの減少、開発者の認証実装負担の軽減を見込めるため

## 改善案

以下のガイドラインに基づいて、やらない、やるかどうかの判断を入れる、やるの3段階で考える。影響範囲 x クリティカル度 x 工数で判断する。

  • やらない
    • 特定のクライアントにしか影響しないちょっとした機能追加・改善
    • 不具合だが認証としては機能しているもの
    • Auth0に移行しきれない機能。最終的に使えなくなってしまうため
  • やる
    • 脆弱性などのインシデントレベルの不具合
    • 認証が通らないなどのクリティカルな不具合 && お客さんの設定の工夫では解決が非常に難しいもの
  • やるかどうかの判断を入れる
    • 「やる」と「やらない」の中間のものは必ず判断を入れる
    • 例
      • クリティカルな不具合だが、影響範囲が狭くお客さんの工夫で解決可能なもの
      • お客さんからの機能要望
      • 事業戦略として重要な機能追加

現在は新しいタスクが入ったら必ずこのガイドラインの3段階のどこに入るかをチームで会話し、優先度を定めるようにしています。このように取り組むタスクを制限することでWIP状態のタスクが多すぎる問題を解消できました。また、ガイドラインに従うことで既存の認証基盤に対する本当に重要なタスクはこなしながら、認証基盤のリアーキテクチャには集中できる状況が作りやすくなりました。

コードレビュー依頼があったら、すぐにレビューに取り掛かれる仕組みを作る

さらに観察したところ、プルリク作成からレビューまでの平均時間が30時間を超えていて、かつ体感としてもコードレビューが行われないと感じることが頻繁にありました。コードレビューのスピードというGoogleの記事によると、「集中状態にあるタスクがない場合には、レビュー対象のコードが来たすぐ後にコードレビューを行なわなければなりません」と、コードレビューは即座に行うことが重要と示されています。プルリク作成からレビューまでの時間を改善するためにも、コードレビュー依頼があったら、すぐにレビューに取り掛かれる仕組みを作る必要があると考えました。

コードレビューを即座に行うためには、レビュー依頼が行われたことやレビューが完了したことを即座に知れるようにすることと、集中状態で無くなった時にレビューするべき一覧は何かを即座に知れるようにすることの両方が重要です。そこで次のような改善提案をしました。

  • GitHubの個人のPullRemindersのreal-time alertsをonにする
    • 理由) レビュー依頼が行われたこと、自分のPRのレビューが完了したことを素早く知るため
    • https://github.com/settings/reminders からorgごとにPullRequestのリマインダを設定できるため、Enable real-time alertsをonにしてもらう
    • 最低限、「You are assigned a review」「Your team is assigned a review」「Your PR is approved or has changes requested」をonにしてもらい、他は個人のやり方に任せる
    • 例) 自分は通知で集中が阻害されたとしても早めに通知が欲しいので、以下のように設定
      • f:id:shiba_yu36:20220103143926p:plain:w400
  • アカウント基盤チーム用のGitHub TeamのPullRemindersで、チームのSlackにレビュー依頼一覧を投稿
    • 理由) 集中状態で無くなった時にレビューするべき一覧は何かを即座に知れるように
    • 1日3回ほど投稿する
    • 設定例 f:id:shiba_yu36:20220103144351p:plain

困った時に早めに相談できるようにペアを作り、手戻りが少なくなるように

また、他の人に頼るタイミングを逃し自分一人で長く悩んでしまうという問題もありました。これは手戻りの増加に繋がり、「レビュー後クローズまでの時間」が長くなってしまう原因になります。また今回の着目指標には入っていませんが「1st commit〜プルリク作成」へ非常に悪影響を与えます。

そこで手戻りが少なくなるように、困った時に早めに相談できるようにペアを作ることにしました。チームの中でメインで動いているエンジニアが4人いたので、ペアを2つ作り、それぞれのペアで密にコミュニケーションを取りながらタスクをこなしていくように変えました。

ボトルネックの改善の結果、平均プルリク クローズ時間が目標の24時間以内に

以上、着目する指標とチームの様子の両方を観察しながらボトルネックを見つけ、それに対して改善をいくつか取ってきました。結果、以下の図のように、Findy Teamsの平均プルリク クローズ時間の指標が、チームに入った2021/10当時は120時間だったのが、現在は23時間ほどまで改善しました。

f:id:shiba_yu36:20220105165347p:plain

目標として立てた24時間以内まで短縮でき、実感としてもプルリクを送ったらすぐにレビューが返ってくる状況でストレスフリーに開発できてきています。

最後に

今回はFindy Teamsの指標を使い、チームのボトルネックを見極め、チームの改善をする様子を書きました。定量的な指標を用いることで、ボトルネックを明確にしやすくなり、なぜそのような改善をしたいかをチームに示しやすくなったため、チーム改善自体も他のメンバーに納得してもらいやすくなったと感じます。

一方で課題もあります。今回はFour Keysにおける「変更のリードタイム」の一部の「平均プルリク クローズ時間」に着目しました。ただFour Keysの一部だけに注目してしまうと、例えば「変更のリードタイム」を短くしたいがためにレビューが雑になりメンテナンス品質が落ちていた、ということが起きてしまうこともあります。Four Keysの全ての指標を見ながらチーム改善をすると、このような変なハックが行われる可能性は低くなるため、Four Keys全てのトラッキングが今後の課題です。Findy Teamsで「デプロイの頻度」「変更障害率」「サービス復元時間」なども取れるようになると嬉しいですね。

最後にPRです。現在アンドパッドでは一緒に働く仲間を大募集しています。今回の記事のように、生産性の指標を見ながら改善していくこともできますので、このようなことに興味がある人がいれば一緒に働きましょう。

engineer.andpad.co.jp

参考資料

前職で行ったことを書いた内容も参考になると思うので、よければご覧ください。

*1:https://engineering-org.findy-teams.com/posts/andpad-interview/

*2:「変更のリードタイム」 = 「1st commit〜プルリク作成」 + 「プルリク作成〜マージ」 + 「マージ〜リリース」と分解できる。Findy Teamsの「平均プルリク クローズ時間」は「プルリク作成〜マージ」なので、「平均プルリク クローズ時間」は「変更のリードタイム」の一部である。

*3:閲覧にはログインが必要です。https://findy-teams.com/service_introductionも参考にしてください。