AIは増幅器であり、方向ではない。

記事作成者、出典：InfoQ

AIによってコードの作成が10倍速くなったとして、その後どうなる？より多くのコードは、より長いコンパイル時間、より重いテスト負荷、より混雑するコードレビュー、そして誰も理解できないコードベースをもたらす。ソフトウェアは負債であり、速く書けば書くほど、より多く借り入れることになる。

Googleのチーフソフトウェアエンジニア、アダム・ベンダーの警告は明確だ：今日あなたがソフトウェアを構築する方法では、10倍のスピードでは全く対応できない。しかし、AI時代の真の勝者は、生産性が最も高いチームではなく、基本が最もしっかりしているチームである。なぜなら、AIは方向性を決定するのではなく、単に拡大するだけだからだ。

Google I/O 2026 のキーノートスピーチで、アダム・ベンダーは、ほとんどの人がまだ考えたことのない問いを投げかけた：AIがコードの生成速度を現在のエンジニアリングプロセスが耐えきれないレベルまで押し上げたとき、開発者エコシステムのうち、何が最初に崩壊するだろうか？彼は、ソフトウェアエコロジーという、おそらくあなたが聞いたことのない概念を用いて、スピーチ全体を貫いた。ソフトウェアエコロジーとは、ソフトウェア生産という社会技術的エコシステムを全体として研究する学問である。言い換えれば、技術だけでなく、人間や文化、組織内の非公式なルールにも目を向ける必要があるということだ。このスピーチの動画をもとに、InfoQが内容を整理した。

核心の見解は以下の通りです：

AIはデフォルトでいかなる問題も解決しません。あなたの実践が優れていれば、それを拡大します。しかし、十分でなければ、より多くの問題を生み出すだけです。
誰もがビルダーであることは素晴らしいが、誰かが構築したすべてを維持しなければならないとなると話は別だ。
実践は神聖不可侵なものではない。実践は変化するが、原則が重要である。
この臨界点において、一线のソフトウェアエンジニアとして、ソフトウェアエンジニアリングの将来を決定する中心にいます。ツールからワークフロー、エンジニアリング実践からエンジニアリング文化まで、動いているシステムを理解できれば、レバレッジを見つけることができます。

「システム」とは何ですか？

2026年のあなたの仕事は、2020年にあなたが想像していた姿とはまったく違う。2020年の自分に今日起こっていることを説明しようとしたら、私は信じないだろう。変化が多すぎて、少し対応しきれないほどだ。私は未来を予測できないが、現在のソフトウェアエコシステムを丁寧に研究すれば、いくつかの答えは私たちが想像するよりもはるかに近い場所にあると信じている。

今日は「ソフトウェアエコロジー（Software Ecology）」という言葉についてお話しします。まるで舞台上で適当に作ったように聞こえるかもしれませんが、これは本物の専門用語です。定義を示す前に、少し背景を整理し、システム思考について深掘りしましょう。

システムとは、一連のルールに従って動作する相互に関連する要素の集まりであり、統一された全体を形成します。抽象的に聞こえるかもしれませんが、あなたはシステムに馴染みがあります。たとえばエアコン：目標温度を認識するサーモスタット、加熱または冷却を行う暖房・換気・空調装置、部屋という空間があり、温度が適切になると信号が停止します。これがシステムです。

あなたがソフトウェアエンジニアであれば、毎日システムと向き合い、システムを設計し、構築し、運用しています。その過程で、あなたはおそらく一つのことを学びました：すべては関連しているということです。

次にエコシステムについて説明します。これは特別なシステムです。定義はやや長いですが、重要です：エコシステムとは、相互に依存するアクターからなる動的ネットワークであり、これらのアクターは環境と共に進化し、自己組織化された行動と分散型の自律性を特徴としています。言い換えると、エコシステムは非常に複雑で、構成要素同士が深く結びつき、各要素は独自の自律性を持ち、意思決定や行動を取ることができます。そして最も重要な点は、環境がシステムの一部であるということであり、両者を分けて考えることはできないということです。

エコシステムは、時間とともに成長し、変化し、進化する複雑適応システムでもある。また、エマージェント・プロパティ（出現的性質）という特性を持ち、これは個々の部品を観察しても見出せないもので、システム全体が組み合わさったときにのみ現れる行動である。この継続的な変化、継続的な学習、そして出現的性質が、エコシステム内で実際に何が起きているのかを理解することを極めて困難にしている。

エコシステムと言えば、山々や川、鳥の鳴き声や花の香りを思い浮かべるかもしれません。しかし、内部開発環境もまた一種のエコシステムです。さまざまなツールやサービス、それぞれのアイデアや要望を持つ人々、ビジネス上の制約が存在します。そしてこれは特別なシステム、すなわち「社会技術システム」です。これは人間と技術が共に構成するシステムです。社会技術システムは極めて複雑です。なぜなら、まずさまざまな技術から始めて、そこに人間を加えるからです。

