リアーキテクティングのその先へ〜品質と開発生産性の壁を越えるプラットフォーム戦略〜 / architecture-con2025

リアーキテクティングのその先へ  〜品質と開発生産性の壁を越えるプラットフォーム戦略〜    @アーキテクチャカンファレンス 2025   株式会社ビズリーチ（Visionalグループ）  西山　創   1

リアーキテクティングのその先へ　〜品質と開発生産性の壁を越えるプラットフォーム戦略〜  2 自己紹介  株式会社ビズリーチ  プロダクト本部　プラットフォーム統括部アーキテクトG (兼検索基盤G)  西山創
Hajime Nishiyama  2006  SIer  基幹システムを中心としたシステムの提案から開発・運用まで経験。   2011  株式会社ビズリーチ   オンプレからAWSへの大規模リニューアルを担当。その後スタンバイ(求人検索エンジン)の新規開発からJV化までを牽引。  2020  株式会社スタンバイ   EMとしてプロダクト組織全体の制度設計を実施。 SREグループの組成、SLOの導入を進める。  2021  トラボックス株式会社   エンジニアとして新規SaaSの開発。サービスのフロントエンド FWの刷新を実施。  2023 - 現在  株式会社ビズリーチ   テックリードとして企業向け候補者検索機能の API化、インデクサーのリニューアルを推進。  現在はアーキテクトとしてプラットフォーム統括部の全体を担当。  

リアーキテクティングのその先へ　〜品質と開発生産性の壁を越えるプラットフォーム戦略〜  • 「ビズリーチ」の紹介  • これまでのリアーキテクティング  • リアーキテクティングの組織構造  • 新たな課題  •
プラットフォームエンジニアリングの現状と戦略  • 今後の展望  3 目次 

4 「ビズリーチ」の紹介 

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

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

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

8 これまでのリアーキテクティング 

これまでのリアーキテクティング  9 ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う / JJUG CCC 2022 Fall - Speaker
Deck  技術的負債が積み重なり、開発生産性が低下（2018年頃） 

これまでのリアーキテクティング  10 ビズリーチにおけるリアーキテクティング実践事例 / JJUG CCC 2025 Spring - Speaker
Deck  現在も継続してリアーキテクティングを進行中。  リアーキテクティングの実践事例の紹介（~2025年） 

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

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

これまでのリアーキテクティング  APIを切り出した後、最終的にコンテキストごとにDBも分ける想定  （ただ、結構先の話になりそう + 場合によっては変わる可能性があるので、当面はAPIを分離しながらコードをきれいにしていくことを優先しています）  13 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）    モデルが適用されるコンテキストを明示的に定義する。    チーム組織、アプリケーションの特定の部分における使用、コードベースやデータベーススキーマのような物理的な表現など、境界を明示的に設定します。    これらの境界内ではモデルの一貫性を厳密に保ちますが、境界外の問題に惑わされたり混乱したりしないようにします。  14 引用：Martin Fowler「martinfowler.com,Bounded Context」（https://martinfowler.com/bliki/BoundedContext.html）  参考：Bounded Context（境界づけられたコンテキスト） 

15 リアーキテクティングにおける組織構造の変遷 

リアーキテクティングの組織構造  16 ストリーム  アラインドチーム  コンプリケイテッド・  サブシステムチーム  コラボレーション    イネイブリング
チーム  ファシリテーション  プラットフォームチーム  X-as-a-Service  チームトポロジー 

リアーキテクティングの組織構造  17 チームタイプ    ストリームアラインドチーム   ビジネスの主な変更フロー (ストリーム)に沿う。職能横断型で他のチームを待たずにデリバリーする。中心となるチームで他のチームはストリームアラインドチームの負荷を減らすために存在する。
    プラットフォームチーム  インフラ、ツール、共通サービスなどの内部サービスをセルフサービスとしてプラットフォームチームに提供する。     イネーブリングチーム  他のチームが新技術やスキルを身につけるのを支援する。     コンプリケイテッド・サブシステムチーム   ストリームチームの認知負荷を下げるために、複雑なサブシステムやコンポーネント(専門家が必要な領域など )を扱う。  インタラクションモード     コラボレーション  2つのチームが探索を目的に協力しあう。効率は悪いが学習は進む。     X-as-a-Service  他チームが提供したものを利用する。     ファシリテーション  新しい技術や学習を支援する。他のチームの障害を取り除く。   チームタイプ/インタラクションモード 

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

