powered by TechFeed
表示モード
Deep Dive

SalesforceはAIツールを数千人のエンジニアに配布するより先に「共通言語」を作った — 組織全体にAI活用を波及させる4段階フレームワーク

7月31日、Salesforce Engineeringが「Enterprise AI Enablement: Salesforce's Agentic Strategy」と題した記事を公開した。数千人規模のエンジニア組織がAIエージェントを組織的に活用できるようになるための、Salesforce独自の習熟度フレームワークと展開戦略を詳しく紹介している。AIツールの配布より先に「共通言語」を整備するというアプローチは、多くの企業が直面する「個人の生産性が組織の成果に転化しない」問題への実践的な回答として注目に値する。

7月31日、Salesforce Engineeringが「Enterprise AI Enablement: Salesforce's Agentic Strategy」と題した記事を公開した。数千人規模のエンジニア組織がAIエージェントを組織的に活用できるようになるための、Salesforce独自の習熟度フレームワークと展開戦略を詳しく紹介している。AIツールの配布より先に「共通言語」を整備するというアプローチは、多くの企業が直面する「個人の生産性が組織の成果に転化しない」問題への実践的な回答として注目に値する。


問題の核心:技術ではなく「組織学習」の課題

AIエージェントツールを数千人のエンジニアに配布すること自体は難しくない。難しいのは、彼らがソフトウェアの作り方を根本的に変えることだ。

Salesforceが直面したのも同じ問題だった。エンジニアたちはそれぞれ独自のプロンプト戦略を開発し、テストやデバッグ、ドキュメント作成への活用法を模索し始めた。個々の生産性向上は起きていたが、それが組織全体に波及しなかった。共通言語と共通の「良い仕事の定義」がなければ、個人の成果は組織の成果にならない。

この課題は変化管理(Change Management)の文脈でも広く知られており、新技術の導入が個人レベルの習得で止まり、組織的な行動変容に至らないケースは珍しくない。Salesforceの場合、この課題に取り組んだのがTPIL(Technology, People, Innovation, and Learning)チームだ。


「4段階の習熟度フレームワーク(PLフレームワーク)」が生まれた経緯

組織内の複数チームがそれぞれ独自のモデルを作っていた。5段階でオーケストレーションを定義したチームがあれば、テレメトリを中心に2×2マトリクスを作ったチームもあった。TPILがそれらを照合すると、各モデルが本質的に同じ成長の旅を描いていたことが判明した。

この収束を受けてTPILが構築したのがPLフレームワーク(Proficiency Level Framework)だ。設計上の重要な判断が一つある。特定のツールやIDEではなく、マインドセットと行動を軸にした点だ。特定ツールを中心に据えると、そのツールが変わった瞬間にフレームワークも作り直しになる。エージェントへの委任・検証・協調という「考え方」を習得すれば、次世代のツールにも転用できる。

また、9段階で詳細に定義したAgent Coding Maturity Curveも参照されたが、日常業務で意識し続けられる粒度ではなかった。変化管理と学習研究の知見は「4〜5ステップが人間が行動できる実用的な上限」を示しており、TPILはこれを4段階に絞り込んだ。


4段階の内容

  • AI-Assisted(AI補助):すべてのコードを自分で書くのではなく、AIを最初の協力者として扱うようになる段階。たとえばコード補完や初稿生成をAIに任せ、自分はレビューと判断に集中するといった行動の変化が該当する。
  • AI-Validating(AI検証):AIの出力をそのまま信頼するのではなく、検証するようになる段階。生産的なAI活用は盲目的な信頼ではなく検証に依存することを学ぶ。テストケースの生成や出力の事実確認をルーティン化するといった行動が典型例だ。
  • AI-Orchestrating(AIオーケストレーション):AIに個々のタスクを指示するのではなく、複数のAIエージェントが連携して大きな成果を出すシステムを設計するようになる段階。AIエージェント同士の役割分担やハンドオフを設計する能力がここで問われる。
  • AI-Native(AIネイティブ):自分のワークフローを最適化するだけでなく、それを組織全体の共有標準として体系化し、組織全体のスピードを上げるようになる段階。自チームで有効だった手法をドキュメント化・横展開し、他のエンジニアの学習を加速させる役割を担う。

各段階で問われるのは「何を知っているか」ではなく、実際に行動がどう変わったかだ。


「評価ツール」ではなく「成長の地図」として機能させる設計

このフレームワークは評価システムでも、ダッシュボードでも、テレメトリ計測でもない。エンジニアとマネージャーが一緒に対話するための共通言語として設計されている。

実際の展開では以下の施策が組み合わされた。

  • AIキャンプ:エージェントツールの話を聞くだけでなく、実際に練習・実験する時間を確保する場
  • 週次セッション:参加者の習熟度の変化に合わせて内容を進化させ続けた
  • マネージャー向けコーチングガイド:1on1の会話を「AIが得意ですか?」から「次の成長ステージは何ですか?」に変える共通言語を提供

成果の測定:受講率ではなく「質問の変化」で測る

TPILが注目したのは出席率やコース修了数ではなく、エンジニアの行動が実際に変わったかどうかだ。

第1四半期だけで数千人規模のエンジニアがAIキャンプに参加し、組織の標準ベースラインより速くAIツールを採用した。しかし、より明確なシグナルは週次セッションの質問内容の変化だった。参加者が基礎的なトピックを超えるにつれ、セッション出席数は自然に減少した。質問の内容も「AIからより良い出力を得るには」から「人間の判断がもっとも重要な場面はどこか」へとシフトした。これは単にエージェントを多く使っているのではなく、仕事の捉え方そのものが変わったことを示す。


組織全体へのインプリケーション

Salesforceはこの経験から4つの原則を導いている。

  1. 共通の期待値をスケールさせるまで、エージェント活用はスケールしない
  2. 習熟度は認定ではなく継続的な進行だ。ゴールへの到達速度より、次のステージへ進んでいるかどうかを測る
  3. 行動の変化こそが測るべき指標だ。出席ではなく、ワークフローの進化と質問の複雑さで測る
  4. 学習文化がどのフレームワークよりも重要だ。ツールとフレームワークは陳腐化する

詳細はEnterprise AI Enablement: Salesforce's Agentic Strategyを参照していただきたい。