技術的負債と戦うビズリーチの挑戦 〜リアーキテクティングの背景〜

株式会社ビズリーチの西山と申します。本日は、リアーキテクティングを推進するためのプラットフォーム構築と、組織戦略の考え方についてお話しします。

自己紹介をさせてください。私は2011年からVisionalグループの株式会社ビズリーチに在籍しています。2020年より株式会社スタンバイやトラボックス株式会社といったグループ会社での仕事を経て、2023年に株式会社ビズリーチに戻ってきました。現在は、ビズリーチプロダクトの検索基盤（企業様が使用する検索機能）の開発に携わりながら、アーキテクトも担っています。

「ビズリーチ」についても、改めてご紹介いたします。「ビズリーチ」は即戦力人材と企業をつなぐ転職サイトであり、求職者様、企業様、ヘッドハンター様というそれぞれ異なる立場にある三者が介在する採用プラットフォームです。将来的には、選択肢と可能性を最大化する「キャリアインフラ」を実現するべく、「社内版ビズリーチ by HRMOS」、「HRMOS（ハーモス）」シリーズなどとも連携しています。創業以来、サービス規模は右肩上がりで、プロダクトも開発組織も拡大を続けています。

なお、「ビズリーチ」がこれまでに行ってきたリアーキテクティングについては「JJUG CCC 2022 Fall」にて「ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う」と題して、技術的負債との向き合い方をご紹介しています。ここでは、2012年頃に刷新したシステムが10年以上経って負債化していたため、事業成長を止めずにいかにレガシーコードと向き合うか、についてご紹介しました。

実際のリアーキテクティングの技術的な進め方の実例については「JJUG CCC 2025 Spring」にて「ビズリーチにおけるリアーキテクティング実践事例」と題して発表しております。

境界づけられたコンテキストによるAPI分割戦略

リアーキテクティング前のプロダクト構造として、バックエンドはJavaで構成され、共有データベース（以下、DB）を見ると複数のモジュールが密に繋がっている巨大なモノリスになっていました。

現在は、これを境界づけられたコンテキスト（Bounded Context）ごとに分けてAPI分割し、マイクロサービス化を進めようとしています。

APIを切り出したあとは、最終的にコンテキストごとにDBを分けて管理できるように進めていく予定ですが、今はAPIを分離しながらコードをキレイにすることを優先的に進めている段階です。

検索基盤とQAチームにおけるチームトポロジー実践事例

まずは「リアーキテクティングにおける組織構造の変遷」として、チームトポロジーの考え方を用いた事例をご紹介します。

事例1：検索基盤刷新におけるチームインタラクションの変遷

私が所属する検索基盤グループは、企業様が求職者様を検索する部分をAPIとして抽出し、検索の品質改善を行うチームです。ここからは、このチームをどのように切り出し、いかにしてマッチング機会の精度を向上するという事業インパクトを創出できたのかについてお話しします。

初期段階では検索システムとしてElasticsearchを導入し、プロダクトが直接参照する形でした。Indexerの処理を含めて、これらのシステムやデータストアをコンプリケイテッドサブシステム（複雑なサブシステム）として、専門性の高い領域を検索基盤グループが運用する形をとりました。

その後、APIとして切り出して疎結合にする際に「検索のユースケース」や「API化するべきプロダクト」に関する知識が必要になるため、プロダクト開発グループと一緒に進める形をとりました。インタラクションとしては、データストアとして切り出した当初はX-as-a-Serviceのような形で疎結合でしたが、開発中はコラボレーションという形に変化させました。

APIを刷新して移行作業が終わった後は、APIを使うX-as-a-Serviceに戻り、検索ドメイン機能を提供するシステムになりました。

その後、検索基盤グループ自体もKPIを持って品質改善としての目標を持ち、事業成長に直接貢献する組織構成になったため、検索基盤グループ自体がストリームアラインドチームとして機能する形に変化しました。

一方で、プロダクト開発グループから見た検索基盤グループは、プラットフォームチームといった属性も併せ持ちます。

事例2：QAスキルの平準化

次に、QAスキルを平準化させていく取り組み事例もご紹介します。

以前は開発をしてからQAチームが全体のテストをして、その後リリースエンジニアがリリースするという流れをとっていました。この体制では、QAチームが仕様や要件を見るために密に結合してテストケースを作る必要がある上に、開発が終わった後にテスト実行という形になるため、リリースまでのリードタイムが長期化していました。