あなたはおそらく、無意識のうちに社会技術システムの知恵に触れてきたはずです。コンウェイの法則をご存知ですか？組織が構築する技術は、その内部のコミュニケーション構造を反映するという法則です。簡単に言えば、同じコンパイラを4つのチームが開発すれば、4段階のコンパイラが出来上がってしまうのです。これが事実です。コンウェイの法則の核心的な洞察は、技術を構築する方法と、それを構築する組織構造が切り離せないということであり、組織が最終的に作られるものを形作るということです。

しかし、組織構造が開発者エコシステムに与える影響だけではなく、価値観と文化もまた深く影響します。あなたのエコシステムが育むのは、組織が奨励するものであり、あなたのエンジニアリング文化が開発者エコシステムを取り巻く環境を形作ります。社会技術システムを理解すれば、ソフトウェア開発のあらゆる場面——アーキテクチャ、事故の振り返り文化、コードレビュー、セキュリティポリシー——にそれらが存在することに気づくでしょう。私たちが構築するもの、そしてそれを構築する方法は、私たちが何を重視しているかを反映しています。十分に意識すれば、この認識を活用して、私たちの価値観を拡大し、それらを私たちが構築するものに注入することができます。

ここで正しい定義を示します：ソフトウェア生態学とは、ソフトウェアを生み出す社会技術的エコシステムを全体的に研究する学問です。先ほどの説明がやや抽象的だったとしても問題ありません。では、実際の事例を見てみましょう。

Googleの開発者エコシステム

私はGoogleについて話すのは、そこで働いているからそれを称賛するためではなく、私が最もよく知っている開発者エコシステムだからです。私の目的は、皆さんがGoogleをそのまま真似すべきだと伝えることではなく、それは皆さんのためになりません。皆さんは異なる企業であり、異なる段階にあり、異なるトレードオフに直面しています。Googleが行った多くの選択は、当時私たちがエコシステムを構築していた際の具体的なニーズに基づいています。

数年前、私たちは内部で「フラミンゴブック」と呼んでいた本を執筆しました。その本の半分はバージョン管理とテストについて述べていますが、全体の前半部はエンジニアリング文化について語られています。多くの人が、なぜ文化にこれほど多くのページを割いているのかと尋ねます。なぜなら、Googleの文化を理解しなければ、私たちがなぜそのような技術的選択をしたのかを理解することはできないからです。これらのことは互いに連動しています。

Googleにはいくつか独自の文化特性があります。私たちは深くエンジニアリング志向であり、重要な意思決定には常にエンジニアが参加します。私たちは透明性を極めて重視し、可能な限りすべてのドキュメントやコードを全員に開放しています。協力的な姿勢を奨励しており、実際にGoogleを離れた人誰かに話を聞くと、同僚たちの協力性が最初に挙げられることが多いです。私たちはコードレビューを採点ではなく指導の機会と捉えています。標準化を極めて重視し、継続的な改善を信じています。責任を問わない事故の振り返りを推奨し、英雄主義よりも持続可能性を、手作業よりも自動化を重視しています。もちろん、これらの理想を常に達成しているわけではありませんが、これが私たちが文化として目指す方向です。

技術面では、単一のコードリポジトリにほぼすべてのコードが集約されており、トランクベースの開発を採用して変更は直接メインブランチにマージされます。バイナリファイルをビルドする際には、ソースコードのほぼすべての行が再構築されます。全員が同じビルドツールチェーンを使用し、グローバルなテスト自動化プラットフォームを導入して、すべてのテストを1か所で実行し、毎日数十億のテストケースを処理しています。グローバルな「最後のグリーン」シグナルがあり、簡単な内部ウェブサイトだけで任意のビルドの状態を確認できます。統一された計算環境により、「自分のマシンでは動く」という問題は基本的に発生しません。開発者フレームワークは高度に標準化されており、核心的なプログラミング言語はごく少数です。

この文化と技術の混合が、今日のGoogleを形作っている。その半分だけを理解し、もう半分を無視することはできない。

運命を共有する

私たちを常にそっと導いている原則を選ぶとすれば、「共有された運命（Shared Fate）」を選びます。これは、エコシステムとその構成要素間の密接な関連性を表しており、共有された運命が高いエコシステムでは、ある構成要素が他のすべての要素に影響を及ぼします。開発者エコシステムにおいて、共有された運命は技術的な選択であると同時に、社会的な選択でもあります。すべての人が同じ技術を使用するだけでは、共有された運命を実現することはできません。それだけでなく、これらの技術をどのように管理するかという社会的契約を築く必要があります。

