※本記事は、Intercom CTOのDarragh Curran氏による講演「How Intercom Doubles Down on AI」の内容を基に作成されています。本講演は、2026年3月12日にアイルランド・キルケニーのLyrath Convention Centreで開催された第5回AWS AI and Data Conference 2026にて収録されました。イベントの詳細情報は https://go.aws/events でご覧いただけます。本記事では、講演内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講演映像をご視聴いただくことをお勧めいたします。
1. イントロダクションとIntercomの変革前夜
1.1 Intercomの歩みと成長の停滞
Darragh Curran： 今日は、真の変化を受け入れ、それを加速させるというテーマでお話しします。私たちは人生の中でおそらく最も劇的な変化の時代のただ中にいると思うのですが、あまりに多くの人がハンドルを握ったまま居眠りをしているように見えます。そして、その結果として、個人としても会社としても、痛い目に遭うことになるでしょう。もし私が今日一つでも皆さんにこのことを真剣に受け止めてもらうきっかけを作れたら、それだけで十分嬉しく思います。
Intercomは、この時代が来る前に生まれた会社でありながら、この時代のために自分たちを再発明した、いわばポスターチャイルドのような存在になりました。簡単に紹介しますと、Intercomは2011年に設立された会社で、本質的にはカスタマーサービス向けのソフトウェアを提供しています。私たちのミッションは、お客様が体験するすべてのやり取りを完璧なものにできるという考え方です。私自身は2012年2月にIntercomへ入社しました。当時AWSで良い仕事に就いていたのですが、それを辞めての転職でした。今振り返れば、キャリアの休憩のつもりが、気づけば14年も経っていたわけです。
入社してからしばらくは、売上が100万ドルから3年で5000万ドルに成長するという、当時としては誇らしい急成長を遂げました。しかし、やがて成長が止まる時期を迎えます。マクロ環境なども言い訳にはできるかもしれませんが、実質的には成長が劇的に鈍化し、ほとんど縮小しかけていました。当然ながら、私たちは何かを変えなければならなくなり、CEOを交代し、創業者であるCEOが復帰することになりました。ところが、その直後にChatGPTがこの世に登場したのです。
1.2 ChatGPT登場という転機
Darragh Curran： 私たちは以前からずっと「もっと良いAIモデルが欲しい」と願い、カスタマーサービスを自動化するための優れたAIシステムを何年も作ろうとしてきました。そこにこの技術が現れて、最初は「これは自分たちにとって好都合だ」と考えていました。しかし、点と点がつながっていくと、恐ろしい事実に気づきます。私たちのビジネスは、人々の質問に答える手助けをすることの上に成り立っていたのに、この技術は基本的な質問には瞬時に答えてしまうのです。
最初は「いや、これはおもちゃに過ぎない。私たちのビジネスは複雑で、あらゆる言語、あらゆるタイムゾーンに対応しなければならないから」と思いました。しかし、それすらもあらゆる言語、あらゆるタイムゾーンで機能することが分かりました。「でも、私たちは質問に答えるために必要なデータへのアクセス手段を持っている」と思えば、今度はそれがリアルタイムでデータを読み込み、新しい情報を学習してしまう。「複雑なワークフローなら、こちらに分がある」と思えば、それも明らかにできないはずが、いつの間にかアクションまで取れるようになっている。ハルシネーションを起こすという弱点についても、「それを起こさないものを作ればいい」「止める方法はある」というだけの話でした。私たちは常に興奮と、途方もない不安の両方を抱えながらこの状況を見つめていました。
そうして私たちはすぐに、自分たちの古いビジネスは事実上「死んだ」のだと気づきました。もちろん瞬時に起きることではありませんが、それでも死んでいたのです。そして唯一のチャンスは、このAIの新しい世界の中でビジネスを再発明することでした。これを本当に実感してもらうために言うと、私たちが売っていたのは、カスタマーサポートチームが座ってカスタマーサービスを行うための製品でした。AIはその業務の大部分を代替できるようになっていました。もしそれが本当に可能なのであれば、私たちが作らなければ、誰か他の会社が作ってしまう。だから、私たちは作らなければならなかったのです。そして、非常に短い期間でこれをやり遂げるという決断をしました。
2. Finnの開発とSaaS業界の危機
2.1 Finn開発の経緯と成果
Darragh Curran： 私たちは短い期間でやり遂げるという覚悟を決め、そこからおよそ4か月ほどでFinnをローンチしました。しかも、それはGPT-4がローンチされたのとまさに同じ日でした。Finnはカスタマーサポート業務の大きな部分を自動化できるものであり、早期に導入してくれた企業にとってはゲームチェンジャーとなりました。私たちはこのプロダクトの性能や品質を継続的に改善していけるように、実験のための仕組みを構築し、それを絶え間なく回し続けました。
最初のバージョンもゲームチェンジャーでしたが、そこからさらに良くなっていきました。しかもこれは線形なスケールではなく、上に行けば行くほど作業は難しくなっていくという性質のものです。9月頃、私たちは週間で100万件のこうした解決を達成するというマイルストーンに到達しました。私たちは何かを解決できたときに報酬を得るというモデルを取っており、これがずっと私たちの北極星でした。今では何十億件ものこうした解決を行っており、何千もの企業がこの猛烈なペースでFinnを利用してくれています。この2年ほどの間に、私たちはコアアーキテクチャを何度も反復させてきました。
現在では、汎用モデルを上回る性能を持つ、自社に特化したモデルを構築するところまで来ています。多くの素晴らしい企業がFinnを選んでサービスを運用してくれていますが、私たちのビジョンはさらに広がっています。eコマースの領域では、いわばパーソナルショッピングアシスタントのような形でファネル全体に自動化を広げようとしていますし、セールスファネルの領域でも、すでにベータ顧客との間でコンバージョン率に対して段階的な変化と言えるほどのインパクトを生み出しており、何百万、何千万という規模のパイプラインを新たに生み出しています。こうして、顧客のライフサイクル全体をより良いものにし、完璧な体験を実現するというビジョンを、実際に形にしつつあります。
2.2 SaaS業界の危機と自己変革
Darragh Curran： ここまでお話ししてきたのは、SaaSの世界が私たちの周りで崩れ落ちていく中で、私たちがどのようなプロダクトおよび戦略上の変化によって成長を加速させることができたのか、その背景です。私自身は公開されているSaaS企業の株式をいくつか保有していますが、今その状況はひどいものです。もしあなたがそうした企業に属しているなら、指をくわえて幸運を祈るというのは正しい戦略ではありません。唯一の道は、自らを積極的に破壊し、再発明する意志と能力を持つことだと私は考えています。
そうしなければ、事実上、死んだも同然です。私は死にたくありません。生きることが好きですし、成長し続けるビジネスの一員でありたいと思っています。あのグラフは、適応しなければ何が失われるのかを示す証拠にほかなりません。これは会社にとっても、私たち個人のキャリアにとっても、まさに生きるか死ぬかの分かれ道です。Finnは私たちにとって命綱でした。私たちの生存に不可欠な存在であり、もし積極的にピボットしてこのプロダクトへの投資を行っていなければ、今日ここに私たちは存在していなかったでしょう。
ただし、Finnがあるからといって、それだけで成功が保証されるわけでは決してありません。それはせいぜい試合に出るための切符を手に入れたようなものであり、これから実際に結果を出さなければなりませんし、世界は今なお劇的に変化し続けています。今重要なのは、どれだけ速く実行できるかということです。これは昔から変わらず重要だったことですが、AIがそこに大きな役割を果たすようになりました。良い知らせがあるとすれば、私たちの経験から言えば、変えなければならないのはただ一つ、絶対にすべてだということです。それは簡単なことですよね。プロダクトも、企業文化も、ビジネスの測り方も、リーダーシップの取り方も、あらゆることです。もちろんこれで全部というわけではありません。
正直なところ、私は途中で息切れしてしまいましたが、本当にすべてを変えなければなりませんし、その道のりでは至るところで抵抗に遭うでしょう。ただしその抵抗は「それは間違っている」という類のものではなく、「それはそうかもしれないけれど、今はまだ」という、厄介な種類の抵抗です。それでも、これらすべてを変えなければなりませんし、そのために戦わなければなりません。結局のところ、私たちは適応するか、あるいは無関係な存在になり惨めに衰退していくかという選択を突きつけられているのです。そして適応するためには、自分たちを今の場所まで導いてきたものであっても、それを破壊し、あるいは作り直す覚悟を持たなければなりません。
3. ソフトウェア開発のやり方そのものを変える
3.1 穴掘りの比喩と重機への転換
Darragh Curran： さて、これは前置きでした。ここからは、私たちがソフトウェアの作り方そのものをどう変えてきたかについて、もう少し詳しくお話ししたいと思います。まず土台となる考え方として、穴掘りの比喩を使わせてください。私たちは誰もが時々、穴を掘るという作業をしています。穴掘りの生産性には昔からある程度の幅があって、ほとんどの人はこの範囲の低い方に位置していますが、時折、他の人より10倍も多く掘れる、非常に優れたシャベル使いが現れます。
AIは今、この状況を変えつつあります。AIにただ身を任せれば、これまで10倍の時間がかかっていたことが1倍の時間でできるようになるかもしれません。ただし、これは一種の罠です。実際に起きているゲームの変化はもっと根本的なものです。もはやシャベルが道具ではなくなっているのです。今の道具は重機であり、シャベルよりもはるかに速く穴を掘ることができます。しかもその差は一桁ではなく、何桁にもわたるもので、私たちにはその大きさを本当の意味で理解しきれていません。今、目指すべき目標地点はずっと上に引き上げられているのです。そこを目指すことができれば、途方もない報酬とチャンスが待っています。
ついでに言うと、重機というものを人が座って運転するものだとイメージするのも、おそらく間違っています。これらの機械は自ら動くようになっていくものです。今、私たちの多くはおそらくシャベルに寄りかかって満足し、世界が変わっていないふりをしているのではないでしょうか。自分のピカピカのシャベルを眺めて悦に入っている一方で、他の人々は重機の群れを操って先へ進んでいます。人は目の前に現れた天井がどれほど高くなったのか、その範囲を理解することに本当に苦労していると思います。ですから、話は結局「適応するか死ぬか」に戻ります。つまり、新しい道具の使い方を見つけるか、自分で自分の墓穴を掘るかのどちらかなのです。
3.2 生産性倍増という目標設定
Darragh Curran： 今からおよそ1年ほど前、私にとって、ソフトウェアを作るという仕事の役割そのものが根本的に変わったのだということが、かなりはっきりと見えてきました。たとえ技術がそれ以上進歩しなかったとしても、すでにゲームは完全に変わってしまっていた。私はこの変化に対して意図的に向き合い、それが自分たちに起きるのをただ待つのではなく、自分たちからそれを推し進めていこうと決意しました。
そこで私は、1年で自分たちの生産性を倍にするという目標を掲げました。大したことではありません、と言いたいところですが、実際には非常に難しい目標です。おそらく、これを達成するにはチームの規模を3倍にしなければならないところを、それだけのお金と時間をかけずにやろうというものでした。同時にこの目標は、野心的でありながら、まったく野心的とは言えないものでもありました。なぜなら、重機はすでに登場しているということを私は知っていたからです。
私はこの緊張関係と常に格闘してきました。2倍にするということは、私の頭の中では、地に足をつけて動き出すための不可欠な最初の一歩であり、そこから先に加速していくためのものです。そして、これがおそらく最も難しいステップでもあります。難しい挑戦において、始めることそのものが一番大変な部分であることが多いからです。私はこの取り組みがどのように進んだのか、何がうまくいったのか、何を違うやり方でやるべきだったのか、そこから学んだことを皆さんと共有したいと思います。おおまかに言うと、この9か月ほどの期間は、3つのフェーズに分けて捉えることができます。最初のフェーズは、「みんな、これが起きている、好奇心を持とう」という段階でした。
4. 変革の3フェーズ
4.1 フェーズ1：自由放任的な奨励期
Darragh Curran： 最初のフェーズは、「みんな、これが起きているんだから、好奇心を持とう」という段階でした。人々にすべてのツールを買わせ、オープンマインドで色々と試すことを促し、プレッシャーを取り除いて、そのための余地を与えました。そして、誰にもお金を使うことを妨げさせないようにしました。当時、多くの同業者から「チームの何人かにCursorのライセンスを取るべきかどうか」と相談されたのを覚えていますが、私たちは「白紙の小切手を渡すからツールは全部使え」というスタンスでした。うちの財務チームからは、お金を使いすぎだとずいぶん文句を言われたものです。ただ、今ではその財務チームの面々が誰よりもClaude Codeにのめり込んでいて、もう私に文句を言わなくなりました。
このフェーズは重要な段階だったとは思いますが、インパクトという点ではそれほど大きくはありませんでした。私たちが目にしたのは増分的な、もちろん歓迎すべきではあるものの、何かを根本から変えるほどではない成果でした。実際の働き方を大きく変えるには至らなかったのです。重要なのは、標準化や複利的な積み上がりがほとんど起きなかったこと、そして採用の度合いも平凡だったということです。誰もが常に新しいことを学びたいと思っているわけではありませんし、そう感じる余裕を持てるほど余裕のない人も多いということが分かりました。
私たちはこのフェーズにいくつかの教訓を得て幕を引きました。第一に、この変化は自然発生的には十分な速さで起きないということです。自分たちで推し進めなければなりません。コミュニティによる自主性に任せるモデルではそこに到達できず、違うアプローチを取るために厳しいトレードオフを受け入れる必要がありました。具体的には、私たちの中でも最も優秀な人材を3人選び、それまで最も重要だった仕事から外して、これだけに専念してもらうことにしました。そして、それぞれが好みのツールを使うのを許すのではなく、一つのツールを選び、意見を持って、そのシステムに全力で賭けることにしました。
選択肢が多いことは一見良いことのように感じられます。あらゆるツールの良いところを取れるとか、人によって得意なツールが違うといった具合です。しかし実際にはそうではないことがほとんどです。ですから、思い切って一つのツールを選んだことが、大きな進展を生み出す鍵になりました。将来的にはツールは収斂していくだろうとは思っていますが、一つを選ぶこと自体が、その裏にある本当の課題を解決することを可能にしてくれます。もう一つの大きな教訓はテレメトリーへの投資です。これは一般的に有用なことですが、この変化に関しては特に、人々があまり目を向けてこなかったり、居心地の悪さを感じたりする側面を見えるようにしてくれます。チームがどのように働いているか、ボトルネックはどこにあるか、実際にツールを使っているかどうか。誰もが「使っている」と言うでしょうが、指標を見ると別の実態が見えてきますし、それによって正しい問いを立てられるようになります。データを実際に深く掘り下げられる能力を持つこと自体に、大きな価値があったと感じています。
4.2 フェーズ2：オピニオネイテッドな推進期
Darragh Curran： ここからフェーズ2に入ります。私にとってこれは、ほんの数週間前、つまり年始か去年の年末あたりに始まった段階で、「よし、これからは意見を持って、強く推し進めよう」という転換点でした。それは、誰もが年末年始に休みを取っている間に世界が変わったと感じられる、あの変曲点の時期と重なっていました。当時のOpusモデルやClaude Codeの進化は本当に一つの角を曲がった感覚があり、「これは私の仕事の一部をこなせる」という程度の興味深さから、「もうエディタの中にいない、ほとんど全部をこなせる」という驚愕へと変わっていきました。このタイミングは偶然でしたが、私たちはすでに一つのシステムに意見を持って全力を注いでいる段階に入っていて、そのシステム自体がほとんど一つのプロダクトのような存在になっていました。
そこで私たちは、このシステム、つまりエージェントと共に働くための原則をいくつか導き出しました。一つ目は、当たり前のようでいて見落としがちなのですが、エージェントをシニアエンジニアのようにオンボードするということです。新しく入ったエンジニアに適切なコンテキストやツールを与えなければ、良い仕事を期待できないのと同じことです。前のフェーズでは各エンジニアが自分自身でこれをやることに任せていましたが、実行した人はある程度の恩恵を得られたものの、ほとんどの人はやりませんでした。だから、一度きちんとやれば全員がその恩恵を受けられます。私たちの場合、これは全社員のコンピューターに自動的にデプロイされ、常に更新され続ける一連のプラグイン群という形を取りました。何か改善を加えれば、全員が即座にその恩恵を受けられる仕組みです。
そしてもう一つの視点の転換として、私たちの仕事の一部は、このエージェントを継続的に訓練し、その仕事、つまり私たち自身の仕事をよりうまくこなせるようにすることだと捉え直しました。どんなチームにも、ある特定の分野で並外れて優れた人が何人かいるものですが、このエージェントのシステムは、チームの中にあるベストな強みの総和になり得るのです。具体的には、あることをどうやるか、障害調査をどう進めるか、あるいは良いプルリクエストの説明文をどう書くか、こうしたことをスキルとして encode していくことです。私たちが範囲外だと思っていたようなことでも、実に多くのことが繰り返し使えるスキルとしてコード化できることに驚かされます。ある例を挙げると、プロダクトのビジュアル部分を担当しているチームは、QAのやり方をこう変えていました。2、3人がコールに参加し、画面を共有しながら通話を録画し、実際にプロダクトを操作しながら、うまくいっていない点を何でも声に出して話すのです。それがビジュアル的な問題であれ、挙動のバグであれ構いません。そして、彼らが構築したスキルのおかげで、そのコールの副産物として、エージェントが通話内容を解析し、指摘されたすべての問題点をスクリーンショットや動画の断片として捉え、それを別のエージェントへの入力として渡し、その別のエージェントが実際に修正を行うのです。QAの部分自体もエージェントに置き換えられる可能性はありますが、いずれにせよ、こうした個々の作業はすべて分解して自動化することができます。
ここで重要な原則がもう一つあります。AI製品においては、あらゆる利用そのものがそのプロダクトの性能を改善するための燃料になり得るというのと同じように、こうしたシステムにも同じことが言えるということです。システムを通過するすべての変更が、それを収穫して改善するための潜在的な原材料になります。つまり、日を追うごとにシステムが改善していく、フライホイールのような構造ができあがるのです。私たちが取り組み始めてから6週間から8週間ほどの間の進捗を振り返ると、これはおそらく、私がこれまでに作ったどんな製品や取り組みよりも変化の速いものだったと言って差し支えないと思います。しかも、それはまだ始まったばかりです。
このフェーズからのもう一つの教訓は、大きな行動変容が必要になるということです。私たちは基本的に全員、自分の仕事のやり方を学び直さなければなりません。5年前のエンジニアとしてのやり方を知っていることが、むしろ不利に働くことすらあります。もっと根本的に優れた、より最適なやり方が存在するのです。スキルの多くは今も十分通用しますが、習慣ややり方はそうではありません。行動変容そのものが、リーダーシップにとっての本質的な仕事、核心的な課題になります。私たちがこれを完璧にやれているとは思いませんが、私たちが取ったアプローチは、まずそれを楽しくすることでした。私たちは好奇心が強く学ぶことが好きな人材を数多く採用していますから、そこを楽しくしようとしました。
具体的には、私たちのプロダクトはFinnであり、これはカスタマーサービスを行うAIプロダクトです。そこで、私たち全員でFinnを一から作ってみようという試みをしました。完全にゼロからというわけではありませんが、実際にAIシステムを作るとはどういうことなのか、たとえば、最初はぎこちない受け答えしかできないものから始めて、アルゴリズムやアーキテクチャを改良しながら段階を登っていく、その過程を体感するというものです。裏側ではLLMによる審査員が提出物を採点する仕組みを作り、これをゲームにしました。指令は「全員がこれをやる」というもので、数週間の期限を設け、チームで一緒に取り組んで楽しんでもらいました。この結果として、R&D組織全体、およそ450人にのぼる全員が、エージェント型のツールを使ってAIプロダクトを実際に作った経験を持つことになりました。これは他のどんな会社でもまず実現できていないことだと思いますし、小さなことのようですが重要です。なぜなら、私たちは新しい世界で、根本的に違うプロダクトを、根本的に違う作り方で作っているからです。これをやるまでは、おそらく組織の中でも先進的な2割ほどの人しかこれに触れていなかったでしょう。しかも、これはエンジニアだけの話ではありません。エグゼクティブアシスタントやAV技術者、マーケターまでもが激しく競い合い、エンジニアたちを打ち負かすことすらありました。楽しい取り組みでしたし、これは全員に対して「アハ体験」を強制的に起こそうとする、私たちなりの試みでした。おおむねうまくいったと思います。
もう一つ大事にしたのは、これを「仕事の一部にする」ということです。私たちは組織として、こうした目標を掲げました。たしか2月4日か6日あたりだったと思いますが、「2月末までにPRの80%をClaude Codeによって駆動させる」という目標を立てました。誰もエディタを所有せず、すべてエージェントによって駆動される状態です。この目標を掲げた当時の実際の数字はおそらく20から30%程度でしたから、これはかなり野心的な目標に感じられました。しかし後から振り返ると、まったく野心的とは言えないものでした。私たちはこの目標を大きく上回り、今ではClaude Codeによって駆動されるPRの割合は90%台に達していますし、この期間のスループットは20%どころか、それをはるかに上回る伸びを見せました。ただし、この道のりのどの時点であってもチームに「これは妥当な目標だと思うか」と尋ねれば、支持的な声にかき消されつつも、「いや、そんなの無理だ」という声が確実にあったはずです。しかし、結局のところできるのです。
4.3 フェーズ3：システム思考への移行
Darragh Curran： フェーズ3は、もう少し抽象的な捉え方になりますが、この1、2か月の間に一夜にして起きたような感覚の転換です。それは、R&Dというものが「プロダクトを作る人間の機械」であるという捉え方から、実際には「プロダクトを作る機械を作る機械」であるという捉え方への転換です。そもそもR&Dの目的とは、戦略を何らかの形でプロダクトや顧客へのインパクトに変換することです。興味深いのは、「コードを書くことはもはやほぼ無料だ」という物語がある一方で、ほとんどの組織がこの分野で実際には速くなっていないということです。多くの人は「コードを書くことは大変な部分ではなかったのだ」と懐疑的でしたが、これをシステムとして捉え、ボトルネックが取り除かれたことに気づくと、では他に何が私たちの足を引っ張っているのかを検証し始めることになります。
そこで今私たちがいる段階は、これを本当にシステマティックに考えようとしている段階です。アプローチとしては、システムにかけるプレッシャーを増やし続け、どこに漏れやボトルネックがあるのかを見つけ出し、それを修正し、そしてまた繰り返すというものです。これに対する良い視覚的なアナロジーがあると思っています。すべてのロケットエンジンは同じ仕事をしているのですが、それぞれの世代を経るごとに、よりシンプルで効率的なものになっていきます。残念ながら、多くのソフトウェアエンジンはRaptor 1のような状態のままで、本来Raptor 3にならなければならないのです。そこに至るプロセスとは、いわば多くのロケットを打ち上げ、そのすべての回から学び続けるようなものだと思います。
これまで私たちがやってきたのは、コードを書く部分にプレッシャーをかけることでした。これはある意味、取り組みやすい部分ではありますが、それでもその中にすら最適化の余地は驚くほどたくさんあり、放っておいて自動的にゼロになるようなものではありません。しかし、これに取り組むと、次第に他の明白な問題にぶつかっていきます。たとえばコードレビューです。そもそもコードレビューとは何のためにあるのか、私たちは何をそこから得たいのか、この部分がスピードを落とすだけの存在になっていないか、どう変えられるのかを問い直す必要があります。デプロイについても同様で、しっかりと整備されたデプロイパイプラインを持っていない人には同情します。なぜなら、これまでの取り組みの恩恵を本当に受けようとすれば、これまでよりもはるかに速いペースで変更をリリースしていくことになるからです。
それに慣れる必要がありますし、もっと些細なことにも気を配らなければなりません。たとえば、十分な品質に達していないソフトウェアを出荷したときには、それを人々に伝えなければなりません。ドキュメントを書くのは誰も好きではありませんが、サポートチームやセールスイネーブルメントチームへの情報共有なども絶えず発生する仕事です。しかし、これらもかなりの部分が自動化可能です。ですから、システム全体を見渡して、漏れやボトルネックを探し続ける必要があります。チューブがどこかで破れているとき、圧力をかければ漏れは早く見つかるのと同じで、ここにはシンプルさと効率化のための大きなチャンスが眠っています。
ここで注意すべき罠が一つあります。人はシャベルで速く掘っているだけなのに、それをすごい速さで穴を掘っていると言い、自分自身も気持ちよくなり、あなたのことすら説得してしまうかもしれません。しかし、それは罠です。ここで本当に求めるべきスピードの得方は、より速くシャベルを使うことではありません。重機に持ち替えること、つまりより高い抽象度で作業できるように移行することなのです。
5. リーダーシップに関する考察
5.1 リーダー自らが変わる重要性
Darragh Curran： そろそろ終わりに近づいてきましたが、リーダーシップに向けて、いくつか他の考察もお伝えしておきたいと思います。これは私たち全員が心に留めておくべきことだと思います。まず一つ目は、変化はまず自分自身から始まるということです。これはどこか自己啓発めいた話に聞こえるかもしれませんが、私たち全員が今の地位にいるのは、もはや存在しない世界で経験を積んできたからです。私たちは皆、デフォルトの状態では無関係な存在になりつつあるのです。私はこれをただ受け入れ、それと折り合いをつけることが良いことだと思っています。
では、再び関連性のある存在に戻るにはどうすればいいのか。そして、自分の経験を違う形に再構成して活かすにはどうすればいいのか。その答えは、もう一度自分の手を汚しに行くことだと思います。うちのファイナンスチームは、まさにそれをやっています。全員が新しいツールを使い始め、最初はターミナルを使うことへの恐怖を克服するのに数週間かかりましたが、今ではそれを使いこなし、楽しんでいます。私自身、ソフトウェアエンジニアとして、チームを作ることと並行してこの役割を始めたときは、非常に多くの仕事をこなしていました。それが自分の育ってきた世界であり、自分の役割へと成長していった過程でした。しかし、あるときから私は多作ではなくなっていきました。もう実際の仕事をしていないということに、自分でも薄々気づいていました。ある程度ごまかすこともできましたが、実際の仕事をしていなかったのです。
私が取っていたある種の対処法は、人々と話し続けることで、それを通じて感覚を保とうとすることでした。しかし、本当に役に立ち、実際に何が起きているのか、どう前進を促せばいいのかを正しく理解させてくれた唯一のものは、もう一度エンジニアに戻ってみることでした。特に、昨年末に訪れたあの変曲点のあたりでそれを行いました。私がこれを実行するたびに、あるいは私がチームの誰かにこれをやるよう促すたびに、彼らは自分のチームを実際にどうリードすればいいのか、驚くほど多くの明確さを得て戻ってきます。そして、そのたびに私は、ほとんどのリーダーがいかに現場から離れてしまっているかを痛感させられます。実際に手を動かしていないのです。そして、それはいずれ痛い目を見ることになります。
もう一つの教訓は、もっと強く後押ししなければならないということです。少し前までは、ソフトウェア企業におけるリーダーシップの役割とは、従業員のためにできる限り快適な環境を作り、彼らが望むものをすべて与えることだと考えられていました。それをしなければ辞めてしまうかもしれないという恐れからです。しかし今は、その逆が正しいのです。従業員が素早く適応するように後押ししていないのであれば、それは彼ら自身にとっても、あなたの会社にとっても、大きな不利益をもたらしています。私は常に、自分が十分に強く後押しできていないのではないかという不安と居心地の悪さを感じています。なぜなら、自分がほぼ間違いなく十分に押せていないと分かっているからです。そしておそらく、皆さんも自分自身やチームをどれだけ強く後押しできているか、多少なりとも自分に嘘をついているのではないでしょうか。
ですから、私はそのことに正面から向き合うことを皆さんに勧めます。誰もが常に変化に抵抗するものであり、それは単なる人間の本性です。もし人々に対する期待を変えなければ、誰も変わりません。しかし、そうすれば、ほとんどの人はほとんどの場合、その挑戦に応えることができます。適応するか死ぬかという選択しかないのだと受け入れられるのであれば、人々を強く後押しして適応させる義務があると私は思いますし、もちろん自分自身に対しても同じことが言えます。
5.2 組織構造の変化
Darragh Curran： もう一つ言えるのは、私たちの組織、あるいは今日会社を新しく立ち上げたとしたら、5年前に私たちの会社を見たときとはまったく違う形になるだろうということです。そして、デフォルトの慣性というものは、意図的に何かしらの変化を強制しない限り、来年も会社が今年と同じ形を保ち続けるという結果をもたらすと思います。一つの見方として、私たちのような長く続いてきた企業は、PM、デザイン、エンジニアリングという三位一体のスキルセットを軸にチームを構成してきました。しかし、コードを書くことがかなり安価になったことの結果として、この構造の多くが実質的に崩れて一つにまとまっていきます。今では、かつてチーム全体でこなしていたことを、一人の個人がこなせるようになっているのです。
そして、そうした人々には、これまでの職能の境界を越えて融合するようなスキルが必要になります。しかし、そうした人材を得ることができれば、彼らは過去にチームがこなしていたのと同じか、それ以上のことをこなすことができます。個人が過去にチームがこなしていたことをこなせるようになると、彼らは持てる影響力や責任の範囲という点で、階層を上に移動していくことになります。よく知られている可視化の例で言えば、人の集団を維持するにはコストがかかり、調整のオーバーヘッドにはコストがかかります。それは実際に、人の活力を吸い取ってしまうことすらあります。率直に言って、より自由に動けるということは、影響力があるだけでなく、非常に楽しいことでもあります。
つまり、ここには、いわばスーパーICとでも言うべき、あるいはテックリードと言うべき人材の集団が現れつつあるという考え方があります。おそらく少人数のグループと一緒に、あるいは完全に一人で、かつてチームが担っていた役割を担うことができる人たちです。もしこれが真実になり得ると信じるのであれば、あなたの仕事は、その役割を担えるかもしれない人材の特性を理解し、見極め、育て、伸ばしていくことになると私は思います。
6. 結び：継続的な適応の必要性
6.1 適応か、無関係への衰退か
Darragh Curran： さて、締めくくりに入りたいと思います。この変化に正面から向き合わない限り、デフォルトでは無関係な存在への道を進んでいくことになります。重力が働く方向はそちらなのです。それがデフォルトなのだということを、本当にしっかりと受け入れる必要があります。変化の速度や、ここにある破壊の天井の高さは、私たちが理解できる範囲をはるかに超えています。
ですから、「もうAIのことはやり終えた」とか「もう自分たちはそこに到達した」などと安心しないでください。誰もまだそこには到達していません。私たちはまだ始まったばかりなのです。だからこそ、押し続け、学び続け、適応し続けなければなりません。インパクトのための土壌は、私たちが理解できる以上にはるかに大きく広がっています。ですから、これは意図的に選び取らなければならない選択なのです。自分のシャベルに心地よく寄りかかったままでいるのか、それとも新しいことを学ぼうとするのか。適応するのか、それともデフォルトのまま朽ちていくのか。私たちはその様子を実際に目にしています。それは決して華やかなものではありませんが、確実に起きていることです。
ですから、適応するために本当に必死に戦い、それに秀でることがどれほど重要か、皆さんに強く伝えたいと思います。私たちは、それをやり遂げたときにどのような報酬が待っているのか、その片鱗をすでに見てきました。とはいえ、私たち自身が適応において完璧だったとは思っていませんし、まだ学ぶべきこと、やるべきことはたくさん残っています。ここから先は、私たちがどのようにやってきたかを、まったく包み隠さずお見せしたいと思います。今、少なくとも当面私たちが注目している指標は、純粋なスループットです。中央の線が、私が目標を設定した時点を示しています。
6月まではこの緑色のターゲットを達成するための時間がまだ残っています。私たちには停滞していた時期があり、その後クリスマスの時期を経て、そこから加速する局面に入りました。おそらくこの目標はかなり余裕を持って達成できると思っています。しかし、今この時点から将来を振り返ったとき、私たちは18か月かけて生産性を2倍にしたわけですが、次はそれを12か月で2倍にするべきだと考えています。ここには確かに加速が起きているのです。もし皆さんがこれをやっていないのであれば、あるいはもっとうまくやれていないのであれば、誰か他の人がすでにそれをやっていて、あなたを追い越して先に進んでいます。私たちがいるこの市場では、スピードこそが命だと思います。以上です。皆さんの幸運を祈ります。