ビズリーチにおけるリアーキテクティング実践事例 / JJUG CCC 2025 Spring

ビズリーチにおけるリアーキテクティング実践事例  ～大規模システムを継続的に変革するための組織 × アーキテクチャ戦略～    @JJUG CCC 2025 Spring
  株式会社ビズリーチ（Visionalグループ）  菊池信太郎  1

菊池信太郎    2012〜株式会社ニトリ  • 店舗 / 物流でトラブルシューティングしたり、現場の改善を回したり  
2014〜 SIer  • 受託開発やSESで複数プロジェクト経験   • テックリード・PM・EMとして開発経験を積む   2018〜株式会社ビズリーチ   • ビズリーチのtoBプロダクトを中心に開発   • EMとしてリアーキテクティングの推進、組織横断プロジェクトなどのリード   • 現在はプロダクト本部プラットフォーム統括部統括部長  2 自己紹介 

1. リアーキテクティングの背景と目的  2. プロダクトをどう変えるか  3. ビジネスを止めずにアーキテクチャを進化させる  4. 変更容易性とテスト容易性を高める  5. プロセスと組織を変える 
6. 今後の展望  3 目次 

4 即戦力人材と企業をつなぐ転職サイト「ビズリーチ」  C (会員の方) と B (直接採用企業様/ヘッドハンター様) へ  転職・採用プラットフォームを提供  引用：ビジョナル株式会社「2025年7月期
第2四半期決算説明資料」 

5 目指す姿：選択肢と可能性を最大化する「キャリアインフラ」  引用：ビジョナル株式会社「2025年7月期第2四半期決算説明資料」 

6 リアーキテクティングの背景と目的 

7 創業以来、サービス規模は右肩上がりに拡大  引用：ビジョナル株式会社「 2025年7月期第2四半期決算説明資料」  

8 ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う / JJUG CCC 2022 Fall - Speaker Deck 
技術的負債が積み重なり、開発生産性が低下（2018年頃）  JJUG CCC 2022 Fallでレガシーコードとの戦いについてお話しました。今回はその続編です。 

デリバリに過度なプレッシャー  • 事業が急成長していると、技術的負債を生んでしまう意思決定が起こりやすい  • QCDSのうちコスト、納期、スコープが固定されると品質が下がる  密結合で凝集度が低いプログラム構造が原因でテストが書きづらい  • プレゼンテーションロジックとドメインロジックがちゃんと分離されていない  • API呼び出しやDBアクセスなど副作用がドメインロジックと同じ場所にあった 
• 度重なる変更でスパゲッティ化したコードは何をやってるのかを読み解くのも一苦労  大規模プロジェクトを計画し、実行しきる組織力が不足  • 過去これまでに何度か技術的負債解消プロジェクトは立ち上がってはいた  • 短期間の課題解決能力は高いが、プロジェクトマネジメントの経験が浅い傾向があった  9 レガシーコードの生まれた原因分析 

10 現在進行系でプロダクトを改善中  引用：Betsy Beyer, Chris Jones, Jennifer Petoﬀ, Niall Richard
Murphy『SRE サイトリライアビリティエンジニアリング』（オライリー・ジャパン, 2017）  p.88「サービスの信頼性の階層」   

11 現在進行系でプロダクトを改善中  ①現状把握とプロセス整備から始め、緊急度の高いリスクは応急処置   ④段階的な内部品質改善   ②ポストモーテムを通じた継続的な改善サイクルの確立  
③自動化、プロセス、テスト、 QA の強化  引用：Betsy Beyer, Chris Jones, Jennifer Petoﬀ, Niall Richard Murphy『SRE サイトリライアビリティエンジニアリング』（オライリー・ジャパン, 2017）  p.88「サービスの信頼性の階層」 

現代のビジネス環境において、市場の変化に素早く対応し、継続的に価値を提供し続ける能力、  すなわち「アジリティ（Agility）」は、企業の競争力を左右する重要な要素  12 リアーキテクティングの目的はアジリティを獲得すること  引用：和田卓人氏が考える “自動テストの真の目的 ”とは？コスト削減ではなく「変化に対応する力」を得るためのベストプラクティス | ログミーBusiness 
（https://logmi.jp/main/technology/330970） 

