本動画は、Googleのソフトウェアエンジニアであるアダム・ベンダーが「ソフトウェアエコロジー」という概念を用いて、AIが開発者エコシステムに与える影響を論じた講演である。社会技術システムとしての開発環境を分析し、AIによって生産性が10倍に跳ね上がる転換点で何が最初に壊れるのかを多角的に検証する。コード生成、ビルド、テスト、バージョン管理、リリースといった各ノードに生じる二次的影響を示しながら、AIは方向ではなく規模を増幅する装置にすぎないと指摘し、健全な基礎の重要性を説く。最終的に、第一線のエンジニア自身がこの転換点でソフトウェアエンジニアリングの未来を形作る当事者であると訴える内容となっている。
ソフトウェアエコロジーという視点
皆さん、こんにちは。調子はどうですか。おお、なかなかいい反応ですね。いい感じです。水曜日の午後3時ですからね。水曜日って、そんなに悪くない曜日ですよね。
転換点に立つソフトウェアエンジニアリングへようこそ。私の名前はアダム・ベンダーです。今日皆さんにお話しするのは、ソフトウェアエコロジーと呼ばれるものについてです。あまり聞き慣れない言葉かもしれません。
なぜこの話をしたいかというと、これがAIが私たちの開発者エコシステム、つまり皆さんが毎日働いている開発者エコシステムに与える影響について、何かを教えてくれるからです。気づいているかどうかわかりませんが、世の中はずいぶんと奇妙なことになってきていますよね。2026年の皆さんの仕事は、2020年に思い描いていたものとはまるで違うはずです。それは間違いありません。もし2020年の私にこれがどうなるか説明しようとしても、私は信じなかったでしょう。
このすべての変化が私たちをどこへ連れて行こうとしているのかを把握しようとすると、少し圧倒されてしまうかもしれません。私は未来を予言することはできません。でも、今日の私たちのソフトウェアエコシステムをそのまま研究すれば、求めている答えのいくつかは、思っているよりもずっと近くにあると考えています。ソフトウェアエコロジーというこの考え方は、私たちの業界における今この瞬間を捉えるための、まさに最適なレンズになると思うのです。
さて、ソフトウェアエコロジーって何だ、と皆さんが問いかけているのが聞こえてきそうですね。それに、ステージに上がるためにこの場ででっち上げたんじゃないか、とも。でっち上げてはいません。これは実在する言葉です。ただ、定義する前に、少し前提を整えておきたいと思います。これから少しシステム思考について深掘りしていきます。それでも大丈夫だといいのですが。少しお付き合いください。最後にはすべて腑に落ちると約束します。
システムからエコシステムへ
ではシステムという概念から始めましょう。システムとは、ある一連のルールに従って動作し、統一された全体を形づくる、互いに関連し合う要素の集まりです。なんだか立派な言い方に聞こえますね。でも皆さんはシステムを知っています。こういうものです。これは皆さんが今日とてもありがたく思っているであろうシステムです。エアコンというのはこういうものですよね。設定すべき温度を知っているサーモスタットがあって、温度を上げ下げするHVACがあって、そして部屋がある。温度がちょうどよくなると、信号が止まる。これがシステムです。
ソフトウェアエンジニアであれば、おそらく常にシステムについて考えることに慣れているでしょう。設計し、構築し、運用しています。でもシステムを扱う中でおそらく学んだことのひとつは、すべてがつながっているということです。すべてがです。これは今日、私から何度か聞くことになるテーマです。
では、エコシステムに移りましょう。これは特殊な種類のシステムです。これは長い定義です。少し我慢して聞いてください。エコシステムとは、相互に依存するアクターからなる動的なネットワークで、それらが環境とともに共進化し、創発的な振る舞いと分散した主体性によって特徴づけられるものです。エコシステムは複雑です。複雑な構成要素から成り立っています。その構成要素自体が深くつながっている。それらは主体性を持っています。意思決定ができる。何かを実行できる。そして私たちにとって決定的に重要なのは、環境がそのシステムの一部だということです。環境はシステムの一部なのです。この二つを切り離すことはできません。
ですからエコシステムは、複雑適応系の一種でもあります。複雑適応系、いわゆるCASは、時間とともに成長し、変化し、進化していく能力によって特徴づけられます。かっこいいシステムはみんな複雑適応系なんです。
さて、複雑適応系はこの創発という性質も持っています。創発的特性とは、システムの個々の部分をいくら見ても見えてこないものです。システムがすべて組み上がったときにのみ見えてくる。そこから振る舞いが立ち現れてくるのが見えるわけです。そしてこの絶え間ない変化、学習、それに加えて創発が、エコシステムの中で何が起きているのかを把握するのを本当に難しくしているのです。
さて、エコシステムと聞いて思い浮かべるもの、少なくともこの会場に入ってくる前に思い浮かべていたものは、おそらくこういう景色でしょう。正直なところ、私は今この場所にいたいくらいです。なんとも牧歌的に見えますよね。でも、皆さんの社内の開発環境も、ひとつのエコシステムなのです。すべてのツールやサービスがある。複雑なアクターがいる。意見を持ち、成し遂げたいことを抱えた人々がいる。ビジネス上の制約がある。これもシステムなのです。
しかも実際には、特殊な種類のシステムです。社会技術システムです。社会技術システムというのは、人とテクノロジーから成るシステムを格好よく言っただけのものです。社会技術システムは、信じられないほど複雑です。なぜ複雑かというと、まずあのテクノロジー全部から始まって、そこに人間を混ぜ込むからです。
でも実は、皆さんは気づかないうちに社会技術システムに関するある知恵に出会っているはずです。コンウェイの法則を聞いたことがある人はいますか。ええ、もちろんです。みんな聞いたことがありますよね。でも手短に言うと、コンウェイの法則はこうです。組織は、自分たちの内部のコミュニケーション構造を反映したテクノロジーを作る。もっとくだけて言えば、4チームのグループがコンパイラを作れば、4パスのコンパイラができあがる。そういうものなのです。
その核心において、コンウェイの法則とは、私たちがテクノロジーを作る方法は、それを作る組織の構造と切り離せないという観察です。組織が、作られるものを形づくる。もちろん、私たちの開発者エコシステムに影響を与えるのは組織構造だけではありません。組織の価値観や文化も、同じくらい深い影響を与え得ます。皆さんのエコシステムは、組織がインセンティブを与えるものを作り上げる。皆さんのエンジニアリング文化は、開発者エコシステムを取り巻く環境を作り出すのです。
つまりこういうことです。社会技術システムについて一度学ぶと、ソフトウェア開発のいたるところにそれが見えてきます。アーキテクチャから、ポストモーテムの文化、コードレビュー、セキュリティポリシーに至るまで。どこにでもあるのです。私たちが作るもの、そしてそれをどう作ると選ぶか、それは私たちが何を大切にしているかの反映です。もし私たちが思慮深くあれば、その知識を使って自分たちの価値観を増幅し、作るものの中に組み込むことができる。望む種類の成果を後押しできるのです。
ですから、ここでようやくソフトウェアエコロジーをきちんと定義できると思います。ソフトウェアエコロジーとは、ソフトウェアを生み出す社会技術エコシステムを全体論的に研究することです。さあ、これで全員が同じ地点に立ちました。
ちなみに、今までの話が少し抽象的に感じられたとしても大丈夫です。これから実際の例を見ていきますから。Googleの開発者エコシステムについてお話しします。
Googleの開発者エコシステム
Googleはとても大きく、そして私に言わせればいくらか複雑な開発者エコシステムを持っています。なぜなら過去25年にわたって、私たちは本当に並外れた能力と、ええ、少々の複雑さを進化させてきたからです。最初に断っておくと、私がGoogleの話をするのは、ひとつには私がそこで働いているからです。でもそれは、私が最もよく理解している開発者エコシステムだからでもあります。ここでの私の意図は、皆さんにGoogleがやったことをやれと言うことではありません。それは皆さんにとっていい結果にはなりません。皆さんは別の会社です。別の状況にいる。気にすべきトレードオフの組み合わせも違います。
どんなエンジニアリング組織もそうであるように、Googleもたくさんの選択をしてきました。それらは、エコシステムを構築していた当時の私たちのニーズに非常に固有のものでした。皆さんの状況は違います。
さて、数年前に私たちは一冊の本を書きました。この本を見たことがある人もいるかもしれません。社内では私たちはこれをフラミンゴ本と呼んでいます。この本は、Googleが実際に内部でどう動いているのかを人々に理解してもらうために書いたものです。本の半分はバージョン管理やテストといったことに費やしました。でも本の前半まるごとは、エンジニアリング文化に充てたのです。これについてはよく質問を受けました。なぜそんなにエンジニアリング文化に紙幅を割くのか、と。
実のところ、Googleが持っている文化を理解しなければ、なぜ私たちが今のような技術的選択をしているのかを理解できないからです。これらは互いに結びついているのです。本を読んでいない人のために、ざっと案内しましょう。心配しないでください。これを全部読む必要はありません。ええ、写真を撮るのは構いませんよ。
Googleをいくらか独特にしているものがいくつかあります。たとえば、私たちは深くエンジニアリング主導です。重要な意思決定が行われるとき、エンジニアは必ずその場にいます。透明性をとても重視しています。できる限りのドキュメントやコードを、できるだけ頻繁に公開しようとしています。人々に助け合うことを奨励しています。実際、Googleを去った人なら誰でも、同僚たちの助けてくれる姿勢を、最も大切なものとして挙げるはずです。私たちはコードレビューを、テストの採点ではなく、メンタリングの機会として扱います。標準化を重視しています。本当に重視しています。継続的改善を信じています。誰かを責めないポストモーテムを大切にしています。英雄的な無理よりも持続可能性が良い、そして手作業の苦役よりも自動化が良い、という考えを大切にしています。
私たちは常にこれらの理想すべてを達成できているわけではありません。でも、文化的に目指しているのはこういうものです。技術面では、皆さんも読んだことがあるであろうモノリシックなリポジトリがあります。これについてはあとでもう少しお話しします。トランクベース開発があって、すべての変更が毎回ヘッドにランドします。Googleでバイナリをビルドすると、ほぼすべてのコード行がソースからビルドされます。これってかなりすごいことですよね。誰もが使う統一されたビルドツールチェーンがあります。グローバルなテスト自動化プラットフォームがあります。一か所がすべてのテストを実行し、一日に何十億ものテストをこなします。最後にグリーンだった状態を示すグローバルなシグナルがあります。社内のシンプルなウェブサイトひとつを見るだけで、どんなビルドの状態でもわかるのです。統一されたコンピュート環境があります。だから私のマシンでは動く、なんてことは、ほぼ起こりません。意見の強い開発者向けフレームワークと、少数の中核言語があります。
この文化とテクノロジーの混ぜ合わせこそが、Googleというものを生み出しているのです。一方だけを見て、もう一方を理解することはできません。
共有された運命という原則
もし私が一つの原則を選ばなければならないとしたら、明示的でないにせよ、ときに暗黙のうちに私たちを導いてきたと思える一つの原則、それは共有された運命と呼ばれるものです。共有された運命とは、エコシステムとその構成要素が互いにどれだけ密接に結びついているかの度合いを表す言葉です。共有された運命の度合いが高いエコシステムでは、一つの構成要素が他のすべてに影響を与え得ます。
開発者エコシステムにおいて、共有された運命は、社会的な選択であると同時に技術的な選択でもあります。全員に同じテクノロジーを使わせるだけでは共有された運命は得られません。そのテクノロジーをどう管理するかについての社会的な契約も育てる必要があるのです。
Googleでは、私たちの共有された運命はモノリシックなリポジトリから始まります。GoogleのすべてのコードはAndroidやChromeといったいくつかの注目すべき例外を除いて、ひとつの共有リポジトリの中にあります。何もかもがです。すべてがトランクにコミットされます。ブランチはありません。バージョンもありません。すべてが一か所にあるのです。
この種の共有された運命のおかげで、私たちは一つのファイルにセキュリティパッチを当てれば、一週間以内に社内のあらゆるアプリケーションがパッチ済みになると確信できます。これってまるで超能力ですよね。適切な場所の10行のコードが、100億行のアプリケーションやシステムソフトウェアにパッチを当てられる。かなり見事なものでしょう。
ただし、共有された運命がいつも良いものとは限りません。共有された運命は選択です。共有された運命があまり意味をなさない場所もあります。たとえば、本番環境では、一つのサービスが他のすべてのサービスを巻き添えにして落とすことや、一つのクラスタがリージョン全体に感染することは望みません。ですから私たちは、特にGoogleは、カスケード障害のような事態を引き起こす危険な種類の共有された運命を持たないように、本当に懸命に取り組んできました。繰り返しになりますが、要点は、共有された運命はトレードオフだということです。それをどこに置くべきかの適切な場所を見極め、そして自分たちにとってうまく機能するようにしなければならないのです。
大規模変更という創発
私たちの共有された運命環境から生まれた最も興味深い創発的特性のひとつが、大規模変更という考え方です。AIよりずっと前から、AIよりはるか前から、Googleの社内ツールは、一人の開発者が文字通り何百万行ものコードを変更することを可能にしてきました。何百万行ものコードを、です。本人が一度も見ることのないコード、二度と目にすることのないコード、何も知らないかもしれないコードを。私たちはそれを自動的に可能にするツールを作ってきました。今日でもそうです。そして少なくとも過去15年間、ずっとそうやってきたのです。
この種の能力のおかげで、私たちは時間をかけてモノレポを進化させてくることができました。言語やフレームワークを更新できる。これこそが、私たちの社内環境が停滞するのを防いでいるものです。これがなければ今のGoogleは存在しなかった、と言っても誇張ではありません。そしてそうしたツールに携わる人たちもそう言うでしょう。会社が必要とするスピードで動き続けられるようにするのは、まさに縁の下の力持ちのような仕事なのです。
大規模変更について言えるのは、それを可能にしているエコシステムの文化的な構成要素と技術的な部分を理解しなければ、その真価を味わえないということです。たとえば、広く浸透したテスト文化が必要です。私がこれをやれるためには、全員がテストを書いている必要があります。それらのテストの結果を見るためにどこを見ればいいかわかるように、単一のプラットフォームが必要です。全員が同じソフトウェアをビルドするように、共通のビルドツールがあるとよいでしょう。私がビルドする。あなたがビルドする。同じ結果が得られる。標準的なライブラリのセットが必要です。何かを差し替えていくときに、どのバージョンのライブラリがあなたでは動いて私では動かないのか、と探し回らずに済むように。標準化されたコードレビューが必要です。どのコードを変更すべきかわかるように、モノレポそのものの透明性が必要です。
大規模変更こそ、Googleにおける手作業の苦役よりも自動化を、というこの精神の究極の体現です。そしてそれはエコシステム全体があってこそ可能になります。私たちの開発環境のどこか一部を指して、これが大規模変更を可能にしているんだ、とは言えません。すべてがつながり合っているのです。
さて、どの開発者エコシステムも、皆さんのものも、これまで働いたことのあるどんなところも、こうした創発的特性を持っています。それはたいてい、自分の職場に固有だと感じられるものです。なぜなら、それはたいてい、どう働きたいかを形づくるために皆さんが下してきた選択の星座の結果だからです。ですからどのエコシステムにもこういうものがあります。Googleには大規模変更がある。皆さんには別の何かがあるのです。
トレードオフが組織の価値観を映す
Googleの開発者エコシステムは、私たちの特定のエンジニアリング文化に埋め込まれた形で、独自のトレードオフのセットを生み出してきました。それらは私たちの技術的、ビジネス的なゴールに資するものです。しかしながら、Googleのエコシステムも、あらゆるエコシステムと同じように、すべてのタスクで卓越できるわけではありません。私たちは極端なスケール、セキュリティ、パフォーマンスのために最適化することを選んできました。そして、ときにそれが開発者の生産性を犠牲にすることになっても、たいていそうします。それは私たちのエコシステムにおいて、私たちが進んで受け入れているトレードオフです。
たとえば5人のスタートアップのような他の場所の開発者エコシステムは、まったく違って見えるでしょう。それでいいのです。5人のスタートアップでは、速度と機敏さこそが、持ち得る最も重要なものです。
5人のスタートアップとGoogleの中間のどこか、そこに皆さんはいるわけですよね。ほとんどの皆さんは、5人から20万人のあいだのどこかのエコシステムに住んでいるはずです。皆さんが下すことになるトレードオフには、本当に注意を払う価値があります。なぜなら、下されているトレードオフを見れば、その組織の価値観が理解できるようになるからです。本当に何を大切にしているのか。大切にしていると口で言っていることではなく、皆さんの組織が実際に何を大切にしているのか。そしてその価値観を理解したとき、これから展開していく変革を、形づくり始めることができるのです。
私たちは今、まさに大きな変革を経験しています。だから、私たちがどこへ向かっているのかを理解しておくのは良いことでしょう。これで、ソフトウェアエコシステムという概念が、もう少しはっきりしてきたかと思います。そろそろ、この部屋にいるトークンを食らう巨象について話す時が来たと思います。
AIファーストの開発者エコシステムとは
AIファーストの開発者エコシステムとは、実際どんなものになるのでしょうか。こういうものをゼロから、まっさらな状態のエコシステムとして構築できればいいのですが、皆さんの誰もそんな贅沢は許されていないでしょう。皆さんは全員、ソフトウェアを出荷し続け、今日やっていることをやり続けなければなりません。しかも、そのありとあらゆる部分を文字通り入れ替えながら、です。大したことないですよね。皆さんの会社は、皆さんが価値を届け続け、何も壊れないようにすることを当てにしているのです。
何も壊れないようにするために、ひとつ質問させてください。皆さんは今日、自分の開発者エコシステムをどれだけよく理解していますか。それをすべて図に描き出せますか。すべての部品がどこにあるか、技術的なものだけでなく、社会的なものも含めて、わかっていますか。自分のエコシステムが実際に何から成り立っているのか、列挙できますか。組織内の他の人たちはそれをどれだけ理解しているでしょうか。その強みは何か、弱みは何か。ボトルネックはどこにあるのか。どこで制約され、どこで自由なのか。どんな選択肢の余地を持っているのか。自分のエコシステムでどんな創発的特性を見てきたか。そしておそらく最も重要なこととして、もし皆さんのエコシステムが、たとえばこれから18か月で10倍から15倍に成長しなければならなくなったら、最初に何が壊れるかわかりますか。
この最後の質問について言えることは、私たちは全員これにすぐ答えなければならなくなる、ということです。なぜなら、地球上のあらゆる開発者エコシステムが、根本的な変革を経つつあるからです。皆さんのところにはまだ届いていないかもしれません。でも、来ます。一つひとつの開発者エコシステムが、この10倍の瞬間という考えと格闘しなければならなくなるのです。
これを回避する道があると言えればいいのですが、来てしまうのです。これは信じられないほどの時代です。でも同時に、いくらか混乱した時代でもあります。私たちが過去25年にわたって意図的に進化させてきたトレードオフのすべてが、再び調整し直されることになります。これは、おそらくこの場のどの登壇者からも、何らかの形で聞いたことでしょう。
未来がどうなるか、私たちはまだわかりません。把握しようとしている最中です。10倍、100倍に見える生産性を予測する人もいます。私たちは桁数で物事を測っているのです。それはとても大きな数字です。突然、10倍成長という問いが、単なる思考実験ではなくなります。皆さんと皆さんの会社にとって、いわばコードレッドの瞬間になるのです。これを把握しなければなりません。今日でなくとも、確実にこれから12か月のうちには。
その前にどうしても強調しておきたいのは、コードを10倍速く生成することと、10倍速くエンジニアリングすることのあいだには大きな違いがある、ということを私は理解しているということです。これらは別物です。実際、Googleではよくこう言います。エンジニアリングとは、時間で積分されたプログラミングだ、と。でも実態として、私たちはプログラミングを大幅に高速化しています。コードを生み出す機械を速く走らせている。ですから、その機械の周りでどうエンジニアリングを行い、顧客に本物の成果を届けるかを、私たちは把握しなければならないのです。
この生産性の伸びをどこまで押し進められるのか、まだ誰にもわかりません。私も本当にわかりません。来週には止まるかもしれない。そうは思いませんけれど。でもひとつ確かなのは、ここから上がっていくということです。
問題は、私たちにはやるべきことがたくさんあると思う、ということです。なぜなら、今日私たちがやっていることは10倍ではうまくいかない、と私はかなりの大金を賭けてもいいからです。皆さんがソフトウェアを作っているやり方、私がソフトウェアを出荷しているやり方は、10倍や100倍の速度ではうまくいかない、と賭けてもいい。何かを変えなければならないのです。
各ノードに10倍が押し寄せると何が起きるか
では、標準的な開発者エコシステムを見ることから始めましょう。簡略化してあります、わかっています。ここに並んでいる用語のいくつかは見覚えがあるといいのですが。でも、皆さんがもっと見慣れた形に直してみましょう。複雑なグラフですね。生産性が10倍、いや、活動量が10倍になった世界では、何が変わらなければならないのでしょうか。
まず、コードをコードベースに取り込むことに関わるノードから始めましょう。ちなみに、テストとバージョン管理はあえて除いてあります。それらについてはあとで触れます。緑のノードが突然10倍多くのことをしなければならなくなったら、何が起こるでしょうか。
ソースコードを書くことから始めましょう。みんながコードを書くのがずっと速くなれば、おそらくコードはずっと多くなりますよね。それは良くありません。ここで、ジェフ・アトウッドの古い言葉を思い出してもらうのにちょうどいいタイミングです。ソフトウェアは負債である、と。だからのっけから、10倍のコードは10倍の負債なのです。私たちは良い状況にはいません。
ところで、お気づきかもしれませんが、みんなにトークンを大量に手渡して、幸運を祈る、というわけにはいきません。だから再教育に投資していることを願います。再教育に投資していますよね。エンジニアリングのプラクティスがどこに文書化されているか、わかっていますか。必要になったとき、それをどう進化させればいいかわかりますか。まあ、家に帰ったときに考えてみるべきことですね。
ビルドシステムにさっと移りましょう。少なくとも、コードが増えればコンパイル時間が増えることを意味します。システムが大きくなれば、コンパイル時間が増える。まさにこれが欲しかったものですよね。皆さんの会社で、コンパイルが遅いと文句を言った人なんて一人もいないと思いますけど。さて、どうなると思いますか。もっと遅くなります。そして、もしエージェントが大量の作業を進めているとしたら、それはコンパイルが増えることを意味します。大きくなるだけでなく、回数も増えるのです。コンパイルは、時間においても計算資源においてもタダではありません。そして、自分がコンパイルにどれだけの時間を費やしているか、気づいたことすらないかもしれません。でも保証します、10倍大きくなれば、何かしら気づくことになります。
そのコード全部の設計についてはどうでしょう。疎結合を促すための適切なエージェント向けスキルを持っていますか。能力を素早く安全に組み合わせられるようにするための、適切なサーバーフレームワークはどうですか。考えてみれば、皆さんの会社では今日、ウェブアプリケーションが何通りの方法で提供されているか、知っていますか。実際にいくつの異なるサーバーフレームワークが動いているか、知っていますか。私は実のところ知りません。エージェントがそのコードを全部書くとしたら、コンポーネントの再利用をどう管理するつもりですか。たぶん、そんなのは問題にならないと踏んでいるのかもしれません。でも、エージェントが書きやすくて、皆さんにとっては保守しにくいコードを書いたとしても、驚かないでください。今のところ、それが標準的なベンチマークのようですから。
エージェントはコードを書くのが得意です。でも、皆さんや私が必要とするのと同じように長期的に考えてくれるとは限りません。そのコードは、きっとうまく構造化されてはいないでしょう。それでいいんです。その部分はなんとかします。でも本当のところ、エージェントは今、私たちのために大量の作業をこなしています。私たちは、それをどう最も効果的に活かすかを、毎日毎日把握していかなければならないのです。
ある時点で、そのエージェントによる作業すべてが、バイナリを大きくしすぎて、もうコンパイルできなくなるかもしれません。あるいは大きくなりすぎて、もう携帯電話に載せて出荷できなくなるかもしれません。コンパイルできるバイナリの最大サイズはどれくらいか、なんて問いを立てたことはありますか。私も実のところ、その答えを知りません。でも、Googleで限界にぶつかりつつあるのはわかっています。一部の場所でバイナリが大きくなりすぎて、もうコンパイルできなくなっているのです。なんとかするでしょう、それは確信しています。でも本当のところ、大きいということには多くの帰結があります。スケールはあらゆる場所に影響を及ぼすのです。
ひょっとしたら皆さんはマイクロサービス派で、私を見ながら、なぜそんなに大きなサービスを作るんだ、うちのサービスはどれも小さいぞ、と思っているかもしれません。それは結構なことです。でも、こちらにも質問があります。10倍のネットワークトラフィック、10倍のサービス、10倍のおしゃべり、10倍のネットワークトラフィックで何が起きるでしょうか。その準備はできていますか。誰も無傷ではこの場を切り抜けられません。スケールはあらゆる場所に影響を及ぼすのです。
コードレビューとトークンの問題
さて、このコード全部を確実にコンパイルできないとしましょう。きっとできませんよね。皆さんのコードレビュープロセスはどうなるでしょう。今、誰もがコードレビューを心配しています。それには十分な理由があると思います。私たちはこの非常に人間的なプロセスに大きな圧力をかけている。そして多くの場合、それはボトルネックになりつつあります。人間について私が知っていることがひとつあります。彼らはボトルネックになるのを嫌います。圧力をかけられると、おかしな振る舞いをするのです。
10倍のコードがあれば、二つのうちのどちらかになります。10倍大きな変更か、10倍多くの変更です。それは皆さんのコードレビュアーにとって何を意味するでしょう。賭けてもいいですが、皆さんのテックリードのほとんどは、1日に、そうですね、10倍開発者のうち5人を通すために必要なレビューの速度すら、維持できないでしょう。それは膨大な作業です。だから彼らはボトルネックにならないために、プロセスを並べ替え始めます。誰も妨げないように、手を抜き始めるのです。なぜなら、誰も足を引っ張る人になりたくないからです。
これの一部はAIで解決できるかもしれません。それは認めましょう。AIを投入してレビュープロセスを良くできるかもしれない。いいでしょう。でもそれは問題の一部しか解決しません。なぜなら、チームの人々がコードを書いていないなら、彼らがコードに出会う唯一の機会はレビューのときだけだからです。でも、レビューのときにはそれほど注意を払っていない。それはさっき言った通りです。では、進化していくコードベースに注意を払っているのは誰なのか。誰もいないのです。じきに、皆さんのコードベースは、誰も理解できない混沌になってしまいます。
そのソースコードすべてに加えて、トークン管理についても考えなければなりません。なぜならトークンは高価だからです。皆さんの一部はおそらくご存じでしょう。スケールにおいては、トークンは私たちが計算に入れなければならない実在のコストです。会社の全員が10倍のトークン、あるいは100倍のトークンを使い始めたら、何が起こるでしょう。あるいは、ひと月分の予算をうっかり1日で使い切ってしまったら。これは私の友人に実際に起きたことです。その支出をどこに置くか優先順位をつけなければならないとしたら、どこに置くかわかりますか。そもそも、今トークンがどこに流れているのか把握できる可視性すら持っていますか。
このシステムの、このシンプルなシステムの、最初の数個のノードを見ただけで、すでに私たちは問題を見つけています。そして、いくつかの厄介な二次的影響が出てくることは、もう明らかです。
テストとバージョン管理の特殊性
ではテストとバージョン管理に移りましょう。これらは少し特殊です。皆さんは、自分のテストインフラがどれだけの計算資源を使っているか、見たことがありますか。皆さんはどうか知りませんが、Googleでは、私のテストが十分に速かったためしがありません。今日はテストが必要以上に速く回っているなあ、なんて言ったことは一度もありません。そもそも今でも十分なキャパシティがないのです。
でも、バージョン管理にランドするすべての変更はテストされなければなりません。それに加えて、エージェントはテストを走らせるのが大好きです。なぜなら、それが自分が良い仕事をしているかどうかを教えてくれるからです。つまりまたしても、エージェントが追加の作業をこなし、私にもやるべき作業が増えるのです。ですから、10倍のコミットとエージェントによるあの作業全部があると、いったいどれだけのテスト計算資源を使うことになるでしょう。
実は、それより悪いことになるかもしれません。なぜなら、Googleで私たちが見てきたのは、コードベースが大きくなるにつれて、依存関係グラフがコードベースのサイズに対して線形ではなく、二次的に大きくなる、ということだからです。ですから、もしコードベースが10倍大きくなって、何も壊れないと確信するためにすべての依存関係をテストしようとすると、100倍ものテストを走らせることになるかもしれません。1000倍のテストを走らせることになるかもしれない。これは本当に興味深い課題になるでしょう。そしてある時点で、皆さんの予算の項目に載ることになります。考えておくべきことです。
つまり、テストをより頻繁に走らせるだけでなく、テストそのものが100倍大きくなるかもしれないのです。率直に言って、もしテストがそんなに大きくならないとしたら、もしテスト計算資源にどれだけ使っているか心配していないとしたら、私はもっと心配です。なぜならそれは、おそらくそもそも十分なテストがないということだからです。そしてエージェントたちが、何が機能しているのかを知る術もなく、皆さんのコードベースのあちこちで無謀なことをやらかしているということなのです。
さて、それを解決できたとしましょう。コンパイルは解決した。テストも解決した。バージョン管理システムについて話しましょう。人気のあるバージョン管理システムのほとんどは、パフォーマンス向けには最適化されていません。まったくです。それらは一貫性と順序のために最適化されています。それが仕事なのです。彼らの仕事は完全な記録を保つことであって、すごく速く動くことではありません。皆さんのバージョン管理システムのパフォーマンスはどれくらいですか。1分間に何件のコミットを処理できますか。保証しますが、思っているより少ないですよ。皆さんが必要とする10倍の速度には、スケールしないでしょう。
そもそも最後に、自分のバージョン管理システムのパフォーマンスについて考えたのはいつのことですか。Gitの開発に携わっているのでもなければ、ないでしょう。正直なところ、バージョン管理のパフォーマンスについて話しているとしたら、何かがひどくおかしくなっている証拠です。私たちは今、開発者体験のはらわたの中にいるのです。はらわたです。でも、システム的な変化を目にするとき、起こるのはそういうことなのです。システム的な変化は、皆さんのシステムのあらゆる隅っこを見つけ出して、こう言うのです。おい、ちゃんと見てるか、と。だって、思ってもみなかったことがここにあるんだから。
それからついでに言っておくと、このバージョン管理の問題を、たくさんの小さなリポジトリで解決しようと考えている人たちには、ちょっとお知らせがあります。何百何千もの小さなリポジトリを抱えてその戦略を運用したことのある人に聞いてみてください。保証しますが、それはまったく新しい種類の課題のセットで、しかもそのどれもAIが必ずしも楽にしてくれるとは限らないのです。
容量以外の予期せぬ課題
ここまで、見てきたすべてのノードで問題にぶつかってきました。信じられないかもしれませんが、私たちはまだ比較的見つけやすいキャパシティ系のノードしか見ていないのです。これらは全部、ただ見つけられるものです。ある数字を取って、10を掛けて、それが良いか悪いかを問えばいいだけです。でも、他にもたくさんの予期せぬ課題があります。ですから、皆さんが心配したほうがいいと私が思うものを、ざっとリストで見ていきましょう。
まず、計算資源を超えた検証です。皆さんが今日使っている検証戦略は、おそらくたくさんのユニットテストと、いくつかの結合テストといったものでしょう。でも、10倍のコードと10倍のサービスがあれば、結合テストが品質戦略の最も重要な部分になります。今日の結合テストのセットアップに満足している人はどれくらいいますか。ライブ配信のために言っておきますと、手が一本も上がっていません。よし、いいでしょう。思った通りです。私も満足していません。結合テストは本当に難しい。そして今、私が望むようなやり方でそれをやるためのツールを、私は持っていないのです。
それから、私がブール値の連言と呼んでいる問題があります。今日ソフトウェアを出荷するためには、すべてのテストが通ることを要求します。すべてのブール値がグリーンになる。出荷する前にすべてが良好。これは理にかなったことです。でも、テストが100万個あったらどうなるでしょう。そして、100万個のテストを走らせるための基盤のインフラの実際の信頼性が疑わしいとしたら。すべてのブール値が真でなければならないようなソフトウェアの出荷は、不可能になるかもしれません。だから、新しい戦略が必要になります。おそらく、どのテストを走らせるのが正しいのかを見極めるための、何か統計的なものが。だって、全部を走らせることはできないのですから。
では、超特大の変更についてはどうでしょう。リファクタリングをして、言語やフレームワークを、どこででも変えられるというのは、本当にわくわくします。誰もができる。でも、何万行、何十万行、何百万行という単位で測られるマージコンフリクトを人々が管理できるようにするためのワークフローや社会的契約を、皆さんは持っていますか。おそらく持っていないでしょう。だから私たちは、非常に大きな変更セットが互いにすれ違いながら進んでいくのを支えるワークフローを、どう作るかを見極める必要があるのです。会社の全員がそれをできるなら、新しい戦略が必要になります。
それからついでに言うと、エージェントによる編集合戦を見たことはありますか。あるエージェントが変更を加える。すると別のエージェントが入ってきて、いや、その変更は気に入らない、別の変更にしよう、と言う。これ、見ている分には面白いんです。両側のトークン代を自分が払っているんだと気づくまではね。
リリース、内部API、そしてJevonsのパラドックス
リリースに移りましょう。皆さんは今日、顧客に何回リリースしていますか。毎日ですか。毎日やっているなら、かなり良いほうです。そうでないなら、皆さんには問題があります。10倍のソフトウェアがやってきます。そしてそのソフトウェアはどこかにランドしなければなりません。もし毎日リリースしていないなら、私の推測では、一つひとつの変更がこれからずっと大きくなっていきます。そして、私のSRE仲間が私に言うことがひとつあるとすれば、それは、非常に大きな変更は非常に恐ろしいということです。そんなことはやめましょう。
でも、コードはどこかへ行かなければなりません。価値を生むためにはデプロイされる必要がある。ですから、皆さんがおそらく試そうとすることのひとつは、より頻繁にリリースすることです。それは良いことです。DORAの仲間たちも誇りに思うでしょう。彼らはこう言うはずです。ええ、ぜひ、もっとリリースしてください、と。でもある時点で、収穫逓減のリリースに行き着きます。毎秒リリースするのは、おそらく大した価値を生まないでしょう。ですから、毎秒リリースと、私はまだ1日1回には至っていないというあたりの、その中間のどこかが、ちょうどよいバランスです。それでもコードは増え続けます。ですから私たちは、より多くのリスクを生まないように、そのコードをどこに置くかを見極める必要があるのです。
皆さんの内部APIはどうでしょう。ここまでソフトウェアを作ることについて話してきました。でも、すべてのAPIとデータを抱えた内部の開発者環境についてはどうでしょう。私が一緒に働く仲間たちに言っているのは、皆さんのすべてのAPIが、突然みんな公開されたも同然になった、ということです。それらは、公衆インターネットに送り出すものに施すのと同じ種類の堅牢化を必要とします。なぜか。エージェントは皆さんと交渉なんてしないからです。彼らはAPIを見つけ出し、それを呼び始めます。そしてもし皆さんのデータにアクセスできるなら、そうするでしょう。保証します。エージェントがあるデータセットにアクセスできるなら、それは彼らにとって利用可能なものなのです。ですから、内部のデータセットや内部のAPIに同じだけの考慮を払ってこなかったなら、非常に興味深い課題にぶつかることになります。なぜなら、エージェントは、皆さんがおそらく見つけてほしくなかったものを見つけ出すからです。
では、Jevonsのパラドックスはどうでしょう。これはおそらくこの12か月で私たちみんなが学んだ言葉です。これが何なのか、いや、どう発音するのかすら、誰も知りませんでした。でも今では、私たちみんながJevonについて知っています。Jevonはこう言います。ある資源が安く、効率的になるほど、私たちはそれをより多く使う、と。そして、トークンでまさにそれが見られますよね。私たちはトークンをいたるところに投入しています。そしてそれが、私たちの働き方や、働き方についての考え方を変えつつあります。私たちは今、これまで見えていなかった生産性の作業、以前は不可視だった作業に、コストをつけているのです。では、それは私たちの振る舞いをどう変えるのでしょうか。まだわかりません。
ところで、そのトークンエンジンをどこに置くかには注意が必要です。もし荷重を支えるようなトークンエンジンを配置すれば、おかしなことが起こり得ます。たとえば、ロールバックのプロセスが、エージェントに十分なキャパシティがあることに依存していたとしたら。誰かがそのエージェントをトークン予算の限界まで使い果たしてしまって、もうロールバックできなくなったとしたら、それはおそらく良くないことですよね。
ロールバックといえば、皆さんは今日ロールバックが基本的になぜ機能するか、知っていますか。それは、本番環境で問題を検知するのにかかる時間より、ほんの少しだけ遅くソフトウェアをリリースしているからです。もし、何かが間違っていると検知できるよりも速く、本当に本当に速くソフトウェアをリリースできるとしたら、それは皆さんのロールバック態勢にとって何を意味するでしょうか。これからは、すべてのロールバックが、その上に降ってくる複数の競合する変更と渡り合わなければならなくなります。ですから、ただ速くリリースすればいいというだけでは足りません。私たちはシステム全体を、ロールバックも含めて考えなければならないのです。それは本当に重要な安全弁です。
誰もがビルダーになる時代と人間の注意
誰もがビルダーである、という考えはどうでしょう。このカンファレンスは、誰もがビルダーであるという考えを称える場として大いに盛り上がってきました。それはかっこいいことだと思います。エンジニアリングの民主化はかっこいい。エンジニアリングを民主化してしまった、と気づくまでは。皆さんの会社にある、好きじゃない、置き換えられたらいいのにと思っているあのツール、わかりますよね。それが何であれ構いません。ここで名指しはしませんけれど。でも、これをバイブコーディングで代替品を作れたらなあ、と思っているツールがきっとあるはずです。さて、それを会社の全員が、使っているすべてのツールについて、掛け算してみてください。全員がまったく違うツールを使い始めたら、皆さんの会社の社会的な構造はどうなるでしょうか。運が良ければ、共通のデータ基盤があるでしょう。それは良いことです。そうすればすべてのデータが同じ場所に入っていきます。でも、もしなかったら。誰もがビルダーである、というのはかっこいい。みんなが作ったもの全部を保守しなければならなくなるまではね。
そして、新人開発者全員に課すことになる技術的リーダーシップのスピードランにも、少し思いを馳せましょう。リードになるのにこんなに時間がかかる理由は、判断を下すのを助けてくれる直感や判断力や専門知識を築き上げなければならないからです。なぜなら、チームを率いているときは、自分一人でやっているときよりも、はるかに大きな影響範囲があるからです。新卒が、50体のエージェントを自由に使える環境に足を踏み入れるのに、直感も判断力もまったく持ち合わせていなかったら、何がうまくいかなくなるでしょうか。10年分の経験を、どうやって6か月で教えればいいのか。私もまだわかりません。
そしてこの最後のものは、皆さんもよく耳にしているでしょう。特に、もしここにいたなら、前のトークでね。人間の注意は、私たちが持つ最も貴重な資源です。そして今、ノイズがあまりにも多い。あまりにも多くのエージェント、あまりにも多くのものが、私たちの注意を要求しています。私たちはこれをどう管理するかを見極めなければなりません。なぜなら、今のところ、それを本当にうまくやる方法を知らないからです。私たちは、注意を払いきれる以上の厄介ごとを自分で作り出すことができない、という事実の恩恵を受けてきました。そして今、それはもう当てはまらないのです。
システムとして考える
さて、ずいぶんたくさんあるように思えますね。それは、システムにおいてはすべてがつながっているからです。ちなみに、今挙げた課題はどれも、システムの中の単一のノードだけを見ていては解決できません。システム全体を見なければならないのです。エージェント開発に適応するためには、私たちは全員、常にシステムで考えることを学び始めなければならないと思います。
これを全部は説明しません。気が向いたらスクリーンショットを撮ってください。でも、システムについて考えるとき、心配すべきものはこういうことです。物事が大きくなること、時間をかけて生じる影響。因果関係はどちらの方向に動くのか。どのノードがすべての隣人と話しているのか。創発はどう見えるのか。どこからともなく出てくるものは何か。インセンティブはどうか、社会的なものも技術的なものも。そう、技術的なシステムもインセンティブを持ち得るのです。でも、自分のエコシステムの中のインセンティブには気をつけてください。キャパシティ、これは何度か言いました。今日もう一度くらい聞くことになるでしょう。フィードバックループとボトルネック。これらがシステム分析の道具です。
複雑に思えるかもしれません。でも、本当に必要なのは二つの問いだけです。なぜ、そして、もしだったら、です。なぜ私たちはこんなに結合テストが少ないのか。もしユニットテストよりも結合テストのほうが多かったら。なぜ私たちはこの特定のプログラミング言語を使っているのか。もしAIがすべてのコードを書いたら。なぜ、というのは、皆さんが自分のシステムの核心まで掘り進んで、それがどう機能するかを突き止めるために使うドリルです。もしだったら、というのは、突き止めたことに挑戦を突きつけます。そして少し想像力を働かせることを求めてきます。
皆さんはおそらく、なぜと問うのがとても得意です。顔を見ればわかります。皆さんはなぜと問う方法を知っている。なぜこれをやっているのか。なぜあれをやっているのか。でも、もしだったら、というのはもっと手強いものです。もしだったら、というのは怖くなり得ます。もし私たちが、自分が抱えていた問題に対して本当によく設計されていると思っていたプラクティスを捨てるよう求められたら。もしだったら、というのは怖くなり得ます。もしこんなふうにテストしなかったら。もしテストをまったく書かなかったら。まあ、調子に乗りすぎないようにしましょうね。でも、許しさえすれば、もしだったら、というのはかなりわくわくするものにもなり得るのです。
AIは増幅器である
そうした機会がどこにあるかを考えている皆さんに、私が見てきたあるパターンについてお話ししたいと思います。それは、AIが増幅器として働く、というパターンです。これを知った途端、私はそれをいたるところで見るようになりました。
このアイデアは私の手柄ではありません。実はDORAの仲間たちから来ています。彼らの去年のAI開発に関するレポートで、本当に物事を理解しているチームのあいだに、ある種の関係性を見つけたのです。彼らはAIを増幅器にする方法を理解していました。AIはより多くのことができる。AIは、より多くのテスト、より多くのドキュメント、より多くのコードをもたらしてくれる。でも、より多くの混乱もです。なぜなら、増幅というのは大きさであって、方向ではないからです。AIは、その全部がどこへ向かおうとお構いなしです。ただ、それをより多くもたらすだけなのです。
DORAが本当に見つけたのは、良い基礎を持つチームは、その増幅を有用な方向に適用できる、ということでした。そうなると、こんな問いが浮かびます。皆さんは自分の基礎についてどう感じていますか。皆さんの会社の意思決定の文化はどうですか。それを良くするために何ができるでしょうか。技術戦略はどうですか。誰か開発者の生産性に目を向けていますか。皆さんの組織の人たちは今日、どれだけうまく協働できていますか。セキュリティの態勢はどう見えますか。コードの健全性、リリースの衛生状態、信頼性はどうですか。
AIは、これらの問題をどれひとつ、放っておいて解決してはくれません。皆さんが持っているプラクティスが良いものであれば、それを増幅することはできる。でも、もし良くないものであれば、より多くの厄介ごとを引き起こすことになります。でも、しっかりした基礎があっても、私たちはかなりの旅路を控えています。私の推測では、これは推測ですよ、あとで確かめてもらって構いません、2030年には、今日の私たちの開発者エコシステムは、今の私たちにとっての2001年のように感じられるようになるでしょう。指摘しておくと、2001年には、私たちはCD-ROMでソフトウェアを出荷していたのですよね。2030年には、それくらい遠いところにいるかもしれないのです。
基礎を築くための指針
皆さんが基礎を築き続けるなかで、その道すがら考えられる他のことをいくつかお伝えしましょう。まず、そして最も重要なこととして、インフラのキャパシティを知る必要があります。どれだけの資源を使えるのかわからなければ、AIをデプロイすることも、計算資源をデプロイすることもできません。これを把握しておく良い方法が必要です。
次に、検証が必要です。なぜなら、検証していないソフトウェアを出荷することはできない、少なくとも出荷すべきではないからです。でも前にも言ったように、検証は変わっていきます。ですから、検証戦略が必要になります。今こそそれを見極めるときです。
それを超えて、隔離が必要です。なぜなら、これまでコードを使ってこなかったような、さまざまな目的のための大量のコードが手に入ることになるからです。それはそれでいいんです。でも、あのかっこいいプロトタイプのコードが、本番環境にまぎれ込んでほしくはありません。だから隔離を気にかける必要があります。楽しい部分が、お金を生み出す部分に影響を与えないようにしなければなりません。
そして最後に、抽象化を気にかける必要があります。私たちは、開発者が悪い選択をしてしまわないように抽象化を作ります。だからこそライブラリやフレームワークなどを作るのです。今日、私たちはウェブサーバーをゼロから作ったりはしません。フレームワークがありますから。なぜなら、物事を間違えるやり方はたくさんあるからです。さて、エージェントにたくさんの意思決定をさせるのも、同じ帰結につながります。ですから私たちは、エージェントがしがみつける良い抽象化を必要としています。エージェントに悪い選択肢を与えてはいけません。
原則は変わらない、変わるのはプラクティス
皆さんは、エンジニアリングのプラクティスは神聖不可侵ではない、ということを受け入れなければなりません。プラクティスは変わります。重要なのは原則のほうです。それは言うは易く行うは難しです。わかっています。特に、私たちの原則の一部がプラクティスのように感じられるときには。それらが全部同じもののように感じられる。たとえばテストのように。もし、自分のチームがなぜこのやり方でソフトウェアをテストするのか、なぜリリースプロセスがこういうふうに機能するのか、本当に考えたことが一度もないなら、それを進化させることはできないでしょう。原則を理解することこそが、この10倍の瞬間を進んでいくなかで、物事を変えるための力と自信を与えてくれるのです。
ソフトウェアエンジニアであることが、本当に魅力的な時代です。嘘はつきません。私たちの仕事のあらゆる次元が再定義されつつあります。私たちはこれまで以上に創造性を働かせる必要があります。コンテキスト管理、トークンの経済性、モデルのドリフトといった問題に取り組むためのスキルが必要です。創造性が必要です。そして、何もかも最適化したいという誘惑に、あまり囚われすぎてもいけません。私たちは探索を奨励する必要があるのです。
私を夜も眠れなくさせている問題があります。それは、ただ最適化するだけでは解決できないとわかっている問題です。それは、私たちのコードベースが成長していくなかで、どうやってそれに対する知的な統御を保つのか、ということです。ちなみに知的な統御とは、目の前にあるものについて人間が推論できるか、ということを格好よく言っただけのものです。私たちはこの戦いに、少なくとも過去15年間、負け続けてきました。私たちの最大のシステムは、今日の私たちの誰もが頭の中で考えられるよりも、はるかに大きいのです。
それでいいんです。AIは私たちに機会を与えてくれると思います。AIは、こうした非常に大きなシステムを、システム全体として実際に理解し始めるための道具を与えてくれるかもしれません。たとえば、いや、たとえばではなく、もし万一、私たちがこの戦いに負け続けてきたと言っても信じてもらえないなら、ひとつ演習を提案させてください。チームに戻ったら、全員に皆さんのシステムのアーキテクチャ図を描いてもらってください。何種類の異なる絵が出てくるか見てみるのです。私たちはこの戦いに、長いあいだ負け続けてきたのです。
ですから私たちには助けが必要です。実のところ、私たちのソフトウェアシステムの多くは、本当に脆いものです。たった一行の悪いコード、あるいは一つの悪い設定フラグで、100万行のシステムを壊すことができてしまう。それは、変更を加えようとする前に二の足を踏ませる種類の脆さです。私が本当にわくわくしているAIの使い道のひとつが、こんな考えです。継続的に更新される、ほとんど対話的なアーキテクチャの空間を手に入れて、そこに問いを投げかけられるようになる、というものです。たとえば、ここからキャパシティを取って東海岸に移したらどうなるか、とか。あるいは、ユーザーの伸びが突然40%跳ね上がったらどうなるか、とか。それを、ささやかな規模のシステムについてでさえ、今日やるのは事実上不可能です。変数が多すぎるし、知っておくべきことが多すぎるからです。でも、AIは非常に大きなデータの集合を理解することができます。ですから、そこには何かがあると思うのです。
でも、この問題について私が気に入っているのは、純粋にコードを生み出す機械を走らせることに集中するのではなく、私たちが作り上げたものへの理解をどう深められるか、と問うているところです。最もわくわくする問題のいくつかは、そこにあると私は思っています。
助け合いと当事者性
私たちの業界で変化が本当に速く起きていることは、否定しようがありません。それは、おそらく皆さんのほとんどがこれまで経験したことのないペースで起きています。皆さん全員が今できる最も重要なことのひとつは、もがいている誰かに、助けを申し出ることです。まだこれを理解できていない誰かに、手を差し伸べる人になってください。私たちはみんな違うスピードで動いています。みんなこの変化に違うやり方で対処しています。自分が取り残されているように感じるのは、とても簡単なことです。シニアエンジニアの皆さん、メンターになってください。行き詰まっている人を見つけて、助けてあげてください。もし自分のAI開発ワークフローを確立できたなら、それを人に共有してください。それは大事に抱え込む秘密ではありません。周りの人たちを助けてあげてください。
もし皆さんがテクニカルリードなら、関わる必要があります。皆さんの会社でソフトウェアエンジニアリングがどう行われていくのか、その舵取りを助ける必要があります。そして決定的に重要なこととして、もしソフトウェアの品質やソフトウェアの設計を気にかけているなら、それを擁護するために自分の声を使わなければなりません。それをやるのは、この部屋にいる皆さんなのです。皆さんの上司はおそらくやらないでしょう。
さて、いささか不格好な比喩で締めくくる危険を冒すなら、もし私たちの開発者エコシステムを生きたエコシステムだと想像してみると、私たちはみんな、一本一本の枝についた一枚一枚の葉をじっと見つめ、まるで特別な生命体であるかのように一本一本の木を世話することに慣れきってしまっています。しかし、私たちが世話するのが一本の木ではなく、森全体になるまで、そう長くはかからないでしょう。そして、森を、一本一本の木を見て管理することはできません。森を管理するには、それをエコシステムとして見なければならないのです。
さて、システム的な変化の厄介なところはここです。それは、すべてのことが、あらゆる場所で、いっせいに起こるという性質を持っています。私たちの誰もが影響を及ぼすには大きすぎる、という性質を。今この瞬間、毎週のように押し寄せてくるように見える変化の波の中で、身を支えるために何かをつかむのは、不可能に感じられるかもしれません。でも、今しがた見つけたように、システムにおいては、すべてがつながっています。小さな行動が、大きな帰結をもたらし得るのです。
そう見えるかもしれないのとは裏腹に、AIによる変革は、皆さんの会社のリーダーたちだけの領分ではありません。彼らには彼らの果たすべき役割があります。でも、皆さんにもあるのです。第一線のソフトウェアエンジニアとして、この転換点の瞬間に、皆さんは、ソフトウェアエンジニアリングがこれからどうなるかを決める、その中心にいるのです。皆さんのツールから、ワークフローから、エンジニアリングのプラクティスから、エンジニアリングの文化まで。もしそこで働いているシステムが見えるなら、テコの支点を探すことができます。皆さんには、思っているよりもずっと多くの主体性があります。本当にあるのです。その主体性を使って、皆さんの組織のために、チームのために、そして皆さん自身のために、未来を創ってください。ありがとうございました。
コメント