※本記事は、Dreamforce 2026で行われた基調講演「Scaling the Agentic Enterprise | Salesforce on Salesforce Keynote」の内容を基に作成されています。この講演では、SalesforceがAIエージェントを全社に広げる中で、何がうまくいき、何がうまくいかず、どのような学びを得たのかが、Customer Zeroとしての戦略や教訓、ベストプラクティスとともに紹介されています。動画は https://www.youtube.com/watch?v=Rdbgq7SW3FU でご覧いただけます。
登壇者は以下の通りです。Salesforceでエンタープライズ・AIテクノロジー部門のプレジデントを務めるJoe Inzerillo氏。社内の変革とRapid Innovation Squadsを紹介したAndy White氏。プレジデント兼最高法務責任者のSebastian Niles氏。スモールビジネス営業およびトランスフォーメーション担当SVPのAdam Johnson氏。Salesforceのカスタマーサクセスチームに約5年半在籍し、それ以前はMicrosoftとGitHubで16年間サービス部門のリーダーを務めたBernard Slowey氏。ヘルプエージェントのプロダクトリーダーであるEmily Winslow氏。Salesforceのピープルオフィサーを務めるNathalie Scardino氏。そして、PenFed Credit UnionのCIOであるShri氏です。
本記事では、講演の内容を要約しております。内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。また、Agentforceの詳細については https://www.salesforce.com/agentforce/ もあわせてご参照ください。
1. はじめに：Agentic Enterpriseのスケールに向けて
1.1 昨年の「始め方」の振り返りから、今年の「スケールのさせ方」へ（Joe Inzerillo）
司会： Salesforceでエンタープライズ・AIテクノロジー部門のプレジデントを務めるJoe Inzerilloをお迎えください。
Joe Inzerillo： 皆さん、こんにちは。正直に申し上げると、もっと大きな会場が必要だったかもしれません。これほど多くの方に足を運んでいただき、ありがとうございます。先ほどのMark（Benioff）の基調講演も素晴らしい内容でしたね。
このセッションで私がやりたいのは、皆さんをSalesforceの内側にご案内することです。私たちが実際にどのようにテクノロジーを使って会社を動かしているのかをお見せします。そのテクノロジーには、私たちが自社で開発しているものもあれば、そうでないものもあります。大事なのは、自社製品かどうかではなく、それらを組み合わせて実際に会社をどう運営しているかという点です。いわば「Salesforce on Salesforce」、つまり私たち自身が最初の顧客として何をしてきたのかをお話しするということです。
昨年の基調講演に参加された方もいらっしゃると思います。昨年のテーマは、エージェント型AIを「どう始めるか」でした。そこでお伝えしたのは、まず小さく始めて素早く動くこと、そしてテストし、調整し、それを繰り返すことでした。加えて、適切なデータは金に匹敵する価値を持つこと、価値とインパクトをきちんと測定すること、そして新しい働き方を積極的に受け入れることもお話ししました。
これらは今でもすべて正しいと考えています。特に、まだエージェント型AIへの取り組みを始めていない方にとっては、今も変わらず有効な出発点です。
しかし今日お話ししたいのは、その先です。始めた取り組みをどうスケールさせるのか、どうやって次のレベルへ引き上げるのか、ということです。一部の業務にエージェントを導入するだけでなく、組織を最初から最後までエージェント型エンタープライズへと変えることで、桁違いのインパクトを生み出す方法をお話しします。昨年が「第1巻」だとすれば、今日は「第2巻」にあたる内容です。
では、私たちが言う「スケール」とは具体的にどのような姿なのでしょうか。まずはその全体像からお見せしたいと思います。
2. Human ScaleとAgentic Scale
2.1 スケールを示す数字と、人間のスケール・エージェントのスケールの違い
Joe Inzerillo： 「スケール」と言うと抽象的に聞こえるかもしれませんので、私たちが実際に達成した数字からお話しします。
1つ目は、Salesforceの全従業員、つまり100%がエージェント型ツールを使っているということです。一部の先進的な部署や技術系の社員だけではありません。会社全体がエージェントとともに働いている状態で、これは非常に大きな変化です。
2つ目は、Salesforce社内だけで20万件のSlackbotスキルが作られたことです。お客様が作ったスキルや、ここにいる皆さんが作ったスキルは含まれていません。私たちの社内で、社員自身が業務のために生み出したスキルだけで20万件あります。
3つ目は、営業面で1億6000万ドルのパイプラインが生まれたことです。これは、私たちがエージェント型の会社に変わっていなければ存在しなかった金額です。
これらの数字は非常に重要だと考えていますが、その背景にある「エージェントのスケール」という考え方について少し説明させてください。
まずその反対側にある「人間のスケール」から考えてみましょう。人間はどのように働き、何ができるでしょうか。ソフトウェアやWebブラウザを開いてクリックし、メニューをたどって操作します。Slackを開いて、別の人間に向けて文字を打ち込みます。こうした作業が得意な人もいれば、苦手な人もいます。しかし、手元のツールを使って一人の人間が生み出せるスケールには、どうしても上限があります。
これに対してエージェントのスケールとは、人間にはそもそも不可能なことを実現できる規模です。3年前ならSFのように思えたことが、今では実際にできるようになっています。たとえば、これまでに交わされたすべての医療に関する会話を横断して推論することや、Salesforceが27年間にわたって蓄積してきた膨大なデータを検索して答えを返すことです。どれだけ優秀で勤勉な人でも、一人の人間がやれる範囲を大きく超えています。
私がこの講演で「エージェントのスケール」と言うときは、こうした人間の限界を超えた規模のことを指しています。
2.2 工程全体をエージェント規模にしなければROIは失われるという気づきと、技術スタックの全体像
Joe Inzerillo： エージェントのスケールについて、ぜひ覚えておいていただきたいことがあります。ある工程をエージェント規模にしたら、その次に続く工程もエージェント規模でなければならない、ということです。
前の工程でエージェントが膨大な量の仕事をこなせるようになっても、次の工程が人間規模のままであれば、そこがボトルネックになります。エージェントが生み出した成果は、人間の処理能力の手前で止まってしまうわけです。私は、そこがROIの墓場になると考えています。
「95%の企業がAIから価値を得られていない」という話を耳にしたことがあると思います。私の見方では、その原因はAIそのものの能力不足ではありません。プロセス全体をエージェント型にしておらず、一部分だけをエージェント型にしているからです。部分的な最適化、つまり局所最適では成果は出ません。プロセスを最初から最後まで通してエージェント規模にして、はじめて本当の価値が引き出せるのです。
では、それをどうやって実現するのか。全体像はMarkが基調講演で非常にうまく説明してくれましたので、ここで改めてスライドを細かく説明することはしませんが、構成を簡単におさらいします。
土台にあるのがデータ層です。その上にお客様の層があり、皆さんがよくご存じのアプリケーションがCustomer 360の層に位置しています。これらのアプリケーションは、今では画面を持たないヘッドレスな形で提供されることも多くなっています。そこにエージェント層であるAgentforceが組み込まれています。
そして最上部にあるのがAI Forceです。私が最もワクワクしているのがこの部分で、まったく新しいインターフェース、つまりインターフェースやワークフローについての新しい考え方を示すものです。これから続くデモでも、このAI Forceの考え方が実際に使われている様子をたくさんご覧いただけると思います。
3. エージェント型AIのための5つのフレームワーク原則
3.1 「誰もが作れる」から「未来に備えた人材」までの5原則
Joe Inzerillo： ここからの話を整理するために、1つのフレームワークを紹介します。この基調講演から何か1つ持ち帰っていただくとしたら、この5つの原則です。全部でなくてもかまいません。いくつかでも持ち帰っていただければ十分です。もちろん5つ全部であれば一番うれしいですが。
1つ目の原則は「誰もが作れる」です。ここで大事なのは、「誰もが作っている」とは言っていない点です。私たちは以前、「全員がビルダーだ」という言い方をしていました。ところが、この言葉は多くの人を不安にさせることがわかりました。事業部門のユーザーにこの話をすると、「私は財務部門でExcelを使って仕事をしているのですが、プログラマーにならなければいけないということですか」と聞かれます。答えはノーです。プログラマーになる必要はありません。全員に作ることを求めているのではなく、誰もが作れるように権限と手段を与えられていることが重要なのです。
2つ目の原則は、先ほどお話ししたエージェントのスケールに関わるものです。既存のプロセスをどう再設計すればエージェント規模で機能するようになるのか、という問いです。そのためにどのプラットフォームやツールが適切なのか、それらをどう組み合わせれば人間に力を与えられるのかを考える必要があります。
ただし、そこで止まってはいけません。3つ目の原則は、事業そのものをどう作り直すかです。組織図をどう変えるか、この変化をどう活かすかを考えなければなりません。働き方を根本から変えてしまう技術革命に取り組みながら、組織図は一切変えず、プロセスもすべてこれまで通りにするというのは、どう考えてもおかしな話です。ですから、エージェントの時代に合わせて組織を作る必要があります。
4つ目の原則は、お客様にとってのシームレスな体験です。エージェント革命には厄介な面もあります。一度素晴らしい体験を提供すると、人々はあらゆる場面で同じ水準を期待するようになるのです。しかも、競合他社が素晴らしい体験を提供すれば、皆さんにも同じ水準が求められます。お客様はあるエージェントで得た良い体験を、次のエージェントとのやり取りにもそのまま持ち込んでくるわけです。
車の音声操作を思い浮かべてみてください。音声操作が登場した頃は「ステレオをつけて」と言うだけで、すごいと感動したものです。ところが今、天気を尋ねて「申し訳ありません、よくわかりません」と返されたら、「なんだこれは、使えないな」と感じるはずです。期待値は一度上がると戻りません。だからこそ、一部分だけでなく、お客様のジャーニー全体をスケールさせる必要があります。
5つ目の原則は、未来に備えた人材の育成です。機械はまだ自分で自分を作ることはできません。エージェントを作るのは人間です。ですから、リスキリングをどう進めるか、従業員とどう向き合うかを考えなければなりません。この点についても、後ほど詳しく掘り下げます。
4. 構築ツールの全従業員への民主化
4.1 非技術系従業員へのコーディングツールの広がりと、IT部門の新たな役割
Joe Inzerillo： では、1つ目の原則である「誰もが作れる」から始めます。繰り返しになりますが、ここで大事なのは「作れる」という点です。ただ、実際にはほとんどの社員がすでに作っています。
Salesforceでは、全従業員の67%が何らかのコーディングツールを使っています。では、その人たちが本当にコードを書けるのかというと、ほとんどの場合は書けません。それでも、機械に話しかける方法は知っています。私たちの場合、その多くはSlackを通じてです。「こういうものが必要です」「概要はこうで、私としてはこういうものを想定しています」「この質問にはこういう方法で答えてほしい」と伝えるのです。その結果としてコードが書かれることもあれば、その場限りのダッシュボードが作られることもありますし、単に質問への答えが返ってくることもあります。いずれにせよ、彼らは作ることができています。
特に注目していただきたいのは、非技術系の従業員でもコーディングツールの利用率が57%に達しており、第1四半期から20%増えているという点です。この流れは大きく加速しています。そして、この加速が止まることはありません。これからも続いていきます。だからこそ、私たちはこの流れを後押ししたいと考えています。
とはいえ、「誰もが作れる」と聞くと、CIOにとっては悪夢のように聞こえるかもしれません。社員がそれぞれ好き勝手に、とんでもないものを作り出すのではないかと心配になるはずです。実際、私たちが取り組みを始めた当初は、ある程度そういう状況でした。ただ、それは私たちが頭の中で「作る」ことを、すべてを一から作り上げるモデルで考えていたからだと思います。
これまでのやり方では、プロダクト担当やプログラムマネージャーが事業部門の人たちのところへ行き、「皆さんに何かを届けるために情報をいただきたい」とヒアリングをしていました。これには時間がかかります。ウォーターフォールからアジャイルに移って改善はしましたが、ヒアリングして作るという流れである以上、どうしても遅れが生じます。
エージェント型の組織になる恩恵を受けたいのであれば、未来の姿を前提に考えなければなりません。私の考えでは、その未来でもIT部門は信頼、インテグリティ、コンプライアンスに深く関わり続けます。バイブコーディングでSOX法対応を済ませることはできません。少なくとも今はまだ無理です。それでも、必ずきちんと対応しなければならない領域です。
さらにIT部門は、記録システムにも強く関与し続けます。データがどのような姿をしているのか、顧客とは何なのか、といった構造を決める役割です。データセマンティクスも同様です。たとえば平均注文額や売上高といった言葉は、人によってさまざまな意味で使われます。こうした定義は、高度に専門化した人たちが決めるべきものです。
ただし、こうしたものはすべて、APIやMCPという形に整えられていくと考えています。なぜなら、私たちはもう人間のためにシステムを作るのではなく、人間が操作するエージェントのためにシステムを作るようになるからです。IT部門がAPIを整えておくことで、作業の大部分、つまりビジネス価値の大半が生まれる部分を事業部門の人たちが担えるようになります。Markが基調講演で話していた「閉じ込められた価値」を解き放つ鍵は、事業部門の人たちがチームの中で自らコーディングできるようにすることにあります。この点は後ほど詳しくご紹介します。
4.2 「100の失敗」から得た教訓と、協働の欲求から生まれたSlack Code
Joe Inzerillo： もちろん、私たちは一夜にしてここにたどり着いたわけではありません。「私たちはなんて賢いんだ」と言うつもりはまったくありません。むしろ、皆さんが同じ失敗をしなくて済むように、私たちが先に100回は失敗してきました。その一部は製品という形になっていて、それについては後ほどお話しします。しかし多くは、単純に試行錯誤の中で学んだ教訓です。
たとえば、トークンをひたすら大量に使えばいいという考え方は、おそらく賢明ではないとわかっていました。それでも、社員がツールを使えるようにしなければならないこともわかっていました。ですから、実際にある程度は試してみることにしました。
また、作り方は人によって違うということもわかっていました。私たちはそれでかまわないと考えました。即興で工夫できる余地を残しておきたかったからです。
アクセス権の問題も避けて通れませんでした。これは決して軽く考えてはいけない問題です。最初は控えめな範囲から始め、信頼とセキュリティが本当に重要だという理解が深まり、安心できるようになるにつれて範囲を広げていきました。
私たちはまた、人間のスケールの限界についても考えていました。会社というシステム全体にどう働きかければ、人間のスケールにとどまっている部分を取り除き、エージェントのスケールに到達できるのか、という問いです。
その過程で私たちが最も強く感じたのは、チームは協働したがっているということでした。部門の壁を取り払い始めると、人々は自然と一緒に働きたがったのです。
その気づきを形にしたのがSlackです。数週間前に発表し、Markも基調講演で触れていたSlack Codeがそれにあたります。Slack Codeでは、技術系の人も非技術系の人も1つのコーディングチャンネルに集まり、これから何を作るのかを一緒に話し合えます。これは非常に重要なことだと考えています。
ここまでは技術面の変化について多くお話ししてきました。ここからは人の変化、つまりこれを実現するために組織がどう作り変えられたのかについて、私の友人であるAndyに話してもらいます。その前に、実際の様子を短い映像でご覧ください。
5. Rapid Innovation Squads（RIZ）とSlack Code（Andy White）
5.1 従来型開発プロセスの限界と、RIZのチーム構成および1日の働き方
Andy White： 皆さん、こんにちは。今日この場に立てることをうれしく思います。Andy Whiteです。Joe、ありがとうございます。お客様、パートナー、そしてTrailblazerの皆さんに、Salesforceが内側からどのように変わりつつあるのかをお伝えできることを楽しみにしてきました。
長い間、あらゆるチーム、あらゆるプロセス、あらゆるシステムは、人間のスケールを前提に作られてきました。それは当時としては正しいやり方でした。しかし、もうそうではなくなりました。私たちが手にしている機会も、私たちを縛っている制約も変わったのです。今こそ、新しい世界に合わせて考え直すべきだと考えています。
これからお話しする従来のプロセスは、ここサンフランシスコのロンバード・ストリートのように聞こえるかもしれません。まず要件をまとめ、そして待ちます。カーブを曲がってフィードバック会議を開き、次にデザインレビューの予定を組み、また待ちます。アーキテクチャレビューを経て、最初に要件を出してくれた人たちのところへ戻ると、「やっぱり違うものがいい」と言われます。そこで変更要求が発生するわけです。
そこで私たちは問いを立てました。チーム、プロセス、システムをエージェントのスケールに合わせて作り直したらどうなるのか。人間とエージェントが一緒に働けば、どれだけ速く進めるのか。この問いに答えるために、私たちは未来へのタイムマシンを作りました。それがRapid Innovation Squadsです。12〜18か月後に仕事がどうなっているのかを理解し、その姿を今に持ち帰って、より速く変化できるようにしたいと考えたのです。Rapid Innovation Squadsでは少し長いので、私たちは「RIZ」と呼んでいます。こちらのほうが格好いいですよね。
RIZチームは非常にシンプルな仕組みから始まりました。出発点は、明確な意見を持ったステークホルダーです。何を解決しようとしているのか、まず問題から始めなければなりません。その問題に対して、エージェント型のビルダーを投入します。人数は1人のこともあれば2人のことも、5人のこともありますが、とにかくできるだけ少なくします。そして、ステークホルダーが持ち込んだ問題を、できるだけ小さく絞り込んでいきます。
ここまでは当たり前に聞こえるかもしれません。本当の違いは、チームの働き方にあります。
RIZチームは朝に集まり、コーヒーを飲みながらスタンドアップミーティングを行います。このミーティングは録音されて文字起こしされ、その内容が公開のSlackチャンネルに流されます。公開にしているのは、1つのRIZチームで起きていることを組織の他のメンバーも学べるようにするためです。極秘の案件であればプライベートチャンネルを使うこともありますが、基本的には公開が重要だと考えています。
次に、その文字起こしをエージェント型のコーディングツールに渡して、その場を離れます。するとエージェントが、話し合った内容に取りかかります。昼食後にも同じことを繰り返します。このチームのメンバーは全員がビルダーで、それぞれがアイデアやプロトタイプを持ち寄り、同じゴールに向かって協力します。そして1日の終わりにもう一度同じことを行い、メンバーが眠っている間もエージェント型コーディングツールが作業を続けます。
5.2 意思決定10倍・成果30倍という知見と、意見を持つステークホルダーMayaの実例
Andy White： この新しい働き方の効果ははっきりしています。明確な意見を持つステークホルダーと組むことで、意思決定のスピードは10倍になりました。そこにエージェント型コーディングツールを組み合わせると、成果が出るまでのスピードは30倍になります。
ただし、大事なのはスピードそのものではありません。この新しい働き方によって、どれだけのビジネスインパクトを生み出せるかが本当の価値です。その成果には、私自身も本当に驚かされています。
また、RIZはタイムマシンですから、私たちはこれからも続け、学び続けていきます。1年後には、今とはまた違う見方をしているはずです。今日お話ししている内容も、あくまで現時点での学びだということです。
先ほどから「意見を持つステークホルダー」と言ってきましたが、その一人をご紹介します。私たちの最初のステークホルダーはMayaで、今日この会場にも来ています。彼女は本当に素晴らしい人です。皆さんの会社にもMayaのような人がいるといいのですが、もしいるなら本当に幸運です。
Mayaが特別なのは、Salesforceのパートナーエコシステムに強い情熱を持っている点です。彼女はパートナー体験の責任者であり、より良い新しいものを生み出すためなら、既存のパートナー体験を壊すこともいといません。そして、自分が所属するRIZチームに深く入り込んでいます。
彼女はプロトタイプを持ってくるだけではありません。自らコードを本番環境に反映しています。私たちが一緒に取り組んでいる意見を持つリーダーの中で、それを成し遂げたのは2人だけで、彼女はその一人です。
これがどれほど大きな意味を持つかというと、彼女はIT部門の人間ではないということです。だからこそ、Joeが話していたIT部門の役割が重要になります。IT部門がレゴブロックのような基盤を整えておくことで、Mayaのような人が安全にビルダーとして活躍できるのです。
6. 法務ケーストリアージとコンプライアンス変革（Andy White、Sebastian Niles）
6.1 法務RIZのビジョンと、数十万件の依頼のトリアージによる信頼とセキュリティの向上
Andy White： 次にご紹介したいのは、法務部門のRIZです。テーマは案件のトリアージです。後ろのスライドには、取引サイクルの短縮やコスト削減に関する数字を載せています。それだけでなく、この取り組みによって営業担当者、法務担当者、そしてお客様の体験も改善されています。法務チームを持つ会社であれば、どこにでも当てはまる話ですので、皆さんにとっても学べることが多いと思います。
法務RIZがこれほどうまくいっている理由の1つは、法務チームのリーダーにあります。社内からエージェントで組織を作り変えようと考えたとき、法務部門は最初に思い浮かぶ部署ではないかもしれません。しかし、私たちの法務部門は違いました。それでは、そのリーダーをお迎えしましょう。プレジデント兼最高法務責任者のSebastian Nilesです。
Sebastian、私たちはRIZで一緒に素晴らしい成果を上げてきましたが、同時にコンプライアンス、セキュリティ、信頼も高めることができました。現状維持ではなく、むしろ向上させたわけです。この点について、あなたの考えを聞かせてもらえますか。
Sebastian Niles： 喜んで。まず、素晴らしいパートナーシップに感謝しています。この取り組みは、私たちの部門の未来にとっても、会社の未来にとっても、そしてお客様やステークホルダーの皆さんの未来にとっても非常に重要です。
今朝の基調講演で、MarkとJensen（Huang）が「以前はできなかったことが、今はできるようになった」と話していました。その結果、あらゆる組織が、そして私たち一人ひとりがより大きな志を持つようになるかもしれません。私があえてこの話をするのは、おっしゃる通り、私たちがグローバルの法務、コンプライアンス、リスク部門について非常に大きなビジョンを掲げているからです。そのビジョンとは、これらの部門をAIネイティブで、信頼を最優先し、エージェント型の組織にすることです。
その理由は2つあります。1つ目は、人間とエージェントの協働の最良の形を、私たち自身の手で定義したいからです。2つ目は、会社を守りながら、切迫感を持ってスピードを上げたいからです。私たちの部門は、特に下振れリスクに強い関心を持っています。
私たちのもとには年間で数十万件もの依頼が届きます。その多くについて、まず「誰に回すべきか」を決めなければなりません。どの法務担当者に回すのか、どのチームに回すのか、どのコンプライアンスチームに回すのか、ということです。では、数十万件の依頼をルーティングし、トリアージする作業は、本当に法務の専門家や社内の優秀な人たちが集中すべき仕事なのでしょうか。
この取り組みは、まさにその部分を変革しています。スライドの成果をご覧いただけばわかる通りです。そして、これが信頼とセキュリティを高める仕組みは2つあります。
1つ目は、大量に発生し、繰り返し行われ、スケールが必要な業務を、エージェント、私たちのプラットフォーム、そしてこれらのツールを使って処理することです。仕事は確実に片づきますが、より速く、よりシンプルに進みます。その一方で、リスクが高くインパクトの大きい領域にチームが本当に集中できるようになります。仕事を適切な場所に振り分けることで、信頼とセキュリティが高まるわけです。
2つ目は、皆さんが作っているもの、私たちが一緒に作っているものが、ガバナンスを効かせることができ、可観測性を備えている点です。
この2つが組み合わさることで、私たちの「事業を行う資格」と「イノベーションを行う資格」の両方が強化され、より速く進めるようになっています。
6.2 RIZによる働き方の変化と、全社へのRIZ展開
Andy White： 素晴らしいですね。私たちにはまだ一緒に取り組むべきことがたくさんありますが、RIZとして働くようになってからチームの働き方がどう変わったのか、以前とどこが違うのか、あなたが耳にしていることを教えていただけますか。
Sebastian Niles： もちろんです。一緒に取り組むべきことは本当にまだたくさんあります。この取り組みでバックログが消えてなくなることはあるでしょうか。バックログがない状態を想像できますか。そうなるとしたら、主にあなたたちが私たちの仕事をすべて優先してくれるからでしょうね。それなら大歓迎です。
冗談はさておき、実際の様子をお話しします。まず、私たちのチームがあなたたちのチームと一緒にこの取り組みに注いでいる熱意とエネルギーです。Joeが「人は協働したがっている」と話していましたが、それはまさにRIZチームの重要な要素です。
また、私たちは問題に対する考え方も一緒に変えています。何なら取り組みやすい大きさにできるのか、どこまで具体的にできるのか、ということです。おっしゃったように、いつまでも待ち続けることはありません。これほど大きな成果を上げた取り組みも、数か月ではなく数週間で実現しました。
Andy White： 数週間です。
Sebastian Niles： その通り、数か月ではありません。もう1つ強調したいのは、人材の変化です。法務およびコーポレートアフェアーズのメンバーは全員、個人として業務を担う人からマネージャーまで、今では「エージェント型の統制範囲」を持つようになっています。あなたたちと一緒に作っているエージェントを管理し、ともに働いているからです。
ただし、そのためには私たちも明確な意見を持たなければなりません。たとえば、新しく作った贈答・接待・会食の承認アプリがあります。皆さんの中にも、こうしたものの事前承認の手続きを経験したことがある方は多いと思います。このアプリによって、その手続きが非常に速く、シンプルに進むようになりました。素晴らしい協働を実現しながら、会社を守りつつスピードも上げることができています。楽しく、社員も満足していて、しかも仕事がきちんと片づく。そういう状態です。
Andy White： ありがとうございます。
Sebastian Niles： これからも一緒に取り組んでいきましょう。
Andy White： もちろんです。
ここで、Salesforceが内側からどのように変わりつつあるのかをまとめておきたいと思います。これは各部門にITを組み込むという話にとどまりません。私たちにはすべての事業部門と組んでいるRIZチームがあり、年末までにはデリバリー全体の3分の2をRIZチームが担う予定です。
皆さんにも同じことができます。私たちの例をそのまま参考にしていただけます。Joeからは、どのように全員がビルダーになれるようにしているのかをお話ししました。私からは、どのように会社を内側から変えているのかをお話ししました。
次は、もう一人の意見を持つステークホルダーに登場してもらいます。彼は自分の事業を土台から作り直しています。私はその様子をインディアナポリスで直接見てきました。SMB営業担当SVPのAdam Johnsonです。Adam、あなたの話を聞かせてください。
7. エージェント型SMB営業とSignalsアプリケーション（Adam Johnson）
7.1 営業組織が抱えていた課題と、Bricks・Sticks・Strawsモデル
Adam Johnson： Andy、ありがとうございます。今日ここでお話しできることを本当にうれしく思います。これから紹介するのは、本当に信じられないような話です。
Andyから、このプロセスには意見を持つリーダーが欠かせないという話がありました。そこで、なぜ私が強い意見を持っているのかを説明させてください。私は20年以上にわたって、営業担当者や営業リーダーとして働いてきました。ですから、営業担当者の考え方はよくわかっています。彼らがどう働くのか、何にストレスを感じるのか、どう意思決定するのか、そして何が仕事の邪魔になっているのかを知っています。だからこそ、営業担当者向けの新しいソリューションを設計し、作るプロセスに、私は多くのものを持ち込めるのです。
Andyはスモールビジネス営業およびトランスフォーメーション担当SVPとして私を紹介してくれましたが、肩書きのとても大事な部分を1つ言い忘れていました。私は正式に「エージェント型ビルダー」でもあるのです。拍手をありがとうございます。この肩書きをどうやって手に入れたのかは、後ほどお話しします。
その前に、私たちがこれまでたどってきた道のりを少し紹介します。昨年のDreamforceでは、営業プロセスにエージェントが現れ始めた場所についてお話ししました。当時はこちらで実験をし、あちらで試験導入をする、という段階でした。今はまったく違います。お客様に向けた営業プロセスのあらゆるステップにエージェントが組み込まれています。アカウント調査、商談の準備、請求など、どの業務でも、エージェントが営業担当者の隣で毎日の仕事を手伝っています。
ただ、ここに至るまでの出発点を理解していただくことも大切です。私たちは、ほとんどの営業組織が抱えているのと同じ課題に直面していました。ツールはバラバラでした。新規顧客をリード獲得から売掛金の回収までつなぐプロセスは、120種類以上もありました。そして、チームが日々の仕事を効果的に進めるために必要な情報は、数十、場合によっては数百もの場所に散らばっていました。
私たちはこの状況を、新しいプロセスを導入することで変えたのではありません。今使えるテクノロジーを活用して、営業担当者にできることの範囲そのものを根本から変えたのです。
最初に取り組んだのは、クリティカルパス、つまり私たちの働き方にとって絶対に譲れないものは何かを考えることでした。私はこれを「Bricks（レンガ）」と呼んでいます。あらゆる業務の土台になるものです。Bricksは事業部門の意見を取り入れつつも、IT部門が中央で管理します。それほど重要だからです。安全で安定していて、確実に機能していなければなりません。あらゆる業務に影響するからです。
この土台の上に、残りの構造を組み立てていきます。その次の層が「Sticks（木の枝）」で、私はこれを地域単位、あるいは機能単位の主体性と呼んでいます。Andyが話したようなRIZチームが、私のような、そして会場の多くの皆さんのような意見を持つリーダーと組んで、チームや部署、特定の地域の生産性を引き上げる具体的な問題に取り組む層です。
さらにその上に載せるのが「Straws（わら）」です。これは現場単位、個人単位の主体性です。業務の流れの中で、一人の人間としてタスクレベルや日々の生産性に役立つものを自分で作る、という層です。
ここで強調しておきたいのは、これはIT部門の重要性を軽く見ようという話ではまったくないということです。むしろその逆です。一人ひとりが、自分にしかできない領域で貢献できるように、全員に必要なツールを渡すということです。セキュリティやコンプライアンスといった話になれば、私の出る幕はありません。しかしSticksやStrawsについては、私には提供できるものがたくさんあり、負荷を分担できます。そうすることで、IT部門は自分たちにしかできないことに時間を使えるようになるのです。
7.2 構築過程で得た3つの気づきと、Signalsアプリのデモ
Adam Johnson： このRIZのモデルで実際に作ったものを1つご紹介します。その前に、これまでの取り組みの中で気づいたことを3つお話しさせてください。
1つ目は、何が問題なのか、何がチームの足を引っ張っているのかを明確にしなければならないということです。2つ目は、その問題を解決するソリューションがどんな姿になるべきか、しっかりとした見通しを持っていなければならないということです。3つ目は、AndyやJoeのように、あなたをステークホルダーとして迎え入れ、プロセスの中で意思決定させてくれる優れたビジネスパートナーが必要だということです。
3つ目が特に重要だと考えているのには理由があります。この1年、チームの中で彼らと一緒に設計と開発を進めてきてわかったのは、新しいソリューションを現場に届けるまでには、何百万もの小さな意思決定が必要だということです。その場に、ユーザーのこと、ユーザーがそれをどう使うのか、そして解決しようとしているビジネス上の問題を本当に理解している人がいなければ、プログラムはいとも簡単に道を外れてしまいます。
それでは、Signalsアプリケーションをご覧ください。私たちが取り組んだ問題はこうです。営業担当者が自分のアカウントの状況を把握するために追いかけなければならない情報源を洗い出したところ、400以上もありました。しかもそれがあちこちに散らばっています。私たちはヘッドレスの仕組みとData 360を使ってこれらをすべて集約し、営業担当者が行動を起こすことだけに集中できる1つの画面で届けたいと考えました。
営業担当者としてログインすると、シグナルはデフォルトで重要度ごとにまとめられています。今日は種類別に見てみましょう。表示を切り替えてリストをスクロールすると、Summit Trail Softwareとの優待契約の期限が近づいているのに、関連する商談が登録されていないことがわかります。
詳しく知りたいので、クリックしてみます。Data 360を使い、営業担当者に届く前にLLMの層を通しているので、行動するために必要な情報が豊富な文脈とともに表示されます。これで状況を把握でき、すぐにお客様に連絡できる状態になりました。
次に「メール」をクリックします。するとSlackbotが自動的に起動し、営業担当者である私に代わってメールの下書きを作ってくれます。私はそれをこの画面から直接送信できます。送信すると、そのメールは活動記録機能を通じて記録システムに連携されます。つまり、営業担当者である私は、マネージャー向けのレポートでこの活動の実績をきちんと認めてもらえます。また、このシグナルはSignalsの画面から消えるので、対応済みであることがわかり、次の案件に移れます。
そして、うれしいお知らせです。Summit Trail Softwareと話がつき、パイプラインを追加することになりました。拍手をありがとうございます。そうしたら、またこの画面に戻ります。ここにボタンがあり、商談を追加できます。追加した商談はやはり記録システムであるCRMに連携されるので、パイプラインにも売上予測レポートにも反映されます。それでも営業担当者である私は、一度もこの画面を離れていません。
これは素晴らしい生産性向上ツールで、チームからも大好評です。なぜなら、これまでは情報が散らばっていて、営業担当者は毎日、毎週、何時間もかけて探し回っていたからです。それが今は、向こうから直接届けられるようになりました。
7.3 リーダー向けの可視化、Claudeの活用、そして成果と今後
Adam Johnson： ただし、これは営業担当者の生産性を上げるだけのツールではありません。リーダーのためのツールでもあります。私は営業リーダーとして、どんな通知が送られたのかを知りたいわけではありません。どの仕事が完了したのか、そしてその仕事がどんなビジネス上の成果につながったのかを知りたいのです。その可視性を持つことが私たちにとって重要です。通知はそれだけではビジネスプロセスになりません。
「可視化と言うなら、どうせダッシュボードを見せるんでしょう」と思われるかもしれません。もちろんダッシュボードもありますし、この画面からMCPを通じてデータに直接アクセスすることもできます。ただ、私は先ほどお話しした現場単位の主体性を発揮して、自分好みのデザインのダッシュボードを作りたいと思いました。
そこでお披露目するのが「Signalsリーダーボード」です。なかなかのものでしょう。私は大のゴルフ好きなので、このデータに触れること自体が楽しく、引き込まれるようなものにしたかったのです。もちろん、生産的で意味のあるものであることは前提です。このデザインは、私が個人的にClaudeを使って作りました。これは完全に私のためだけのもので、私が欲しかったものそのものです。本当に素晴らしいことだと思っています。
実は、私たちはこの開発プロセスの中でClaudeをいくつかの形で使っています。今ご覧いただいたのは、先ほどお話しした現場単位の主体性の例で、データの見た目を私自身が変えました。それとは別に、開発プロセスそのものにもClaudeを使いました。これほど速く進められたのはそのおかげです。キックオフミーティングから、1日あたり3,000人以上のアクティブユーザーが現場で使う状態になるまで、わずか数か月でした。
さらに、私たちはClaudeをQAアナリストとしても使いました。大きな変更を展開するとき、何を知りたいでしょうか。ユーザーが期待通りに使ってくれているかどうかです。これを確かめるには、CRM上の記録とシグナルの処理状況を手作業で突き合わせて検証する必要があり、何時間もかかるはずでした。それがClaudeを使うと、私の作業時間は15分ほどで済みました。本当にすごいことです。
では、こうした変革全体で何が実現したのか。私たちはチームに、何時間分もの営業活動の時間を取り戻しました。チームが必要なときにすぐ取り出して使える、再利用可能なスキルのライブラリもできました。商談のアポイントは増え、パイプラインも増え、成約も増えています。そして、お客様にとってもより良い成果を生み出しています。エージェントの時代に、チームに作るためのツールを渡せば、これだけのことが可能になるのです。
Joe Inzerillo： Adam、素晴らしい話でした。本当に、本当に素晴らしい内容です。ここにある数字の中で、特に皆さんに実感していただきたいのが、この1億6000万ドルのパイプラインです。これは会社にとって本物の価値であり、数字として測れる価値です。私たちはよく「損益計算書に反映される価値」と言いますが、これはまさに損益計算書に反映される数字です。
Adam Johnson： その通りです。
Joe Inzerillo： この先はどう考えていますか。可能性は無限だと思いますが、これから何が来るのか、少しだけ教えてください。ここで終わりではありませんし、私たちは止まるつもりはありませんから。
Adam Johnson： ええ、止まりません。今いちばん面白いのは、現場からフィードバックが届き始めていることです。今日お見せしたこのプロダクトは、毎日少しずつ良くなっています。それに、取り組める問題はまだまだたくさんあります。すでにいくつものRIZチームが、さまざまなテーマで動き始めています。できることは本当にたくさんあります。Joe、これからも作り続けるのが楽しみでなりません。
Joe Inzerillo： 素晴らしい。本当にありがとう、Adam。
ここまでで、現場のプロセスをどう再設計するのか、そして事業部門とどう関わるのかを見てきました。次は、これをポートフォリオ全体でどう機能させ、お客様にどう届けるのかについてお話しします。まず短い映像をご覧いただき、そのあとBernardに説明してもらいます。
8. プロアクティブ・サービスのスケールとAgent Scriptアーキテクチャ（Bernard Slowey）
8.1 サービスリーダーがぶつかる壁と、ヘルプエージェントCaseyの進化
Bernard Slowey： 今の映像、気に入っています。あれは私たちのチームの2年分の仕事を表したものです。皆さん、こんにちは。Bernard Sloweyです。Salesforceのカスタマーサクセスチームに来て5年半ほどになります。その前は16年間、MicrosoftとGitHubで、ずっとサービス部門のリーダーを務めていました。
私は仕事柄、毎週のようにサービス部門のリーダーたちと話をしています。そこで聞くフィードバックは、私自身のチームから聞くものと同じです。どのサービスリーダーも、同じ壁にぶつかっているのです。
どういうことか説明します。私たちは誰でも、あらゆる場面でプロアクティブでありたいと思っています。オンボーディングのときにはお客様に電話をかけ、一人ひとりに直接ご挨拶し、私たちの製品がどれほど優れているか、お客様に使っていただけてどれほどうれしいかをお伝えしたい。お客様から電話をいただいたら、全員に最速で応答したい。会社から送るメールは、「返信不可」のアドレスからではなく、ちゃんと人が受け取れるアドレスから送りたい。
問題は、計算が合わないことです。どの会社にも損益計算書があり、おそらくどの会社でもCFOがサービスリーダーに「もっと少ないリソースで、もっと多くの成果を出してほしい」と言っています。それが現実です。
Salesforceも例外ではありません。私たちには100万社を超えるお客様がいて、従業員は8万人以上います。仮にその従業員全員をカスタマーサクセス部門に異動させたとしても、すべてのお客様に人が付き添うオンボーディングを提供することはできません。Markがサポートエンジニアになったらどう思うかもわかりません。正直なところ、それは本人に試してもらわないとわかりませんね。
しかし、状況は変わりつつあります。エージェントのスケールが、この壁を壊し始めているからです。おかげでサービスリーダーは、これまで夢見てきた問いを本気で投げかけられるようになりました。もし無限にスケールできるとしたらどうするか。制約のない体験を作れるとしたら、どんな体験を作るか。それこそがSalesforceで私たちが考えてきたことです。
私たちはこの取り組みを2年前に、ポータル上のヘルプエージェント「Casey」から始めました。最初は受け身型のサポートでした。お客様がポータルに来て質問をすると、Caseyが答えようとします。答えられなければ、サポートエンジニアに引き継ぎます。
この12か月間で、私たちはこの体験をライフサイクル全体に広げてきました。Caseyの中には、今ではいくつものサブエージェントがいます。オンボーディング用のサブエージェントは、お客様がSalesforceを使い始めて軌道に乗るまでを支援します。アドプション用のエージェントは、お客様がまだ使っていない機能を見つけ、その機能について説明して活用を後押しします。更新用のエージェントは、お客様とやり取りしながらSalesforceとの契約更新を進めます。
さらに、先ほどの映像でご覧いただいた通り、チャネルも広げました。ヘルプエージェントは今、音声でも利用できます。米国かカナダから「1-800-NO-SOFTWARE」に電話をかければ、英語のみですが、私たちのヘルプエージェントと話せます。本当によくできていますので、ぜひ試してみてください。きっと驚かれると思います。
8.2 Agent Scriptによる再構築と、決定論・非決定論の使い分けから得た教訓
Bernard Slowey： ここからは、私たちがこれをどうやって実現したのかを詳しくお話しします。皆さんにも同じことをしていただけるようにするためです。
私たちにとって本当の転機になったのは、12か月前のDreamforceでした。Agentforceチームがこの舞台でAgent Scriptを発表したのです。私たちはヘルプエージェントを、Agent Scriptの上で一から作り直しました。そのアーキテクチャをお見せします。
お客様がエージェントにアクセスすると、まずエージェントルーターが受け付けます。ルーターはお客様の意図、つまりお客様が片づけたい用件を見極め、それに合ったサブエージェントに振り分けます。サポート、オンボーディング、アドプション、更新のサブエージェントがあり、それぞれが自分の担当する用件に特化しています。そして、どのサブエージェントも必要に応じて、ユーティリティ用のサブエージェント群を呼び出すことができます。
このアーキテクチャの素晴らしい点は、モジュール型になっていることです。新しいことをしたいときは、新しいレゴブロックを1つ追加するだけで済みます。このアーキテクチャのおかげで、私たちはスケールできるのです。
わかりやすい例が人間への引き継ぎです。たとえばお客様がサポート用のサブエージェントと話していて、サポートエンジニアにつないでほしいと言ったとします。そのとき、サポート用のサブエージェントは、人間への引き継ぎを専門に担当するサブエージェントを呼び出すだけです。そのサブエージェントが引き継ぎの専門家として、お客様をエンジニアにつなぎます。この構造が、私たちのスケールを可能にしてきました。
もう1つ、私たちにとって非常に大きかったのが、今日Markも話していた決定論と非決定論の問題です。これは私たちにとって、ホワイトボードの上だけの概念ではありません。
今お見せしているのは、以前のアーキテクチャで人間に引き継ぐときに実際に使っていたものです。人間への引き継ぎのためにLLMに送っていたJSONの塊です。中身が膨大なのがおわかりいただけると思います。印刷してみたら、10ページもありました。10ページです。
私たちはこれをLLMに送っていました。LLMは判断を加えるので、ときにはうまくいかないこともありました。LinkedInで私がタグ付けされて、「ケースの作成がうまくいかない」と言われることもよくありました。MVPの皆さんからもSlackで「動いていない」と何度も連絡をもらいました。そう言われて当然です。ここはまさに真価が問われる場面です。お客様が人間の助けを求めた瞬間なのですから、ただ確実に動かなければいけません。それなのに、毎回確実には動いていなかったのです。
Agent Scriptに移行した今は、論理的なフローで処理しています。「この条件ならこうする、この条件ならこうする、そしてこのサポートエンジニアに回す」という形です。その結果、精度が上がり、信頼性も高まりました。さらに、ケースを作成するのにトークンを使う必要がなくなりました。トークンは、もっと難しい処理のために取っておけるようになったのです。
これは「確率的な決定論」とでも呼ぶべきものの好例です。確実に動かすべき部分は決定論的なロジックで処理し、LLMは本当に判断が必要な難しい部分のために使う、ということです。
9. Salesforce内ヘルプエージェントのデモ（Bernard Slowey、Emily Winslow）
9.1 業務の流れの中に入り込むヘルプエージェント
Bernard Slowey： 最後にお話ししたいのは、このヘルプエージェントに取り組んできた2年間で、私がおそらく最もワクワクしていることです。それは、ヘルプエージェントをSalesforceの製品の中で提供し始めたことです。
数週間前から、Salesforceの画面にある「？」マークのヘルプ体験をこのエージェントに置き換える形で、展開を始めています。私が特に気に入っているのは、このエージェントが利用者の文脈を理解している点です。あなたが誰なのか、今何をしているのか、どのページを開いているのか、エラーメッセージが表示されたのかどうか。こうした豊富な文脈をデータグラフに取り込み、それをもとにエージェントが動いています。
お客様はもうログインする必要がありません。すでにSalesforceにログインしているからです。ポータルに移動する必要もありません。すべてをSalesforceの中で完結できます。
それでは、実際のデモをお見せします。少し進め方を変えて、ヘルプエージェントのプロダクトリーダーであるEmily Winslowを紹介します。Emily、皆さんにご挨拶を。
Emily Winslow： 皆さん、こんにちは。
Bernard Slowey： ここからは、私がJohn Smithになりきります。私はSMB企業のサポートチームを率いていて、Salesforceを使い始めてまだ日が浅いという設定です。今、サービスコンソールを開いて、自分のチームのサポートチケットを確認しています。
すると、Salesforceの画面上にポップアップが表示されます。このポップアップは、先ほどお話ししたのと同じデータグラフから出ています。私がまだ有効にしていない機能の中に、オンにすれば業務をもっと効率化できるものがあると、エージェントが判断したのです。前の章でお話ししたアドプション用のサブエージェントが、ここで実際に動いているわけです。
このポップアップをクリックしてみます。すると、ヘルプエージェントがSalesforceの画面の中で立ち上がります。もうポータルに行く必要はありません。エージェントのほうが、私の業務の流れの中に入ってきてくれます。お客様がいる場所に合わせてスケールしているということです。
ご覧のように、その機能について説明してくれる、とても充実した体験が提供されます。どうすればその機能を有効にできるのかも教えてくれます。私が誰なのかを把握しているので、名前を呼んで個別に挨拶してくれます。ログインし直す必要もありません。さらに、エージェントと何度もやり取りしながら、その機能についてもっと詳しく質問することもできます。
これが、Salesforceの中で動くヘルプエージェントです。現在は段階的に展開しているところで、10月末までには、コア組織を利用しているすべてのお客様にご利用いただけるようになる予定です。私たちは本当に楽しみにしています。拍手をいただけたらうれしいですね。どうぞ、遠慮なさらずに。ありがとうございます。
それでは、最後のパターンに移ります。Joeにもう一度ステージに戻ってもらい、私たちの素晴らしいピープルオフィサーであるNathalieにも登壇してもらいましょう。Nathalie、ステージへどうぞ。ここからは、私たちが作り上げようとしている未来の人材について話してもらいます。Joe、よろしくお願いします。
10. 職務の再設計と未来に備えた人材（Joe Inzerillo、Nathalie Scardino）
10.1 技術変革は人の変革であり、すべての職務を再設計する
Nathalie Scardino： Joe、こんにちは。
Joe Inzerillo： こんにちは。ここで会うとは奇遇ですね。
Nathalie Scardino： 本当にそうですね。
Joe Inzerillo： 1年前、私たちはここに立っていました。正確にはこのステージではなく向こうの会場でしたが、気持ちのうえでは同じステージです。そのとき私たちは、「物事の進み方が本当に速い」と話していました。それが今では、さらに10倍の速さで進んでいます。たった1年前のことなのに、もう10年前のように感じます。
ただ、すばらしいと思うのは、こうした変化のすべてが人によって支えられているという点です。人材という資源がなければ、私たちが進めてきたような転換はできません。そこで、いくつかデータを用意しました。皆さんにお見せしたうえで、あなたがこれをどう見ているのか、自由に話してもらえればと思います。本当に驚くべきことが起きていますから。
Nathalie Scardino： 本当にすごいことです。昨年も話しましたし、今朝の基調講演を見た方も多いと思いますが、これは確かにテクノロジーの変革です。しかし、今日ご覧いただいたすべて、AdamやSebastianの話も含めて、根本にあるのは人の変革です。
そのため、私たちにとって最も大きな取り組みは、すべての職務を一つ残らず再設計することでした。もちろん、人事部門の働き方そのものも再設計しなければなりませんでした。データがそれを示しています。今後数年で仕事の70%が変わるといわれている一方で、84%のリーダーはまだ職務を再設計していません。テクノロジーやAIが進化しているのはすばらしいことです。しかし、ワークフローを根本から作り直さなければ、その価値は引き出せません。私たちが力を入れてきたのはまさにその部分です。
Joe Inzerillo： Markが基調講演で使った「自らが望む変化になれ」という言葉が、私はとても好きです。職務の進め方を作り直すという話でいえば、あなた自身も自分の仕事のやり方を作り直してきましたよね。これは、最初にお話しした「誰もが作れる」という原則につながる話です。
Nathalie Scardino： ええ、誰もが作れます。今では、すべての従業員の手元に豊富なインテリジェンスが届いています。だからこそ、おっしゃる通り誰もが作れるのです。私たちはそれを、Customer Zeroとしての自社の取り組みの中で実際に見てきました。
Salesforceは50か国で事業を展開し、従業員は9万人近くいます。この8か月で、そのうち約1万8000人が、以前には存在しなかった職務に就きました。まったく新しく生まれた職務です。エージェント型の営業、エージェント型の財務、サービス、マーケティングといった領域で、これは非常に大きな変化でした。
人事部門の中で、従来型のオペレーション業務を担っていた人たちも変わりました。彼らはもうケースの処理をしていません。代わりに、エージェントを活用した従業員体験を、業務の流れの中で、全社規模で従業員に届けるにはどうすればいいかに注力しています。
Joe Inzerillo： それはすばらしいですね。私の講演を見たことがある方はご存じだと思いますが、私はスライドが好きではありません。今日も結構な数のスライドをお見せしましたし、役に立つこともあるのですが、やはりデモのほうが好きです。あなたが私たちのチームと一緒に、RIZのモデルで作ったものを見せてもらえますか。
Nathalie Scardino： デモで見ていきましょう。「いつでもリアルタイム」ですからね、Joe。
11. NextGen HRオンボーディングとサポートのデモ
11.1 新入社員体験の変革と、Customer Zeroから製品への展開
Nathalie Scardino： これからご覧いただくのは、次世代型の従業員サポートです。従業員のライフサイクルの中でも特に大きな節目の1つが、入社時のオンボーディングです。Salesforceには毎週何百人、年間では何千人もの新しい仲間が入社してきます。
これまでは、新入社員が何かを手に入れるたびにチケットを起票し、「社用の携帯電話はどこで受け取ればいいのか」を自分で調べなければなりませんでした。そうした事務手続きや煩雑な作業に、あまりにも多くの時間が取られていたのです。そこで私たちは、オンボーディングの体験を根本から見直し、まったく新しいものに作り替えました。
こちらは新入社員のSarahです。彼女は今まさにオンボーディング中で、オフィスに初出社する前から社用の携帯電話が必要です。さらに、在籍証明書も必要としています。車を買う予定だからです。
Joe Inzerillo： いいですね、Sarah。
Nathalie Scardino： ですから、彼女にはすぐに届けなければなりません。どうやって手に入れればいいのか、何日もかけて考えている余裕はありません。彼女は、今日、今この瞬間に必要としているのです。
そこで登場するのがSlackbotです。Slackbotは、私たちの従業員体験にとって、これまでで最大の贈り物だといえます。人事オペレーションチームは自分たちの職務を再設計し、自らリスキリングを行いました。今の彼らの仕事は、Sarahが必要としているものを、必要な文脈とデータに沿って届けられるようにエージェントを訓練することです。
画面をご覧ください。Sarahは在籍証明書を必要としています。Slackbotは、依頼しているのがSarah本人であることを把握しています。彼女の権限設定も、関連するデータも、置かれている状況もわかっています。そのため、在籍証明書を数日ではなく数秒で提供できるのです。
これが全社規模で行われていると考えてみてください。節約できた時間をすべて従業員に返すことができます。これは私たちにとって、エージェントによって実現した非常に大きな成果です。
Joe Inzerillo： 本当にすばらしいですね、ありがとうございます。事業部門がIT部門と組み、小さなチームで素早くイノベーションを起こす。その組み合わせが、こうした成果につながっているのだと思います。本当にありがとうございました。
Nathalie Scardino： ありがとうございました、Joe。お会いできてよかったです。
Joe Inzerillo： こちらこそ。
今ご覧いただいたのは、ある意味で私たち自身の強い意見に基づいた取り組みです。データもいくつかお見せしましたが、これもSalesforceのCustomer Zeroとしての取り組みの一部です。私たちは自分たちの課題を解決するだけで終わらせず、それを製品という形にしています。
Nathalieが今見せてくれたものの多くは、HR Serviceに、特にSlack上での体験として取り入れられています。とても面白い製品で、まだその可能性のほんの一部に触れたにすぎません。まず自分たちの課題を解決し、それを皆さんの課題の解決にもつなげる。これはその好例です。
ここまでがCustomer Zeroとしてのデモです。ただ、どうしても我慢できず、お客様にも来ていただくことにしました。
12. PenFed Credit Unionの事例と統合プラットフォーム、および総括
12.1 シンプルさを原則とした統合デジタルバンキング基盤とエージェント活用（Shri）
Joe Inzerillo： Salesforceはお客様が大好きで、お客様が成し遂げたことを紹介するのも大好きです。まずはこちらの言葉から始めたいと思います。これはPenFed Credit UnionのCEOであるJamesの発言です。PenFedは名前の通り、国防総省の関係者のための信用組合です。規制産業であり、政府にも関わる組織ですから、イノベーションの最前線にいるとは普通は思わないかもしれません。しかし実際には、彼らはまさにその最前線にいます。
この言葉は、PenFedの決算説明会で語られたものです。私たちは「損益計算書に反映される価値を届ける」と言ってきましたが、PenFedはそれを決算説明会の場で語っているわけです。CEOは本当にすばらしい人物で、ビジョナリーとしてこの取り組みを推し進めてきました。ただ、皆さんもご存じの通り、実際に仕事を形にしているのはCIOです。そこで、Shriをステージにお迎えして、その話を聞かせてもらいたいと思います。
Shri、来てくださって本当にありがとうございます。あなたの道のりは、ある意味で大変なものだったと思います。ビジョナリーなCEOが強く背中を押してくる一方で、CEOが自信を持って押せるのは、あなたがこれまで成果を積み重ねてきたからです。どんなことから取り組み始め、それがどう広がり、CIOとしての取り組みが決算で語られるところまで来たのか、その道のりを聞かせてください。
Shri： Joe、ありがとうございます。この場に立てて本当に光栄です。実は、これは皆さんが思っているよりずっと簡単で、ずっと速く進むものです。その秘訣は常にシンプルさにあります。そして、シンプルさがもたらす最大の見返りがスピードです。
背景からお話しします。私たちの取り組みは約5年前に始まりました。そのとき、変革を進めるうえで最も大切な指針として掲げたのが「シンプルさを追求する」ことでした。その指針に従って進んだ結果、私たちはSalesforce上に世界初の統合デジタルバンキングプラットフォームを築くことができました。ここは拍手をいただくところですよ。
ありがとうございます。具体的には、400を超えるアプリケーションをSalesforceに集約し、5〜6種類あったAPI技術をMuleSoftに統一しました。そして、フェーズを重ねるごとに進むスピードが上がっていきました。
最初のフェーズは支店とコールセンターの変革で、これには約2年かかりました。その後すぐに、同じ技術スタックの上で、それまでに作った資産を再利用してオンラインバンキングのプラットフォームを変革しました。こちらは9か月もかかりませんでした。次のフェーズはモバイルアプリで、変革にかかったのは6か月未満です。そしてつい最近、最初のエージェントを2週間足らずで立ち上げました。
今では、この統合デジタルバンキングプラットフォームが、すべての商品とすべてのチャネルを支えていて、300を超えるデジタル資産があります。データもセキュリティの仕組みもあらゆる資産も、1つの基盤、同じプラットフォームの上にそろっていると、AIを導入するのはずっと簡単になります。既存のワークフローの中でエージェントを有効にするだけで済むからです。これこそが、私たちの戦略がもたらした最大のメリットです。
これから取り組もうとしている方に向けて、いくつか私なりの考えをお伝えします。1つ目は、まず社内向けの用途から始めることです。そこで信頼と自信を積み上げ、その成熟度を持って社外向けの用途に進むのがよいと思います。
私たちが最初に手がけたのは、IT部門向けの従業員エージェント「Agent Penny」です。Agent PennyはITサービスデスクへの問い合わせの80%以上をその場で解決し、年間でおよそ200万ドルのコスト削減につながっています。
2つ目のユースケースは通話の要約です。PenFedでは1日におよそ1万件の通話を受けています。そこで導入したのが「Agent Wingman」です。トップガンにちなんだ名前で、嫌いな人はいないと思います。
Joe Inzerillo： いい名前ですね。
Shri： Agent Wingmanは、1件の通話ごとに約3分を短縮しています。1日に換算すると、およそ3万分の削減になります。
私が伝えたいのは、シンプルさを追求してほしいということです。複雑さは、スピードにも、イノベーションにも、セキュリティにも重くのしかかる最大の税金です。その複雑さを取り除けばスピードが手に入り、そのスピードが成功をもたらしてくれます。
Joe Inzerillo： 本当にすばらしい話でした。今朝の基調講演でMarkも言っていましたが、私たちがここでやりたいことの1つは、皆さんにインスピレーションを届けることです。そして、私自身がインスピレーションを受けているのは、すばらしい仕事をしているお客様たちです。その道のりの一端を共有してくださって、本当にありがとうございました。
12.2 総括：講演全体の振り返りとDreamforceでの学びの案内
Joe Inzerillo： では、そろそろまとめに入ります。今日お話ししたことを振り返っておきます。
まず私たちは、皆さんが自由に使い、カスタマイズできるプラットフォームを作っています。組織の全員がものを作れるようにするためです。AI Force、Slackbot、コワーカーといったものは、いずれも「誰もが作れる」という民主化を実現するために私たちが提供しようとしているものです。
次に、RIZの事例を通じて、IT部門と事業部門の関わり方をどう作り直せば、小さなチームで素早く進み、価値を継続的に届けられるのかをお見せしました。皆さんの参考になればと思っています。
また、IT部門がプラットフォームを提供して事業部門と組むというこのモデルの中で、事業部門のステークホルダーが自分たちの望むビジョンを、これまでよりずっと速く主導できるようになることもお話ししました。これはAdamの話で具体的にご覧いただいた通りです。
Bernardの話では、これをカスタマーサービス全体にどうスケールさせるのかを見ていただきました。皆さんもすでにSalesforceの画面上でCaseyを体験されているか、これから体験されると思います。お客様がいる場所に、適切なテクノロジーで寄り添うことは非常に重要です。
そしてNathalieとの話では、未来に備えた人材を築くために、私たちがリスキリングと社内で起こしたい変化をどう考えているかをご紹介しました。
かなり多くの情報をお伝えしましたが、実際にはまだまだ詳しい話がたくさんあります。そこで、いくつかご案内させてください。
まず、こちらのQRコードを読み取っていただくと、「エージェント型エンタープライズをどうスケールさせるか」というガイドをご覧いただけます。今日お話しした内容を、より詳しくまとめたものです。さらに特典として、昨年このセッションに参加できず前半の話を聞けなかった方のために、昨年のガイドの改訂版も含めています。まだ取り組みを始めていない方は、まず昨年のガイドを読んでから、この第2巻を読んでみてください。こちらはさらに良い内容になっています。
次に、私たちは皆さんがいる場所、つまりこのDreamforceの会場で、直接お会いしたいと考えています。こちらのQRコードからは、Customer Zeroの事例を紹介する100以上の体験プログラムをご覧いただけます。今日お見せした内容や私たちの取り組みをテーマごとに細かく分け、それぞれをより深く掘り下げられるようにしました。60を超えるシアターセッションがあり、デモブースもあります。
まだキャンプグラウンドに行っていない方は、ぜひ足を運んでみてください。まず何より、見ているだけで楽しい場所です。会場の中に森のような空間を作るなど、思い切った仕掛けをたくさん用意しています。本当に一見の価値があります。そこでは、実際にこの取り組みを担っている人たちと話すことができます。私たちのIT部門の現場のメンバーも連れてきていますので、ぜひ直接話を聞いてください。実際にキーボードに触れて、こうした取り組みの一部を自分で体験することもできます。ぜひ参加してみてください。
さらに、ラーニングラボもご用意しています。Markが基調講演で紹介した新しい製品群にも、Customer ZeroとしてのDNAが織り込まれています。
最後に、皆さんの貴重な時間をいただき、本当にありがとうございました。そして、私たちを信頼してくださっていることにも感謝しています。もしお時間があれば、ぜひフィードバックをお寄せください。皆さんのために、私たちがもっと良くなるための糧にします。ありがとうございました。残りのDreamforceも楽しんでください。