アジリティを獲得し、開発スピードと信頼性を上げるために、4つの観点から整理  • 価値提供への集中  • 透明性・検査・適応  • 変化は機会  • 失敗からの学習  13
アジリティを獲得するために考えるべきこと  • 自動化による品質保証  • テスト駆動開発 (TDD)  • 継続的なリファクタリング  • 知識の共有と品質向上  • 柔軟なアーキテクチャ  • 自己組織化チームの組成  • 明確な役割と責任  • 心理的安全性の醸成  • ステークホルダーとの協調  • 学習する文化の支援  組織技術  • イテレーティブな開発  • 継続的なフィードバック  • フローの最適化  • 価値に基づく優先順位付け  プロセスマインドセット 

14 プロダクトをどう変えるか 

15 リアーキテクティング前のプロダクト構造  バックエンドは Java で出来ている巨大なモノリス   • commonという名の巨大なpackageが共有されており、全プロダクトが密結合  • 昔ながらのSSRがほとんどで、フロントエンドとバックエンドが密結合 
• 複雑なトランザクションスクリプトになっており、全般的にコードの凝集度が低い 

影響確認、コミュニケーションに時間がかかる  • 適切なモジュール分割がされていないので、オーナー不在になりがち  • なにか改善しようにも影響範囲が大きく、都度他のチームとコミュニケーションが発生する    変更、テストに時間がかかる  • テストが書きづらいこともあり、マニュアルテストを手厚くやらないと不安になる  •
JavaやSpringなどのバージョンアップをするにもかなり工数がかかる    ビルドに時間がかかる  • ちょっとした変更で広範囲にビルドが走る  • 組織拡大に伴い、ビルド時間が伸び続ける  16 発生していた問題の一例 

将来的にはマイクロサービスとしてさらに分割する可能性もあるが、まずは大きく切り出す  • Actorごとに開発組織も営業組織も分かれているため、会員、ヘッドハンター、採用企業は素直に分ける  • C向けプロダクトとB向けプロダクトをつなぐ採用コンテキストはいったんAPIとして大きく切り出し、必要に応じてモジュール分割していけるようにする  17 Bounded Context でモジュール分割 

APIを切り出した後、最終的にコンテキストごとにDBも分ける想定  （ただ、結構先の話になりそう + 場合によっては変わる可能性があるので、当面はAPIを分離しながらコードをきれいにしていくことを優先しています）  18 Bounded Context で組織、API、DBを分離 

「Explicitly deﬁne the context within which a model applies. Explicitly
set boundaries in terms of team organization, usage within speciﬁc parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don't be distracted or confused by issues outside.」  ― Eric Evans『Domain-Driven Design: Tackling Complexity in the Heart of Software』（Addison-Wesley Professional,2003）    モデルが適用されるコンテキストを明示的に定義する。チーム組織、アプリケーションの特定の部分における使用、コードベースやデータベーススキーマのような物理的な表現など、境界を明示的に設定します。これらの境界内ではモデルの一貫性を厳密に保ちますが、境界外の問題に惑わされたり混乱したりしないようにします。  19 参考：Bounded Context（境界づけられたコンテキスト）  引用：Martin Fowler「martinfowler.com,Bounded Context」（https://martinfowler.com/bliki/BoundedContext.html） 

うまく境界面を設定できている状態とは、非同期で業務機能間が結合されていること  • 境界面の切り方を間違えると、密結合な分散モノリスができあがる  • マイクロサービス化しても常に同期する必要があれば、可用性は低く、メリットが半減する  20 適切な境界面はどこか？ 

イベントストーミング、ドメインエキスパートとの対話などによってドメインモデルを手に入れる  • イベントストーミングは、非エンジニアも含め、ワークショップ形式でわいわいやる  • ドメインモデリングは設計・開発を通して、反復的に洗練させていく  21 業務機能を分割するには業務理解から 

22 「残」は業務分割の自然な切り口になりうる  「業務実行者の視点からは、残は業務を駆動し、業務の完了基準を提供し、業務を非同期／疎結合に分割するものとみえます。業務と帳簿を設計する人に対しては、残は、業務分割の自然な切り口を提供し、業務と帳簿を一体として分割するとともに、業務責任の線引きを明確にします。」    引用：杉本啓『データモデリングでドメインを駆動する ──分散／疎結合な基幹系システムに向けて』（技術評論社 ,2024） 

