ビズリーチが挑むメトリクスを活用した技術的負債の解消 / dev-productivity-con2025

ビズリーチが挑む  メトリクスを活用した技術的負債の解消  開発生産性Conference2025, 2025/7/4    Visionalグループ　株式会社ビズリーチ  プロダクト本部プラットフォーム統括部ビズリーチプラットフォーム部 SODA推進グループ  外山大 
1

アジェンダ  1. 技術的な負債が蓄積された背景  2. ビズリーチの取り組み  • リアーキテクティング  • ボトルネックを解消するプロセス改善  •
生成AIの活用  • SODAの活用  3. 今後の展開  4. まとめ  2

外山大 Dai Toyama  自己紹介  • SIerでキャリアをスタートし、エンジニア -> EMを経験  •
2016年、合同会社DMM.comに転職。EMとして海外向けサイト、家事代行サービス立ち上げ、モバイル事業、豊洲のデジタルアート PRJなどを経験  • 2021年、建設DXを推進する株式会社アンドパッドにジョイン。 EM、組織開発部長などを務める  • 2023年、「SODA構想」に共感して株式会社ビズリーチにジョイン   Certified ScrumMaster® Certified Agile Leadership Essentials® Certified Agile Leadership for Organizations® 経歴  趣味スノーボード、ロックフェス、キックボクシング   3

会社概要  4 株式会社ビズリーチ / BizReach, Inc.  創業　　：2009年4月  代表者　：株式会社ビズリーチ代表取締役社長　酒井哲也 
グループ従業員数：2,149名（2023年7月末時点）  拠点　　：東京、大阪、名古屋、福岡、静岡、広島  資本金　：1億3,000万円  事業内容：HR Techのプラットフォーム・SaaS事業 

株式会社ビズリーチビジョン  自分の可能性を信じ、  自分の意志ではたらき方を選択することができたら、  覚悟をもった主体的な「はたらく」を実現できる。  生産性も向上し、企業にも活力が生まれる。    そのために、自分らしく「はたらく」をあたりまえにする  「キャリアインフラ」になりたい。   
一人ひとりが活き活きとはたらくことができる社会のために。  「キャリアインフラ」になる  5

株式会社ビズリーチミッション  6 時代の変化により、市場の構造が複雑化し、  価値観も多様化している。    キャリア形成において重要なのは、  自分の未来に自信を持てる「はたらく」を選択し、  挑戦し続ける企業と繋がり、新たな活力を生み出すこと。   
私たちは世の中にたくさんの「選択肢と可能性」を提供し、  「はたらく」を変革していく。  キャリアに、選択肢と可能性を 

株式会社ビズリーチサービス一覧  7 即戦力人材と企業をつなぐ  転職サイト  OB/OG訪問  ネットワークサービス  人財活用システム  採用管理システム  勤怠管理システム 
経費精算システム  労務・給与システム  社内スカウトで  人材流出を防ぐ   

8 メトリクスを活用した  技術的負債の解消 

1. 技術的な負債が蓄積された背景  9

技術的な負債が蓄積された背景  10 変更が積み重なる  コードがスパゲティ化  時には場当たり的な  変更になるケースも  事業が急成長  技術的な負債が蓄積 

技術的な負債が蓄積された背景  11 技術的な負債が蓄積  事業運営が  継続していく  開発組織の人も  入れ替わっていく  誰も見た事ないコードが増え  経緯を知る人が減っていく 

12 技術的負債が蓄積される弊害  1. 技術的な負債が蓄積された背景 

技術的負債が蓄積されると・・・ 13 1. 開発生産性への影響 2. 人材・組織への影響 3. ビジネスへの影響

技術的負債が蓄積されると・・・ 14 1. 開発生産性への影響 • 開発速度の低下 ◦ コードの理解・変更コストが高くなり、新しい機能追加に時間がかかる • バグ・障害の増加
◦ 複雑で整合性のとれていないコードは、テストしにくくバグが混入しやすくなる ◦ CI/CDが不安定となり、リリース遅延や失敗が増加