Googleでは、共通の運命は単一のコードリポジトリから始まります。会社のすべてのコードは、AndroidやChromeなどのごく少数の例外を除き、一つの共有リポジトリにあります。すべてのコードはマスターにコミットされ、ブランチもバージョン番号も存在せず、すべてが一つの場所に集約されています。この共通の運命により、一つのファイルにセキュリティパッチを適用すれば、一週間以内に会社内のすべてのアプリケーションが修正されることを確信できます。十行のコードで百億行のアプリケーションとシステムソフトウェアを修正するとは、まるで超能力のようでした。

しかし、運を共有することは常に良いとは限らず、それは選択です。生産環境では、あるサービスが他のすべてのサービスをダウンさせたり、あるクラスターが全体のリージョンに感染したりすることは決して望ましくないため、カスケード障害を引き起こすような危険な運の共有を避けるために多くの努力を重ねてきました。運の共有はトレードオフであり、適切な配置を見つけて、それがあなたのために機能するように確保する必要があります。

大規模な変更

私たちが共通の運命の中で最も興味深いエマージェント属性の一つは、大規模な変更です。注目してください：AIが登場するずっと前から、Googleの内部ツールは、開発者が数百万行のコードを変更できるようにしていました。そのコードは、彼らが読むことも、再び見ることも、おそらくまったく知らないコードでした。私たちは、これらを自動的に可能にするツールを構築してきました。今日もそうであり、過去少なくとも15年間、ずっとそうしてきました。

この能力により、私たちはモノリシックなコードリポジトリを継続的に進化させ、言語やフレームワークを更新し、内部環境が硬直化するのを防ぐことができます。大規模な変更がなければ、今日のGoogleにはなれなかったと言っても過言ではありません。これらのツールを開発している同僚たちは、会社が必要な速度で前進できるように、裏方で活躍するヒーローのような仕事をしています。

しかし重要なのは、大規模な変更を可能にする文化的要素と技術的要素を理解しなければ、その本質を真正に理解できないということです。必要なのは何でしょうか？普及したテスト文化—誰もがテストを書くこと。統一されたテストプラットフォーム—結果がどこで得られるかが明確であること。共通のビルドツール—あなたがビルドしても、私がビルドしても結果が同じであること。標準化されたライブラリ—コンポーネントを交換しても、どのバージョンが自分には有効で他人には無効かと探し回ることがないこと。標準化されたコードレビューと、コードリポジトリ自体の透明性—どのコードを変更すべきかが明確になること。大規模な変更は、Googleの「手作業より自動化を重視する」という理念の究極の体現であり、この実現にはエコシステム全体の協力が不可欠です。開発環境の特定の部分を指して「これが原因だ」と言うことはできません。すべての要素がつながっているからこそ、それが可能になるのです。

あなたのエコシステム、あなたのトレードオフ

各開発者エコシステムには、このようなエマージェントな特性が存在します。それらは通常、あなたの働き場所に独特な雰囲気を与えるものであり、それはあなたが行ってきた一連の選択の結果です。

Googleの開発者エコシステムは、私たちの技術的およびビジネス上の目標に沿って独自のトレードオフを生み出してきました。しかし、あらゆるエコシステムと同様に、すべてのタスクで優れたパフォーマンスを発揮することはできません。私たちは、開発者の生産性を犠牲にしても、極大なスケール、セキュリティ、パフォーマンスの最適化を選択し、このトレードオフを受け入れています。5人規模のスタートアップのエコシステムはまったく異なり、スピードと柔軟性が最も重要になります。

あなたが属するエコシステムの規模は、5人から20万人の間です。あなたが直面するトレードオフは非常に注目に値します。なぜなら、これらのトレードオフを検討することで、その組織が本当に重視している価値観——口では重視していると主張するものではなく、実際に観察される選択によって明らかになるもの——を理解できるからです。これらの価値観を理解すれば、進行中の変革を形作ることができるようになります。

10倍のタイミング：すべてのノードが圧力を受けています

トークンを食べている象について話す時です：AIファーストの開発者エコシステムは一体どのような姿をしているのでしょうか？

ゼロから新しいエコシステムを構築するのはもちろん素晴らしいが、誰もその余裕はない。あなたは、ほぼすべての部分を置き換えながらも、ソフトウェアの提供を継続しなければならない。会社は、あなたが問題を起こさずに価値を生み出し続けることを期待している。

では、自分に次の質問をしてみてください：今日の開発者エコシステムについて、どれだけ理解していますか？それを完全に描き出せますか？技術的な部分だけでなく、社会的な部分まで、すべての構成要素がどこにあるか知っていますか？あなたのエコシステムが何で構成されているか列挙できますか？あなたの組織の他のメンバーはどれだけ理解していますか？その強みと弱みは何か？ボトルネックはどこにありますか？どこが制約されていて、どこが自由ですか？あなたにはどのような選択肢がありますか？どのようなエマージェント特性を観察しましたか？おそらく最も重要なのは：もしあなたのエコシステムが今後18ヶ月以内にコード量を10〜15倍に処理しなければならなくなった場合、何が最初に崩壊するか、あなたはわかっていますか？