例：開発残としてのバックログ（書籍中の例から引用）  • 「仕様定義と開発という2つの活動の間にバックログがあって、両者を接続する」  • 「残は活動と活動の間に置かれたバッファー」  23 「残」は業務分割の自然な切り口になりうる  引用：杉本啓『データモデリングでドメインを駆動する ──分散／疎結合な基幹系システムに向けて』（技術評論社 ,2024） 

マイクロサービス化による疎結合化は非同期・結果整合性の許容とセット  • 全てAPIを同期的につないでいくと、疎結合化のメリットが薄れる  • 非同期に処理して、結果整合性の担保で問題ない場合は、トランザクションを分離したい  • エンティティの状態ではなく、ドメインイベントによって責務を分けることができる  24 「残」とイベント駆動でコンテキストをつなぐ  レジュメ更新 
<Event>  レジュメ審査残  審査完了  <Event>  審査完了通知  ステータス更新  レジュメ更新  審査 Context  会員  Context  レジュメ審査 

25 ビジネスを止めずにアーキテクチャを進化させる 

26 • 小さく書き直すことで、すぐに成果が出る   • 実際の成果を目にすれば安心するので、一気に書き換えるような時間的プレッシャーやストレスを回避できる   • 書き直して新しくなった機能は、モダンアーキテクチャで機能
改善を進めることができる   • お客様への公開が先になる場合は、フィーチャーフラグを使うことでリリースとデプロイを分離できる   ビッグバンリライトを避ける  ビッグバンリライト  • リリースされるまで書き換えの効果を享受できない   • 競合他社に何年もの先行を許すことになる   • 大規模になるほどリスクと不確実性が増し遅延する   • 遅延するほど、チームへのプレッシャーは大きくなる   • 再構築の結果、元よりもさらに悪くなる可能性がある     参考： Martin Fowler「Maarten’s Newsletter,The Explosive Nature of 'Big Bang' Rewrites」  (https://mdalmijn.com/p/the-explosive-nature-of-big-bang ）  段階的な書き直し  継続的にビジネス成長させるなら、原則ビッグバンリライトは避けるべき 

グロース開発を1年半止めて、ビッグバンリライトしたプロジェクト  • 旧プロダクトも並行稼働していたので、ユーザー側で切り替えることはできるようになっていた  • 事業としてのタイミング、営業やお客様との関係性など様々な条件が重なり、ビッグバンリライトでもそこまで問題にならなかったが、今思うとそれなりにリスクは存在していた（当時のEM談）  → 前述の通り、原則ビッグバンリライトはやめておいたほうが無難  27 事例：ヘッドハンター向けプロダクトリニューアル 
※ヘッドハンター様向けサービスの画面   【新】【旧】

その前に・・・  使われていない機能は、強い意思で削除しましょう 🗑  28 ビジネス価値の高いものから開発する 

ユーザーが毎日使う機能、各事業KPIに影響が大きい機能を計画段階で選定  • 候補者検索、スカウト送信  • レコメンド  • 会員登録導線  • AIによるレジュメ自動生成、求人自動生成  29
ビジネス価値の高いものから開発する 

「色んな所で細かい改善を打つのもよいのだが、結局の所はそのサービスに置いての「一番の大通り」に施策を打つのが最も効果が良いと言うのがメルカリでの施策を通して得た学びだ。」    「全ユーザの10%しか使っていない場所を2倍良くするよりも、95%のユーザが使っている場所を1.1倍改善するほうが遥かに結果が出やすい。」    引用：樫田光「グロースの逆説 : メルカリで分析とサービスグロースをやる前に知りたかったこと」
  (https://note.com/hik0107/n/n91e296a409a9)    30 「大通りを大事にしろ」 

ビジネス価値の高い機能から順番に開発して、段階リリース  • 画面別、機能別に新アーキテクチャへリプレイス  • デザイン負債にも課題があったため、リデザインも段階的に実施  • 各種KPIを毀損しないように、カナリアリリースで段階解放  31 事例：Cプロダクトのリアーキテクティング  リアーキと並行でリデザインも段階的に実施 
カナリアリリースで数値検証しながら段階解放 

フロントエンドの技術的負債もデザイン負債も両方解決したい…  • せっかく新しいアーキテクチャでフロントエンドを書き直すのだからデザインも情報設計も変えたい  • しかし、統一の取れていないデザインを段階的にリリースはできない  • ビッグバンリライトもしたくない  32 デザイン負債を抱えているプロダクトの改善アプローチ 

33 実際にCプロダクト / 採用企業向けプロダクトで実践したアプローチ  1. 新デザインの企画  2. 既存プロダクト全体へ最低限の変更で新デザインを適用  3. 表層デザイン・情報設計を再構成し、新しいアーキテクチャで実装してリリース 
（グロナビの配置など、場合によってはCSSの適用難度が高い。弊社は力技でなんとかしました😇）  デザイン負債を抱えているプロダクトの改善アプローチ 

検索チームを作り、検索APIをマイクロサービス化することにより、事業インパクトを生み出すことができた  • 検索アーキテクチャが刷新され、A/Bテストなどの検証サイクルを通して、改善が加速  • リアーキテクティングから始めたが、現在はグロースやR&Dなどにも取り組む  データ鮮度の悪化、頻発する同期漏れ、障害復旧に時間がかかるなどの問題が解決され、信頼性指標が大幅改善   34 事例：検索基盤の刷新 
高速にPDCAサイクルを回せる検索基盤へ Indexing処理のパフォーマンス大幅改善

AIや検索の重要性が事業成長にとって増してきたと同時にデータ品質の課題にも取り組み中  もともと全社データ分析基盤としてBigQueryを整備してきたが、AIや検索の精度を改善していくため、より質の高いデータを提供できるように構築  35 事例：プロダクトデータ基盤の構築 

36 変更容易性とテスト容易性を高める 

DDDと一緒に語られることが多いが、ソフトウェアの設計パターンであり、関心事を分離することでテストが書きやすくなる。  • レイヤードアーキテクチャ：関心事の分離とシステムの構造化  • ドメインモデル：ビジネスロジックの中核を表現する  • 集約とリポジトリパターン：データアクセス層を抽象化  37 変更容易性とテスト容易性を高める設計パターンの採用 

リアーキテクティング後は、70-95％のテストカバレッジを保っている  • Codecovでカバレッジを可視化  • チームごとにカバレッジ目標を設定  • カバレッジが高い ≠ 品質が高いなので、100%は必要ない  •
Googleによると  ◦ 60%：「許容できる」  ◦ 75%：「賞賛に値する」  ◦ 90%：「模範的」  38 テストカバレッジは「品質の出発点」 

リアーキテクティングの中でテストのあり方も変えていく必要がある  39 テストピラミッドの段階的実現  引用：「Move Fast & Don't Break Things 」―
Google Test Automation Conference 2014  （https://docs.google.com/presentation/d/15gNk21rjer3xo-b1ZqyQVGebOp_aPvHU3YH7YnOMxtE/edit?slide=id.g3f5c82004_8611#slide=id.g3f5c82004_8611） 

40 テストピラミッドの段階的実現  引用：テストサイズで再考する「テストピラミッド」 Googleが提唱する効率的な自動テスト戦略 | ログミーBusiness  （https://logmi.jp/main/technology/330972） 

改善前  E2Eテストもユニットテストも不足しているところからのスタート  →アイスクリームコーンですらない（！）    リリースプロセス改善  デプロイ頻度を上げるため、もともと実施していた手動シナリオテスト（E2Eテスト）を自動化  →アイスクリームコーンの形に    現在  リアーキテクティングにより、各プロダクトでテストが整備されつつある 
  今後  Small / Medium テストを増やし、Large テストを最小限に減らし、テストピラミッドへ！  41 アイスクリームコーンからピラミッドへ段階的に移行 

42 プロセスと組織を変える 

アジリティを獲得するために考えるべきこと  • 自動化による品質保証  • テスト駆動開発 (TDD)  • 継続的なリファクタリング  • 知識の共有と品質向上  • 柔軟なアーキテクチャ  • 自己組織化チームの組成  • 明確な役割と責任  • 心理的安全性の醸成  • ステークホルダーとの協調  • 学習する文化の支援  組織  技術  • イテレーティブな開発  • 継続的なフィードバック  • フローの最適化  • 価値に基づく優先順位付け  プロセス  マインドセット  再掲 

ユーザーストーリーマッピング、業務フローでプロダクトの全体像を可視化する  • 初期要件を整理する際、ユーザーストーリーマッピングを書く  • ユーザーの行動を時系列で洗い出し、整理することで、プロダクトの全体像をつかみやすくなる  • 業務フローを可視化し、ステークホルダーとすり合わせる  • プロダクトバックログの洗い出しがしやすくなり、開発順序や優先順位を定められる  45
プロダクト価値を可視化し、価値に基づく優先順位付け 

47 「どんな悪いことが起こりそうか」を考えるのではなく、「すでに悪いことが起こってしまった」という前提で考える    プレモーテムを実施する理由   • 「どんな悪いことが起こりそうか」を考える方法だと …  ◦ 自分たちの計画の欠点を見つけることと同義
  ◦ 欠点がない方が優れているという評価・価値観と相反する   ◦ 楽観的になる（都合の良い解釈をしてしまう）   • 「すでに悪いことが起こってしまった」という前提で考えると …  ◦ 後知恵が使える  ◦ 原因を多く考えられた方が優秀   プレモーテム（死亡前死因分析）の実施 

48 開発チーム全員でQA 

49 AIを使って効率化する工夫も各所で生まれている 

• はじめはQAが主導していたが、今では開発チーム全員がテスト分析をできるようになる  • ペアプロ、モブプロによって、開発者全員がTerraformをさわれるようになる  • フロントエンドエンジニアがバックエンドのAPI開発にも染み出す  51 スキルの平準化を促進し、属人化を防ぐ 

ドメイン知識が検索・再利用できる状態を目指し、Cosense（旧：Scrapbox）でWikiを再構築  • 階層構造ではなく、リンクによって整理されるため、人が増えても破綻しない  • 索引を作るようにメンテナンスすることで、みんながよく使うページほど品質が高くなる仕組み  • 議事録、プロダクト仕様、調査、相談、思考メモなどを全てCosenseで書き始めた  • 関連ページをまとめたSmart Contextをexportする機能も追加され、LLMとの親和性も高い 
→NotebookLMやClaudeに参照させて使うことができる  52 ナレッジマネジメントの実践  引用： https://scrapbox.io/support-doc-jp/Cosense_基本の３つの動作 

53 チームで学習する文化が自律的に育まれている 

54 今後の展望 

特にモジュール分割を進める中で直面している課題  • システム構成が複雑化し、システムの依存関係を全て知るのが難しくなっている  ◦ Backstageなどで、システムコンポーネントの情報を全て集約し可視化する  ◦ そろそろPlatform Engineeringチームが欲しくなってきている  • モジュール間・チーム間のインタラクションが発生し、認識齟齬が起こる 
◦ 将来像や設計方針を言語化し、共有する  ◦ SLOを整備し、エラーバジェット運用などで障害発生時の判断をシステム化する  55 アーキテクチャを進化させる中で生まれた新たな課題 

• AIコーディングツールで開発は加速する（している）  • 要求・要件を言語化し、リファレンス実装もある「あとはやるだけ」の作業はすでに『Claude Code』や『Devin』で実装できてしまう  • 普段の開発もAI活用は進み始めているが、さらに大規模なリライトなども今後検証予定  56 AIによるリアーキテクティングの加速 
https://www.anthropic.com/claude-code  https://www.cursor.com/ja 

• Bounded Context（境界づけられたコンテキスト）で分割するのは、人間にとって認知負荷が下がり嬉しいが、AI にとってもコンテキストウィンドウ（モデルが一度に考慮または記憶できるトークン単位のテキスト量）が存在するため、嬉しいものになる  • これまでアジリティを獲得するために、変更容易性・テスト容易性を高めたり、テストピラミッドの実現を目指してきたが、AIコーディングツールの登場によって、これまで以上に開発の加速に耐えられるような開発環境を整えられるかどうかで圧倒的な差ができてしまうのは容易に想像がつく  •
小さいチームで、AIと一緒に計画し、AIといくつかのモジュールを開発するようになると思うが、人間の認知能力がボトルネックになるので、Platform Engineering、ナレッジマネジメントなどへの投資も必須になってきそう  57 AIによる開発パラダイムシフト 

• ソフトウェアエンジニア  • エンジニアリングマネジャー  • QAエンジニア  • MLエンジニア  • MLOpsエンジニア 
58 各ポジション絶賛募集中！   https://hrmos.co/pages/hrmos/jobs/3100100100963/apply  カジュアル面談はこちらから Engineering Blog https://engineering.visional.inc/blog/ 

ビズリーチにおけるリアーキテクティング実践事例 / JJUG CCC 2025 Spring

ビズリーチにおけるリアーキテクティング実践事例 / JJUG CCC 2025 Spring

Visional Engineering ＆ Design

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript

ビズリーチにおけるリアーキテクティング実践事例  ～大規模システムを継続的に変革するための組織 × アーキテクチャ戦略～    @JJUG CCC 2025 Spring

菊池信太郎    2012〜株式会社ニトリ  • 店舗 / 物流でトラブルシューティングしたり、現場の改善を回したり

1. リアーキテクティングの背景と目的  2. プロダクトをどう変えるか  3. ビジネスを止めずにアーキテクチャを進化させる  4. 変更容易性とテスト容易性を高める  5. プロセスと組織を変える

4 即戦力人材と企業をつなぐ転職サイト「ビズリーチ」  C (会員の方) と B (直接採用企業様/ヘッドハンター様) へ  転職・採用プラットフォームを提供  引用：ビジョナル株式会社「2025年7月期

5 目指す姿：選択肢と可能性を最大化する「キャリアインフラ」  引用：ビジョナル株式会社「2025年7月期第2四半期決算説明資料」

6 リアーキテクティングの背景と目的

7 創業以来、サービス規模は右肩上がりに拡大  引用：ビジョナル株式会社「 2025年7月期第2四半期決算説明資料」

8 ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う / JJUG CCC 2022 Fall - Speaker Deck

10 現在進行系でプロダクトを改善中  引用：Betsy Beyer, Chris Jones, Jennifer Petoﬀ, Niall Richard

11 現在進行系でプロダクトを改善中  ①現状把握とプロセス整備から始め、緊急度の高いリスクは応急処置   ④段階的な内部品質改善   ②ポストモーテムを通じた継続的な改善サイクルの確立

アジリティを獲得し、開発スピードと信頼性を上げるために、4つの観点から整理  • 価値提供への集中  • 透明性・検査・適応  • 変化は機会  • 失敗からの学習  13

14 プロダクトをどう変えるか

「Explicitly deﬁne the context within which a model applies. Explicitly

25 ビジネスを止めずにアーキテクチャを進化させる

その前に・・・  使われていない機能は、強い意思で削除しましょう 🗑  28 ビジネス価値の高いものから開発する

ユーザーが毎日使う機能、各事業KPIに影響が大きい機能を計画段階で選定  • 候補者検索、スカウト送信  • レコメンド  • 会員登録導線  • AIによるレジュメ自動生成、求人自動生成  29

36 変更容易性とテスト容易性を高める

リアーキテクティング後は、70-95％のテストカバレッジを保っている  • Codecovでカバレッジを可視化  • チームごとにカバレッジ目標を設定  • カバレッジが高い ≠ 品質が高いなので、100%は必要ない  •

リアーキテクティングの中でテストのあり方も変えていく必要がある  39 テストピラミッドの段階的実現  引用：「Move Fast & Don't Break Things 」―

40 テストピラミッドの段階的実現  引用：テストサイズで再考する「テストピラミッド」 Googleが提唱する効率的な自動テスト戦略 | ログミーBusiness  （https://logmi.jp/main/technology/330972）

42 プロセスと組織を変える

アジリティを獲得し、開発スピードと信頼性を上げるために、4つの観点から整理  • 価値提供への集中  • 透明性・検査・適応  • 変化は機会  • 失敗からの学習  43

アジリティを獲得し、開発スピードと信頼性を上げるために、4つの観点から整理  • 価値提供への集中  • 透明性・検査・適応  • 変化は機会  • 失敗からの学習  44

アジリティを獲得し、開発スピードと信頼性を上げるために、4つの観点から整理  • 価値提供への集中  • 透明性・検査・適応  • 変化は機会  • 失敗からの学習  46

48 開発チーム全員でQA

49 AIを使って効率化する工夫も各所で生まれている

アジリティを獲得し、開発スピードと信頼性を上げるために、4つの観点から整理  • 価値提供への集中  • 透明性・検査・適応  • 変化は機会  • 失敗からの学習  50

53 チームで学習する文化が自律的に育まれている

54 今後の展望

• ソフトウェアエンジニア  • エンジニアリングマネジャー  • QAエンジニア  • MLエンジニア  • MLOpsエンジニア

59