技術的負債が蓄積されると・・・ 15 2. 人材・組織への影響 • 開発者体験の悪化とモチベーションの低下 ◦ 技術的負債がない環境では生じないような作業が発生する ↓ ◦
仕事が遅くなるフラストレーションを感じる ↓ ◦ 意味のある仕事に時間を使えない虚無感 ↓ ◦ モチベーションの低下に繋がる

技術的負債が蓄積されると・・・ 16 3. ビジネスへの影響 • ビジネス上のリスク（競争力の低下・コスト増） ◦ 市場機会の喪失 ▪ 変化への対応が遅れたり、トラブル対応に追われて本来の価値創出ができなくなることで
競争力が低下 ◦ 技術コストの増加 ▪ 開発生産性の悪化により対応コストが増加する ◦ 品質・信頼性の低下による顧客離れ ▪ 技術的負債によって障害が頻発すると、ユーザー体験が損なわれ、ブランド信頼や顧客ロイヤルティに悪影響を及ぼす ◦ M&AやIPO時の評価低下 ▪ 技術的負債が蓄積されたシステムは、買収・出資などの際の評価減要因となり得る

技術的負債が蓄積されると・・・  17   • 開発速度の低下  ◦ コードの複雑性がますことにより、認知負荷が増加  ◦ コードの理解・変更コストが高くなり、新しい機能追加に時間がかかる   
• バグ・障害の増加  ◦ 複雑で整合性のとれていないコードは、テストしにくくバグが混入しやすくなる  ◦ CI/CDが不安定となり、リリース遅延や失敗が増加    • ビジネス上のリスク（競争力の低下・コスト増）  ◦ 市場変化への対応遅れによる機会損失  ◦ 品質・信頼性の低下による顧客離れ   

技術的負債が蓄積されると・・・  18 参考文献  • 『LeanとDevOpsの科学』  ◦ Nicole Forsgren Ph.D. ,
Jez Humble, Gene Kim 著, 武舎広幸訳（インプレス, 2018年）  • 『エンジニアリング組織論への招待』  ◦ 広木大地著（技術評論者, 2018年）織  • 『ソフトウェアアーキテクチャメトリクス』  ◦ Christian Ciceri、Dave Farley、Neal Ford、Andrew Harmel-Law、Michael Keeling、Carola Lilienthal、João Rosa、Alexander von Zitzewitz、 Rene Weiss、Eoin Woods 著、島田浩二訳（オライリージャパン, 2024年）  • 『レガシーコード改善ガイド』  ◦ マイケル・C・フェザーズ著, ウルシステムズ株式会社 (監修), 平澤章, 越智典子, 稲葉信之, 田村友彦, 小堀真義訳（翔泳社, 2009年）  • 『エンジニアのためのマネジメントキャリアパス』   ◦ Camille Fournier 著, 武舎広幸, 武舎るみ訳（オライリージャパン, 2018年）  • DORA Report URL: https://dora.dev/research/2024/dora-report/   

技術的負債が蓄積されると・・・  19 • 開発速度の低下 ◦ コードの複雑性がますことにより、認知負荷が増加 ◦ コードの理解・変更コストが高くなり、新しい機能追加に時間がかかる • バグ・障害の増加
◦ 複雑で整合性のとれていないコードは、テストしにくくバグが混入しやすくなる ◦ CI/CDが不安定となり、リリース遅延や失敗が増加 • ビジネス上のリスク（競争力の低下・コスト増） ◦ 市場変化への対応遅れによる機会損失 ◦ 品質・信頼性の低下による顧客離れ事業を継続していればどの企業にも起こり得る      どの企業でも起こったら困る  要因影響

技術的負債にどのように向き合うか  技術的負債に  どのように向き合うか？  20

技術的負債にどのように向き合うか  21 技術的負債にどのように向き合うか？     ソフトウェアを利用して  継続的にビジネスをしている  全ての企業にとって非常に重要な課題   
 

22 2. ビズリーチの取り組み 

