AI 時代におけるエンジニアリングチームの管理方法とは

Fiona Fung は Anthropic の大会で 28 分間にわたり、AI 時代においてどのようにエンジニアリングチームをマネジメントすべきかについて語りました。

彼女がこれらのスライドを作成した時点では、Anthropic はまだ Routines 機能をリリースしていませんでした。

それから三週間後、Routines が稼働しました。これは Claude Code がクラウド上で計画通りに自動的にタスクを実行できる機能であり、ローカルでターミナルを常時開いておく必要はありません。彼女が実際に Code with Claude 2026 大会のステージに立った時には、スライドのいくつかはすでに時代遅れになっていました。

Fiona Fung は、Anthropic が運営する Claude Code と Cowork の二つの製品ラインにおけるエンジニアリングと製品の責任者です。彼女は以前、マイクロソフトで十二年間（Visual Studio からスタートし）勤務した後、メタ社に移り Facebook Marketplace や Instagram のエンジニアチームを率いました。そして 2025 年 9 月に Anthropic に合流しました。今回の講演は 30 分にも満たないもので、テーマは「AI 時代におけるエンジニアリングチームのマネジメント」というごく一般的な内容に聞こえますが、彼女が語ったのは Claude Code チームでこの一年間に経験した失敗や、打ち砕かれた既存のルール、そしてまだ解決していない現実的な課題のみです。抽象的な空論は一切含まれていません。

動画の元リンク：https://www.youtube.com/watch?v=igO8iyca2_g

要点速覧

• ソフトウェアエンジニアリングのボトルネックは、過去には「コードを書くのが遅い」ことでしたが、現在は検証、レビュー、異機能間の協力、そしてセキュリティへと移行しています。過去の各種プロセスは「コードを書くコストが高い」という前提に基づいて設計されていましたが、「コードを書くことがほぼ無料になった」現在では、プロセスをすべて再構築する必要があります。

• プロセスが自然に消滅することはめったになく、組織は SLA（サービスレベルアグリーメント）、規則、レビューを次々と積み重ねていきます。AI を用いてエンジニアリングチームを変革する第一歩とは、まさに古くなったプロセスを削除することを明確に許可することです。

• 技術的な議論のやり方が変わりました。過去には人々をホワイトボードのある部屋に集めてアーキテクチャ図を描かせましたが、現在は Claude に同時に三つの PR（プルリクエスト）を作成させ、API の実際の影響範囲と照らし合わせながらコードについて議論します。

• Claude Code チームでは、すべての PR に Claude が参加しています。「このコードを誰が書いたのか？」という問いは、すでに意味を失いつつあります。

• マネージャーは必ず現場の IC（個人貢献者）として経験を積む必要があります。Fiona は採用においてこの点を強く主張し、採用を担当する同僚たちは当初「今どき、マネージャーがわざわざコードを書く立場に戻ろうとするのか」と理解できませんでした。彼女の返答は明快でした。「そう思わないなら、早めに別れるのがお互いのためです」。

• 組織はできるだけフラットにし、すべてのチームが一つのミッション（目標）を共有します。理由は単純です：目標が変わった際、階層が多ければ多いほどアライメントのロスが生じやすくなるため、フラットであることが柔軟性を意味します。

• コードこそが唯一の「ソース・オブ・トゥルース」（真実の情報源）であり、設計ドキュメントではありません。もし spec（仕様書）を維持したいのであれば、それをコードリポジトリに提出し、Claude にコードとドキュメントの一貫性を検証させます。

• 効果を測る指標は三つです：新人が業務に慣れるまでの時間、PR のライフサイクル、そして Claude が支援して提出されたコードの割合。しかし彼女は警告します、「AI によって書かれたコードの量」だけを執拗に追うのは虚栄的な指標であり、重要なのは製品品質と信頼性です。

【1】過去二十年で業界は二度再構築された

