改訂版エンジニアリングリーダーシップのルール

• AIツールへの移行と急成長（hypergrowth）環境の中で、この1年検証して再定義したエンジニアリングリーダーシップの5大ルールと、それを裏づける実際のプロジェクト事例の整理
• マイグレーションは今やチームではなく個人が95%主導し、従来の10%の時間で完了可能。初期コストが下がるほど、個人の判断の影響力が大きくなる
• 一次コードはほぼ無料だが、うまく動くコードのコストはテストやCI/CDなどの開発ハーネスに左右され、無料ではない
• ほとんどのプロセスの基本ケースはエージェントで完全自動化でき、コードレビューのファーストパスも、優れたハーネスのほうが人間より速く効果的
• AIの利点を実際に享受するには、ドメインコンテキストを持つ継続的なチームと、速く堅牢な意思決定が前提条件

---

背景

• 2014年初め〜2020年末にhypergrowth環境で勤務。hypergrowthの最大の価値は、ミスが来年ではなく翌月に明らかになる点（速く動くほど問題は大きく顕在化する）
• 最近hypergrowthを再び思い出した理由は、Imprintの急速な事業成長、昨年の大規模採用、そしてAIツールへの移行によって作業可能な速度が変わったため
• この記事では、再定義したリーダーシップのルールと、その信念を持つに至った過去1年の具体的なプロジェクトをあわせて整理する

改訂版ルール

1. マイグレーションはチームではなく個人が実行できる

• 複雑で大きな変更でも、それを主導する個人またはチームが95%を所有し、従来比10%の時間で完了する
• 初期コストが下がるほど、各マイグレーション品質に対する報酬/ペナルティが大きくなる
  • 小さな欠陥であっても、一緒に保守する同僚のソフトウェアに対するメンタルモデルを崩してしまう
• 会社に及ぼす個人の判断の影響力は、かつてないほど大きい

2. 一次コードはほぼ無料だが、動くコードのコストは開発ハーネスに左右される

• 誰もがコードを書くべき時代ではあるが、厄介なエッジケースを避けつつうまく動くコードを書くことは、依然として難しい
• その難易度は、テスト、CI/CD、検証環境、変更プレビューなどの開発ハーネスによって決まる
• 「誰もがコーディングする」会社であっても、マーケティングチームがサーバー割り当てを減らすわけではなく、彼らが安全に参加できる境界の存在が重要（ソフトウェア記述によるカスタマイズを許可するSaaS製品に似ている）
• 2年前にエンジニアリング速度を高めるうえで最も価値があったものは、今日でもなお最も価値がある

3. プロセスの基本ケースをエージェント向けに最適化する

• 適切なハーネス・制御・ドメインコンテキストと、設計者の優れた判断があれば、ほとんどのプロセスの基本ケースを完全自動化できる
• 人間によるコードレビューの基本ケースは、優れたハーネスによるコードレビューより遅く、効果も低い
  • ハーネスも見落とすが人間も見落とすし、大半の領域では変更は比較的安全である
  • ただし一部の高リスク領域は例外であり、この区別を適切に捉えられればリスクなく速くなり、失敗すれば無数の問題が起こる
• 系として、週次・隔週スプリントのような計画プロセスは低すぎる高度で動いており、人間による共同計画はもっと高いレベルで行われるべきである

4. ドメインコンテキストを持つ継続的で高オーナーシップ（high ownership）のチームがさらに重要になる

• Uberでの教訓：継続的で堅牢なチームは、ドメインコンテキストを蓄積し、仲間意識を形成し、強いオーナーシップによって魔法のような成果を出す
• 実行コストが安くなった時代でも、正しいことをしなければならない。それは少し簡単になっただけで、大幅に簡単になったわけではない
  • 例：本番環境の最適化に必要なデータがそもそも収集されておらず、ハーネスの解決策は合理的だが間違っていた。唯一の解決策は、欠けていた情報を計測することだった
• AIファースト企業は少数の天才エンジニアで運営されるという通説に反対する。判断力の高い個人でもドメインコンテキスト不足で限界にぶつかるため、継続的なチームこそが基本単位である

5. 速く、良く、堅牢な意思決定がAIの恩恵を受ける前提条件

• 法務レビューを自動化で置き換えるには、Legalがその変更を約束できなければならず、それは慎重な設計とチームの協働意欲に依存する
• 実行速度向上の恩恵は、速く、堅牢で、良い意思決定を下せる場合にのみ得られる
• これが、平均的なCTOの役割が1年前よりはるかに技術的で、官僚的でなくなった主な理由である
  • チーム間で意見が分かれたとき、拘束力のある決定を下せる唯一の人物である場合が多く、速度を維持するために絶えず決定を下している
  • これは幹部のほうが優れた意思決定者だという主張ではなく、幹部たちが互いに足並みをそろえ、その決定を尊重する限り、拘束力のある幹部判断が比類なく強力だということ

