Rampのジェフ・チャールズが語る、コーディングが制約でなくなったときに次のボトルネックを見つける方法

チャールズ氏は個人的なエピソードから話を始めた。同氏はかつて、参加者が500ドルの車を購入して24時間走らせるレース「24 Hours of Lemons」に出場したことがある。そこで激しくクラッシュした。本人は無事だったが車はそうはいかず、チャールズ氏はクラッシュの責任は完全にドライバーである自分にあったと認めた。

しかしプロのレースでは、ドライバーが問題になることはめったにないとチャールズ氏は言う。同氏によれば、レースへの影響のうちドライバーが占めるのは約15%にすぎない。残りは、ドライバーと車の相互作用、そして車とチームの相互作用から生まれる。どれほど優れたドライバーでも、周囲のシステムの水準までしか力を発揮できない。勝利は、単に速く走ることではなく、運転を取り巻くボトルネックを取り除くことから生まれる。

主な例として挙げられたのがピットストップだ。1950年代、タイヤ交換には67秒かかっていた。現在は1.8秒だ。チャールズ氏は、これはメカニックに37倍がんばれと求めた結果ではないと指摘した。チームはボトルネックを見つけ出し、役割の専門化、技術の向上、練習量の増加を通じて改善を重ねてきた。同氏はF1の変化のペースにも触れた。チャールズ氏によれば、F1マシンを構成する約1万6,000個の部品のうち、翌年に引き継がれるのは約10%にすぎない。同氏は聴衆に、自分たちのコードの90%が毎年入れ替わる状況を想像してほしいと呼びかけ、それこそが「基準」だと述べた。

チャールズ氏のたとえでは、ピットストップの計測は車が入ってきた時点で始まり、出ていった時点で止まる。プロダクトチームの場合、計測は顧客が痛みを感じた時点で始まり、その痛みを解決するプロダクトを顧客が手にした時点で止まる。AIはボトルネックを取り除くが、同時にそれを移動させもする。次のボトルネックを最も早く見つけたチームが勝つ。

チャールズ氏は、おなじみのライフサイクルとして、特定(identify)、定義(define)、構築(build、従来は最も長いフェーズ)、改善(improve)を挙げた。エンジニアは自らの仕事の多くを自動化したため、コーディングは格段に容易になった。同氏がプロダクトマネージャーに送ったアドバイスは、「もっとエンジニアのようになれ」、そして「エンジニアと同じくらい怠惰になれ」というものだった。生み出されるコードが増えたことで、PMが定義し、協働し、調整し、出荷し、テストし、リリースすべきものも増えている。そのためPMは自分自身の「工場」に投資する必要があるとチャールズ氏は論じた。問われるのは、チームがどれだけ速くボトルネックを特定し、それを中心に工場を再設計できるかだ。

講演の残りでは、5つのステップと、Rampがそれぞれをどのように改善し、自動化してきたかが取り上げられた。

顧客の痛みはさまざまな場所に存在する。チャールズ氏は、Gong、Zendesk、LogRocket、アンケート、そして時折経営陣に届く怒りのメールを挙げた。コンテキストはサイロや対立する意見に分散しているため、最初のボトルネックはシグナルとノイズを分けることだ。

チャールズ氏は、LLMだけではこれは解決しないと指摘した。100万トークンのコンテキストウィンドウでも、RampのGongの文字起こしの0.5%未満しか収まらないという。

Rampはまず、顧客の不満を毎日投稿する「ヘイトチャンネル」から小さく始めた。チャールズ氏は実際の引用を示しながら、それが「あっという間に手に負えなくなった」と冗談を飛ばした。その後チームは一から作り直し、顧客インサイトエージェントを構築した。これは従来型のETLとパイプラインを使って社内のあらゆるデータソースからデータを取り込み、ベクトル検索を用い、共通のコンテキストに基づいてフィードバックをクラスタリングする。また、Rampのプロダクト、チーム、機能を理解しており、組織の他のメンバーもアクセスできる。

次にチームは、インサイトをできるだけ多くの人の手に届ける方法を試した。質問に答えるSlackエージェント、HTMLダッシュボード、そしてチャールズ氏のお気に入りである「ヘイトポッドキャスト」だ。ヘイトポッドキャストでは、約100人の顧客がプロダクトのどこが壊れているかを語るのを聴くことができる。チャールズ氏は、これが顧客と話すことの代わりにはならないと強調した。データが追跡可能なので、どの顧客と話すべきかを正確に教えてくれるのだという。

チャールズ氏は、「何を作りたいですか?」と問いかけるところから始まるAIツールを批判した。超知能システムにそう聞かれても、ユーザーはただ画面を見つめるだけだ。同氏はそれが正しい出発点なのかを疑問視し、AIは企業自身のシステムとつながったときに実用的になると論じた。

