プロダクトチームを研究所のように運営する：Dan Shipperが語る、動き続けるフロンティアの上での開発

Shipperは、講演の前の週にリリースされたモデル、Fable 5.1とAstra 6を使って問題を提示した。彼はこれらで作ったものをいくつか紹介した。一つはワーテルローの戦いの3D再現で、本人いわく歴史的に正確なものだ。これはたった一つのプロンプトで作られ、モデルは約4時間かけて取り組んだという。ある同僚は、エージェント同士がどう相互作用し、どうまとめてシミュレーションされるかについての科学論文をモデルに与えた。数回のプロンプトの後には、自分のコンピューター上で約1000体のエージェントが可視化付きで動いていた。Shipperによれば、Astraは今やPremiereに入ってEveryの動画を本格的に編集できるほど優秀になっている。さらに、スライド資料のアニメーションも、資料自体の大部分もAstraが作ったもので、自分はアニメーションタブに一度も触れていないと付け加えた。

そのうえで彼は、プロダクトリーダーはどうすべきかと問いかけた。目の前の仕事に集中して黙々と進めるのも、しばらくは通用するかもしれない。顧客に聞くのは効果が限られる。多くの顧客はこうしたツールに詳しくなく、何をすべきかは会社が示してくれると期待しているからだ。B2BのSaaSアプリを3Dのマルチプレイヤー戦略ゲームに作り変えることも可能ではあるが、難しい。会場の全員がこの問題に直面しており、自分も例外ではないと彼は語った。

彼が最初に掲げたルールは、冗談めかしつつも真面目な意図を含むものだった。瞑想リトリート、サイケデリック体験、あるいはフロンティアモデルとの初めての出会いから30日以内に、人生の大きな決断をしてはならない。

Shipperの診断では、プロダクトチームは全員に、ロードマップの実行とフロンティアへの追随という二つのことを同時に求めている。彼はこれらを相反する働き方だと考えている。フロンティアの探索は発散的だ。新しいモデルを試し、デモを作り、さまざまなことに手を出し、そのほとんどを捨てる。活用は収束的だ。集中し、ノーと言い、すでに計画したロードマップを実行する。同じ人に両方を求めれば、その人たちは常に二方向に引き裂かれることになる。

彼の提案は、プロダクト組織を研究所のように運営すること、少なくとも研究所の要素を加えることだ。

Shipperによれば、今日のほとんどの組織では、誰もが探索と実行を少しずつ担っている。また、どの組織にも他の人よりはるかに多く探索する人が数人いるはずだと彼は確信しており、そうした人を見つけ出すことが重要だと述べた。彼らがアーリーアダプターだ。Shipperは自分もその一人だと考えている。週末にはすでにAstraやFableを動かし、個人プロジェクトや、仕事に持ち込むかもしれない実験に取り組んでいるような人たちだ。彼らが熱中するものの多くは役に立たないだろう。しかし彼らは「すでに未来に生きている」ため、プロダクトがどうなり得るかについて優れた感覚を持っている。

その欠点は、彼の言葉を借りれば、アーリーアダプターが「とてつもなく周りの気を散らす存在になり得る」ことだ。したがってプロダクトリーダーにとって重要な問いは、チーム内の、そして場合によっては顧客の中のアーリーアダプターを、他の全員の気を散らすことなくどう活かすかである。

Everyが見出した解決策であり、多くの優れた企業が行き着きつつあると彼が考えるのは、独立したラボチームだ。一部の人はすでに機能しているものの改善とスケールに責任を持つ。別の人たちは次に来るものの探索に責任を持つ。

これは高くつくという反論を彼は予想していた。それに対する答えは、AIのおかげで一人だけのラボチームが可能になったということだ。新しいモデルが出るたびにそれを探索して報告する役目を、一人に任せればいい。今では一人ひとりがAstraやFableに膨大な仕事をさせられるので、必要な投資は小さいと彼は主張した。

Shipperは二つのチームを主に期待値によって区別した。ラボチームは、特に新しいモデルが登場したときに能力を探索し、多くの実験を並行して進める。作ったものの約90％は捨てることを想定すべきだ。プロダクトチームはプロダクトを改善・スケールし、既存顧客に価値を届け、「がらくたを大量に投げつける」のではなく、プロダクトの一貫性とわかりやすさを保つ。ラボが試したものの約10％を採用することを想定すべきだ。