リアーキテクティングの組織構造  事例1: 検索基盤刷新におけるチームインタラクションの変遷  19 プロダクト開発G  プロダクト  Indexer  検索基盤G  Elasticsearch  検索API導入の例 
初期段階=検索機能を専門チームが運用  ストリームアラインドチーム  コンプリケイテッド・サブシステムチーム 

リアーキテクティングの組織構造  プロダクト開発G  事例1: 検索基盤刷新におけるチームインタラクションの変遷    20 Indexer  検索API  検索API導入の例  API開発〜API導入=検索基盤GがプロダクトにAPI組み込み 
参照先の切替PJ  検索基盤G  コラボレーション  プロダクト  Elasticsearch  ストリームアラインドチーム  コンプリケイテッド・サブシステムチーム  コラボレーション 

リアーキテクティングの組織構造  事例1: 検索基盤刷新におけるチームインタラクションの変遷    21 プロダクト  Indexer  検索API  検索API導入の例  API提供後=インターフェースを通じて検索ドメインを提供 
検索基盤G  プロダクト開発G  Elasticsearch  ストリームアラインドチーム  コンプリケイテッド・サブシステムチーム  X-as-a-Service 

リアーキテクティングの組織構造  事例1: 検索基盤刷新におけるチームインタラクションの変遷    22 プロダクト  Indexer  検索API  検索API導入の例  検索品質(検索に特化したKPI)を改善することで事業貢献を行う 
検索基盤G  プロダクト開発G  Elasticsearch  ストリームアラインドチーム  X-as-a-Service 

リアーキテクティングの組織構造  事例1: 検索基盤刷新におけるチームインタラクションの変遷 23 プロダクト Indexer 検索API 検索API導入の例プロダクトから見たらプラットフォーム検索基盤G 
プロダクト開発G Elasticsearch  検索基盤G プラットフォームチーム X-as-a-Service

リアーキテクティングの組織構造  開発チーム  開発チーム  事例2: QAスキルの平準化  24 事例2: QAスキルの平準化の例  QAチームがプロダクトの品質チェック、テストを実施(スプリットQA)  プロダクト 
QAチーム  コラボレーション  コラボレーション  QA  リリース  ストリームアラインドチーム  コンプリケイテッド・サブシステムチーム  コラボレーション 

リアーキテクティングの組織構造  開発チーム  開発チーム  QAチーム  事例2: QAスキルの平準化  25 事例2: QAスキルの平準化の例  QAチームがプロダクトの品質チェック、テストを実施(インプロセスQA) 
ファシリテーション  ファシリテーション  プロダクト  QA  リリース  ストリームアラインドチーム  イネーブリングチーム  ファシリテーション 

リアーキテクティングの組織構造  開発チーム  事例2: QAスキルの平準化  26 事例2: QAスキルの平準化の例  +αとしてValueStreamに沿っていることを保証するプロダクトとしてのE2E  プロダクト  QA 
リリース  開発チーム  システム横断G  E2Eシナリオ  作成  Dev  QA  Dev  Dev  QA  Dev  ストリームアラインドチーム  X-as-a-Service 

27 新たな課題 

新たな課題  「ビズリーチ」の事業領域と組織図との関係  28 レジュメ登録  ログイン  スカウト受信  ・  応募  母集団形成  スカウト送信 
求人作成  (※)  返信  ・  書類通過  面接  採用決定  個  人  企  業  ・  ヘ  ッ  ド  ハ  ン  タ  ー  採用プラットフォーム   企業様向けプロダクト   ヘッドハンター様向けプロダクト   求職者様向けプロダクト  

新たな課題  リアーキテクティングを進めた現在の組織図  29 プロダクト開発  サービス開発 A  サービス開発 B  サービス開発 C 
サービス開発 X  データプロダクト  AIプラットフォーム  データ基盤  検索グロース  AIプロダクト  プラットフォーム  API 開発 a  SRE  システム横断  API 開発 b  DBRE  ID基盤G  API 開発 x  API 開発   検索プラットフォーム 