講演の冒頭、フィオナはタイムラインを 2000 年代初頭に遡りました。当時彼女はマイクロソフトで Visual Studio 2005——世界で主流な開発ツールの一つ——に取り組んでいました。その頃はソフトウェアはまだ CD で配布され（さらに前にはフロッピーディスク）、各バージョンに確固たるリリースのラインが存在しました。なぜなら、ソフトウェアは生産ラインに送られてディスクを刻印し、箱詰めされ、店舗へ並べられる必要があったからです。

その後インターネットが到来し、配布方法は CD からオンライン配信へと変化し、エンジニアリングのリズムも根底から覆されました。今や AI の時代ですが、今回は単なるリリースリズムの変化ではなく、「コードを書く」という行為そのものが変容しています。

**

過去に通用した古い経験則は、現在では必ずしも機能しません。

（"What served you prior may not serve you any longer."）

彼女は講演の中でこの言葉を繰り返し強調しました。長年にわたりエンジニアリングのリズムは、「コードを書くのは高価だ」「テストを書くのは高価だ」「リファクタリングするのは高価だ」という仮定の上に構築されてきました。ウォーターフォールからアジャイルまで、あらゆる手法はこの希少な資源を配分するためのものでした。

昨年彼女はなおも「バイブコーディング（vibe coding：感覚に頼るプログラミング。OpenAI の共同創設者であるアンドレイ・カルパティが 2025 年初頭に提唱した概念）について不満を漏らしていました。「なぜ至る所で定数値が使われているのか、エンジニアリングのプラクティスが良くない」と。しかし一年後、モデルはあまりにも多くのことができるようになりました。この突破は単なる「速度向上」の範疇を超え、全体のスループットが直接一桁分も飛躍したものです。

【2】コーディングがボトルネックでなくなった今、新たな卡点はどこに現れるのか

Claude Code チームの現在のボトルネックは、検証（validation）、レビュー（review）、異機能間の協力、セキュリティです。

コード量が大幅に増加した今、彼女が他のエンジニアリング責任者から最も頻繁に問われるのは「人間がこの量のコードをどうやってレビューできるのか？」という質問です。彼女はまた、メンテナンスコストの算出方法についても知りたいと考えています。生成されたコードのコストはほぼゼロですが、メンテナンスコストがゼロになるわけではありません。

注：** 講演で言及された「Claude Code を使って Claude Code を構築する」というのは、Anthropic 社レベルでの公的な実践です。ボリス・チェルニーはこれまでに複数のインタビューで、自身が Claude Code を用いて非技術者向けのデスクトップエージェントである Cowork を 10 日間で構築したと語っています。これは修辞ではなく、エンジニアリングの現実です。

彼女は「静かに機能しなくなっている」旧来のプロセスの一覧を提示しました。半年に及ぶ製品ロードマップ、煩雑なスケジュール会議、コード所有権の明確化、長時間にわたるコードレビュー会議、伝統的なチーム構造、ナレッジベースの共有、そして新人向けの長いオンボーディング（onboarding：入社研修）です。これらすべてが当初「開発コストが高すぎる」という現実によって強制的に作り出された歴史的産物なのです。

**

プロセスは自然に消滅することはほとんどありません。私たちは習慣的に、新しいプロセスを次々と積み重ねていきます。

（「Rarely do processes kill themselves, we tend to just layer more and more and more processes on.」）

彼女は痛烈な例を挙げました：かつてあるチームでは、SLA（サービスレベルアグリーメント）の数が多すぎて、エンジニアがどの対応を優先すべきか理解するために大掛かりな表を作成して強制的に並べ替える必要があったと。彼女はこの過度な積み重ねを整理するべきだと以前から感じていましたが、実際に手を動かす決意をしたのは Anthropic に入社してからでした。

【3】何もしないこと：6 ヶ月ロードマップ、設計ドキュメント、製品レビュー

Claude Code に加入したばかりの頃、彼女は「6 ヶ月ロードマップは不要なのですか？」と尋ねていました。

