※本記事は、Adam Bender氏(Google)によるGoogle I/O 2026のセッション「Software engineering at the tipping point」の内容を基に作成されています。本セッションは、システム思考を用いて開発者エコシステムがソフトウェアシステムの進化をどのように導くかを学び、AI主導のソフトウェア開発がもたらすシステム的な影響への理解を深め、業界に訪れる刺激的な変化への備え方を考える内容となっています。動画の詳細情報は https://www.youtube.com/watch?v=2n41YjR5QfU でご覧いただけます。本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。また、Google I/O 2026のProfessional Developmentセッション一覧(https://goo.gle/professional-develope...)や、Google for Developersのチャンネル登録(https://goo.gle/developers)もあわせてご参照ください。
1. 導入:システム思考とソフトウェアエコロジー
1-1. システムとエコシステムの定義
皆さん、こんにちは。私はAdam Benderと申します。今日は「ソフトウェアエコロジー」という、おそらく多くの方が耳にしたことのない言葉についてお話しします。この考え方は、私たちが日々働いている開発者エコシステムにAIがどのような影響を与えているのかを理解する手がかりになると考えています。
2026年の私たちの仕事は、2020年に想像していたものとはまったく違う姿になっています。もし2020年の自分に今の状況を説明したとしても、とても信じてもらえなかったでしょう。この変化がどこへ私たちを連れて行くのかを考えると、圧倒されそうになることがあります。私は未来を予測することはできませんが、今日の開発者エコシステムをありのままに研究することで、私たちが探している答えの多くに、思っているよりずっと近づけると考えています。ソフトウェアエコロジーという考え方は、業界が置かれているこの特別な瞬間を捉えるための、まさに最適なレンズを与えてくれます。
本題に入る前に、まずシステム思考について少し掘り下げておきたいと思います。システムとは、一定のルールに従って作用し合う、相互に関連した要素の集まりが統一体を形づくったものです。これだけ聞くと難しく感じるかもしれませんが、実はとても身近なものです。例えば、皆さんが今日ありがたいと思っているであろうエアコンもシステムの一種です。適温を知っているサーモスタットがあり、温度を上げ下げするHVAC(空調設備)があり、そして部屋があります。そして温度が適正になると、信号が止まります。これがシステムです。ソフトウェアエンジニアであれば、システムについて考えることには慣れているはずです。私たちはシステムを設計し、構築し、運用しています。しかし、システムを扱ってきた中で誰もが学ぶことのひとつは、あらゆるものがつながっているということです。これは今日、何度も繰り返し出てくるテーマになります。
次に、エコシステムという特別な種類のシステムについてお話しします。エコシステムとは、環境と共進化する相互依存的なアクターの動的なネットワークであり、創発的なふるまいと分散的な主体性によって特徴づけられるものです。エコシステムは複雑であり、複雑な構成要素から成り立っています。その構成要素同士は深く結びついており、それぞれが主体性を持ち、意思決定を行い、行動することができます。そして重要なのは、環境そのものがそのシステムの一部だという点です。環境とシステムを切り離すことはできません。つまりエコシステムは、複雑適応系(CAS)と呼ばれる種類のシステムでもあります。複雑適応系は、時間の経過とともに成長し、変化し、進化していく能力を特徴としています。魅力的なシステムはたいてい複雑適応系です。そして複雑適応系は、創発という性質も持ち合わせています。創発的な特性とは、システムを構成する個々の要素をいくら見ても見えてこないものであり、システム全体が組み合わさって初めて見えてくるふるまいのことです。この絶え間ない変化と学習、そして創発性が組み合わさることで、エコシステムの中で何が起きているのかを把握することを非常に難しくしています。
エコシステムと聞くと、多くの方はこの会場に入る前まで、自然の中の理想的な風景を思い浮かべていたのではないでしょうか。正直、私も今すぐそこにいたいくらいです。しかし、皆さんの社内の開発者環境もまた、ひとつのエコシステムなのです。そこにはツールやサービスがあり、意見や成し遂げたいことを持つ複雑なアクターである人々がおり、さらにビジネス上の制約もあります。これもまたシステムであり、しかも特別な種類のシステムです。
1-2. ソフトウェアエコロジーの定義と社会技術システム
私たちの開発者エコシステムは、社会技術システムと呼ばれるものにあたります。社会技術システムとは、簡単に言えば人と技術から成るシステムのことです。社会技術システムは非常に複雑です。なぜなら、まず技術という要素があり、そこに人という要素が混ざり合うからです。皆さんはおそらく、社会技術システムに関する知見をすでにどこかで耳にしているはずです。コンウェイの法則をご存じの方は多いと思います。簡単に説明すると、組織は自らの内部のコミュニケーション構造を反映した技術を構築する、というものです。もう少しくだけた言い方をすれば、4つのチームでコンパイラを開発すれば、4パスのコンパイラができあがる、ということです。実際そうなるものなのです。コンウェイの法則の核心は、私たちが構築する技術のあり方が、それを構築する組織の構造と切り離せないという観察にあります。組織のあり方が、何が作られるかを形づくっているのです。
もちろん、開発者エコシステムに影響を与えるのは組織構造だけではありません。組織の価値観や文化も、同じくらい大きな影響を及ぼします。皆さんのエコシステムは、組織がインセンティブを与えているものをそのまま反映して構築されます。そしてエンジニアリング文化こそが、開発者エコシステムを取り巻く環境そのものをつくり出しているのです。社会技術システムという考え方を一度知ってしまうと、ソフトウェア開発のあらゆる場面でそれを見出せるようになります。アーキテクチャから、ポストモーテムの文化、コードレビュー、セキュリティポリシーに至るまで、あらゆる場所に存在しています。私たちが構築するものや、それをどのように構築するかという選択そのものが、私たちが何を大切にしているかを映し出す鏡なのです。もし私たちが意識的であれば、この知識を使って自分たちの価値観を増幅させ、それを構築物に組み込み、望む成果を後押しすることができます。
ここまで来て、ようやく皆さんにソフトウェアエコロジーの定義をお伝えできる準備が整いました。ソフトウェアエコロジーとは、ソフトウェアを生み出す社会技術的なエコシステムを、全体論的に研究する学問だと私は定義しています。ここまでの内容は少し抽象的に感じられたかもしれませんが、それで問題ありません。ここからは、実際の具体例としてGoogleの開発者エコシステムについてお話ししていきます。
2. 事例研究:Googleの開発者エコシステム
2-1. Googleのエコシステムの背景と特徴
ここからは、実際の具体例としてGoogleの開発者エコシステムについてお話しします。Googleは非常に大規模で、そして正直に言えば、いくぶん複雑な開発者エコシステムを持っています。なぜなら、過去25年間にわたって、私たちは本当に卓越した能力を進化させてきた一方で、そう、少なからぬ複雑さも積み重ねてきたからです。あらかじめお断りしておきますが、私がGoogleについて話すのは、単に私自身がそこで働いていて、自分が最もよく理解している開発者エコシステムだからです。皆さんに「Googleがやったことをそのまま真似すべきだ」と伝えたいわけではありません。それは皆さんにとって良い結果をもたらさないでしょう。皆さんは違う会社に所属し、違う場所にいて、Googleとは異なるトレードオフを抱えているはずです。Googleのようなどんなエンジニアリング組織も、その時々のニーズに合わせて数多くの選択を重ねてきました。皆さんの状況はそれとは異なります。
数年前、私たちは社内の働き方を伝えるための本を書きました。社内では「フラミンゴブック」と呼んでいます。この本を書いたのは、Googleが実際にどのように機能しているかを人々に理解してもらうためでした。バージョン管理やテストといった技術的な話題にはこの本の半分を割いていますが、残りの前半はすべてエンジニアリング文化について書かれています。なぜエンジニアリング文化にそれほど多くのページを割いたのかとよく聞かれるのですが、実際のところ、Googleが持つ文化を理解しなければ、私たちがなぜそうした技術的な選択をしてきたのかを理解することはできません。文化と技術は互いに結びついているのです。
Googleを特徴づける文化的な要素をいくつか簡単にご紹介します。まず、私たちは徹底してエンジニアリング主導です。重要な意思決定の場には、常にエンジニアが同席しています。透明性も非常に重視しており、できる限り多くのドキュメントやコードを公開しようとしています。人を助けることも奨励しています。実際、Googleを退職した人に話を聞くと、同僚の助け合いの精神をもっとも印象深い点として挙げる人が多いです。コードレビューは、採点の場ではなくメンタリングの機会として位置づけています。標準化も非常に重視しており、継続的改善という考え方を大切にしています。ブレームレス(非難のない)ポストモーテムの文化も根づいており、英雄的な奮闘よりも持続可能性を、そして労苦よりも自動化を優先するという価値観を持っています。これらすべてを常に完全に達成できているわけではありませんが、これが私たちが文化的に目指している姿です。
技術面では、皆さんもおそらく読んだことがあるであろうモノリシックなリポジトリ、いわゆるモノレポを採用しています。すべての変更が毎回トランク(主幹)に反映される、トランクベース開発を行っています。Googleでバイナリをビルドするとき、ほぼすべてのコード行がソースからビルドされます。これはかなり驚くべきことです。全社共通のビルドツールチェーンがあり、誰もがそれを使っています。グローバルなテスト自動化基盤もあり、一つの場所で1日に数十億件ものテストを実行しています。最後にグリーン(全テスト通過)だった状態を示すグローバルなシグナルもあり、社内のシンプルなウェブサイトを一つ見るだけで、どのビルドがどんな状態かを把握できます。統一されたコンピューティング環境も整っており、「自分のマシンでは動くのに」という状況はほとんど起こりません。意見を持った(=方向性が明確な)開発者向けフレームワークと、少数のコア言語も用意しています。こうした文化と技術が組み合わさることで、Googleという存在が形づくられているのです。片方だけを理解しても、もう片方を理解することはできません。
2-2. シェアード・フェイトという原則
もし、私たちを暗黙のうちに、あるいは時に明示的に導いてきた原則を一つだけ挙げるとすれば、それは「シェアード・フェイト(共有された運命)」と呼ばれる考え方です。シェアード・フェイトとは、あるエコシステムとその構成要素同士が、どれほど密接に結びついているかを表す言葉です。シェアード・フェイトの度合いが高いエコシステムでは、一つの構成要素が他のすべてに影響を及ぼします。開発者エコシステムにおいて、シェアード・フェイトは技術的な選択であると同時に、社会的な選択でもあります。単に全員に同じ技術を使わせるだけでシェアード・フェイトが得られるわけではなく、その技術をどのように管理していくかについての社会的な合意も築く必要があります。
Googleにおけるシェアード・フェイトは、モノリシックなリポジトリから始まっています。AndroidやChromeなど一部の顕著な例外を除き、Googleのすべてのコード行は一つの共有リポジトリに置かれています。すべてがトランクにコミットされます。ブランチはありません。バージョンもありません。すべてが一箇所にあるのです。このようなシェアード・フェイトのおかげで、あるファイルにセキュリティパッチを一つ適用すれば、1週間以内に会社のすべてのアプリケーションにそのパッチが適用されていることを確認できます。これはまさに超能力のようなものです。適切な場所に置かれた10行のコードが、100億行のアプリケーション・システムソフトウェアにパッチを当てることができるのです。これは非常に印象的なことだと思います。
ただし、シェアード・フェイトは常に良いものというわけではありません。シェアード・フェイトは一つの選択であり、それがあまり意味を持たない場面もあります。例えば本番環境では、一つのサービスが他のすべてのサービスを道連れにしたり、一つのクラスタが地域全体に影響を及ぼしたりすることは避けたいと考えます。そのため、Googleは連鎖的な障害を引き起こすような危険な種類のシェアード・フェイトを持たないよう、特に力を入れて取り組んできました。繰り返しになりますが、シェアード・フェイトはトレードオフです。それをどこに適用すべきかを見極め、自分たちにとってうまく機能するようにする必要があります。
2-3. ラージスケールチェンジ(LSC)
私たちのシェアード・フェイトな環境が生み出した、もっとも興味深い創発的特性の一つが、ラージスケールチェンジ(LSC)という考え方です。AIが登場するはるか以前から、Googleの社内ツールは、一人の開発者が文字通り数百万行のコードを変更することを可能にしてきました。しかもその開発者は、変更したコードを二度と見ることもなければ、その中身についてほとんど何も知らないかもしれません。私たちはそれを自動的に実現できるツールを構築してきました。しかも、それを少なくともこの15年間にわたって続けてきています。この能力のおかげで、私たちは時間をかけてモノレポを進化させることができています。言語やフレームワークを更新することができ、これこそが社内環境を停滞させないための原動力になっています。もしこの仕組みがなければ、私たちは今のGoogleにはなれていなかったと言っても過言ではありません。この仕組みを支えるツールに携わっている人たちは、この会社を必要な速度で動かし続けるための、いわば縁の下の力持ちのような存在だと言えるでしょう。
ラージスケールチェンジについて理解するには、それを可能にしている私たちのエコシステムの文化的な側面と技術的な側面の両方を理解する必要があります。例えば、こうした変更を可能にするには、全社的なテスト文化が必要です。誰もがテストを書いていなければ、私はこうした変更を行うことができません。テスト結果を確認できる場所が一つに定まっている、単一のプラットフォームも必要です。共通のビルドツールがあることも重要で、私がビルドしても皆さんがビルドしても、同じ結果が得られるようにする必要があります。標準化されたライブラリ群も必要です。そうでなければ、何かを入れ替えるたびに、どのバージョンのライブラリが自分には合っていて、皆さんには合っていないのかを探し回ることになってしまいます。標準化されたコードレビューも必要ですし、モノレポ自体の透明性も必要です。そうすることで、どのコードを変更すべきかを把握できるようになります。LSCはまさに、Googleにおける「自動化は労苦に勝る」というエートス(精神性)の究極的な体現であり、それはエコシステム全体があってこそ初めて可能になっているのです。開発者環境のどこか一箇所だけを指して「これがLSCを可能にしている」と言うことはできません。すべてが結びついた結果として、LSCは実現しているのです。
3. 自組織のエコシステム理解と「10倍」という課題
3-1. 自組織のエコシステムを把握する問い
皆さんが働いているどんな開発者エコシステムにも、こうした創発的な特性が存在しています。それはたいてい、その職場に固有のものだと感じられる要素です。なぜなら、それは皆さんがどのように働きたいかを形づくるために積み重ねてきた、無数の選択が織りなす結果だからです。すべてのエコシステムには、こうした固有の何かがあります。Googleにはラージスケールチェンジがありますが、皆さんの組織には別の何かがあるはずです。Googleの開発者エコシステムは、私たちに固有のエンジニアリング文化に組み込まれる形で、独自のトレードオフの組み合わせを生み出してきました。それらは私たちの技術的・事業的なゴールに資するものです。
とはいえ、Googleのエコシステムも、他のあらゆるエコシステムと同様に、すべてのタスクで卓越しているわけではありません。私たちは極端なスケール、セキュリティ、パフォーマンスを最適化することを選んできました。そして、それが時に開発者の生産性を犠牲にすることになっても、たいていはそれを受け入れています。それは私たちのエコシステムにおいて、あえて受け入れているトレードオフです。一方、例えば5人規模のスタートアップの開発者エコシステムはまったく違う姿になるはずですし、それはそれで問題ありません。5人規模のスタートアップでは、スピードと機動力こそが何よりも重要な要素になります。皆さんの多くは、5人からGoogleの20万人の間のどこかのエコシステムに身を置いているはずです。皆さんが行っているトレードオフに注目することは非常に重要です。なぜなら、そのトレードオフを見ることで、その組織が本当に大切にしている価値観が見えてくるからです。「何を大切にしていると言っているか」ではなく、「実際に何を大切にしているか」です。そして、その価値観を理解できて初めて、今まさに起きている変革を自分たちの手で形づくっていくことができるようになります。私たちは皆、今まさに大きな変革のただ中にいますから、自分たちがどこへ向かっているのかを理解しておくことは、きっと役に立つはずです。
ソフトウェアエコシステムという概念について、ここまでで少し輪郭がはっきりしてきたと思います。ここからは、部屋の中にいる「トークンを食い尽くす象」の話をしたいと思います。つまり、AIファーストな開発者エコシステムとは、実際のところどのような姿になるのか、という問いです。ゼロからグリーンフィールドのエコシステムを構築できれば理想的ですが、皆さんの誰一人として、そんな贅沢は許されていないはずです。皆さんは全員、今のシステムのあらゆる部分を置き換えている最中も、これまでどおりソフトウェアを出荷し続け、日々の仕事を続けなければなりません。それは決して簡単なことではありません。皆さんの会社は、皆さんが価値を届け続け、何も壊れないようにしてくれることを期待しています。
そこで、何も壊さないために、一つ質問をさせてください。皆さんは今日、自分たちの開発者エコシステムをどれだけ理解していますか。その全体像を地図に描くことはできますか。すべてのパーツがどこにあるか把握していますか。技術的な部分だけでなく、社会的な部分についても、です。自分たちのエコシステムが何から成り立っているか、列挙できますか。組織内の他の人たちは、それをどれだけ理解していますか。強みや弱みは何ですか。ボトルネックはどこにありますか。制約されている部分と、自由に動ける部分はどこですか。どんな選択肢(オプショナリティ)を持っていますか。自分たちのエコシステムの中で、どんな創発的な特性を見たことがありますか。そして、おそらくもっとも重要な問いとして、もし自分たちのエコシステムが今後18か月で突然10倍から15倍に成長しなければならなくなったとしたら、真っ先に何が壊れるか分かりますか。この最後の問いについて重要なのは、私たち全員がこれに、すぐに答えを出さなければならないということです。なぜなら、地球上のあらゆる開発者エコシステムが、今まさに根本的な変革の只中にあるからです。まだ皆さんのところまで波が届いていないかもしれませんが、確実にやって来ます。あらゆる開発者エコシステムが、この「10倍」という瞬間と向き合わなければならなくなります。この状況から逃れる方法があればよいのですが、残念ながら、それは避けられずにやって来ます。これは信じられないほど刺激的な時代であると同時に、いくぶん混乱を伴う時代でもあります。
3-2. 10x成長という課題
過去25年間かけて意図的に進化させてきたすべてのトレードオフが、今まさに再調整されようとしています。おそらくこの会場にいる登壇者のほぼ全員から、何らかの形でこの話を聞いたことがあると思います。私たちはまだ、未来がどうなるのか分かっていません。今まさにそれを解き明かそうとしている最中です。生産性が10倍、あるいは100倍になるだろうと予測する人たちもいます。私たちは物事を「桁」単位で測るようになっています。それはとても大きな変化です。突然、10倍成長という問いは単なる思考実験ではなくなり、皆さんと皆さんの会社にとっての「コードレッド」的な瞬間になっています。今日でなくとも、確実に今後12か月以内には、この問いに向き合わなければならなくなるでしょう。
ここで先に進む前に、ぜひ強調しておきたいことがあります。それは、「コードを10倍速く生成すること」と「エンジニアリングを10倍速くすること」の間には大きな違いがある、ということです。これらはまったく別のものです。実際、Googleでは、エンジニアリングとは「プログラミングを時間軸で積分したもの」だとよく言っています。しかし現実には、私たちはプログラミングそのものを大幅に高速化しつつあります。コードを生み出す機械のスピードを上げているのです。だからこそ私たちは、その「コードを生み出す機械」の周りで、どうエンジニアリングを組み立て直せば、顧客に本当の成果を届けられるのかを考えなければなりません。
この生産性の伸びをどこまで押し上げられるのか、まだ誰にも分かりません。正直、私にも分かりません。来週にでも成長が止まる可能性もないとは言えませんが、私はそうは思いません。一つだけ確かなのは、ここから先、私たちは伸び続けていくだろうということです。問題は、今日私たちがやっていることが、10倍の速度ではうまく機能しないだろうということです。かなり自信を持って賭けてもいいのですが、皆さんが今ソフトウェアを構築しているやり方、そして私自身がソフトウェアを出荷しているやり方は、10倍や100倍の速度ではおそらく通用しません。何かを変えなければならないのです。
それでは、標準的な開発者エコシステムを見てみましょう。単純化はしていますが、ここに挙げる用語の多くは、皆さんにも馴染みがあるはずです。ただ、皆さんがより見慣れた形、つまり複雑なグラフとして表現してみます。生産性が10倍になった世界、というより、活動量が10倍になった世界では、何が変わらなければならないのでしょうか。まずは、コードをコードベースに取り込むことに関連するノードから見ていきます。ここでは、あえてテストとバージョン管理は除外しています。それらについては、この後すぐに取り上げます。
4. 「10倍」の思考実験:コード生成への影響
4-1. ソースコードとビルドシステムへの影響
まずはコードを書くこと、つまりソースコードの記述から見ていきましょう。誰もがコードを書くのが速くなれば、当然コードの量も増えるはずです。これは、あまり良い兆候ではありません。ここで、Jeff Atwoodの古い言葉を思い出していただきたいと思います。「ソフトウェアは負債である」という言葉です。つまり、いきなり10倍のコードが生まれるということは、10倍の負債が生まれるということでもあります。私たちは、あまり良い状況にいるとは言えません。
ちなみに、皆さんもお気づきのとおり、ただトークンを大量に配って「あとは頑張って」と言うだけでは済まされません。ですから、皆さんが再教育(リトレーニング)にきちんと投資していることを願っています。皆さんは投資していますよね。自分たちのエンジニアリングの実践方法が、どこにドキュメント化されているか把握していますか。もし必要になったとき、それをどう進化させればよいか分かりますか。これは、家に帰ってから考えてみる価値のあることです。
次に、ビルドシステムについても手短に見ていきましょう。コードが増えれば、少なくともコンパイル時間は長くなります。システムが大きくなれば、コンパイル時間も伸びる。これはまさに、私たちが望んでいなかった事態です。皆さんの会社で、コンパイルが遅いという不満を誰も口にしたことがないとは思えません。そして、これからそのコンパイルはさらに遅くなっていきます。もしエージェントが多くの作業を担うようになれば、それはコンパイルの回数そのものが増えることを意味します。つまり、コードベースが大きくなるだけでなく、コンパイルの頻度そのものも増えるのです。コンパイルは時間的にも計算資源的にも、決して無料ではありません。これまでコンパイルにどれだけの時間を費やしているか意識したことがなかったかもしれませんが、規模が10倍になれば、間違いなくその影響を実感することになるはずです。
4-2. コード設計・バイナリ・ネットワークへの影響
次に、そうして生まれたコードの設計についても考える必要があります。皆さんは、疎結合を促すための適切なエージェント向けスキルを持っていますか。素早く安全に機能を組み合わせるための、適切なサーバーフレームワークは用意されていますか。そもそも、自社でウェブアプリケーションがどれだけ多様な方法で提供されているか、把握していますか。実際にどれだけ多くの異なるサーバーフレームワークを運用しているか、ご存じでしょうか。正直に言うと、私自身も把握できていません。エージェントがコードのほとんどを書くようになったとき、コンポーネントの再利用性をどう管理していくのでしょうか。もしかすると、それは大した問題にならないと踏んでいる方もいるかもしれません。しかし、エージェントが書くコードは、書くこと自体は簡単でも、皆さんにとって保守しづらいコードになりがちだということに、驚かないでいただきたいと思います。それが、今のところの一つの基準になっているようです。エージェントはコードを書くことには長けていますが、私たちのように長期的な視点で物事を考えているとは限りません。そうして生まれたコードは、きれいに整理された(well-factored)ものにはならないでしょう。それは仕方のないことで、いずれ解決していく問題だとは思いますが、実際のところ、エージェントは今、私たちのために多くの作業をこなしてくれています。そして私たちは、その作業を日々どう最も効果的に活用していくかを考えていかなければなりません。
そしてある時点で、こうしたエージェントによる作業の積み重ねによって、バイナリが大きくなりすぎてコンパイルできなくなる、という事態が起こり得ます。あるいは、大きくなりすぎてスマートフォンに出荷できなくなるかもしれません。皆さんは、コンパイル可能な最大のバイナリサイズがどれくらいか、考えたことがあるでしょうか。私自身、正確な答えは分かりませんが、Googleの一部の領域では、すでにその限界にぶつかりつつあることは知っています。実際、いくつかの箇所ではバイナリが大きくなりすぎて、コンパイルできなくなっているのです。いずれ解決する自信はありますが、大きさというものには、様々な結果がついて回るというのが現実です。スケールはあらゆるところに影響を及ぼします。
もしかすると、皆さんの中にはマイクロサービス型のショップで仕事をしていて、「なぜそんな大きなサービスを作る必要があるのか、うちのサービスは全部小さいのに」と思っている方もいるかもしれません。それはそれで結構ですが、では一つ質問させてください。ネットワークトラフィックが10倍になったら、サービス数が10倍になったら、サービス間のやり取り(チャッター)が10倍になったら、どうなるでしょうか。ネットワークトラフィックが10倍になる準備はできていますか。誰もこの影響から無傷ではいられません。スケールの影響は、あらゆるところに及ぶのです。
4-3. コードレビューのボトルネック化
さて、仮にこのコードを確実にコンパイルできないとしましょう。そのとき、コードレビューのプロセスはどうなるでしょうか。今、誰もがコードレビューについて懸念を抱いていますが、それには十分な理由があると思います。私たちは、この非常に人間的なプロセスに、大きなプレッシャーをかけようとしています。そして多くの場合、それはボトルネックになりつつあります。人というものについて私が知っている一つのことは、彼らはボトルネックになることを好まないということです。プレッシャーをかけられると、人は妙な振る舞いをするようになります。コードが10倍に増えれば、次の二つのうちどちらかが起こります。変更のサイズが10倍になるか、変更の件数が10倍になるか、です。それは、コードレビューを担当する人たちにとって何を意味するでしょうか。皆さんのテックリードのほとんどは、こうした「10倍の生産性を持つ開発者」を、1日にたとえ5人分でもレビューし続けられるだけの速度を維持できないだろうと、私はかなりの自信を持って賭けることができます。それは非常に大きな負荷です。
そうなると、彼らはボトルネックにならないために、プロセスを組み替え始めるでしょう。誰も止め役になりたくないので、手順を端折り始めるはずです。もちろん、AIを使ってこの問題の一部を解決することは可能でしょう。レビュープロセスの改善にAIを活用することもできるはずです。しかし、それはあくまで問題の一部を解決するにすぎません。なぜなら、もしチームのメンバーが自分でコードを書かなくなったなら、彼らがコードに触れる唯一の機会はレビューの時だけになってしまうからです。しかも、先ほど申し上げたとおり、レビューの際にはそれほど注意を払わなくなっている。では、コードベースが進化していく様子に、いったい誰が注意を払うのでしょうか。答えは、誰も、です。まもなく、皆さんのコードベースは、誰も理解できない代物になっていくでしょう。
5. トークン管理、テスト、バージョン管理への影響
5-1. トークン管理の課題
先ほどのソースコードの話に加えて、私たちはトークン管理についても考えなければなりません。トークンにはコストがかかるということを、皆さんもすでにご存じだと思います。規模が大きくなれば、トークンは私たちが本当に考慮しなければならないコストになります。もし社内の全員が今の10倍、あるいは100倍のトークンを使い始めたらどうなるでしょうか。あるいは、うっかり1か月分の予算を1日で使い切ってしまったら、どうなるでしょうか。実はこれは、私の知人の身に実際に起きたことです。もし支出の優先順位をつけなければならないとしたら、どこに予算を割くべきか分かりますか。そもそも、今トークンがどこに使われているのか、それを可視化できていますか。
このシステムのほんの最初の数個のノードを見ただけでも、すでに問題が見えてきており、この先にかなり難しい二次的な影響が待ち受けていることは明らかです。
5-2. テストインフラへの影響
次に、テストとバージョン管理に話を移します。これらは少し特殊な存在です。皆さんは、自分たちのテストインフラがどれだけの計算資源を使っているか、意識したことがあるでしょうか。少なくとも私自身は、Googleにおいて「自分のテストは十分すぎるほど速い」と感じたことは一度もありません。「今日はテストが必要以上に速く終わった」などと言ったこともありません。今の時点でさえ、十分なキャパシティがないのです。それでも、バージョン管理に取り込まれるすべての変更は、テストされなければなりません。しかも、エージェントはテストを実行するのが大好きです。なぜなら、それによって自分の仕事がうまくいっているかどうかが分かるからです。つまり、エージェントが追加の作業を生み出し、私にはさらにやるべき仕事が増える、という構図です。10倍のコミット数と、エージェントによるこうした作業の積み重ねによって、いったいどれだけのテスト用計算資源を使うことになるのか、想像してみてください。
実は、事態はそれよりも悪くなる可能性があります。というのも、Googleで私たちが観察してきたのは、コードベースが大きくなるにつれて、依存関係グラフは線形にではなく、二次関数的に増大していくという事実だからです。つまり、コードベースが10倍大きくなり、何も壊れないことを確認するためにすべての依存関係をテストしようとすると、実行するテストの数は100倍に達する可能性があります。もしかすると1000倍になるかもしれません。これは非常に興味深い課題になるはずですし、いずれ皆さんの予算の中の一項目として重くのしかかってくるでしょう。よく考えておくべきことです。つまり、テストを実行する頻度が増えるだけでなく、一回あたりのテストの規模自体が100倍になるかもしれないということです。そして正直に言うと、もしテストの規模がそこまで大きくならない、テスト用の計算資源についてあまり心配していないという状況であれば、私はむしろそちらのほうを心配します。なぜなら、それはそもそも十分な数のテストを持っていない可能性が高く、エージェントたちが何が正しく動いているのかを確認する手段もないまま、コードベースの中を好き勝手に(yoloで)動き回っているということを意味するからです。
5-3. バージョン管理システムの限界
さて、ここまでの課題を解決できたと仮定しましょう。コンパイルの問題も、テストの問題も解決できたとします。次はバージョン管理システムについて考えてみましょう。世の中で広く使われているバージョン管理システムの多くは、パフォーマンスのために最適化されているわけではありません。まったくそうではないのです。それらは一貫性や順序性を保つことを目的として最適化されています。それが本来の役割であり、高速に動作することではありません。皆さんのバージョン管理システムのパフォーマンスは、どれほどのものでしょうか。1分間に何コミットまで処理できますか。断言しますが、皆さんが思っているよりも少ないはずです。10倍の速度に対応できるようにはスケールしません。バージョン管理システムのパフォーマンスについて、最後に考えたのはいつでしょうか。そもそも考えたことがありますか。Gitの開発に携わっている人でもない限り、まずないでしょう。正直なところ、もしバージョン管理のパフォーマンスについて話をしなければならない状況に陥っているとすれば、それは何かがひどく間違っている証拠です。私たちは今、開発者体験の一番奥深く、いわば「はらわた」の部分にまで踏み込んでいるのです。しかし、それこそがシステミックな変化というものです。システミックな変化は、システムのあらゆる隅々にまで入り込み、「ちゃんと注意を払っているか。ここに、あなたが予想もしていなかったものがあるぞ」と問いかけてくるのです。
ちなみに、この「バージョン管理の問題は、小さなリポジトリをたくさん作ることで解決できるはずだ」と考えている方にお伝えしておきたいことがあります。数百、数千もの小さなリポジトリを運用している人に話を聞いてみてください。それはそれでまったく新しい種類の課題を生み出すだけであり、そのどれもがAIによって必ずしも楽になるわけではないということを、断言できます。
ここまで、私たちが見てきたすべてのノードで問題にぶつかってきました。しかも、これらはまだ「見つけやすい」キャパシティに関するノードに過ぎません。つまり、ある数字を10倍してみて、それがうまくいきそうか、まずそうかを考えるだけで見つけられるような課題です。この先には、まだ他にも予想外の課題がたくさんあります。
6. その他の見落とされがちな課題群
6-1. 検証戦略の変化
ここからは、皆さんに気をつけていただきたいことのリストを、駆け足で見ていきたいと思います。まず、計算資源の話にとどまらない検証(バリデーション)の問題です。おそらく今日、皆さんの検証戦略は、大量のユニットテストと、いくらかの統合テストといったものが中心になっていると思います。しかし、コードが10倍、サービスが10倍になった世界では、統合テストが品質戦略の中でもっとも重要な要素になっていきます。今日の統合テストの体制に満足している方はどれくらいいらっしゃいますか。ライブ配信をご覧の皆さんのためにお伝えしておきますが、一つも手が挙がっていません。ええ、そうだろうと思っていました。私自身も満足していません。統合テストは本当に難しく、私自身、自分が望むようなやり方でそれを行うためのツールを今は持ち合わせていません。
さらに、私が「ブール値の連言(conjunction of booleans)」問題と呼んでいるものもあります。今日、ソフトウェアを出荷するためには、すべてのテストが通ることを求めます。すべてのブール値が緑になる。すべてが良好な状態になってから出荷する。これは合理的なやり方です。しかし、テストの数が100万件に達し、その100万件のテストを実行する基盤インフラそのものの信頼性が疑わしくなったとき、何が起きるでしょうか。すべてのブール値が真であることを条件にソフトウェアを出荷する、というやり方そのものが不可能になるかもしれません。そうなれば、新しい戦略が必要になります。おそらくそれは、統計的な手法によって、実行すべき適切なテストを見極めるようなものになるはずです。なぜなら、すべてを実行することはもうできないからです。
6-2. 大規模変更のリスク
超巨大な変更についても考えてみましょう。あらゆる場所で言語やフレームワークをリファクタリングし、変更できるようになるというのは、非常に刺激的なことです。誰もがそれを行えるようになります。しかし、数万行、数十万行、あるいは数百万行に及ぶマージコンフリクトを管理するためのワークフローや社会的合意は、皆さんの組織にありますか。おそらくないでしょう。ですから私たちは、こうした非常に大規模な変更セットが互いにすれ違いながら進んでいけるようなワークフローを、どう構築していくかを考えていく必要があります。会社の全員がそれを行えるようになるのであれば、新しい戦略が必要になります。
そして、皆さんは「エージェンティックな編集合戦」を見たことがあるでしょうか。あるエージェントが変更を加え、別のエージェントがやってきて「いや、その変更は気に入らない。別の変更にしよう」と言い出す現象です。これは、両陣営の分のトークン代を自分が支払っているのだと気づくまでは、なかなか面白い光景です。
次にリリースについて考えてみます。皆さんは今日、顧客に対してどれくらいの頻度でリリースしていますか。毎日でしょうか。もし毎日リリースしているなら、かなり良い状態だと言えます。もしそうでないなら、一つ問題を提起させてください。皆さんはこれから10倍のソフトウェアを手にすることになります。そのソフトウェアはどこかに出荷されなければなりません。もし毎日リリースしていないのであれば、おそらく一回あたりの変更がどんどん大きくなっていくことになるでしょう。私の友人たちが口をそろえて言うのは、非常に大きな変更は非常に恐ろしい、ということです。ですから、それは避けたいところです。しかし、コードはどこかに行かなければなりません。デプロイされて初めて価値を持つのです。ですから、皆さんが試みるであろう一つの方法は、より頻繁にリリースすることです。それは良いことです。DORAの友人たちも、きっと誇らしく思うでしょう。「もっとリリースしてください」と言うはずです。しかし、ある時点で、リターンは逓減していきます。毎秒リリースすることが、それほど大きな価値を生むとは思えません。毎秒リリースすることと、1日1回リリースすることの間のどこかに、適切なバランス点があるはずですが、それでもコードは増え続けていきますから、リスクを増やさないために、どこにそのコードを置くべきかを考えなければなりません。
内部APIについてはどうでしょうか。ここまでソフトウェアの構築について話してきましたが、社内のAPIやデータを含む内部の開発者環境についてはどうでしょう。私が友人たちに伝えているのは、皆さんのAPIはすべて突然「公開API」になってしまった、ということです。なぜなら、それらは公衆インターネットに公開するものと同じ種類の堅牢化が必要になるからです。なぜかというと、エージェントは皆さんと交渉してくれないからです。彼らはAPIを見つければ、それを呼び出し始めます。そして、もしデータへのアクセスを得られるなら、彼らは間違いなくそれを取りに行きます。エージェントがデータセットにアクセスできるのであれば、それは彼らにとって「利用可能」なものなのです。もし皆さんが、自社の内部データセットや内部APIに対して、公開APIと同じレベルの配慮をしてこなかったのであれば、非常に興味深い課題に直面することになるでしょう。なぜなら、エージェントは皆さんが見つけてほしくなかったものまで見つけ出すからです。
ジェヴォンズのパラドックスについてはどうでしょうか。これは、この12か月ほどで私たち全員が学んだ言葉です。以前は誰もこの言葉を知らず、発音の仕方すら分からなかったはずです。しかし今では、皆この言葉を知っています。ジェヴォンズが言っているのは、ある資源が安く効率的になればなるほど、私たちはそれをより多く使うようになる、ということです。そしてまさに、トークンについてそれが起きています。私たちはあらゆる場所にトークンを投入しています。それが、私たちの働き方、そして働き方についての考え方そのものを変えつつあります。私たちは今、以前は目に見えなかった生産性の裏側の作業に、コストという値札をつけようとしている、あるいはそうなりつつあるところです。それが私たちのふるまいをどう変えるのか、正直まだ分かりません。ちなみに、こうした「トークンエンジン」をどこに配置するかについては、注意が必要です。もし荷重を支える(load-bearing)ような箇所にトークンエンジンを置いてしまうと、奇妙なことが起こり得ます。例えば、ロールバックのプロセスが、あるエージェントが十分なキャパシティを持っていることに依存しているとしたらどうでしょうか。もし誰かがそのエージェントのトークン予算を使い切ってしまい、ロールバックができなくなったとしたら、それはおそらく悪いことです。
ロールバックといえば、そもそも今日ロールバックがうまく機能している理由をご存じでしょうか。基本的にそれは、皆さんが不具合を検知するのにかかる時間よりも、わずかに遅いペースでソフトウェアをリリースしているからです。もし、不具合を検知できる速度よりもはるかに速くソフトウェアをリリースできるようになったら、それは皆さんのロールバック体制にとって何を意味するでしょうか。あらゆるロールバックが、その上に重なって着地する複数の競合する変更と向き合わなければならなくなります。つまり、単に速くリリースするだけでは十分ではなく、システム全体、すなわちロールバックも含めて考える必要があるのです。これは非常に重要な安全弁です。
6-3. 組織・人材への影響
「誰もがビルダーになれる」という考え方についてはどうでしょうか。この会議では、誰もがビルダーになれるということを称賛する場面が多くありました。私はそれを素晴らしいことだと思っています。エンジニアリングを民主化することは、それを民主化したのだと気づくまでは、確かに素晴らしいことです。皆さんの会社に、置き換えたいと思っているツールが一つくらいあるはずです。名前は挙げませんが、きっと「バイブコーディングで作り直したい」と思っているツールがあるでしょう。それを、会社の全員が使っているすべてのツールについて掛け合わせてみてください。全員がまったく異なるツールを使うようになったとき、会社の社会的な結びつきはどうなるでしょうか。もし運が良ければ、共通のデータ基盤を持っているかもしれません。それは良いことです。すべてのデータが同じ場所に集まっているのであれば。しかし、もしそうでなかったら?「誰もがビルダーになれる」というのは、皆が作ったものすべてを保守しなければならなくなるまでは、素晴らしいことなのです。
そして、若手エンジニアたちに強いることになる「テクニカルリーダーシップの早回し」についても、少し考えておきましょう。リードになるまでに時間がかかる理由は、判断や直感、専門性を積み上げる必要があるからです。チームを率いる立場になると、自分一人で作業するときよりもはるかに大きな「爆発半径(ブラストレディウス)」を持つことになるからです。新卒社員が、50体のエージェントを自由に使える環境に足を踏み入れたとき、しかしそこには直感も判断力もまだ備わっていないとしたら、いったい何が起きるでしょうか。10年分の経験を、どうやって6か月で教え込めばよいのでしょうか。正直、私にもまだ分かりません。
そして最後に、皆さんもすでに何度も耳にしてきたであろう話題です。特に、この前のセッションにいらっしゃった方であれば。人間の注意力こそが、私たちが持っているもっとも貴重な資源です。そして今、私たちの周りには多くのノイズがあります。あまりにも多くのエージェントが、あまりにも多くのことで私たちの注意を求めてきます。私たちはこれをどう管理していくか、考えなければなりません。なぜなら、今のところ私たちはそれをうまくやる方法を知らないからです。これまで私たちは、自分たちが処理できる以上のトラブルを自ら生み出すことができないという事実によって、ある意味で救われてきました。しかし、もはやそうではなくなりつつあります。
さて、ここまでの話はかなりの量になったと思います。それは、システムの中ではすべてがつながっているからです。私がここまで挙げてきた課題は、どれもシステムの中の一つのノードだけを見ていても解決できるものではありません。システム全体を見なければならないのです。エージェンティックな開発に適応していくためには、私たちは皆、常にシステムとして物事を考える術を学んでいく必要があると思います。
7. DORAの知見とシステム思考の実践
7-1. AIは「増幅器」であるという知見
こうした課題や機会がどこにあるのかを考えている間に、私が気づいたある一つのパターンについてお話ししたいと思います。それは、AIが増幅器として働く、というパターンです。このアイデアを知った瞬間から、私はあらゆる場所でそれを見かけるようになりました。ただし、これは私自身が思いついたアイデアではありません。これはDORAの友人たちの発見によるものです。彼らが昨年発表したAI開発に関するレポートでは、うまくやれているチームの間に、こうした関係性が見出されたと報告されています。彼らは、AIを増幅器にする方法を見出したチームがある、ということを発見したのです。AIはより多くのことをこなせるようになります。より多くのテスト、より多くのドキュメント、より多くのコードを生み出せます。しかし同時に、より多くの混乱も生み出します。なぜなら、増幅というのは方向ではなく大きさの問題だからです。AIは、それがどこへ向かうかを気にしません。ただ、そこにあるものをより多く生み出すだけです。DORAが実際に見出したのは、優れた基礎(ファンダメンタルズ)を持つチームこそが、その増幅の力を有用な方向に活かすことができる、ということでした。
これは、一つの問いを投げかけてきます。皆さんは、自分たちの基礎についてどう感じていますか。皆さんの会社の意思決定文化はどうなっていますか。それを改善するために何ができるでしょうか。技術戦略についてはどうですか。開発者の生産性に目を向けている人はいますか。組織の中で、人々は今日どれだけうまく協働できていますか。セキュリティの体制はどうなっていますか。コードの健全性、リリースの衛生状態、信頼性はどうですか。AIは、これらの問題をデフォルトで解決してくれるわけではありません。もし皆さんが良い実践(プラクティス)を持っているなら、AIはそれを増幅してくれます。しかし、それが良くないものであれば、AIはさらに多くの混乱を引き起こすことになります。とはいえ、たとえ堅実な基礎を持っていたとしても、私たちの前には本当に激しい変化の道のりが待ち受けています。私の推測でしかありませんが——後で私に確認していただいて構いません——2030年になると、今日の私たちの開発者エコシステムは、今の私たちから見た2001年のような感覚になっているのではないかと思います。ちなみに2001年当時、私たちはソフトウェアをCD-ROMで出荷していました。それくらい、2030年は今とは遠く離れた場所になっているかもしれない、ということです。
基礎を築き続けていく中で、他にも考えておくべきことをいくつかお伝えしたいと思います。まず、そして何よりも重要なのが、インフラのキャパシティを把握しておくことです。どれだけのリソースを使えるのか分からなければ、AIをデプロイすることも、計算資源をデプロイすることもできません。これを追跡しておくための良い仕組みが必要です。次に、検証(バリデーション)が必要です。検証していないソフトウェアを出荷することはできませんし、少なくともそうすべきではないからです。しかし、先ほども申し上げたとおり、検証のあり方は変わっていくことになるので、新しい検証戦略を今のうちに考えておく必要があります。それに加えて、アイソレーション(分離)も必要です。なぜなら、これまでコードを書く目的として使ってこなかったような、様々な目的のためのコードが大量に生まれてくるからです。それ自体は問題ありませんが、あの面白いプロトタイプのコードが、実際に本番環境に紛れ込んでしまうことは避けたいところです。ですから、アイソレーションについて気を配る必要があります。楽しみのためのものが、収益を生む部分に影響を与えないようにする必要があるのです。そして最後に、抽象化(アブストラクション)についても気を配る必要があります。私たちが抽象化を構築するのは、開発者が間違った選択をしないようにするためです。だからこそライブラリやフレームワークなどを構築するわけです。今日、私たちはゼロからウェブサーバーを構築したりはしません。フレームワークがあるからです。物事を間違える方法がたくさんあるからです。そして、エージェントに多くの意思決定を委ねることも、それと同じ結果を招きます。ですから、エージェントが頼ることのできる、良質な抽象化が必要です。悪い選択肢を与えないようにしなければなりません。
皆さんは、エンジニアリングの実践(プラクティス)は決して神聖不可侵なものではないのだと、受け入れる必要があります。実践は変わるものですが、重要なのは原則(プリンシプル)のほうです。言うは易く行うは難しであることは理解していますが、特に私たちの原則の一部は、実践そのものであるかのように感じられてしまうことがあります。例えばテストがそうです。もし皆さんが、なぜ自分のチームが今のようなやり方でソフトウェアをテストしているのか、なぜリリースプロセスが今の形になっているのかを、一度もきちんと考えたことがないのであれば、それを進化させることはできません。原則を理解することこそが、この「10倍の瞬間」を進んでいく中で、物事を変えていくための力と自信を与えてくれるのです。
7-2. システム思考の実践方法
ソフトウェアエンジニアであるということは、実に魅力的な時代だと思います、これは本音です。私たちの仕事のあらゆる側面が再定義されつつあります。私たちはこれまで以上に創造性を発揮する必要があります。コンテキスト管理、トークンの経済性、モデルドリフトといった課題に取り組むためのスキルが必要です。私たちには創造性が必要であり、あらゆるものを最適化したいという誘惑にとらわれすぎてはいけません。私たちは探求(エクスプロレーション)を奨励する必要があります。
私を夜も眠れなくさせている問題が一つあります。それは、単に最適化するだけでは解決できないと分かっている問題です。それは、私たちが成長していく中で、コードベースに対する「知的統制(インテレクチュアル・コントロール)」をどう維持していくか、という問題です。ちなみに知的統制というのは、要するに「人間が目の前にあるものについて、きちんと推論できるかどうか」を言い換えた表現です。私たちは、少なくともこの15年間、この戦いに負け続けてきました。私たちの最大級のシステムは、私たちの誰もが把握できる規模をはるかに超えてしまっています。それでも構わないと思っています。私はAIが、私たちにこうした非常に大規模なシステムを、一つの全体として理解し始めるための道具を与えてくれる可能性があると考えています。もし、私たちがこの戦いに負け続けてきたという話を信じられないという方がいらっしゃれば、一つ実験をご提案します。チームに戻ったら、皆に自分たちのシステムのアーキテクチャ図を描いてもらってください。どれだけ異なる絵が出てくるか、見てみてください。私たちはこの戦いに長い間負け続けてきたのです。だからこそ、助けが必要になります。
実のところ、私たちのソフトウェアシステムの多くは非常に壊れやすいものです。100万行規模のシステムであっても、たった一行の悪いコードや、一つの誤った設定フラグによって壊れてしまうことがあります。それは、変更を加える前に二の足を踏んでしまうような、まさに「脆さ」だと言えます。私が本当に期待しているAIの使い方の一つに、こういうものがあります。継続的に更新される、ほとんどインタラクティブなアーキテクチャ空間を手に入れて、そこに質問を投げかけられるようになるというアイデアです。例えば、「もしここからキャパシティを取ってきて、東海岸に移したらどうなるか」「もしユーザーの成長が突然40%跳ね上がったらどうなるか」といった質問です。今日、そこそこの規模のシステムに対してそれを行うことは、機能的にほぼ不可能です。あまりにも多くの変数があり、把握しておかなければならないことが多すぎるからです。しかし、AIは非常に大規模なデータの集合から意味を見出すことができますから、そこには何か可能性があると思っています。この問題の面白いところは、単にコードを動かす機械を回すことだけに集中するのではなく、「自分たちが構築してきたものへの理解を、どう深めていけるか」を問うている点です。私は、そこにこそ、もっとも刺激的な課題のいくつかがあると考えています。
私たちの業界で変化がとてつもない速さで起きていることは、疑いようがありません。しかも、皆さんのほとんどがこれまで経験したことがないであろうペースで起きています。今、皆さん一人ひとりにできるもっとも重要なことの一つは、まだうまく対応できずに苦しんでいる誰かに手を差し伸べることです。まだこれを乗りこなせていない人のために、助けの手になってあげてください。私たちは皆、それぞれ違うスピードで前に進んでおり、それぞれ違うやり方でこの変化に対処しています。自分だけが取り残されているように感じてしまうのは、とても簡単なことです。シニアなエンジニアの皆さんは、メンターになってください。行き詰まっている人を見つけて、助けてあげてください。もし皆さんがすでに自分なりのAI開発ワークフローを見出しているなら、それを周りの人たちと共有してください。それは、独り占めすべき秘密ではありません。周りの人たちを助けてあげてください。もし皆さんがテックリードの立場にあるなら、積極的に関わっていく必要があります。皆さんの会社でソフトウェアエンジニアリングがどのように進んでいくのか、その舵取りを手伝う必要があります。そして何より重要なのは、もし皆さんがソフトウェアの品質やソフトウェア設計について気にかけているなら、それを声に出して主張していかなければならないということです。この会場にいる皆さんこそが、それをやる人たちです。皆さんの上司たちには、おそらくそれはできません。
8. 変化に備える実践的視点と結び
8-1. 実践的な備え
基礎を築き続けていく中で、他にも考えておくべきことがいくつかあります。まず、そして何よりも重要なのが、インフラのキャパシティを把握しておくことです。どれだけのリソースを使えるのかが分からなければ、AIをデプロイすることも、計算資源をデプロイすることもできません。これをきちんと追跡できる仕組みを持っておく必要があります。次に必要なのが検証(バリデーション)です。検証していないソフトウェアを出荷することはできませんし、少なくともそうすべきではありません。ただし、これまでお話ししてきたとおり、検証のあり方そのものが変わっていくことになりますから、今のうちに新しい検証戦略を考えておく必要があります。
それに加えて、アイソレーション(分離)も必要になります。これまでコードを書く目的として想定してこなかったような、様々な目的のためのコードが大量に生まれてくるからです。それ自体は問題ありませんが、あの面白いプロトタイプのコードが、実際に本番環境へ紛れ込んでしまうことは避けたいところです。楽しみのために書かれたものが、収益を生む部分に影響を与えないよう、気を配る必要があります。そして最後に、抽象化(アブストラクション)についても考えなければなりません。私たちが抽象化を構築するのは、開発者が間違った選択をしないようにするためです。だからこそライブラリやフレームワークなどを構築しているのであり、今日ゼロからウェブサーバーを組み立てたりはしません。物事を間違える方法があまりに多いからです。そして、エージェントに多くの意思決定を委ねることも、これとまったく同じ結果を招きます。ですから、エージェントが頼ることのできる、良質な抽象化を用意しておく必要があります。悪い選択肢を与えないようにしなければなりません。
皆さんは、エンジニアリングの実践(プラクティス)が決して神聖不可侵なものではないのだと、受け入れる必要があります。変わっていくのは実践であり、重要なのは原則(プリンシプル)のほうです。言うは易く行うは難しであることは承知していますが、特に私たちの原則の一部は、実践そのものであるかのように感じられてしまうことがあります。例えばテストがそうです。もし皆さんが、なぜ自分のチームが今のようなやり方でソフトウェアをテストしているのか、なぜリリースプロセスが今の形になっているのかを一度もきちんと考えたことがないのであれば、それを進化させることはできません。原則を理解することこそが、この「10倍の瞬間」を進んでいく中で、物事を変えていくための力と自信を与えてくれるのです。
8-2. 知的統制という課題
ソフトウェアエンジニアであるということは、実に魅力的な時代だと思います。これは本音です。私たちの仕事のあらゆる側面が再定義されつつあります。私たちはこれまで以上に創造性を発揮する必要があります。コンテキスト管理、トークンの経済性、モデルドリフトといった課題に取り組むためのスキルが必要です。私たちには創造性が必要であり、あらゆるものを最適化したいという誘惑にとらわれすぎてはいけません。探求(エクスプロレーション)を奨励していく必要があります。
私を夜も眠れなくさせている問題が一つあります。それは、単に最適化するだけでは解決できないと分かっている問題です。それは、私たちが成長していく中で、コードベースに対する「知的統制(インテレクチュアル・コントロール)」をどう維持していくか、という問題です。ちなみに知的統制というのは、要するに「人間が目の前にあるものについて、きちんと推論できるかどうか」を言い換えた表現に過ぎません。私たちは、少なくともこの15年間、この戦いに負け続けてきました。私たちの最大級のシステムは、私たちの誰もが把握できる規模をはるかに超えてしまっています。それでも構わないと思っています。私はAIが、私たちにこうした非常に大規模なシステムを、一つの全体として理解し始めるための道具を与えてくれる可能性があると考えています。もし、私たちがこの戦いに負け続けてきたという話を信じられないという方がいらっしゃれば、一つ実験をご提案します。チームに戻ったら、皆に自分たちのシステムのアーキテクチャ図を描いてもらってください。どれだけ異なる絵が出てくるか、見てみてください。私たちはこの戦いに長い間負け続けてきたのです。だからこそ、助けが必要になります。
実のところ、私たちのソフトウェアシステムの多くは非常に壊れやすいものです。100万行規模のシステムであっても、たった一行の悪いコードや一つの誤った設定フラグによって壊れてしまうことがあります。それは、変更を加える前に二の足を踏んでしまうような、まさに「脆さ」だと言えます。私が本当に期待しているAIの使い方の一つに、こういうものがあります。継続的に更新される、ほとんどインタラクティブなアーキテクチャ空間を手に入れて、そこに質問を投げかけられるようになるというアイデアです。例えば、「もしここからキャパシティを取ってきて、東海岸に移したらどうなるか」「もしユーザーの成長が突然40%跳ね上がったらどうなるか」といった質問です。今日、そこそこの規模のシステムに対してそれを行うことは、機能的にほぼ不可能です。あまりにも多くの変数があり、把握しておかなければならないことが多すぎるからです。しかし、AIは非常に大規模なデータの集合から意味を見出すことができますから、そこには何か可能性があると思っています。この問題の面白いところは、単にコードを動かす機械を回すことだけに集中するのではなく、「自分たちが構築してきたものへの理解を、どう深めていけるか」を問うている点です。私は、そこにこそ、もっとも刺激的な課題のいくつかがあると考えています。
8-3. 結び:エージェンシーを持つこと
私たちの業界で変化がとてつもない速さで起きていることは、疑いようがありません。しかも、皆さんのほとんどがこれまで経験したことがないであろうペースで起きています。今、皆さん一人ひとりにできるもっとも重要なことの一つは、まだうまく対応できずに苦しんでいる誰かに手を差し伸べることです。まだこれを乗りこなせていない人のために、助けの手になってあげてください。私たちは皆、それぞれ違うスピードで前に進んでおり、それぞれ違うやり方でこの変化に対処しています。自分だけが取り残されているように感じてしまうのは、とても簡単なことです。シニアなエンジニアの皆さんは、メンターになってください。行き詰まっている人を見つけて、助けてあげてください。もし皆さんがすでに自分なりのAI開発ワークフローを見出しているなら、それを周りの人たちと共有してください。それは、独り占めすべき秘密ではありません。周りの人たちを助けてあげてください。もし皆さんがテックリードの立場にあるなら、積極的に関わっていく必要があります。皆さんの会社でソフトウェアエンジニアリングがどのように進んでいくのか、その舵取りを手伝う必要があります。そして何より重要なのは、もし皆さんがソフトウェアの品質やソフトウェア設計について気にかけているなら、それを声に出して主張していかなければならないということです。この会場にいる皆さんこそが、それをやる人たちです。皆さんの上司たちには、おそらくそれはできません。
最後に、少し不格好なたとえ話になることを承知の上で申し上げます。もし皆さんが、私たちの開発者エコシステムを一つの生きたエコシステムだと考えるなら、私たちはこれまで、一枚一枚の葉、一本一本の枝を、まるで特別な生命体であるかのように、じっと見つめ、大切に世話をすることに慣れてきました。しかし、それも長くは続きません。まもなく私たちは、一本の木を管理するだけでなく、森全体を管理していくことになります。そして、森を個々の木を見ることで管理することはできません。森を、一つのエコシステムとして捉えることによってのみ、管理することができるのです。
さて、ここでシステミックな変化について厄介なことをお伝えしておきます。それは、あらゆる場所で、あらゆるものに対して、一斉に起きるという性質を持っているということです。私たち一人ひとりが影響を及ぼすには大きすぎるように感じられることもあります。まるで毎週のように押し寄せてくる変化の波の中で、自分の足場を確保するための何かをつかむことすら、不可能に思えるかもしれません。しかし、私たちが先ほど発見したとおり、システムの中ではすべてがつながっています。小さな行動が、大きな結果を生むことがあるのです。どう見えるかにかかわらず、AIによる変革は、皆さんの会社のリーダーたちだけの専有領域ではありません。彼らにも果たすべき役割はありますが、皆さん自身にもまた役割があります。この「転換点」とも言うべき瞬間において、現場の最前線にいるソフトウェアエンジニアである皆さんこそが、ソフトウェアエンジニアリングが今後どうなっていくのかを決める、まさにその中心にいるのです。ツールから、ワークフロー、エンジニアリングの実践、そしてエンジニアリング文化に至るまで、すべてがそうです。システムの働きを見ることができれば、そこにレバレッジ(てこの力)を見出すこともできます。
皆さんが思っている以上に、皆さんにはエージェンシー(主体性)があります。本当にそうなのです。そのエージェンシーを使って、皆さんの組織のために、皆さんのチームのために、そして皆さん自身のために、未来を創り出していってください。ありがとうございました。