「Ripplingの成長速度は10段階中の11まで到達したと思っていたら、実はその先の12があったなんて」——CPOのMatt MacInnisはそう言います。
HR、給与計算、デバイス管理、コーポレートカード、経費管理まで、企業運営に必要なすべてを単一システムに統合するプラットフォーム「Rippling」。2年前に、ALL STAR SAAS FUNDのマネージングパートナー・前田ヒロとの対話でコンパウンド戦略の本質を伝え、日本の起業家たちを奮い立たせたMattが、今度は「AI時代のプロダクト戦略」を語ります。
「給与が300ドル減った」という社員からの問い合わせに1時間が消える。そういった雑務をAIで一掃する。しかしその裏側では、ハルシネーションが絶対に許されない「決定論的なシステム」を作り続けなければならない......HRや給与計算という領域の難しさと面白さが、そこにあります。
爆速開発を実現する短期決戦の方法や、ロードマップは1〜2ヶ月で吹き飛ぶ前提で動くこと、さらに社内AIコパイロットでJiraチケットのバックログを一掃する話など、Ripplingの思想と実践を余すところなく教えてくれました。
＼このセッションは、YouTubeでも公開中／
Ripplingのやるべきことは、山ほど残っている
──ALL STAR SAAS FUNDのカンファレンスのために東京へ来てくださってからもう2年ほど経ちましたが、あのときもみんなを奮い立たせてくれました。それ以降、みんなのコンパウンドスタートアップに対するみんなの考え方が一気に高まったんです。でもあれから、状況は大きく変わりました。
Matt：本当に変わりました。クレイジーなくらい。
──そこで今日は、まさに今、日本の起業家の多くが悩んでいる3つの大きな問いについて聞きたいと思っています。その3つの悩みというのは、正しい戦略は何なのか。自分たちのスピードは十分なのか。そして、どうすればもっと速くなれるのか。
Matt：それらは、すべての起業家が常に抱えている悩みでしょうね（笑）。AIで多少は拍車がかかってはいますが、そもそもが難しい問いです。
──それでも、Ripplingの成長はどんどん加速していっているように見えます。
Matt：本当に不思議な感覚でね。Ripplingはもともと、ありえないくらいのスピードで成長してきました。でも、気づいたんです。「10段階中の11」の先に、実は「12」があることを（笑）。
──僕も知りませんでした（笑）。まず、戦略の話からお聞きしたいと思います。AIエージェントのわかりやすいユースケースは、コーディングやカスタマーサポート、あとはリーガルの領域です。ただ、HRやファイナンスは「AIネイティブな体験」がまだ見えにくいなと感じています。そこで、Mattさんの視点を聞きたいんです。特に、ワークフローやシステム・オブ・レコードといった領域に取り組む起業家にとって、プロダクトロードマップについて「考えるべき戦略」とは？
Matt：広い意味を持つ問いですから、いろいろな論点があると思います。ただ、データや情報を預かる以上、ハルシネーションは許されません。「たまに合っている」では通用しない。だから、Ripplingの言葉で言うと「決定論的に動くシステム」を設計しなければならないんです。
たとえば、リーガルAIの「Harvey」を考えてみましょう。とても成功していて、ビジネスモデルも興味深い。長く続く事業を築けるでしょう。
でも、彼らが扱うのは、Large Language Modelのど真ん中の「L（Language）」、つまり言語です。LLMという新しいテクノロジーは、いま私たちが手にしている成熟度でも、“正解が一つに決まらない問題”と本質的に相性がいい。なぜなら言語は決定論的ではないからです。
完璧なリーガルドキュメントなんて存在せず、どんな問題であっても「唯一の正解」は無い。あるのは、自らが出した答えだけです。その後で裁判官なり陪審員なりが「良い文書だったかどうか」を判断するわけです。
Ripplingの事業は、Harveyから見ればスペクトラムの対極にある。「言語寄りで正解がない領域」の正反対にいます。給与計算があり、従業員を管理するHRシステムがあって、健康保険に入っているかどうか確認もする。こういう話には、明確に「間違った答え」が存在します。そして、間違った答えが大量にあるんです。
だからこそ、たとえインターフェース上ではLLMでも、その裏側では徹底して決定論的に動くソフトウェアを作らないといけません。起業家として考えると、そんなシステムが簡単に、当たり前に作れるような域には、まだ誰も届いていません。言い換えれば、やるべきことは山ほど残っているということです。
その機能、あの“Clippy”になっていないか？
──では、どういったシステムを作るべきだと？
Matt：これから膨大な時間、投資、エネルギーが注ぎ込まれて作るのは、まずLLMのレベルでは推論や判断をしながら、それでいて自分の作業を検証できる。そして、システム・オブ・レコードの処理が正しいことを証明でき、間違いがあればすぐ見抜いて示せる……そんな賢いシステムです。
だから、Ripplingが会社として取っているアプローチ、そして私がプロダクト責任者として掲げている戦略はこうです。
「ときどき動くソフトウェア」は出さない。そう、"Clippy"は出さない。
Clippyというのは、2000年ごろのMicrosoft WordやOfficeにいたクリップ型のアシスタントキャラクターです。「おっ、手紙を書こうとしていますね？」みたいに話しかけてくるやつ。
あんなふうに、いろんなものにAIを“貼り付ける”ことはできても、実際の価値がまったく届けられていないものは出さない。
だから、長期的な戦略、最終的に勝つ戦略を立てる賢明なやり方は何かというと、「時間をしっかりかけてリサーチと開発をして、エンジニアリングに取り組み、約束した価値を本当に届けられるシステムを作ること」。何度も期待を裏切った末に、ようやく形になるなんてしないことです。
正直、システム・オブ・レコードとAIの融合を狙うRipplingの競合の大半が、ここを盛大にしくじっていると感じます。「こんなのAIの粗悪品だ」と顧客に言われるようなものを出している。
誤解のないように言うと、Ripplingでも、私がとても優秀なPdMたちとプロダクトレビューをするとき、「それはClippyだよ」と言うことがあるんです。「確かにAIは載せてるけれど、顧客に届く価値は増えていないよ」ってね。
だから、「顧客のためにどんな問題を解こうとしているのか」という第一原理から考えることを軽んじてはいけない。そのうえで、毎回“ちゃんと”動くものを作るために、サイクルを回さなくてはならないのです。
おそらくこの領域で最終的に出てくるプロダクトのうち、いま世に出ているのは、せいぜい10%程度だと思います。何もかも、まだ超がつくほど初期段階なんです。
Software 1.0 2.0 3.0からもう一度考えてみて
──ぜひ聞きたいのが、Rippling AIのユースケースです。Mattさんがチームとのディナー会で参加するメンバーのプロフィールを把握するために、Rippling AIを使ったという投稿をXで見ました。顧客が試したあと「もうこれがない時代には戻れない！」と感じさせるようなRippling AIのユースケースは何だと考えますか？
Matt：この質問に答えるには「そもそもAIとは何であり 何ではないのか」という本質から立ち返るのがいいと思います。
（OpenAIの共同設立者やテスラの元AI部門責任者を経て、現在はAnthropicに在籍する）Andrej Karpathy氏は、このテーマについてとてもクリアな考えを持っています。彼が語ったのが「Software 1.0 2.0 3.0」という考え方です。
1.0は決定論的なコード。たいていは人間が手で書いたものです。Pythonでも何でも、用いる言語は構わない。Software 1.0は、書いたとおりに必ず動く昔ながらの基盤で、いま目にするものの大半を生み出してきました。
Software 2.0は機械学習。大量のデータを流し込んで、モデルを学習させ、いろいろなことを予測できるようにする。顔認識技術が出てきたのもここからですし、機械学習の応用は世の中に山ほどあって、その多くは私たちが日々使っているコンシューマー向けのアプリケーションにも、ビジネス向けのアプリケーションでも使われています。
これが「人工知能」と呼ばれたこともありましたが、本当のAIには似ても似つかないものでした。ただ膨大なデータセットのなかのパターンマッチングにすぎず、決定論的なSoftware 1.0ともまるで違う。でも補完的で、Software 2.0があることで確かに少しずつ便利になっていきました。
そして、Software 3.0がLLM、「大規模言語モデル」です。膨大な学習データの上で、トークンを次々とつなげながら、一定のレベルで推論する力を持ちます。
Software 1.0から3.0までは、すべてが共存しているんです。ただ、それぞれ持っている価値がまったく違う。そして、このソフトウェアの発展のなかで、一つの戦略が見えてきています。Software 3.0は、頻繁に2.0や1.0に頼っている、ということです。
AIモデルでできる強力なことの一つは、あなたが頼んだ仕事を実行するコードをAI自身に書かせることですよね。1年くらい前のAI界隈のジョークって、「1+1すらできないじゃん」というものでした。あの問題が解決したのは、モデルが頭の中で計算できるように訓練をしたからではなく、モデルにPythonを書かせて、計算を実行させて答えを持ち帰らせるようにしたからですよね。人間が電卓をサッと取り出すのと同じです。
そこで、世界をSoftware 1.0、2.0、3.0というレンズで捉えて、その3つのレイヤーすべてに3.0を通じてアクセスできるとしたら、問いはこうなります。
ソフトウェアの能力という足場をまるごと使って、「どうしたらプロダクトに価値を持たせられるか」。
Ripplingの場合、さっき話に出た投稿の例で言うと、あれはサンフランシスコで「トップパフォーマー」を集めたディナー会をやったときの話です。世界のいろいろな都市でやっていて、最も優秀な社員たちを称える会なんです。選ばれた一部のメンバーが集まって、全員がそれぞれのテーブルに着くので、私は自分と同じテーブルに誰がいるのか知りたかったんです。
それで、アシスタントが送ってくれた「一緒のテーブルにいる人たちのリスト」をスクリーンショットし、Rippling AIへ放り込んで、「同じテーブルにいる人たち全員についてプロフィールをまとめてくれ」と頼みました。いつ入社したのか、どの部署にいるのか、レポートラインは誰なのか。そして何より大事なのが、直近の評価において、私がディナー会のときに話に出せる、その人の活躍を箇条書きで示して欲しい、とリクエストしました。そうしたら、Rippling AIはパッと返してくれた。
ここで起きた“魔法”を考えてみてください。Software 3.0は「Mattが何をしようとしているのか」を考えた。「彼は相手を褒めたいんだな、いい上司でありたいんだな、なるほどわかった」とね。そして、自分でプランを立てはじめます。
次に、Software 1.0がデータベースに入って、パフォーマンス評価のデータを取り出す。そして、機械学習が得意とするテキスト全体のスキャンをする。それからまたSoftware 3.0に引き上げて、「話すべき話題はこれです」と返してくれる。
リストを反復しながら、必要な情報を取りに行き、プランを組み立てることは上のレイヤーで起きていて、それが下のレイヤーで実行されています。本当にシンプルなことです。でも、魔法のようなポイントは、権限管理の仕組みを横断しているという点なんです。
パフォーマンス評価を読む権限があるのか。これはデリケートな問題ですよね。データを取り出すこと、権限を適用すること、そして私が何を見たいのかを把握したうえで、パフォーマンス評価の各項目の意味を理解すること。これらはすべて、評価データのなかに別々に存在している情報です。
あくまでも、ごく基本的なユースケースで、Rippling AIにとってはむしろ簡単な部類の話ですが、私たちにできることを知ってもらう最初の入り口としては、良い例だと思います。
「給与が300ドル減った」......その問い合わせのために1時間が消えていく
──さらにRippling AIを知るために、ユースケースを教えてください。
Matt：Ripplingは給与計算と人事管理、福利厚生の管理、それに健康保険、コーポレートカード、デバイスのセキュリティやデバイスの発注、そして在庫管理まで、すべてを一つのシステムに統合しています。
そして、それらのデータをすべて、単一の基盤となるオブジェクトグラフに集約します。つまり、単一のデータストアですね。さらにその上に、各データの意味を説明するメタデータを整備しています。
これはAI以前からシステムに備わっていたのですが、あまり整備されていませんでした。そこで私たちはメタデータレイヤーをしっかり整備したんです。システム内のすべてのデータの意味を、きちんと説明できるようにね。
その結果、AIは自然言語、つまり普通の英語として読み取り、内容を理解したうえで、アクセスできるデータをどう推論するか判断できるようになりました。
──なるほど。この取り組みによってどんな影響があったんですか。
Matt：まず、システムを作る企業にとっての戦略的な観点から言うと、まず人間が嫌いなことからやるべきです。これは鉄則です。「あったら面白くない？」みたいな発想じゃダメなんです。実際に顧客のところへ行って、一日何をしているか見せてもらい、「一番やりたくない作業はどれですか」と聞くこと。
たとえば、多くの管理者が嫌がる作業の一つは、社員からの給与に関する質問への対応です。「なんで給料が下がったんですか」とか、「なんで300ドルも減ってるんですか」とか。社員が1,000人もいるのに、たった1人のために、給与明細の300ドルの差異を説明するために1時間も取られてしまう。でもやらないといけない。じゃなきゃ、アナリストを雇って対応させるしかないか……って。
この質問に答えるために、何をしなくちゃいけないと思いますか？
今週の給与明細を取り出して、2週間前の明細も取り出す。それだけでまず10分が消えます。あれこれ探って、PDFを並べて開いて見比べてみる。「総支給額は同じだ......あ、でも控除が違うぞ？なぜだろう。控除、控除、控除、控除......ああ、なるほど、今回の給与で、福利厚生の控除が前回より増えている。でも、どうしてだろう？」。
それでまたソフトウェアへ戻って、福利厚生システムを開き、何が変わったか調べる。すぐにはわからないけれど、やるしかない。そして、やっと理由がわかったら、今度は社員へのメッセージの下書きをする。何が違うのか、なぜ違うのかを説明する。すると、また追加の質問が返ってきたりして、社員とのやり取りが続く......。
想像してみてください。これだけで1〜2時間が消えるんです。私はこの作業をなくしたい。社員がちゃんと回答をもらえるようにはしたいが、でも人間が関わらなくて済むようにしたいんです。
Ripplingは、あなたの給与明細を読み取り、すべての控除項目を理解することができます。LLMは福利厚生が変わっていることを判断して、「福利厚生のデータを確認しにいく必要がありそうだ」となる。そして裏側で、福利厚生エージェントに問い合わせて、「何が変わったか」を照会します。すると一定期間の変更内容をまとめて返してくれます。
「この人は1月は福利厚生に未加入で、2月1日から加入しているので、だから2月には1月にはなかった福利厚生の控除が発生するから、それが手取りが減った理由だ」とわかる。エージェントは社員へのメールを書くことも、チャットで直接返信を書くこともできます。
こういうのは、あまりセクシーなことだとは思えないかもしれない。社員からしても、「人の代わりにエージェントがやってくれるのか」くらいの感覚でしょう。でも管理者にとっては違うんです。この作業にお金と時間を使っている人たちにとっては、とんでもないレバレッジなんです。
こうした、「ただ大変なだけの作業」は、Software 1.0では自動化も難しかった。でも、Software 3.0によるLLMのアプローチなら解決できるんです。至るところにある雑務を一掃できるようになる。
このカテゴリには、本当にワクワクしています。やれることは無数にありますしね。とにかく世界は、根本的に変わっていくと思う。会社を運営するのに今ほど多くの人を雇わなくて済むようになる。会社運営の管理コストは大幅に下がっていくはずです。
エージェントが、複数の人間をまたいで動く「マルチプレイヤー」に
──セクシーではないと言いますが、十分に魅力的なケースですよ。
Matt：もう一つだけ、例を。「マルチプレイヤー」という概念を紹介します。今お話ししたのは「社員が質問し、エージェントが作業して、答えを返す」というものでした。1対1のやり取りですよね。次は、休暇を例にしてお話ししましょう。
たとえば、出産した場合、一定期間の休暇が取れます。会社からもお金が支払われますし、国からも手当が出ます。保険会社からも費用が補填されます。休暇は3ヶ月のこともあれば、1年に及ぶかもしれません。帝王切開だった場合は、保障される期間や内容が変わります。出産が予定より早まったり遅れたりすることもありますしね。休暇の開始日が直前に変わることもあります。
だから休暇の状況をずっと追い続ける必要があるんです。実は、これはとても煩雑で、たくさんの人が関わります。HR部門、ファイナンス部門、そして給与部門。こうしたことは育児休暇だけでなく、忌引きなど様々な種類の休暇で起きるわけです。
Ripplingでは、休暇を扱うエージェントを提供することにしました。管理者も社員も、ファイナンスやリーガルのメンバーも、このエージェントとやり取りできます。裏側ではすべての情報を正確に追跡し、その人の状況、休暇期間、給与をすべて把握しています。その上で、すべての推論やコミュニケーションが行なわれます。このエージェントが一番上に立って、すべてを自動で処理するんです。
だから、もし「赤ちゃんが早く生まれた」と伝えたら、エージェントは瞬時に判断できます。「給与を調整しなければいけない、休暇の開始日をこの日に設定して、雇用保護期間もここからはじまるように調整しなければ」とかね。こうしたタスクの長いリストを、上から順に自動でこなしていきます。
だから経済的な話をすると、Ripplingは顧客にトークン単位ではなく、アウトカムベース課金できるようになる。SaaSのサブスクリプションは続けますが、アウトカムベース課金も導入していきます。
では、この処理にどれだけのトークンを消費するのか。その裏側の処理のためにOpenAIやAnthropicにいくら支払うのか。もちろん、コストは多少かかります。でも、私たちにとって、そのグロスマージンはとんでもなく大きいものになります。
起業家が取り組むべき、3つの「教訓」
──ここまでのお話でも、起業家が取り組むべき「戦略」について多くの示唆があります。
Matt：教訓をまとめるなら、こんな感じです。
まず、顧客が嫌がっている問題を解決すること。必ずそこからはじめてください。そして、本物の問題を解決すること。徹底的に磨き込むために、しっかり時間をかけてください。AIプロダクトを世に出したいからといって、中途半端なソリューションを出さないように。当然だろうと思うかもしれませんが、Ripplingの競合たちが実際に犯している間違いです。
そして、徹底的に磨き込むという観点で考えると、Software 1.0の世界で必要なこと、Software 3.0の世界で必要なこと、そのギャップをプロダクトでどう埋めるかを考えてください。重要なビジネスの場面で、90%の精度では足りませんから。
Ripplingのようにこういったソリューションを提供できる会社は、圧倒的なグロスマージンを手にすることになるはずです。SaaSは常に高いグロスマージンを実現してきましたが、今はAnthropicやOpenAIへの支払いが増えて、マージンが下がるのではという懸念が投資家の間にあります。でも私は、本当に価値あるものを提供できていれば、マージンは問題にならないと思いますね。
Software 1.0の土台がないAIは勝てないのか
──Software 1.0、2.0、3.0の話に戻ると、本当に長く続くソフトウェア会社になるには、Software 1.0のレイヤーでしっかり結果を出すことが必要で、カバーする情報の範囲も広くなければならないのではと。だから戦略の一つは、できるだけ多くのデータを取り込むことになるのでしょうか。
Matt：それは私自身がまだ答えを出せていないことなんです。
というのも、私はすでにそれを考えなくて済む立場にいるからなんですよね。Ripplingはすでに最高のSoftware 1.0と2.0を持っていますから。リスク管理など、あらゆる面で素晴らしいプラットフォームがあって、数万社がこのシステムで動いており、膨大なデータと顧客獲得の勢いもあります。
Hiroのような投資家の立場からすると、スタートアップが売り込みに来たとき、そのスタートアップはAIを持っている、LLMで「何かやっている」わけです。でも、それはOpenAIやAnthropicの上に薄いレイヤーを乗せているだけかもしれない。
では、その裏側には何があるのか。AIを支える基盤インフラをどうやって構築し、持続させるつもりなのか。ここを見極めたいところですよね。
本当に多くのAIスタートアップが、実際にはベースモデルの上のレイヤーをいじっているだけで、どこに持続性があるかが疑問です。
だからSoftware 1.0のレイヤーでしっかりやらなければという話は、ビジネスソフトウェアの領域にいるなら、コアな業務データを自分たちで押さえている必要がある、ということなんです。あるいは、深く差別化された業務プロセスのツールを提供できなければなりません。
でもそれも、リーガルなど、ごく一部の言語処理が中心の分野を除けば、最終的にはデータベースに行き着くでしょう。データベースを持っていなくて、データを生み出すワークフローも持っていないなら、その上でLLMを動かせる立場になるのはとても難しいはずです。
Ripplingがスピードを仕組みにした「Blitz」
──ここから、プロダクトの話に移らせてください。外から見ていると、以前よりもずっと速く、多くのものを出しているように見えます。実際そう感じていますか。どうやって実現しているのでしょうか。組織図に変化があったのか、何かプロセスを導入したのか。
Matt：その答えは、そんなに複雑なものではないでしょう。スピードは、それ自体が競争優位なんです。スピードと品質は相反すると思われがちですが、必ずしもそうではない。すばやくサイクルを回しさえすれば、スピードと品質は両立できます。
「代謝の高い会社」というのがあって。そういう会社の目標は、とにかく速くやることです。少し考えたら、できるだけ早く動く。なぜなら、決断について考えても何も学べないから。実際に決断して、結果を見ることでしか学べない。これをプロダクト開発に当てはめると、「いかに早く最初の1つを作って、人の目に触れさせるか」ということになる。
単なるMVPとは違います。そう感じるとしたら、フレームワークに囚われた矮小化した考え方じゃないでしょうか。むしろ、最大限に野心的なものを出すようなイメージです。これがまさにRippling流のやり方なのです。
できるだけ早い段階で、すべての機能を入れようとします。さらに大きなプロダクトであっても、「昨日にでも市場に出したかった」という切迫感がある。さもないと、競合からボコボコにやられてしまう。まだやられていないのは、私たちが常に先を行っているからです。
──いや、ボコボコにしている側でしょう（笑）。
Matt：そうだといいんですけどね。でも根底にあるのは、考えすぎないという姿勢です。
私がよく使うマネジメントのフレームワークがあって、どんな決断も完璧には当てられない、というものなんです。プロジェクトの人員が多すぎるか少なすぎるか、リリースが早すぎるか遅すぎるか……完璧な正解を出すことは絶対にできません。
だからリーダーとして、意思決定者として考えるべきは、どうせ正解は出せないなら、どちらに振れたほうが「まだマシ」なのかを見極めて、そっちへ舵を切る。
スピードで言えば、「速すぎること」はあり得ます。準備不足のままリリースしてしまうことも、確かにあります。でも、遅すぎることもあり得るでしょう。「起こりうる問題はすべて考えられる」と過信して、事前にすべて対処しようとしてしまったり。
起きるかどうかもわからないエッジケースのために余分に時間をかけて作り込んで、そして実際に市場に出してみると、結果として問題がまったく別のところで起きたりする。こちらで一生懸命やったことが全部無駄になってしまったわけです。そもそも顧客にとって問題ではなかったから、みたいな理由でね。
だから、考えすぎるか、考えなさすぎるか。スピードを出しすぎるか、出さなすぎるか。その答えは「考えを減らして、スピードを上げる」ですね。それを何度も何度も繰り返す。つまずくこともあるし、ミスもするでしょう。でも、学ぶスピードが圧倒的に速くなる。
だからRipplingでは、本当に重要な戦略的プロジェクトでは「Blitz（ブリッツ）」というやり方をしています。
──Blitz……どういった方法なのでしょう？
Matt：Parkerまたは私が入って、チームと毎週......場合によっては毎日集まります。この部屋で交わされるすべてのコミットメントには、「MMDD（日付）」と「DRI（担当者）」がひも付かなくてはいけないようにしているんです。
部屋には議事録を取る人がいて、すべてのコミットメントの内容、担当者、日付を記録します。そして次に集まったとき、もし自分がコミットしたものをたった1つでも、期日どおりに出せなかったら……非常にまずいことになります。
出せないこと自体は許される。でも「出せない」と事前に宣言しなければならない。ミーティングにただ現れて「おっと、やってませんでした」では済まされません。みんなすぐにそれを学びます。こうやって私たちはエンジンの代謝を上げているんです。
結果的に、戦略的な優位性につながる仕組みだと捉えています。いつも完璧なわけではなくても、ペースは高く保てる。だから大量にリリースし続けられるし、AIはエンジニアの生産性を間違いなく加速させています。
社内AIコパイロット「Ripples」が変えたエンジニアの仕事
──「AIはエンジニアの生産性を加速させている」と言いますが、まさにそこが気になっていたんです。スピードアップのために社内ツールを作っているんですか？
Matt：もちろんです。社内のAIコパイロットにはかわいい名前をつけていて、「Ripples」っていうんです。
Ripplingには、DevEx（開発者体験チーム）があって、彼らはインフラ構築を担ってくれています。開発者の生産性を向上させるための、SOPのようなものを整備してくれているんです……ただ、最初に断っておくと、Ripplingが他社にはない特別なことをしているとは思っていません。トークン消費の最適化に取り組みながら、他の会社と同じことをしているだけです。みんなCodexとClaude Codeを、ガンガン叩いていますからね。
興味深いのは「何が加速したか」という点です。それはゼロイチのプロダクト開発ではないし、ソフトウェアの基幹部分の重い作業でもない。たとえば、給与計算エンジンやデバイスセキュリティの監視システムは非常にリスクが高いので、AIに好き勝手やらせるわけにはいきません。ここはもちろん慎重に、細心の注意を払う必要があります。
でもそのほかにも、プロダクトの中には250件のJiraチケットが積まれていたんです。「このボタンがたまに動かない」とか、「この計算が実はちょっとだけずれている」とか。そういう細かいものが溜まってたんです。
エンジニアは、そういうあまり気持ちが乗らない仕事を後回しにしがちです。そういった領域では、AIに思い切りやらせました。品質問題のバックログを一掃して、パフォーマンス問題のバックログも全部片付けました。
たとえば、このエンドポイントがタイムアウトしている、P99が20秒かかっている、これをどうやって2秒まで縮めようか......AIはエンジニアに対して、この呼び出しのどこで遅延が発生しているか、どう修正すればいいかを、非常にうまく説明してくれます。
ここがポイントです。エンジニアは修正作業自体は好きですから。でも、5年前のコードを掘り返して、なぜこう動いているかを調べるのは好きじゃない。その点、AIには感情がないから、「わかった、やっておくよ」とやってくれる。この使い方が、社内で大きな成果をあげています。
──なるほど、Ripplesが、Jiraチケットを処理してくれていると。
Matt：そうです。エンジニアの作業を助けてくれています。自律的に動くわけではないけれど、気が重くなるような作業が、ぐっと取りかかりやすくなるんです。「よし、片付けるか」って気になれるんです。みんなプロダクトを良くしたいし、バックログも早く消したいので、AIがそれをずっと楽にしてくれています。
──Ripplesは、いわばRippling独自のハーネスみたいなものですね。
Matt：そうです。SOPであり、標準的な指示書であり、スキルファイルであり、エージェントをレールに乗せるためのあらゆるものですね。
AI時代、ロードマップは1〜2ヶ月で吹き飛ぶ。それでも前に進む方法
──AIの変化が速すぎて、プロダクトロードマップを作るのがどんどん難しくなっていると感じます。6ヶ月前に決めたことがすぐ陳腐化してしまう。Ripplingではどうやって対処していますか。
Matt：いい質問ですね。これに対する私のアプローチは、「バーベル」で考えることです。
バーベルの片側は、大きな全体像を考えること。ユーザー体験がどうあるべきかを議論する。テクノロジーが進化していく目先の分岐は一旦無視して、理想のケースを考えます。もう片側は中間をすべて忘れて、アセンブリレベルのロードマップに戻るのです。
というのも、RipplingのAIロードマップは本当に猛スピードで動いていて変化していますから、超具体的なレベルまで落とし込まなくちゃいけなかったんです。SlackのMCP連携はいつ出すのか、エージェント向けSOP管理環境はいつ出すかなど、粒度を非常に細かくして、それらを積み上げてビジョンへ向かっているように見える形にする。
昔のようにもっと安定していた時代なら、粗めの粒度でロードマップを持って、それを論理的なかたまりで考えていくことができましたが、そうはいかなくなってますよね。AIプロダクトに限っては、何度やっても1〜2ヶ月で吹き飛びますから。
──ということはやはり、ケイデンスを速めているんですね。
Matt：とにかく代謝を高くして、ボトムアップで作っていくんです。マーケティングチームにとって悩ましいことは、取っかかりをつかめないことです。7月に何かを発表しようと決めても、「えっ、まだ4月だよ」と。6月以降のことはあまり約束ができないんです。マーケティングやセールスなど開発の“先”にいる人たちには、「この先数ヶ月で何が出てくるかは、はっきりとは言えない」と伝えています。
新しい機能を次から次へと、ものすごいスピードで世に出していることがもたらすインパクトは──2年後振り返ったとき、何につながっているのかは正直わかりません。でも、私たちがボトムアップで出すものは、すべて即座に役に立つということは確かです。
CPOの仕事も変わった。今は毎日、会社の価値を左右する判断を下している
──正式にCPOになってからは1年ほどですね。ここ数年で、その役割は変わったと思いますか。CPOに求められることを定義するとしたら、何を挙げますか。
Matt：私の場合、創業から1年半あたりで入社して、最初の7年間はCOOでした。なぜ私がプロダクトを引き受けたかというと、外部からエグゼクティブを採用しても、Ripplingの全体像を把握しながら、Rippling流のやり方まで身につけられる人はいないと思ったからです。とにかく、咀嚼すべきことが膨大すぎるので。
それで私が手を挙げて、「いいよ、私がプロダクトをやる」と言ったんです。CEOのParkerは、ホッと胸をなでおろしていました。たぶん彼は、外部の人材を探し回りたくなかったんだと思いますけどね……（笑）。
でも、すぐにわかったのは、手を挙げて本当によかったということ。そのころから、AIへの転換が本格的に加速しはじめたタイミングでしたから。たしかに、AI以前のプロダクト責任者を経験していないのはハンデだと思います。でも一つ言えるのは、プロダクトリーダーとしての私は、毎日連続で重大な戦略判断をしている感覚があり、これが最も重要なことなのです。
正直に言うと、本当に疲れます。プロダクトに関するあらゆる判断が、会社の価値に大きな影響を及ぼしますから。
以前のCPOの仕事は、管理業務が多かったと思うんです。PdMを束ねて方針を示したり、プレスリリースから逆算したプロセスを整えたり、PRDのフォーマットを整えたり、定期的なプロダクトレビューで品質を維持したりね。それがCPOの仕事であるという印象でした。
従来のSaaSのやり方、特に私たちが採っていた戦略は、既存の各プロダクト領域の機能をRipplingのやり方で作りきって、そこから価値を取ってきました。かなりわかりやすいプレイブックだったんです。
でも今は、AIで可能になったことを武器に、すべてのカテゴリーを再発明していかなければならなくなりました。だから、プロダクトリーダーの役割は、もっと会社全体の成果に直結するようになった。少なくとも私たちの規模の会社にとっては、ここ長い間なかった感覚なんです。今も、ガバナンスとプロセスが大事なことに変わりはありませんけれど。
──確かにそうですね。ずっと重大な判断をし続けている感じですよね。一つ判断を間違えると、時代遅れになりかねない。
Matt：まさに、そこなんです。私は、人間に未来を予測する力がそんなにあるとも考えません。だから、「2年後に何が起こるか確信が持てないのなら、唯一の選択肢は今すぐ価値を届けること」です。
今いる場所から、できるだけ速くサイクルを回して舵を取っていく。そして、たまに立ち止まって俯瞰して、「自分たちは、向かいたい方向を向けているか」と自問するんです。自分の未来予測の能力を過信しすぎないことです。
昨日、シリコンバレーの投資家であるSarah Guoさんと話す機会がありました。彼女はGreylock Partnersを経て、今はConvictionという非常に成功しているAI特化のベンチャーファームを率いています。彼女がConvictionを立ち上げたのは2022年。AIブームから見ると少し早すぎるくらいでしたが、彼女の賭けは正しかった。「早くて正しい動きができる」というのは最高なことですよね。
彼女は2022年にConvictionの立ち上げについてのエッセイを書いていて、昨日、彼女に会う前に読み返したんです。そうしたら、書かれていた言葉の多くが今も正しかった。ただ多くの部分は、大げさな言い方ですが、完全に時代遅れだった。古い感じだったんです。「こんな言葉もう使わないよな」という感じのね。
そして今は2026年。もしあの時点で、現在のAIがどうなっているかを予測しようとしていたら、間違いなく完全に外れていたはずです。一度試してみてほしいのですが、2024年に書かれた「2026年の予測」をいま読み返してみると、いかに重要なことを外していたかがわかるでしょう。謙虚になれるはずですよ。
プロダクト戦略家として、起業家として、会社をはじめる人なら誰でも前提として持っておくべき心得は「2028年を予測する能力はかなり低い」ということ。
──今日を生き、今をできる限り深く理解して、自分の判断に活かすべし、と。
Matt：そうです。できるだけ速くサイクルを回して、ボトムアップで次の一手を出し続ける。顧客の問題を解決できると強く確信できるものだけをね。
Rippling AIが成長に与えた影響。正直、まだ1%だ
──ずっと高い成長率を維持してきたわけですが、これはRippling AIを含めたAI需要のおかげなのでしょうか。それとも、社内でAIを活用した効率化によるものなのでしょうか。
Matt：正直に言うと、どちらもあまり関係ないかもしれません。「今のところは」という意味でね。
私たちのモメンタムは常に「Ripplingを使いはじめるともっと使いたくなる」という会社のコアテーゼ（中心となる主張や仮説）によるものなんです。私たちが目指しているのは、ビジネス全体をRipplingで動かしてもらうこと。カスタムワークフローやスプレッドシートで管理している社内プロセスも、給与計算、HR、デバイス管理、コーポレートカード、経費管理、調達もすべてRipplingで動かしてほしいわけです。
だから、私たちの成長を支えているのは、顧客が成長していること。そして彼らがプラットフォームをより多く使い、採用も増やしていることなんです。AIで雇用が失われるという話を聞きますが、今のところは起きていないですしね。だから正直に言って、私たちの成長の多くは、ずっと取り組んできた勢いからきている、というのが正しいでしょう。
現段階で、AIが私たちの流れをすでに大きく変えたのは、デモの場面です。新規顧客が今のRipplingを他社と比較するとき、「Ripplingでできること」を見せると圧勝できる。だから私たちを最も加速させたのは「勝率」と表せるでしょうね。新規顧客獲得で、他社に勝つ力です。
そして素晴らしいのは、それらはまだ苗木の状態ということ。果樹園に植えた苗木がRipplingの上で育っていく。時間とともに、もっと使ってもらえるようになる。だから、AIはソフトウェア開発を加速させました。AIは顧客獲得でも優位をもたらした。でも、この先数年でRipplingが遂げる成長でいえば、まだ1%程度しか恩恵を受けていないと思います。
──これからが本番ということですね。
Matt：AIのなかでも、最も機密性の高いデータを扱うソフトウェアは、急いで出してはいけないし、正しくやらなければならない。だから、今まさに正しくて顧客のためになることをたくさん進めているわけですが、そこに到達するまでに少し余計に時間がかかりました。私たちの場合、リーガルAIのように「書類を代筆してあげましょう」という具合にはなりませんから。はるかに重いエンジニアリングが必要でした。
でも間違いなく、私たちはソフトウェア業界でAIの最大の受益者の一つになるでしょう。世の中はまだ気づいていないと思いますが、私には本当に、本当にはっきり見えています。
──ええ、私も感じます。そうなる予感がします。
GTMを後回しにする創業者が、必ずはまる罠
──では最後の質問です。すべての創業者が考えるべき、一つのトピックや問いは何でしょう。「もっと早く考えておけばよかった」と悔やむことも含めて。
Matt：GTM（Go To Market）ですね。
創業者が技術を理解すること、そして顧客のために解くべき課題を理解することは、とても重要です。でも、若い創業者と話すたびに、「顧客にはどうやってリーチするの？」と聞くと、すると彼らは少し考えて「セールスを使います」と言う。
私は「ああ、セールスを使うんですね。ちなみに、セールスより非効率なGTMが思いつきますか？」と聞くんです。すると彼らは「えっ、どういう意味ですか？」となります。「セールスを雇って顧客を探させるより非効率な顧客獲得方法が思いつくか？」と。すると答えは必ず「いや、思いつかない」。それは、そうなんですよ。これより非効率なGTMのやり方なんてありませんから。
このとんでもない変化が起きている環境でB2Bソフトウェアを作っているなら、GTMの問題を解かなければならない。顧客獲得コストを下げる方法を見つけなくちゃいけないんです。ビジネス全体の経済プロファイルをどう改善するかをね。
忘れがちなんですが、起業家として覚えておくべきは、会社というのは最終的に「キャッシュマシン」でなければなりません。投じた資金より、はるかに多くのキャッシュを生む。キャッシュフローが、すべての会社の価値の源泉です。
だからキャッシュを生む方法を見つけなければならない。GTMで顧客を獲得し、それによって売り上げを得て、十分なグロスマージンを確保する。それで営業費用を賄い、そこからEBITが生まれ、キャッシュフローにつながる。その仕組み全体を、しっかり理解してください。
だから、すべての起業家がもっと早く考えるべきことは「どうやってキャッシュマシンにするか」です。基本的な原則として、今のAI界隈は熱狂状態で、投資家からのキャッシュが無料に見える。ちなみに、「投資家からのキャッシュ」と「顧客からのキャッシュ」はまったく違いますからね。投資家からのキャッシュは、長い目で見れば会社にとって何の価値ももたらしませんからね。
「GTMは後で考えればいい」と言いがちですが、それは落とし穴です。資本がまるで無料に見えるこの異常な環境にいても、最終的には大量のキャッシュを生むビジネスを作らなければならない。その義務からは、決して逃れられないんです。
──とても根本的で、本当に重要な問いだと思います。本当にありがとうございました。久しぶりに話せてよかったです。近いうちに東京でお会いできるといいですね。
Matt：ええ、ぜひ。また食の冒険に行きましょう。ありがとうございました。
