開発状況をデータで可視化し、再現性ある育成文化を醸成。2チーム合同のプロジェクトで挑んだビズリーチの開発生産性への取り組みとは?
開発状況をデータで可視化し、再現性ある育成文化を醸成。2チーム合同のプロジェクトで挑んだビズリーチの開発生産性への取り組みとは?

目次
目次を読み込み中...
本記事のサマリ
導入前:解決したかった課題
異なるスキルセットを持つ2チーム合同のプロジェクトにより、開発属人化とレビュー偏重が課題に。
Findy Team+を導入した理由
チームの状態を可視化し、課題特定と育成サイクルの構築を目的に導入。
導入の決め手
Four Keysをはじめとした指標をもとに、現場の課題を明確に可視化できる点。
導入後:成果
属人化を解消し、育成の再現性を高める。レビューの偏りも改善し、チームの一体感を向上。
プロジェクト
旧プロダクトからの機能移行に伴う、6人規模での約7ヶ月間の合同プロジェクト。
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」や社内スカウトで人材流出を防ぐ「社内版ビズリーチ by HRMOS」、人財活用プラットフォーム「HRMOS(ハーモス)」シリーズなど、HR Tech 領域を中心に様々なインターネットサービスを運営する株式会社ビズリーチ。その事業を支えるビズリーチのプロダクト組織では、2つのチームが合同でプロジェクトを始動しました。
異なるドメインやスキルセットを持つメンバーが一つのプロジェクトに携わる中で、属人化の解消、レビュー体制の再構築、育成の仕組みづくりという課題にどう向き合ったのか。
Findy Team+を活用しながら、開発生産性の可視化と自律的な改善文化を根付かせたビズリーチの取り組みについて、鈴木さん、栗原さんにお話を伺いました。
プロフィール
鈴木 智順さん
東京大学大学院修了。2021年株式会社ビズリーチ新卒入社。「HRMOS」の開発を経て、現在は「ビズリーチ」のサービス運用を支える基盤業務システムであるCRS ASSISTの開発を牽引する立場として、大規模リプレースプロジェクトの推進とチームビルディングを担当。
栗原 拓也さん
SES、事業会社でエンジニアとして開発に従事。2022年、株式会社ビズリーチに入社。2023年より エンジニアリングマネージャーとして、担当ドメイン領域のマイクロサービス化によるリアーキテクティングを推進。
チーム合同プロジェクトで直面した「見えざる壁」。スキルのばらつきとレビューの属人化にどう向き合ったか

──御社の事業と、お二人の役割を教えてください。
鈴木:当社では、転職サイト「ビズリーチ」や人財活用プラットフォーム「HRMOS(ハーモス)」シリーズなどを展開しています。
私はその中で、「ビズリーチ」の社内業務を支える基盤システム「CRS ASSIST」のテックリードを務めています。普段はCRS ASSISTチームとしてプロダクトの開発と運用を行っていますが、この度、旧システム(CRS Admin)から新システム(CRS ASSIST)へのリプレースを進めるため、業務基盤チームと合同でプロジェクトを立ち上げました。私は全体の進行管理とチーム間の連携推進を担っています。
栗原:私は業務基盤チームのエンジニアリングマネージャーとして、プロダクトの共通基盤や内部APIの開発を担当しています。今回のリプレースプロジェクトでは、私のチームが鈴木さんのCRS ASSISTチームに合流し、プロダクトのユースケースを踏まえた共通基盤のアップデートや内部APIのプロダクトとの接続などを中心として担当しました。もともと異なる開発文化・領域を持つチーム同士だったため、組織の融合とスムーズなコラボレーションづくりも意識して進めました。
──今回のプロジェクトが発足した時期と体制について教えてください。
鈴木:プロジェクトは 2025年1月に発足しました。旧プロダクトから新プロダクトへ段階的に機能を移行していく必要があり、その対応のために、既存の開発体制とは別にプロジェクト単位でチームを構成して取り組むことにしました。
プロジェクト期間はおよそ 7ヶ月間。途中でメンバーの入れ替わりはありましたが、平均6名規模 のチームで開発を進めていきました。
――Findy Team+を導入し、開発の可視化に取り組まれた背景にはどのような課題があったのでしょうか?
鈴木:一番の課題は、2チームが一つのプロジェクトを推進するにあたりメンバーのスキルやドメイン知識に大きな幅があったことです。
たとえば、私たちCRS ASSISTチームはフロントエンド/バックエンド双方に対応できるメンバーがいるものの、構成としてはバックエンドの比率がやや高いチームでした。対して業務基盤チームはAPIやインフラなどバックエンド領域に強みを持つメンバーが多い体制です。結果として、2チーム全体を合わせるとバックエンド寄りの構成になっていました。
このように背景の異なるメンバーが一つのゴールに向かうなかで、作業やレビューが特定領域に集中してしまい、属人化が進むリスクを強く感じていました。
特にフロントエンドのレビューを担当できる人が限られており、「その人が休んだらレビューが止まる」という状況は何としても避けたいと思っていました。こうした属人化を防ぎ、チームとして安定した開発体制を構築するには、まず現状を正しく可視化し、全員で課題を共通認識とすることが不可欠だと考えました。その手段として、Findy Team+の導入を決めました。
栗原:私たちのチームは後から合流したため、まずは開発フローやコードベースへのキャッチアップが必要でした。ある程度の期間、アウトプットのスピードが落ちることは想定していましたが、その状況をデータとして客観的に把握できたことで、「今はこのフェーズだから焦らなくて大丈夫」といった健全な共通認識がチームに生まれたのは非常に大きかったですね。
そこから、どう回復させていくかを建設的に議論できる土壌が整ったと感じています。

