PR Agent × Findy Team+が生み出すデータドリブンな開発改善。PRのリードタイムを平均14日間から5日間へ短縮した株式会社つみきの取り組みとは？
PR Agent × Findy Team+が生み出すデータドリブンな開発改善。PRのリードタイムを平均14日間から5日間へ短縮した株式会社つみきの取り組みとは？
目次
目次を読み込み中...
本記事のサマリ
導入前：解決したかった課題
開発状況の可視化が不十分で、どこに課題やボトルネックがあるかを把握するのが難しい状態だった。そのため、改善の方向性を議論する際にも感覚や経験に頼る場面が多く、開発スピードを向上させることが難しい状況になっていた。また、経営層との共通の指標を持つのが難しかった。
Findy Team+を導入した理由
開発プロセスの可視化と、リードタイム短縮のための共通指標を確立するため。特に、Four Keys指標を活用し、課題の特定と定量的な改善を進める仕組みを整えたかった。
導入の決め手
Four Keysの可視化とPRごとのリードタイム分析により、開発のボトルネックを明確化できる点。データに基づいた議論が可能になり、経営層とエンジニアの認識を統一できると判断した。
導入後：成果
PRのリードタイムが平均14日間から5日間以内に短縮。レビュー数が増加し、PRの滞留が解消。レベル分類による優先度の明確化で、チーム全体の開発プロセスが効率化された。
PR Agent × Findy Team+が生み出すデータドリブンな開発改善。株式会社つみきの取り組みとは？
国内最大級の映画・ドラマ・アニメのレビューサービス「Filmarks（フィルマークス）」の開発・運営を行っている株式会社つみきでは、エンジニア組織の開発生産性向上とプロセス改善に向けて、「Findy Team+」を活用しています。
今回は、プロダクトマネジメントとエンジニアマネジメントを担当する野田氏にインタビュー。「Findy Team+」導入の背景や、開発生産性向上に向けた具体的な取り組み、そして導入後の成果について詳しく伺いました。
――御社のエンジニア組織について詳しく教えてください。
野田：私たちの開発組織は、エンジニア約20名で構成されています。プロダクトの開発を中心に、複数のチームが協力しながらスプリント開発を進めています。私自身は、プロダクトマネジメントとエンジニアマネジメントの両方を担当し、開発チーム全体の生産性向上や開発者体験の改善に取り組んでいます。
――開発組織としてのミッションについて教えてください。
野田：私たちのミッションは、ユーザーが快適にプロダクトを利用できる環境を提供し続けることです。そのために、開発のスピードと品質の両立を意識し、改善や新機能を迅速にリリースできる開発体制の構築に注力しています。
――現在の開発体制について、もう少し詳しく教えていただけますか？
野田：開発Unitは、それぞれの専門領域に応じてチームに分かれています。基本的にスプリント単位での開発を行っており、定期的にふりかえりを実施しながら、プロセスの改善を図っています。私たちの強みは、このふりかえり文化が根付いていることです。エンジニア自身が主体的に改善を提案し、試行錯誤を重ねながら組織の生産性向上に取り組んでいます。
経営とエンジニアが同じ視点を持つために──開発生産性の「共通言語」を求めて
――開発生産性の計測に取り組もうとしたきっかけを教えてください。
野田：開発生産性を向上させることは、エンジニア組織にとって常に求められるテーマです。しかし、「生産性が上がった」と言える明確な指標がなかったんです。特に、経営層とエンジニアの間で「生産性」の捉え方にズレがありました。経営層からは「もっと早く開発してほしい」という期待がありますが、開発プロセスにはレビューや品質管理などの重要なステップが含まれており、それらを無視して単純にスピードを上げることはできません。
そこで、経営層とエンジニアが共通の指標を持ち、同じ視点で生産性を語れるようにするために、開発生産性の可視化に取り組むことにしました。
独自の分析に限界を感じたタイミングで出会った、Findy Team+という選択肢
――導入前に抱えていた課題について教えてください。
野田：一番の課題は、開発プロセスの可視化ができていなかったことです。「なんとなく開発のスピードが遅い」「もっと効率的にできるはず」といった抽象的な議論はあるものの、具体的に何がボトルネックになっているのか、どのプロセスを改善すればいいのかが分からない状況でした。
また、評価の仕方も属人的になりがちでした。例えば、「あのエンジニアは対応が早い」といった定性的なフィードバックに依存しており、組織全体の改善につながる仕組みにはなっていませんでした。
――Findy Team+を導入するきっかけは何だったのでしょうか？
野田：当時、開発生産性を可視化する方法を模索していたのですが、自分たちでGitHubのデータを分析するのは手間がかかるし、継続的にメンテナンスをするのが難しいと感じていました。そんなときに、社内のエンジニアがFindy Team+の記事を見つけて、「これ、良さそうじゃない？」と共有してくれたんです。
ちょうどその頃、会社全体でも「可視化を強化しよう」という流れがあり、経営層との共通認識を持つためのツールとしてFindy Team+の導入を決めました。
――導入はスムーズに進みましたか？
野田：そうですね、比較的スムーズでした。確かにまとまったコストはかかりましたが、手作業でのデータ分析にかかるコストと比較すると、導入する価値は十分にあると説明し、社内の理解を得ることができました。特に、「経営層とエンジニアの間で共通の指標を持てるようになる」という点が評価され、スムーズに導入が進んだと思います。
また、導入にあたって「このツールを使うことで、具体的にどんな効果があるのか？」という点をしっかり説明しました。実際、Findy Team+のレポート機能を活用することで、「どのプロセスにボトルネックがあるのか」が可視化できるようになり、それが経営層への説明にも役立っています。
PRを“AIで分類・分析”する文化へ──大きなPRを見直し、組織全体の改善議論を活性化
――AI（PR Agent）×Findy Team+の活用方法についてお伺いさせてください。現在、PR Agentをどのように活用されているのでしょうか？
野田：もともとはAIレビューでの活用を期待していたのですが、現状では「PRの難易度を分類するラベリング機能」に特化して活用しています。
利用するなかでPR Agentが自動的にeffort（弊社ではわかりやすくレベルと呼んでいます。）を5段階でつけてくれる機能に着目しました。PRのレベルを4段階に分類し、これを基に、「まずはレベル1・2の簡単なPRからレビューしよう」という文化を作りました。その結果、新しくジョインしたエンジニアでもレビューに参加しやすくなり、チーム全体のレビュー数が増えました。
また、「特定のメンバーにレビューが偏る」という課題もありましたが、PRのレベルを可視化したことで、「このPRは誰でもレビューできる」という判断がしやすくなり、レビュワーの負担が分散されるようになりました。
――実際にFindy Team+とのかけ合わせでは、どのように活用されていますか？
野田：主にサイクルタイムの分析やPRのモニタリングに活用しています。特に、レベルごとの分類を活用して、開発プロセスのどこに課題があるのかを特定し、改善につなげる取り組みを行っています。
分析方法としては、分類したレベルごとにチームモニタリングを作成、それぞれのリードタイムを計測しています。最初は開発組織全体の数値を確認し、その後、レベルごとに分析を行なっています。「どのレベルのPRが特に時間がかかっているのか」を分析して、改善の優先順位を決めるという流れです。
例えば、導入当初はレベル4（最もリードタイムが長いカテゴリ）のPRが多く、開発のボトルネックになっていました。そこで、「レベル4のPRをできるだけなくす」という方針を決め、PRの分割やレビューの仕組みの見直しを行いました。その結果、現在ではレベル4のPRはほとんど発生しなくなり、開発のリードタイムが短縮されています。
――レベル4のPRをなくすために、具体的にどのような取り組みをされたのでしょうか？
野田：まず、レベル4のPRが発生した場合は、そのままレビューを進めずに「分割できないか」を検討するようにしました。チーム内でも、「このPRは大きすぎるので、分けたほうがいい」という共通認識を持つようになり、自然とPRのサイズが適切になっていきました。
PRを再考するという文化を作れたことで、「最近4が増えてきてますね。なにかissueの粒度が粗いのかも、複雑な実装をしているのかも。もっと改善できないか」などのように、負債がたまる予兆のようなものを以前よりも議論できるようになりました。
また、スプリントごとにチーム比較機能を活用し、各レベルごとのリードタイムの推移をチェックしました。特に、レベル3のPRのリードタイムをどう短縮するかが次の課題として浮かび上がり、「レベル3のPR数を減らすのか、リードタイムを短縮するのか」という議論をチームで重ねながら改善に取り組んでいます。
リードタイムが平均14日間から5日間以内に──可視化とふりかえりが生んだ改善のサイクル
――Findy Team+の導入後、どのような成果が出ましたか？
野田：一番の成果は開発のリードタイムが短縮されたことです。導入前は、PRのリードタイムが平均約14日間ほどかかっていましたが、現在では5日間以内に収まるようになりました。現在は次のステップの取り組みをしているため、多少リードタイムがあがっているところはありますが、それも目標に達成した上での取り組みなのでチームとしても納得感をもって取り組めています。
また、新しい取り組みに対しても1スプリントで結果をふりかえり、リードタイムの増加傾向をすぐに判断できるようになりました。
加えて、全体としてレビュー数が大きく上昇しました。レビュワーの偏りが施策前は大きく、その人たちに頼っていた部分が大きかったのですが、負荷軽減にも効果を発揮していると感じます。可視化することで定期的に見直す機会があるのも成果の一つと言えるでしょう。
定性的な部分でも、チームの開発者体験（DevEx）が向上していると感じています。特に、「PRが滞留しにくくなった」「レビューの優先順位が明確になった」という点で、エンジニアからのポジティブなフィードバックが増えました。
――新しい取り組みに対しても1スプリントで結果のふりかえりをしているとのことですが、具体的にお伺いしてもよろしいでしょうか？
野田：私たちのチームは、2週間に1回のふりかえりを必ず実施する文化が根付いています。そのため、新しい施策やツールを試す際にも、「まずはスプリントで試してみる」「2週間後のふりかえりで評価し、続けるか判断する」という流れができています。
Findy Team+の導入や、PR Agentの活用も同じプロセスで進めてきました。エンジニアが「試してみて、ダメだったらやめる」というスタンスで改善を進められる環境があるので、チーム全体が積極的に生産性向上に取り組めるようになっています。
また、ふりかえりの手法自体も、飽きさせない工夫をしています。例えば、「KPT（Keep, Problem, Try）」を長く使っていたのですが、徐々にマンネリ化してきたため、ふりかえりのフレームワークを定期的に変えるようにしました。加えて、ファシリテーターもローテーションで担当し、特定の人に負担が集中しないようにしています。この「ふりかえりをふりかえる」という文化が、組織の改善スピードを支えていると感じています。
Four Keys＋SPACE指標でDevExも可視化──Findy Team+へのさらなる期待
――今後、さらに開発生産性を向上させるために取り組みたいことはありますか？
野田：現在はPR単位での開発プロセス改善に取り組んでいますが、今後はタスク設計の可視化にも力を入れていきたいと考えています。
例えば、PRが作成される前の段階で、タスクの粒度を適切に設定することで、開発の見積もり精度を向上させ、スムーズなPR作成につなげることができると考えています。また、GitHub IssueやJiraなどのタスク管理ツールとの連携を強化することで、開発フロー全体を可視化し、さらなる改善に取り組んでいきたいですね。
――Findy Team+への期待や、今後一緒に取り組んでいきたいことがあれば教えてください。
野田：現在のFindy Team+は、主にコーディング以降の開発プロセスを可視化するのに役立っていますが、今後はタスクの計画や管理の段階から可視化できると、より強力なツールになると考えています。
また、開発生産性を測る指標として「Four Keys」に加えて、開発者体験（DevEx）を評価する指標も取り入れたいと考えています。Findy Team+のサーベイ機能を活用し、SPACE指標の可視化にもトライしていきたいです。
――最後に、エンジニア組織の魅力や、採用に向けたメッセージをお願いします。
野田：私たちの組織は、新しい技術やツールを積極的に取り入れ、開発生産性を向上させることに本気で取り組んでいます。エンジニア一人ひとりが主体的に改善を進められる環境があり、「やりたい」と思ったことを試せる文化があります。開発生産性の向上やチームの成長に興味がある方は、ぜひ一緒に働きましょう！
※現在つみきでは、エンジニアを募集しています。
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
本記事のサマリ
導入前：解決したかった課題
開発状況の可視化が不十分で、どこに課題やボトルネックがあるかを把握するのが難しい状態だった。そのため、改善の方向性を議論する際にも感覚や経験に頼る場面が多く、開発スピードを向上させることが難しい状況になっていた。また、経営層との共通の指標を持つのが難しかった。
Findy Team+を導入した理由
開発プロセスの可視化と、リードタイム短縮のための共通指標を確立するため。特に、Four Keys指標を活用し、課題の特定と定量的な改善を進める仕組みを整えたかった。
導入の決め手
Four Keysの可視化とPRごとのリードタイム分析により、開発のボトルネックを明確化できる点。データに基づいた議論が可能になり、経営層とエンジニアの認識を統一できると判断した。
導入後：成果
PRのリードタイムが平均14日間から5日間以内に短縮。レビュー数が増加し、PRの滞留が解消。レベル分類による優先度の明確化で、チーム全体の開発プロセスが効率化された。
PR Agent × Findy Team+が生み出すデータドリブンな開発改善。株式会社つみきの取り組みとは？
国内最大級の映画・ドラマ・アニメのレビューサービス「Filmarks（フィルマークス）」の開発・運営を行っている株式会社つみきでは、エンジニア組織の開発生産性向上とプロセス改善に向けて、「Findy Team+」を活用しています。
今回は、プロダクトマネジメントとエンジニアマネジメントを担当する野田氏にインタビュー。「Findy Team+」導入の背景や、開発生産性向上に向けた具体的な取り組み、そして導入後の成果について詳しく伺いました。
――御社のエンジニア組織について詳しく教えてください。
野田：私たちの開発組織は、エンジニア約20名で構成されています。プロダクトの開発を中心に、複数のチームが協力しながらスプリント開発を進めています。私自身は、プロダクトマネジメントとエンジニアマネジメントの両方を担当し、開発チーム全体の生産性向上や開発者体験の改善に取り組んでいます。
――開発組織としてのミッションについて教えてください。
野田：私たちのミッションは、ユーザーが快適にプロダクトを利用できる環境を提供し続けることです。そのために、開発のスピードと品質の両立を意識し、改善や新機能を迅速にリリースできる開発体制の構築に注力しています。
――現在の開発体制について、もう少し詳しく教えていただけますか？
野田：開発Unitは、それぞれの専門領域に応じてチームに分かれています。基本的にスプリント単位での開発を行っており、定期的にふりかえりを実施しながら、プロセスの改善を図っています。私たちの強みは、このふりかえり文化が根付いていることです。エンジニア自身が主体的に改善を提案し、試行錯誤を重ねながら組織の生産性向上に取り組んでいます。
経営とエンジニアが同じ視点を持つために──開発生産性の「共通言語」を求めて
――開発生産性の計測に取り組もうとしたきっかけを教えてください。
野田：開発生産性を向上させることは、エンジニア組織にとって常に求められるテーマです。しかし、「生産性が上がった」と言える明確な指標がなかったんです。特に、経営層とエンジニアの間で「生産性」の捉え方にズレがありました。経営層からは「もっと早く開発してほしい」という期待がありますが、開発プロセスにはレビューや品質管理などの重要なステップが含まれており、それらを無視して単純にスピードを上げることはできません。
そこで、経営層とエンジニアが共通の指標を持ち、同じ視点で生産性を語れるようにするために、開発生産性の可視化に取り組むことにしました。
独自の分析に限界を感じたタイミングで出会った、Findy Team+という選択肢
――導入前に抱えていた課題について教えてください。
野田：一番の課題は、開発プロセスの可視化ができていなかったことです。「なんとなく開発のスピードが遅い」「もっと効率的にできるはず」といった抽象的な議論はあるものの、具体的に何がボトルネックになっているのか、どのプロセスを改善すればいいのかが分からない状況でした。
また、評価の仕方も属人的になりがちでした。例えば、「あのエンジニアは対応が早い」といった定性的なフィードバックに依存しており、組織全体の改善につながる仕組みにはなっていませんでした。
――Findy Team+を導入するきっかけは何だったのでしょうか？
野田：当時、開発生産性を可視化する方法を模索していたのですが、自分たちでGitHubのデータを分析するのは手間がかかるし、継続的にメンテナンスをするのが難しいと感じていました。そんなときに、社内のエンジニアがFindy Team+の記事を見つけて、「これ、良さそうじゃない？」と共有してくれたんです。
ちょうどその頃、会社全体でも「可視化を強化しよう」という流れがあり、経営層との共通認識を持つためのツールとしてFindy Team+の導入を決めました。
――導入はスムーズに進みましたか？
野田：そうですね、比較的スムーズでした。確かにまとまったコストはかかりましたが、手作業でのデータ分析にかかるコストと比較すると、導入する価値は十分にあると説明し、社内の理解を得ることができました。特に、「経営層とエンジニアの間で共通の指標を持てるようになる」という点が評価され、スムーズに導入が進んだと思います。
また、導入にあたって「このツールを使うことで、具体的にどんな効果があるのか？」という点をしっかり説明しました。実際、Findy Team+のレポート機能を活用することで、「どのプロセスにボトルネックがあるのか」が可視化できるようになり、それが経営層への説明にも役立っています。
PRを“AIで分類・分析”する文化へ──大きなPRを見直し、組織全体の改善議論を活性化
――AI（PR Agent）×Findy Team+の活用方法についてお伺いさせてください。現在、PR Agentをどのように活用されているのでしょうか？
野田：もともとはAIレビューでの活用を期待していたのですが、現状では「PRの難易度を分類するラベリング機能」に特化して活用しています。
利用するなかでPR Agentが自動的にeffort（弊社ではわかりやすくレベルと呼んでいます。）を5段階でつけてくれる機能に着目しました。PRのレベルを4段階に分類し、これを基に、「まずはレベル1・2の簡単なPRからレビューしよう」という文化を作りました。その結果、新しくジョインしたエンジニアでもレビューに参加しやすくなり、チーム全体のレビュー数が増えました。
また、「特定のメンバーにレビューが偏る」という課題もありましたが、PRのレベルを可視化したことで、「このPRは誰でもレビューできる」という判断がしやすくなり、レビュワーの負担が分散されるようになりました。
――実際にFindy Team+とのかけ合わせでは、どのように活用されていますか？
野田：主にサイクルタイムの分析やPRのモニタリングに活用しています。特に、レベルごとの分類を活用して、開発プロセスのどこに課題があるのかを特定し、改善につなげる取り組みを行っています。
分析方法としては、分類したレベルごとにチームモニタリングを作成、それぞれのリードタイムを計測しています。最初は開発組織全体の数値を確認し、その後、レベルごとに分析を行なっています。「どのレベルのPRが特に時間がかかっているのか」を分析して、改善の優先順位を決めるという流れです。
例えば、導入当初はレベル4（最もリードタイムが長いカテゴリ）のPRが多く、開発のボトルネックになっていました。そこで、「レベル4のPRをできるだけなくす」という方針を決め、PRの分割やレビューの仕組みの見直しを行いました。その結果、現在ではレベル4のPRはほとんど発生しなくなり、開発のリードタイムが短縮されています。
――レベル4のPRをなくすために、具体的にどのような取り組みをされたのでしょうか？
野田：まず、レベル4のPRが発生した場合は、そのままレビューを進めずに「分割できないか」を検討するようにしました。チーム内でも、「このPRは大きすぎるので、分けたほうがいい」という共通認識を持つようになり、自然とPRのサイズが適切になっていきました。
PRを再考するという文化を作れたことで、「最近4が増えてきてますね。なにかissueの粒度が粗いのかも、複雑な実装をしているのかも。もっと改善できないか」などのように、負債がたまる予兆のようなものを以前よりも議論できるようになりました。
また、スプリントごとにチーム比較機能を活用し、各レベルごとのリードタイムの推移をチェックしました。特に、レベル3のPRのリードタイムをどう短縮するかが次の課題として浮かび上がり、「レベル3のPR数を減らすのか、リードタイムを短縮するのか」という議論をチームで重ねながら改善に取り組んでいます。
リードタイムが平均14日間から5日間以内に──可視化とふりかえりが生んだ改善のサイクル
――Findy Team+の導入後、どのような成果が出ましたか？
野田：一番の成果は開発のリードタイムが短縮されたことです。導入前は、PRのリードタイムが平均約14日間ほどかかっていましたが、現在では5日間以内に収まるようになりました。現在は次のステップの取り組みをしているため、多少リードタイムがあがっているところはありますが、それも目標に達成した上での取り組みなのでチームとしても納得感をもって取り組めています。
また、新しい取り組みに対しても1スプリントで結果をふりかえり、リードタイムの増加傾向をすぐに判断できるようになりました。
加えて、全体としてレビュー数が大きく上昇しました。レビュワーの偏りが施策前は大きく、その人たちに頼っていた部分が大きかったのですが、負荷軽減にも効果を発揮していると感じます。可視化することで定期的に見直す機会があるのも成果の一つと言えるでしょう。
定性的な部分でも、チームの開発者体験（DevEx）が向上していると感じています。特に、「PRが滞留しにくくなった」「レビューの優先順位が明確になった」という点で、エンジニアからのポジティブなフィードバックが増えました。
――新しい取り組みに対しても1スプリントで結果のふりかえりをしているとのことですが、具体的にお伺いしてもよろしいでしょうか？
野田：私たちのチームは、2週間に1回のふりかえりを必ず実施する文化が根付いています。そのため、新しい施策やツールを試す際にも、「まずはスプリントで試してみる」「2週間後のふりかえりで評価し、続けるか判断する」という流れができています。
Findy Team+の導入や、PR Agentの活用も同じプロセスで進めてきました。エンジニアが「試してみて、ダメだったらやめる」というスタンスで改善を進められる環境があるので、チーム全体が積極的に生産性向上に取り組めるようになっています。
また、ふりかえりの手法自体も、飽きさせない工夫をしています。例えば、「KPT（Keep, Problem, Try）」を長く使っていたのですが、徐々にマンネリ化してきたため、ふりかえりのフレームワークを定期的に変えるようにしました。加えて、ファシリテーターもローテーションで担当し、特定の人に負担が集中しないようにしています。この「ふりかえりをふりかえる」という文化が、組織の改善スピードを支えていると感じています。
Four Keys＋SPACE指標でDevExも可視化──Findy Team+へのさらなる期待
――今後、さらに開発生産性を向上させるために取り組みたいことはありますか？
野田：現在はPR単位での開発プロセス改善に取り組んでいますが、今後はタスク設計の可視化にも力を入れていきたいと考えています。
例えば、PRが作成される前の段階で、タスクの粒度を適切に設定することで、開発の見積もり精度を向上させ、スムーズなPR作成につなげることができると考えています。また、GitHub IssueやJiraなどのタスク管理ツールとの連携を強化することで、開発フロー全体を可視化し、さらなる改善に取り組んでいきたいですね。
――Findy Team+への期待や、今後一緒に取り組んでいきたいことがあれば教えてください。
野田：現在のFindy Team+は、主にコーディング以降の開発プロセスを可視化するのに役立っていますが、今後はタスクの計画や管理の段階から可視化できると、より強力なツールになると考えています。
また、開発生産性を測る指標として「Four Keys」に加えて、開発者体験（DevEx）を評価する指標も取り入れたいと考えています。Findy Team+のサーベイ機能を活用し、SPACE指標の可視化にもトライしていきたいです。
――最後に、エンジニア組織の魅力や、採用に向けたメッセージをお願いします。
野田：私たちの組織は、新しい技術やツールを積極的に取り入れ、開発生産性を向上させることに本気で取り組んでいます。エンジニア一人ひとりが主体的に改善を進められる環境があり、「やりたい」と思ったことを試せる文化があります。開発生産性の向上やチームの成長に興味がある方は、ぜひ一緒に働きましょう！
※現在つみきでは、エンジニアを募集しています。
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
PR Agent × Findy Team+が生み出すデータドリブンな開発改善。PRのリードタイムを平均14日間から5日間へ短縮した株式会社つみきの取り組みとは？
本記事のサマリ
導入前：解決したかった課題
開発状況の可視化が不十分で、どこに課題やボトルネックがあるかを把握するのが難しい状態だった。そのため、改善の方向性を議論する際にも感覚や経験に頼る場面が多く、開発スピードを向上させることが難しい状況になっていた。また、経営層との共通の指標を持つのが難しかった。
Findy Team+を導入した理由
開発プロセスの可視化と、リードタイム短縮のための共通指標を確立するため。特に、Four Keys指標を活用し、課題の特定と定量的な改善を進める仕組みを整えたかった。
導入の決め手
Four Keysの可視化とPRごとのリードタイム分析により、開発のボトルネックを明確化できる点。データに基づいた議論が可能になり、経営層とエンジニアの認識を統一できると判断した。
導入後：成果
PRのリードタイムが平均14日間から5日間以内に短縮。レビュー数が増加し、PRの滞留が解消。レベル分類による優先度の明確化で、チーム全体の開発プロセスが効率化された。
PR Agent × Findy Team+が生み出すデータドリブンな開発改善。株式会社つみきの取り組みとは？
国内最大級の映画・ドラマ・アニメのレビューサービス「Filmarks（フィルマークス）」の開発・運営を行っている株式会社つみきでは、エンジニア組織の開発生産性向上とプロセス改善に向けて、「Findy Team+」を活用しています。
今回は、プロダクトマネジメントとエンジニアマネジメントを担当する野田氏にインタビュー。「Findy Team+」導入の背景や、開発生産性向上に向けた具体的な取り組み、そして導入後の成果について詳しく伺いました。
――御社のエンジニア組織について詳しく教えてください。
野田：私たちの開発組織は、エンジニア約20名で構成されています。プロダクトの開発を中心に、複数のチームが協力しながらスプリント開発を進めています。私自身は、プロダクトマネジメントとエンジニアマネジメントの両方を担当し、開発チーム全体の生産性向上や開発者体験の改善に取り組んでいます。
――開発組織としてのミッションについて教えてください。
野田：私たちのミッションは、ユーザーが快適にプロダクトを利用できる環境を提供し続けることです。そのために、開発のスピードと品質の両立を意識し、改善や新機能を迅速にリリースできる開発体制の構築に注力しています。
――現在の開発体制について、もう少し詳しく教えていただけますか？
野田：開発Unitは、それぞれの専門領域に応じてチームに分かれています。基本的にスプリント単位での開発を行っており、定期的にふりかえりを実施しながら、プロセスの改善を図っています。私たちの強みは、このふりかえり文化が根付いていることです。エンジニア自身が主体的に改善を提案し、試行錯誤を重ねながら組織の生産性向上に取り組んでいます。
経営とエンジニアが同じ視点を持つために──開発生産性の「共通言語」を求めて
――開発生産性の計測に取り組もうとしたきっかけを教えてください。
野田：開発生産性を向上させることは、エンジニア組織にとって常に求められるテーマです。しかし、「生産性が上がった」と言える明確な指標がなかったんです。特に、経営層とエンジニアの間で「生産性」の捉え方にズレがありました。経営層からは「もっと早く開発してほしい」という期待がありますが、開発プロセスにはレビューや品質管理などの重要なステップが含まれており、それらを無視して単純にスピードを上げることはできません。
そこで、経営層とエンジニアが共通の指標を持ち、同じ視点で生産性を語れるようにするために、開発生産性の可視化に取り組むことにしました。
独自の分析に限界を感じたタイミングで出会った、Findy Team+という選択肢
――導入前に抱えていた課題について教えてください。
野田：一番の課題は、開発プロセスの可視化ができていなかったことです。「なんとなく開発のスピードが遅い」「もっと効率的にできるはず」といった抽象的な議論はあるものの、具体的に何がボトルネックになっているのか、どのプロセスを改善すればいいのかが分からない状況でした。
また、評価の仕方も属人的になりがちでした。例えば、「あのエンジニアは対応が早い」といった定性的なフィードバックに依存しており、組織全体の改善につながる仕組みにはなっていませんでした。
――Findy Team+を導入するきっかけは何だったのでしょうか？
野田：当時、開発生産性を可視化する方法を模索していたのですが、自分たちでGitHubのデータを分析するのは手間がかかるし、継続的にメンテナンスをするのが難しいと感じていました。そんなときに、社内のエンジニアがFindy Team+の記事を見つけて、「これ、良さそうじゃない？」と共有してくれたんです。
ちょうどその頃、会社全体でも「可視化を強化しよう」という流れがあり、経営層との共通認識を持つためのツールとしてFindy Team+の導入を決めました。
――導入はスムーズに進みましたか？
野田：そうですね、比較的スムーズでした。確かにまとまったコストはかかりましたが、手作業でのデータ分析にかかるコストと比較すると、導入する価値は十分にあると説明し、社内の理解を得ることができました。特に、「経営層とエンジニアの間で共通の指標を持てるようになる」という点が評価され、スムーズに導入が進んだと思います。
また、導入にあたって「このツールを使うことで、具体的にどんな効果があるのか？」という点をしっかり説明しました。実際、Findy Team+のレポート機能を活用することで、「どのプロセスにボトルネックがあるのか」が可視化できるようになり、それが経営層への説明にも役立っています。
PRを“AIで分類・分析”する文化へ──大きなPRを見直し、組織全体の改善議論を活性化
――AI（PR Agent）×Findy Team+の活用方法についてお伺いさせてください。現在、PR Agentをどのように活用されているのでしょうか？
野田：もともとはAIレビューでの活用を期待していたのですが、現状では「PRの難易度を分類するラベリング機能」に特化して活用しています。
利用するなかでPR Agentが自動的にeffort（弊社ではわかりやすくレベルと呼んでいます。）を5段階でつけてくれる機能に着目しました。PRのレベルを4段階に分類し、これを基に、「まずはレベル1・2の簡単なPRからレビューしよう」という文化を作りました。その結果、新しくジョインしたエンジニアでもレビューに参加しやすくなり、チーム全体のレビュー数が増えました。
また、「特定のメンバーにレビューが偏る」という課題もありましたが、PRのレベルを可視化したことで、「このPRは誰でもレビューできる」という判断がしやすくなり、レビュワーの負担が分散されるようになりました。
――実際にFindy Team+とのかけ合わせでは、どのように活用されていますか？
野田：主にサイクルタイムの分析やPRのモニタリングに活用しています。特に、レベルごとの分類を活用して、開発プロセスのどこに課題があるのかを特定し、改善につなげる取り組みを行っています。
分析方法としては、分類したレベルごとにチームモニタリングを作成、それぞれのリードタイムを計測しています。最初は開発組織全体の数値を確認し、その後、レベルごとに分析を行なっています。「どのレベルのPRが特に時間がかかっているのか」を分析して、改善の優先順位を決めるという流れです。
例えば、導入当初はレベル4（最もリードタイムが長いカテゴリ）のPRが多く、開発のボトルネックになっていました。そこで、「レベル4のPRをできるだけなくす」という方針を決め、PRの分割やレビューの仕組みの見直しを行いました。その結果、現在ではレベル4のPRはほとんど発生しなくなり、開発のリードタイムが短縮されています。
――レベル4のPRをなくすために、具体的にどのような取り組みをされたのでしょうか？
野田：まず、レベル4のPRが発生した場合は、そのままレビューを進めずに「分割できないか」を検討するようにしました。チーム内でも、「このPRは大きすぎるので、分けたほうがいい」という共通認識を持つようになり、自然とPRのサイズが適切になっていきました。
PRを再考するという文化を作れたことで、「最近4が増えてきてますね。なにかissueの粒度が粗いのかも、複雑な実装をしているのかも。もっと改善できないか」などのように、負債がたまる予兆のようなものを以前よりも議論できるようになりました。
また、スプリントごとにチーム比較機能を活用し、各レベルごとのリードタイムの推移をチェックしました。特に、レベル3のPRのリードタイムをどう短縮するかが次の課題として浮かび上がり、「レベル3のPR数を減らすのか、リードタイムを短縮するのか」という議論をチームで重ねながら改善に取り組んでいます。
リードタイムが平均14日間から5日間以内に──可視化とふりかえりが生んだ改善のサイクル
――Findy Team+の導入後、どのような成果が出ましたか？
野田：一番の成果は開発のリードタイムが短縮されたことです。導入前は、PRのリードタイムが平均約14日間ほどかかっていましたが、現在では5日間以内に収まるようになりました。現在は次のステップの取り組みをしているため、多少リードタイムがあがっているところはありますが、それも目標に達成した上での取り組みなのでチームとしても納得感をもって取り組めています。
また、新しい取り組みに対しても1スプリントで結果をふりかえり、リードタイムの増加傾向をすぐに判断できるようになりました。
加えて、全体としてレビュー数が大きく上昇しました。レビュワーの偏りが施策前は大きく、その人たちに頼っていた部分が大きかったのですが、負荷軽減にも効果を発揮していると感じます。可視化することで定期的に見直す機会があるのも成果の一つと言えるでしょう。
定性的な部分でも、チームの開発者体験（DevEx）が向上していると感じています。特に、「PRが滞留しにくくなった」「レビューの優先順位が明確になった」という点で、エンジニアからのポジティブなフィードバックが増えました。
――新しい取り組みに対しても1スプリントで結果のふりかえりをしているとのことですが、具体的にお伺いしてもよろしいでしょうか？
野田：私たちのチームは、2週間に1回のふりかえりを必ず実施する文化が根付いています。そのため、新しい施策やツールを試す際にも、「まずはスプリントで試してみる」「2週間後のふりかえりで評価し、続けるか判断する」という流れができています。
Findy Team+の導入や、PR Agentの活用も同じプロセスで進めてきました。エンジニアが「試してみて、ダメだったらやめる」というスタンスで改善を進められる環境があるので、チーム全体が積極的に生産性向上に取り組めるようになっています。
また、ふりかえりの手法自体も、飽きさせない工夫をしています。例えば、「KPT（Keep, Problem, Try）」を長く使っていたのですが、徐々にマンネリ化してきたため、ふりかえりのフレームワークを定期的に変えるようにしました。加えて、ファシリテーターもローテーションで担当し、特定の人に負担が集中しないようにしています。この「ふりかえりをふりかえる」という文化が、組織の改善スピードを支えていると感じています。
Four Keys＋SPACE指標でDevExも可視化──Findy Team+へのさらなる期待
――今後、さらに開発生産性を向上させるために取り組みたいことはありますか？
野田：現在はPR単位での開発プロセス改善に取り組んでいますが、今後はタスク設計の可視化にも力を入れていきたいと考えています。
例えば、PRが作成される前の段階で、タスクの粒度を適切に設定することで、開発の見積もり精度を向上させ、スムーズなPR作成につなげることができると考えています。また、GitHub IssueやJiraなどのタスク管理ツールとの連携を強化することで、開発フロー全体を可視化し、さらなる改善に取り組んでいきたいですね。
――Findy Team+への期待や、今後一緒に取り組んでいきたいことがあれば教えてください。
野田：現在のFindy Team+は、主にコーディング以降の開発プロセスを可視化するのに役立っていますが、今後はタスクの計画や管理の段階から可視化できると、より強力なツールになると考えています。
また、開発生産性を測る指標として「Four Keys」に加えて、開発者体験（DevEx）を評価する指標も取り入れたいと考えています。Findy Team+のサーベイ機能を活用し、SPACE指標の可視化にもトライしていきたいです。
――最後に、エンジニア組織の魅力や、採用に向けたメッセージをお願いします。
野田：私たちの組織は、新しい技術やツールを積極的に取り入れ、開発生産性を向上させることに本気で取り組んでいます。エンジニア一人ひとりが主体的に改善を進められる環境があり、「やりたい」と思ったことを試せる文化があります。開発生産性の向上やチームの成長に興味がある方は、ぜひ一緒に働きましょう！
※現在つみきでは、エンジニアを募集しています。
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
