全社員4,000人にCowork、CTOは開発「現役復帰」:DoorDash CTOが語るAI時代の組織論
Claude公式の対談シリーズ「Office Hours with Boris Cherny」から、DoorDash共同創業者兼CTOのAndy Fang氏の回を紹介します。DoorDashではClaude Codeが全社で稼働し、4,000人の全社員がCoworkを利用。そしてFang氏自身、スタンフォードの寮で創業コードを書いて以来、久しぶりに本番コードを出荷する「現役復帰」を果たしたといいます。Claude Code生みの親のBoris Cherny氏との対談は、ツールの話を超えて、プロセス・組織・採用まで踏み込む濃い内容です。要点を読み解きます。
CTOの現役復帰と、「数ヶ月後にもう一度試す」の価値
Fang氏は2013年、スタンフォードの寮で自らすべてのコードを書いていましたが、会社の成長とともにコーディングから離れていました。復帰のきっかけがClaude Code。今はターミナル中心に、手でコードを書かないことを自分に課し、複数リポジトリでgit worktreeを使って複数セッションを並行稼働させているそうです。
印象的なのが最初の体験談です。当初「誰にも助けを求めず本番機能を出荷する」と決めて挑戦したものの、エージェントにローカル環境の設定を理解させられず失敗。ところが2026年初頭に同じことを試したら、そのまま動いた——今では5つの言語で本番に出荷しているとのこと。Cherny氏の指摘も本質的です。
LLM以前は「同じアイデアを繰り返し試す」のは学習しない悪手だったが、今は新しいモデルで同じアイデアを試すと、突然うまくいくことがある。Fang氏はこれを組織論に翻訳します——エンジニアは自分が作った動くものへの愛着を捨てる訓練(unlearn)が必要。モデルの能力が変わるたび、セットアップも構築中のエージェントも再想像すべきだ、と。
リーダーへの宿題:「全エンジニアリングマネージャーが本番コードを出荷せよ」
DoorDashの展開で目を引くのが、リーダー自身に課された目標です。すべてのエンジニアリングマネージャーが、プロトタイプではなく、DoorDashの全プロセスを通して本番コードをマージすること。モデルの能力が体感できるだけでなく、「チームのエンジニアを遅くしているボトルネックはどこか」が自分の目で見える、という一石二鳥の設計です。
導入方針も明快でした。2025年にClaude Codeを導入した際、IT・セキュリティと組んでAIツール専用の迅速な調達・審査プロセスを用意。トークン予算は最初から絞らず、探索を最適化する方針を取りました。Cherny氏が他社リーダーによく贈る助言とも一致します——「全員にトークンを配れ。イノベーションが誰から出てくるかは予測できない」。Fang氏も、現状のやり方で生産的な人ほど最初は抵抗し、意外な人が飛びつく、と同意しています。
スケールの現在地:Flex、Swarm的な夜間実行、そして新しい問題
現在、Claude Codeの利用は組織全体に広がり、コーディング速度は採用率と相関して向上。インフラ投資として、社内プラットフォーム「Flex」を構築しました——DoorDashクラウド内のVM上で、セキュリティ承認済みのClaudeセッションをクラウドで起動できる基盤で、Claude Agent SDKで構築したAIコードレビューエージェントもこの上で動いています。
一方で、スループット向上は新しい問題も生みます。マージ待ちへの不満、再設計が必要になったCI/CD、AIレビューに頼って人間がラバースタンプ(形式承認)しがちになる問題、業界全体で増えるセキュリティ関連の論点——Fang氏はこれを「いたちごっこ」と表現し、本番前にセキュリティ問題を捕まえる側にもAIを使う投資を進めていると語ります。
「3〜5倍速」の号令と、そこから得た学び
全社に投げかけられたチャレンジが強烈です——プロジェクトを3〜5分の1の時間で完了せよ。昨年12週間かかった案件なら、最大4週間で。実例も出ています。歴史的にはエンジニア4人×1四半期が必要だった大規模コード移行を、1人が3週間で完了。大型プロダクトのローンチ時期も半分以下に前倒しされました。
うまくいった要因として挙がるのが3つ。①小さいチーム(3〜5人)は調整コストが消えて加速する。②コードベースを「エージェントフレンドリー」にする先行投資——あるテックリードは、こだわりのアーキテクチャ原則50個超をリポジトリ内のMarkdownに書き出し、エージェントが常に参照できるようにした。③スキルの標準化——モバイルチームはシミュレータ起動やテストワークフローを呼び出し可能なスキル化し、面倒な手作業を背景処理に変えた。
一方で最大の障害は技術ではありませんでした。ユーザー向け機能では、プロダクトレビュー・シップレビュー・デザインレビューといった「良い理由があって作られたプロセス」が、今や最大の摩擦点になっている。Fang氏の結論はこうです——AIの速度を活かすのはエンジニアリングの問題ではなく、全社の問題。部門横断のリーダーが自分たちの働き方を変えなければ、この速度は解放されない。
デザイナーが直接コードでピクセルパーフェクトまで仕上げる、iOSの専門家は少数のゲートキーパーに絞って残りはコードベースを自由に動くジェネラリストにする——「自己完結できるチームほど速い」が貫かれています。
ROIの考え方と「AIチャンピオン」
ROIについての整理も実務的です。エンジニアリングはコードスループット(完璧ではなくゲーム可能だが方向としては正しい)と納期短縮で測れる。一方ナレッジワークはまだ探索期で、2つのレンズで見ている——①全員のベースラインを上げる(誰もがやる作業の時間削減。全員が10%生産的になるだけで、この規模の会社では巨大)②部門ごとのワークフロー自動化(数万の加盟店への営業アウトリーチのような、部門を根本から効率化する特定業務。こちらのほうがインパクトは大きいかもしれない)。そして究極の成功指標は、顧客が価値をより速く受け取ること。
非技術部門への広げ方は「AIチャンピオン」方式です。営業・マーケ・オペレーション・サポートの各ドメインで、自然発生的に熱中している人を見つけて公式にチャンピオンと呼び、その領域のペインポイントを聞き、エージェントでの効率化か、同僚が使える共有スキルの整備を任せる。見つけ方は簡単だといいます——一番ハマっている人は楽しんでいて、楽しい人は黙っていられないから。
リーダーと新卒への助言
締めの助言も要点が明確です。リーダーへ:自分でAIを使うこと。チームに勧める説得力のためだけでなく、働き方の激変がエンジニアにもたらす不安への共感のため——コードという職人技に自分を重ねてきた人にとって、これはある種のアイデンティティの危機であり、リーダーはそれを理解すべきだと。
そしてもうひとつは書かれた成果物(written artifacts)の共有——成功例だけでなく、無駄にトークンを溶かした失敗例も含めて。文書化は学びを組織にスケールさせる最良の方法であり、エージェント自身も読んで学べるという副産物まで付いてきます。新卒へ:好奇心を保ち、ツールで遊び続けること。この働き方のパラダイムで育った世代が、想像しなかった活用法で会社を驚かせることを期待している、と。
まとめ
この対談から持ち帰るべきは、「速いエンジニアリング」が終着点ではなく起点だという視点です。コーディングが速くなった瞬間、ボトルネックはレビューへ、CI/CDへ、そして部門横断のプロセスへと移動していく。
だからリーダー自身が本番コードを出荷して摩擦を体感し、書かれた成果物で学びを流通させ、プロセスそのものを再設計する。League事例が「規制産業での転換」だとすれば、DoorDashは「スケール企業でのプロセス再発明」の教科書です。エンジニアリング組織のリーダーはもちろん、「AIで速くなったのに全体は速くなっていない」と感じているすべてのチームに刺さる内容だと思います。
INNOOV株式会社について
この記事は、AtlassianやIntercomなどのSaaS導入支援と、AIを活用した業務プロセス改善を行うINNOOV株式会社がお届けしました。「自社でもこんな仕組みを作ってみたい」「ツール導入を相談したい」という方は、お気軽にお問い合わせください。