※本記事は、Anthropicが公開した動画「How Spotify runs agents across 20M+ lines of code, with Niklas Gustavsson」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=9DHZLw5653E でご覧いただけます。本記事では、動画の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。
本動画では、SpotifyのChief ArchitectおよびVP of Engineeringを務めるNiklas Gustavsson氏に、Anthropicが聞き手として登場し、Spotifyが2000万行を超える巨大なコードベースの中でどのようにコーディングエージェントを活用しているのかを伺っています。Spotifyの社員は、アイデアを言葉で説明するだけで、Claudeに1、2時間で動作するプロトタイプを構築させることができるといいます。あわせて、Claude CowdworkおよびClaude Codeについても紹介されています。
1. オープニング:IDEを使わなくなった衝撃と経歴
1.1 IDEを使わなくなった2ヶ月間
Boris Cherny: Niklas、今日はお時間をいただきありがとうございます。実は昨年の9月にも一度お話をさせていただいたことがありましたね。そのとき、あなたは「年末には誰もIDEを使わなくなっていると思う」とおっしゃっていました。私はその場では、それはさすがにあり得ないと感じていたんです。2年くらいの時間軸であれば起こり得るかもしれないとは想像していましたが、2ヶ月というのはあまりに極端に思えました。ところが実際にその2ヶ月後、私自身がIDEを使わなくなっていることに気づいたんです。仕事のやり方そのものが完全に変わってしまいました。私はこの業界に30年近くいますが、これほどの変化は見たことがありません。
Niklas Gustavsson: 面白いことに、社内でも社外の反応とまったく同じように受け止められていました。ただ、私たちには数週間ほどの先行期間があっただけです。それだけの差でしかなかったのですが、体感としては外から見ていたのとまったく同じ驚きでした。
1.2 分子生物学からエンジニアへ
Boris Cherny: それでは、まずあなたがどのようにコーディングの世界に入ったのかからお聞きしたいと思います。
Niklas Gustavsson: 私のバックグラウンドは実は生物学にあります。分子生物学者としての訓練を受けてきました。博士課程で研究をしていた当時、いわゆる「ビッグデータ」と呼ばれ始めていたものを扱うようになりました。具体的にはゲノムシーケンシングから得られる大量のデータです。そうしたデータを扱う中で、自分のプログラミング能力を高める必要があると感じるようになりました。そこで、もともとは1年間のサバティカルのつもりで方向転換したのですが、結果的にこの業界に身を置くことになり、気づけば30年近くが経っていました。
2. 個人的な「AGIモーメント」の変遷と現在のワークフロー
2.1 LLM黎明期からOpus 4/5までの転機
Boris Cherny: 現在のエージェントやLLMをめぐる大きな変化の中で、あなた個人の使い方も、Spotifyとしての使い方も、業界の最先端にあるように感じています。個人的に「AGIモーメント」だと感じた瞬間はいつだったのでしょうか。
Niklas Gustavsson: 取り組んでいた問題によって、いくつかそうした瞬間がありました。私たちはLLMが登場し始めた比較的早い段階から、コード変更を自動化するためにLLMを活用しようと試みていました。ただ、最初は本当に苦戦の連続でした。しばらく試行錯誤を重ねる中で、LLMをジャッジとして使う方法などが見えてきて、そこからようやく手応えのある結果が得られ始めました。
Boris Cherny: それは数年前の話ですね。
Niklas Gustavsson: そうです。Claudeが登場する以前、初期のGPTの時代でした。当時得られていた結果は、すべての問題を解決できるようなものではありませんでしたが、この技術がどこに向かっていくのかという方向性を示してくれるものでした。ただ、私個人のコーディングという観点で本当のブレイクスルーだったと感じたのは、おそらく昨年の11月から12月頃に登場したOpus 4、あるいは5でした。それまでは賢いオートコンプリートのような存在だったものが、本当に現実の課題を投げかけられる相手に変わったのです。しかも、それほどプロンプトエンジニアリングを工夫する必要もありませんでした。
Boris Cherny: 具体的にはどのような点が一番大きかったのでしょうか。
Niklas Gustavsson: 私にとって一番大きかったのは、もうコードを自分で編集する必要がなくなったことです。それまでのワークフローでは、モデルにコードの8割程度、モデルによっては7割程度を書かせて、そこから先はIDEに入って最後の詰めの編集作業を自分でやる、というのが常でした。それが必要なくなったのです。これは本当に驚くべきことでした。この変化こそが、今回の飛躍がこれほど大きく感じられた理由の大きな部分を占めていると思います。
2.2 tmuxとモノレポ/ポリレポでの運用
Boris Cherny: 今の働き方はどのようなものですか。Claude Codeをどう使っていますか。Spotifyとしてはどう使っているのでしょうか。
Niklas Gustavsson: かなり素朴な、いわゆるバニラに近い使い方をしていると思います。ターミナルの中でtmuxのセッションをいくつも立ち上げて作業をしています。何か作業をするときは、常にバックグラウンドで複数のエージェントを動かしている状態です。
Boris Cherny: ターミナルのタブはいくつくらい開いているのですか。
Niklas Gustavsson: だいたい5個から10個くらいの間です。加えて、diffなどを確認できるペインもいくつか使っています。こうしたClaudeのセッションと対応するターミナルのマトリクスを、複数のワークツリーの中に組んで作業をしている形です。私たちの体制としては、少数の非常に大きなモノレポへの統合を段階的に進めていますが、依然として数千規模の小さなポリレポも残っています。ですので、私の作業のほとんどはそうしたモノレポの中で行われています。基本的にはそこでいくつかのClaudeとターミナルを常時動かしていて、ポリレポの方に手を入れる必要があるときは、その都度、一時的なClaudeのセッションを立ち上げるという形をとっています。
Boris Cherny: モノレポとポリレポ、どちらがClaudeにとって相性が良いと感じますか。
Niklas Gustavsson: 正直に言うと、モノレポとエージェントの組み合わせについては当初かなり不安を持っていました。というのも、以前使っていたツールの中には、インデックス処理などで問題が出ていたものがあったからです。私たちのバックエンドのモノレポは2000万行を超える、かなり大規模なリポジトリです。ところが実際にはClaudeはこうした大規模リポジトリの中でも驚くほどうまく機能することが分かりました。私たちが発見したことの一つは、Claudeがリポジトリ内の他のコードを参照して、取り組んでいる問題を解決するための着想を得るのが非常に得意だということです。
3. Fleet Managementの起源とHonkへの進化
3.1 コードベース急増と自動化の限界
Boris Cherny: 構築されてきたインフラについても伺いたいのですが、Spotifyでは「Honk」を作られましたよね。LLMを実験的に試していた最初期の頃から、Honkの構築、そしてAgent SDK上でのバックグラウンドエージェントの構築に至るまで、あなたたちは常に他の人たちよりも先に未来を見据えてきたように感じます。そうした文化やチームの特性はどこから来ているのか、そしてその経緯を教えていただけますか。
Niklas Gustavsson: 5、6年前になりますが、私たちのコードベースが、それを支えるエンジニアの人数に対して7倍ものスピードで成長していることに気づいたのです。つまり、時間が経てば経つほど、維持しなければならないコードだけがどんどん増えていく状態でした。一方でSpotifyは、ユーザーに届けたいアイデアが尽きることのない会社です。ですので、メンテナンス作業に足を取られている場合ではありませんでした。そこで私たちは、メンテナンス作業をできる限り自動化しようと動き始めました。その多くは、最新のJavaバージョンへの移行やライブラリのアップデートといった、地味で退屈な作業でした。また、あるAPIから別のAPIへ、コードベース全体にわたって移行するような作業も多くありました。
そこで私たちは「Fleet Management」と呼ぶ基盤を構築しました。これは、これまでのようにマイグレーションの手順書やチュートリアルを全チームに配布して、各チームが自分のコンポーネントに対して手作業でマイグレーションを行うよう依頼するのではなく、コードベース全体に対して一括で変更を加える方法を見つけられないか、という発想から生まれたものです。
Boris Cherny: つまり、どのチームも結局は同じ作業を繰り返していたわけですね。
Niklas Gustavsson: そうです。何百というチームが、何千というコンポーネントに対して、まったく同じ作業を手作業で繰り返していました。こうしたマイグレーションはそれぞれ完了までに何ヶ月もかかり、多くても年に10件程度しかこなせませんでした。サポート対象のフレームワークのバージョンに追従するだけで精一杯という状態だったのです。そこで改めて自動化に取り組み、そのための基盤を一から構築しました。私たちはこれまでに数百万件規模のPRをこうした形でマージしてきましたが、それらはすべて、適用すればコードや設定の変更を行ってくれる決定論的なスクリプトに依存したものでした。
その過程で早い段階から気づいたのは、コードのAPIの表面積は非常に大きいということです。コードに変更を加えようとすると、あっという間に複雑になっていきます。あるメソッドやAPIを置き換えるだけでも、それが5通りもの異なる呼び出され方をしているとなると、非常に厄介な作業になります。
Boris Cherny: つまり、従来の静的解析による変換だけでは対応しきれなかった、ということですね。
Niklas Gustavsson: まさにその通りです。例えば、あるAPIの戻り値を変数に代入しているようなケースでは、変数や状態を追跡する仕組みが必要になってきます。
Boris Cherny: それは相当厄介ですね。
Niklas Gustavsson: ええ、非常に厄介でした。コードを移行するための各スクリプトは、あらゆるエッジケースに対応しようとするうちに、何千行にも膨れ上がっていきました。こうした背景があったからこそ、初期のLLMが登場し始めたとき、これをこの問題に応用できないかと考えたのです。ただ、最初はまったくうまくいきませんでした。モデル自体の性能が十分でなかったこともありますし、私たちのやり方があまりに素朴だったことも一因です。当初は単にコードをモデルの前に置いて、一発でその変更をやらせようとしていただけでした。それではうまくいかなかったのです。
3.2 Honkの誕生とジャッジ機構の変遷
時間が経つにつれてモデルは改善し、私たちのアプローチについての考え方も洗練されていきました。そこで、出力が意図した通りのものになっているかを確認するために、LLMをジャッジとして適用するようになりました。また、問題自体をさまざまな形で分解し、細かく砕いて取り組むようにもなりました。こうした試行錯誤と、社内での数多くの工夫を重ねた末に、これらを統合したものが今私たちが「Honk」と呼んでいるものになりました。ただ、当時のHonkは今とはまったく異なる姿をしていて、Claude上に構築されたものではなく、どちらかというと自前で組み上げた仕組みの集まりでした。それでも、これは実際に解決可能な問題なのだという最初の光明になりました。そこからHonkには何度も何度も改良が重ねられていきました。今日リリースしているものは「V2」と呼んでいますが、実際には8番目くらいのバージョンに相当するのではないかと思います。正直なところ、途中からバージョンの数を数えるのをやめてしまったほどです。
Honkはもともと、コードの変更をスケジューリングし、全リポジトリにわたってオーケストレーションするという、自動化されたマイグレーションのための仕組みとして始まりました。しかし、比較的早い段階でエンジニアたちが、これは他の用途にも使えると気づき始めました。例えばSlack上で何かを依頼して、タスクを代わりにやってもらう、といった使い方です。そうした経緯もあり、今日ではHonkはもっとユビキタスなツールへと成長しています。
Boris Cherny: Honkのアーキテクチャについて教えてください。どのような構成要素があるのでしょうか。コードを書くエージェントがあるとおっしゃっていましたが、これはClaudeのAgent SDKの上に構築されているのですよね。
Niklas Gustavsson: その通りです。
Boris Cherny: それから、エージェンティックな検証を行う仕組み、つまりジャッジのようなものもあるかと思いますが、それについても詳しく教えていただけますか。
Niklas Gustavsson: 以前はHonkの中にジャッジを持っていましたが、実は今はそれを取り除いています。というのも、先ほどお話ししたOpus 4や5あたりから、エージェントやモデル自体の性能が十分に高くなり、もはやジャッジを必要としなくなったからです。初期のHonkにおいては、このジャッジは非常に重要な役割を果たしていました。私の記憶している数字が正しければ、PRの成功率をおよそ20〜30%程度から、80%程度にまで引き上げてくれたのです。
Boris Cherny: それは大きな変化ですね。
Niklas Gustavsson: ええ、大きな変化でした。ただ、その後モデル自体の性能と、エージェントとしての完成度が追いついてきたことで、今ではそのジャッジをHonkから取り除いています。アーキテクチャとしてのHonkは非常にシンプルで、Kubernetesのpod上でAgent SDKが動作しているというものです。一連のツールセットへのアクセス権を持たせています。
4. Honkのアーキテクチャと検証(Verification)ループ
4.1 Honkのシステム構成と検証基盤
Niklas Gustavsson: V2より前の段階では、エージェントに与えるツールは、私たちが信頼できると判断した上であらかじめ許可リストに登録した、限定的なセットに限られていました。しかしV2になってからは、ユーザー自身が独自のツールを追加できるようになりました。そのため今では、エージェントは私たちの社内ツールであれば何でも利用できる状態になっています。中でも特に重要なツールの一つが、検証を行える機能、つまり基本的にCIビルドを実行できる機能です。これはLinuxとmacOSの両方で実行することができます。
Boris Cherny: macOSというのは特に重要ですね。例えばiOSの開発ではmacOS上でのビルドが必須になりますから。
Niklas Gustavsson: その通りです。
Boris Cherny: これは単にビルドを行うだけなのでしょうか、それともiOSのシミュレーターを実際に立ち上げて、モデルにアプリを起動させるところまでやらせているのでしょうか。どこまで踏み込んでいるのか気になります。
Niklas Gustavsson: そうした種類のテストまで行うことができます。実際に、シミュレーターとClaudeを統合して、例えばデザインからFigma、そしてUIの実装へと直接つなげる作業を自動化しているケースもあります。この仕組みは、私たちのTVアプリをiOSアプリから移植する際にも活用してきました。
Boris Cherny: 検証というのは、私たちがよく話題にするテーマの一つですね。ただ、こうしたクローズドループ型の開発、つまりエージェントにタスクを与えて、そのエージェントがタスクを分解しながら、人間を介さずに多くの作業をこなしていくという形では、検証こそが単一で最も重要な要素だと感じています。よくある間違いの一つは、企業が検証ループの整備にどれだけ投資すべきかを過小評価してしまうことだと思うのですが、いかがですか。
Niklas Gustavsson: まさにその通りだと思いますし、私たちにとっても同じことが言えます。私たちがエンジニアリングの実践の中で行った大きな変更の一つが、テスト自動化を強化することでした。
4.2 所有権モデルとテスト自動化の強化
Niklas Gustavsson: 私たちはコードベースを数千のコンポーネントに分割しており、それぞれのコンポーネントには明確に定義された所有権があります。特定のチームがそのコンポーネントを所有し、そのチームがすべての責任を負う形です。多くの場合、そのチームがコンポーネントを設計し、実装し、運用もしています。Fleet Managementへの投資を行う以前は、マージされるすべての変更について、そのチームがループの中に入って確認する、という前提がありました。そのため、ポストテストの自動化については、多少雑になっていても構わないという側面がありました。なぜなら、必要であればそのチームが常にすべてのPRを確認できたからです。
しかし、ソースコードに対するPRの自動化を進め始めたことで、チームに対する期待値そのものを変える必要が出てきました。もはやこうした変更の一つひとつについて、チームがループの中に入っているとは限らなくなったのです。私たちはこうした変更の多くを、チームがそのPRを一度も目にすることなく自動マージするようになっていきます。これはつまり、私たちのソフトウェアがそうした自動化された変更に耐えられるようにするために、はるかに優れたテスト自動化を構築する必要があったということを意味していました。今、現在の状況にズームインしてみると、これは私たちにとって非常に役に立っています。なぜなら、以前から整備してきたのと同じ検証の仕組みを使って、エージェントにタスクを投げられるようになったからです。
5. 品質・速度・信頼性への考察とROI測定
5.1 品質とスピードの関係
Boris Cherny: エンジニアリングの世界でよく語られるトレードオフの一つに、信頼性・品質と、スピードとの間の対立があります。ただ、私にはそれがある種の偽の二項対立のように感じられるのです。というのも、より速く進みたいのであれば、本来やるべきことは品質の実践をきちんと自動化することであり、それを誰か一人の頭の中だけに留めておくのではなく、スキルやCLAUDE.md、あるいは何らかのMCPの中にきちんとエンコードしておくことだと思うからです。Claudeが実行できる形になっていることこそが重要で、それこそが最終的により速く進むための鍵になります。これはエンジニアリングにおいて生産性というものが常にインフラへの投資と結びついているという、一つの例だと思うのですが、あなたが話していたこととも重なりますね。
Niklas Gustavsson: 私たちは品質の指標を維持したまま、スピードを大幅に改善できていると感じています。ただ、それは無償で得られたものではありません。先ほどお話ししたテスト自動化への投資が必要でしたし、今後も信頼性に関する実践への投資を続けていく必要があると考えています。こうした投資の一部は、今回のような移行の中で変化していくものでもあります。
Boris Cherny: そして、どんどんスピードを上げていこうとすればするほど、それを維持するためにさらに信頼性への投資を増やさなければならなくなる、ということですね。
Niklas Gustavsson: ええ、まさにその通りです。実際、私たちは1日あたりおよそ4500件もの本番デプロイを行っています。これだけの規模になると、何かがうまくいかなくなる可能性のある箇所も相応に多くなります。ですから、本番環境に出ていくすべてのものが求める品質を確保できているかどうかを担保するための、しっかりとした実践が必要になってきます。
Boris Cherny: これほど多くのデプロイを行っている狙いは何なのでしょうか。以前であれば単なる継続的デプロイという発想だったのかもしれませんが、今ではエージェントにとってのより速いフィードバックという意味合いもあるのでしょうか。それとも、どのように捉えていますか。
Niklas Gustavsson: これはSpotifyが存在してきた間、ずっと最適化を続けてきたことです。私たちは、開発者が何かアイデアを思いついたら、それをできる限り早く本番環境に届けられるようにしたいと常に考えてきました。数年前まではそれには数週間から数ヶ月かかっていましたが、私たちはそれをずっと最適化し続けてきて、今では1時間程度にまで短縮されています。先ほども触れたように、私たちには検証し、探求したいアイデアがたくさんあります。そのフィードバックを得るのが早ければ早いほどよいのです。場合によっては社内のユーザーからのフィードバックであったり、場合によっては社外のユーザーからのフィードバックであったりしますが、いずれの場合も、より速く反復できればできるほど、より良いプロダクトを作れて、かつユーザーにより速く届けられるということが分かっています。もちろん、すべてのアイデアが1時間で出荷できるわけではありません。多くのアイデアは出荷までに相応の検証を必要とします。ただ、素早く検証を得られるという発想そのものが、私たちにとって非常に重要なのです。そして、エージェントも間違いなくそのループの一部を担っています。
5.2 デプロイ頻度とROI測定
Boris Cherny: Spotifyのエンジニアリング組織はかなり大きな規模ですよね。数千人のエンジニアがいるかと思います。
Niklas Gustavsson: そうですね、2900人ほどのエンジニアがいます。
Boris Cherny: これだけのことに取り組む中で、ROIについてはどのように考えていますか。測定方法や、正しい方向に進んでいるかどうかの確認はどのように行っていますか。
Niklas Gustavsson: ROIの測定に関して言えば、これまでのところは比較的容易で、非常に明確なシグナルが見えていました。PRの頻度において75%以上の改善が見られており、これはAIツールによるものだと直接的に紐づけることができています。また、現時点でおよそ73%のPRが、AIによって作成されたものだと直接的に帰属させられると考えています。こうした指標については、私たちはかなりうまくやれていると思います。ただ、当然ながら、それをユーザー価値や収益に結びつけて考えたいという思いもあります。
Boris Cherny: それをどうやって測定するのですか。例えばA/Bテストのような形なのか、それともホールドアウトを使ったケーススタディのようなものなのか、どのように考えていますか。
Niklas Gustavsson: そうですね。私たちはエンジニアが行う成果物、つまりPRやデプロイメントを、私たちが「work item」と呼んでいるものに接続できるようにしたいと考えています。work itemというのは、基本的に私たちが計画している作業のことです。そして、それがA/Bテストやロールアウトへとつながり、そこから遡って、このPRがこのDoD(Definition of Done)に貢献し、それがこのユーザー価値に貢献した、という形で追跡できるようにする。それが私たちの目指す姿であり、今まさにそうしたつながりを構築しようとしているところです。
とはいえ、当初のROIに関する議論は、私たちが非常に大きな改善を目にすることができていたこともあって、かなり容易なものでした。ただ、成熟度が高まり、コストも改善してきている中で、そうしたROI見積もりの精度に対する期待値そのものが高まってきていると感じています。ですからこそ、私たちはその種の測定方法をどう改善していけるかに取り組んでいるのです。その一部はどれだけ生産性が改善したかということであり、もう一部は、その改善を得るためにどれだけのコストがかかっているのか、ということです。
Boris Cherny: まさにその通りですね。そして今では、数十パーセント、あるいは数百パーセントもの改善が見えるようになってきていますから、それを本当に突き詰めて、どれだけのトークンを使ったのか、どれだけの時間がかかったのか、どれだけの成果が生まれたのかを把握したくなりますよね。
Niklas Gustavsson: ええ、まさにその通りです。
6. エンジニアリングリーダーへのアドバイス:標準化への投資
6.1 標準化への投資
Boris Cherny: 最後に一つだけ質問をさせてください。あなたの同業者、つまり他の会社のCTOやVP of Engineeringといったエンジニアリングリーダーたちに対して、どのようなアドバイスをされますか。
Niklas Gustavsson: 私たちが見出したことの一つは、こうした基盤的な能力への投資、つまりこれまでお話ししてきたテスト自動化や検証の話ですが、それが非常に重要だということです。そしてもう一つ、私たちが目にしてきた側面として、標準化というものがあります。私たちはこれまで、より一貫性のあるコードベースにすること、使用するツールや使用するフレームワークについてより統一を図ることを推し進めてきました。そして、これはもともと人間の作業を単純化し、人間をより生産的にするために行っていた投資だったのですが、それがまったく同じように、むしろそれ以上にうまくエージェントに対しても効果を発揮することが分かってきたのです。
先ほども触れましたが、Claudeは私たちのモノレポ内にある他のコードから着想を得ることができます。しかし、もしそのコードが10通りもの異なる書き方をされていれば、Claudeはより混乱してしまいます。ですから、一貫性が高ければ高いほど、私たちのエージェントはよりうまく機能するということを、私たちは目の当たりにしてきました。ですので、もし私が一つだけアドバイスをするとすれば、そうした種類の投資を軽視しないでほしい、ということです。
以前から通用していたのと同じ、健全なエンジニアリングの実践というものは、この新しい世界においても依然として必要とされています。その姿は少し違って見えるかもしれません。あなたのコードベースの中に新しいアクターが加わったということは事実ですが、根本的な原則は変わらず同じように当てはまるように思います。少なくとも、私たちの環境ではそうでした。
7. 現場エンジニアへの個人的アドバイスと働き方の変化
7.1 問題解決の本質と働き方の変化
Boris Cherny: これまで長くエンジニアリングの仕事をしてきた現場のエンジニアたちに対しては、どのようなアドバイスをされますか。Spotifyでは、エンジニアが地下鉄の中でPRを出しているという話も出ていましたが、それも本当に面白い話だと思います。エンジニアリングという仕事自体が変化していく中で、その真っただ中にいる人たちに対して、どのようなアドバイスをされますか。
Niklas Gustavsson: ここでは、もう少し個人的な角度からお話しさせてください。私はこれまで、コーディングにおける問題解決の部分を心から楽しんできた人間です。少しオタクっぽく聞こえるかもしれませんが、私は暇なときに競技プログラミングをすることがあります。それはただ純粋に楽しい頭の体操だからです。
心のどこかでは、先ほどお話ししたように、この変化が仕事の仕方そのものを完全に変えてしまうのではないかと、ずっと不安を感じていました。自分自身にとって、あの困難な思考の課題に取り組むという部分を失ってしまうのではないか、という心配です。しかし今、私は5つのエージェントをバックグラウンドで動かしている自分自身に気づきますし、それらのエージェントとの関わり方は、1年前や2年前の働き方とはまったく異なるものになっています。そして私にとって、結果的にはその心配は間違いだったと分かりました。私が本当に好きなのは問題を解決するということそのものであって、その問題をどうやって解くかという手段の部分は、自分にとって決定的に重要な要素ではなかったのです。
これは常に人によって違うものであり、それぞれの人がそれぞれのやり方でこの移行に向き合っていくことになると思います。ただ、私が言えるのは、自分がどのような種類の問題を解決できるかということに焦点を当てるべきだ、ということです。私自身は、以前よりも生産性が上がったと感じていますし、自分がこなせる仕事から生み出せる価値も大きくなっています。また、以前なら本当に解けなかったような問題も、今なら解けるようになっています。以前であれば入り込むのに何日も、何週間もかかっていたようなコードベースにも飛び込んでいけるようになり、以前はまったくできなかったような形で貢献できるようになっています。私にとって、これは本当に素晴らしいことです。もちろん、これは人によって見え方が違ってくると思いますが、まずは試してみて、自分なりにこうしたツールを活用できるやり方を見つけてほしいと思います。
7.2 プロトタイピング文化の広がり
Boris Cherny: 私自身についても、大きな変化を感じています。実装にかかる時間という観点では、Claudeがバックグラウンドで作業してくれている間に、私は他のことをできるようになりました。その代わりに、その時間を埋めているのは、次に何をすべきかを考えることであったり、顧客と話すことであったり、そして想像していた以上に、プロトタイピングに多くの時間を使うようになったことです。その一部は社外向けのプロダクトのためであり、一部は社内向けの自動化のためでもあります。こうした変化は、あなたにとってはどのように感じられていますか。
Niklas Gustavsson: 私にとっても似たような形で起きていると思います。実はこれまでお話ししていなかったのですが、私たちが特に大きく投資している分野の一つがプロトタイピングです。これはエンジニアだけでなく、非エンジニアの層に対しても向けたものです。Claudeやそれに類するツールが実現したことの一つは、誰であっても、自分の頭にあるアイデアを自然言語で表現し、それをClaudeに実装させることができるようになった、ということです。
そうした中で、非エンジニアも含めて社内の人たちがこの方法に気づき始め、実際に私たちの本物のアプリでそれを試そうとし始めました。私たちのアプリはかなり複雑な代物なのですが、それでも彼らはできそうだという手応えを感じ始めていました。そこで私たちは数ヶ月前から、それを簡単に行えるようにするための基盤を構築し始めました。今では、モバイルアプリやバックエンドに対して、非常にシンプルな方法でエンドツーエンドのプロトタイプを作れるようになっていますし、そうしたプロトタイプを共有できる社内アプリストアのようなものも用意しています。そこでは、他の人が作ったプロトタイプを自分のアプリの中で実際に試してみることもできます。これは、以前ならエンジニアを何人も動かしてようやく作ってもらえるようなアイデアを、今では1、2時間もあれば実際に動くプロトタイプとして手に入れ、それを実際のユーザーやリアルなデータとともに人々に見せて回れるようになった、という意味で、まさに大きなブレイクスルーになっています。これには、以前はモバイルアプリの中で何かを作る方法にあまり詳しくなかったようなエンジニアたちも含まれています。
Boris Cherny: そうしたことは、1年前には想像もできなかったことですが、今では毎日のように行われているわけですね。
Niklas Gustavsson: ええ、その通りです。
Boris Cherny: その点、本当に素晴らしいと思います。こうした取り組みを行っているのが誰なのか、その顔ぶれに変化は見られますか。エンジニアが中心なのか、それともデザイナーやプロダクトマネージャーからの利用が多いのか、その辺りはどう変わってきていますか。
Niklas Gustavsson: 本当にあらゆる人たちが関わっています。現時点では、共同CEOの一人もこの社内アプリストアにプロトタイプを持っているほどです。
Boris Cherny: それは実際に良いものなのですか。
Niklas Gustavsson: ええ、そうです。私たちのシニアエグゼクティブの何人もが、良いプロトタイプを作っています。それらは、彼らがずっと頭の中に持っていたアイデアであることが多く、本来であればそれを実現できるエンジニアリングチームが社内に存在しているのですが、そのチームは他のことに専念しています。ですから、そうした人たちが、以前よりずっと早く何かを試して、その手触りや実際の見た目を確かめられるようになったということです。これによって、1日でアイデアを検証できるようになりました。以前であれば、それには数週間、あるいは数ヶ月かかっていたはずです。
Boris Cherny: Niklas、本当にありがとうございました。
8. クロージング
Boris Cherny: Niklas、今日は貴重なお話を本当にありがとうございました。IDEを手放すという個人的な体験から始まり、Fleet ManagementやHonkの構築の歴史、そして検証ループや標準化への投資といったエンジニアリングの基盤の話、さらにはROI測定の取り組み、そしてエンジニア自身の働き方やプロトタイピング文化の広がりまで、非常に幅広い変化についてお聞きすることができました。
Niklas Gustavsson: こちらこそ、ありがとうございました。