そこで、QAチームをそのまま動かすのではなく、イネーブリングチームとしてQAスキルを開発チーム自体にトランスファーし、テスト観点なども含めてファシリテーションしていく活動を行いました。

結果的に開発チーム自体がQAも行えるようになったため、リードタイムは短くなりました。プラスアルファとして、システム横断グループ（旧プロセスエンジニアリンググループ）が登場し、E2Eテストでプロダクト全体のQAをチェックする体制をとっています。こちらは社内向けプロダクトのような形で、バリューストリームに沿ってコアなビジネス部分をチェックするE2Eシナリオを作り、開発チームの補助輪として機能させています。

リアーキテクティングの次なる課題

リアーキテクティングを進めてチームやプロダクトが増えてくると、技術的負債以外の課題が発生してきました。

冒頭でもお話しした通り、「ビズリーチ」には、求職者様、企業様、ヘッドハンター様というそれぞれ異なる立場にある三者のお客様がいらっしゃいます。お客様同士が直接やり取りをするわけではなく、三者間でよりよいマッチング機会を創出するための採用プラットフォームが真ん中にあるという形です。

転職活動をしたことがある方は経験があるかと思いますが、自社に転職活動をしていることは知られたくないですよね。では、そういった機能をどのプロダクトが担保するのか。過去の「ビズリーチ」では、企業様向けのプロダクトとヘッドハンター様向けのプロダクトが独自にブロック機能を作っていました。ブロックの実装漏れがあると事故が発生してしまいます。それを回避するため、出していい情報の精査やメッセージの制御は、採用プラットフォーム側で解決することにしました。

そのため、組織構造としてもプロダクト開発が上にあり、プラットフォームとしてはマッチングのAPI部分を提供しています。その他、全体のサービス品質を守るためのSREやデータベースの品質を守るためのDBREといったところも担っています。

データプロダクトは、データを利活用するための基盤づくりや、データを活用したグロースを担うチームが在籍している組織です。

このようにチームを増やしていく中で、チーム内で価値提供できるように、1チームにフロントエンドからインフラ、スクラムマスターまで在籍し、全体で一気通貫できるような体制を作っていきました。

インフラ管理についても、プロダクト開発とプラットフォームの領域を明確に分離しました。以前はSREグループが全体の統制を取っていたのですが、レビューや構築のプロセスで自由度が制限される側面がありました。現在は、それぞれの特性に合わせて管理責任を分けることで、スピードとガバナンスの両立を図っています。

GitHubのリポジトリについても、巨大なモノレポから、プロダクトコードごとの分割やAPI単位での集約など、チームの成長と分割に合わせて有機的に変化しています。

リポジトリを分けることで各チームの自由度は高まりましたが、プロダクトやAPIが増えたことによる依存関係の複雑化が現在の課題となっています。特に、プロダクトとプラットフォームの中間に位置する機能（マッチング機能など）をどちらに実装すべきかといった、境界線の引き方については、現在も議論を重ねながら進めています。

組織拡大が生んだ「品質・生産性・ガバナンス」の新たな壁

組織拡大が生んだ課題については、ざっくり分けると「品質」「生産性」「ガバナンス」の3つに分けられます。

「可観測性」と「信頼性」低下の課題

品質面ではよくある問題だと思いますが、マイクロサービス化するとトレースが難しくなります。プロダクトのバックエンドから採用のAPIを通し、採用のAPIもAIのAPIを使うなど、一気通貫でログやトレースを見続けられるように維持するのが難しい状態です。DatadogやAPIの設定を含め、運用し続けるのが困難です。

また、API呼び出しの階層が深くなり、共通機能での問題が全プロダクトに波及するカスケード障害の問題もありました。

DBの分割がまだ行われていないため、コネクション数の増加によるリソース競合も発生しやすくなっています。既存システムが企業側と求職者側のデータを紐づけるための高負荷なクエリが発行されていることに加え、純粋なリクエスト増加に伴う負荷も重なり、DB周りの障害が増えているのも課題です。

他にも、API呼び出しなどでデータをやり取りする際、通信障害で「処理は通ったがレスポンスだけ返ってこない」という時に、呼び出し側がエラーと判断して再試行することで重複登録のリスクが頻発していました。

このような信頼性低下の対応策としては、2次災害を防ぐサーキットブレーカーを入れたり、二重登録防止のためにRFCのドラフトにあるIdempotencyヘッダーを入れてアプリケーションで回避しています。データベース負荷については、分割予定ではありますが、Read-Replicaを用意して接続を向けるなどの対応をしています。