彼はラボチーム自体が新しいものではないことを認めた。彼の主張は、この技術によって、ラボチームがかつてない形で機能し始めているということだ。主な例として挙げたのはAnthropic Labsである。Shipperによれば、Claude Codeはその小さな実験グループから生まれたもので、彼はそれを史上最大級かつ最も成功した生産性プロダクトの一つと呼んだ。MCP、スキル、Claude designもその小さなグループから生まれ、Anthropicはうまくいった実験により多く投資してきたという。さらに、外部の誰も目にしなかった実験がおそらく他に1000件はあっただろうと付け加えた。

Shipperの最初の推奨は、非常に小さなチームだ。かつての標準は、Jeff Bezosが提唱した8〜10人の「ツーピザチーム」だった。AI時代に向けて彼が提案するのは、最大でも1〜2人の「ツースライスチーム」だ。その理由は、今では1〜2人でも非常に速く非常に遠くまで進めること、そしてそれより大きくなると調整のコストや相反するビジョンが生じることにある。

Everyでうまくいっており、他社でも機能し始めていると彼が考える組み合わせが、海賊と建築家だ。海賊は価値を見つけることに取り憑かれた「スロップ・キャノン（粗製品の大砲）」である。大量の雑な作業をこなし、そのほとんどを捨て、最終的に何か面白いものを見つける。Shipperは自分を海賊だと称している。建築家は、たとえば海賊がバイブコーディングしたもののような雑然としたシステムを見て、それを価値があり、美しく、拡張可能なものに仕上げる。この組み合わせはAIにおいて非常に強力だと彼は考えている。

二つ目の実践はドッグフーディングだ。ラボチームにとって最も重要なのは、何かを作ることと、それが良いものかどうかを知ることの間のループをできる限り緊密にすることだと彼は述べた。最も緊密なループは、自分自身のために作ることだ。それが無理なら、すばやくテストしてくれるアーリーアダプターの顧客を何人か集めることを勧めた。理想的には、実験は実際の仕事で使われるべきだ。そうすれば、それが本当に役立つのか、単に目新しいだけなのかを見分けられる。彼はこの区別が非常に重要だと強調した。

Shipperは、この実践はおそらくプロダクトチームのあるべき運営とは異なると指摘した。ラボは、たとえ同じ目標を競合するアプローチで狙うことになっても、多くの実験を並行して進めるべきだ。それは雑然として一貫性がないように見えるかもしれない。彼の考えでは、能力が変化するとフロンティアは非常に不確実になり、異なる人が異なる角度から同じ問題に取り組むことで、その全体像を描き、何に価値があるかを判断しやすくなる。

最後の実践は、ほとんどの実験が捨てられるにもかかわらず、実験のROIを全体としてプラスにすることだ。Shipperは三つの方法を挙げた。

• 外部向けコンテンツ。 Everyは、何を試し、何がうまくいき、何がうまくいかなかったかを公開することで良い成果を上げてきた。人々はこれを楽しんでくれ、Everyの記事やプロダクトに読者や顧客を呼び込んでいると彼は述べた。
• アーリーアダプター・プログラム。 多くの顧客は会社ともっと近い関係になりたいと考えており、ラボと協働することでそれが実現する。
• 学びをプロダクトチームと共有すること。 最低限、ラボは今何が可能になったかをプロダクトチームに伝えるべきだ。そうすればプロダクトチームは、自らフロンティアを探索しなくても新しい能力を考慮に入れられる。

次にShipperは、ラボの成果をプロダクトへ移す方法を取り上げた。彼は左から右へ流れるパイプラインを説明した。アイデアはまずラボ内だけの実験として始まる。ほとんどは失敗するが、いくつかは機能し始める。それらは実際の仕事でテストされる。Everyでの最初のテストは、チームの他のメンバーがそのツールを採用し、気に入るかどうかだ。適切な仕組みは、その会社がどんな顧客を相手にしているかによって変わると彼は指摘した。社内での採用が進めば、そのアイデアはアーリーアダプターの顧客に提供でき、プロダクトチームがロードマップのどこに組み込むかを検討できる段階にあることが多い。そこでもすべてが生き残るわけではないが、最終的にはいくつかがスケールしてリリースできる状態になる。

彼の具体例は、Everyの編集長であるKateに関するものだった。Shipperは3年間、Kateを「愛情を込めて」自動化しようとしてきたという。Kateはコピーエディットに関して確かなセンスを持っている。Everyが現在約30人規模になった今、すべてのコピーエディットを彼女一人でこなすことはできない。同じレベルのセンスを持つ人を採用して育てるのも難しい。Shipperは、彼女がこれ以上コピーエディットで夜遅くまで働かなくても、AIによって彼女の影響力を広げたいと考えた。