Rampは独自のエージェント「Glass」を構築し、必要なコンテキストを与えた。GlassはSnowflakeのデータやユーザーリサーチとつながっているため、定性的・定量的な両方の根拠を用いて、顧客が片付けたいジョブを特定できる。また、Rampのプロダクト戦略、Rampでのスペックの書き方、そしてコードベースも理解している。チャールズ氏によれば、これによりPMはもはやエンジニアに「これは実現可能か?何かを壊さないか?見落としていることはないか?」と尋ねる必要がなくなった。代わりにAIに尋ねればよく、同氏の言葉を借りればAIがPMの「テックリード」になる。

GlassはRampのプロダクト原則、デザインシステム、コードベースを把握しているため、実際のプロダクト内で動作するプロトタイプを作ることができる。チャールズ氏は、エンジニアがPMに求めているのは単一の成果物ではないと論じた。プロトタイプ単体では「役に立たない」し、長いスペックも同様だ。エンジニアが求めているのはその組み合わせ、つまり問題が実在することを示す定性的・定量的な根拠、自分のコーディングエージェントに渡せる要件、そしてインスピレーションを得るためのプロトタイプだ。チャールズ氏はこのセットを、プロダクトとエンジニアリングの間の「次の契約」と呼んだ。

チャールズ氏は、構築がもはやボトルネックではないという言い方は単純化しすぎだと認めた。1つのボトルネックを取り除くと次が露わになり、構築フェーズの中だけでも3つが連続して現れると同氏は説明した。

コーディング。 チャールズ氏は、今や誰もがコーディングエージェントを持つべきだと述べた。Rampは強力なハーネスと、自社のコードベースを真に理解するエージェントを求めて、独自のエージェント「Inspect」を構築した。InspectはSlack内で動作し、環境は完全にプロビジョニングされており、5秒未満で起動でき、デプロイ済みのプレビューを返すため、PMは構築中のものを実際に触ることができる。チャールズ氏によれば、Inspectのセッション数は100万回に達し、RampのPRの75%がInspectによって作られ、直近1か月では約1,000件のPRがエンジニア以外から生まれたという。同氏の但し書きは、コーディングエージェントがうまく機能するのは強固なアーキテクチャとコードベースの上に限られ、その基盤が会社のどれだけの範囲でAIを使えるかを左右する、というものだった。

コードレビュー。 コードが増えれば、エンジニアはそれを精査するのに時間を取られる。Rampが構築した「Review Buddy」は、コードベース、品質チェック、セキュリティ上の懸念を理解し、加わるべき適切な人間のレビュアーを見つけ出す。また、コードを生成したプロンプトも見られるため、そもそもAIがどのように使われたかを監査でき、目に見えるコンテキストに基づいたレビューが可能になる。チャールズ氏によれば、現在PRの93%はReview Buddyによって自動的に処理されている。これにより、最も優秀なエンジニアは、正確性やリスクについて本当に疑問が生じる残り7%に集中できる。

テスト。 チャールズ氏は、かつてのPMのルーティンを説明した。QA環境を立ち上げ、フィクスチャを調整し、画面をクリックして回り、エンジニアがお気に入りの機能を飛ばしていないかを確認する、というものだ。Rampはこれをブラウザベースのテストエージェント「Testo」で自動化した。Testoは本番データに基づいて100通りの組み合わせでプロダクトを立ち上げ、ユーザーと同じようにプロダクトを使う。「請求書を支払う、ただし償却して」といった指示を与えると、クリックして操作を進め、バグなどのブロッキングな問題を報告する。チャールズ氏によれば、Testoは分かりにくいフローやデザインシステム違反を指摘するなど、「非常に思慮深い」デザインや品質に関するフィードバックも返してくれる。そのフィードバックは開発ループに戻される。チャールズ氏は、Testoが直近30日間で425件のバグを発見したと報告した。顧客ではなくRamp自身に見つけてほしかったバグだという。

これだけの量を出荷するようになると、ボトルネックは人間の注意力になるとチャールズ氏は述べた。PMは通知に溺れ、調整が仕事になってしまう。プロセスが多すぎれば作り手の足を引っ張り、少なすぎれば全員が混乱する。

同氏の原則は「すべての質問はAPIである」というものだった。Rampは、チャールズ氏が「ガジェット」と呼ぶものを構築した。これは質問の背後にある意図を理解し、それを公式な記録、つまりNotion上のロードマップ、スペック、顧客との通話記録、さらにSlackやLinearのチケットと結びつける。エージェントが役に立つには組織を読み取れる必要があり、それはつまり組織がエージェントにとって読み取れるものでなければならないということだ。

チャールズ氏はいくつかの例を挙げた。「予定どおり進んでいるか?」といった進捗に関する質問には、全体像を把握し、次のステップの担当者を知り、根拠を示せるエージェントが答える。このエージェントはロードマップの更新や進捗報告の投稿も行い、成果物が遅れている人に催促もする。機能が何をするのか、どう売るのか、ブラジルで利用できるのか、何のためのものか、いくらかかるのか、といった営業からの質問には「Gadget」が対応し、理解できないものは適切な担当者に回す。ローンチに際しては、Gadgetはプロダクトを理解しているため、ヘルプセンターの記事を書き、ブログ記事や顧客向けメールの下書きも手伝える。チャールズ氏によれば、現在PM宛ての質問の85%はAIによって完全に回答されており、残りの質問への回答はシステムにフィードバックされている。

