受託開発組織でアウトカム向上を目指す。Findy Team+ Award 2年連続受賞・エックスポイントワンが示す“開発生産性向上”の取り組み
受託開発組織でアウトカム向上を目指す。Findy Team+ Award 2年連続受賞・エックスポイントワンが示す“開発生産性向上”の取り組み
目次
目次を読み込み中...
本記事のサマリ
導入前：解決したかった課題
エンジニアの評価が定性的・属人的であった点や、施策の効果を客観的に評価できていない点が課題でした。また、受託開発の利益に直結する工数あたりのアウトプットを、定量的に測定し改善する必要がありました。
Findy Team+を導入した理由
開発生産性の主要指標であるFour Keysを計測・分析し、データに基づいた改善サイクルを確立することで、エンジニアの評価やプロジェクトの健全性を客観的に把握できるデータドリブンな組織づくりを目指すために導入を検討しました。
導入の決め手
Four Keys計測・分析の仕組みを自前で構築するコストと比較して、利用料が安価であるという価格優位性が大きな魅力でした。加えて、GitHub Projects連携や将来的なアウトカム測定まで見据えたプロダクトの将来性が、自社の目指す方向性と一致したことも決め手となりました。
導入後：成果
サイクルタイムが22.4時間から13.3時間へと約半分に短縮し、エンジニア1人1日あたりのマージ済みプルリクエスト数も2.6件から4.2件へと増加するなど、数値として明確な成果が出ました。また、データを基に課題が可視化され、チームが自発的に改善策を講じるようになるなど、データドリブンな組織文化の醸成が進みました。
受託開発組織でアウトカム向上を目指す。Findy Team+ Award 2年連続受賞・エックスポイントワンが示す“開発生産性向上”の取り組み
クライアントの多様なニーズに応える受託開発を主力事業としながら、開発生産性の向上に先進的に取り組んできた株式会社エックスポイントワン。その功績は、優れた取り組みを行った企業を表彰する「Findy Team+ Award」の2年連続受賞という快挙にも表れています。
多くの受託開発組織が、プロジェクトごとに異なる技術スタックや文化、そして開発スタイルから、組織横断での生産性評価に課題を抱えています。その中で同社は、いかにしてFour Keysを指標とした改善サイクルを確立し、組織全体の成長を加速させているのか。本記事では、CTOの鈴木様とEMの中山様のお二人に、Findy Team+導入の背景から具体的な取り組み、そして今後の展望についてお話を伺いました。
──本日はよろしくお願いいたします。まずはお二人の自己紹介と、貴社開発組織についてお伺いできますでしょうか。
鈴木： 取締役CTOの鈴木です。AI受託企業での長期インターン、自社開発企業でのSaaS運用・保守を経て、エックスポイントワンにリードエンジニアとして入社しました。現在は、エンジニアやPM、QAなどを含む生産部門全体を指揮しています。
中山： リードエンジニアの中山です。プロダクトの新規開発や保守運用を担当しつつ、若手エンジニアの育成も行っています。
鈴木： 我々の組織としては、全社で23名、うちエンジニアが8名という少数精鋭の体制です。組織のミッションとして「すべての課題に境界なく立ち向かい解決すること」を掲げています。
中山： 開発組織の雰囲気としては、非常にフラットだなと感じています。意思決定のスピードが速く、技術的にも組織的にも変化を恐れない文化が特徴です。
属人化した評価からの脱却。客観的な”ものさし”が組織を変えた
──開発生産性の計測に取り組みをしようとしたきっかけは何でしょうか？
鈴木： 開発生産性の計測に踏み切った理由は、大きく三つあります。まず、エンジニアの評価をそれまでの定性的なものから定量的な指標に基づいた形にしたかったこと。次に、様々な施策の効果を客観的に評価したかったこと。そして最も重要な理由は、我々のビジネスモデルそのものと深く関わっています。
──ビジネスモデル、ですか。
鈴木： はい。突き詰めると、受託開発は労働集約型のビジネスモデルです。そのため、工数あたりのアウトプット量を増やすことが、そのまま会社の利益に直結します。
何かを改善しようと思ったとき、まずそれを測定する仕組みから始めなければ、改善の方向性も効果も分かりません 。開発生産性を高めるためには、まずそれを定量的に評価する必要がある。これが計測に踏み切った最大の動機です。
──様々なツールがある中で、Findy Team+を選ばれた決め手は何だったのでしょうか？
鈴木： 当初、GitHub Marketplaceで公開されているFour Keys計測用のActionの利用も試みました。しかし、それをチームで活用し、様々な角度から分析できる仕組みまで自前で構築するとなると、そのコストは決して小さくありません。Findy Team+の利用料は、その内製化コストと比較して非常に安いと感じました 。プロダクトの価格優位性は大きな魅力でしたね。
中山：プロダクトの将来性への期待も大きかったです。単にFour Keysを測定するだけでなく、GitHub Projectsとの連携や、将来的にはアウトカムの測定まで見据えて開発を進めている点に惹かれました。より高いレイヤーの人間が求めるデータまで可視化しようとしている。そこに、我々が目指す方向性との一致を感じました。
データが組織を動かす。「サイクルタイム13.3時間」への道のり
──Findy Team+を導入し、組織として何を目指しましたか？
鈴木： 目指したのは、一貫して「データドリブンな組織づくり」です。その中でも、最初に特に重要視したのが「リードタイムの短縮」でした。リードタイムは開発プロセスにおける非常に重要な指標だと考えています。リードタイムが短ければ、エンドユーザーに価値提供するスピードが上がり、CS向上に繋がる。なにより、早期にデバッグに取り組めるため、品質向上にも繋がります。
中山： 具体的には、新規プロジェクトでスクラム開発とFindy Team+を同時に導入しました。そして、Findy Team+で計測されるサイクルタイムやマージ済みプルリクエスト数といった重要指標を、週次でトラッキングすることから始めました。
──その成果はいかがでしたか？
中山： 数字として明確な成果が出ています。昨年と比較すると、サイクルタイムは22.4時間から13.3時間へと約半分に短縮されました。また、エンジニア1人1日あたりのプルリクエスト作成数も、平均2.6件から4.2件へと大きく増加しています。
2024年7月〜12月までのサイクルタイムの平均値
2025年1月〜6月までのサイクルタイムの平均値
2024年7月〜12月まで（左）と2025年1月〜6月まで（右）のマージ済みプルリク数の推移と総量
鈴木： また、定性的な面でも大きな変化がありました。私のような立場からすると、各プロジェクトが今どんな状態なのかをデータで察知しやすくなりました 。以前よりも解像度高く、プロジェクトの健全性を評価できるようになったと感じています。
──取り組む上で難しかったポイントはありましたか？
中山： メンバーのレビュー力向上を目的として導入した「相互レビュー」と、「リードタイム短縮」の両立です。1つのプルリクエストを複数人でレビューするため、どうしてもレビュー依頼からマージまでの時間が長くなってしまいました。エンジニア全員でレビューの質を担保しつつ、どうすればリードタイムを短縮できるか。これは大きな挑戦でした。
──どのように乗り越えられたのでしょうか？
中山： スプリントのレトロスペクティブ（振り返り）で、メンバーにFindy Team+の数値を公開し、サイクルタイムをKPIとして意識してもらうことから始めました 。データを皆で見たところ、レビューから承認までの時間が特に長いことが一目瞭然でした。この事実をチームで共有し、皆で対策を考えました。「プルリクエストの粒度をもっと小さくしよう」「実装作業よりも、他のメンバーのレビューを優先しよう」といったルールが、チームの中から自発的に生まれたのです。結果として、レビューの観点が統一され、リードタイムも大きく改善されました。
AIは暴走列車。レールを敷き、組織の武器とする
──AIの活用も積極的に行われていると伺いました。
鈴木： はい。生成AIの導入も、意思決定から導入完了まで約1ヶ月というスピードで実現しました。現在、PMがGeminiで提案スライドを作成したり 、Claude Codeをエンジニア全員に配布し、GitHubのIssueからコードを8割方生成する、といった活用を進めています。GitHub Copilotによるコードレビューも行っています。
中山： AIは強力なツールですが、同時に「暴走列車」のような側面も持っていると考えています。そのため、私たちが重視しているのは、AIを適切にコントロールするための「レール」をしっかりと作ることです。例えば、汎用的なIssueテンプレートを用意し、それに沿って記述された内容をインプットとすることで、AIによる出力のばらつきを小さくしています。
また、Figmaのアノテーションを活用して、フロントエンドのコードを生成するといった工夫も行っています。よろしければこちらの記事もご参照ください。
静的なFigmaデザインから動的なUIを生成 〜AIに”動き”を伝える「アノテーション駆動開発」〜
https://zenn.dev/x_point_1/articles/d9c51ede3c31ef
目指すは「持続的に高い生産性を発揮できる組織」
──最後に、今後の展望と、一緒に働きたいエンジニア像をお聞かせください。
鈴木：今後、我々が目指すのは「高い生産性を持続的に発揮できる組織」、そして「技術や市場の変化に柔軟に適応できる強い組織」です。そのために、データに基づいた改善サイクルを回し続けることを重視しています。
また、これからのAI駆動開発の時代において、単にアウトプットを出すことは当たり前になっていくでしょう。その流れも踏まえると、その先にある「アウトカム」、つまり事業へどれだけ貢献できたかという点がさらに重要になります。
そうなると、エンジニアに求められるスキルも当然変わってきます。「コードが書けること」の価値は以前より相対的に低くなり、むしろ要件定義や設計といった上流工程にしっかり対応できる能力がより一層求められてきます。また、技術力だけでなく、例えば周囲の助けを上手に借りる力や、チームに活気をもたらすといった『人間力』も含めた『総合力』が、これからますます重要になってくると考えています。
我々は少数精鋭で、0→1のフルスクラッチ開発に携われる機会も多く、社会課題の解決に高頻度で挑戦できる環境です。このエキサイティングな挑戦を、『面白い』と感じて一緒に楽しんでくれる方と、ぜひご一緒したいですね。
※株式会社エックスポイントワンの公式サイトは以下よりご覧いただけます。
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
本記事のサマリ
導入前：解決したかった課題
エンジニアの評価が定性的・属人的であった点や、施策の効果を客観的に評価できていない点が課題でした。また、受託開発の利益に直結する工数あたりのアウトプットを、定量的に測定し改善する必要がありました。
Findy Team+を導入した理由
開発生産性の主要指標であるFour Keysを計測・分析し、データに基づいた改善サイクルを確立することで、エンジニアの評価やプロジェクトの健全性を客観的に把握できるデータドリブンな組織づくりを目指すために導入を検討しました。
導入の決め手
Four Keys計測・分析の仕組みを自前で構築するコストと比較して、利用料が安価であるという価格優位性が大きな魅力でした。加えて、GitHub Projects連携や将来的なアウトカム測定まで見据えたプロダクトの将来性が、自社の目指す方向性と一致したことも決め手となりました。
導入後：成果
サイクルタイムが22.4時間から13.3時間へと約半分に短縮し、エンジニア1人1日あたりのマージ済みプルリクエスト数も2.6件から4.2件へと増加するなど、数値として明確な成果が出ました。また、データを基に課題が可視化され、チームが自発的に改善策を講じるようになるなど、データドリブンな組織文化の醸成が進みました。
受託開発組織でアウトカム向上を目指す。Findy Team+ Award 2年連続受賞・エックスポイントワンが示す“開発生産性向上”の取り組み
クライアントの多様なニーズに応える受託開発を主力事業としながら、開発生産性の向上に先進的に取り組んできた株式会社エックスポイントワン。その功績は、優れた取り組みを行った企業を表彰する「Findy Team+ Award」の2年連続受賞という快挙にも表れています。
多くの受託開発組織が、プロジェクトごとに異なる技術スタックや文化、そして開発スタイルから、組織横断での生産性評価に課題を抱えています。その中で同社は、いかにしてFour Keysを指標とした改善サイクルを確立し、組織全体の成長を加速させているのか。本記事では、CTOの鈴木様とEMの中山様のお二人に、Findy Team+導入の背景から具体的な取り組み、そして今後の展望についてお話を伺いました。
──本日はよろしくお願いいたします。まずはお二人の自己紹介と、貴社開発組織についてお伺いできますでしょうか。
鈴木： 取締役CTOの鈴木です。AI受託企業での長期インターン、自社開発企業でのSaaS運用・保守を経て、エックスポイントワンにリードエンジニアとして入社しました。現在は、エンジニアやPM、QAなどを含む生産部門全体を指揮しています。
中山： リードエンジニアの中山です。プロダクトの新規開発や保守運用を担当しつつ、若手エンジニアの育成も行っています。
鈴木： 我々の組織としては、全社で23名、うちエンジニアが8名という少数精鋭の体制です。組織のミッションとして「すべての課題に境界なく立ち向かい解決すること」を掲げています。
中山： 開発組織の雰囲気としては、非常にフラットだなと感じています。意思決定のスピードが速く、技術的にも組織的にも変化を恐れない文化が特徴です。
属人化した評価からの脱却。客観的な”ものさし”が組織を変えた
──開発生産性の計測に取り組みをしようとしたきっかけは何でしょうか？
鈴木： 開発生産性の計測に踏み切った理由は、大きく三つあります。まず、エンジニアの評価をそれまでの定性的なものから定量的な指標に基づいた形にしたかったこと。次に、様々な施策の効果を客観的に評価したかったこと。そして最も重要な理由は、我々のビジネスモデルそのものと深く関わっています。
──ビジネスモデル、ですか。
鈴木： はい。突き詰めると、受託開発は労働集約型のビジネスモデルです。そのため、工数あたりのアウトプット量を増やすことが、そのまま会社の利益に直結します。
何かを改善しようと思ったとき、まずそれを測定する仕組みから始めなければ、改善の方向性も効果も分かりません 。開発生産性を高めるためには、まずそれを定量的に評価する必要がある。これが計測に踏み切った最大の動機です。
──様々なツールがある中で、Findy Team+を選ばれた決め手は何だったのでしょうか？
鈴木： 当初、GitHub Marketplaceで公開されているFour Keys計測用のActionの利用も試みました。しかし、それをチームで活用し、様々な角度から分析できる仕組みまで自前で構築するとなると、そのコストは決して小さくありません。Findy Team+の利用料は、その内製化コストと比較して非常に安いと感じました 。プロダクトの価格優位性は大きな魅力でしたね。
中山：プロダクトの将来性への期待も大きかったです。単にFour Keysを測定するだけでなく、GitHub Projectsとの連携や、将来的にはアウトカムの測定まで見据えて開発を進めている点に惹かれました。より高いレイヤーの人間が求めるデータまで可視化しようとしている。そこに、我々が目指す方向性との一致を感じました。
データが組織を動かす。「サイクルタイム13.3時間」への道のり
──Findy Team+を導入し、組織として何を目指しましたか？
鈴木： 目指したのは、一貫して「データドリブンな組織づくり」です。その中でも、最初に特に重要視したのが「リードタイムの短縮」でした。リードタイムは開発プロセスにおける非常に重要な指標だと考えています。リードタイムが短ければ、エンドユーザーに価値提供するスピードが上がり、CS向上に繋がる。なにより、早期にデバッグに取り組めるため、品質向上にも繋がります。
中山： 具体的には、新規プロジェクトでスクラム開発とFindy Team+を同時に導入しました。そして、Findy Team+で計測されるサイクルタイムやマージ済みプルリクエスト数といった重要指標を、週次でトラッキングすることから始めました。
──その成果はいかがでしたか？
中山： 数字として明確な成果が出ています。昨年と比較すると、サイクルタイムは22.4時間から13.3時間へと約半分に短縮されました。また、エンジニア1人1日あたりのプルリクエスト作成数も、平均2.6件から4.2件へと大きく増加しています。
2024年7月〜12月までのサイクルタイムの平均値
2025年1月〜6月までのサイクルタイムの平均値
2024年7月〜12月まで（左）と2025年1月〜6月まで（右）のマージ済みプルリク数の推移と総量
鈴木： また、定性的な面でも大きな変化がありました。私のような立場からすると、各プロジェクトが今どんな状態なのかをデータで察知しやすくなりました 。以前よりも解像度高く、プロジェクトの健全性を評価できるようになったと感じています。
──取り組む上で難しかったポイントはありましたか？
中山： メンバーのレビュー力向上を目的として導入した「相互レビュー」と、「リードタイム短縮」の両立です。1つのプルリクエストを複数人でレビューするため、どうしてもレビュー依頼からマージまでの時間が長くなってしまいました。エンジニア全員でレビューの質を担保しつつ、どうすればリードタイムを短縮できるか。これは大きな挑戦でした。
──どのように乗り越えられたのでしょうか？
中山： スプリントのレトロスペクティブ（振り返り）で、メンバーにFindy Team+の数値を公開し、サイクルタイムをKPIとして意識してもらうことから始めました 。データを皆で見たところ、レビューから承認までの時間が特に長いことが一目瞭然でした。この事実をチームで共有し、皆で対策を考えました。「プルリクエストの粒度をもっと小さくしよう」「実装作業よりも、他のメンバーのレビューを優先しよう」といったルールが、チームの中から自発的に生まれたのです。結果として、レビューの観点が統一され、リードタイムも大きく改善されました。
AIは暴走列車。レールを敷き、組織の武器とする
──AIの活用も積極的に行われていると伺いました。
鈴木： はい。生成AIの導入も、意思決定から導入完了まで約1ヶ月というスピードで実現しました。現在、PMがGeminiで提案スライドを作成したり 、Claude Codeをエンジニア全員に配布し、GitHubのIssueからコードを8割方生成する、といった活用を進めています。GitHub Copilotによるコードレビューも行っています。
中山： AIは強力なツールですが、同時に「暴走列車」のような側面も持っていると考えています。そのため、私たちが重視しているのは、AIを適切にコントロールするための「レール」をしっかりと作ることです。例えば、汎用的なIssueテンプレートを用意し、それに沿って記述された内容をインプットとすることで、AIによる出力のばらつきを小さくしています。
また、Figmaのアノテーションを活用して、フロントエンドのコードを生成するといった工夫も行っています。よろしければこちらの記事もご参照ください。
静的なFigmaデザインから動的なUIを生成 〜AIに”動き”を伝える「アノテーション駆動開発」〜
https://zenn.dev/x_point_1/articles/d9c51ede3c31ef
目指すは「持続的に高い生産性を発揮できる組織」
──最後に、今後の展望と、一緒に働きたいエンジニア像をお聞かせください。
鈴木：今後、我々が目指すのは「高い生産性を持続的に発揮できる組織」、そして「技術や市場の変化に柔軟に適応できる強い組織」です。そのために、データに基づいた改善サイクルを回し続けることを重視しています。
また、これからのAI駆動開発の時代において、単にアウトプットを出すことは当たり前になっていくでしょう。その流れも踏まえると、その先にある「アウトカム」、つまり事業へどれだけ貢献できたかという点がさらに重要になります。
そうなると、エンジニアに求められるスキルも当然変わってきます。「コードが書けること」の価値は以前より相対的に低くなり、むしろ要件定義や設計といった上流工程にしっかり対応できる能力がより一層求められてきます。また、技術力だけでなく、例えば周囲の助けを上手に借りる力や、チームに活気をもたらすといった『人間力』も含めた『総合力』が、これからますます重要になってくると考えています。
我々は少数精鋭で、0→1のフルスクラッチ開発に携われる機会も多く、社会課題の解決に高頻度で挑戦できる環境です。このエキサイティングな挑戦を、『面白い』と感じて一緒に楽しんでくれる方と、ぜひご一緒したいですね。
※株式会社エックスポイントワンの公式サイトは以下よりご覧いただけます。
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
受託開発組織でアウトカム向上を目指す。Findy Team+ Award 2年連続受賞・エックスポイントワンが示す“開発生産性向上”の取り組み
本記事のサマリ
導入前：解決したかった課題
エンジニアの評価が定性的・属人的であった点や、施策の効果を客観的に評価できていない点が課題でした。また、受託開発の利益に直結する工数あたりのアウトプットを、定量的に測定し改善する必要がありました。
Findy Team+を導入した理由
開発生産性の主要指標であるFour Keysを計測・分析し、データに基づいた改善サイクルを確立することで、エンジニアの評価やプロジェクトの健全性を客観的に把握できるデータドリブンな組織づくりを目指すために導入を検討しました。
導入の決め手
Four Keys計測・分析の仕組みを自前で構築するコストと比較して、利用料が安価であるという価格優位性が大きな魅力でした。加えて、GitHub Projects連携や将来的なアウトカム測定まで見据えたプロダクトの将来性が、自社の目指す方向性と一致したことも決め手となりました。
導入後：成果
サイクルタイムが22.4時間から13.3時間へと約半分に短縮し、エンジニア1人1日あたりのマージ済みプルリクエスト数も2.6件から4.2件へと増加するなど、数値として明確な成果が出ました。また、データを基に課題が可視化され、チームが自発的に改善策を講じるようになるなど、データドリブンな組織文化の醸成が進みました。
受託開発組織でアウトカム向上を目指す。Findy Team+ Award 2年連続受賞・エックスポイントワンが示す“開発生産性向上”の取り組み
クライアントの多様なニーズに応える受託開発を主力事業としながら、開発生産性の向上に先進的に取り組んできた株式会社エックスポイントワン。その功績は、優れた取り組みを行った企業を表彰する「Findy Team+ Award」の2年連続受賞という快挙にも表れています。
多くの受託開発組織が、プロジェクトごとに異なる技術スタックや文化、そして開発スタイルから、組織横断での生産性評価に課題を抱えています。その中で同社は、いかにしてFour Keysを指標とした改善サイクルを確立し、組織全体の成長を加速させているのか。本記事では、CTOの鈴木様とEMの中山様のお二人に、Findy Team+導入の背景から具体的な取り組み、そして今後の展望についてお話を伺いました。
──本日はよろしくお願いいたします。まずはお二人の自己紹介と、貴社開発組織についてお伺いできますでしょうか。
鈴木： 取締役CTOの鈴木です。AI受託企業での長期インターン、自社開発企業でのSaaS運用・保守を経て、エックスポイントワンにリードエンジニアとして入社しました。現在は、エンジニアやPM、QAなどを含む生産部門全体を指揮しています。
中山： リードエンジニアの中山です。プロダクトの新規開発や保守運用を担当しつつ、若手エンジニアの育成も行っています。
鈴木： 我々の組織としては、全社で23名、うちエンジニアが8名という少数精鋭の体制です。組織のミッションとして「すべての課題に境界なく立ち向かい解決すること」を掲げています。
中山： 開発組織の雰囲気としては、非常にフラットだなと感じています。意思決定のスピードが速く、技術的にも組織的にも変化を恐れない文化が特徴です。
属人化した評価からの脱却。客観的な”ものさし”が組織を変えた
──開発生産性の計測に取り組みをしようとしたきっかけは何でしょうか？
鈴木： 開発生産性の計測に踏み切った理由は、大きく三つあります。まず、エンジニアの評価をそれまでの定性的なものから定量的な指標に基づいた形にしたかったこと。次に、様々な施策の効果を客観的に評価したかったこと。そして最も重要な理由は、我々のビジネスモデルそのものと深く関わっています。
──ビジネスモデル、ですか。
鈴木： はい。突き詰めると、受託開発は労働集約型のビジネスモデルです。そのため、工数あたりのアウトプット量を増やすことが、そのまま会社の利益に直結します。
何かを改善しようと思ったとき、まずそれを測定する仕組みから始めなければ、改善の方向性も効果も分かりません 。開発生産性を高めるためには、まずそれを定量的に評価する必要がある。これが計測に踏み切った最大の動機です。
──様々なツールがある中で、Findy Team+を選ばれた決め手は何だったのでしょうか？
鈴木： 当初、GitHub Marketplaceで公開されているFour Keys計測用のActionの利用も試みました。しかし、それをチームで活用し、様々な角度から分析できる仕組みまで自前で構築するとなると、そのコストは決して小さくありません。Findy Team+の利用料は、その内製化コストと比較して非常に安いと感じました 。プロダクトの価格優位性は大きな魅力でしたね。
中山：プロダクトの将来性への期待も大きかったです。単にFour Keysを測定するだけでなく、GitHub Projectsとの連携や、将来的にはアウトカムの測定まで見据えて開発を進めている点に惹かれました。より高いレイヤーの人間が求めるデータまで可視化しようとしている。そこに、我々が目指す方向性との一致を感じました。
データが組織を動かす。「サイクルタイム13.3時間」への道のり
──Findy Team+を導入し、組織として何を目指しましたか？
鈴木： 目指したのは、一貫して「データドリブンな組織づくり」です。その中でも、最初に特に重要視したのが「リードタイムの短縮」でした。リードタイムは開発プロセスにおける非常に重要な指標だと考えています。リードタイムが短ければ、エンドユーザーに価値提供するスピードが上がり、CS向上に繋がる。なにより、早期にデバッグに取り組めるため、品質向上にも繋がります。
中山： 具体的には、新規プロジェクトでスクラム開発とFindy Team+を同時に導入しました。そして、Findy Team+で計測されるサイクルタイムやマージ済みプルリクエスト数といった重要指標を、週次でトラッキングすることから始めました。
──その成果はいかがでしたか？
中山： 数字として明確な成果が出ています。昨年と比較すると、サイクルタイムは22.4時間から13.3時間へと約半分に短縮されました。また、エンジニア1人1日あたりのプルリクエスト作成数も、平均2.6件から4.2件へと大きく増加しています。
2024年7月〜12月までのサイクルタイムの平均値
2025年1月〜6月までのサイクルタイムの平均値
2024年7月〜12月まで（左）と2025年1月〜6月まで（右）のマージ済みプルリク数の推移と総量
鈴木： また、定性的な面でも大きな変化がありました。私のような立場からすると、各プロジェクトが今どんな状態なのかをデータで察知しやすくなりました 。以前よりも解像度高く、プロジェクトの健全性を評価できるようになったと感じています。
──取り組む上で難しかったポイントはありましたか？
中山： メンバーのレビュー力向上を目的として導入した「相互レビュー」と、「リードタイム短縮」の両立です。1つのプルリクエストを複数人でレビューするため、どうしてもレビュー依頼からマージまでの時間が長くなってしまいました。エンジニア全員でレビューの質を担保しつつ、どうすればリードタイムを短縮できるか。これは大きな挑戦でした。
──どのように乗り越えられたのでしょうか？
中山： スプリントのレトロスペクティブ（振り返り）で、メンバーにFindy Team+の数値を公開し、サイクルタイムをKPIとして意識してもらうことから始めました 。データを皆で見たところ、レビューから承認までの時間が特に長いことが一目瞭然でした。この事実をチームで共有し、皆で対策を考えました。「プルリクエストの粒度をもっと小さくしよう」「実装作業よりも、他のメンバーのレビューを優先しよう」といったルールが、チームの中から自発的に生まれたのです。結果として、レビューの観点が統一され、リードタイムも大きく改善されました。
AIは暴走列車。レールを敷き、組織の武器とする
──AIの活用も積極的に行われていると伺いました。
鈴木： はい。生成AIの導入も、意思決定から導入完了まで約1ヶ月というスピードで実現しました。現在、PMがGeminiで提案スライドを作成したり 、Claude Codeをエンジニア全員に配布し、GitHubのIssueからコードを8割方生成する、といった活用を進めています。GitHub Copilotによるコードレビューも行っています。
中山： AIは強力なツールですが、同時に「暴走列車」のような側面も持っていると考えています。そのため、私たちが重視しているのは、AIを適切にコントロールするための「レール」をしっかりと作ることです。例えば、汎用的なIssueテンプレートを用意し、それに沿って記述された内容をインプットとすることで、AIによる出力のばらつきを小さくしています。
また、Figmaのアノテーションを活用して、フロントエンドのコードを生成するといった工夫も行っています。よろしければこちらの記事もご参照ください。
静的なFigmaデザインから動的なUIを生成 〜AIに”動き”を伝える「アノテーション駆動開発」〜
https://zenn.dev/x_point_1/articles/d9c51ede3c31ef
目指すは「持続的に高い生産性を発揮できる組織」
──最後に、今後の展望と、一緒に働きたいエンジニア像をお聞かせください。
鈴木：今後、我々が目指すのは「高い生産性を持続的に発揮できる組織」、そして「技術や市場の変化に柔軟に適応できる強い組織」です。そのために、データに基づいた改善サイクルを回し続けることを重視しています。
また、これからのAI駆動開発の時代において、単にアウトプットを出すことは当たり前になっていくでしょう。その流れも踏まえると、その先にある「アウトカム」、つまり事業へどれだけ貢献できたかという点がさらに重要になります。
そうなると、エンジニアに求められるスキルも当然変わってきます。「コードが書けること」の価値は以前より相対的に低くなり、むしろ要件定義や設計といった上流工程にしっかり対応できる能力がより一層求められてきます。また、技術力だけでなく、例えば周囲の助けを上手に借りる力や、チームに活気をもたらすといった『人間力』も含めた『総合力』が、これからますます重要になってくると考えています。
我々は少数精鋭で、0→1のフルスクラッチ開発に携われる機会も多く、社会課題の解決に高頻度で挑戦できる環境です。このエキサイティングな挑戦を、『面白い』と感じて一緒に楽しんでくれる方と、ぜひご一緒したいですね。
※株式会社エックスポイントワンの公式サイトは以下よりご覧いただけます。
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
