AIネイティブなエンジニアリング組織の構築

AIネイティブなエンジニアリング組織の構築

先週、Will Larson (@Lethain) が、リーダーがAIスキルについてエンジニアリングマネージャーをどのように評価しているか尋ねました。私の返信（考えるべき質問リスト）は、多くのブックマークを獲得しました。

より広範には、AIネイティブなエンジニアリング組織をどのように構築するかをしばらく考えてきました。FurtherAIでの過去9ヶ月間の構築経験から得られた教訓を共有します。

［画像］

パート1：出荷方法の変化

エンジニアあたりの出荷量

1月以降、エンジニアが1日にマージするコード変更の数は約5倍に増加しましたが、リバート率は0.5%未満に抑えられています。

［画像］

しかし、エンジニアにコーディングエージェントを与えただけでは、この結果は得られませんでした。

プロセスの一つのステップを高速化するたびに、次のステップで作業が滞りました。

そこで、ソフトウェア出荷のプロセス全体を一度に一つずつ見直し、最適化できる点を見つけ始めました。

出荷プロセスの再構築

［画像］

• コード（3月） – エージェントがコードを書き、エンジニアがそれを指示します。初期の頃はツールが変更に影響を与えることが稀だったため、明確な数値はありません。しかし、現在ではほぼ100%と言ってよいでしょう。
• テスト（4月） – エージェントがコードと並行してテストを作成します。変更にテストが含まれる割合は、15%から91%に増加しました。
• レビュー（5月） – 人間によるレビューの前に、AIが99%の変更をレビューします。以前は60%でした。人間のレビュアーは、判断が必要な部分に集中できます。
• CI（6月） – テストを並列化し、変更の影響を受けるテストのみを実行します。CIは、同じ17分で以前の20倍のテストを実行できるようになりました。
• バグレポート（7月） – バグ受付プロセスを自動化するためにClaudeTag (@claudeai) を使用し始めました。Slackで誰でもバグを報告でき、ClaudeTagが重複を特定し、チケットを作成し、適切な担当者に割り当てます。現在、バグチケットの60%を処理しています。
• ルール（8月） – バグやレビューコメントが、エンジニアしか知らないルールを露呈した場合、それをコミットやPRごとに実行される小さなPythonチェックに変換しました。これにより、暗黙知をルール化します。エージェントはこれらのチェックに遭遇すると、自身のコードを修正して次に進みます。ルールはゼロから21まで増えました。これらは、低リスクの変更が人手を介さずにマージできるようになる大きな要因です。
• マージ（8月） – テスト、自動チェック、AIレビューをパスした低リスクの変更は、自動的にマージされます。現在、変更の最大3分の1が人手を介さずにマージされています。
• コードチャンネル（9月） – 誰でもSlackチャンネルを開き、エージェントに変更内容を説明し、PRを作成させることができます。まだ明確な数値はありませんが、コラボレーションに非常に役立っています。複数の人が同じエージェントを一つのチャンネルで利用し、進行中の作業にコンテキストを追加したり、指示したりできます。また、Devin (@cognition) のクラウドセッションをチームでのコラボレーションに活用しています。

また、社内のPoirotとSherlockエージェントを使用して、本番環境とステージング環境の問題を調査・解決しています。これらのエージェントは、ログ、メトリクス、トレース、読み取り専用データベースアクセスなど、必要なすべてのツールとコンテキストを持っています。

エージェント同士が連携する瞬間は、最も素晴らしいものの一つです。Claude Tagがリクエストをトリアージし、Devinが作業を行い、Poirotが必要な内部データを取得します。彼らが互いに話し、情報をやり取りするのを見るのは楽しいです。

興味深い副次的効果として、非エンジニアもコードを出荷し始めています。デザイナーは8月以降、デザインシステムを構築した変更を含む約50件の変更をマージしました。デプロイメントや顧客対応の役割を持つ人々も、Slackから直接UIの微調整を行えるようになりました。

コスト