データが示す「チームの現在地」。ボトルネックの特定とフロー改善
――実際にFindy Team+でデータを見て、どのような気づきがありましたか?
鈴木:最初に感じたのは、想像以上にレビューが偏っているという驚きでした。感覚的にも偏りはあると認識していたものの、グラフで「レビュー担当者の100%がCRS ASSISTチームのメンバー」と明確に可視化されたときは、やはりインパクトが大きかったです。
このデータを見て、「どうすればこの偏りを減らしていけるか?」という問いが生まれ、レビュー体制をできるだけ50:50に近づけるという具体的な目標をチームで設定するきっかけになりました。
──課題が明らかになった後、チームではどのような改善に取り組まれたのでしょうか?
鈴木:まず注力したのは、プルリクエストが滞留せず、スムーズに流れる開発フローの実現です。Four Keysの指標も参考にしながら、さまざまなメトリクスをチェックしていましたが、特に意識したのは「レビュー依頼からレビュー開始までの時間」でした。
この時間は、実際の作業が止まっている“待ち時間”であり、最も改善インパクトの大きい領域だと考えたからです。たとえば、レビューが3日後に行われると、実装した本人も「これ何だっけ?」と思い出すところから始めなければならず、無駄なコンテキストスイッチが発生してしまいます。
そこで、プルリクエストが24時間以内にレビューされる状態を理想とし、チーム全体で平均時間をモニタリング。レビューの早期着手を促す取り組みを行いました。
データが後押しする、戦略的な個人育成プラン

――レビューの属人化という課題に対しては、どのようにアプローチされたのでしょうか?
鈴木:個人育成の観点では、大きく2つのアプローチを実践しました。
ひとつはペアレビューの導入です。まだ一人でレビューを完結するのが難しいメンバーには、経験豊富なメンバーとペアでレビューに参加してもらい、最終的な確認は別のメンバーが行う前提で進めました。
実践の中でレビューの観点や思考プロセスを学ぶ機会を設けることで、着実にスキルアップへとつなげています。
もうひとつは、戦略的なタスクアサインです。たとえば、あるメンバーに特定ドメインのレビューができるようになってほしい場合には、まずそのドメインの実装タスクを優先的に任せました。
実装を通してドメイン知識をキャッチアップし、次のイテレーションではその領域のレビューも担当できるようになる、といった育成サイクルを意図的に作っていきました。
――個人の育成を進める上で、コミュニケーション面で工夫されたことはありますか?
鈴木:特に意識したのは、育成やスキル移転をチーム全体の「合意事項」として進めたことです。
1on1でのフォローだけでなく、定例ミーティングでもFindy Team+のダッシュボードを全員で見ながら、「今のチームのボトルネックはレビューの偏りだよね」「だからAさんにこの領域のスキルを身につけてもらう必要があるんだ」といった会話をオープンに共有していました。
こうしたプロセスを通して、教える側には「チームのために自分の知識を共有する責任」が芽生えますし、教わる側にも「この学びはチームの生産性向上のための重要な投資なんだ」という納得感が生まれます。
育成や改善が“誰かのタスク”ではなく、チーム全体で共有する目標になっていたからこそ、焦ることなく、かつ実効性のあるスキル移転が進められたと感じています。
「頻繁なレビューの往復」の裏側を探る。データ起点の1on1
――栗原さんは、データを見ながらメンバーとコミュニケーションを取る際に意識されていたことはありますか?
栗原:私が意識していたのは、数値の良し悪しで判断するのではなく、その数値の裏側にある「事実(こと)」ベースで話すことです。例えば、あるメンバーのスプリントゴール達成が遅れていた際、データを見ると、特定のプルリクエストでレビューのやり取りが通常よりも多く発生していたことがありました。
ここで「レビューのやりとりがコードの変更内容に対して多すぎる」と指摘するのは簡単ですが、そうではなく、「なぜこんなにやり取りが多くなっているんだろう?」という問いを立てて本人と対話することを心がけました。すると、実は実装に着手する前の段階で、ゴールイメージや仕様に対する関係者との認識のズレがあったことが根本的な原因として見えてきました。これは、データという客観的な事実がなければただの推測で終わってしまっていたかもしれません。データを出発点として対話を深掘りすることで、本質的な課題解決に繋げることができました。
ビズリーチの成長を支える組織文化