作成したドキュメントも、最初の 3 ヶ月は使えていたものの、新年を迎えた頃にはすでに半分ほどが変更されていました。現在彼女は「jit planning（即時計画）」という言葉を使っています。これはプログラミングの概念である just-in-time コンパイルに由来しており、「必要になった時点で何をするか」を意味します。プロトタイプのコストがほぼゼロに近づいているため、「事前計画」というレバレッジはもはや機能しなくなっているからです。

設計ドキュメントも大幅に削減されました。Claude Code チームのデフォルトの議論媒体は「まずドキュメントを書くこと」から「まず PR（プルリクエスト）を送ること」へと変わり、アイデアがあればすぐに実装してしまいます。製品レビュー会も同様に行われる回数が減っています。製品形態が変化しすぎるため、モックアップをレビューするよりも、内部バージョンを Anthropic の全社員に展開し（彼女はこれを ant-fooding と呼んでいます。社名 Anthropic に「ant」が含まれているため）、その後外部ユーザーへ公開して実際の使い方を聞く方が効果的だからです。

【4】もっと行うこと：検証、品質保証のソース側へのシフト

彼女はチームに対して検証への投資を倍増させるよう求め、shift left（左移）と呼んでいます。従来のソフトウェアパイプラインでは「左」がソース側、「右」がデリバリー側ですが、品質保証をデリバリーに近い手動テストから、ソースに近い自動化へと移行させます。

なぜこのことが重要になっているのか？それは役割の境界線が曖昧になりつつあるからです。彼女のデザイナーの同僚も現在コードを提出しています。Fiona はついでに、ある小さな不安について語りました：彼女がある求人関連のバグを修正した翌日、Boris のメッセージストリームをざっと見たところ、誰かがチーム内で新しいバグを報告するために彼を@ しているのを発見しました。彼女は当時の気持ちを「心臓が半拍分止まったようだった」と表現し、自分が引き起こした問題ではないかと恐れました。

誰も自分のコミットによってサービスをダウンさせたくありません。この高スループットな環境下では、これは非常に現実的な心理的負担です。従来の手動 QA では、これほど高いコード出力率に対応することはできません。そのため、品質保証はより早期に自動化メカニズムに依存する必要があります。

【5】技術議論の方法の変化：ホワイトボードから 3 つの PR へ

Claude Code チームに参加したばかりの頃、彼女はリファクタリングを行い、ついでにコードベースを熟悉しようと考えていました。Boris と技術的な方針で意見が対立し、彼女はその瞬間も慣習的に肩を叩いて「さあ、ホワイトボードルームに行こう」と言おうとしました。

次の瞬間、彼女はすぐに気づきました。実際には Claude に同時に 3 つのバージョンの PR を作成させ、完全なコード実装を直接比較させることができると。さらに、すべての呼び出し元への影響も抽出できます。ホワイトボードではこれほど直感的な全体像を描くことはできませんが、コードなら可能です。

コード記述が容易になるにつれ、果てしない議論は極めて高価なものとなります。

（"When building is cheap, arguing is expensive."）

この判断を提示する際、彼女の口調は特に厳粛でした。彼女は直ちに聴衆に警告しました。生成コストがゼロに近づいているからこそ、チーム文化と底线の合意形成がいっそう重要になるのだと。

決して「最後の commit を行った者が勝つ」という状態に陥ってはなりません。例えば、誰かが深夜 3 時まで熬夜してこっそりコードを提出したり、リリース直前にタイマーを設定して駆け込みで操作を行ったりすることは絶対に許されません。むしろコードの価値が低下しているからこそ、チーム内の横方向での整合性を保つためには明確な底线が必要なのです。

【6】コードレビュー：Claude に任せるもの、人間が残すもの

Cat Wu は大会の午前中の基調講演で、Claude による PR（Pull Request）の自動レビュー能力について述べていました。Fiona の視点はそのさらに先を行くもので、具体的に「何を Claude に任せ、何を人間に残すか」を論じています。

注：** Cat Wu は Claude Code の製品責任者であり、Boris Cherny と共に Claude Code の製品方向性を主導しています。