地球上すべての開発者エコシステムが根本的な変革を経験しています。まだあなたのいる場所まで到達していないかもしれませんが、それは間もなくやってきます。すべての開発者エコシステムは、この10倍の瞬間と向き合わざるを得ません。これは信じがたい時代ですが、同時に非常に混乱する時代でもあります。過去25年間に意図的に構築されてきたすべてのトレードオフが、再び見直されるでしょう。

コード生成を10倍速くすることと、エンジニアリング開発を10倍速くすることは、異なる二つのことである。Googleでは、エンジニアリングとは時間にわたって積み重ねられたプログラミングであるとよく言う。しかし問題は、我々がプログラミングの部分を大幅に加速させ、コードマシンの動作を速めているということだ。そのため、本当に顧客に価値を届けるためには、このコードマシンの周囲でエンジニアリングをどう整えるかが重要になる。この生産性の向上がどこまで推し進められるかは誰にもわからないが、一つ確実なことは、ここから私たちは上昇しているということである。

問題は、今日私たちがソフトウェアを構築し、提供する方法では、10倍または100倍の速度では対応できないということであり、何かを変える必要がある。

まず、開発者エコシステムの簡略版から見てみましょう。アクティビティが10倍に増加する世界では、何が変わらなければならないでしょうか？

コードの入库

ソースコードを書く。もし誰もがコードを速く書けるようになると、コード量は大幅に増えるが、それは良いことではない。ジェフ・アトウッドは、ソフトウェアは負債であると述べている。したがって、コードが10倍になれば、負債も10倍になる。そして、単に每人にトークンを配って「頑張って」と言うだけではいけない。トレーニングを終えた後で投資することを検討してほしい：あなたのエンジニアリングプラクティスドキュメントはどこにありますか？それらをどのように進化させますか？そのあとで考えましょう。

システムを構築する。より多くのコード、より大きなシステムは、より長いコンパイル時間を意味する。あなたの会社では、今現在誰もコンパイルの遅さに不満を言っていないだろうが、どうだろう、これからさらに遅くなる。そして、エージェントが大量の作業を処理している場合、コンパイル回数も急増する。コンパイルは、時間的にも計算リソース的にも無料ではない。あなたは自分がコンパイルにどれだけの時間を費やしているかに気づいていないかもしれないが、規模が10倍になると、必ず気づくだろう。

コード設計。分離を促進するのに適したエージェント化スキルを持っていますか？さまざまな機能を迅速かつ安全に組み合わせるための適切なサーバーサイドフレームワークはありますか？あなたの会社でWebアプリケーションが何種類のデプロイ方法で動いているか知っていますか？何種類の異なるサーバーサイドフレームワークが稼働していますか？エージェントが書いたコードのコンポーネント再利用をどのように管理していますか？もしかすると、これは重要ではないと賭けているかもしれません。しかし、エージェントが書きやすく保守しにくいコードを生成したとしても、驚くには当たりません。これが現在の基準レベルだからです。エージェントはコードを書くのは得意ですが、長期的な視点で考えることは必ずしもしません。そのコードは、再構築がうまくいかないのは確実です。でも、それは気にしないでください。この部分は将来的に解決します。しかし事実は、エージェントが私たちの多くを代わりに処理してくれているということです。私たちは毎日、これらの能力を最も効率的に活用する方法を考えなければなりません。

ある時点で、これらのエージェント化された作業により、あなたのバイナリファイルがコンパイルできなくなるほど巨大になる可能性があります。あるいは、スマートフォンにプッシュできなくなるほど巨大になるかもしれません。あなたはこの質問をしたことがありますか？「コンパイル可能な最大のバイナリサイズはどれくらいですか？」私は答えを知りませんが、Googleでは私たちはその限界に近づいており、一部のバイナリはすでにコンパイルできないほど巨大になっています。しかし、私たちはこの問題を解決できると信じています。しかし事実は、大規模化には多くの連鎖反応があり、規模の影響は至る所に及びます。

あなたはマイクロサービス技術スタックを使っているのかもしれないが、こう思っているかもしれない：「私のサービスはどれも小さいから、気にする必要はない」と。しかし、一つ問題がある：ネットワークトラフィックが10倍、サービス数が10倍、通信量が10倍になったとき、あなたは準備できているか？誰もが逃れられない。スケールの影響は至る所に存在する。