──ビズリーチのプロダクト組織には、どのような特徴がありますか?
鈴木:ビズリーチのプロダクト組織で何より大切にしているのは、「お客様の本質的課題解決」です。エンジニアやデザイナーなど職種に関係なく、「課題解決にどう貢献できるか」「何が最適なアプローチか」といった視点を常に持っています。
その実現のために欠かせないのが仲間との協働であり、チームで知見や失敗を共有しながら学び合う文化が根付いています。特に私が強く実感しているのは、感覚に頼らず事実ベースで議論し、仕組みを通じて改善を積み重ねていく姿勢です。
今回の合同プロジェクトでも、データに基づいて個人の強みを組織の強みに変えることに成功しました。そして、失敗も含めてプロセスを振り返り、次に活かしていく文化があったからこそ、開発生産性の向上を着実に実現できたのだと思います。
成功体験を再現性のある型に AI活用と上流工程の可視化で、さらに価値ある開発へ
──今後の展望について教えてください。
鈴木:今回のプロジェクトを通じて、「データを起点にチーム改善を回していく」という成功体験を得ることができました。これは再現性のあるやり方なので、今後の別プロジェクトや新たな課題への対応にも展開していきたいと考えています。
直近では、AIの活用を、私自身も積極的に推進しています。特に今回のリプレースプロジェクトのような複雑性の高い案件では、開発の上流工程で大きな効果を実感しています。
例えば、アーキテクチャ設計の「壁打ち」相手として使うのはもちろん、特に効果的だったのが、AIを活用した大規模な既存コードの調査です。複数リポジトリやチームにまたがるコードを横断的に読み解き、「あるべき設計」を考えるといった作業です。
こうした複雑な作業は、従来非常に時間がかかっていましたが、AIを活用することで作業スピードが飛躍的に向上したことに加え、これまでは工数の観点から難しかった、より広範囲な情報の調査や深い分析が可能になりました。その分析結果を設計の「材料」とすることで、最終的なアウトプット(設計)の質そのものを、さらに高いレベルへ引き上げられるようになったと感じています。
こうした活用を個人のTipsで終わらせず、Findy Team+で可視化しながら組織ナレッジとして展開していくことで、チーム全体の成果を底上げしていきたいですね。
栗原:私のチームも、新たなメンバーを迎えて次のプロジェクトが始まっています。今回の経験で得た「型」を活かし、スムーズなプロジェクトの立ち上げを実現したいと考えています。
これまではプルリクエストを中心に開発工程を可視化していましたが、今後は設計などのより上流工程にも踏み込んで可視化・改善に取り組んでいきたいです。手戻りを減らし、より本質的な価値提供に集中できる開発体制を築いていきたいですね。
──今後、一緒に働きたいエンジニア像について教えてください。
鈴木:ビズリーチのプロダクト組織の文化に共感し、共に挑戦してくださる方と働けたら嬉しいです。技術力そのものだけでなく、それをどう事業価値に結びつけていくかを常に考えられる方や、仲間との協働を大切にできる方を歓迎します。
特に、前例のない課題に価値を見出し、自らの前提を疑いながら柔軟にアプローチできる方。さらに、ガバナンスと新機能開発のバランスを取りながら、AIなどの技術を駆使してプロダクトにインパクトを与えたいという意志を持った方と、一緒にプロダクトを磨いていきたいと考えています。

※株式会社ビズリーチでは、エンジニアを募集しています。
https://findy-code.io/companies/114
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
本記事のサマリ
導入前:解決したかった課題
異なるスキルセットを持つ2チーム合同のプロジェクトにより、開発属人化とレビュー偏重が課題に。
Findy Team+を導入した理由
チームの状態を可視化し、課題特定と育成サイクルの構築を目的に導入。
導入の決め手
Four Keysをはじめとした指標をもとに、現場の課題を明確に可視化できる点。
導入後:成果
属人化を解消し、育成の再現性を高める。レビューの偏りも改善し、チームの一体感を向上。
プロジェクト
旧プロダクトからの機能移行に伴う、6人規模での約7ヶ月間の合同プロジェクト。
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」や社内スカウトで人材流出を防ぐ「社内版ビズリーチ by HRMOS」、人財活用プラットフォーム「HRMOS(ハーモス)」シリーズなど、HR Tech 領域を中心に様々なインターネットサービスを運営する株式会社ビズリーチ。その事業を支えるビズリーチのプロダクト組織では、2つのチームが合同でプロジェクトを始動しました。
異なるドメインやスキルセットを持つメンバーが一つのプロジェクトに携わる中で、属人化の解消、レビュー体制の再構築、育成の仕組みづくりという課題にどう向き合ったのか。
Findy Team+を活用しながら、開発生産性の可視化と自律的な改善文化を根付かせたビズリーチの取り組みについて、鈴木さん、栗原さんにお話を伺いました。
プロフィール
鈴木 智順さん
東京大学大学院修了。2021年株式会社ビズリーチ新卒入社。「HRMOS」の開発を経て、現在は「ビズリーチ」のサービス運用を支える基盤業務システムであるCRS ASSISTの開発を牽引する立場として、大規模リプレースプロジェクトの推進とチームビルディングを担当。
栗原 拓也さん
SES、事業会社でエンジニアとして開発に従事。2022年、株式会社ビズリーチに入社。2023年より エンジニアリングマネージャーとして、担当ドメイン領域のマイクロサービス化によるリアーキテクティングを推進。
チーム合同プロジェクトで直面した「見えざる壁」。スキルのばらつきとレビューの属人化にどう向き合ったか