Claude に任せるべきもの：コードスタイルのチェック、lint による重複除去、コードレビューへの回答、一般的なバグの検出、そしてユニットテストの補完です。彼女は現在、Claude が PR（Pull Request）を「管理」することに非常に優れており、通常は人間が引き継ぐ前に大部分の汚い作業や重労働を完了していると言います。

依然として人間の介入が必要なものは 3 つのカテゴリーに分類されます。第一に法務およびコンプライアンス（法令遵守）レベルでの審査です。リスクの範囲に関わるためです。第二にセキュリティ上の敏感なコードの境界確認です。バグ（脆弱性）が発生した際の代償が高すぎるためです。第三に製品体験に対するセンス（直感）と品味です。これも現在の大規模言語モデルが乗り越えるのが非常に難しい障壁の一つです。

第三のカテゴリーについて、彼女は軽妙な例を挙げました。彼女には小さな趣味があり、それは節句に合わせて Claude のターミナルのイメージを飾ることです。クリスマスの際は、Claude を雪だるまに変身させようとして ASCII アート（文字絵）で描かせました。その結果をデザイナーの同僚に意見を求めたところ、相手は一言、「あなたはそれを Mr. Peanut として描いてしまった」と返しました。

**

注：** Mr. Peanut はアメリカの有名スナックブランド「Planters」のマスコットキャラクターで、礼帽と片眼鏡を着用しており、雪だるまと輪郭が似ているためです。

彼女は最終的にシンプルに「氷のような青色＋雪花」という案を採用しました。この物語を通じて彼女は製品センス（直感）の重要性を説いています：抽象的な判断は自動化するのが極めて困難だからです。

【7】コードの境界線は日渐模糊となり、役割分担も再編成されている

Claude Code チームでは、ほぼすべての PR に Claude が参加しています。「このコードは誰が書いたのか？」という問いは、すでに荒唐無稽でさえあり、意味をなさなくなっています。

Fiona は、こうした表面的な事象にこだわらず、本当に理解したいことは何かを深く掘り下げるよう提案します：誰の修正がバグを引き起こしたのか？顧客に対して技術的な詳細を説明できる十分な背景知識を持つのは誰か？このコードモジュールの来歴と経緯について最もよく知っているのは誰か。もし後者のような細分化された質問をするのであれば、往々にしてそれらに答えるためのより良い自動化の道筋が見つかるはずです。例えば彼女は以前、毎朝コーヒーを淹れながら Claude Code を顧客フィードバックチャンネルに接続し、情報の要約と集計を実行するという習慣を持っていました。しかし現在ではこの作業は Routines 自動化タスクに組み込まれており、手動でコマンドを入力する手間さえ省かれています。

注： Routines は Claude Code の機能の一つで、時間指定やトリガーに基づいた自動化タスクを設定できるものです。Fiona がこの講演の準備を始めた一か月前にようやくこの機能がリリースされ、彼女の自身のスライド内容さえも更新を余儀なくされました。

このような役割の境界線が曖昧になる現象は双方向的に起こっています。一方では非技術出身の人々も袖をまくり上げてコードを書くようになり、Claude Code チームの PM（プロダクトマネージャー）が実際に PR（プルリクエスト）を提出しています。他方では、エンジニアが自分の専門分野という狭い領域から飛び出し、従来は他の職種に属していた業務を奪い合うようになります。Fiona は自らの例を挙げて説明しました：彼女は以前 Claude Code のユーザーアンケートを改善したいと考えましたが、コンテンツデザイナーが見つかりませんでした。過去であれば、コンテンツチームのメンバーを巻き込んで文章の細部まで何度も推敲する必要があったでしょうが、現在は彼女自身が Claude を文案のパートナーとして直接使用しています。彼女は典型的なエンジニアとして自嘲し、「文章を簡潔にまとめることについては全く不得意だ」と述べています。

