株式会社ビズリーチについて

皆さんこんにちは。ビズリーチの外山大と申します。よろしくお願いいたします。

本日は「ビズリーチが挑むメトリクスを活用した技術的負債の解消」と題し、講演いたします。

弊社について少し紹介させてください。テレビCMなどで転職関連のサービスとしてご存じの方もいらっしゃると思いますが、HR関連の複数のサービスを提供している会社です。今回はVisionalグループとして協賛させていただいていますが、グループ内の株式会社ビズリーチから発表させていただいています。

株式会社ビズリーチは、「『キャリアインフラ』になる」というビジョンを掲げています。
インフラというと私たちの生活に必要不可欠な電気や水道などをイメージされると思いますが、それと同じように、働く人々が主体的にキャリアを考え、築いていくうえで必要不可欠な存在、つまりキャリアのインフラになりたいという思いを込めてこのビジョンを掲げています。そしてキャリアインフラになることで、一人ひとりが活き活きと働くことができる社会の実現を目指しています。

このビジョン実現に向けて掲げているのが「キャリアに、選択肢と可能性を」というミッションです。キャリア形成において重要なのは、自分の未来に自信を持てる「はたらく」を選択し、挑戦し続けられる企業とつながることができることだと考えています。だからこそ、キャリア形成においてたくさんの選択肢と可能性を提供し、HR市場をこれからも変革していきたいと考えています。またビズリーチとしては、社名になっている「ビズリーチ」というサービス以外にも「HRMOS（ハーモス）」シリーズなど、HR関連のサービスを複数展開しており、これらを含めて「『キャリアインフラ』になる」というビジョンの実現を目指しています。

事業の急成長 - 技術的負債が蓄積した背景とその弊害

ここから本題に入らせていただきます。今日はメトリクスを活用した技術的負債の解消というテーマですが、まず技術的負債が蓄積された背景とその弊害についてお話ししたいと思います。

まず技術的負債が蓄積された経緯です。ありがたいことに、我々の事業は急成長を続けています。その成長の中でさまざまな新規開発や、機能のアップデートを重ねてきました。時には成長速度に合わせた開発を優先したことで場当たり的なアップデートになってしまうケースも多々ありました。その結果、コードが複雑に入り組んだ、いわゆるスパゲッティ状態になってしまった経緯があります。

また、事業運営が長期にわたり継続していく中で、開発組織のメンバーも入れ替わっていきます。新しい仲間が入社したり、卒業していく仲間がいたりすると、誰も見たことのないコードが増えたり、これまでの経緯を知る人がいなくなっていたりしました。こういった経緯を経て技術的負債が蓄積されてきたわけです。

技術的負債が蓄積されると、以下のようなことが起こります。



技術的負債が発生してしまう要因というのは、ソフトウェアを使用してビジネスを展開している企業であれば、どんな企業でも起こり得るものです。一方で、その弊害はどんな企業でも起こったら困るものばかりです。技術的負債にどのように向き合うかは、ソフトウェアを利用して継続的にビジネスをしているすべての企業にとって非常に重要な課題だと言えます。

このような技術的負債に対して、ビズリーチではどのように向き合っているのかという事例を、4つの軸で紹介します。リアーキテクティング、ボトルネックを解消するプロセス改善、生成AIの活用、SODAによる可視化です。

まずはリアーキテクティングです。リアーキテクティングの取り組みについては過去に何度か発表しており、こちらは3年前に弊社の菊池が発表した内容ですが、事業戦略の変化に対応しやすいアーキテクチャの改善を繰り返していく、ドメインを分けて段階的にAPI化していくといった発表を行いました。現在、リアーキテクティング開始から約3年が経過し、対象範囲の半分以上が進んでいる状況です。どこから進めるかが成功の肝になると考えており、「ビズリーチ」ではビジネス観点でインパクトの大きい部分を優先的に実行しました。
リアーキテクティングでのメトリクス活用方法ですが、目的は技術的負債を解消してビジネスにおける競争力を維持・向上させることです。競争力は抽象度が高く、営業力など開発以外の変数も含むため、開発にフォーカスした定量的メトリクスを見ながら目的を目指すことも重要かと思っています。Four Keys、GitHub Activity、Datadogのレイテンシーなどを参考にしてきました。

