事業が成長し、業務への理解が深まると、プロダクトに求められる役割や、変更したい範囲も変わります。しかし、その理解を既存の構造へ反映するには、コードの修正に加え、複数のチームにまたがる責務や優先順位の合意、利用側の移行が必要になることがあります。
ビズリーチでも、設計やテスト、開発基盤の改善を重ねる一方で、プロダクトや組織をまたぐ変更の難しさが残っていました。その経験から、技術的負債が長期化する仕組みと、構造を見直す取り組みを振り返ります。さらに、得られた学びを、AIも参加して変更と検証を進められる環境への投資につなげて考えます。
株式会社ビズリーチで、プロダクト本部 プラットフォーム統括部の統括部長を務める菊池信太郎です。2026年9月17日、「技術的負債に向き合うConference 2026」で登壇した内容を記事にまとめました。
発表スライドは「技術的負債から考える、AI時代のエンジニアリング投資 ― ビズリーチの技術的負債と向き合った経験から、変更し続けられるソフトウェアを考える」で公開しています。
以下のスライド画像は同資料から引用し、ページ番号を添えています。
業務への理解と構造のずれが、技術的負債を生む
ビズリーチでは、求職者と採用企業がメッセージをやり取りします。当初は、その進捗を両者が共有するモデルとして捉えていました。業務への理解が進み、お客様に見える機能は変更しましたが、データモデルはそのまま残りました。その後の書き直しでは、変更しやすくするために判定処理を一箇所へ隔離しました。
従来の実装では、求職者がメッセージを保存すると、求職者側と採用企業側のメッセージボックスを作り、採用企業側の「対応済み」まで判定していました。
ここで、送信APIや通知イベントの仕様は保ったまま、採用企業側の「対応済み」の条件だけを変える場合を考えます。変えたいのは採用企業の業務ルールですが、求職者側の保存処理を調べる必要があります。変えたい業務と、理解・変更する実装の範囲がずれているわけです。これは設計を比較するための説明例で、この仕様変更を実施したという話ではありません。
判定を隔離した時点でも、問題には気づいていました。ただ、処理を一箇所へ集めることと、その判断を本来担う領域へ移すことは別の仕事です。移行先の責務を決め、利用側と合意し、実際に切り替える必要がありました。
この記事では、こうした業務上の責務と実装上の依存のずれによって、変更に広い調査や調整が必要になる状態を、構造的負債として扱います。
依存と調整が積み重なり、負債を返しにくくする
当初の構造には、その時点での事業の捉え方がありました。創業期から在籍するエンジニアに聞くと、求職者向け・採用企業向け・ヘッドハンター向けを合わせて、一つのプロダクトと考えていたそうです。開発者は少なく、全員がコード全体を理解していました。一つのリポジトリと共有データベースを使う構成も、その認識に沿った自然なものでした。
事業が成長し、機能もチームも増えると、変更の影響を調べ、調整する負担が大きくなります。ビズリーチでは、CI/CDやテスト、QA、設計、リリースの改善を重ね、各プロダクト内の変更容易性は取り戻しつつあります。それでも、レジュメや求人、メッセージなど、複数の領域をまたぐ変更には調査依頼や優先順位の調整が必要でした。
この経験から、負債が生まれることと、長期に残ることは分けて考えたいと思っています。
業務への理解と実装のずれが生じると、そのずれを補う調査・調整・検証が変更のたびに必要になります。その仕事に時間を使うほど、構造を改善する余力が減る。目の前の変更を既存構造への追加で進めると、依存や例外も増えていく。これを負債の「増幅」と捉えています。
さらに、既存構造を前提とする利用側が増えると、構造を変えるための合意や移行も重くなります。それぞれのチームには優先する仕事があり、一つのチームでは返済を決められなくなる。この、変更しやすくするための変更まで難しくなる状態が「固定化」です。
メッセージの判定処理を隔離したのも、局所的な変更をしやすくするためでした。しかし、業務判断を担う領域を変えるには、責務の合意と利用側の移行が残っています。問題への気づきだけでは解けなかったのは、この部分でした。
もちろん、すべての負債がこの経路をたどるわけではありません。初期のテスト不足など、別の原因もあります。また、事業成長のために、負債を認識しながら短期施策を優先する必要もありました。その判断も含めて、後から理解を構造へ反映できるようにしておく必要があります。
責務の合意を、利用側の移行までつなぐ
そこで見直したのは、メッセージの保持・伝送と、それを使う各プロダクトの業務判断を、誰が担うかです。処理の移動先を決める前に、情報を持ち、更新し、ルールを決める責務を整理しました。
メッセージについて合意した設計では、複数のプロダクトに共通する機能を担うマッチングプラットフォームが、メッセージを保持・伝送します。採用企業側の「対応済み」は採用企業側で判断します。送信可否やブロック適用は共通の責務に含めますが、各プロダクト固有の進捗や画面状態まで一括して決めません。
この設計で目指すのは、送信API・通知イベントの仕様を維持できる変更なら、採用企業側の判定条件を採用企業側で変えられる状態です。登壇時点では、合意した責務設計に沿ってAPI・イベントを実装しています。
横断する設計と、各プロダクトの計画を合意する
ビズリーチでは、組織横断のアーキテクチャ変更を検討する委員会を組成し、提案と判断材料を文書にするRFCを使って合意形成を進めました。関係する領域から制約や懸念を持ち寄り、責務や連携の方針を検討します。
ただし、設計への合意だけでは移行の時間は確保できません。レジュメや求人、メッセージの横断変更では、各プロダクトの責任者やエンジニアリングマネージャーへ説明し、調査を依頼して、優先順位を調整する必要がありました。ロードマップを決める事業PO会での合意も、その仕事の一部です。
この経験から、返済の計画には、提供側の実装に加えて、利用側の切り替え、検証、旧経路の撤去まで含める必要があると考えています。新しいAPIを作っても、利用側が従来の経路に依存していれば、構造的な負担は残るためです。
稼働を続けながら進める方法として、既存と新しい機能を併存させ、呼び出しを段階的に切り替えるストラングラーパターンがあります。切り替え後の動作を確かめ、不要になった旧経路を撤去するところまでを見据えます。
業務の境界を定め、変更と改善を繰り返す
候補者検索では、APIによる分離によってランキングを独立して変更できるようになりました。検索基盤の切り出しと旧経路の撤去も完了しています。
ただ、変更できるようになっても、新しいランキングがよいかどうかは別に確かめる必要があります。採用時期や選考状況によって利用者の行動が変わるため、リリース前後の単純な比較では評価しにくいという課題がありました。
そこで、新旧の検索結果を混ぜて提示し、利用者の行動から比較するInterleavingを導入しました。検索とその後の行動を結び付けるログも整えています。詳しくは、検索ランキングの比較のためにInterleavingの導入と評価をした際の工夫で紹介しています。
こうした設計を考える手がかりになるのが、ドメイン駆動設計の「境界づけられたコンテキスト」です。業務上の言葉やルールを、一貫した意味で扱う範囲を定めます。APIで分離するだけでなく、その内側で何を判断し、外側と何を共有するかを考えます。
候補者検索の事例も、この観点から捉えられます。「誰を、どの順序で提示するか」という判断を検索側で扱い、利用側との接点をAPIの仕様として定める。その範囲で変更と検証を繰り返し、利用者の行動から結果を評価する。変更する範囲を絞りながら、改善の効果は利用者への価値に照らして確かめます。
AIとともに、プロダクトを変え続けるために投資する
メッセージの責務整理では、深まった理解を構造へ反映する難しさがありました。候補者検索では、独立して変更できる構造と評価の仕組みを整え、改善を重ねています。業務の意味と変更の範囲が明確になれば、AIへ伝える文脈や、変更後に確かめる条件も整理しやすくなります。これからは、この変更と学習の仕事にAIも参加できる環境へ投資したいと考えています。
業務の理解と判断理由を伝える
AIが既存コードを読んで把握できるのは、現在の挙動です。それが今の業務に合っているか、どの責務を変えたいかは、別に考える必要があります。メッセージの例でも、現行の判定処理と、採用企業側が判断を担う合意済みの設計には違いがあります。
顧客や業務を理解し、何を変え、何を守るかを人間が考える。AIも調査や比較を助け、その理解を実装へ反映する。こうした仕事を進めるために、現行挙動、合意した設計、未決定事項を区別し、判断理由とともに参照できるようにします。
変更を試し、結果から直せるようにする
AIが変更を試し、検証結果を受け取り、修正して再実行できる環境を整えます。業務ルールやAPI・イベントの仕様をテストで確かめ、実行権限と隔離環境で操作範囲を制限します。環境の起動や結果の受け渡しを毎回人が担うと、検証・修正も人待ちになるためです。
情報・ツール・実行結果をつなぎ、AIの仕事を支える仕組みをハーネスと呼んでいます。設計やテスト、実行基盤への投資を、AIも一連の仕事で使えるようにつなげていきます。
構造の移行がすべて終わるのを待たず、現行挙動の調査やテストの追加から始められます。調査や検証の負担を下げられれば、これまで費用が見合わず見送っていた改善にも取り組みやすくなります。
結果から、前提も見直す
候補者検索で利用者の行動からランキングを評価しているように、AIと進める開発でも、仕様どおりに動いたかに加えて、顧客に役立ったかを確かめます。実装が合意した条件を満たさなければ実装を直し、期待した効果が得られなければ、業務の捉え方や仕様、評価条件も見直します。
AIも見直し案を作れますが、業務ルールや評価条件の採否は、責任を持つ人やチームが判断します。合意した内容を実装と検証へ反映し、結果を次の判断へ戻す。その際には、AIが根拠と権限に沿って進め、必要な判断を人へ求められたかも確かめます。
投資の効果は、次の変更で繰り返す調査や手作業が減ったか、品質を保ちながら時間や費用を抑えられたかで見ていきたいと考えています。
理解を構造へ反映する仕事を先送りしない
技術的負債を引き受ける判断は、これからもあります。それでも、理解を構造へ反映する仕事を先送りし続けない。人とAIが変更を試し、結果から学べる環境を整え、プロダクトを変え続ける力につなげていきたいと考えています。
ビズリーチでは、新しい仲間を募集しています。
お客様にとって価値あるモノをつくり、働く環境の変革に挑戦する仲間を募集しています。
募集中のポジションやプロダクト組織の詳細は、ぜひキャリア採用サイトをご覧ください。