組織の拡大による生産性の課題

生産性については、組織が拡大したことによって、ボトルネックになる箇所が移ってきました。開発チームごとに設計方針やルールが混在していて、CI/CDやリンターの設定をどうするかといった問題が発生しています。1リポジトリで複数のモジュールを扱うと、CIやテスト時間が増加するという問題もあります。

開発環境では、APIの分割に伴いローカルでの依存関係が複雑化し、以前のモノリス構成に比べて動作確認が困難になっています。現在はモックを提供して効率化を図っていますが、それだけでは結合レベルでの本質的なテストには至らないという懸念があります

また、API同士を連携させるため、インターフェースを定義して互いに規約を守る「コントラクト」を意識した開発が必要になっています。 これには作業工数がかかりますし、本来はすぐに変更したい箇所であっても、互換性維持のために一旦Deprecated（非推奨）として残すなどの手間が発生しています。インターフェース駆動開発を取り入れてはいるものの、結果として変更の難易度が上がり、生産性が落ちてしまっているのが現状です。

障害が発生した際に原因を特定する難易度も上がっています。1つの問題に対して、様々なチームとコミュニケーションを取りながら影響範囲を探さなければいけないという状況も起きています。

対策として、ビジネス観点での一気通貫した監視を導入し、どこで起きた問題がどこまで波及するかを把握したり、エラー情報を適切に伝播させたりしています。また、API単位での監視強化や、対応手順をまとめたランブック（手順書）の用意、チームを跨いだ障害訓練なども実施しています。こうした取り組みで対応はしていますが、依然として分散システム特有の課題として発生し続けているのが現状です。

デリバリー面では、各チームがリポジトリごとに独自のCI/CDパイプラインを構築しており、使用ツールもバラバラです。開発の自由度を優先した結果のトレードオフではありますが、サイドカーコンテナの設定やイメージ管理のコストが各チームに個別に乗ってしまっています。依存先APIの増加によりテスト環境の競合も発生しています。

チーム間のコミュニケーション課題

最後はガバナンスの問題です。開発をどう進めていくかという点で、システムの依存関係が複雑すぎて「どのAPIがどこで使われているのか」が不透明になっています。必要なAPIは揃っているものの「どのチームがどのAPIを使い、どのドメインを扱っているのか」を把握する負担が大きく、オンボーディングや他チームとのコミュニケーションにおける認知負荷が高まっています。

特に新機能の開発時には「このAPIに繋ぐべきか、プロダクト側に実装すべきか」といった要件定義の段階で、チーム間の調整コストが一定発生してしまいます。これは既存システムとの整合性も含めた過渡期ゆえの問題でもありますが、まだドメインごとにコンテキストが完全に分割しきれていない状況ならではの課題だと感じています。

こうした課題への対応として、まずはプロダクトマネージャー同士が連携し、機能の整合性を取るためにロードマップの同期を組織的に行っています。これを「PO会」と呼んでおり、定期的に開催しています。

また、完全な新機能や新しい取り組みを行う際には、一時的に専用のプロジェクトチームを作り、そちらで開発を進め、形になったところで元のチームに戻す、というスタイルにしています。このように、一時的にチームを跨いだ（横断的な）体制でプロジェクトを進めることで、調整コストを抑える工夫をしています。

なお、今後考えうるリスクとして、やはりセキュリティや認証認可といった、最も守るべき部分については、いかに全体で一貫した統制を保ち続けるかという点に課題を感じています。特に脆弱性対応のコストが課題です。サイドカーコンテナなどが各チームで独自に動いているため、定期的なバージョンアップやパッチ対応といった作業が、今は各チームにそれぞれの負担になっている状態です。

また、監視の運用設定などもチームごとに行っている箇所があり、運用のための設定をすべてチーム側で負担しなければなりません。こうしたコストは、チームが増えれば増えるほど、組織全体としては大きくなっていくのではないかと懸念しています。

開発者の認知負荷を下げる「プラットフォームエンジニアリング」

ここまで課題についてお話ししましたが、これを解決する対策としては、プラットフォームエンジニアリングを進めなければいけないと考えています。

プラットフォームエンジニアリングは、セルフサービス型の開発者プラットフォームを構築・運用し、開発者の生産性を上げるために認知負荷を下げていく専門分野です。ゴールデンパスを作って本質的な開発に集中できるようにすることを目指しています。

