11月11日、Paul Constantinides、Anubhav Dhoot、Jackie Chambers de Freitasの3名が「How Salesforce Scaled Engineering AI Adoption Without Stifling Innovation」と題した記事を公開した。約500名のエンジニアを擁するSalesforceのHyperforce Runtime Platform（HRP）組織が、チームの自律性を損なわずにAI活用を組織全体へ展開した実践的なアプローチが詳述されている。
3ヶ月でサイクルタイムを半減——何が機能したか
AIツールの実験は多くの組織で起きている。問題は「チームごとの実験をどう組織全体のケイパビリティに昇華させるか」だ。SalesforceのHRP組織（約70〜80スクラムチーム、約500名）はこの問題に正面から向き合い、**わずか3ヶ月でAI採用率ほぼ100%**を達成した。
成果の数字は以下の通りだ：
- チームスループット 26%向上
- インナーループ効率 32%改善（インナーループ：ローカル開発環境内のコード編集・ビルド・テストのサイクル）
- サイクルタイムが22日→11日に半減
- スプリント完遂率が66%→90%に向上（コミットした優先事項の達成率、36%増）
- コードメンテナビリティスコアは6.04を維持（品質を落とさずに生産性向上を実現）
特筆すべきは、「Flight Plan」と呼ばれるPR作成・ゲーティングツールを導入した4人チームの事例だ。Flight Planは4つのエージェントで構成されており、それぞれ「計画立案」「実装」「検証」「レポート生成」の役割を分担している。歴史的なベロシティが約40ストーリーポイントだったチームが、約235ストーリーポイントにまで伸びた。さらに241件のマージ済みPRにおいて、199件の実際のバグをローカルで検出・修正（初回プッシュ前）、組織全体に換算すると年間約11万件の不要なデプロイ実行を削減できると推計している。
鍵は「フェデレーテッドモデル」と明確なオーナーシップ
多くのAI展開が失敗する原因は、所有権の曖昧さにある。誰がリリース品質に責任を持ち、誰がリリース後の運用を担うのかが不明確なまま、ツールだけが配布される。
HRP組織が採用したのはフェデレーテッドAI採用モデルだ。構造は以下の3層で構成される：
- AI Steering Committee：重複排除、ガバナンス、標準策定、採用メトリクスの管理。個別チームの開発には介入しない
- デリバリーチーム（各スクラムチーム）：自分たちの痛点から生まれたAIケイパビリティを、スクラムプロセスを通じて端から端まで責任を持って開発・運用する
- AI Champions：Steering CommitteeとスクラムチームをつなぐブリッジRole。週次でのデモ・トレーニング・フィードバック収集を担う
この仕組みで重要なのは「チームが自分たちの問題を解くために自発的に参加する」設計だ。ある時期には約30のAIワークストリームがボトムアップで特定され、各デリバリーチームが志願して担当した。トップダウンで押し付けた施策ではなく、既存の摩擦点から自然に生まれたという点が特徴的である。
HRPDXプラグイン：ツール配布の自動化
実験の成果が「チーム内に留まる」問題を解決するため、チームはHRPDXプラグインを整備した。これはAnthropicが提供するAIコーディングアシスタント「Claude Code」向けの共有プラグインであり、エンジニアは一度インストールするだけで、セッション開始時に自動更新される仕組みだ。Gitコンベンション、PR規約、Flight Planなどのスキルがこのプラグイン経由で全員に配布される。
結果として97%のプラグイン採用率を達成。SalesforceのAIコードレビューツール「Prizm」は95%の採用率に達した。一方、共有Claude命令ファイルの採用は遅れており、メトリクスを使ってギャップを特定・改善中だという。「配布できているか」と「実際に使われているか」を別々に計測する必要性を、このチームは強調している。
SDLCとDORAメトリクスで意思決定を駆動する
感覚ではなくデータで判断するために、チームは既存のデータパイプラインを活用してSDLCおよびDORAメトリクスを可視化した。DORAメトリクスとは、GoogleのDevOps Research and Assessment（DORA）チームが策定した業界標準の開発パフォーマンス指標群であり、Deployment Frequency、Lead Time for Changes、Change Failure Rate、Time to Resolutionの4指標で構成される。これらをスクラム・ポートフォリオの両レベルで計測・追跡している。
さらにClaudeスキルを使ってパイプラインをクエリし、チームの生産性・デリバリーメトリクスを統合したレポートを自動生成するしくみも構築している。3〜5月と6〜8月の比較により、採用前後の変化を定量的に把握できた。
コードレビュー・テスト・デプロイへの拡張
ローカル開発の効率が上がると、次のボトルネックはPRレビューサイクルに移った。コードを速く書けても、他チームのレビュー待ちで詰まる。この問題に対してチームは、チーム固有のPrizmスキルを開発してアンチパターンの検出とシニアレビュー相当のフィードバックをインナーループに取り込んだ。また「HourGlass」というスキルでチームのPRサイクルタイムを分析してボトルネック箇所と改善策を提示する仕組みも構築した。
次のフェーズとして、テストケース（ユーザージャーニー生成）やテストにおけるLLM-as-judgeの活用が計画されている。
Salesforceのこのアプローチが示すのは、AI採用の成否は「ツール選定」だけでは決まらず、「オーナーシップ設計」と「フィードバックループの整備」が重要な要因であるという点だ。大規模組織での横展開に課題を感じているエンジニアリング組織にとって、具体的な組織構造・メトリクス・ツール配布の仕組みが一通り示されている点でリファレンスとなる内容である。
詳細はHow Salesforce Scaled Engineering AI Adoption Without Stifling Innovationを参照していただきたい。
