Findy Team+で開発生産性向上に取り組んだ話

我々は、普段からスプリントレビューやスプリントレトロスペクティブ、ワーキングアグリーメントなどを取り入れて日々チームとして開発プロセスの改善に取り組んでいました。しかし、いずれもチームメンバーの主観・直感に基づいた改善しか行うことができず、手応えが薄い状況でした。

Findy Team+を導入したことで、開発プロセスの各工程を具体的な数値として客観的に把握・分析できるようになり、そこから自分たちの状況に合わせたプロセス改善を実施できるようになりました。

最初の取り組みとして、スプリントレトロスペクティブの中でFindy Team+のサイクルタイム分析機能を利用した開発タスクの振り返りを行いました。

サイクルタイム分析ではスプリントの単位で次の期間の平均時間を確認することができます。

• Gitの作業用ブランチを作成してからプルリクエストをオープン（開始）するまで
• プルリクエストがオープンされてからレビューが開始されるまで
• プルリクエストレビューがアプルーブ（承認）されるまで
• プルリクエストがマージされるまで

これらを振り返りの材料とすることで、

• 今回はどこで滞留が起きていたのか
• 前回と比べて何が変わったのか

チーム全員で客観的な数値として確認・分析できるようになりました。導入前は個人の主観・直感に依存していたので、これは我々にとって大きな変化でした。

スプリントレビューでの振り返り資料

振り返りをこのやり方に変えたことによって、次の効果を得ることができました。

• 具体的な狙いを持って改善策を考えられる。
• 実行した改善策の成果を可視化できる。

例えば添付の画像を例にすると、

• 具体的な狙いを持って改善策を考えられる。
  「プルリクエストレビューがアプルーブされるまでの時間を短くするため」に「タスクの粒度を細かくすること」、「プルリクエストに気づいたら最優先で対応すること」に取り組みました。
• 実行した改善策の成果を可視化できる。
  タスクの粒度を細かくしたことで、「プルリクエストレビューがアプルーブされるまでの時間」が「10時間」と「プルリクエストをオープンするまでの時間」が「7時間」、それぞれ短くなり改善の方針が適切だったことを具体的な数値として確認できたので、この取り組み内容を開発ルールに取り入れました。

この課題に対して、レビュワーの指定方法を見直すことにしました。

• 変更前： レビュワーをチーム全員に指定し、手の空いた人が対応
• 変更後： プルリクエストごとに特定の1名をレビュワーに指定

「全員に指定する＝誰かがやるだろう」という状態になっていたものを、1名に責任を明確化することで、レビューの滞留を解消する狙いです。

以下は、Findy Team+での推移グラフです。

グラフを見ると、2026年1月30日以降プルリクエストの件数は増えていますが、オープンからマージまでの平均時間（黄色の線）が明確に低下していることがわかります。また、オープンからレビューまでの平均時間（オレンジ色の線）も低下しており、24時間以内が目標のところ、約4時間まで改善することができました。

この改善は、Findy Team+で数値を継続的にモニタリングしていたからこそ、チーム構成の変化によるプロセスの機能不全に早期に気づき、具体的な施策（レビュワー指定方法の変更）につなげることができた結果だと考えています。

mazucocoチームの開発フローの中で特に課題となっていたのが、プルリクエストレビューで次の2点です。

• レビュー完了の判断基準が明確でない
• 「誰が・いつ・どこまで見ればよいか」が属人化していた

その結果、プルリクエストが滞留しやすく、サイクルタイムの増加につながっていました。

もう一つの大きな課題は、とにかくレビューに時間がかかることでした。

• 実装の意図を読み解くのに時間がかかる
• 軽微な指摘に時間を取られてしまう

この状態では、レビュー待ちがボトルネックとなり、開発全体の流れが滞ってしまいます。

mazucocoチームでは、2週間に一度、サイクルタイム分析を踏まえた振り返りを実施するようにしました。

• サイクルタイムを可視化
• チーム独自に「平均コメント対応スピード」を算出
• 数値を基に議論することで、感覚論を排除

振り返りのフレームワークとしては、KPT（Keep / Problem / Try）を採用し、改善点を継続的に洗い出すようにしました。

振り返りの結果、次のようなものをTryとして取り組むことにしました。

レビューの属人化を防ぐため、次のルールを明確化しました。

• プルリクエストは2人以上のLGTMコメント後にマージ
• マージはプルリクエスト作成者が速やかに実施

これにより、「誰の判断で止まっているのか」が分かりやすくなり、レビュー待ちの停滞を減らすことができました。

レビュー時間短縮のために、GitHub Copilotを事前レビュー役として活用しました。

• Copilotにある程度レビューさせた状態でプルリクエストを作成
• レビュアーは本質的な観点（設計・意図）に集中

これにより、人がゼロからレビューする負担を軽減し、全体のレビュー速度向上につなげています。

まず注力していきたいのは、これまで行ってきた改善活動を社内に認知してもらうことです。

• 数値のビフォー・アフターだけでなく、そこに至るまでの試行錯誤も含めて共有する
• 「ツールを導入した」という事実ではなく、「どう活用し、何が変わったのか」を伝える

こうした情報発信を通じて、同じような課題を抱える他のチームが、改善活動を自分たちにも適用できるものとして捉えられる状態を目指します。
改善を一部の取り組みに留めず、再現可能なアプローチとして認識してもらうことが重要だと考えています。

もう一つの重要なテーマが、社内でFindy Team+を使ってくれる人を増やすことです。

Findy Team+を活用することで、

• 開発プロセスを数値として捉えられるようになる
• 振り返りの議論が感覚論ではなく、事実ベースで行えるようになる
• 改善の効果を継続的に確認できる

といった変化が生まれてきました。

今後は、
「Findy Team+の設定方法」や「機能紹介」よりも、
「Findy Team+を使うことで、チームの会話や意思決定がどう変わるのか」
に焦点を当てた事例共有を進めていく予定です。

具体的な活用イメージを持ってもらうことで、ツール導入の心理的ハードルを下げ、自然と利用が広がっていく状態を目指します。

最終的な目的は、特定のツールや手法を広めることではありません。
数字を見て振り返り、改善を試し、その結果をまた確認する――
このサイクルが日常的に回る環境を社内に根付かせることです。

これまでの取り組みや得られた知見を共有しながら、より多くのチームが自分たちに合った形で改善を進められるよう、今後も実践と発信を続けていきます。