ただし定量的指標は、ケント・ベック氏のキーノートでも紹介されていたグッドハートの法則の通り、目標にしてしまうとハックされる性質があります。目的が達成されているかを常にピン留めし、参考指標として使うことが重要です。

リアーキテクティングの成果と効果

いくつかリアーキテクティングの成果・効果の事例をご紹介します。

まず、検索機能をリリースした事例をご紹介します。その前に、我々のビジネスモデルを簡単にご説明します。企業様やヘッドハンターの方々が求職者様へ自らアプローチできるプラットフォームを提供しており、求職者の皆様には職務経歴書などの情報をビズリーチ上に登録していただきます。一方で、採用する側の企業様やヘッドハンター様は、それをもとに求める人材を検索します。マッチする方がいればスカウトを送ります。検索の精度、つまり求める人材の検索しやすさはユーザー体験に大きな影響を与える機能です。この部分をレガシーコードから切り離してグロースしています。

リアーキテクティングとその後のグロースを同じチームが担っていましたが、結果として、リアーキテクティングによって開発スピードは著しく向上しました。左のグラフがレガシーコードのデプロイ頻度で、中央値は週に1〜2回です。一方、右のグラフが切り離してグロースした検索機能のデプロイ頻度で、週に10回以上デプロイしています。検索機能はユーザー体験への影響が大きいため、多くの施策を実施できていることはビジネス的にも非常に大きいと考えています。



2つめの事例は、求職者様向けWebのリアーキテクティングです。求職者様が職務経歴書を登録するなどの機能で、toCということもありA/Bテストを頻繁に行う性質があります。範囲が広いため、リアーキテクティングとグロースを別チームで実施しています。



リアーキテクティングの効果ですが、グロースを担当する1つのチームを例に挙げると、左がレガシーコードを改修していた時期のアクティビティで、右がリアーキテクティング後のコードを改修していた時期のアクティビティです。レガシーコードを触っている時期はコミットが途切れ途切れになっています。これは調査に時間がかかるため、間が空いてしまうことが現れていると考えられます。



一方で右側は、グロースチームがリアーキテクティング後のコードを触り始めた時のアクティビティです。触り始めは学習期間のためアクティビティが低いのですが、そこからの学習スピードが非常に速く、学習後のアクティビティも多いです。リアーキテクティングした成果が如実に表れていると考えています。

これは弊社のIR資料でも紹介している「レジュメ自動作成」という機能を、リアーキテクティング後のWebに組み込んだ際のアクティビティですが、効果の大きな施策を素早く打てたビジネスインパクトが大きい事例だと思っています。

ボトルネックを解消するプロセス改善

次に紹介するのは、ボトルネックを解消するプロセス改善についてです。こちらはレガシーなコードのリリースプロセスの改善事例になります。先ほどのリアーキテクティングは、コードの負債中心の話でしたが、負債はプロセスにも存在します。



組織がスケールするにつれて、リリースプロセスもそれに耐えられるよう改善する必要がありました。プロセスを整理しようとした際の状態は、ルールはあるが文書が散在している、ルールの存在理由が分からない、ドキュメントがない、関係者もいない、といった状況で、プロセスの見直しにも「考古学」が必要な状態でした。

さらに、プロセス整理を複雑にしていた要因として、会社がスケールする過程で増えたガバナンス対応があります。プロセスを改善しつつも、ガバナンス要件を担保する必要がありました。例えばPRの紐付けルールや承認フローについて、このPRはどのイシューに紐付いていて、承認は規定されたフローを満たしているか、といった点です。そういったものは早くリリースしたいという意味では省略したいのですが、ガバナンスとしては非常に重要なものも多々あります。こうした項目がなぜ必要なのかを確認しながら整理していく必要がありました。

この改善に向けて、取り組み前は2週間に1度のリリースでしたが、これを2倍にする目標を掲げ、実現時に何がボトルネックになるかを逆算して課題を洗い出しました。進め方としては各チームではなく、専任のチームが実施する形を取りました。内容としてはDevOps、内部統制、既存プロセスの可視化、CI/CDなど多岐にわたり、組織横断的な調整が必要になるため、そういったケイパビリティを持つチームでなければ難しい部分がありました。