コードレビュー。すべてのコードを信頼性高くコンパイルできないと仮定した場合、あなたのコードレビューのプロセスはどうなるでしょうか？誰もがコードレビューを懸念しており、その理由はあります。この非常に人間的なプロセスに大きな圧力がかかっており、多くの場合、それがボトルネックになっており、人々はボトルネックになることを嫌います。圧力をかけると、彼らの行動は奇妙になります。コード量が10倍になると、10倍の大規模な変更か、10倍の変更が発生します。あなたのテクニカルリーダーは必要なレビュー速度を維持できるでしょうか？ほとんどのテクニカルリーダーは、10倍の開発者1日分のコード量すらレビューできません。

したがって、彼らはボトルネックにならないよう、プロセスを再編し、近道を取って、誰もがブロックされないようにします。誰もブロックしたいとは思わないからです。AI を活用して一部の問題を解決することは可能で、コードレビューの改善に AI を導入することもできます。しかし、これは部分的な解決にすぎません。なぜなら、チームメンバーがコードを書かなくなれば、コードに触れるのはレビューのときだけになり、その際の注意が十分でなければ、コードベースの進化を誰が見守っているのでしょうか？誰もいません。すぐに、あなたのコードベースは誰にも理解できない状態に陥ってしまいます。

トークン経済。トークンは高価であり、すでにご存知の方も多いでしょう。大規模な規模では、トークンは考慮しなければならない実際のコストです。会社の全員が10倍、あるいは100倍のトークンを使い始めた場合、どうなるでしょうか？もしあなたが不注意で1日で1か月分の予算を使い果たしてしまったら？トークンをどこに優先的に使うべきかを決断しなければならない場合、あなたはどこに優先的に投資すべきかわかっていますか？また、トークンがどこに流れているかを可視化していますか？

この単純なシステムの最初の数ノードだけで、すでに問題が見つかりました。また、いくつかの挑戦的な二次効果が生じることは明確です。

テストとバージョン管理

これまで、あなたのテストインフラがどれほどの計算リソースを消費しているかを見たことがありますか？Googleでは、私はこれまで自分のテスト速度に満足したことがありません。

バージョン管理に取り込まれるすべての変更はテストされる必要があります。しかし、それ以外にも、エージェントはテストを実行するのが好きです。なぜなら、テストによって自分自身の成果がどうだったかがわかるからです。そのため、エージェントは追加の作業量を生み出し、私の仕事量も増えました。では、10倍のコミット量とエージェントが行ったすべての作業を合わせると、現在どれだけのテスト計算リソースを消費しているでしょうか？

実際の状況はさらに悪化している可能性があります。Googleで観察されたのは、コードベースが成長するにつれて、依存関係グラフが線形ではなく二次関数的に増加するということです。したがって、コードベースが10倍になると、実行するテストは10倍ではなく、100倍、あるいは1000倍になる可能性があります。これは非常に興味深い課題であり、いずれはあなたの予算表に一行として現れます。現在、テストに必要な計算リソースのコストを心配していないのであれば、それこそ私がより心配する点です。なぜなら、それはおそらくあなたが十分なテストを実施していないことを意味し、そのエージェントが安全網なしであなたのコードベース内でYOLOしている可能性があるからです。

コンパイルとテストの問題が解決したとして、次にバージョン管理システムを見てみよう。最も人気のあるバージョン管理システムは、パフォーマンス最適化を目的としていない。それらは一貫性と順序付けに最適化されている。これが本来の仕事であり、完全な履歴を維持することであって、高速で動作させることではない。あなたのバージョン管理システムは、1分間に何回コミットを処理できるだろうか？きっとあなたの想像よりずっと少ない。必要な10倍のスピードには拡張できない。バージョン管理システムのパフォーマンスについて、最後に考えたのはいつか？Gitの開発者でない限り、おそらく一度も考えたことがないだろう。正直に言えば、バージョン管理のパフォーマンスを議論する必要に迫られているということは、何かが深刻にずれてしまっている証拠だ。私たちは開発者体験の最底辺にいる。だが、これがシステム全体の変化の結果だ：それはあなたのシステムのあらゆる隅々に現れて、「ねえ、気づいてる？」と問いかける。あなたが予期しなかったことが、やってきたからだ。

多くの小さなリポジトリを使ってバージョン管理の問題を解決しようとしている方々へ、何百、何千もの小さなリポジトリを運用してきた人に聞いてみてください。私は保証しますが、それはまったく新しい一連の課題にすぎません。AIが必ずしもこれらの問題を簡単にしてくれるわけではありません。

意外リスト

これまで私たちは、比較的見つけやすい容量型ノードだけを見てきました。つまり、ある数字に10を掛けて、良くなったり悪くなったりするかどうかを問うだけでした。しかし、予想外の課題が多数存在します。

戦略を検証する。今日の検証は多くのユニットテストといくつかの統合テストで構成されている。しかし、コードとサービスが10倍になる世界では、統合テストが品質戦略の最も重要な部分になる。今日の統合テスト手法に満足している人は何人いますか？私も満足していません。統合テストは本当に難しいです。今のところ、私が望む形で統合テストを実行できるツールはまだありません。

