正式リリースされた Findy Teams で dinii のエンジニアリングチームの生産性を可視化してみた
こんにちは、dinii でソフトウェアエンジニアをしている唐澤 @karszawa です。先日発表された M1 Max プロセッサの MacBook Pro が届くのが楽しみすぎて気が気でない今日このごろです。
エンジニア全員分の M1 Max MBP を購入しました！ワクワク☺️ pic.twitter.com/zBZToYDZFn
— 山田真央｜ダイニー (@maochil) October 19, 2021
本日はエンジニアリングブログの第N回として、先日正式リリースされた Findy Teams を使って dinii のエンジニアリングチームの生産性を分析してみたいと思います。
Findy Teams について
Findy Teams は GitHub における種々のアクティビティを可視化して開発組織の活発度をわかりやすく教えてくれるサービスです。可視化してくれるメトリクスは定番の「マージまでの時間」や「プルリクエストの作成数」など。更にそれらの指標をメンバー（チーム）ごと・期間ごとに表示・比較できることが便利です。
似たようなサービスとして Pull Panda の Pull Analytics があり、機能は Findy Teams に劣るものの便利に使っていました。が、残念ながらサービスの買収に伴って開発が停滞してしまっており、別のツールを探しているところでした。
そもそもどうしてそういった指標を観察する必要があるのかということは Findy CTO の @ma3tk さんがわかりやすい解説ブログを書いてくれていますので、ぜひそちらをご覧ください。
dinii の様子を見てみた
まず大前提ですが、dinii のエンジニアチームは非常に小規模で、フルタイムのメンバーはなんと3名しかいません。業務委託（副業）で関わってくれているメンバーは4名いますが、フルタイムメンバーとは働き方が大きく異なるので今回はフルタイムメンバーと副業メンバーで分けて指標を見ていきます。チームごとに指標を分けて表示できる機能がとても便利です！
リードタイム
リードタイムは以上のような結果となりました。前期間との差分を比べるとプルリク作成数・クローズまでにかかった時間は減少しています。直近の数字としては プルリク作成数が日に7.5件（一人あたり2.5件）でクローズまでにかかった時間が17.9時間 でした。作成数は意識しやすいのでこんなものかと思いましたが、クローズまでにかかった時間は想定よりも長い印象です。次のような理由が考えられそうです。
ドラフトのプルリクエストが長く存在している
フレックス制なのでレビュワーとレビュイーの活動時間が一致していない
土日にプルリクエストがオープン状態のまま放置されている
ドラフトのプルリクエストや土日の分の日数もリードタイムとしてカウントされるようです。体感として遅い印象はないため、まだまだ改善の余地はあるとは思いつつ、当面はこの数字を維持できていれば問題ないでしょう。
ちなみにブログを書いている今現在のプルリクエストの作成状況は以下の図のとおりです。
オープン状態のプルリクエストはドラフトも含め11件存在しています。それぞれのプルリクエストがマージされていない理由は以下の通りです。
ドラフト → 5件
レビュー待ち → 1件
金曜の午後か土日にオープンされレビューが間に合っていないもの → 3件
金曜の午後か土日に変更依頼があり修正が間に合っていないもの → 1件
レビューは完了しているものの諸事情でマージできないもの → 1件
純粋にレビューが滞っていたと言えそうなのは1件だけでした。
また dinii の開発方針として「作業が完了していないものでも積極的にドラフト状態のプルリクエストを出す」ということを目指しているため、ドラフトの件数が約半数を占めています。今後も Findy Teams を使っていくとするとドラフトの扱いが肝になりそうです。
更に興味深い現象として、8月末のクローズ時間の増加と、9月のレビューまでにかかった時間は増加しているもののマージまでの時間は逆に減少しているという事象が挙げられます。
8月末の出来事を思い出してみると、確かにこの辺りで大きな障害が起こってしまい対応のためにコードを書くことよりも方針の検討・共有に時間を取られていた気がします。実際に数字としてその影響が見て取れ、面白いですね。
9月の現象に関しては正直理解が難しいです。求ム仮説。
プロセス別内訳
こちらではプルリクエストがクローズされるまでにどのような経緯を辿ったかということが可視化されています。
例えば一番上の帯はプルリクエストが出されてからレビューもされずにダイレクトにマージされた数を表しており、割合は14％でマージまでにかかった時間は平均1.1時間でした。レビューされないプルリクエストが存在するかと驚かれるかもしれませんが、dinii ではソースコードの管理はモノレポかつ メインライン+リリーストレイン で行っており、リリースブランチの変更はメインラインに自動作成されたプルリクエスト（Sync PR）で取り込んでいます。この Sync PR はレビュー済みのコミットをもとに作成されるため、アプルーブボタンを押す一手間を惜しんでダイレクトにマージされることがあります。ちなみに main ブランチへの直プッシュは流石に GitHub の機能で禁止しているため、main ブランチへマージされるすべてのコミットがプルリクエストになります。
レビュー後に一発でアプルーブされる割合は59%で、一度コメントが付いて修正が必要になるのは35%でした。ちなみにこれを業務委託のエンジニアに限ると即アプルーブが44％で要修正が50%になりました。コードベースへの習熟度が異なるので当たり前の差ではあり、またあまりに素通り過ぎるのも問題があるのかもしれませんが、チームの効率性の良さを表していると言えそうです。
ちなみに業務委託の方々のリードタイムは次のようになっていました。
基本的にフルタイムメンバーが稼働している時間は業務委託の方は本業の活動をされているので、どうしても時差的な問題がありリードタイムは伸びてしまっています。また、メンバーごとに働き方も全く異なるので、一人ひとりの数字を見たほうが良いかもしれません。
レビューコラボレーション
最後に、誰が誰のプルリクエストをどれだけレビューしているのかという図です。
上述の通り Sync PR が大量に作成されるやり方なので Sync PR を作成している bot が一番プルリクエストを作成しています。よく頑張ってくれています。他に見て取れる情報としては、私 karszawa と JunyaKimura ののレビュー数が比較的多いということです。dinii ではプロダクトごとにコードオーナーを設定しており、私はそのプロダクト数が最も多いためレビュー数も多いです。また JunyaKimura は dinii の唯一のバックエンドサービスである dinii-self-backend のコードオーナーのためレビュー負荷が大きいです。
チームがまだまだ小さいため、そういった状況はすでに把握できており、この程度のレビュー負荷であれば問題ないということも確かめられています。しかし、ある程度の大きさの組織では、誰が何をどのぐらいやっているかがわかりづらくなっていくと思うので、そういった組織では絶大な力を発揮するのではないかと思われます。
まとめ
長くなってしまったので今回はここまででとします。Findy Teams には他にも便利な機能がたくさんあります。例えば 1on1 の機能ではメンバーごとに他のメンバーや別の期間の自分自身とアクティビティを比較することもできます。この機能は、新規参加メンバーのオンボーディングが上手く行っているかなどを定量的に評価するのに便利だと思います。メンバーの少ない dinii では既存のメンバーのアクティビティについては把握が容易なため、むしろこういった使い方がメインになってくるかもと思いました。まあそもそも新しいメンバーが入ってくれないと意味がないんですけどね。
というわけでいつもの採用情報です！！
開発チームの活発度をメトリクスをもとに定量的に改善していきたい方はもちろん、飲食業界を変えたい方、TypeScript や JavaScript が大好きな方、GraphQL や Hasura に興味がある方にぴったりな会社だと思いますので、まずは導入店でのお食事などからいかがでしょうか？
少しでも興味があるという方は採用ページからの応募でも良いですが、筆者の Twitter でも連絡をお待ちしているので、ぜひお気軽にお声がけください。
この記事が気に入ったらサポートをしてみませんか？