──御社の事業と、お二人の役割を教えてください。
鈴木:当社では、転職サイト「ビズリーチ」や人財活用プラットフォーム「HRMOS(ハーモス)」シリーズなどを展開しています。
私はその中で、「ビズリーチ」の社内業務を支える基盤システム「CRS ASSIST」のテックリードを務めています。普段はCRS ASSISTチームとしてプロダクトの開発と運用を行っていますが、この度、旧システム(CRS Admin)から新システム(CRS ASSIST)へのリプレースを進めるため、業務基盤チームと合同でプロジェクトを立ち上げました。私は全体の進行管理とチーム間の連携推進を担っています。
栗原:私は業務基盤チームのエンジニアリングマネージャーとして、プロダクトの共通基盤や内部APIの開発を担当しています。今回のリプレースプロジェクトでは、私のチームが鈴木さんのCRS ASSISTチームに合流し、プロダクトのユースケースを踏まえた共通基盤のアップデートや内部APIのプロダクトとの接続などを中心として担当しました。もともと異なる開発文化・領域を持つチーム同士だったため、組織の融合とスムーズなコラボレーションづくりも意識して進めました。
──今回のプロジェクトが発足した時期と体制について教えてください。
鈴木:プロジェクトは 2025年1月に発足しました。旧プロダクトから新プロダクトへ段階的に機能を移行していく必要があり、その対応のために、既存の開発体制とは別にプロジェクト単位でチームを構成して取り組むことにしました。
プロジェクト期間はおよそ 7ヶ月間。途中でメンバーの入れ替わりはありましたが、平均6名規模 のチームで開発を進めていきました。
――Findy Team+を導入し、開発の可視化に取り組まれた背景にはどのような課題があったのでしょうか?
鈴木:一番の課題は、2チームが一つのプロジェクトを推進するにあたりメンバーのスキルやドメイン知識に大きな幅があったことです。
たとえば、私たちCRS ASSISTチームはフロントエンド/バックエンド双方に対応できるメンバーがいるものの、構成としてはバックエンドの比率がやや高いチームでした。対して業務基盤チームはAPIやインフラなどバックエンド領域に強みを持つメンバーが多い体制です。結果として、2チーム全体を合わせるとバックエンド寄りの構成になっていました。
このように背景の異なるメンバーが一つのゴールに向かうなかで、作業やレビューが特定領域に集中してしまい、属人化が進むリスクを強く感じていました。
特にフロントエンドのレビューを担当できる人が限られており、「その人が休んだらレビューが止まる」という状況は何としても避けたいと思っていました。こうした属人化を防ぎ、チームとして安定した開発体制を構築するには、まず現状を正しく可視化し、全員で課題を共通認識とすることが不可欠だと考えました。その手段として、Findy Team+の導入を決めました。
栗原:私たちのチームは後から合流したため、まずは開発フローやコードベースへのキャッチアップが必要でした。ある程度の期間、アウトプットのスピードが落ちることは想定していましたが、その状況をデータとして客観的に把握できたことで、「今はこのフェーズだから焦らなくて大丈夫」といった健全な共通認識がチームに生まれたのは非常に大きかったですね。
そこから、どう回復させていくかを建設的に議論できる土壌が整ったと感じています。

データが示す「チームの現在地」。ボトルネックの特定とフロー改善
――実際にFindy Team+でデータを見て、どのような気づきがありましたか?
鈴木:最初に感じたのは、想像以上にレビューが偏っているという驚きでした。感覚的にも偏りはあると認識していたものの、グラフで「レビュー担当者の100%がCRS ASSISTチームのメンバー」と明確に可視化されたときは、やはりインパクトが大きかったです。
このデータを見て、「どうすればこの偏りを減らしていけるか?」という問いが生まれ、レビュー体制をできるだけ50:50に近づけるという具体的な目標をチームで設定するきっかけになりました。
──課題が明らかになった後、チームではどのような改善に取り組まれたのでしょうか?
鈴木:まず注力したのは、プルリクエストが滞留せず、スムーズに流れる開発フローの実現です。Four Keysの指標も参考にしながら、さまざまなメトリクスをチェックしていましたが、特に意識したのは「レビュー依頼からレビュー開始までの時間」でした。
この時間は、実際の作業が止まっている“待ち時間”であり、最も改善インパクトの大きい領域だと考えたからです。たとえば、レビューが3日後に行われると、実装した本人も「これ何だっけ?」と思い出すところから始めなければならず、無駄なコンテキストスイッチが発生してしまいます。
そこで、プルリクエストが24時間以内にレビューされる状態を理想とし、チーム全体で平均時間をモニタリング。レビューの早期着手を促す取り組みを行いました。
データが後押しする、戦略的な個人育成プラン