採用において、Claude Code チームが特に重視するのは二つのタイプの人材です。一つは製品感覚を持つクリエイティブなビルダー：好奇心が強く、問題を見ると即座に製品化して解決しようとし、体験を繰り返し磨き上げる人々です。もう一つは深遠なシステム専門家：チームが Claude Code Remote を構築する際に、分散システムの経験を持つ人材が不足していることが判明しました。彼女がもはや重視しなくなったのは、純粋なコーディングの生産量（スループット）です。モデルがこの部分をすでに均質化してしまったからです。

【8】組織形態：できる限りフラットに、マネージャーは IC からスタートする

Anthropic が彼女を Claude Code チームに招聘した際、相手側はデフォルトで「IC（インディビジュアル・コントリビューター）10 人にマネージャー 1 人という比率で、さらにその下に階層構造を設ける」という採用方針を持っていました。しかし Fiona はこれを受け入れませんでした。

彼女が目指したのは、できる限りフラットな組織です。Claude Code と Cowork の二つのラインはチームのミッション（目的）のみを共有し、各グループが個別にミッションを設定することを禁じます。その理由は非常に現実的なものです：ミッションが変われば、多層的な階層構造では下位へのアライメントに多くの時間を要するため、フラットであることがすなわち柔軟性を意味します。

彼女はさらに一つの原則を堅持しました：Claude Code チームのすべてのマネージャーは、まず IC（インディビジュアル・コントリビューター、現場のエンジニア）として働くことです。

採用担当者の最初の反応は「あなたは狂っている」というものでした。つまり、マネージャーが自ら IC として働くことを望む人はいないというのです。

私は Claude Code チームのすべてのマネージャーに IC（Individual Contributor）としての経験からスタートすることを求めています。これが私のチームに対する期待であり、これに賛同できない場合は早期に別々の道を進むべきです。

（「これは Claude Code チームにおけるドッグフーディングの本質であり、私が求めるものです。もし興味がない方がいるなら、早めに別れるのが私たちにとって良いことです。」）

この方針は彼女自身にも適用されます。彼女がコードを本番環境にプッシュしたのは 2017 年までで、Anthropic に加入してから再びコーディングを始めたのです。彼女は Meta に在籍していた頃も年に一度は PR を提出しようとしていましたが、社内ツールの進化があまりにも速く、一年かけて覚えたコマンドが翌年には使えなくなってしまうのだそうです。

今では git コマンドさえも忘れてしまい、すべて Claude にお任せしています。

（「最近では git コマンドすら覚えていません。すべて Claude に頼んで対応してもらっています。」）

【9】ドキュメントから退き、コードを「唯一の事実源」とする

Claude Code チームでは現在、コードを最終的な source of truth（唯一の事実源）と位置付けています。例えば Fiona は技術的な顧客対応に対してどのように答えているでしょうか？彼女はデスクトップ版 Claude Code を起動し、ローカルの repo にマウントさせた上で、大規模言語モデルが直接コードからロジックを検索して回答するようにしています。この手法は、ソフトウェア業界に長年根付いていた「開発ドキュメントとコードの同期が取れていない」という千年の課題を完全に解決しました。

ただし、彼女はあえて補足しています。この経験則が万能であるわけではありません。もし貴社のチームで業務上、完璧な要件定義ドキュメントの作成が必須であれば、当然のことながら spec（仕様書）もコードリポジトリ内に格納し、Claude に最終的に生成されたコードとドキュメント記述との整合性をクロスチェックさせるべきです。

これらの変化を推進する際、Fiona は「統一すべき事項」と「各チームに委ねる事項」の 2 レベルで区別しました。統一すべき核心的な原則は以下の通りです：すべてのチームメンバー（包括的なパートナーや Cowork も含む）が Claude Code を使用する；自動化可能な業務はすべて Claude に任せる（社内ではこれを「claudify everything」と呼んでいます）；すでに人間に役立っていない旧来のプロセスを廃止することを明確に許可する。

最後の原則について、彼女は具体的な例を挙げました。Claude Code チームはかつてスタンドアップミーティングを行っていましたが、チームが大きくなるにつれて共有スプレッドシートへの週次進捗報告に変更しました。ある日、彼女はこの大規模な表を見て退屈を感じました：なぜなら、必要な情報はすべて Claude が読み取れる場所に存在しているからです。実際には、Claude に要約スクリプトを書いておき、誰でもいつでも他のメンバーのステータスサマリーを取得できるようにすれば、誰かに進捗記入を催促するよりもはるかに効率的です。