この取り組みでメトリクスをどのように活用したかというと、組織のスケールに耐え切れなかったリリースプロセスの改善を目的に、どこがボトルネックになるのかを明らかにするため「デプロイ頻度を2倍にするにはどうするか」という状態目標を置き、そこから逆算しました。課題やボトルネックを浮き彫りにしたうえで、手動プロセスなどを確認しながら改善を進めていきました。

実際に行ったこととしては、まずバリューストリームマッピングで全てのプロセスを可視化し、ボトルネックを順次改善することを繰り返しました。手作業だったテストプロセスの自動化、複数プロダクトにまたがるE2Eテストのオーナー整理、属人化していた作業の標準化などを実施しました。



結果として、改善前のバリューストリームマッピングでは多くのプロセスが存在していましたが、改善後は大幅にスッキリとシンプルな状態になりました。現在はリリースプロセスの自動化がかなり進み、スケールした組織でも改善を回せる状態となっています。リリース頻度は中央値で従来の2倍となり、週1回から2回のリリースが可能な状態になっています。



さらにリリースプロセスをシンプル化できたことと、最近の生成 AIの目まぐるしい進化により、自動化できる部分も見えてきています。

生成AIの活用 - 実験コストを減らし、迅速な学習を

次に生成 AIの活用をご紹介します。生成 AIの活用は、大きく分けて開発作業での活用と、業務への活用からプロダクトへの発展の2つの軸で紹介します。



生成 AIの活用についてはまだ実験的な取り組みが多数あります。定量的なメトリクスにこだわらず、当事者の定性的なメトリクスを参考にしながら、あらゆる可能性を試すことが大事だと考えています。ケント・ベック氏の3Xモデルでいう探索フェーズに当たると思っており、実験コストを減らして学習を迅速にすることが重要だと考えています。

事例として、開発作業での生成 AI活用、まずコーディング支援としての使い方ですが、Claude Code、Cursor、Devinなどを利用可能な環境を整えています。ただ、これを使うと決めきれている状況ではありません。生成 AIはトレンドが毎月のように変わる状況でもあるので、検証を繰り返している段階です。

我々の開発組織の特徴としては、技術的負債が蓄積された巨大なリポジトリもあれば、比較的新しいリポジトリもあります。バックエンド／フロントエンドやチーム構成など、さまざまなバリエーションがあるため、それぞれに異なる傾向が出ると考えています。その中で各種ツール・生成 AIモデルを比較していきたいと考えています。

またPR数、PRサイズ、リードタイムなど、さまざまな角度のデータを取得できる環境は整っており、主観的な観点だけでなく客観的な数値データでの比較も行うことで導入を促進したいと考えています。結果をご報告できる機会があればと思っています。

ここでのメトリクス活用ですが、まだ明確なデータは取れていないものの、PR数、PRサイズ、リードタイムを測って検証していきたいと考えています。コードの生成をAIに任せることで、開発者が価値創出に注力できるかが目的なので、それをピン留めしつつ、これらのメトリクスも複眼的に見ていきたいと考えています。

開発作業での生成 AI 活用とドキュメンテーションの活用事例

次に、開発作業での生成 AI活用とドキュメンテーションの活用事例をご紹介したいと思います。

技術的負債の原因の1つとして、ドキュメントがないという話はよくありますが、この領域での活用への期待は大きいと考えています。事例をご紹介する前に、まず私たちのドキュメンテーション文化の浸透状況をお話しします。開発組織ではCosenseというツールを導入しています。ミーティングのガヤのようなライトなものから設計ドキュメントまで、あらゆる用途で使い倒しており、何でも記録する文化が浸透してきています。

Cosenseの特徴として、ページ間のリンクとタグによる分類でドキュメントを関連付けるのが簡単で強力です。さらに「Export For AI」という機能があり、プレーンテキストで2hop先の内容までエクスポートできます。これによりチームのドキュメントを簡単に集められます。