これらすべてが無償で行われたわけではありません。夏の間、エンジニアリングの労力の大部分はテストとツールに費やされ、エンジニアあたりの顧客向け変更数は月17〜30件の間で推移しました。

9月にはそれが45件に跳ね上がりました。10月は48件のペースです。

［画像］

パート2：チーム内の変化

エンジニアリングが高速化するにつれて、別の問題に気づき始めました。

新たなボトルネック

コードを書く速度は大幅に向上しましたが、何を構築するかを決定する速度はそれほど向上しませんでした。

簡単な例を挙げます。

ある機能が以前は10日間かかっていたとします。計画に3日、構築に6日、レビューに1日です。

エージェントが構築を3.5倍高速化しても、計画とレビューが変わらなければ、機能全体の速度は1.75倍にしかなりません。

計画とレビューが、以前の40%から70%を占めるようになりました。

［画像］

従来、これらの意思決定の多くはエンジニアリングマネージャー、プロダクトマネージャー、デザイナーを通じて行われていました。エンジニアの速度が向上するにつれて、これはますます困難になります。

エンジニアがはるかに速く構築できるチームを、意思決定やレビューの周りにボトルネックを作らずにどのように組織化できるでしょうか？

私たちの賭けは、エンジニアへのオーナーシップをさらに推進することです。マネジメント層を増やすのではなく、エンジニア自身が計画、実行、レビューの大部分を処理できるようにしたいと考えています。

これは、エンジニアとマネージャーに期待されることを変えます。

エンジニアにとっての意味

エンジニアリングのシニアリティを、問題全体をどれだけエンドツーエンドで所有できるかという観点から考えるようになっています。おおよそ以下の通りです。

• ジュニアエンジニア – エージェントを使って構築し、それが間違っている時に気づくことができる。
• シニアエンジニア – 自身の作業の計画とレビューを行う。
• スタッフエンジニア – 曖昧な問題を引き受け、トレードオフを行い、それが成功したかどうかを示す数値を所有する。

これはまた、エンジニアが顧客にさらに近づく必要があることを意味します。

顧客の問題の理解からソリューションの出荷、成功の検証、本番環境でのリグレッションの所有まで、プロセス全体をエンドツーエンドで担当できるようにエンジニアを支援しています。

マネージャーにとっての意味

これはエンジニアリングマネージャーに期待されることも変えます。

1. 作業に深く関わる。

マネージャーは、何が構築されているのか、なぜ構築されているのか、そしてそれが正しいソリューションなのかを理解する必要があります。

コードがレビューされたかを確認するだけでなく、マネージャーがステージング環境でエンドユーザーのように機能を試すことを期待しています。実際に製品を使用すると、異なるクラスの問題に気づくことができます。

しかし、目標は単にレビューを増やすことではありません。常に、エンジニア自身が正しい意思決定を行えるように育成することが目標であり、マネージャーは判断が必要なものにのみ介入します。

2. よりプロダクトに精通する。

コードを書くコストが低下すると、何を構築するかを決定することがはるかに重要になります。

エンジニアリングマネージャーには、顧客を理解し、強いプロダクト意見を持ち、技術的な決定だけでなくプロダクトの決定を下すことに快適であることを期待しています。

また、エンジニアがそのような判断力を養うのを助けるべきです。すべての小さなプロダクトの決定をPMやデザイナーに委ねる必要はありません。

現状

今年のほとんどの時間を、エンジニアをより速くする方法を見つけることに費やしました。今、組織全体をそのスピードで動かす方法を見つけようとしています。

これはコード、テスト、レビューの自動化よりも難しい問題になるだろうと推測しています。

まだ初期段階であり、まだ解決していないことがたくさんあります。しかし、これは私が取り組んだ中で最も興味深いエンジニアリングの課題の一つです。

他のチームが何を見ているのか興味があります。エンジニアが出荷速度を上げたとき、最初に何が壊れましたか？

私たちは、次の波の課題を解決するために、@furtheraicom でエンジニアリングマネージャー/ディレクターを募集しています。もしこれが興味深いと思ったら、連絡してください！