――レビューの属人化という課題に対しては、どのようにアプローチされたのでしょうか?
鈴木:個人育成の観点では、大きく2つのアプローチを実践しました。
ひとつはペアレビューの導入です。まだ一人でレビューを完結するのが難しいメンバーには、経験豊富なメンバーとペアでレビューに参加してもらい、最終的な確認は別のメンバーが行う前提で進めました。
実践の中でレビューの観点や思考プロセスを学ぶ機会を設けることで、着実にスキルアップへとつなげています。
もうひとつは、戦略的なタスクアサインです。たとえば、あるメンバーに特定ドメインのレビューができるようになってほしい場合には、まずそのドメインの実装タスクを優先的に任せました。
実装を通してドメイン知識をキャッチアップし、次のイテレーションではその領域のレビューも担当できるようになる、といった育成サイクルを意図的に作っていきました。
――個人の育成を進める上で、コミュニケーション面で工夫されたことはありますか?
鈴木:特に意識したのは、育成やスキル移転をチーム全体の「合意事項」として進めたことです。
1on1でのフォローだけでなく、定例ミーティングでもFindy Team+のダッシュボードを全員で見ながら、「今のチームのボトルネックはレビューの偏りだよね」「だからAさんにこの領域のスキルを身につけてもらう必要があるんだ」といった会話をオープンに共有していました。
こうしたプロセスを通して、教える側には「チームのために自分の知識を共有する責任」が芽生えますし、教わる側にも「この学びはチームの生産性向上のための重要な投資なんだ」という納得感が生まれます。
育成や改善が“誰かのタスク”ではなく、チーム全体で共有する目標になっていたからこそ、焦ることなく、かつ実効性のあるスキル移転が進められたと感じています。
「頻繁なレビューの往復」の裏側を探る。データ起点の1on1
――栗原さんは、データを見ながらメンバーとコミュニケーションを取る際に意識されていたことはありますか?
栗原:私が意識していたのは、数値の良し悪しで判断するのではなく、その数値の裏側にある「事実(こと)」ベースで話すことです。例えば、あるメンバーのスプリントゴール達成が遅れていた際、データを見ると、特定のプルリクエストでレビューのやり取りが通常よりも多く発生していたことがありました。
ここで「レビューのやりとりがコードの変更内容に対して多すぎる」と指摘するのは簡単ですが、そうではなく、「なぜこんなにやり取りが多くなっているんだろう?」という問いを立てて本人と対話することを心がけました。すると、実は実装に着手する前の段階で、ゴールイメージや仕様に対する関係者との認識のズレがあったことが根本的な原因として見えてきました。これは、データという客観的な事実がなければただの推測で終わってしまっていたかもしれません。データを出発点として対話を深掘りすることで、本質的な課題解決に繋げることができました。
ビズリーチの成長を支える組織文化

──ビズリーチのプロダクト組織には、どのような特徴がありますか?
鈴木:ビズリーチのプロダクト組織で何より大切にしているのは、「お客様の本質的課題解決」です。エンジニアやデザイナーなど職種に関係なく、「課題解決にどう貢献できるか」「何が最適なアプローチか」といった視点を常に持っています。
その実現のために欠かせないのが仲間との協働であり、チームで知見や失敗を共有しながら学び合う文化が根付いています。特に私が強く実感しているのは、感覚に頼らず事実ベースで議論し、仕組みを通じて改善を積み重ねていく姿勢です。
今回の合同プロジェクトでも、データに基づいて個人の強みを組織の強みに変えることに成功しました。そして、失敗も含めてプロセスを振り返り、次に活かしていく文化があったからこそ、開発生産性の向上を着実に実現できたのだと思います。
成功体験を再現性のある型に AI活用と上流工程の可視化で、さらに価値ある開発へ
──今後の展望について教えてください。
鈴木:今回のプロジェクトを通じて、「データを起点にチーム改善を回していく」という成功体験を得ることができました。これは再現性のあるやり方なので、今後の別プロジェクトや新たな課題への対応にも展開していきたいと考えています。
直近では、AIの活用を、私自身も積極的に推進しています。特に今回のリプレースプロジェクトのような複雑性の高い案件では、開発の上流工程で大きな効果を実感しています。
例えば、アーキテクチャ設計の「壁打ち」相手として使うのはもちろん、特に効果的だったのが、AIを活用した大規模な既存コードの調査です。複数リポジトリやチームにまたがるコードを横断的に読み解き、「あるべき設計」を考えるといった作業です。
こうした複雑な作業は、従来非常に時間がかかっていましたが、AIを活用することで作業スピードが飛躍的に向上したことに加え、これまでは工数の観点から難しかった、より広範囲な情報の調査や深い分析が可能になりました。その分析結果を設計の「材料」とすることで、最終的なアウトプット(設計)の質そのものを、さらに高いレベルへ引き上げられるようになったと感じています。
こうした活用を個人のTipsで終わらせず、Findy Team+で可視化しながら組織ナレッジとして展開していくことで、チーム全体の成果を底上げしていきたいですね。
栗原:私のチームも、新たなメンバーを迎えて次のプロジェクトが始まっています。今回の経験で得た「型」を活かし、スムーズなプロジェクトの立ち上げを実現したいと考えています。
これまではプルリクエストを中心に開発工程を可視化していましたが、今後は設計などのより上流工程にも踏み込んで可視化・改善に取り組んでいきたいです。手戻りを減らし、より本質的な価値提供に集中できる開発体制を築いていきたいですね。
──今後、一緒に働きたいエンジニア像について教えてください。
鈴木:ビズリーチのプロダクト組織の文化に共感し、共に挑戦してくださる方と働けたら嬉しいです。技術力そのものだけでなく、それをどう事業価値に結びつけていくかを常に考えられる方や、仲間との協働を大切にできる方を歓迎します。
特に、前例のない課題に価値を見出し、自らの前提を疑いながら柔軟にアプローチできる方。さらに、ガバナンスと新機能開発のバランスを取りながら、AIなどの技術を駆使してプロダクトにインパクトを与えたいという意志を持った方と、一緒にプロダクトを磨いていきたいと考えています。