ただし、各チームに任せる範囲も非常に明確に定義されています：バグの triage（分診）メカニズム、スケジュールのペース、当直担当者の配置方法、あるいはどのワークフローを優先的に Claude 化すべきかなど、これらすべてを各チームが自らの判断で決定することを認めています。

【10】3 つの観測可能な指標と、1 つの警告

具体的な数字は明かさなかったが、3 つの方向性を指摘した。

新人が戦力として活躍するまでの期間（オンボーディング期間）が大幅に短縮された。エンジニア、デザイナー、PM が新チームで有効な成果を生み出す速度が明らかに向上した。

PR（プルリクエスト）に必要なサイクル時間が劇的に短くなった。彼女はついでに、これは掘り下げる価値のある指標だと付け加えた。なぜなら、その変化は単にチームが AI ツールを受け入れているかどうかだけでなく、場合によっては下流のインフラ基盤の弱点を露呈するからだ。例えば、CI（継続的インテグレーション）パイプラインや製品インフラ環境が、エンジニアの爆発的に増加したコミットレートに対応しきれていないケースなどだ。

Claude が関与するコミットの割合が高まっている。Claude Code チームの雰囲気では、Claude を伴わないコミットは例外であり、Claude を伴ったコミットこそがデフォルトの標準的な運用となっている：

私は約 4 ヶ月間、Claude の支援を伴わないコミットを見たことがない。

（"I don't think I've seen a non-Cloud assisted commit probably in the last four months or so."）

しかし、指標に関するこのセクションでは明確に警告も加えている。「コードのどの程度が AI によって生成されたか」だけをみてはいけない。各社のプレスリリースではこの割合がどんどん高まっているように聞こえるが、スループットそのものが目的ではない。結局のところ、何を解決しようとしているのか、製品の品質と信頼性が守られているかを振り返る必要がある。

【11】彼女自身もまだ答えを出せていない 3 つのこと

Fiona は講演の最後に、自分にも答えが出ていない 3 つの問題があると認めた。

第一に、エンジニアがプラットフォームを跨いで流動的に動くようになった今、従来の「iOS チーム＋Android チーム」という編成にはもはや意味があるのか。

第二に、自動化されたコードレビューをどこまで推進すべきか。「信頼するが検証せよ（trust but verify）」の境界線は、モデルの進化に伴って再び移動する可能性がある。彼女は当日の早い段階で行われたモデル能力に関する講演に触れ、レビューを Claude に委譲する割合を決めるのは一度きりの決定ではないと指摘した。

第三に、役割の境界が曖昧になった今、どうすれば全員が同じように生産感を持てるか。エンジニアがコンテンツ作成を行い、PM がコードを書き、デザイナーがバグ修正をするようになれば、従来の成果物の帰属は曖昧になる。公平性を設計する新たな課題が生じている。

彼女が聴衆に残した最後のアドバイスは、非常に素朴で直接的なものだった。

極めて手間がかかり、特に煩雑なワークフローを一つ選び出し、それが今なお誰のために機能しているのかを再考してみることだ。

（"Pick your noisiest workflow … is it still really serving, what's the purpose of there."）

彼女は自身の経験談を逆の例として挙げた。以前あるチームを率いていた際、週に一度必ず行われる定例会議があった。50 人以上が大きな部屋に詰めかけられていた。しかし Fiona がよく観察すると、名前を呼ばれて立ち上がって報告する人たちが一瞬だけ顔を上げるのを除き、他の全員が一斉にキーボードを叩いて低头していることに気づいた。その後、彼女はただ一言、「なぜ私たちは今なおこの意味のない会議を開いているのか」と問いただし、その瞬間に全会一致で解散が決まった。

動画の元リンク：https://www.youtube.com/watch?v=igO8iyca2_g