なぜ、今プラットフォームエンジニアリングを目指さないといけないかというと、リアーキテクティングを進めたことで、課題となるボトルネックがチーム数とシステム数の増加に移っているため、チーム内だけでの解決は難しくなっているからです。

そのため、ストリームアラインドチームが効果的に継続的に価値を創出し続けられるようにチームや組織を考える必要があります。そうすると、チームを小さくするとか、連携のためにチーム内外のプロトコルを作るとか、適切な認知負荷を下げる、といった案が出てくると思います。その中では、やはり認知負荷が一番大きくのしかかってきている状態です。

課題内在性認知負荷や学習関連負荷は必要なものでもあります。そこで、課題外在性認知負荷をどうやって解消するかに注力する必要があります。

リアーキテクティングは、認知負荷の軽減とも言い換えられます。境界づけられたコンテキストによる分割は、課題内在性認知負荷への対応でした。ただ、大きくなりすぎると自分たちで扱うのは難しいため、ビジネス領域をもとに、必要な負荷を分散させようとしています。

一方で、システム刷新については、課題外在性認知負荷を軽減していくための取り組みとして進めています。

チームによって作業可能な技術領域の範囲は異なりますが、一番注力したいのはビジネス領域であるアプリケーションコードです。

こちらの図は、 CNCF（Cloud Native Computing Foundation）のプラットフォーム領域のリファレンスをお借りしたものです。先ほどの課題をマッピングすると、いくつかの対応策が見えてきます。

例えば、対障害性でいうと、アプリケーションごとに作り込むのではなく、サービスメッシュを導入して共通でサーキットブレーカーを持たせる。二重登録のリスクについては、単なるAPIコールではなく、イベント駆動アーキテクチャを採用して確実なデータ連携を行う。そして、CI/CDのサイロ化やデプロイの課題については、標準的なプラットフォーム基盤を導入して統制を取る、など。CNCFの知見を取り入れることで、今の私たちが抱える問題を一つひとつ解消していけると考えています。

また、プラットフォームエンジニアリングを進める上で、自分たちの現状を把握しないと何をやっていいか分からないため、CNCFの成熟度モデルに自分たちの現状をマッピングしてみました。

すると、戦略的にできているところは少なく、暫定的にアドホックに対応している箇所が多いことが見えてきました。

現状のアドホックな対応としては、SREグループがモニタリングの一元管理の仕組みを提供したり、APIドキュメントのルール化などを進めたりしています。しかし、それらのルールを各チームが主体的に利活用できる状態にはまだなく、現状はアーキテクトグループや各チームのテックリードが中心となって仕組み作りを行っている段階です。

組織的な対応としてはまだまだこれからですが、戦略的にこのフェーズを一段階「右」へと進めていくことが非常に重要な時期に来ていると考えています。

Four Keys向上とAI活用による「未知を既知に変える」戦略

これまでのお話を踏まえて、今後の戦略についてもお話しします。

私たちは「チームファースト思考」を推奨しています。多くのチームに共通する課題外在性負荷があるなら、最小化するプラットフォームを整備して体制を整えていく。

指標としてFour Keysの向上を掲げ、開発チームが「知らない」「難しい」と感じる「未知」を「既知」に変える活動が必要です。実際に対応するかどうかは別として、リアーキテクティングで新しいAPIを作った際にストラングラーパターンによる移行時の機能整合性を自動担保するエコシステムを制作するアイデアなどが出ています。

ナレッジマネジメントにおけるチームAPIのドキュメントやインターフェースについては、現在Cosense（コセンス）等を使ってチームで進めています。最近では、Slack上でMCPサーバーやLLMエージェントを活用しており、AIに聞けば他チームの情報がすぐに手に入るようになりました。そのため、今後はよりAIを活用した生産性向上や、開発フローの促進が必要になると考えています。

また「AIを活用したプラットフォーム戦略」を進める必要がありますが、一方でAIコーディングエージェントの進化が速く、仕組み作りが想像以上のスピードで進んでしまいます。そうなると、各チームが独自の判断で実装を加速させてしまい、品質担保やガバナンスが効かなくなるリスクも同時に生まれてくると感じています。

ただ、プラットフォームエンジニアリングそのものもAIエージェントで加速させることが可能ですので、うまく活用して進めていきたいと考えています。

最後に、ビズリーチでは現在、様々なポジションで採用活動をしております。ご興味があれば、ぜひ一度お話ししましょう。

ご清聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。