※株式会社ビズリーチでは、エンジニアを募集しています。
https://findy-code.io/companies/114
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
開発状況をデータで可視化し、再現性ある育成文化を醸成。2チーム合同のプロジェクトで挑んだビズリーチの開発生産性への取り組みとは?

本記事のサマリ
導入前:解決したかった課題
異なるスキルセットを持つ2チーム合同のプロジェクトにより、開発属人化とレビュー偏重が課題に。
Findy Team+を導入した理由
チームの状態を可視化し、課題特定と育成サイクルの構築を目的に導入。
導入の決め手
Four Keysをはじめとした指標をもとに、現場の課題を明確に可視化できる点。
導入後:成果
属人化を解消し、育成の再現性を高める。レビューの偏りも改善し、チームの一体感を向上。
プロジェクト
旧プロダクトからの機能移行に伴う、6人規模での約7ヶ月間の合同プロジェクト。
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」や社内スカウトで人材流出を防ぐ「社内版ビズリーチ by HRMOS」、人財活用プラットフォーム「HRMOS(ハーモス)」シリーズなど、HR Tech 領域を中心に様々なインターネットサービスを運営する株式会社ビズリーチ。その事業を支えるビズリーチのプロダクト組織では、2つのチームが合同でプロジェクトを始動しました。
異なるドメインやスキルセットを持つメンバーが一つのプロジェクトに携わる中で、属人化の解消、レビュー体制の再構築、育成の仕組みづくりという課題にどう向き合ったのか。
Findy Team+を活用しながら、開発生産性の可視化と自律的な改善文化を根付かせたビズリーチの取り組みについて、鈴木さん、栗原さんにお話を伺いました。
プロフィール
鈴木 智順さん
東京大学大学院修了。2021年株式会社ビズリーチ新卒入社。「HRMOS」の開発を経て、現在は「ビズリーチ」のサービス運用を支える基盤業務システムであるCRS ASSISTの開発を牽引する立場として、大規模リプレースプロジェクトの推進とチームビルディングを担当。
栗原 拓也さん
SES、事業会社でエンジニアとして開発に従事。2022年、株式会社ビズリーチに入社。2023年より エンジニアリングマネージャーとして、担当ドメイン領域のマイクロサービス化によるリアーキテクティングを推進。
チーム合同プロジェクトで直面した「見えざる壁」。スキルのばらつきとレビューの属人化にどう向き合ったか

