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

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

外山大 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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

技術的負債が蓄積されると・・・  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/   

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

生成AIの活用  54

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

生成AIの活用  57

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

87 3.今後の展開 

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

4.まとめ  89

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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