ビズリーチでの向き合い方  23 2-1. リアーキテクティング  2-2. ボトルネックを解消するプロセス改善  2-3. 生成AIの活用  2-4. SODAによる可視化 

リアーキテクティング  25 リアーキテクティングの取り組みについては過去にも紹介  https://speakerdeck.com/visional_engineering_and_desig n/jjug-ccc-2022-fall  • 事業戦略は常に変化し続ける  • 変化に強いアーキテクチャへリアーキテクチャしていく  •
ドメインを分けて段階的にAPI化を進めている 

リアーキテクティングの現在  26 • 対象範囲の半分以上はリアーキが進んでいる状況  • ビジネス観点でインパクトの大きな部分からリアーキを進めている  リアーキテクティング開始から約3年 

リアーキテクティングの現在  27 • リアーキテクティングの目的  ◦ 技術的負債を解消してビジネスにおける競争力を維持・向上させる    • 活用できるメトリクス  ◦
Four Keys  ◦ Github Activity（コミット数やレビュー数）  ◦ Datadog（レイテンシーなど）    参考）グッドハートの法則  • イギリスの経済学者チャールズ・グッドハート（Charles Goodhart）が1975年のイギリスの金融政策に関する論文で提唱した法則  • 「測定されると決まった指標は、それが目標にされた瞬間に有効性を失う」 

事例紹介  28 2-1. リアーキテクティング 

リアーキテクティングの効果  29 事例1：検索機能  • 求人要件にマッチする求職者様を、企業様/ヘッドハンター様が検索する機能  • ユーザー体験への影響が非常に大きい機能  • レガシーなコードから切り離してグロース  •
リアーキとその後のグロースを同じチームが実施   

リアーキテクティングの効果  30 • 左がレガシーコードのデプロイ頻度で週に1,2回の頻度  • 右が検索機能のデプロイ頻度で、週に10回以上の頻度  • ユーザー体験に大きな影響がある機能で多くの施策を実施できている  レガシーコード  検索機能 

リアーキテクティングの効果  31 事例2：会員様向けWebリアーキ  • 会員様向けにレジュメの登録や企業様からのスカウト受信などの機能を提供  • toCということもありA/Bテストなど頻繁に行う性質をもつ  • 使用頻度、開発頻度の高い部分をリアーキ  •
リアーキとグロースを別チームで実施 

リアーキテクティングの効果  32 • グロースチームのActivityについて、レガシーコードの対しての改修時と、リアーキ後のコード改修時を比較  • リアーキ後は学習スピードが早くActivityの量も多い 

リアーキテクティングの効果  33 • ↓の機能のWebへの組み込みでの実績  • ビジネスへの効果が大きいポイントを優先的にリアーキする  • 開発スピードの改善をビジネスインパクトの大きい箇所を優先することで効果が最大化される  引用：ビジョナル株式会社「2025年7月期第3四半期決算説明資料」 

リアーキテクティング  34 リアーキテクティングの「現在」  https://speakerdeck.com/visional_engineering_and_desig n/jjug-ccc-2025-spring  • ドメインを踏まえた適切なモジュール分割  • ビジネス価値の高いものから実施  •
変更容易性とテスト容易性の高い設計パターンへ  • プロセスと組織を変える取り組み 

ボトルネックを解消するプロセス改善  36 • レガシーなコードのリリースプロセスの改善  ◦ 組織がスケールしていくに伴い、リリースプロセスもそれに耐えられるよう改善する必要があった  ◦ リリースプロセスに負債が蓄積していて、改善にはまず考古学が必要な状態  ▪ ルールはあるが、文書として散在している 
▪ ルールはあるが、なぜ存在してるかわからない  ▪ ドキュメントがない、関係者も既にいない   

ボトルネックを解消するプロセス改善  37 • プロセスの整理の難易度を上げた要因  ◦ 会社がスケールしていく過程で増えていったガバナンスへの対応  ▪ プロセスの改善  ▪ ガバナンスへの対応 
◦ これらをどちらも実現する必要があった  ◦ 開発者目線では簡素化したいが、ガバナンス目線で必要となるものもある  ▪ PRの紐付けルール  ▪ 承認フローなど 