新たな課題  開発速度重視でチームを組成したことで、チーム数・サービス数を増加させることが出来た。  30 チーム内で価値提供できるよう体制  • (フロントエンド)  • バックエンド  • インフラ 
• DevOps  • (QA)  • (スクラムマスター)  • (PdM)    ※()内はチームによって存在しない。  プロダクト開発  サービス開発 A  サービス開発 B  サービス開発 C  サービス開発 X  データプロダクト  AIプラットフォーム  データ基盤  検索グロース  AIプロダクト  プラットフォーム  API 開発 a  SRE  システム横断  API 開発 b  DBRE  ID基盤G  API 開発 x  API 開発   検索プラットフォーム 

新たな課題  新規開発のAPIはAWSアカウントを分離することで身軽に開発。  プロダクトサービスのインフラはSRE グループがクラウドインフラの管理を担当。  APIサービスのインフラは開発チーム間でインフラを共同管理。  データプロダクト  プラットフォーム 
インフラ管理をプロダクト・プラットフォームで独立  31 プロダクト開発  サービス開発 A  サービス開発 B  サービス開発 C  サービス開発 X  AIプラットフォーム  データ基盤  検索グロース  AIプロダクト  API 開発 a  SRE  システム横断  API 開発 b  DBRE  ID基盤G  API 開発 x  API 開発   検索プラットフォーム  　アカウントA  　アカウントB 

新たな課題  チーム状況やコンテキストによってマイクロモノリスや単一レポジトリを採用。  チームの成長とチームの分割が有機的に行われた結果の判断。  データプロダクト  プラットフォーム  リポジトリはマイクロモノリスやモノレポを採用  32
プロダクト開発  サービス開発 A  サービス開発 B  サービス開発 C  サービス開発 X  AIプラットフォーム  データ基盤  検索グロース  AIプロダクト  API 開発 a  SRE  システム横断  API 開発 b  DBRE  ID基盤G  API 開発 x  API 開発   検索プラットフォーム  既存サービスは巨大なモノレポ   　単一レポ  　単一レポ    マイクロモノリス  

新たな課題  • プロダクトとプラットフォームどちらで機能実装すべきかなどは議論途中の箇所もある。    データプロダクト  プラットフォーム  システム構成が複雑化  33
プロダクト開発  サービス開発 A  サービス開発 B  サービス開発 C  サービス開発 X  AIプラットフォーム  データ基盤  検索グロース  AIプロダクト  API 開発 a  SRE  システム横断  API 開発 b  DBRE  ID基盤G  API 開発 x  API 開発   検索プラットフォーム 

新たな課題  課題を分類すると3つ  34 品質  生産性  ガバナンス 

新たな課題  課題の分類：品質  35 品質  生産性  ガバナンス 

新たな課題  36 • 各プロセスのリクエストログを紐づけてみるのが難しい  • 一貫したトレースが難しい  可観測性の低下  プロダクト  バックエンド 
採用コンテキスト  API-1  AIグループ  API-2  ログ  ログ  ログ 

新たな課題  37 カスケード障害発生回数の増加  • 内部APIの失敗がFrontendまで伝播。  信頼性の低下  プロダクト  バックエンド  採用コンテキスト 
API-1  AIグループ  API-2  プロダクト  バックエンド  プロダクト  バックエンド  ここで障害が起きると  全プロダクトに影響する 

新たな課題  38 • 共有DBがSPOF  • 一部システムによる負荷増加が他システムへ影響  ※過渡期により複数システムで余分なクエリーが実行されている影響もある。 
信頼性の低下  プロダクト  バックエンド  採用コンテキスト  API-1  AIグループ  API-2  プロダクト  バックエンド  プロダクト  バックエンド  CPU, メモリ, IO, コネクションの  リソース競合 

新たな課題  39 • 登録処理がDBへの Insert→APIのPUTに変更されたことで重複登録リスクが発生。  信頼性の低下  プロダクト  バックエンド  採用コンテキスト 
API-1  通信障害等で  リクエストは到達するが  レスポンスが帰ってこなかった場合  リトライ機構により  同じデータが二重登録 