ブール値の論理積の問題。今日あなたはソフトウェアをリリースしようとしており、すべてのテストがパスし、すべてのブール値が緑になり、すべてが問題ない場合にのみリリースするという要件を設けている。これは理にかなっている。しかし、百万個のテストがあり、その基礎となるテストインフラストラクチャ自体が百万個のテストを実行する信頼性に問題を抱えている場合、どうなるか？ソフトウェアをリリースするにはすべてのブール値が真でなければならないという要件は、もはや実行不可能になるかもしれない。あなたはすべてのテストを実行できないため、どのテストを正しく実行すべきかを判断するための新しい戦略、おそらく統計的手法を必要とする。

巨大な変更。あらゆる部分を再構築し、言語やフレームワークを変更するのは確かに興奮する。しかし、数万行、数十万行、百万行に及ぶマージコンフリクトを管理できるようなワークフローと社会的契約は存在するのか？おそらくない。もし会社の全員が巨大な変更を自由に行えるとしたら、新しいワークフローストラテジーが必要になるだろう。

エージェント編集戦争。あるエージェントが変更を加え、別のエージェントが駆けつけて「いや、気に入らない、違う変更を加える」と言う。見ていると面白いが、両方にトークン料を支払っていることに気づくと話は変わってくる。

リリースの頻度。あなたは今日、顧客にどれくらいの頻度でリリースしていますか？毎日？それは良いことです。そうでない場合、問題があります：10倍以上のソフトウェアが生成され、それらはどこかに配置しなければなりません。毎日リリースしていないと、変更の規模が大きくなりがちです。私のSREの友人們は、非常に大きな変更は非常に恐ろしいと教えてくれます。それをしてはいけません。しかし、コードは価値を生むためにデプロイされる必要があるため、より頻繁にリリースしようとするかもしれません。それは良いことです。DORAの友人們は喜ぶでしょう。しかし、ある点で収益は逓減します。1秒ごとにリリースしても、それほど価値は得られないでしょう。コードは依然として増加し続け、より多くのリスクを生まないよう、どこに配置するかを理解する必要があります。

内部API。私はいつも同僚たちに言っていますが、あなたのすべてのAPIが突然公開されてしまったのです。エージェントはあなたに相談することなく、APIを見つけて直接呼び出します。アクセスできるものは何でも使用します。私が保証します。もし内部インターフェースや内部データセットをパブリックAPIのようにしっかりと保護していなかった場合、エージェントはあなたが決して見られたくなかったものを発見してしまうでしょう。

ジェヴォンズのパラドックス。ジェヴォンズは、資源が安くなり、効率的になればなるほど、私たちはそれをより多く使うと述べた。トークンの爆発的拡大は、その生きた例だ。私たちはそれらをあらゆる場所に導入しており、これは私たちの働き方や仕事の捉え方を変革している。これまで見えなかった生産性の労働に価値を付与しているが、これは私たちの行動にどのような影響を与えるだろうか？私はまだ知らない。

ロールバック。なぜ今日のロールバックが基本的に実行可能なのか、你知道ですか？それは、あなたがソフトウェアをリリースする速度が、本番環境で問題を検出する速度よりもやや遅いからです。もし、問題を検出する前に非常に非常に速くリリースできるなら、あなたのロールバックの姿勢はどうなるでしょうか？すべてのロールバックは、積み重なった複数の互いに矛盾する変更に対処しなければならなくなります。したがって、ただ速くリリースするだけでは不十分です。ロールバックという重要なセーフティバルブを含む、全体のシステムを考慮する必要があります。ちなみに、トークンエンジンをどこに配置するかには注意が必要です。もし、あなたのロールバックプロセスが特定のエージェントに十分な容量があることを前提としており、以前に誰かがそのエージェントのトークン予算を使い果たしたために、現在ロールバックが不可能になっているとしたら、それはおそらく良いことではありません。

誰もがビルダーだ。会社で嫌いなツールの代替品を、自分で作ってみたことがあるだろう。それを、会社の全員とすべてのツールに掛け合わせてみよう。全員がまったく異なるツールを使い始めたとき、会社の社会的構造はどうなるか？もしあなたが運良く統一されたデータ基盤を持っていて、すべてのデータが同じ場所に集まるなら、まだマシだ。しかし、そうでなかったら？誰もがビルダーであることはクールだが、全員が作成したすべてのものを維持しなければならなくなると、話は変わってくる。

技術リーダーシップの短期集中講座。技術リーダーになるのに時間がかかるのは、直感、判断力、専門知識を身につけて意思決定を支える必要があるからだ。チームを率いるとき、あなたのミスの影響範囲は、単独で行動するときよりもはるかに広くなる。新卒が、五十のエージェントを呼び出せる環境に立ちながら、直感や判断力がまったくない状態で入ったら、何が起きるだろう？どうやって六个月で十年分の経験を教えることができるのか？私は知らない。