ボトルネックを解消するプロセス改善  38 • 取り組み前：2週間に1度のリリース頻度  • これを2倍にするという状態目標を立てて逆算することで、プロセスにおける様々な課題を洗い出す    • 専任チームが実施  ◦
チームをまたがる複雑なプロセスの改善  ◦ 実行するチームのメンバー構成には様々なケイパビリティが必要  ▪ DevOps、内部統制、既存プロセスの可視化、CI/CD 

ボトルネックを解消するプロセス改善  39 • ボトルネックを解消するプロセス改善の目的  ◦ 組織のスケールに耐えきれなくなったリリースプロセスの改善    • 活用できるメトリクス  ◦
デプロイ頻度  ◦ リードタイム  ◦ 手動プロセス数 

ボトルネックを解消するプロセス改善  40 実施したこと  • Value Stream Mappingにより複雑なプロセスを可視化  • ボトルネックを特定し順次改善を繰り返していく  ◦
手作業だったテストの自動化  ◦ 複数プロダクトにまたがるEtoEテストのオーナー整理  • 属人化していた作業の標準化  ◦ ログ監視の標準化など 

ボトルネックを解消するプロセス改善  41 結果  • 現在ではリリースプロセスの自動化がかなり進んだ状態  • 週1のリリース頻度にまで改善  • 以下の変化により、さらにシンプル化、自動化できる部分が見えてきている  ◦
リリースプロセスをシンプル化出来てきたこと  ◦ 生成AIの進化   

ビズリーチでの向き合い方   42 2-1. リアーキテクティング   2-2. ボトルネックを解消するプロセス改善   2-3.
生成AIの活用  2-4. SODAによる可視化  

生成AIの活用  43 2-3-1. 開発作業での生成AI活用  a. コーディング支援  b. ドキュメンテーション  c. テスト分析 
d. ポストモーテム分析  2-3-2. 業務への活用からプロダクトへの活用  2-3. 生成AIの活用 

生成AIの活用  44 • 実験的な取り組みにおけるメトリクス  ◦ 生成AIの活用に関しては、検証・実験段階のものも多数  ◦ 定量的なメトリクスにこだわらず、当事者の定性的なメトリクスを参考にしながら、あらゆる可能性を試すのが大事   
参考）ケント・ベック 3xモデル（Explore、Expand、Extract）  引用：The Product Development Triathlon（https://www.facebook.com/notes/383448953014576/）  Explore（探索）：  探索の成功は予測不可能であるため、最も期待値の高い戦略は、実験コストを削減し、相関関係のない多数の実験に少額の投資を行うこと 

生成AIの活用  45 a. コーディング支援  2-3-1. 開発作業での生成AI活用 

生成AIの活用  46 各種支援ツールの導入  • Claude Code / Devin / Cursor
/ Cline など利用可能  • 以下のような特徴のあるコードに対して、最適な支援ツールや生成AIモデルは何かを見ていく  ▪ 負債の多い巨大なレポジトリ / 比較的新しいレポジトリ  ▪ バックエンド / フロントエンド  ▪ 支援ツール  ▪ 生成AIモデル  • PR数、PRのサイズ、リードタイム様々な角度でデータを集める  • 主観的な観点での評価だけでなく、客観的な数値データでの評価することで、導入を促進していく狙い 

生成AIの活用  47 • 支援ツールの導入の目的  ◦ コードの生成を生成AIに任せることで、開発者が価値の創出に注力    • 活用できるメトリクス  ◦
PR数、PRサイズ、リードタイムなど検証中    ※ 現在はまだ明確な比較データは取れていない段階 

生成AIの活用  48 b. ドキュメンテーション  2-3-1. 開発作業での生成AI活用 

生成AIの活用  49 ドキュメンテーションの状況  • 開発組織全体でCosenseを導入  • MTGのガヤなどのライトなものから設計ドキュメントまで、あらゆる用途で使い倒している  • あらゆるものを記録する文化が浸透してきた 