新たな課題  40 信頼性低下に対する対応策  耐障害性に対する対応  二重登録に対する対応  DB負荷 (過渡期による課題)  サーキットブレーカーの導入  • クライアントアプリケーション
にサーキットブレーカー機能を追加  • 機能的には500だが、バックエンドAPIの二次災害を防ぐ目的  Idempotencyヘッダーの導入  • RFC: draft-ietf-httpapi-idemp otency-key-header  • APIによる機能集約→DBの分割を予定  • 用途に合わせた Read−Replicaを用意 

新たな課題  課題の分類：生産性  41 品質  生産性  ガバナンス 

新たな課題  42 • 開発チームごとのコードスタイル、設計方針の差異。  ◦ リポジトリ内に複数ルールが混在  • CIにかかる時間の増加 
◦ テストシナリオ数の増加    組織の拡大で発生した生産性の課題  /job  /progress  /search  リポジトリ間の差異  リポジトリ内の差異 

新たな課題  43 • 開発・テストの難易度上昇  ◦ mockの提供で効率化  組織の拡大で発生した生産性の課題  プロダクト  バックエンド  採用コンテキスト 
API-1  ローカルではmockを利用して開発、結合テスト  mockイメージを提供 

新たな課題  44 インターフェース変更の難易度上昇  • インターフェース駆動開発  組織の拡大で発生した生産性の課題  jar  生成  open api. 
yaml  jar  インターフェース  リポジトリ  プロダクト  バックエンド  採用コンテキスト  API-1 

新たな課題  45 障害対応の難易度上昇  • RunBookの準備。  • APIをまたいだエラー監視の導入  • ビジネス観点での監視の導入。 
• チームをまたいだ障害対応の避難訓練  • 事前の協力体制  組織の拡大で発生した生産性の課題  エンドポイントごとのエラー監視の導入 

新たな課題  組織の拡大で発生した生産性の課題  46 • リポジトリごとにCI/CDパイプラインを整備  ◦ デプロイするのはECSサービス。少しずつ違うパイプラインが生まれる。  ▪ ecs cli
vs ecspresso, Codebuild vs GithubWorkﬂow, コードの書き方  • インフラ環境構築のリードタイム増大  ◦ ECSサービスのサイドカーとして監視用コンテナ、ログ配信用コンテナを配置  ▪ イメージ管理、設定追加の対応コスト  ◦ DB等のミドルウェアは既存環境を再利用している  ▪ コネクション数の設定、接続の設定などのコミュニケーションコスト  • テスト環境のコンフリクト  ◦ マイクロモノリスで1サービスを提供している。  ▪ チームが増えたことでテスト用のAWS環境の利用に制限がかかる 

新たな課題  課題の分類：ガバナンス  47 品質  生産性  ガバナンス 

新たな課題  48 • システムの依存関係を知るのが難しい  • どのAPIがどのドメインを取り扱っているかの認識齟齬  • 機能開発するうえでの要件決定
時には一定の調整コストが発生。  • 過渡期なこともあり、完全にドメインが分割されていない。  課題: チーム間コミュニケーションの複雑さ上昇  データプロダクト  プラットフォーム  プロダクト開発  サービス開発 A  サービス開発 B  サービス開発 C  サービス開発 X  AIプラットフォーム  データ基盤  検索グロース  AIプロダクト  API 開発 a  SRE  システム横断  API 開発 b  DBRE  ID基盤G  API 開発 x  API 開発   検索プラットフォーム 

新たな課題  49 • チームのPdM同士で連携する PO会の開催でチームごとのロードマップの同期    対応: ビジネスモデルへの変更に対するチーム間の協力体制  データプロダクト 
プラットフォーム  プロダクト開発  サービス開発 A  サービス開発 B  サービス開発 C  サービス開発 X  AIプラットフォーム  データ基盤  検索グロース  AIプロダクト  API 開発 a  SRE  システム横断  API 開発 b  DBRE  ID基盤G  API 開発 x  API 開発   検索プラットフォーム  PO会  PJチーム 

新たな課題  50 • PJを作り一時的にコラボレーション    対応: 開発チームの協力体制  データプロダクト  プラットフォーム 
プロダクト開発  サービス開発 A  サービス開発 B  サービス開発 C  サービス開発 X  AIプラットフォーム  データ基盤  検索グロース  AIプロダクト  API 開発 a  SRE  システム横断  API 開発 b  DBRE  ID基盤G  API 開発 x  API 開発   検索プラットフォーム  PJチーム 