このような背景の中での活用事例として、オンボーディング資料の生成があります。私たちは開発をさらに進めるため、新しい仲間がどんどんジョインしています。チームに関連するドキュメントはCosenseのリンク機能のおかげで収集が容易です。それらをNotebookLMにインプットし、それをベースにオンボーディング資料を作成します。分からないことがあった場合はNotebookLMに問い合わせることで、Cosenseに収録された情報をもとに高精度の回答が得られます。

別の活用事例としてCosenseに蓄積されたドキュメントを活用するため、CosenseのMCPサーバー運用を実験的に開始しています。これにより、Cosenseのデータをプログラマブルな範囲まで活用する試みです。またSlackのボットを生成 AIとCosenseに接続する取り組みも行っており、後ほど紹介する「prAlie‑dog（プレーリードッグ）」プロジェクトもその一環です。これにより、Slackでボットに質問や壁打ちをすると、Cosenseに蓄積されたデータをもとに回答してくれます。

例えばプロジェクトの進捗状況を尋ねると、進捗ミーティングの議事録がCosenseにあるため最新状況を答えてくれます。またAPIなどの設計ドキュメントもCosenseにあるので、設計ポリシーを尋ねると背景を含めて詳細に答えてくれるといったことが可能になります。ここについてのメトリクス活用方法ですが、目的は知見の入手コストを低減しつつ、あらゆる可能性を探索することにあります。メトリクスとしては調査タスクのリードタイムが減るかどうかなどが考えられますが、実験者の定性的な観点が重要な指標になると考えています。



これはタスクのリードタイムを可視化したもので、各タスクがどのステータスにどれくらい時間を要したかをグラフィカルに確認できます。調査タスクのリードタイムが減ってきた傾向や、ドキュメント活用できる箇所と活用できていない箇所の差が広がる様子などが見えてきます。関連ドキュメントが不足している機能が明確になれば、優先度を判断しやすくなると期待しています。

テスト分析における生成AIの活用事例- 8割もの作業を自動化

続いて、テスト分析での活用事例を紹介します。生成 AIを活用することで作業の8割を自動化できたという事例です。NotebookLMにFigmaのデザイン、テスト分析の流れを記載したドキュメント、過去のテスト分析例を読み込ませ、その結果をMiro AIにインプットしてマインドマップを生成します。エンジニアはそのマインドマップをレビューするという使い方です。



右側の図では、必要なテスト観点がマインドマップとして出力され、それをベースにテスト設計やテストケース作成を進められます。メトリクスとしては、作業者の感覚で「8割自動化できた」といった主観的な評価が重要になります。同時に、コストを抑えつつテスト品質を落とさないことが目的でもあるため、障害発生率なども多角的に確認する視点が必要です。

ポストモーテム分析での活用事例 - 課題をより広く捉えるために

次に、ポストモーテム分析への活用に取り組んでいます。
もともとポストモーテムでは、参加メンバーやチームによって深掘り度合いや観点にばらつきがあるという課題があり、議論が参加メンバーの視点に限定されやすいという側面もありました。



これは悪いことではないのですが、開発チーム内でポストモーテムを行うと、そのメンバーに「自分たちができることは何か」という意識がどうしても働く傾向があります。これは良い面もある一方、本来であれば要件定義で考慮すべき事項や、組織全体で取り組むべき連携課題が、自分たちの頑張りで解決できる範囲の施策にとどまってしまうこともありました。

そこで、こういった指摘を生成 AIによるレビューで行えば、より広く課題を拾い上げやすくなるのではないか、という仮説を立てました。現在検証中ですが、NotebookLMやCosenseのAI機能を利用して実施しています。
ポストモーテムを読ませる前に、前段として二次インプットを用意しました。

1. 深掘りが十分に行われたかの分析観点

   • どの工程で混入したか
   • どの工程で検出されるべきだったか
   • 対応プロセス各期間（発生→検知、検知→応急対応、応急→根本対応）で課題がなかったか
   • 原因に対するネクストアクションが決定されているか
   • 振り返るべき点に過不足がないか

