こんにちは。ファインディ株式会社でテックリードをしている戸田です。
先日公開したFindy AI Meetup in Fukuoka #6のイベントレポートで、「AIで開発が速くなったはずなのに、レビューが詰まってトータルの生産性が変わらなかった」という話に触れました。
そこで今回は、そのレビュー詰まりを題材に、数値を見る → 仮説を立てる → 改善アクションを打つ → 結果を検証する というワンサイクルを1つの実例として紹介します。
Findy Team+とFindy AI+を組み合わせて、AI導入前後の数値を可視化し、そこから仮説を立て、改善アクションを打ち、結果を検証するまでの一連の流れを追っていきます。
AIで速くなったはずなのに、1人あたりの生産性は変わらなかった
開発でAIを使い始めたときの私たちの想定はシンプルでした。AIがコードを書いてくれるなら、1人あたりが生み出すアウトプットは増え、開発生産性も自然と上がる はずだ、というものです。
実際、ファインディ社内でのAIの利用率は順調に伸びていきました。多くのエンジニアが日常的にAIを使うようになり、実装そのものは速くなったという実感の声もありました。
そこで本当に生産性が上がったのかを確かめるため、Findy Team+の詳細比較機能を使ってAI導入前後の各種メトリクスを比較してみました。
すると1人あたりの生産性はほとんど変わっていなかったのです。人が増え、AIで実装も速くなった。それでも1人あたりのアウトプットは増えていない。この食い違いが、最初の重要な問いになりました。
メトリクスを深掘りして見えた「レビュー詰まり」
AI導入前後で比較した結果、1人あたりのプルリクエスト作成数は横ばいのままでした。
この理由を探るため、Findy Team+で工程ごとのメトリクスに分解して深掘りしました。
ここで注目したのは、開発フローの段階ごとの指標です。変更のリードタイム／サイクルタイム、プルリクエスト作成数、そしてプルリクエストが作られてからマージされるまでのレビュー時間、オープン時間。これらを並べて、どの段階が想定と違う動きをしているのかを見ていきました。
まず変更のリードタイムに注目しました。すると、コミットからオープンまでの平均時間は10%ほど速くなっていました。 しかし、オープンからレビューまでの平均時間は15%ほど、レビューからアプルーブまでの平均時間は30%ほど遅くなっていた ことがわかりました。
コミットしてからプルリクエストを作成するまでは若干速くなったものの、プルリクエストのオープンから、レビューをもらって最終的にアプルーブをもらうまでの時間がAI導入前よりも悪化していた ことが、数値から読み解けました。
ここまでで 1人あたりの生産性が変わらなかった理由が、プルリクエストを作成してからマージされるまでのフローにある ということが見えてきました。
プルリクエストを作成してからマージされるまでに行われる工程の1つにレビューがあります。そこでレビューの工程に関するメトリクスに注目してみました。すると、プルリクエストに対する平均コメント数が50%ほど増えている ことがわかりました。
ここまで深掘りしてわかったことは、AIによって実装にかかる時間は確かに短くなっている一方で、レビューの工程に問題が出ていたということです。
つまり、AIは開発フローの「実装」という一工程を速くしていました。しかし実装が速くなった分だけプルリクエストがレビュー待ちに積み上がり、フロー全体ではかえって詰まりやすくなっていたのです。
仮説
ここまでの分析から1つの仮説を立てました。AIで実装が速くなった分、プルリクエストの質が下がっているのではないか。その結果レビューでのやり取りが増え、アプルーブまでの時間が延び、最終的にリードタイムが悪化している のではないか、という見立てです。
この仮説の裏付けを取るために、実際にレビューでやり取りが膨らんでいたプルリクエストを取得し、コメントの中身を分類しました。
わかったのは、指摘されていた内容の半分以上が作成者自身のセルフレビューで防げるような内容だったということです。例えば、消し忘れたデバッグコード、命名やフォーマットの不統一、考慮漏れのエッジケースや、そもそもビジネスロジックと要件が一致していないなど、本来は提出前にプルリクエストの作成者が気づかないといけない指摘です。
AIが書いたコードを十分に理解しきらないままレビュー依頼を出してしまい、本来は作成者が気づくべき部分をレビュアーがコメントで補っていたのです。プルリクエストへのコメント数が50%増えていたのは、この肩代わりの表れだったわけです。仮説は、実際のプルリクエストの中身によって裏づけられました。
改善アクション
原因が レビュー依頼前のセルフレビュー不足 にあるとわかれば、打つ手は具体的になります。私たちは、セルフレビューを個人の心がけに任せるのをやめ、仕組みとして組み込むことにしました。
具体的には、複数の観点を同時にチェックするセルフレビュー用のスキルを用意しました。そして、プルリクエストを作成するタイミングでこのスキルが強制的に実行されるようにしました。提出前に、AIが書いたコードをAI自身が複数の観点からレビューする工程を、フローの中に固定したのです。
このセルフレビュー用スキルの設計や中身については、別記事で詳しく解説しています。
結果検証
改善アクションを打ったあとは、必ず数値に戻って効果を確かめます。このとき、いきなりリードタイムを見るのではなく、まず 施策がちゃんと使われているか という観点を確認するのがポイントです。
まずFindy AI+で、用意したスキルの実行状況を追いました。導入直後はばらつきがありましたが、運用に乗るにつれてスキルの利用率が上がっていきました。
利用率が十分に上がったタイミングで、改めてFindy Team+の数値を確認しました。すると、レビューからアプルーブまでの平均時間が10%ほど速くなっている ことがわかりました。実装が速くなった効果が、ようやくフロー全体の速さとして表れ始めたのです。
また、プルリクエストの平均コメント数や変更障害率も若干の改善が見られました。セルフレビューのスキルを強制したことにより、プルリクエストの質が上がり、不具合も減った ことが数値から読み取れました。
あわせてFindy AI+で、AIの使われ方そのものの推移も見てみました。改善のサイクルを回していくなかで、トークン使用量もセッション数も右肩上がりに伸びていました。そして同じ時期に、プルリクエストの作成数も増えています。
AIの活用と開発生産性がようやく同じ方向に動く、つまりAI推進と生産性がリンクし始めた ことが数値から読み取れました。
もし数値が動いていなければ、仮説か改善アクションのどちらかが外れているということなので、また数値を見るステップに戻ります。当たっていれば、次のボトルネックを探しに行く。これを繰り返すのが、可視化と改善のサイクル となります。
まとめ
このように可視化と改善を繰り返した結果、横ばいが続いていた1人あたりのプルリクエスト作成数も増加に転じました。AI導入前後の2024年から2025年では変化がありませんでしたが、セルフレビューを仕組みに組み込んだあとでは、1人あたりのプルリクエスト作成数が約1.5倍に増えていました。
今回お伝えしたかったのは、可視化と改善はセットで考える ということです。
数値を可視化するだけでは、現場は変わりません。今回も、Findy Team+で生産性が横ばいだと可視化できただけでは何も解決せず、そこからメトリクスを深掘り、仮説を立て、プルリクエストを分析して、セルフレビューを仕組みに組み込むという改善まで進めて、初めてリードタイムに変化が出ました。
逆に、可視化のない改善は再現性のないものになります。もし可視化をせずに「レビューが詰まっている」という感覚だけで打ち手を考えてしまうと、原因がプルリクエストのセルフレビュー不足にあることにも、施策が効いたかどうかにも辿り着けませんでした。
可視化が改善の入口を教え、改善の結果がまた数値に表れる。数値を見る → 仮説を立てる → 改善アクションを打つ → 結果を検証する というワンサイクルは、可視化と改善を再現性高く行う ための型です。
AIを導入しただけではアウトプットも生産性も上がりません。可視化された数値を起点に改善のサイクルを回し、ボトルネックを一つずつ解消していく。これによって初めて、AI活用は開発生産性まで繋がってきます。
私たちもまだ、次の問題を探しながら可視化と改善のサイクルを回し続けている途中です。開発生産性の向上やAI推進は、可視化と改善のサイクルを継続することで、継続して積み重ねていくもの なのです。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