新たな課題  51 今後考えうるリスク  セキュリティ、  認証認可の必要性  脆弱性対応コスト  コンテナ運用コスト  アプリケーションごとの認証認可  ライブラリ、Dockerイメージは増加 
CI/CD、ルーティング、テスト環境の占有、監視、トレース 

52 プラットフォームエンジニアリングの現状 

プラットフォームエンジニアリングの現状  プラットフォームエンジニアリングとは？  53 • ソフトウェアの開発とデリバリを目的とした、セルフサービス型の開発者プラットフォームの構築と運用に関する専門分野。    • 目的  ◦
開発者の認知負荷軽減  ◦ 開発生産性の向上  ◦ サービス品質の向上  ◦ ガバナンス強化 

プラットフォームエンジニアリングの現状  ゴールデンパス  54 • 開発チームが最も効率的かつ安全にソフトウェアを開発・デプロイするための、推奨される一連の経路やツールセット。開発者が直面する偶発的な複雑性を排除し、本質的な課題に集中できる環境を構築したもの。  ◦ 開発者の選択肢の最適化: 多数存在するツールや技術の中から、組織のベストプラクティスに基
づいた最適な選択肢を提供。  ◦ オンボーディングの迅速化: 新しい開発者がプロジェクトにスムーズに合流できるよう、標準化された開発環境とプロセスを提供。  ◦ 品質とセキュリティの確保: 事前に定義されたセキュリティ基準や品質ガイドラインが組み込まれているため、高い品質と安全性を維持できる。  ◦ 継続的な改善の促進: プラットフォームチームがゴールデンパスを継続的に改善することで、開発体験全体が向上。 

プラットフォームエンジニアリングの現状  なぜいまプラットフォームエンジニアリングなのか？  55 • リアーキテクティングを進めたことで課題となるボトルネックが移りつつある。  ◦ 〜2025まではリアーキテクティングをすることが一番の目的(【JJUG_2022秋】ユーザー数100 万人規模の事業成長を止めずに、レガシーコードと戦う)  ◦ チーム数の増加、システム数の増加に伴い新たな課題が上がってきた。 

プラットフォームエンジニアリングの現状  チームファースト  56 ストリームアラインドチームが効果的に継続的に価値創出し続けるようにチームや組織を考える。  適切なサイズ  チームAPI  適切な認知負荷  ダンバー数  5人/15人/50人/150人 
チーム内外のプロトコル  ドキュメント/プロセス  扱える範囲のシステムやコンポーネントにフォーカス   

プラットフォームエンジニアリングの現状  認知負荷  57 • 認知負荷は3つに分類  ◦ 課題内在性認知負荷  ◦ 課題外在性認知負荷  ◦
学習関連負荷  • ワーキングメモリーより認知負荷が上回るとオーバーフローする。  • タスクや課題領域の種類が多くてもコンテキストスイッチにより非効率  課題内在性  認知負荷  課題外在性  認知負荷  学習関連負荷  ワーキングメモリー  新しい知識の  ための学習  問題領域の本質  不要な認知負荷  チーム分割  削減対象  価値創出 

プラットフォームエンジニアリングの現状  リアーキテクティングは言い換えれば認知負荷の軽減  58 • 境界づけられたコンテキストによる分割  ◦ 課題内在性負荷の分割  ◦ 複雑なビジネス領域を分割 
• システム刷新によるアーキテクチャのモダナイズ  ◦ 課題外在性負荷の軽減  ◦ レガシーコードの削減  ◦ 古いライブラリのメンテナンスコスト   

プラットフォームエンジニアリングの現状  ストリームアラインドチームの課題外在性認知負荷  59 • チームによって作業可能な技術領域の範囲が違う。  • 理想としてはデプロイ頻度、リリースリードタイムを落とさずにアプリケーションコードにのみ
フォーカスしたい  アプリケーション   コード  ログ  セキュリティ  監視  トレース  フレームワーク設定   プロジェクト設定  CI・CD  リポジトリ設定  コンテナの設定   データベース  インフラコード  etc… 