2. 参加者以外の観点が必要かの分析
   4つの職務視点でレビューを依頼しました。

   • 開発エンジニア：自動化や効率化の指摘
   • 開発エンジニアリーダー：チーム習慣や具体的プロセスの指摘
   • プロダクトマネージャー：要件定義やユースケース定義に関する指摘
   • エンジニアリングマネージャー：チーム間連携、育成、組織課題の指摘

このインプットを与えてポストモーテムを読ませた結果、現状では議論内容の要約にとどまっています。期待していたのは、たとえば「コーディングでの考慮不足が原因と結論づけたが、実は要件定義で詰めるべきだったのでは」といった指摘でしたが、それにはプロンプトのチューニングやコンテキストの充実がもう少し必要だと感じています。

ただ、要約を見てマネージャーが「深掘りが十分か」をレビューする用途には有効です。今後はCosenseに蓄積された情報と連携させ、設計内容などの背景をインプットすることで、さらに深掘りされた分析が可能になると考えています。

これは今後、大量の件数をインプットした場合の分析の精度も見ていければと思っています。これの目的としては、ポストモーテムに多角的な観点を追加して学びの精度を上げたいというところで、うまくいけばIssue化件数が増えたり、そこからさらに障害の件数が減ることを期待していますが、まだ検証中の段階です。

プロダクトへの活用への発展 - 「prAlie‑dog（プレーリードッグ）」プロジェクト

次は業務での活用からプロダクトへの活用に発展した事例を紹介します。弊社内では、先ほど触れた「prAlie‑dog（プレーリードッグ）」プロジェクトという名称で進行しています。

これは業務に特化した生成 AIアプリケーションをSlackのワークフローやチャットボットとして実装したものです。入口の部分にSlackを利用することで、極力低コストで生成 AIを業務フローに取り入れることを狙っています。さらに社内ニーズをトリガーとしているため、検証リソースや利用促進・展開のコストも抑えられるメリットがあります。

ここでブラッシュアップして活用が進んだものをお客様への提供にまでつなげられた例として、「求人自動生成」という企業様向け機能があります。弊社のIR資料でも紹介されていますが、技術的な観点から業務効率化を経てプロダクションに導入された一例です。その他に現在20以上のプロジェクトが進行しており、この中には、先ほど紹介したSlackでCosenseに蓄積されたデータを取得する取り組みも含まれます。
このようにビズリーチではプロダクトへの生成 AI活用にも力を入れており、当社の前年会計年度において生成AIの特許公開件数が日本で1位となっています。今紹介したものもその1つです。

SODAによる、開発組織の可視化と意思決定

最後はSODA（SODA : Software Outcome Delivery Architecture）による可視化です。まずSODAとは何かを説明します。SODAとは、ビズリーチが提唱しているフレームワークで、開発組織を取り巻くさまざまな状況をメトリクスとして可視化し、それを意思決定に役立てるものです。



このSODAはいくつかのサブプロジェクトで成り立っています。1つ目はチームパフォーマンスで、開発チームのパフォーマンスに関わるものです。Four Keysやケイパビリティー、DORAが提唱するようなメトリクスを可視化します。あとは品質データですね。コードカバレッジだったり、顧客アウトカム（顧客の問題が解決できたか）だったり、プロジェクトデイリーリソースの状況（人・もの・金）ですね。プロジェクトの進捗状況などもここにあります。

こういったすべてを透明性高く見えるようにするエビデンスビューと、複数のサブプロジェクトで進めています。ご興味のある方は、これまで発信している資料をご覧いただければと思います。

SODAでのデータモニタリング

SODAで技術的負債解消のどのようなデータを可視化しているかをご紹介します。技術的負債解消と機能追加のバランス、開発パフォーマンスのモニタリングの2軸でお話しします。

技術的負債解消と機能追加のバランス

まず技術的負債解消と機能追加のバランスです。どのようなバランスで負債解消と機能追加を行うかは非常に難しく、正解がない領域です。ただ、明確な意思を持って臨み、その意思を説明できることが重要だと思っています。意思決定にはレベルとそれを担うレイヤーがあります。