生成AIの活用  50 Cosenseの特徴  • ページ間リンクとタグによる分類でドキュメントを関連付けられるのが特徴  • Export For AI という最大2hop先の内容までテキストとしてExportできる 
• これを活用するとチームのドキュメントを集めるのが容易になる   

生成AIの活用  51 活用事例1：オンボーディング資料の生成  • チームに関連するドキュメントをNotebookLMにインプット  • Cosenseの特徴によりリンク付けと収集が容易で強力  • これをベースにオンボーディング資料の生成  •
わからないことがあった時の問い合わせなどにも活用 

生成AIの活用  52 活用事例2：CosenseのMCPサーバ運用  • CosenseのMCPサーバ運用を実験的に開始  • 蓄積したドキュメントをさらにプログラマブルな範囲に活用の幅を広げる試み  • さらにSlackのbotでCosenseと接続  •
Cosenseに蓄積されたデータを学習してSlackで壁打ちのような使い方をする実験などもしている  ▪ 例）プロジェクトの進捗状況を聞く  ▪ 例）設計ポリシーを聞く、など   

生成AIの活用  53 • ドキュメンテーションでのAI活用の目的  ◦ 知見の入手コストを低減し、開発者が価値の創出に注力  ◦ 入手できる知見の質はそのまま、むしろ広範囲で精度の高いものにしたい  ◦ とにかくあらゆる可能性を探索する 
  • 活用できるメトリクス  ◦ 調査タスクのリードタイム、など    ※ 実験者の定性的な観点も重要なメトリクス   

生成AIの活用  54

生成AIの活用  55 c. テスト分析  2-3-1. 開発作業での生成AI活用 

生成AIの活用  56 テスト分析  • テスト分析の自動化により8割を自動化  • NotebookLMに以下を読ませる  ▪ Figmaのデザイン  ▪
テスト分析の流れを記載したドキュメント  ▪ 過去のテスト分析  • 結果をMiro AIにインプットしてマインドマップを生成  • エンジニアはそれをレビューする 

生成AIの活用  57

生成AIの活用  58 • ドキュメンテーションでのAI活用の目的  ◦ テスト分析のコストを低減し、開発者が価値の創出に注力  ◦ テストの品質はそのまま、むしろ広範囲の観点で精度を向上させたい    •
活用できるメトリクス  ◦ 自動化比率（データではなく感覚値）  ◦ 障害発生件数   

生成AIの活用  59 d. ポストモーテム分析  2-3-1. 開発作業での生成AI活用 

生成AIの活用  60 ポストモーテムで感じていた課題  • 参加メンバーやチームによって、深掘り度や観点などにバラつきがある  • 参加メンバー内で出来る解決策になりやすい  ◦ 開発チーム内でなんとかしようという意識が働く  ◦
他チームの課題があったとしても、自分たちに出来ることの範囲で考える  • 上記のような課題を生成AIのレビューにより指摘するという試み  • 生成AIモデルとして適しているものを探るためNotebookLM、CosenseのAI機能で実施して比較 

生成AIの活用  61 プロンプトとしてインプットした内容①  • 深掘りや十分な議論が行われたかの分析観点  ◦ 障害の原因がどの工程（要件定義/設計/実装）で混入したか  ◦ 障害はどの工程（コードレビュー/開発者テスト/受入テスト）で検出されるべきだったか  ◦
障害対応プロセスの各期間（発生から検知まで/検知から応急対応/根本対応）における課題があったか  ◦ 原因に対するネクストアクションが決定されているか  ◦ ポストモーテムとして振り返るべき点に過不足がないか 

生成AIの活用  62 プロンプトとしてインプットした内容②  • 参加者以外の観点が必要だったかの分析観点  ◦ 以下の4種の職務を設定し、それぞれの観点でのレビューを指示  ▪ 開発エンジニア  •
自動化や効率化などの指摘を期待  ▪ 開発エンジニアリーダー  • チームの習慣や具体的なプロセス観点の指摘を期待  ▪ プロダクトマネージャ  • 要件定義や市場分析、ユースケース定義などに関する指摘を期待  ▪ エンジニアリングマネージャ  • チーム間の連携、エンジニア育成、組織的な課題に関する指摘を期待 