プラットフォームエンジニアリングの現状  品質の課題  • 分散トレーシングの導入   • 集中ログ管理システム   生産性の課題  •
APIテンプレート化  • ドキュメント整備  • CI/CDの標準・自動化  • 開発者ごとのテスト環境プロビジョニング   ガバナンス  • API、ドメインごとのウェブポータル   • プロビジョニングツール   • 認証認可基盤  • 静的解析、実行時解析   • サイドカー一元管理  60 課題とプラットフォームエンジニアリングの分類  https://tag-app-delivery.cncf.io/ja/wgs/platforms/whitepaper/ より図を引用 

プラットフォームエンジニアリングの現状  課題に対する対応例  61 課題に対する対応としては以下のようなことが考えられる  耐障害性に対する対応  • サービスメッシュ(envoy, istio)でサーキットブレーカーを提供  二重登録に対する対応  •
EDA(イベント駆動アーキテクチャ)をモジュールとして提供。AsyncAPIの導入  CI/CDのサイロ化  • GithubActionとして標準化やk8sの導入  サイドカーコンテナイメージの管理  • ロギング、モニタリングの標準イメージ提供に加えカスタマイズ機能を提供 

プラットフォームエンジニアリングの現状  62 プラットフォームエンジニアリングの成熟度モデル  特性暫定的である戦略的であるスケーラブルである最適化している投資プラットフォームの機能に対して、
人員と資金がどのように割り当てられているかボランティアまたは一時的専任チームプロダクト活発なエコシステム採用ユーザーはなぜ、どのようにして内部プラットフォームやその機能を発見し、利用しているか一貫していない外部からの動機づけ内発的な動機づけプロアクティブな参加インターフェースユーザーがどのようにしてプラットフォームの機能と対話し、利用しているか機能毎に独自の手順標準ツールセルフサービスのソリューション統合されたサービス戦略プラットフォームとその機能が、どのように計画され、優先順位がつけられ、開発され、維持されているかリクエストに応じて中央集権的な追跡中央集権的な支援マネージドサービス計測どのようなプロセスでフィードバックと学びを収集し、取り入れているか？アドホック一貫性を持った収集洞察の獲得定量的かつ定性的 https://tag-app-delivery.cncf.io/ja/wgs/platforms/maturity-model/v1/ より引用 

プラットフォームエンジニアリングの現状  63 組織に照らし合わせた成熟度の現状  特性    暫定的である  戦略的である  スケーラブルである   最適化している 
投資  プラットフォームの機能に対して、人員と資金がどのように割り当てられているか  ボランティアまたは一時的  専任チーム  プロダクト  活発なエコシステム  採用  ユーザーはなぜ、どのようにして内部プラットフォームやその機能を発見し、利用しているか   一貫していない  外部からの動機づけ  内発的な動機づけ  プロアクティブな参加  インターフェース  ユーザーがどのようにしてプラットフォームの機能と対話し、利用しているか  機能毎に独自の手順  標準ツール  セルフサービスのソリューション  統合されたサービス  戦略  プラットフォームとその機能が、どのように計画され、優先順位がつけられ、開発され、維持されているか  リクエストに応じて  中央集権的な追跡  中央集権的な支援  マネージドサービス  計測  どのようなプロセスでフィードバックと学びを収集し、取り入れているか？  アドホック  一貫性を持った収集  洞察の獲得  定量的かつ定性的  https://tag-app-delivery.cncf.io/ja/wgs/platforms/maturity-model/v1/ より引用 

プラットフォームエンジニアリングの現状  • SREグループはアラート通知、分散トレーシング、モニタリングの一元管理、提供  • APIはリポジトリを通してドキュメント、クライアントライブラリの提供  •
アーキテクトグループがアドホックにサポート  • スケーリング出来ていない。  • 組織的な動きはこれから  64 組織とプラットフォームエンジニアリングの現状  プロダクト開発  サービス開発 A  サービス開発 B  サービス開発 C  サービス開発 X  データプロダクト  AIプラットフォーム  データ基盤  検索グロース  AIプロダクト  プラットフォーム  API 開発 a  SRE  システム横断  API 開発 b  DBRE  ID基盤G  API 開発 x  API 開発   検索プラットフォーム  アーキテクト 