──御社の事業と、お二人の役割を教えてください。
鈴木:当社では、転職サイト「ビズリーチ」や人財活用プラットフォーム「HRMOS(ハーモス)」シリーズなどを展開しています。
私はその中で、「ビズリーチ」の社内業務を支える基盤システム「CRS ASSIST」のテックリードを務めています。普段はCRS ASSISTチームとしてプロダクトの開発と運用を行っていますが、この度、旧システム(CRS Admin)から新システム(CRS ASSIST)へのリプレースを進めるため、業務基盤チームと合同でプロジェクトを立ち上げました。私は全体の進行管理とチーム間の連携推進を担っています。
栗原:私は業務基盤チームのエンジニアリングマネージャーとして、プロダクトの共通基盤や内部APIの開発を担当しています。今回のリプレースプロジェクトでは、私のチームが鈴木さんのCRS ASSISTチームに合流し、プロダクトのユースケースを踏まえた共通基盤のアップデートや内部APIのプロダクトとの接続などを中心として担当しました。もともと異なる開発文化・領域を持つチーム同士だったため、組織の融合とスムーズなコラボレーションづくりも意識して進めました。
──今回のプロジェクトが発足した時期と体制について教えてください。
鈴木:プロジェクトは 2025年1月に発足しました。旧プロダクトから新プロダクトへ段階的に機能を移行していく必要があり、その対応のために、既存の開発体制とは別にプロジェクト単位でチームを構成して取り組むことにしました。
プロジェクト期間はおよそ 7ヶ月間。途中でメンバーの入れ替わりはありましたが、平均6名規模 のチームで開発を進めていきました。
――Findy Team+を導入し、開発の可視化に取り組まれた背景にはどのような課題があったのでしょうか?
鈴木:一番の課題は、2チームが一つのプロジェクトを推進するにあたりメンバーのスキルやドメイン知識に大きな幅があったことです。
たとえば、私たちCRS ASSISTチームはフロントエンド/バックエンド双方に対応できるメンバーがいるものの、構成としてはバックエンドの比率がやや高いチームでした。対して業務基盤チームはAPIやインフラなどバックエンド領域に強みを持つメンバーが多い体制です。結果として、2チーム全体を合わせるとバックエンド寄りの構成になっていました。
このように背景の異なるメンバーが一つのゴールに向かうなかで、作業やレビューが特定領域に集中してしまい、属人化が進むリスクを強く感じていました。
特にフロントエンドのレビューを担当できる人が限られており、「その人が休んだらレビューが止まる」という状況は何としても避けたいと思っていました。こうした属人化を防ぎ、チームとして安定した開発体制を構築するには、まず現状を正しく可視化し、全員で課題を共通認識とすることが不可欠だと考えました。その手段として、Findy Team+の導入を決めました。
栗原:私たちのチームは後から合流したため、まずは開発フローやコードベースへのキャッチアップが必要でした。ある程度の期間、アウトプットのスピードが落ちることは想定していましたが、その状況をデータとして客観的に把握できたことで、「今はこのフェーズだから焦らなくて大丈夫」といった健全な共通認識がチームに生まれたのは非常に大きかったですね。
そこから、どう回復させていくかを建設的に議論できる土壌が整ったと感じています。

データが示す「チームの現在地」。ボトルネックの特定とフロー改善
――実際にFindy Team+でデータを見て、どのような気づきがありましたか?
鈴木:最初に感じたのは、想像以上にレビューが偏っているという驚きでした。感覚的にも偏りはあると認識していたものの、グラフで「レビュー担当者の100%がCRS ASSISTチームのメンバー」と明確に可視化されたときは、やはりインパクトが大きかったです。
このデータを見て、「どうすればこの偏りを減らしていけるか?」という問いが生まれ、レビュー体制をできるだけ50:50に近づけるという具体的な目標をチームで設定するきっかけになりました。
──課題が明らかになった後、チームではどのような改善に取り組まれたのでしょうか?
鈴木:まず注力したのは、プルリクエストが滞留せず、スムーズに流れる開発フローの実現です。Four Keysの指標も参考にしながら、さまざまなメトリクスをチェックしていましたが、特に意識したのは「レビュー依頼からレビュー開始までの時間」でした。
この時間は、実際の作業が止まっている“待ち時間”であり、最も改善インパクトの大きい領域だと考えたからです。たとえば、レビューが3日後に行われると、実装した本人も「これ何だっけ?」と思い出すところから始めなければならず、無駄なコンテキストスイッチが発生してしまいます。
そこで、プルリクエストが24時間以内にレビューされる状態を理想とし、チーム全体で平均時間をモニタリング。レビューの早期着手を促す取り組みを行いました。
データが後押しする、戦略的な個人育成プラン