人間の注意は、私たちが持つ最も貴重なリソースです。現在、ノイズが非常に多く、多くのエージェントや多くのものが私たちの注意を奪い合っています。私たちはこの問題を管理する方法を見つける必要があります。かつては、私たちが混乱を引き起こす能力が、注力できる能力を超えることはありませんでした。しかし、今はもはやそうではありません。

これらは多く聞こえるかもしれませんが、それはシステム内ではすべてが関連しているからです。先ほど挙げたすべての課題は、システムの1つのノードだけを見て解決することはできません。全体のシステムを見なければなりません。

エージェント化開発に適応するため、私たちはすべて、システム的な思考を継続的に身につける必要があります。システムを考えるとき、以下に注目すべきです：物事がどのように大きくなるか、時間とともに変化する効果、因果関係の流れ方向、どのノードがすべての近隣と対話しているか、エマージェンスはどのように見えるか、どこからともなく現れるものは何か。インセンティブメカニズムは？社会的・技術的なもの、容量、フィードバックループ、ボトルネック——これらがシステム分析のツールです。

複雑に見えるかもしれませんが、本当に必要なのは二つの質問だけです：なぜ（Why？）ともしも（What if？）。なぜ私たちの統合テストはこれほど少ないのですか？もしユニットテストよりも統合テストの方が多くあったらどうなりますか？なぜこれらの特定の言語を使用しているのですか？もしAIがすべてのコードを書いたらどうなりますか？

「なぜ」は、システムの核心に深く入り込み、その動作原理を理解するためのドリルです。皆さんは「なぜ」を尋ねることにとても得意ですが、「もしも」の方がより難しい部分です。「もしも」は、これまで非常に優れた設計だと信じてきた実践を手放す必要がある場合、恐れを伴うことがあります。テストをしなければどうなるでしょうか？まったくテストを書かなければどうなるでしょうか？あまり極端には行かないでください。しかし、それを許容すれば、「もしも」は非常に興奮させるものにもなり得ます。

AIは増幅器であり、方向ではない

AIは増幅器である。この考えは、DORAの友人たちから来たもので、彼らが昨年発表したAI開発レポートでは、本当に物事を理解したチーム間に共通する関係性が見られた：彼らはAIを増幅器として活用する方法を理解したのだ。

AIはあなたに更多のテスト、更多のドキュメント、更多のコードを提供できるが、更多の混乱ももたらす。拡大は方向ではなく、振幅である。AIはそれらがどこへ向かうかには関心がない。ただ、更多を提供するだけだ。DORAが真正に発見したのは、基本がしっかりしているチームが、この拡大効果を有用な方向に導くことができることである。

これは次のような問題を引き起こします：あなたは自分の基本的なスキルに自信がありますか？あなたの会社の意思決定文化はどのようなものですか？それを改善するために何ができますか？技術戦略は？開発者の生産性を誰かが注目していますか？今日、組織内の人がどれほど協力できていますか？セキュリティ状態は？コードの健全性、リリースの清潔さ、信頼性は？AIはデフォルトでいかなる問題も解決してくれません。あなたの実践が優れていれば、それを強化します。しかし、十分でなければ、さらに多くの問題を引き起こすだけです。

しかし、基礎がしっかりしていても、私たちはまもなく本物の旅を経験することになります。2030年までには、今日の開発者エコシステムが、2001年の私たちにとってどれほど遠く感じられたかと同じくらい遠く感じられているだろうと私は推測します。2001年にはまだCD-ROMでソフトウェアをリリースしていたのが、2030年にはそのくらいの距離を感じているかもしれません。

基本力を着実に高める過程で、途中で考えてみてほしいことが4つあります。

第一に、インフラストラクチャの容量です。どれだけのリソースを割り当てられるかを把握していないと、AIを導入したり、計算リソースを展開したりすることはできません。これらを適切に追跡する方法が必要です。

第二に、検証戦略を確認してください。検証されていないソフトウェアを公開してはいけませんし、すべきでもありません。しかし、検証戦略は変化します。今こそ明確に考えるべき時です。統合テストが最も重要な武器となりますが、あなたにはまだ適切なツールが揃っていない可能性があります。

第三に、隔離です。さまざまな目的のために多くのコードが作られ、その中にはこれまでコードで実現されなかった目的もあるでしょう。それは問題ありませんが、面白いプロトタイプのコードが本番環境に流入するのは避けたいです。楽しみの要素が収益を生む部分に影響を与えないようにしましょう。

