AI ネイティブなエンジニアリング組織を運営する

長年にわたり、エンジニアリングのキャパシティはアプリケーション構築における高コストな要素でした。ソフトウェアの計画やリリースに関わるかつてのプロセス、まずウォーターフォールモデル、その後アジャイルへと移行しましたが、すべてがこのコストを前提に設計されていました。 私は2000年代初頭にVisual Studioでの開発に従事し、キャリアをスタートさせました。その頃はCD-ROMでソフトウェアを配布しており、厳格な製造納期が存在しました。オンラインでのソフトウェア配布が可能になると、継続的なアップデートのリリースへと移行し始めました。現在では再び働き方を変えようとしており、今回はソフトウェアを書くのに要する時間と人件費が焦点となっています。 Claude Code チームにおいては、コードの記述、テスト作成、リファクタリングはもはや私たちの足かせとはなりません。しかし、エージェント型コーディングによって実際にコードをタイプする必要性が失われたとしても、ボトルネックが消えたわけではありません。代わりに検証（verification）、コードレビュー、セキュリティが新たな課題として浮上しました。 現在では誰もが非常に高速に大量のコードを生成できるようになりましたが、これに伴い新たな疑問も生じています。「このコードは正しいのか？」「どのように維持管理されるのか？」そして、同僚であるエンジニアリングリーダーから最も頻繁に寄せられる質問の一つは、「人間がどのようにして、你们的なコードレビューのペースについていけるのか？」です。 ## The processes that quietly stopped working 私たちはすべて、何かの隙間を埋めたり、より良く機能させたりする目的でプロセスを導入しています。しかし、その隙間がもはや存在しなくなり、それらのプロセスが時代遅れになった場合、それらは自ら消えることはほとんどありません。Claude Code チームがアジェンティックコーディングをデフォルトの作業方法として使い始めたとき、既存のプロセスの多くが機能しなくなりました。以下に、私たちが書き直した規範とその理由を示します。 ## Planning: shift roadmaps to just in time 従来の規範では、コーディングコストが高かったため、事前計画に多くの時間を費やすことが一般的でした。私が Claude Code チームに参加した当初、私たちは非常に良い 6 ヶ月間のロードマップを作成しましたが、Claude Code の登場により状況が次々と変化し、3 ヶ月目にはすでに時代遅れになっていました。 エンジニアリングの速度とスループットは現在では異なっているため、スプリントの計画方法も変わりました。私はこれを「ジャストインタイム（JIT）プランニング」と呼んでいます。まさに JIT コンパイルのように、「適切なタイミングで必要な分だけ」をどう行うかが問われます。私たちの計画のリテラルは、設計ドキュメントから PR やプロトタイプ内での議論へとシフトしました。この領域の動きが速いため、多くの製品レビューを行うことはなくなりました。現在のプロセスは、まずプロトタイプを作成し、多くの内部ユーザーに利用してもらい、そのフィードバックに基づいて行動を開始するというものです。 ## コンテキスト収集：著者に聞くのではなく、Claude に尋ねる エンジニアがコードを記述していた時代、多くの質問に対する答えを得るための最初のステップは、そのコードを書いた人物を見つけることでした。現在ではすべてのプルリクエスト（PR）が Claude によって支援されているため、「誰がこの変更を加えたのか？」という問いだけでは不十分です。私たちの新しい規範は、一歩深く踏み込むことです：実際には何を知りたいのか？例えば、回帰の原因となった人物を探しているのか、顧客の質問に答える専門家が必要なのか、それとも意思決定の背景情報を求めているのか。そのような質問を Claude に投げかけ、より多くのデータと文脈を提供することで、Claude が直接回答できるかどうかを検討します。 Claude Code チームでは、どのような問いであっても、プロセスとして「これを自動化する方法はないか？」と必ず追加で問います。例えば、毎朝顧客フィードバックチャネルの要約を Claude に実行させることは、かつて私がコーヒーを飲みながら手動で行っていた儀式から、背景で自動的に実行されるタスクへと変化しました。 ## コードレビュー：信頼せよ、しかし検証せよ 私たちは [Code Review](https://code.claude.com/docs/en/code-review) を積極的に活用しています。Claude はスタイルやリンティングの処理、PR へのフィードバック要求、バグの検出と完全なコミット前の修正、テストの追加をすべて担当します。人間が必ず関与すべき領域は専門知識です。 新しい規範は、重要な場面で人間のレビューを行うことです：法的レビューにおいては、リスク許容度について常に法務パートナーに関与してもらいます。信頼境界やセキュリティに敏感なコードについては、ドメインの専門家に関与してもらいます。プロダクトマネージャーとデザイナーも、プロダクトセンスや審美性の観点から関与する必要があります。 ただし、モデルの改善に伴い信頼と検証の適切なバランスは常に変化していくため、継続的に評価を行うことが重要です。今日人間に必要とされるものが、次のモデルでは異なるものに見えるようになるかもしれません。 ## チーム構成：役割の境界が曖昧になる Claude や AI はチーム全体の役割を再構築しました。現在、私たちのプロダクトマネージャー（PM）は多くのコードを書きますが、それは見ていて楽しいことです。Claude によって、非伝統的なバックグラウンドを持つ人々がより多くのエンジニアリング業務を担えるようになり、一方でエンジニアたちはコンテンツやデザインといった、従来技術側には含まれていなかった仕事も引き受けるようになりました。 Claude Code エンジニアリングチームにおいては、私は主に2つのプロファイルに重点を置いています。1 つ目は、製品感覚を持つ創造的なビルダーです。問題解決型の製品をリリースすることに深く好奇心を持ち、情熱を持っている夢想家たちです。もう 1 つは、深いシステム専門知識を持つエンジニアです。例えば、私がチームに参加した際、システム背景を持つ専門家不足に気づきました。Claude をウェブ上で動作させる [Claude Code on the Web](https://www.anthropic.com/news/claude-code-on-the-web) を構築する際には、どこでも Claude を実行できるようにするために、そのような専門知識が必要でした。 一方、私が重視しないのは純粋な処理速度です。その点はモデルが担ってくれます。より重要なのは、依然として人間の専門知識が必要な領域はどこかという問いであり、そこに焦点を当てるべきです。 Before After 計画 6 ヶ月間の製品ロードマップ。 ジャストインタイム（JIT）計画：プロトタイプを作成し、内部ユーザーに使用してもらい、そのフィードバックに基づいて行動する。 文脈の収集 コードを書いた人物を見つけ、直接尋ねる。 まず Claude に質問する。その後、自分が尋ねていることが自動化可能かどうかを確認する。 コードレビュー 人間がすべてをレビューする。 Claude はスタイル、バグ、テストを担当する。ドメイン専門知識が重要な箇所は人間がレビューする。 チーム編成 固定された役割：エンジニアはコードを書き、PM（プロダクトマネージャー）は計画を立て、デザイナーはデザインを行う。 役割の境界が曖昧になる：PM がプロトタイプを作成し、エンジニアがデザインと文脈の把握を担当する。創造的なビルダーと深いシステム専門知識を持つ人材を採用する。 新しい規範の導入方法 これらの規範が変化するにつれ、一部の側面はチーム原則として義務化され、他の部分は小規模なサブチーム（ポッド）に任せて独自に見つけてもらうことにしました。Claude Code コアチームには、交渉不可能な「必須事項」としての一連の原則が存在します： - 製品を徹底的に自社利用する：Claude Code チームの全メンバー、クロスファンクションなパートナーを含め、全員が Claude Code（および Claude Cowork）を利用しています。私たちは常に、Claude が私たちの業務をより速く、より効率的に行うための方法を模索し続けています。 - チームは可能な限りフラットに保つ：私が Claude Code に参加した際、すべてのマネージャーはまず IC（Individual Contributor：個人貢献者）としてスタートし、製品リリースを通じてチーム内で効果的なエンジニアとしての役割を学び、Anthropic のエンジニアとして働くことがどのようなものかを体感・理解することを望んでいました。Claude Code と Claude Cowork には一つの全体的なチームミッションがあります。マネージャーはチームの俊敏性を保ちつつ、作業のポッド（小グループ）をサポートし、人々が必要な場所に移動できるようにしています。 - 機能しなくなったプロセスを躊躇なく廃止する：最後に、私たちは「なぜそのように行うのか」について絶えず問い直します。何かがもはや意味をなさない場合、チームメンバーには古いプロセスに異議を唱え、廃止する明確な権限が与えられています。 これらの数少ないルールの中でさえ、各ポッドは大きな裁量権を持っています。Claude をどのようにトリアージ（選別）に活用するか、どのような計画会議やスタンドアップを実施するか、どのワークフローを最初に「Claudified」（Claude 化）するかについて、適応する余地があります。 ## 新しいプロセスが定着したかどうかを知る方法 変更を導入する際に、すべてのエンジニアリングリーダーが今すぐ追跡し始めるべき数値を3つ紹介します。 - オンボーディングの習熟期間が短縮される：エンジニア、デザイナー、またはプロダクトマネージャー（PM）はいつから効果を発揮し始められるか？私たちのチームでは、1 年前よりもはるかに速く、エンジニアたちは最初の週にすでに本番コードをリリースするようになった。 - プルリクエスト（PR）のサイクル時間が短縮される：これはパイプラインがスケールする上でどこでつまずいているかを特定するのに役立つ可能性があるため、掘り下げてみると面白い。生成されるコード量が大幅に増えるにつれ、ビルドシステムや継続的インテグレーション（CI）が追いつかなくなる場合もある。 - クロード支援によるコミットが増加：私たちのチームではデフォルトで、すべてのコミットが Claude によって支援されている。過去 4 ヶ月間で、Claude 支援ではないコミットを見たことがない。 3 つ目の項目については、スループットと成功を混同しないこと。スループットは一つの指標に過ぎず、真の指標は解決しようとしている課題を測定することである。適切なアライメントがあれば、スループットは問題をより速く解決するのに役立つ。 ## 始め方 もし私が一つだけお伝えできることがあるとすれば：**最もノイズの多いワークフローを選べ**ということだ。それは最もコストがかかるワークフローかもしれないし、あなたが恐れているもの、あるいはチームが楽しみにしていないものかもしれない。そして問うのだ：それでもなおその目的を果たしているか？そうであれば、それを自動化できないか？ かつて、高価な週次レビューを行うチームに所属したことがありました。会議室には大勢の人が集まり、全員がラップトップを操作していました。ただし、自分の番でステータス報告をする時だけ例外でした。彼らは顔を上げ、状況を報告するとすぐにまたラップトップに戻ります。私はただ一つのシンプルな質問をしました。「なぜ私たちは再びこの会議を開いているのでしょうか？これは私たちの時間の無駄遣いのように思えます。」そのたった一つの質問が、全員にこの会議が必要ないことを気づかせました。そこで私たちはその会議をキャンセルしました。 では、自問してみてください：あなたのエンジニアリングワークフローの中で、自動化を検討すべき、あるいは完全に廃止してもよい部分はどれでしょうか？

AI ネイティブなエンジニアリング組織を運営する

背景や根拠まで確認しますか？

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

ニュースの次に確認する

調べる

選ぶ

サイト