「開発生産性」という新たな市場を切り拓いてきた、ファインディのエンジニア組織支援SaaS「Findy Team+」。その成長の裏側には、急速な時代変化に対応しながら、幾度となく試行錯誤を重ねてきたプロダクトと組織の進化がありました。
AIの台頭により、開発のあり方そのものが再定義されつつある今、プロダクトマネージャー(以下、PM)とエンジニアはどのように連携しながら、正解のない問いに挑み続けているのでしょうか。
プロダクトオーナーの沢井さんと、開発部長の浜田さんの二人に、Team+立ち上げから現在に至るまでのプロダクトと組織の変遷、そして2026年にリリースされた新サービス「Findy Insights」「Findy Context」が目指す未来像について語っていただきました。
既存のトレンドを追う存在から、新たなスタンダードそのものを生み出す存在へ。ファインディが挑む、次世代のプロダクト開発の現在地を紐解きます。
沢井 拓 | プロダクトマネジメント室 副室長
大学卒業後、新卒でエンジニアとしてキャリアスタート。その後、SansanにてEM、PdM、QAマネージャーなどを経験。ファインディではプロダクト戦略およびFindy Team+のプロダクトオーナーを務める。
浜田 直人 | プロダクト開発部 部長
新卒でSIerに就職後、Web系企業やスタートアップを経て、2022年5月にファインディへ参画。現在はFindy Team+開発部の部室長として開発者体験を向上させながら、開発生産性を高める方法を日々探求している。趣味は、株式投資、Moomin、筋トレ。
目次
「開発生産性」から、「経営と開発をつなぐ」プラットフォームへ進化
AIが活用する知識基盤と、人の意思決定をつなぐ新サービス
組織の機動力を最大化するPMとエンジニアの信頼関係
難易度の高い挑戦を支えた、PMとエンジニアの共創
開発のトレンドを追う側から、生み出す側へ。AI時代の“新たな標準”をつくる挑戦
さいごに
「開発生産性」から、「経営と開発をつなぐ」プラットフォームへ進化
—今回は、Findy Team+(以下、Team+)の進化の過程と、その中でPMとエンジニアがどのように連携してきたのかを伺えればと思っています。立ち上げ当初の「開発生産性の可視化・改善」から、現在では「経営と開発をつなぐ」プロダクトへと広がっていますよね。これまでどのようなフェーズを経て現在に至ったのでしょうか?
浜田:
初期構想として掲げていたのは、ファインディの転職サービスで提供している「スキル偏差値*」の考え方を、個人ではなくチーム単位へ応用することでした。プルリクエスト数やリードタイムなどを集計し、チームの状態をスコアとして表現しようとしていたんです。
スキル偏差値*:GitHubなどの公開データをもとに、エンジニアのスキルや技術力を可視化するファインディ独自のアルゴリズム
この考え方に共感してくれたスタートアップ企業を中心に、初期導入は進んでいきました。
ただ当時は、開発組織を定量的に評価すること自体への抵抗感が強い時期でもあったんですね。コミット数や開発速度を測ることそのものが、現場からネガティブに受け取られるケースも少なくありませんでした。
風向きが変わったのは、海外の研究などを通じて、「開発生産性」という言葉そのものが国内に浸透しはじめてからです。このタイミングで実施した開発生産性が優れた企業を表彰する「Findy Team+ Award」などの施策も後押しとなり、「開発生産性を可視化・改善するプロダクト」としての立ち位置が徐々に確立されていきました。
エンジニア組織の開発生産性が優れた企業「Findy Team+ Award 2023」
—今でこそソフトウェア開発における「開発生産性」の概念は知られるようになっていますが、当時はまずその価値観自体を広げていくフェーズだったんですね。
浜田:
はい。その後、スタートアップ中心だったフェーズから、エンタープライズ企業へと展開していく中で、新たな壁にも直面しました。エンタープライズ企業では、そもそもアジャイル開発が十分に浸透していないケースも多く、データを見ながら継続的に改善していく文化や体制が整っていないことも少なくありませんでした。
Team+は、本来そうした改善サイクルを回していくことで価値を発揮するプロダクトなので、ツールを導入するだけでは十分な価値につながりづらかったんです。
そこで、単なるプロダクト提供にとどまらず、「コンサルティング×SaaS」という形で、開発プロセスの改善まで伴走する方向へとシフトしていきました。実際に現場へ深く入り込む中で感じたのは、単に開発現場の効率を可視化するだけではなく、開発組織の状態を経営判断につなげていく重要性です。 「経営と開発をつなぐ」という現在のコンセプトは、そうした課題感から生まれてきたものです。
—なるほど。直近では、AIによるソフトウェア開発の変化もかなり大きいと思いますが、プロダクトの方向性にも影響を与えているのでしょうか?
浜田:
はい。実際、スタートアップなどのSMB(Small to Medium Business)領域では、すでにAIを活用した開発へのシフトが始まっています。その流れは、遅かれ早かれエンタープライズ企業にも広がっていくはずです。
だからこそTeam+においても、「AIを前提とした開発において、何を可視化するべきか」という、新たな指標を見つけていくことが重要になると考えています。
—プロダクトの方向性が変化していく中で、開発チームの体制や、事業への関わり方にも変化はあったのでしょうか?
浜田:
変わりましたね。先ほど触れたように、初期の頃は「開発生産性をどう可視化・改善するか」という比較的明確なテーマがありました。たとえば、海外の研究や書籍で紹介されている指標をどうプロダクト上で計測するか。あるいは、レビューのボトルネックをどう可視化するか、といったテーマです。
取り組むべき方向性がはっきりしていたので、開発チームとしても「いかに速く、高品質に実装するか」という実行部分に集中しやすい環境だったと思います。
ところが、AIの登場以降は、「そもそも何を測るべきなのか」という前提自体を問い直す必要が出てきました。
その結果、開発に着手する前の企画段階から、エンジニアが企画や事業サイドと一緒に議論する重要性が格段に増したと感じています。組織としても、PMやBiz側とエンジニアが一体となってプロダクトを作る体制へと進化してきました。
AIが活用する知識基盤と、人の意思決定をつなぐ新サービス
—直近では、Team+を拡張する「Findy Insights(以下、Insights)」や「Findy Context(以下、Context)」といった新サービスもリリースされていますよね。これらは、「経営と開発をつなぐ」というコンセプトの中で、どのような役割を担っているのでしょうか?
沢井:
一言で言えば、組織の知識基盤をつくる役割を担っています。
多くの企業では、重要な知見が「暗黙知」として個人の中に埋もれてしまい、経営判断に十分活用しきれていないという課題があります。InsightsやContextは、そうした課題を解決するためのプロダクトです。
Contextは、組織内の知識を蓄積・更新し続けることで、AIが価値を発揮できる基盤をつくるプロダクトです。
一方のInsightsは、そのデータを分析し、人が正しい意思決定を行うための可視化を担っています。AIが活用できる知識基盤と、人が意思決定するためのインサイト。その両方をつなぐことで、組織全体の意思決定をより良くしていきたいと考えています。
—プロダクトの領域も広がってきている中で、それぞれに対する開発リソースの配分や優先順位はどのように設計されているのでしょうか?
浜田:
現在は、それぞれのサービスごとにチームを分けて動いています。
Context専任が1チーム、Insights専任が1チーム、そしてTeam+を担当する2チームの計4チーム体制です。各チームは5名ほどで構成しており、新規領域と既存領域の優先度が混在しないように設計しています。
沢井:
プロダクトマネジメント側では、Team+に3名、Insightsに専任PMが1名いる体制です。私自身は、プロダクトオーナーとして全体を見ながら、Contextの企画も推進しています。
—なるほど。では、InsightsやContextは、Team+の延長線上にありつつも、開発体制としては独立した新規プロダクトに近い感覚なのでしょうか?
浜田:
そうですね。コードベースも完全に分かれていますから。
それもあって、既存プロダクトとの整合性に縛られることなく、プロダクトにとって最適な技術や設計をゼロベースで選択できていますね。
—開発部長である浜田さんは、各チームとどのように関わっているのですか?
浜田:
基本的には各チームのマネージャーと連携して動いていますね。
ただ、Team+では先ほどお話ししたように、AIの登場によって、「何を測るべきか」という問い自体が、再び問い直されているフェーズにあります。そのため、私自身も商談やコンサルティングに同席して直接顧客の声を拾い、現場の解像度を上げながら、プロダクトの次なる方向性を探っています。
組織の機動力を最大化するPMとエンジニアの信頼関係
—PMとエンジニアの連携についても伺わせてください。プロダクトごとにどのような体制で開発を進めているのでしょうか?
浜田:
既存サービスのTeam+と、ContextやInsightsといった新規サービスとでは、進め方に少し違いがあります。
ContextやInsightsでは、企画と開発がかなり密に連携しています。まだ市場を探索している段階なので、「どの方向性が当たるのか」をリアルタイムで議論しながら、スピード感を持って開発を進める必要があるからです。
一方、Team+では、3名のプロダクトマネージャーがそれぞれ異なる機能やテーマを担当し、そこにエンジニアがアサインされる体制になっています。
—新規サービスでは特に密に連携されているとのことですが、沢井さんはこれまでPMとして経験を積まれてきた中で、ファインディのエンジニアとの距離感についてどのように感じていますか?
沢井:
前職では、「考えるのがPM、作るのがエンジニア」という役割分担が明確でした。それ自体には合理性があると思っています。ただ、今のTeam+のフェーズでは、その進め方だけでは難しいと感じるようになりました。実際に試した時期もありましたが、プロダクトの変化スピードに対して、体制が追いつかなくなっていたんです。
そこで現在は、アイデアが生まれた段階からエンジニアと一緒に議論しています。
「どう作るか」だけでなく、「何を作るべきか」から一緒に考える。発注・受託ではなく、同じ目線でプロダクトを育てる感覚が強くなりましたね。
浜田:
組織として最適な形を模索し続けることが重要だと考えているので、開発体制も状況に応じて頻繁に見直しています。
最近も、開発優先順位の管理方法を大きく変更しました。もともとは、各メンバーが担当領域を持ちながら開発を進める体制だったのですが、一時期は全体最適を重視し、優先度の高いタスクに全員で順次取り組む形へ切り替えたんです。
ただ、実際に運用してみると、案件ごとにメンバーが流動化することでコミュニケーションコストが増えたり、担当範囲が見えづらくなったりと、運用面での課題も出てきました。また、AIの活用によって、エンジニア一人がフルスタックに開発を進めやすい環境が整いました。その結果、一つの開発に複数人で集中するよりも、各自がAIを活用しながら並行して進めたほうが、スピードも成果の伸びしろも大きい。そこで、各メンバーがそれぞれに担当領域を持ち、複数の開発を同時並行で進める形に戻しました。現在は、スキルセットによっては複数人で動くケースもありますが、基本的には一人で開発を進めるスタイルにしています。
—そうした体制変更によって、開発スピードやリリース数にも変化はありましたか?
浜田:
大きく変わっていますね。複数の開発が同時に進むようになり、全体のスピードはかなり向上しました。
加えて、担当領域が明確になったことで、個人の役割もよりクリアになっています。それによって、当事者意識も強まったと感じています。大きな方針転換ではありましたが、PM側も現場の状況をしっかり汲み取り、柔軟に合意してくれたことで、迅速に体制を戻すことができました。
実際にやってみて、違えばすぐに修正する。そうした柔軟さや意思決定の速さは、今の事業フェーズにおいて非常に重要だと感じています。
難易度の高い挑戦を支えた、PMとエンジニアの共創
—お二人が深く関わったプロジェクトの中で、特に印象に残っているものはありますか?
沢井:
特に印象深いのは、Team+における「エージェント機能」の開発ですね。
セキュリティ要件の観点から自社データセンター内にシステムを閉じ、外部との通信経路を厳格に制限している企業が一定数存在していました。となると、プロダクトの価値以前に、導入そのものが難しいわけです。
そこで、データ取得部分のみをエージェントとして切り出し、必要情報のみをTeam+へ連携する構成を採用したんです。
この方法ですべての制約を解決できるわけではありませんが、導入ハードルは大きく下がりました。これまで提案自体が難しかったエンタープライズ企業にも導入可能性が生まれ、実際に多くのお客様に受け入れていただけたのは大きな成果だったと思います。
浜田:
正直、かなり難易度の高いプロジェクトだったと思います。一方で、コンセプト段階で複数のお客さまから強い関心を得られたこともあり、事業として無視できない規模のニーズになるという確信もありました。だから、迷わず進めることにしたんです。
結果として、何も決まっていない状態から、課題の特定、解決策の設計、体制構築までを一気に進め、約4か月という短期間でプロジェクトを完遂させることができました。
—難易度が高いからこそ、PMとエンジニアの連携も重要だったと思います。進めるうえで意識していたことはありますか?
沢井:
あえて、技術的な解決策に踏み込みすぎないように意識していました。
私自身、エンジニアとしての経験があるので、どうしても細かな技術的判断に意見を挟みたくなる場面があったんです。ただ、「こうすれば実現できる」と具体的に寄せすぎてしまうと、かえって議論の幅を狭めてしまう可能性もあります。
そこで、まずはアイデアや方向性を提示し、技術的な実現可否についてはエンジニア側に委ねることにしました。技術的制約を早い段階で強く意識しすぎると、「それは難しい」という結論に寄りやすくなってしまうため、まずは可能性を広げることを優先したんです。
—お二人のお話を伺っていると、手探りな状態から始まったことが伝わってきます。その中で、「これはいける」と感じた瞬間はあったのでしょうか?
沢井:
正直なところ、最初は実現できるのか半信半疑でした。転機になったのは、メンバーの一人が「他社で似たような仕組みがある」という情報を持ってきてくれたことです。
そこからエンジニアと議論を重ねながら検証を進める中で、多くの企業では外部から内部への通信は厳しく制限されていても、内部から外部への通信は許可されているケースが少なくないことが見えてきました。この前提に、エージェント構成が非常にうまく適合したんです。
さらに、開発コストも比較的抑えられる見込みが立ったことで、「これなら実際に形にできるかもしれない」という確信へと徐々に変わっていきました。
浜田:
PMとエンジニアが日常的に壁打ちしながら仮説を磨いていく。そうしたオープンなコミュニケーション文化が、今回のプロジェクトを前に進める原動力になったと感じています。
開発のトレンドを追う側から、生み出す側へ。AI時代の“新たな標準”をつくる挑戦
—ここまでお話をお伺いしていて、現在はTeam+事業全体としても、各プロダクトとしても、大きな変化のタイミングにあるのだと感じました。エンジニアとPM、それぞれの立場から、Team+の開発に関わる面白さについて教えてください。
浜田:
現在は、AIの影響によって開発プロセスそのものが大きく変わりつつありますが、標準的な方法論はまだ確立されていません。たとえばレビューのあり方一つを取っても、「そもそも何を測るべきか」という定義自体が、まだ白紙に近い状態なんです。
だからこそ、自分たちで試行錯誤を重ねながら仮説を立て、未来のスタンダードそのものをかたちにしていける可能性がある。その変化の最前線に深く関われることが、何より大きな醍醐味だと感じています。
沢井:
これまでは、Four Keys*など外部で定義された基準をもとにプロダクトを構築してきましたが、今後は自分たち自身が新たな基準を提示する側に回れるかもしれない。その転換点に立ち会いながら、新たな指標や考え方を抽出し、社会に提示していける可能性があるのは、とてもワクワクしますよね。
Four Keys*:Googleの「DORA」研究で提唱された、ソフトウェア開発組織のパフォーマンスを測る代表的な4指標(デプロイ頻度、変更のリードタイム、変更失敗率、サービス復旧時間)
ー トレンドを追うのではなく、自らトレンドを生み出す側に回れるというのは、とてもワクワクしますね!
浜田:
そうですね。今は、開発のあり方そのものが大きく変わる転換点だからこそ、大きなチャンスでもあると感じています。
沢井:
新規領域の「Context」や「Insights」でも、まさにそうした挑戦を続けています。
たとえば「組織の中に知識をどう蓄積し、循環する状態を作るか」といったテーマは、一歩間違えると概念的な議論だけで終わってしまうと思うんです。ただ、Team+にはこれまで蓄積してきた開発組織のデータや知見がありますし、それを具体的なプロダクトとして成立させられる環境があります。
お客さまと対話を重ねる中でも、確かな手応えを感じています。
抽象的な理想を、価値あるプロダクトとして社会実装していく。その難易度の高さにもがきながらも、そこにある可能性を信じて挑戦し続けられる。それが、ファンディでプロダクト開発に向き合う最大の魅力だと思います。
──ありがとうございました!
さいごに
ファインディではエンジニア含む全職種でカジュアル面談を実施しています!少しでも興味をもっていただいたら、下の「話を聞きに行きたい」よりお申し込みをお願いします。もちろんすぐの転職を検討していなくても構いません。
みなさんとお話できることを楽しみにしています!