まずは組織構成です。弊社ではリアーキテクティングを進めるチームとグロースを進めるチームを分けており、チーム組成にバランスの意思を込めています。

次にプロジェクト優先度です。機能追加と同様に負債解消をプロジェクト化し、優先度を決めていきます。これはマネージャーやプロダクトオーナーの意思が込められることが多いと考えています。これによりバックログの実施優先度にバランスの意思が込められます。

次は作業割合です。これはリファクタなどに当たり、エンジニアメンバーの意思が反映されるところで、日々の開発作業の中で必要なものを実施していきます。



SODAで可視化しているのは上の2つです。3つ目も分離して記録することは可能ですが、エンジニアに2つの作業を分けて記録してもらう負担が過剰だと判断し、割り切って上の2つを可視化しています。

それをどう見ていくかというと、「ビズリーチ」では工数の実績をモニタリングしています。
具体的には、CrowdLogというツールを使って工数を集計しています。工数はどのプロジェクトにどれだけ使ったかという形で集計していますが、そのプロジェクトを分類することで集計しています。まず大分類として費用なのか投資なのか。中分類として短期戦略なのか中長期戦略なのか人材戦略なのか保守運用なのか。小分類としてさらに細分化し、グロース施策なのかリアーキ施策なのか開発生産性向上施策なのか採用・育成・障害対応なのかと分類しています。

詳細はお見せできませんが、大分類としての費用・投資の比率、中分類の比率、小分類の比率、さらに時系列の推移などを見ることができます。モニタリングするポイントとしては、大項目・中項目・小項目のバランスが意思決定した範囲内にあるか、特にリアーキや基盤整備への投資が意思決定した範囲で推移しているかを見ています。



現在のフェーズを鑑みてグロースのリバランス、グロースへの投資強化なども行っています。時系列の変化では、改善型で効果の出現に時間がかかるものについて保守の工数が減ってきているか、障害対応の割合はどう変化しているか、などを見ています。今のところそういった問題はありませんが、エラーバジェットのような運用を目指したいと考えています。

開発パフォーマンスのモニタリング - 多角的な判断を行うための環境整備

次に開発パフォーマンスのモニタリングです。SODAで可視化している2つ目のポイントです。施策によって目的やフェーズが異なり、参考にすべき指標も変わってきますが、目的をピン留めし、それに近づいているかを確認しながら多角的な判断ができる環境の整備を進めています。



今後の展開としては、技術的負債を蓄積させない、あるいは生まない仕組みを目指していきたいと考えています。コードやプロセスに対する現在の負債解消施策を継続しつつ、それを蓄積しないための文化や仕組みの構築・醸成が重要だと思っています。そのためにSLOやエラーバジェットの運用に本腰を入れて取り組んでいきたいと考えています。

ポストモーテムなどの振り返りから学びの効果を最大化する文化も重要だと思っています。これについては、ドキュメンテーションの文化や、そこから学びを得やすくする仕組みの進化が重要だと考えています。次に生成 AIの活用です。今後、開発プロセスが大きく変わるパラダイムシフトが起きるだろうと考えています。

最後に信頼性の継続的向上です。信頼性の最適な状態を定義し、継続的に向上させていきたいと考えています。SLOやエラーバジェットにも力を入れていきます。こういった取り組みにおいてもメトリクスを活用し、総合的な判断ができるようにしていきます。

まとめ

今日のまとめです。



1点目は、リアーキテクティング。つまり技術的負債解消はビジネスインパクトを踏まえた優先度で実施したことが良い結果につながったということです。ROIが高くなりやすく、負債解消の意義も理解されやすいです。

2点目は、生成 AI活用のような探索フェーズでは、まずやってみることが重要な点です。身近な定性メトリクスを参考にまず試し、取り組みを共有する仕組みも大切です。

3点目は、本来の目的をピン留めした上でメトリクスを活用することが大事というところです。定量・定性問わず効果を測る際にメトリクスを参考にしますが、測定結果だけに振り回されず、本来の目的に近づいているか多角的に判断する必要があります。

私からの発表は以上です。ブログやXでも情報を発信していますので、興味のある方はぜひご参照ください。ご清聴ありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です