彼は、Kateが朝起きたときに受け取ったメッセージを見せた。「大したことじゃないけど、過去3年間のあなたのコピーエディットを全部ダウンロードして、最新の記事でFableにコピーエディットをさせてみた」。こうした実験を数年間続けてきたが、Kateが実際に使えるほど能力が向上したのはごく最近のことだと彼は述べた。社内ではこれを「Kate bench」と呼んでいる。

次のステップは社内での利用だった。Everyには社内エージェントがあり、Shipperはこれを会社全体のための単一のエージェントだと説明した。Kateは今、原稿に対して「Kateパス」をかけるようこのエージェントに頼んでいる。エージェントは彼女の過去の編集をもとに、彼女がするのと同じように修正提案を入れ、時間とともに改善していくよう作られている。Shipperはこれを空き時間に作った。彼いわく、これは「なんとなく機能している」。Kateが使い始め、他の人にも広がりつつあり、彼はこれを非常に良い兆候だと評した。

社内利用の段階で、Shipperは建築家を呼び込む。今回はYanekがその役を担った。Yanekは彼と一緒に働き、なんとなく機能している雑なものを良いものに仕上げる人物だ。Yanekは、ドキュメントごとに提案がいくつ採用されたか、そしてエージェントのパスの後にKateがどれだけ作業をする必要があるかを表示するダッシュボードを作った。これはエージェントの処理後に彼女が行う編集を追跡することで実現している。Shipperの報告によると、この種の編集でKateが行った作業量は前月より12％減った。Yanekの仕事は、プロトタイプを、改善と複利的な成長を続けられる本物のシステムに変えることだと彼は説明した。

このプロジェクトは現在、Everyがアーリーアダプターの顧客に提供することを検討する段階にある。また、同じプロセスがコピーエディット以外でも機能するかどうかも検討している。Shipperは機能すると考えているが、それはまだ未解決の問いだとした。彼はこの歩みを、ラボ内だけの実験から、顧客に提供できると考えられるものへの移行としてまとめた。

Shipperは、アイデアをパイプラインに沿って前進させるための二つの実践を示した。

一つ目は、パイプラインを定期的に見直すことだ。彼はNotionでトラッカーを管理しており、毎週の全社ミーティングで全員がその内容について話し合う。彼はこれを極めて重要だと述べた。実験をしていないプロダクトチームのメンバーも、ラボが何を面白いと考え、何が前進しているのかを知ることができる。自分たちで慌てて実験をしなくても、そのアイデアが有望だと証明された場合のプロダクトへの影響を考えられる。彼の考えでは、これによってラボとプロダクト組織の足並みがそろう。

二つ目は、アイデアを先に進めるための明確な判断基準を定め、前進するたびにそれをイベントにすることだ。Everyの基準は次のとおりだ。

• 人々は使っているか、そして繰り返し使っているか？ 社内での利用を価値の代理指標とする。
• 既存のものより10倍優れているか？ Shipperはこれを興味深いフィルターだと述べた。新しいものはわくわくするが、本当の問いは1カ月後もまだ優れているかどうかであり、それは時間をかけて利用状況を観察しなければわからない。
• コストは見合うか？ 今は機能していても、それを大規模に顧客に提供できるか。

明確な基準があることでプロセスの厳密さが保たれると彼は述べた。

最終的な目標は、勝者をメインのプロダクトに統合することだとShipperは言う。研究所や意図的な自己破壊は古くからある考え方だと認めつつ、AIによってチームが非常に速く動けるようになった今だからこそ、ようやくうまく機能するようになったと主張した。

彼の例はOpenAIのCodexだった。彼の説明によれば、小さなチームがメインのアプリとは別にCodexを作った。OpenAI社内では複数のチームが同時にコーディングの未来に取り組み、IDEやCLIといった異なる形態を試していた。Codexは2026年2月にデスクトップアプリをリリースし、Shipperはこれを素晴らしいものだと考えていると述べた。Codexは急速に成長したためChatGPTに統合され、その基盤になったという。彼の話では、小さなCodexチームは、彼が日間アクティブユーザー8億人と表現したアプリを、自分たちの実験のやり方があまりにうまくいったために引き継ぐことになった。

Shipperは、このアプローチがもたらすと彼が考える可能性について語って講演を締めくくった。それは、現在のプロダクトをスケールさせながら、「正気を失うことなく」次のバージョンのプロダクトを作ることだ。うまくいっているかどうかを見極める彼の基準は、新しいモデルのリリースにチームがどう反応するかである。体制が正しければ、そうした瞬間を恐れるのではなく、歓迎し、わくわくするようになるだろうと彼は語った。