>
她做这套幻灯片时，Anthropic 还没有推出 Routines 功能。
三周后，Routines 上线了。这是一个让 Claude Code 在云端按计划自动跑任务的功能，不需要在本地一直开着终端。等到她真正站上 Code with Claude 2026 大会的讲台时，幻灯片里好几张就已经过时了。
Fiona Fung 是 Anthropic 旗下 Claude Code 和 Cowork 两条产品线的工程与产品负责人。她之前在微软干了十二年（从 Visual Studio 做起），后来去 Meta 带过 Facebook Marketplace 和 Instagram 的工程团队，在 2025 年 9 月加入了 Anthropic。这次演讲不到三十分钟，主题听起来很普通："AI 时代怎么管一个工程团队"，但她讲的全是这一年来在 Claude Code 团队踩过的坑、砸碎的旧规则，以及还没想明白的现实挑战，一点也不讲抽象的空话。
视频原链接：https://www.youtube.com/watch?v=igO8iyca2_g
要点速览
【1】二十年里，行业被重塑了两次
演讲一开始，Fiona 把时间线拉回了 2000 年代初。她当时在微软做 Visual Studio 2005——全球主流的开发工具之一。那会儿软件还是靠 CD 发行的（再早点是软盘）。因为软件要送到流水线上刻盘、装盒、铺货到店里，每个版本都有雷打不动的发布主线。
后来互联网来了，把发行方式从 CD 变成了在线分发，工程节奏随之被颠覆。现在轮到 AI，但这次变的不只是发行节奏，而是"写代码"这件事本身。
过去管用的老经验，现在未必行得通了。
（"What served you prior may not serve you any longer."）
她在演讲里反复回到这一句。多年来工程节奏围绕一个假设搭建：写代码贵、写测试贵、重构贵。从瀑布到敏捷，每一种方法论都是在分配这块稀缺资源。
去年她还在抱怨 vibe coding（凭感觉编程，由 OpenAI 联合创始人 Andrej Karpathy 在 2025 年初提出）："为什么到处用常量，工程实践不好。"一年之后，模型变得能干太多。这种突破已经远超单纯的"提速"范畴，而是整体的吞吐量直接跃升了一个数量级。
【2】当编码不再是瓶颈，新的卡点出现在哪里
Claude Code 团队现在的瓶颈是验证、评审、跨职能协作、安全。
代码量提升后，她被其他工程负责人问得最多的问题是："这些代码人怎么审得过来？"她也想知道维护成本怎么算。生成代码的成本几乎为零，但维护成本不会跟着归零。
她列出了一份"正在悄然失效"的旧流程清单：长达半年的产品路线图、繁琐的排期会议、对代码的所有权划分、马拉松式的代码评审会议、按部就班的传统团队结构、知识库分享、以及漫长的新人入职培训（onboarding）。这些统统都是因为当初"开发成本太高"而被现实倒逼出来的历史产物。
流程极少会自然消亡。我们习惯的做法是不断地往上叠加新流程。
（"Rarely do processes kill themselves, we tend to just layer more and more and more processes on."）
她举了个痛点例子：之前在某个团队，SLA（服务级承诺）多到需要拉个大表格强制排序，工程师才能弄清楚哪条需要优先响应。她早就觉得这种过度堆砌该清理了，但真正下决心动手，还是到了 Anthropic 之后。
【3】少做什么：六个月路线图、设计文档、产品评审
刚加入 Claude Code 时她还在问："不需要做六个月路线图吗？"
写出来了，前三个月还能用，过完新年再看，已经变了大半。她现在用一个词：jit planning（即时规划），借编程概念里的 just-in-time 编译，意思是什么时候需要再做什么，因为原型成本已经趋零，"提前规划"的杠杆消失了。
设计文档也大量减少。Claude Code 团队的默认讨论媒介从"先写一份 doc"换成了"先发一个 PR"，有想法直接做出来。产品评审会同样开得少，因为产品形态变化太快，与其评审 mock，不如把内部版本推给 Anthropic 全员（她管这个叫 ant-fooding，因为公司名 Anthropic 含"ant"），再推给外部用户，听他们怎么用。
【4】多做什么：验证，把质量保障往源头推
她希望团队在验证上加倍投入，叫 shift left（左移）。传统软件流水线左是源头右是交付，把质量保障从靠近交付端的人工测试，往靠近源头的自动化推。
为什么这件事变重要？因为角色边界正在模糊。她的设计师同事现在也在提交代码。Fiona 顺带讲了一个真实的小焦虑：她有次修了个跟求职简历相关的 bug，第二天扫了一眼 Boris 的消息流，看到有人在群里 @ 他报新 bug。她形容自己当时的感触是"心跳都漏了半拍"，生怕是自己捅的娄子。
每个人都不希望因为自己的提交把服务搞挂。在这个高吞吐量的环境下，这是非常真实的心理负担。传统的人工 QA 根本接不住这么高的代码产出率，所以质量保障必须更早地依赖自动化机制。
【5】技术辩论的方式变了：从白板到三个 PR
刚加入 Claude Code 团队时她想做一次重构，借机熟悉代码库。和 Boris 在技术方案上有分歧，她差点习惯性地拍肩膀说"走，去白板房画一下"。
下一秒她马上意识到，其实完全可以让 Claude 同时搓出三个版本的 PR，直接对比完整的代码实现，甚至能拉出对所有调用方的影响。白板上可画不出这么直观的全局视角，但代码可以。
当写代码变得轻而易举，无休止的争论就显得极其昂贵。
（"When building is cheap, arguing is expensive."）
抛出这个判断时，她的语气尤为严肃。她随即提醒听众：正因为生成代码的成本趋于零，团队文化和底线共识反而变得越发关键。
决不能沦为"谁最后一个 commit 谁赢"。比如有人熬夜到凌晨三点偷偷交代码，或者设个定时任务抢在上线前压哨操作，这绝对不行。恰恰是因为代码不值钱了，团队横向对齐反而更需要明确的底线。
【6】代码评审：Claude 接什么，人保留什么
Cat Wu 在大会上午的 keynote 已经讲了 Claude 自动评审 PR 的能力。Fiona 这里的视角更具体：什么交给 Claude，什么继续留给人。
交给 Claude 去做的： 风格检查、lint 去重、回应代码评审意见、抓常规 bug，以及补全单元测试。她说 Claude 现在非常擅长"打理"PR，通常在人工接手之前就把大部分脏活累活干完了。
依然需要人工介入的有三类：
第三类她讲了个轻松的例子。她有个小爱好：按节日装饰 Claude 的终端形象。圣诞节那次她想把 Claude 变成雪人，让 Claude 用 ASCII 字符画。她把结果发给设计师同事征求意见，对方一句话："你把它画成了 Mr. Peanut。"
她最终采用了简单方案：冰蓝色 + 雪花。这个故事她拿来说明产品 sense 的意义：抽象判断很难自动化。
【7】代码边界日渐模糊，角色分工也在重新洗牌
在 Claude Code 团队，几乎所有的 PR 都有 Claude 参与。"这段代码到底是谁写的？"这个问题正在变得荒诞甚至没有意义。
Fiona 建议不要纠结于这种表象，而是深挖你真正想搞懂的是什么：是谁的修改引爆了 bug？谁有足够的背景上下文去跟客户解释技术细节？谁对这块代码模块的来龙去脉更清楚？如果你问的是后面细分的这几个问题，就会发现往往有更好的自动化路径来回答。比如她原来有个习惯：每天早上泡一杯咖啡，用 Claude Code 对接客户反馈频道去跑一遍信息汇总摘要；现在这个动作已经被编排进了 Routines 自动化任务里，连手动敲命令都省了。
这种角色的模糊化是双向发生的。一面是非技术出身的人员也开始卷起袖子写代码，Claude Code 团队里的 PM 就在实打实地提交 PR。另一面则是让工程师跳出自己的一亩三分地，去抢传统上属于其他岗位的活儿。Fiona 拿自己举了个例子：她原本想优化一下 Claude Code 的用户问卷调查，又找不到内容设计师。过去她可能要拉着内容团队的人反复抠文案字眼，现在她直接用 Claude 作为文案搭档。她自嘲作为一个典型的工程师，"在把文案写得精炼这件事情上可谓是一塌糊涂"。
在招聘上， Claude Code 团队重点看两类人：
她不再看重的是原始编码吞吐量，模型已经把这部分拉平了。
【8】组织形态：尽量扁平，经理从 IC 做起
Anthropic 招她进 Claude Code 时，对方默认按"10 个 IC 配 1 个经理，再向下嵌套"的结构来招人。Fiona 不要这种。
她想要的是尽量扁平。Claude Code 和 Cowork 两条线只共用一个团队 mission，不让每个小组各自定 mission。理由很实在：mission 一变，多层级要花很多时间向下对齐，扁平等于灵活。
她还坚持一条：Claude Code 团队里所有经理都要先做 IC（individual contributor，一线工程师）。
招聘官最初的反应是"你疯了"，意思是没有经理愿意先做 IC。
（"This is what dogfooding on the Claude Code team's about, this is what I expect and if someone's not interested it's better for us to do earlier separation."）
这一条对她自己也是。她的上一次 push 代码到生产环境是 2017 年，加入 Anthropic 之后才重新写起代码。她说自己在 Meta 时每年还试着提交一次 PR，但内部工具变得太快，一年学一个命令第二年就过期了。
（"Nowadays I don't even remember git commands, I just always ask Claude to help me out with all of that."）
【9】从文档退位，让代码成为"唯一事实来源"
Claude Code 团队现在把代码视作最终的 source of truth（唯一事实来源）。比如 Fiona 现在是怎么答复技术客诉的？她会直接启动桌面版 Claude Code，挂载本地 repo 后让大模型直接从代码找逻辑去回答。这种做法彻底干掉了软件行业的一个千年遗留问题：开发文档总是不和代码同步。
但她特意补充说明：这条经验并不是放之四海而皆准的。如果你们团队业务要求必须有完备的需求文档，那就顺理成章把 spec 也提到代码库里，让 Claude 交叉校验一下最后跑出来的代码跟文档写的是否吻合。
在推行这些变化时，Fiona 区分了"必须统一"和"交给小组"两层。
必须统一的几条核心准则：
最后一条她给了个具体例子。Claude Code 团队曾经搞过站会，团队变大后改成在共享表格里填周进度。某天她看着这张大表觉得索然无味：因为信息明明都在 Claude 能读到的地方，其实让 Claude 写个总结脚本丢在那里，任何人随时去拉一下其他人的状态摘要，这不比催人填表高到不知道哪里去了。
不过给小组自行拿捏的空间也非常清晰： 诸如 bug 的 triage（分诊）机制、排期的节奏、谁值班怎么值，乃至哪些工作流优先级较高需要率先上 Claude，统统放权让小组自己说了算。
【10】三个可观察的指标，和一个警告
她没透露具体数字，但点了三个方向：
（"I don't think I've seen a non-Cloud assisted commit probably in the last four months or so."）
但她在指标这一段明确加了警告：不要只看"代码有多少由 AI 生成"。各家公司新闻稿里这个比例越说越高，但吞吐量本身不是目的，要回头看你究竟在解决什么问题、产品质量和可靠性还守不守得住。
【11】她自己也没想清楚的三件事
Fiona 在演讲最后承认，有三个问题她还没答案：
总结
她给听众的最后建议其实非常朴素直接：
（"Pick your noisiest workflow … is it still really serving, what's the purpose of there."）
她拿自己的亲身经历当了反例。以前在带某个团队时有个雷打不动的周例会，五十多号人挤在一个大屋子里。但 Fiona 细看发现，除了被点到名字起来汇报状态的人会假装抬一下头，其他人全都不约而同在低头敲键盘。后来她只问了一句"我们到底图什么还在开这破会"，瞬间全票通过顺带原地解散了。
>
>
📸 流程图/示意图
>
彼女がこのスライドを作成した時点では、Anthropic はまだ Routines 機能をリリースしていませんでした。
3週間後、Routines がリリースされました。これは Claude Code がクラウド上で定期的に自動タスクを実行できる機能で、ローカルで端末を開きっぱなしにする必要はありません。そして彼女が実際に Code with Claude 2026 カンファレンスの舞台に立った時には、スライドの何枚かはすでに時代遅れになっていました。
Fiona Fung は Anthropic の Claude Code と Cowork の両プロダクトラインにおけるエンジニアリング＆プロダクト責任者です。彼女は以前、Microsoft で12年間勤務し（Visual Studio からスタート）、その後 Meta で Facebook Marketplace や Instagram のエンジニアリングチームを率い、2025年9月に Anthropic に参入しました。今回の講演は30分弱で、テーマはごく普通の「AI時代におけるエンジニアリングチームのマネジメント」ですが、彼女が語ったのは、この1年間に Claude Code チームで経験した数々の失敗や打ち砕かれた旧来のルール、そしてまだ答えの出ていない現実的な課題であり、抽象的な空論は一切ありません。
動画元リンク：https://www.youtube.com/watch?v=igO8iyca2_g
ポイント一覧
【1】20年の間に、業界は2度再構築された
講演の冒頭で、Fiona は2000年代初頭にまでタイムラインを遡りました。彼女は当時 Microsoft で Visual Studio 2005——世界の主要な開発ツールの1つ——を開発していました。当時、ソフトウェアは CD で配布されていました（さらに遡ればフロッピーディスクです）。ソフトウェアを製造ラインでディスクに焼き、箱詰めし、店舗に配送する必要があったため、各バージョンには絶対的なリリーススケジュールが存在しました。
その後インターネットが登場し、配布方法が CD からオンライン配信へと変わり、エンジニアリングのリズムは一変しました。今度は AI の番ですが、今回変わったのは配布リズムだけではなく、「コードを書く」という行為そのものです。
かつて有効だった経験則は、もはや通用しないかもしれません。
（"What served you prior may not serve you any longer."）
彼女は講演で繰り返しこの言葉に立ち返りました。長年にわたり、エンジニアリングのリズムはある前提の上に構築されてきました：コードを書くのは高コスト、テストを書くのは高コスト、リファクタリングは高コスト。ウォーターフォールからアジャイルまで、あらゆる方法論はこの希少なリソースをどのように配分するかという問題でした。
昨年、彼女はまだ vibe coding（感覚でプログラミングすること。OpenAI 共同創業者 Andrej Karpathy が2025年初頭に提唱）について不満を述べていました：「なぜ至る所で定数を使っているんだ、エンジニアリングプラクティスが良くない」。1年後、モデルは格段に有能になりました。このブレークスルーは単なる「高速化」の域をはるかに超え、全体的なスループットが直接1桁向上したことを意味します。
【2】コーディングがボトルネックではなくなったとき、新たな課題はどこに現れるか
Claude Code チームの現在のボトルネックは検証、レビュー、クロスファンクショナルな協働、セキュリティです。
コード量が増加した後、彼女が他のエンジニアリング責任者から最もよく聞かれた質問は：「このコードを人間がどうやってレビューしきれるのか？」というものでした。彼女自身もメンテナンスコストがどう算出されるのか知りたいと考えていました。コード生成のコストはほぼゼロですが、メンテナンスコストがゼロになるわけではありません。
彼女は「静かに機能しなくなっている」旧来のプロセスのリストを挙げました：半年先のプロダクトロードマップ、煩雑なスケジューリングミーティング、コードの所有権の細分化、マラソンのようなコードレビューミーティング、段階的な従来型チーム構造、ナレッジベースの共有、そして長大な新人オンボーディング。これらはすべて、かつて「開発コストが高すぎる」という現実によって生み出された歴史的産物です。
プロセスが自然に消滅することはほとんどありません。私たちは新しいプロセスをひたすら積み重ねていく習慣があります。
（"Rarely do processes kill themselves, we tend to just layer more and more and more processes on."）
彼女は痛烈な例を挙げました：以前のチームでは、SLA（サービスレベル契約）が多すぎて、大規模な表に強制的にソートをかけないと、エンジニアがどの SLA を優先的に対応すべきかわからない状態でした。彼女は以前からこの過剰な積み重ねを整理すべきだと感じていましたが、実際に決断して行動に移したのは Anthropic に来てからでした。
【3】減らすべきこと：6ヶ月ロードマップ、設計ドキュメント、プロダクトレビュー
Claude Code に加わったばかりの頃、彼女はまだ「6ヶ月のロードマップは必要ないの？」と尋ねていました。
作ってみると、最初の3ヶ月は使えましたが、新年を過ぎて見直すと、大半が変わっていました。彼女は今、jit planning（ジャストインタイム計画） という言葉を使っています。プログラミングの概念である just-in-time コンパイルから借用したもので、必要なときに必要なことを行うという意味です。プロトタイピングのコストがゼロに近づいている今、「事前計画」のレバレッジは消滅しました。
設計ドキュメントも大幅に削減されました。Claude Code チームのデフォルトの議論メディアは「まず doc を書く」から「まず 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."）
この判断を述べたとき、彼女の口調は特に厳しいものでした。彼女は聴衆にこう注意を促しました：コード生成のコストがゼロに近づいているからこそ、チーム文化と共通の基盤がますます重要になるのです。
決して「最後にコミットした者が勝ち」になってはいけません。例えば、誰かが深夜3時まで起きてこっそりコードをコミットしたり、リリース直前に定时タスクを仕掛けて滑り込みで操作したりするのは絶対に許されません。まさにコードの価値が下がったからこそ、チームの横方向のアラインメントには明確な妥協点が必要なのです。
【6】コードレビュー：Claude に任せること、人間が残すこと
Cat Wu がカンファレンス午前中のキーノートで、Claude による自動 PR レビュー機能についてすでに講演しました。Fiona のここでの視点はより具体的です：何を Claude に任せ、何を人間に残すか。
Claude に任せること： スタイルチェック、lint の重複除去、コードレビューコメントへの応答、通常のバグの発見、そしてユニットテストの補完。彼女によれば、Claude は今や PR の「整理」を非常に得意としており、通常、人間が引き継ぐ前にほとんどの汚れ仕事を終えています。
依然として人間の介入が必要な3つのカテゴリ：
3つ目のカテゴリについて、彼女は軽妙な例を挙げました。彼女には小さな趣味があります：Claude の端末の見た目を季節ごとに飾ることです。クリスマスには Claude を雪だるまに変えようと、Claude に ASCII アートで描かせました。その結果をデザイナーの同僚に見せて意見を求めたところ、一言：「ミスター・ピーナッツに描けちゃってるよ。」
彼女は最終的にシンプルな案を採用しました：アイスブルーと雪の結晶。この話は、プロダクトセンスの重要性を示しています：抽象的な判断は自動化が難しいのです。
【7】コードの境界が曖昧になり、役割分担も再編されている
Claude Code チームでは、ほぼすべての PR に Claude が関与しています。「このコードは誰が書いたのか？」という問いは、荒唐無稽で意味を失いつつあります。
Fiona は、このような表面的なことにこだわるのではなく、本当に知りたいことを深掘りするよう提案しています：誰の変更がバグを引き起こしたのか？ 誰が十分な背景知識を持って顧客に技術的詳細を説明できるのか？ 誰がこのコードモジュールの経緯をよく理解しているのか？ 後者の細分化された質問をするならば、より良い自動化の方法があることがわかるでしょう。例えば、彼女にはかつてこんな習慣がありました：毎朝コーヒーを淹れ、Claude Code を使って顧客フィードバックチャンネルの情報を要約すること。今ではこの作業は Routines の自動化タスクに組み込まれ、手動でコマンドを打つ必要すらなくなりました。
この役割の曖昧化は双方向で進行しています。一方では、非技術出身のメンバーもコードを書き始めており、Claude Code チームの PM も実際に PR を提出しています。もう一方では、エンジニアが自分の担当領域を飛び出して、伝統的に他のポジションの仕事とされていた役割を担うようになっています。Fiona 自身の例を挙げると、彼女は Claude Code のユーザーアンケートを改善したいと思いましたが、コンテンツデザイナーが見つかりませんでした。以前であれば、コンテンツチームと一緒に何度も文案の文言を詰めていたでしょうが、今は Claude をコピーライティングのパートナーとして直接使っています。彼女は典型的なエンジニアとして、「文案を洗練させることに関しては、めちゃくちゃ苦手だ」と自嘲しています。
採用において、 Claude Code チームは2つのタイプの人材に重点を置いています：
彼女がもはや重視しないのは、生のコーディングスループットです。モデルがすでにその部分を平均化してしまったからです。
【8】組織形態：可能な限りフラットに、マネージャーは IC からスタート
Anthropic が彼女を Claude Code に採用する際、相手側はデフォルトで「IC 10人につきマネージャー1人、さらに下位に階層を設ける」という構造で採用を進めていました。Fiona はそれを拒否しました。
彼女が求めたのは可能な限りフラットな組織でした。Claude Code と Cowork の2つのラインは単一のチームミッションのみを共有し、各サブグループが個別にミッションを設定することを許しません。その理由は実に現実的です：ミッションが変わると、多階層では下位へのアラインメントに多くの時間を要しますが、フラットであれば柔軟性が増すからです。
彼女はもう1つ固く主張しました：Claude Code チームのすべてのマネージャーは、まず IC（個人貢献者、現場のエンジニア）を経験しなければならない。
採用担当者の最初の反応は「正気ですか？」というもので、マネージャーが IC をやりたがるはずがないという意味でした。
（"This is what dogfooding on the Claude Code team's about, this is what I expect and if someone's not interested it's better for us to do earlier separation."）
このルールは彼女自身にも適用されます。彼女が最後に本番環境にコードをプッシュしたのは2017年で、Anthropic に入ってから再びコードを書き始めました。Meta にいた頃は年に1回 PR を提出しようとしていたそうですが、内部ツールが変わるのが速すぎて、1年間で1つのコマンドを覚えても翌年には陳腐化してしまったとのことです。
（"Nowadays I don't even remember git commands, I just always ask Claude to help me out with all of that."）
【9】ドキュメントから撤退し、コードを「唯一の事実の源泉」に
Claude Code チームは現在、コードを究極の source of truth（唯一の事実の源泉） と見なしています。例えば、Fiona は技術的な顧客クレームにどう対応しているのでしょうか？ 彼女はデスクトップ版 Claude Code を起動し、ローカルリポジトリをマウントして、大規模言語モデルにコードから直接ロジックを探させて回答します。このアプローチは、ソフトウェア業界の千年の課題——開発ドキュメントがコードと同期しない——を完全に解決しました。
ただし彼女は、この経験則がすべての状況に当てはまるわけではないと補足しています。もし皆さんのチームの業務上、完璧な要件ドキュメントが必要であれば、spec もコードベースにコミットし、Claude に最終的なコードとドキュメントの整合性を相互検証させるのが良いでしょう。
これらの変更を推進するにあたり、Fiona は「必ず統一すべきこと」と「チームに委ねること」の2層を区別しています。
必ず統一すべき中核的な原則：
最後の点について、彼女は具体例を挙げました。Claude Code チームはかつてスタンドアップミーティングを行っていましたが、チームが大きくなった後は共有スプレッドシートに週次の進捗を記入する方式に変更しました。ある日、彼女はその大きな表を見て味気なさを感じました：情報は明らかに Claude が読める場所にあったからです。実際、Claude に要約スクリプトを書かせてそこに置いておけば、誰でもいつでも他のメンバーのステータス概要を取得できる——表の入力を催促するよりもはるかに優れていると気づいたのです。
一方で、チームに委ねる裁量の範囲も明確です： バグのトリアージ（振り分け）メカニズム、スケジュールのリズム、当番の割り振り方、さらにはどのワークフローの優先度が高く Claude を先に導入すべきかといったことまで、すべてチームの自主判断に委ねています。
【10】3つの観測可能な指標と、1つの警告
彼女は具体的な数値は明かしませんでしたが、3つの方向性を示しました：
（"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つの問題があることを認めました：
まとめ
彼女が聴衆に贈った最後のアドバイスは、実に素朴で直接的です：
（"Pick your noisiest workflow … is it still really serving, what's the purpose of there."）
彼女は自身の経験を反面教師として挙げました。以前あるチームを率いていたとき、絶対に外せない週次ミーティングがあり、50人以上が大きな部屋に詰めかけていました。しかし Fiona がよく観察してみると、名前を呼ばれて状況報告をするように指示された人が申し訳程度に顔を上げる以外は、他の全員が一致団結して下を向いてキーボードを叩いていました。その後、彼女が「一体何のためにこのクソミーティングを続けているんだ」と尋ねたところ、瞬時に全会一致でその場で解散することが決まりました。
>
>
📸 フローチャート/図解