――レビューの属人化という課題に対しては、どのようにアプローチされたのでしょうか?
鈴木:個人育成の観点では、大きく2つのアプローチを実践しました。
ひとつはペアレビューの導入です。まだ一人でレビューを完結するのが難しいメンバーには、経験豊富なメンバーとペアでレビューに参加してもらい、最終的な確認は別のメンバーが行う前提で進めました。
実践の中でレビューの観点や思考プロセスを学ぶ機会を設けることで、着実にスキルアップへとつなげています。
もうひとつは、戦略的なタスクアサインです。たとえば、あるメンバーに特定ドメインのレビューができるようになってほしい場合には、まずそのドメインの実装タスクを優先的に任せました。
実装を通してドメイン知識をキャッチアップし、次のイテレーションではその領域のレビューも担当できるようになる、といった育成サイクルを意図的に作っていきました。
――個人の育成を進める上で、コミュニケーション面で工夫されたことはありますか?
鈴木:特に意識したのは、育成やスキル移転をチーム全体の「合意事項」として進めたことです。
1on1でのフォローだけでなく、定例ミーティングでもFindy Team+のダッシュボードを全員で見ながら、「今のチームのボトルネックはレビューの偏りだよね」「だからAさんにこの領域のスキルを身につけてもらう必要があるんだ」といった会話をオープンに共有していました。
こうしたプロセスを通して、教える側には「チームのために自分の知識を共有する責任」が芽生えますし、教わる側にも「この学びはチームの生産性向上のための重要な投資なんだ」という納得感が生まれます。
育成や改善が“誰かのタスク”ではなく、チーム全体で共有する目標になっていたからこそ、焦ることなく、かつ実効性のあるスキル移転が進められたと感じています。
「頻繁なレビューの往復」の裏側を探る。データ起点の1on1
――栗原さんは、データを見ながらメンバーとコミュニケーションを取る際に意識されていたことはありますか?
栗原:私が意識していたのは、数値の良し悪しで判断するのではなく、その数値の裏側にある「事実(こと)」ベースで話すことです。例えば、あるメンバーのスプリントゴール達成が遅れていた際、データを見ると、特定のプルリクエストでレビューのやり取りが通常よりも多く発生していたことがありました。
ここで「レビューのやりとりがコードの変更内容に対して多すぎる」と指摘するのは簡単ですが、そうではなく、「なぜこんなにやり取りが多くなっているんだろう?」という問いを立てて本人と対話することを心がけました。すると、実は実装に着手する前の段階で、ゴールイメージや仕様に対する関係者との認識のズレがあったことが根本的な原因として見えてきました。これは、データという客観的な事実がなければただの推測で終わってしまっていたかもしれません。データを出発点として対話を深掘りすることで、本質的な課題解決に繋げることができました。
ビズリーチの成長を支える組織文化

──ビズリーチのプロダクト組織には、どのような特徴がありますか?
鈴木:ビズリーチのプロダクト組織で何より大切にしているのは、「お客様の本質的課題解決」です。エンジニアやデザイナーなど職種に関係なく、「課題解決にどう貢献できるか」「何が最適なアプローチか」といった視点を常に持っています。
その実現のために欠かせないのが仲間との協働であり、チームで知見や失敗を共有しながら学び合う文化が根付いています。特に私が強く実感しているのは、感覚に頼らず事実ベースで議論し、仕組みを通じて改善を積み重ねていく姿勢です。
今回の合同プロジェクトでも、データに基づいて個人の強みを組織の強みに変えることに成功しました。そして、失敗も含めてプロセスを振り返り、次に活かしていく文化があったからこそ、開発生産性の向上を着実に実現できたのだと思います。
成功体験を再現性のある型に AI活用と上流工程の可視化で、さらに価値ある開発へ
──今後の展望について教えてください。
鈴木:今回のプロジェクトを通じて、「データを起点にチーム改善を回していく」という成功体験を得ることができました。これは再現性のあるやり方なので、今後の別プロジェクトや新たな課題への対応にも展開していきたいと考えています。
直近では、AIの活用を、私自身も積極的に推進しています。特に今回のリプレースプロジェクトのような複雑性の高い案件では、開発の上流工程で大きな効果を実感しています。
例えば、アーキテクチャ設計の「壁打ち」相手として使うのはもちろん、特に効果的だったのが、AIを活用した大規模な既存コードの調査です。複数リポジトリやチームにまたがるコードを横断的に読み解き、「あるべき設計」を考えるといった作業です。
こうした複雑な作業は、従来非常に時間がかかっていましたが、AIを活用することで作業スピードが飛躍的に向上したことに加え、これまでは工数の観点から難しかった、より広範囲な情報の調査や深い分析が可能になりました。その分析結果を設計の「材料」とすることで、最終的なアウトプット(設計)の質そのものを、さらに高いレベルへ引き上げられるようになったと感じています。
こうした活用を個人のTipsで終わらせず、Findy Team+で可視化しながら組織ナレッジとして展開していくことで、チーム全体の成果を底上げしていきたいですね。
栗原:私のチームも、新たなメンバーを迎えて次のプロジェクトが始まっています。今回の経験で得た「型」を活かし、スムーズなプロジェクトの立ち上げを実現したいと考えています。
これまではプルリクエストを中心に開発工程を可視化していましたが、今後は設計などのより上流工程にも踏み込んで可視化・改善に取り組んでいきたいです。手戻りを減らし、より本質的な価値提供に集中できる開発体制を築いていきたいですね。
──今後、一緒に働きたいエンジニア像について教えてください。
鈴木:ビズリーチのプロダクト組織の文化に共感し、共に挑戦してくださる方と働けたら嬉しいです。技術力そのものだけでなく、それをどう事業価値に結びつけていくかを常に考えられる方や、仲間との協働を大切にできる方を歓迎します。
特に、前例のない課題に価値を見出し、自らの前提を疑いながら柔軟にアプローチできる方。さらに、ガバナンスと新機能開発のバランスを取りながら、AIなどの技術を駆使してプロダクトにインパクトを与えたいという意志を持った方と、一緒にプロダクトを磨いていきたいと考えています。

※株式会社ビズリーチでは、エンジニアを募集しています。
https://findy-code.io/companies/114
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます。