プラットフォームエンジニアリングの現状  65 戦略的にプラットフォームエンジニアリングを進めるフェーズ特性暫定的である戦略的であるスケーラブルである最適化している投資プラットフォームの機能に対して、
人員と資金がどのように割り当てられているかボランティアまたは一時的専任チームプロダクト活発なエコシステム採用ユーザーはなぜ、どのようにして内部プラットフォームやその機能を発見し、利用しているか一貫していない外部からの動機づけ内発的な動機づけプロアクティブな参加インターフェースユーザーがどのようにしてプラットフォームの機能と対話し、利用しているか機能毎に独自の手順標準ツールセルフサービスのソリューション統合されたサービス戦略プラットフォームとその機能が、どのように計画され、優先順位がつけられ、開発され、維持されているかリクエストに応じて中央集権的な追跡中央集権的な支援マネージドサービス計測どのようなプロセスでフィードバックと学びを収集し、取り入れているか？アドホック一貫性を持った収集洞察の獲得定量的かつ定性的 https://tag-app-delivery.cncf.io/ja/wgs/platforms/maturity-model/v1/ より引用

66 今後の展望 

今後の展望  • ストリームアラインドチームのデリバリーを最優先に考える  • 多くのチームに共通する課題外在性認知負荷を下げることが最優先  ◦ 最低限のプラットフォーム(TVP)  • 各チーム内のメンバーがボランティア的に活動している状況からチームによるサポート体制へ移行が必要 
67 チームファースト思考とプラットフォームエンジニアリング 

今後の展望  指標は生産性の向上(Four Keys)  • リードタイム  • デプロイ回数  • 障害発生率  •
障害復旧時間  68 プラットフォームエンジニアリングの適用箇所  課題外在性負荷の探索と解消  開発チームの  「未知」を「既知」に変える  • 既存仕様  • API  • アーキテクチャ  • ミドルウェア    • セットアップ  • フレームワーク  • ライブラリ  • CI  • CD  • モニタリング  • ロギング    • QA環境  • CI  • ライブラリ    リリース  QA  開発  設計 

今後の展望  リアーキテクティングのQA(リグレッションテスト)は難しい  • 暗黙的な仕様  • 過去のドキュメント不備  • 本番環境でのみ存在する、エッジケース 
• 検証環境とのデータ量の差による性能検証  • 複数のプロダクトが同時にリアーキテクティングしている  69 リアーキテクティングを加速させる為のプラットフォームエンジニアリング  旧プロダクト  新プロダクト  API  例: In/Outを抑えた検証環境の提供 

今後の展望  SlackでCosenseの情報を検索可能なAIエージェント(社内開発)  • 他チームに質問したり、有識者を探す手間がなくなった。  • オンボーディング初日からドメイン知識を自主学習可能  •
チームAPIとしての役割も    ※今後はより一層AIを活用した開発フローが促進される(SpecKitなど)    70 ナレッジマネジメントの実践 + AIの効果  https://speakerdeck.com/visional_engineering_and_design/jjug-ccc-2025-spring?slide=52   

今後の展望  • 課題外在性負荷は各チームは日々カイゼンしていることもある  • AIコーディングエージェントの登場で想像以上に開発はドライブしていく  • 人間の認知負荷が低い = AIのコンテキストが短い =
AIの精度が高くなる  • 課題外在性認知負荷を減らし、本質的な価値創造に注力できるかが生産性  ◦ これはAIを活用しても変わらない  • プラットフォームがなくても、各チームがAIエージェントを駆使して実装してしまう  ◦ モニタリング、ロギングなどのガバナンスが取れなくなるリスクが有る  • プラットフォームエンジニアリングそのものはAIエージェントで加速させることが可能  71 AIを活用したプラットフォームエンジニアリング戦略 

72 各ポジション絶賛募集中！ Engineering Blog プロダクト採用についてソフトウェアエンジニアエンジニアリングマネジャー QAエンジニア MLエンジニア MLOpsエンジニア
さまざまなポジションで募集しています。まずは気軽にカジュアル面談でお話ししましょう。 … 

リアーキテクティングのその先へ 〜品質と開発生産性の壁を越えるプラットフォーム戦略〜 / ar...

リアーキテクティングのその先へ 〜品質と開発生産性の壁を越えるプラットフォーム戦略〜 / architecture-con2025

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript

リアーキテクティングのその先へ〜品質と開発生産性の壁を越えるプラットフォーム戦略〜 / ar...

リアーキテクティングのその先へ〜品質と開発生産性の壁を越えるプラットフォーム戦略〜 / architecture-con2025