実際の適用事例

マイグレーション

• 1年前は手動デプロイで週約6回 → 現在は週200〜400回デプロイ。エンジニア数は2倍だがYoYで20〜30倍増加。デプロイ・マイグレーションの運用方式の全面改編を、インフラチームの2人が2か月間で90%実施
• 1月1日時点で約25%が毎日Claude CodeまたはCursorを使用 → 2月末には100%。トップダウンの指示なしに、ツール品質の改善と未採用者との対話で摩擦を除去。現在、ほぼすべてのPRの一次作成はハーネスが担当
• 多様な設定方式を2つの設定メカニズム（ほとんど変わらないクライアント/サーバー定数用、製品別・頻繁に変わる値用）へ統合。個々のエンジニアの独立プロジェクトとして進行
  • 1人がアーキテクチャを整理 → 別の1人が参照アーキテクチャを実装 → 複数人が他領域へ適用。以前なら数年がかりのプロジェクトだったが、1四半期未満で完了。エンジニア・非エンジニアチームが値を管理するための社内ツールも含む
• マルチリポジトリのフロントエンドを約1か月でモノレポアーキテクチャへ統合。95%をフロントエンドエンジニア1人が主導し、共有フロントエンドハーネスを確保し、摩擦の原因だったnpmパッケージホスティングから完全に脱却
• ほとんど型がなかったフロントエンドコードを完全に静的型付け。1人のエンジニアが大量のトークンを使って数週間かけて実施
• より良いセキュリティデフォルトと高速なデプロイのためにnpmからpnpmへ移行。1人のエンジニアが数日間、毎日数時間ずつ作業

動くコードのコストは開発ハーネスに左右される

• 設計文書やPRを他チームのエンジニアに「壁の向こうへ投げる」やり方は成果がない。粗雑な（slop）PR・設計文書は安いが、むしろ有害である
  • 整理・修正が必要で、そのコンテキストがLLMを汚染し、最初から始めるより悪い結果を招く
• マネージャーが変更を直接検証し、デプロイ後にダッシュボードを確認し、発生した問題を解決する限り、マネージャーのコード貢献は大きな成功となる。そうでない場合、肯定的な効果はない

プロセス基本ケースのエージェント最適化

• カスタマーオペレーションチームのすべての流入イシューを、チーム・未解決チケットを把握し、データウェアハウスへ限定的にアクセスして影響度を算定するハーネスでトリアージ。複雑で高スキルだが面白くはない作業を、より速く処理
  • エッジケースは依然として人間がトリアージし、人間のワークフローを変えずに、同じ流れの中で一部ステップだけを自動化
• コードレビューのファーストパスは、変更を実装した同じハーネスが作成コンテキストを空にした状態で実施し、人間はより価値の高いフィードバックに集中
• 前四半期にClaude CodeとCoworkを全社展開。fraudチームが特に積極的に手作業を一次自動化へ置き換え、潜在的攻撃の初期調査を自動実行（データ自体に起因するアトリビューションを含む）
• JiraからLinearへ移行。より強力なMCPと優れたSlack統合により、エージェントファーストのワークフロー基盤を強化。Linearからイシューを取得して自動解決する社内ハーネスのアルファテストはほぼ完了

ドメインコンテキストを持つ継続的で高オーナーシップのチーム

• 参加当時は才能ある人材がプロジェクトごとにすばやく領域をローテーションして非常に反応的だったが、現在はすべての重要領域に専任の小規模チームを配置して継続投資しており、これらのチームが直接新しいAI手法を活用している
• SierraAIローンチ後、チームが絶えず改善し、真に卓越した水準へ発展。専任で集中したチームなしには不可能だった成果

速く、良く、堅牢な意思決定

• 設定方式の変更は論争を呼ぶものだったため、アプローチを繰り返し説明。チームごとに影響が異なり、恩恵はエコシステムレベル（1人が全チームの設定を構成する）でしか生じないため、ボトムアップでは難しい
• CI/CDパイプラインの作り直しもデプロイ・リリースのメンタルモデルを変えるため論争的で、フィーチャーフラグによりデプロイとリリースを明示的に分離するよう強制
• Webモノレポ統合も意見が分かれる論争的な決定であり、統一された決定の利点が大きい
• SierraAI導入は競合製品や未導入案との難しい議論を伴い、クロスファンクショナルな論争を終わらせる幹部の承認が必要だった

まとめ

• 上記の事例は代表的な一部にすぎず、ほかにも多数実施している。可能なことの範囲は毎月拡大し続けている
• 足を引っ張る要因は大きく変わっていない：組織的な不整合、明確さの不足、粗末な技術アーキテクチャ