生成AIの活用  63 生成AIからの指摘  ◦ まだ記載内容の要約に止まっている  ◦ 深掘りにはプロンプトチューニングやコンテキストの強化がまだ必要  ◦ 要約をマネージャーが見て、深掘りが十分かのレビューをするには有効   
今後の予定としては、  • Cosenseのデータを活用してコンテキストを充実させることも試していきたい  • また、大量の件数をインプットした場合の分析の精度なども見ていきたい 

生成AIの活用  64 • ポストモーテム分析の目的  ◦ ポストモーテムにおける分析に多角的な観点を追加し、学びの精度を上げる    • 活用できるメトリクス  ◦
Issue化数  ◦ 障害発生件数    ※ 現在はまだ検証中の段階 

生成AIの活用  65 2-3-2. 業務への活用からプロダクトへの活用 

生成AIの活用  66 https://speakerdeck.com/visional_engineering_and_design/shibuya-ai-1   prAlie-dog  プレーリードッグプロジェクト 

生成AIの活用  67 業務への活用からプロダクトへの活用  • prAlie-dog（プレーリードッグ）プロジェクト  ◦ 業務に特化した生成AIアプリケーションを Slack のワークフローやチャットボットとして実装  ◦
低コストで生成AIを業務フローに取り入れることが可能  ◦ 社内ニーズをトリガーとしているので、検証リソースや利用促進、展開のコストも抑えられる  ◦ うまく行ったものをお客様への提供にまで繋げられているものもある（求人自動生成）  ◦ 20以上のプロジェクトが進行中  ◦ SlackでCosenseに蓄積されたデータを参照するのもこのプロジェクトの一環         

生成AIの活用  68 業務への活用からプロダクトへの活用  • prAlie-dog（プレーリードッグ）プロジェクト    引用：ビジョナル株式会社「2025年7月期第3四半期決算説明資料」  

生成AIの活用  69 生成AI関連の特許数では日本で1位  引用：ビジョナル株式会社「2025年7月期第3四半期決算説明資料」 

SODA（SODA :Software Outcome Delivery Architecture）による可視化  71 SODAとは・・・  開発組織を取り巻く様々な状況をメトリクスとして可視化し、それを元に意思決定をしていくフレームワーク     
 

Software Outcome Delivery Architecture(SODA): BizReach ver.  72

SODA Journey  https://speakerdeck.com/takabow/devopsdays-tokyo2022-huakutokarashi-merug ai-shan-apuroti-leantodevopsfalseke-xue-woshi-jian-site https://speakerdeck.com/visional_engineering_and_design/number-rsgt2023 https://speakerdeck.com/visional_engineering_and_design/developer-experienc e-day-2023 https://speakerdeck.com/visional_engineering_and_design/devopsdaystokyo-20 23 https://speakerdeck.com/visional_engineering_and_design/jasst24-tokyo
2022-4-21 DevOpsDaysTokyo 2022 2023-1-11 Regional Scrum Gathering Tokyo 2023 2023-4-18 DevOpsDaysTokyo 2023 2023-6-14 Developer eXperience Day 2023 2024-3-14 JaSST'24 Tokyo 77 https://speakerdeck.com/visional_engineering_and_design/dev-productivity-con2 024 2024-6-29 開発生産性 Conference 2024

SODAによる可視化  78 a. 技術的負債解消と機能追加のバランス  b. 開発パフォーマンスのモニタリング  2-3-4. SODAによる可視化 

生成AIの活用  79 a. 技術的負債解消と機能追加のバランス  2-3-4. SODAによる可視化 

SODAによる可視化  80 バランスの意思決定にはレベルがある    ◦ 組織構成（部室長）  ▪ リアーキを進めるチームとグロースを進めるチームを分ける  ▪ チーム組成にバランスの意思をこめる 
  ◦ プロジェクト優先度（PO/MGR）  ▪ 機能追加と同様に負債解消をプロジェクト化して優先度決め  ▪ バックログの実施優先度にバランスの意思を込める    ◦ 作業割合（メンバー）  ▪ リファクタ  ▪ 日々の開発作業の中で必要なものを実施   