チャールズ氏は、PMは自然と小さく受け身の仕事、つまり簡単で目に見えやすく確実性が高く、ドーパミンが出るようなタスクに流れがちだと論じた。同氏はそれを「大きな間違い」と呼んだ。野心についてのクレア氏による先の講演を引き合いに出し、小さなことに集中するのは野心的ではなく、PMはそうしたループから自動化によって抜け出すべきだと述べた。

Rampでは、ほとんどの小さな課題についてAIがループ全体を回している。課題を適切なチームに振り分け、Linearのバックログと照合し、重複を排除し、件数を数え、順位付けする。その後、計画を作成してSlackで人間に確認し(「準備はできていますか?いつでもコーディングできます」)、コードを書き、テストとCI/CDにかけ、ローンチ時にはナレッジベースを更新する。何千もの小さなループにおいて人間は「ほんのかろうじて」ループに関わるだけで、そのおかげで大きなループに集中できる。チャールズ氏によれば、こうした自律的なループのおかげで、顧客、営業担当者、あるいはRamp自身が見つけたUXの問題の60%が24時間以内に修正されているという。

チャールズ氏は最後に、聴衆から寄せられるであろう3つの問いに答えた。

品質を保ちながら速くなっていると、どうやって分かるのか? チャールズ氏は、プロダクトの速度はラップタイムより測りにくく、簡単には数値化できないものもあると認めた。同氏は1974年のニキ・ラウダのエピソードを紹介した。フェラーリで1周走った後、ラウダはエンツォ・フェラーリに、この車は走りもハンドリングもブレーキもひどいと告げ、それからエンジニアのもとへ行って修正したという。チャールズ氏は、Rampのカルチャーも似ていると述べた。同氏の答えは、スピードとはどういうものかを知っている「ドライバー」を雇い、その人に主導権を与え、たとえ一部のリーダーにとってはつらいことであっても、自分に異を唱えさせることだった。

エンジニアであれトークンであれ、予算が限られている場合は? チャールズ氏によれば、2006年、アウディは遅い車を抱えており、より速くならずにどうすれば勝てるかを問うた。その答えは燃費だった。ピットストップを減らしてコース上にいる時間を増やすことで、チャールズ氏によれば3連勝につながったという。制約は、世界トップクラスになる1つの次元を選ぶことを強いる。チャールズ氏のアドバイスは「制約は受け入れよ、ただしボトルネックは受け入れるな」というものだった。会社を10倍にしうるボトルネックを1つ選び、そこから始めるべきだという。

PMは自分の仕事を自動化しているのではないか? チャールズ氏は、エンジニアが主導できる多くの事柄からPMが外れられるのは「素晴らしい」ことだと述べた。それがレバレッジを生むからであり、PMはそれを恐れる必要はないという。同氏は、この役割が3つの方向に進化していくと見ている。1つ目は技術的なトラックで、業界が十分に投資していないとチャールズ氏が考えている領域だ。工場そのものを作り、ボトルネックを特定して足かせを取り除き、会社やそのAIが顧客のために構築するのを助けるプロダクトを出荷するPMである。2つ目はテイストメーカー、つまり「ドライバー」で、おそらく最も重要で最も目立つ役割だ。ハンドルを握り、AIにはできないことを行い、優れたプロダクトの基準を定める人である。3つ目はGMだ。チャールズ氏は、PMがマーケティング、営業、グロース、オペレーションへと領域を広げ、事業成果に責任を持ち、機能部門全体を率いるようになると見ている。

チャールズ氏は3つの要点をまとめた。第一に、スピードは単にコーディングを速くすることではなく、構築プロセスにおけるボトルネックを見つけて取り除くことから生まれ、どのチームにもボトルネックは存在する。第二に、1つのボトルネックを解決すると次が露わになり、仕事はそれらをできるだけ速く乗り越えていくことだ。第三に、プロダクトリーダーは、自分たちが届けるプロダクトへのこだわりを少し減らし、それを作る工場にもっとこだわるべきだ。

同氏はさらに、講演で紹介したものはすべてすでに時代遅れだと付け加えた。F1と同様にチームは互いに模倣し合うものであり、チャールズ氏は聴衆に対し、Rampを真似して追い越してほしいと呼びかけ、すでにそうしている人もいるだろうと述べた。エンツォ・フェラーリの「最高のフェラーリは、次に作るフェラーリだ」という言葉を引用し、チームが作る最高のプロダクトは次のローンチであり、それは今日構築するソフトウェア工場から始まると語った。チャールズ氏は最後に、誰もが顧客にもっと多くを届けられるよう、どのように構築しているかをコミュニティでもっとオープンに共有してほしいと呼びかけて講演を締めくくった。