第四に、抽象化です。開発者が悪い選択をしないようにするために、私たちは抽象化を構築します。これが、ライブラリやフレームワークがある理由です。誰もがWebサーバーをゼロから作ることはありません。エージェントに多くの意思決定を任せると、同様の結果を招きます。そのため、エージェントが従うべき良い抽象化が必要です。悪い選択肢を与えないでください。

あなたはまた一つのことを受け入れなければなりません：エンジニアリングの実践は神聖なものではありません。実践は変化しますが、原則が重要です。これは言うは易く行うは難しです。あなたのチームがなぜこのような方法でソフトウェアをテストしているのか、またはなぜリリースプロセスがこのように機能しているのかを、これまで真剣に考えたことがなければ、それを進化させることはできません。原則を理解することで、この10倍の瞬間を乗り越える力と自信を得られます。

現在はソフトウェアエンジニアにとって魅惑的な時代です。私たちの仕事のあらゆる側面が再定義されており、これまで以上に創造性が求められています。コンテキスト管理、トークン経済学、モデルのドリフトといった課題に対応するためのスキルが必要であり、創造性が不可欠です。すべてを最適化する誘惑に過剰に囚われず、探求を促す必要があります。

ずっと気になって眠れない問題がある。それは最適化だけでは解決できない：コードベースが成長するにつれて、どのようにしてそれに対する知的統制を維持するのか？知的統制とは、人間が目の前のものを論理的に推論できるかどうかを意味する。我々はこの戦いに少なくとも15年間敗北し続けている。私たちの最大のシステムは、もはや誰一人として理解できる規模を超えている。信じられないなら、実験をしてみよう：チームの全員にシステムアーキテクチャ図を描かせて、どれだけ多くの異なるバージョンが出てくるか見てみればいい。

私たちの多くのソフトウェアシステムは非常に脆弱で、1行の悪いコードや誤った設定フラグだけで数百万行のシステムを破壊できてしまいます。この脆弱性により、変更を加える前に必ず慎重に考える必要があります。しかし、AIに関して私は非常に興奮するアイデアを持っています。それは、継続的に更新され、ほぼインタラクティブなアーキテクチャ空間であり、そこに質問を投げかけることができるというものです。もしこの容量を東海岸に移したらどうなるでしょうか？ユーザーの成長が突然40%急増したらどうなるでしょうか？今日の、たとえ中規模のシステムであっても、このような問いに答えることは機能的にほぼ不可能です。変数が多すぎます。しかしAIは膨大なデータセットを理解できるため、ここには掘り起こせる価値があると私は考えています。

この質問が好きな理由は、単にコードマシンをより速く回すだけでなく、すでに構築したものに対する理解をどう深めるかを問いかけているからです。

変化は非常に速く、あなたたちの多くが経験したよりも速く起こっています。今、あなたたちができることの一つは、苦しみている人々を助け、まだ状況を理解していない人々に手を差し伸べることです。私たちはすべて、異なる速さで進み、異なる方法でこの変化に対応しています。自分が遅れていると感じるのは、とても容易なことです。

経験豊富なエンジニアたちは、メンターになってください。つまずいている人を見つけ、手助けしてください。AI開発ワークフローを理解したなら、それを他の人に共有してください。これは特別な秘密ではありません。テクニカルリーダーの皆さんは、自社におけるソフトウェアエンジニアリングの方向性を導くために積極的に関与しなければなりません。ソフトウェアの品質や設計にこだわるなら、その声を上げてください。これらのことを実行するのは、まさにここにいる皆さんの役割です。あなたの上司がやるとは限りません。

開発者エコシステムを生き物のような生態系と捉えるなら、私たちはこれまで、まるで特別な生命形態を育てるように、すべての木の枝に付いた1枚1枚の葉に目を光らせてきました。しかし、そう遠くない将来、私たちが管理するのは1本の木ではなく、全体の森になります。森を管理するには、1本の木に注目するのではなく、森全体を一つの生態系として捉える必要があります。

システム的な変化には、あらゆる場所、あらゆる事物に同時に起こるという特徴があります。その規模が大きすぎて、何にも手が届かないように感じられます。今、あなたは、毎週押し寄せる変革の波の中で、何ひとつ自分を支えてくれるものがないと感じているかもしれません。しかし、先ほど明らかにしたように、システムの中ではすべてが関連しており、小さな行動が大きな結果を生む可能性があります。

表面の様子とは関係なく、AIへの移行は経営層だけの領域ではありません。この転換点において、現場のソフトウェアエンジニアとして、あなたはソフトウェアエンジニアリングの未来を決定する中心にいます。ツールからワークフロー、エンジニアリング実践からエンジニアリング文化まで、システムがどのように動いているかを理解できれば、レバレッジを見つけることができます。あなたが持つ自律性は、思っている以上に大きいのです。この自律性を活かして、あなたの組織、チーム、そして自分自身の未来を切り開いてください。