SODAによる可視化  81 技術投資・費用をモニタリング  ◦ ビズリーチでは工数の実績でモニタリング  ◦ CrowdLogを使って工数を集計  ◦ プロジェクトを分類するカテゴリーを以下のように定義  ▪
大分類  • 費用 / 投資  ▪ 中分類  • 短期戦略、中長期戦略、人材戦略、保守・運用  ▪ 小分類  • グロース施策、リアーキ施策、開発生産性向上、採用、育成、運用、障害対応、など 

SODAによる可視化  82 技術投資費用のモニタリング 

SODAによる可視化  83 技術投資費用のモニタリング  • モニタリングするポイントとしては  ◦ 大項目、中項目、小項目のバランスが意思決定した範囲内にあるか  ▪ 特にリアーキや基盤整備への投資が意思決定した範囲で推移しているか  •
現在のフェーズを鑑みたリアーキとグロースのリバランスなども実施  （グロースへの投資を強化する、など）  ◦ 時系列の変化  ▪ 改善系で効果の出現に時間がかかるものの推移  ▪ 障害対応の割合など  • 今後はエラーバジェットのような運用を目指したい 

SODAによる可視化  84 技術的負債解消と機能追加のバランスをどうするか  • 元CTO竹内真さんのブログ  ◦ https://note.com/singtacks/n/n4612d8256c7a       
  • SODA推進谷内栄樹のブログ  ◦ https://engineering.visional.inc/blog/666/soda-engineering-invest ment/   

生成AIの活用  85 b. 開発パフォーマンスのモニタリング  2-3-4. SODAによる可視化 

SODAによる可視化  86 • 技術的負債解消の施策で参考とするメトリクスはその目的とフェーズにより様々  • 目的はピン留めしつつ、フェーズによって参考にする指標を選んで活用するのが重要  • SODAは様々なメトリクスを可視化し、多角的な判断の助けとなることを目指している   

87 3.今後の展開 

開発生産性に対する取り組み今後の展開  88 • 技術的負債を蓄積させない仕組みの構築  ◦ コードやプロセスに対する負債解消施策を継続  ◦ 負債をコントロールするには文化や仕組みが重要  ▪
SLOやエラーバジェットの運用  ▪ 学びの効果最大化（ポストモーテムの効果最大化）    • 生成AIの活用  ◦ 開発プロセスのパラダイムシフト    • 信頼性の継続的向上  ◦ 信頼性の最適な状態定義  ◦ 継続的に向上できる状態を作り維持する  ▪ SLOやエラーバジェットの運用      こういった取り組みにおいても、メトリクスを活用した総合的な判断が可能な環境の整備を進める

4.まとめ  89

まとめ  技術的負債解消はビジネスインパクトを踏まえた優先度で  本来の目的をピン留めしたメトリクス活用が大事  90 生成AI活用のような探索フェーズではまずやってみる事が重要  • ビジネスインパクトが大きい部分のアウトプットを上げていくとROIが高くなる 
• 技術的負債解消の意義の証明という効果も   • AI活用のような探索フェーズでは身近な定性メトリクスを参考にまずやってみることが重要   • 取り組みを共有する仕組みも大事   • 定性、定量含め効果を測るのにメトリクスを参考にするのは重要   • 本来の目的に近づいてるか、多角的な観点で判断できるとよい  

91 BlogとXで発信中！  Blog https://engineering.visional.inc/blo g/ Visionalグループで働くエンジニアの技術的な取り組みや、イベント・登壇情報などをお届けします。   X @VISIONAL_ENG

ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-...

ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript

ビズリーチが挑むメトリクスを活用した技術的負債の解消 / dev-productivity-...

ビズリーチが挑むメトリクスを活用した技術的負債の解消 / dev-productivity-con2025