※本記事は、Google I/O 2026の「Professional Development」セッションとして公開された動画「Build core skills to thrive as an AI-era developer」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=q_Jq4IgYImk でご覧いただけます。本記事では、動画の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
登壇者は、Google社内でDeveloper Intelligence Teamのリードを務めるNicole Forsgren氏とAndrew Macvean氏です。両氏はキャリアを通じてソフトウェアエンジニアという存在そのものを研究しており、エンジニアリングを取り巻く人、プロセス、ツール、システム、文化といったあらゆる要素を調査対象としています。本セッションは、Google I/O 2026のProfessional Developmentセッションの一環として公開されました。関連セッションの一覧は https://goo.gle/professional-develope... から、Google for Developersのチャンネル登録は https://goo.gle/developers からご確認いただけます。
1. オープニング:AIネイティブ時代の到来と本セッションの狙い
1.1 自己紹介と本セッションの前提
Andrew: 皆さん、こんにちは。今日はNicoleと私の二人でお話しします。私たちはGoogleのDeveloper Intelligence Teamのリードを務めており、キャリアを通じてソフトウェアエンジニアという存在そのものを研究してきました。人、プロセス、ツール、システム、そして文化まで、エンジニアリングを取り巻くあらゆる要素を調査対象にしています。
Nicole: まず私たちが強調したいのは、今がソフトウェアエンジニアリングにとって非常に大きな節目だということです。変化の大きさだけでなく、その変化のスピードそのものが際立っている、という指摘をよく目にします。
Andrew: そうですね。今日私たちが本当に答えたいのは、「AIネイティブの時代において、ソフトウェアエンジニアである私たちはどうすれば活躍し続けられるのか」という問いです。この問いに答えるために、今回はT字型のソフトウェアエンジニアリング像という枠組みを使って話を進めます。具体的には、いま現場で起きているパターンを紹介し、トップクラスのエンジニアが身につけているスキルや能力について詳しく掘り下げ、最後に皆さんが自分の役割をどう捉え直せばよいかという実践的なヒントもお伝えするつもりです。
1.2 AI導入の実態と生産性パラドックス
Andrew: 本題に入る前に、まず前提を揃えておきたいと思います。今何が実際に起きているのか、という点です。第一に、ソフトウェア開発の現場ではAIツールの導入がかなり広範囲に進んでいます。おそらくここにいる皆さんにとっても驚きではないでしょう。テック業界の専門職の大多数がすでにAIを使っており、多くの場合、かなり強く依存している状態です。
Andrew: 影響の大きさも顕著です。Google社内では、コードの4分の3がAIによって書かれています。一方で、「それは本当に生産性を上げているのか」という、非常にまっとうな疑問も出てきます。上がっているとして、それは10%なのか、10倍なのか、100倍なのか。実のところ、一部の現場では「生産性のパラドックス」とでも呼ぶべき現象が起きています。私たちのDORAチームが複数の企業を対象に行った調査によれば、AIの導入が進むほど個人レベルの生産性には恩恵がある一方で、チームレベルの生産性はむしろ低下することがあるのです。
Andrew: この1年、Google社内では非常に興味深いパターンが見えてきました。まず、明確な恩恵があります。AIが生成するコードの量や自律性が増しているだけでなく、適切な仕組みと環境さえ整っていれば、そのコードはきちんと長持ちする、ということです。今日のプレゼンテーションは、まさにそれを可能にするスキルと能力についての話です。
Nicole: もう一つ興味深いのは、トップラインの数字の裏にある行動の変化です。たとえばAIを最も積極的に活用しているエンジニアほど、実はコーディングに費やす時間、アイデアを練る時間、そして同僚とのコラボレーションに費やす時間が増えているんです。
Andrew: これは一見すると直感に反しますよね。AIに仕事を委ねているのだから、人間の活動量は減るはずだと思いがちです。ですが実際にはむしろ活動量が増えている。ただし、その活動の「形」が以前とは少し違うものになっている、ということなんです。私たちのトップパフォーマーは、AIにどんどん仕事を委任しながらも、以前より受け身ではなく、むしろ主体的に動いています。
Nicole: ただ、AIによる恩恵は一様ではないという点も強調しておきたいです。「ガベージイン・ガベージアウト」という古くからの格言がありますが、まさにその通りで、AIとの協働そのものを極めるだけでなく、そのAIを適用する文脈やドメインの理解も同時に極める必要がある、という研究結果が数多く出ています。
Andrew: そしてこれは、ここにいる皆さんには釈迦に説法かもしれませんが、ソフトウェアエンジニアリングはコーディングだけではありません。そもそもコーディングはボトルネックだったことは一度もないんです。私たちが扱っているのは非常に複雑な営みであり、真の恩恵を得るためには二つのことを認識する必要があります。一つ目は、AIをソフトウェア開発ライフサイクル全体、さらに言えばプロダクト開発ライフサイクル全体で捉えるべきだということ。コード生成をはるかに超えた領域でAIを考える必要があります。二つ目は、これは単に従来の働き方にAIを当てはめる話ではない、ということです。本当の変革が起きるのは、従来のプロセスそのものが進化し、あるいは変容したときです。私たちは今、複数のパラダイムシフトのただ中にいて、まったく新しいプロセスが生まれ、まったく新しい役割を担う人々がソフトウェア開発ライフサイクルに登場してきています。
1.3 変化への戸惑いとポジティブなメッセージ
Andrew: そこで冒頭の問いに戻りますが、これだけの変化に向き合うのは簡単なことではありません。ただ、今日は皆さんに二つの良い知らせをお伝えできると思っています。一つ目は、皆さんが今どう感じていたとしても、決して一人ではないということです。これについては社内外を問わず数多くの研究があり、複雑な感情が湧き上がっているのは事実として確認されています。
Andrew: 変化の規模とスピードを考えれば、これは何ら驚くことではありません。ワクワクする気持ちも本物ですし、チャンスが広がっているのも本物です。ただ同時に、それはとても大変なことでもあります。二つ目の良い知らせは、この講演そのものが、皆さんがこの状況を乗り越えて、AIネイティブの時代においても活躍し続けるための方法についての話だということです。魔法の杖のようなものはありませんが、活躍し続けるための道筋は確かに存在します。
Nicole: 私たちが得ている強力なエビデンスとして言えるのは、ソフトウェアエンジニアという役割の形が変わりつつあるにもかかわらず、この変化に意図的に向き合えば、この分野で働くうえで最もエキサイティングな時期になり得るし、そうあるべきだということです。
2. トップパフォーマーに見られる5つの行動パターン
2.1 高い視座で働く/意図を左にシフトする
Nicole: ありがとうございます、Andrew。ここからは、AIネイティブなアプローチを取り入れている私たちのハイパフォーマーたちに見られるパターンについてお話しします。まず個別の興味深い行動を紹介し、そのあとでソフトウェアエンジニアリングという役割そのものがどう拡張されているかという話に統合していきます。Andrewも触れた通り、私たちの仕事はエンジニアリングシステム全体とそこに含まれるあらゆる要素を測定し、研究することです。ですから私たちは、あるアイデアの種が生まれてから、それが実際にユーザーの手元に届くまでのエンドツーエンドの時間を測っています。つまり、単なるソフトウェアエンジニアリングやコーディングだけでなく、プロダクト開発プロセス全体を捉えているということです。
Nicole: そのシステムの中で、最も生産性の高いAIネイティブなエンジニアたちは、いくつかの点で従来とは異なる動き方をしています。これから5つのパターンを順に紹介します。一つ目は、彼らがより高い視座(altitude)で仕事をしているということです。エンジニアリングの知識に加えて、ビジネスの文脈やユーザーニーズへの理解を組み合わせています。何を作るか、どう作るかだけでなく、なぜそれを作るのかを深く考えているのです。これ自体は、これまでもシニアエンジニアに求められてきたことではあります。ただ、AIが実行のスピードを加速させている今だからこそ、これをうまくやることの重要性はかつてないほど高まっています。
Nicole: 二つ目は、意図(インテント)を左にシフトするという動きです。今日この会場でもすでに耳にされた方がいるかもしれません。従来「シフトレフト」といえば、テストやセキュリティの検討をライフサイクルのより早い段階に移すことを意味していました。しかし今は、より多くの作業がエージェントによって自律的に処理されるようになっています。だからこそ、私たちは意図そのものを左にシフトする必要があるのです。つまり、事前により多くの時間とエネルギーを費やして、計画を立て、明確な指示を説明し、トレードオフについて議論し、適切な文脈を与えるということです。これが意味するのは、根本的な「真実の源(source of truth)」が、コードそのものから離れつつあるということです。それは、事前に行われる構造化されたインテントの記述へとシフトしています。私たちのエンジニアは仕様ファイル(specification files)を書くようになっていますが、これは考えてみればプロダクト思考を明示的な形にしたものです。これはAIをより適切に導く助けになると同時に、過去よりもずっと明示的に意思決定を文書化することにもつながります。そしてこれが重要なのは、エージェントが実行を担う割合が増えるほど、構築の過程でこうしたトレードオフや意思決定を把握しておく必要があるからです。意図を記録せずに作ることは、たしかに魅力的です。週末にちょっと手を動かすだけなら、その方が楽しいかもしれません。しかしそれでは、誰もその根拠を理解できないプロトタイプができてしまうリスクを負うことになります。ですから、こうして絶えず進化していく知識を能動的に整理していくことは、深刻な認知的過負荷を防ぐための有効な戦略の一つなのです。
2.2 環境・システムを設計する/マイクロチームの台頭
Nicole: 先ほどの話を踏まえて三つ目のパターンに移ります。私たちのトップエンジニアは、いわゆる「バイブコーディング」をしているわけではありません。ただコードを生成させるためにプロンプトを打っているのではなく、彼らがしているのは環境そのもののデザインです。ガードレールを設定し、エージェントと人間が共通の目標、より広い目的に向かって協働できるようなシステムを作り上げています。これは、一人の人間の能力を超えたスケールで動くための、推論のシステムを作るようなものだとイメージしてください。ここには、エージェント、あるいはエージェントのチームをセットアップし、彼らに適切な文脈と適切なスキルを与えて行動できるようにすることも含まれます。私たちのトップエンジニアは、単に速いコードが欲しいわけではなく、検証済みで質の高いコードを求めています。ですから、こうしたエージェントのチームに実行を委任するとき、どうやって品質のバーを高く保つのか、エージェントはいつ行動すべきで、いつ互いに議論してより良い解決策を見出すべきなのかを知る必要があります。これはすべて、先ほどお話しした二つ目のパターン、つまり仕様ファイルとインテントの記述から生まれるものです。そして意図を早期に左にシフトして記録してはいても、フィードバックループがこのプロセスにとって非常に重要であることに変わりはありません。
Nicole: 四つ目のパターンとして、AIは単に人々の開発の「仕方」を変えているだけでなく、「誰が」開発できるかも変えています。人の職種と、その人が実際に担える業務やタスクの種類とが切り離されつつあるのです。これに伴って、私たちはマイクロチーム、つまり小規模でクロスファンクショナルなアジャイルなポッドの台頭も目にしています。こうしたチームはコミュニケーションのオーバーヘッドが少なく、コラボレーションのループがはるかに密です。彼らが活用し展開しているエージェントのおかげで、こうしたチームは大規模かつ高い速度で実行できます。ただ、これも意図を左にシフトしているからこそ可能になっているという点は繰り返し強調したいです。それによってエージェントへの委任をうまく行えるようになるからです。文脈、制約条件、目標、トレードオフ、成功基準を明確に言語化する必要があります。そうすることでエージェントは「どうやるか」を担当でき、すでに学習済みのミスを繰り返したり、無駄な試行錯誤を続けたりすることがなくなります。同時に、エージェントが適切なツールにアクセスし、データをナビゲートし、そのうえで人間と一緒に反復していけるようなシステム設計も必要になります。
2.3 科学的マインドセットと継続的な実験
Nicole: 五つ目、そして最後のパターンは、科学的なマインドセットを持ち、私たち全員が継続的に探求し続けることです。最先端で働き続けるためには、失敗に対してオープンである必要があります。物事の進むスピードがこれほど速い中では、最初から正解を出すことはもはや重要ではありません。重要なのは、動きながら学び、そこから反復し、その学びを学習する組織全体にフィードバックしていくことです。実際、私たちのエンジニアは毎週のように新しいアプローチを試し、その学びをシステムに体系化して戻すという投資をしています。ここでも、インテントとフィードバックループが鍵になります。ただランダムに探索して、その学びを一切記録せず、応用もしないのであれば、それは科学的なマインドセットとは呼べません。
Nicole: ここまでをまとめると、私たちが話しているのは、左へのシフト、上への視座のシフト、そしてシステム設計の三つです。システム設計には、環境そのものに加えて、その環境の中にいる人間、エージェント、ツールといった主体、さらにそれらすべてをつなぎ合わせる文化までが含まれます。これによって私たちは、最も重要な問題に労力を集中させ、できる限り速く学び適応しながら効果的に実行し、その学びをシステムへとフィードバックしていくことができるようになります。以上が、私たちが今回の変化の中で目にしている五つのパターンです。冒頭で立てた今日のゴールに立ち返ると、これらを統合して、AIネイティブの時代を生き抜くために必要な中核的スキルをどう考えるか、という枠組みへとつなげていきたいと思います。多少の繰り返しにはなりますが、今日お話ししている変化の点と点をしっかりつなげて強調したいと思います。
3. 進化するT字型エンジニアモデル
3.1 従来のT字型モデルのおさらい
Nicole: ここまでお話しした通り、私たちのトップパフォーマーは、ますますT字型の人材になってきています。T字型エンジニアという考え方自体は、決して新しいものではありません。皆さんもすでによくご存知だと思います。私たちもこの概念にはかなり馴染みがあります。ただ、その中でいくつかの新しい変化が見えてきています。まず、T字型エンジニアという言葉を聞いたことがない方のために基本的な前提を説明すると、Tの上部にある横棒は、ソフトウェアエンジニアリングという広いエコシステム全体にわたる、幅広い基礎知識を表しています。これは、すべての領域における専門性を意味するわけではなく、システムの主要な部分がどう機能しているかについての十分な理解を持っている、ということです。そして、Tの縦の軸は、そのエンジニアが持つ深く専門的な知識と実践的な専門性を表しています。それは特定の分野、たとえばフィンテックのような領域かもしれませんし、特定の技術スタックやフレームワークかもしれません。しかし、これこそが私たちの言う「深い専門性」です。
3.2 新しい横棒と両翼の拡張
Nicole: ただ、私たちが目にしているのは、このT字の形そのものの興味深い進化です。まず一つ目として、新しい横棒の層が加わっています。それは、AIと効果的に協働し、関わっていくためのスキルです。AIネイティブなエンジニアが、タスクごとの文脈に応じたAIの制約をきちんと理解できることは、もはや交渉の余地のない必須条件になっています。私たちは、AIの出力や品質を評価し、最終的にAIを効果的にステアリングできる能力が必要です。
Nicole: さらに、Tの両翼にも広がりが見られます。より広い視野が求められるようになっているのです。AIによって参入障壁が下がり、コーディングのスループットが大きく増加した結果、この文脈を理解することがこれまで以上に重要になっています。片方の腕にあたるのが「隣接エンジニアリング」です。AIがどんどん機能するコードを生み出すようになっているからこそ、私たちが行うべき重要な検討事項やトレードオフが、より前面に出てくる必要があります。もう一方の領域が「隣接非エンジニアリング」であり、具体的にはビジネスとユーザーの文脈に関わるものです。AIが「どうやってコードを書くか」を担えるようになった今だからこそ、私たちが解決しようとしているビジネス上・文脈上のニーズについて、きちんと考え、理解していることが求められます。
Nicole: 興味深いのは、これ自体はすでにシニアエンジニアに期待されてきたことだという点です。これは先ほども少し触れました。ただ、私たちのエンジニアがますます高い視座で働き、エージェントを活用してより多くのことができるようになっている今、状況が変わってきています。つまり違いは、第一に、AIを効果的に活用するという前提そのものがあること、そして第二に、これまでお話ししてきたさまざまな理由から、深さと広さの両方に対する必要性が、より一層シビアになっているということです。それをより強く実感するようになった、ということですね。私たちには隣接する知識も必要ですし、深い技術的知識も必要です。そうでなければ、AIは私たちがより速く誤った方向に進むことを助けてしまうだけになりかねません。
Andrew: ありがとうございます、Nicole。ここまで大丈夫でしょうか、皆さん。ここまで順調ですか。それでは、このモデルをもう少し詳しく分解していきます。T字型を構成する各スキル領域を順番に見ていきましょう。それぞれについて、Google社内でのエピソードをいくつか紹介していきます。まず強調したいのは、実際に現場で何が起きているのか、私たちが何を学んでいるのか、そしてT字全体の重要性をはっきりさせることです。そのうえで、皆さんがこうした行動や推奨されるプラクティスを身につけるために役立つ、実践的なヒントをまとめてお伝えしていきます。
4. コアエンジニアリングスキルと生成AI活用スキル
4.1 コアスキルの3つの変化と実践ヒント
Andrew: それでは、まずコアとなるソフトウェアエンジニアリングスキルから始めましょう。これらのスキルがどう進化しているかを理解するために、私たちの検索組織でのエピソードを紹介したいと思います。今、私たちのところでは、プロダクトマネージャーが機能をライブ実験まで一気通貫で出荷しています。彼らは従来型のコードを書いているわけではありません。彼らが使っているのは社内プラットフォームで、それが彼らのインテント、つまりユーザーやビジネスのニーズを、実際の本番の技術スタック上で動く機能へと翻訳してくれるのです。外から見ると、「PMがコードを書いて本番まで持っていけるなら、従来のコアなソフトウェアエンジニアリングスキルにはどんな役割が残っているのか」と思われるかもしれません。しかし実際のところ、これは非常に高度なプラットフォームなしには成立しません。システムアーキテクチャに関する深い専門性、さまざまな言語フレームワークの知見、スケーラビリティ要件や信頼性要件といったものが、すべてそのプラットフォームに作り込まれているのです。これは、エンジニアが抽象化のスタックをどんどん高いところへ登っていっている、という好例だと思います。エンジニアは個々の機能を手作りしているのではなく、それらの機能が安全に存在できるエコシステムそのものを精密に設計しているのです。これはむしろ、より高いレベルのエンジニアリングの深さを必要とすることなんです。
Andrew: こうした流れを踏まえて、私たちが見ている三つの具体的な変化についてお話しします。一つ目は、コード生成がどんどん速くなっているからこそ、効果的な検証がボトルネックになりうるということです。AIは強力な力の増幅装置になり得ますが、その出力を評価し、統合し、保守するための深い専門性を私たち自身が持っていなければなりません。ただし、AIがこれだけのスケールで動いている以上、これは一行ずつ手作業で検証するという話ではありません。認知的にそれは不可能です。むしろ重要なのは、効果的なフィードバックループを設定し、問題をリスクの低い環境で確実に捉え、そのデータを使ってエンジニアの注意を最も価値の高い、本当に必要な部分に向けることです。実際、私たちの社内プラットフォームは、機能を素早く試験し、安全な形でパフォーマンスデータを収集し、そのフィードバックループを使ってエンジニアの専門性が本当に必要とされる場所に的を絞れるように設計されています。
Andrew: これが二つ目のポイントにつながります。Nicoleもすでに触れていましたが、私たちのエンジニアはバイブコーディングをしているのではなく、コントロールしているのです。まさに精密なエンジニアリングです。もし深いエンジニアリングの理解がなければ、自分が構築しているシステムそのものを理解していなければ、AIは驚くほどのスピードで技術的負債や認知的負債を生み出すリスクを抱えることになります。だからこそ私たちのチームは社内プラットフォームの開発に取り組んできました。それによって、インテントから、機能し、高品質で、信頼性が高く、安全なコードへと至る開発を実現しようとしています。私たちのエンジニアは、システムの境界やガードレールを設定することを考えています。たとえば、エージェントが従うべき細かなスタイルガイドの規約を具体的に指定し、エージェントが逸脱し始めたときにそれを検知できるような適切なチェック機構を組み込んでいます。ご存知の通り、一部のモデルは非常に自信満々に見える傾向があります。大規模に運用していると、変更をそのまま丸ごと受け入れてしまいがちです。私が好きな言葉に「タスクは委任しても、判断は委任するな」というものがあります。モデルを正しい方向に押し進めるのは、まさに皆さんのコアなエンジニアリングスキルなのです。ここでも重要なのは、最小限のリスクで問題を捉え、是正できるような環境、つまりシステムを作ることです。私たちが避けたいのは知的な受動性です。だからこそフィードバックループがこれほど重要になります。エンドユーザーからのフィードバックやパフォーマンスに関するフィードバックを取得し、それをインテントへの適合度を測るために使うということです。オブザーバビリティも重要で、それによってガードレールが不足している箇所や、エージェントが適切な文脈を持たずに誤った前提で動いている箇所を特定できます。
Andrew: ここまで「深い専門性を維持しましょう」と言うのは簡単ですが、この速く変化し続ける環境の中で実際にどう実践すればよいのでしょうか。私たちのトップチームが実践している三つの具体的なヒントを紹介します。一つ目は、再実装を学習ツールとして活用することです。AIは非常に速く解決策を生成できるので、最初の草案をそのまま受け入れるのではなく、AIに一度それを解体させ、別のアプローチで再実装させます。そして、なぜそのアプローチを取ったのか、その過程で何を学んだのかをドキュメント化させるのです。これは、最初の前提を確認したり、抜け落ちている文脈を見つけたり、異なるアプローチが持つ含意を考え抜いたりするうえで、非常に有効です。二つ目は、自分が書いたわけではないコード、システムアーキテクチャ、エージェントの判断トレースについてウォークスルーを行うことです。エンジニアに自分が書いていないコードやシステムを説明してもらうことで、共有のメンタルモデルや、システムに対する理解を築く助けになります。ここではアナログな手法、つまりホワイトボードを使ったアプローチが非常に有効に機能しています。実際、私たちのチームでは、システムの中のロジックを言語化するために、ホワイトボーディングをますます多く取り入れる傾向が見られます。私たちにとって、コードはもはや第一級の成果物ではありません。インテントへの忠実さ、ビジネスとエンドユーザーの目標を達成できているか、そしてシステムに対する共有された理解こそが、意図的に届けるべき成果物になっているのです。三つ目は、皆さんもすでにご覧になっていると思いますが、スキルファイルやルールファイルなどを使って、チームの実践、期待値、組織的な知識を、一貫性のあるスケーラブルな形でエージェントに明示的にコード化するという実践です。これは、より高い信頼性を保ちながら大規模に文脈をエンジニアリングしていく方法だと言えます。私たちのトップチームは、エージェントをそのまま既製品として使うのではなく、構造化されたエージェントのロールプロファイルを作成し、キュレーションし、維持管理しています。そこには非常に具体的な振る舞いの属性が与えられ、私たちのシステムの中で効果的に機能するためのレシピが提供されています。「エージェントにとって良い振る舞いとは何か」を常に振り返り続けることを求められるということ自体が、コアなエンジニアリングスキルを研ぎ澄ませ続けるための、非常に良い方法なのです。それによって、自分が作ろうとしているシステムについての最新の理解を維持でき、何がうまくいっていて何がうまくいっていないのか、どうすればエージェントをより効果的にできるのかを知るためのフィードバックループを作ることができます。そして重要なのは、こうしたルールやシステムの仕様は、通常のコードと同じように、適切なバージョン管理とオブザーバビリティの実践のもとで扱われるべきだということです。
4.2 単一エージェント操縦からオーケストレーションへ
Nicole: ありがとうございます。次に、生成AIの活用についてお話しします。私たちのエンジニアがどのようにAIと協働し、AIが効果的に機能するための仕組みをどう構築しているのかを紹介したいと思います。ここでは、単なるAIの強化(enhancement)の時代から、AIネイティブなエンジニアリングへと本当に移行しつつあります。これは大きなメンタルモデルの転換であり、単一のエージェントを操縦する「指揮者」から、システム全体をまとめ上げる「オーケストレーター」へと役割が変わるということです。ここでは三つの原則が見えてきています。私たちのオーケストレーターは、非同期に動く複数のAIエージェントのチームを管理しています。それぞれのエージェントは独自のコンテキストウィンドウを持ち、それぞれ固有の責任領域を担っています。そして、その上に立つ人間のソフトウェアエンジニアが、環境を設定し、その流れを方向づける存在になります。私たちのエンジニアは、Andrewが話したようなスキルをエージェントに与えることで、直接的にも間接的にもエージェントの振る舞い方を教えています。これは要するに、タスクを実行するために必要な正確なレシピやツール、ドメイン知識をエージェントに与えるということです。
Nicole: このオーケストレーションへのシフトは新しいスキルです。いつ委任すべきで、いつ委任すべきでないかを見極める必要があります。私たちのトップチームは、自分たちの仕事について明確な人間のベースラインを設定し、検証にかかるオーバーヘッドを測定することで、この「自動化の罠」を回避しています。うまくいく確率が最も高いタスクを見つけるために、実験を重ねています。これによって、まだエージェントが遂行できないタスクや、人間のセンスと判断が本当に必要とされるタスクに、人間の注意を集中させ続けることができます。評価にかかるコストが新たなクリティカルボトルネックになっているため、私たちのエンジニアはシステム思考のスキルに深く関わらざるを得なくなっています。うまくいかない領域については、エージェントのトレースを分析し、システムのどこを改善できるかについて共通理解を築いていきます。それは、エージェントが使っていないツールの使い勝手の問題かもしれませんし、エージェント自身に与えられているスキルの問題かもしれません。一つの例が、敵対的なレビューエージェントです。私たちは、意思決定やエッジケースに疑問を投げかけさせるためにこうしたエージェントを展開しています。トレースは記録され、そこから学んだことをもとにインテントやエージェントのルールが更新されます。これらはすべて、基盤となるソフトウェアシステムに対する深い理解と、モデルやエージェントの強みと弱みを理解するAIスキルの両方があって初めて可能になることです。
Nicole: Google社内では、レビューが必要なコードの量が大幅に増加しています。そこで私たちはコードレビューエージェントを構築しています。その目的は、機能性、信頼性、パフォーマンス、ユーザビリティ、セキュリティ、そして保守性までも評価することです。私たちのゴールは人間のコードレビュアーをAIに置き換えることではなく、むしろより緊密なフィードバックループを作ることです。できるだけ早い段階で、できるだけ多くの問題を捕捉したいのです。そして、その問題をシステムにフィードバックしていきます。たとえば、どこで誤った前提が置かれていたかを記録しながら、人間の認知力を高価値なタスクのために温存するのです。だからこそ私たちは、シェパーディングエージェントという仕組みも作りました。これらのエージェントは、変更をCI/CDパイプラインの中で導いていく役割を担います。複数回にわたってレビューエージェントを起動させ、さらにリスク評価エージェントを活用します。このリスク評価エージェントは進行中の変更をスキャンし、リスクの高い変更に人間のレビューが必要だとフラグを立てます。ここでもやはり、ソフトウェアエンジニアには「タスクは委任しても、判断は委任するな」という原則が求められます。これは私たちのお気に入りの言葉の一つです。私たちのソフトウェアエンジニアは、ここで重要な役割を果たしています。まず、ユーザビリティや保守性といった概念について、期待値を定義する役割です。そもそもこれらの言葉が何を意味するのか、チームによってどう異なるのか、文脈によってどう変わってくるのかを定義する必要があります。次に、こうした概念の間にはしばしばトレードオフが存在します。どのような状況でパフォーマンスを優先し、どのような状況でユーザビリティを優先するのか。これを適用するには人間の判断とセンスが必要です。AIは私たちに情報を与え、検討しているトレードオフに潜むリスクを浮かび上がらせる助けにはなりますが、最終的な判断は人間から生まれるものです。
Nicole: 私たちがGoogle社内で今まさに取り組んでいる例として、TensorFlowに関するいくつかの移行作業があります。これは非常に複雑で繊細な作業です。単一のチャットボットを使うのではなく、私たちのチームは厳格な3エージェント体制を構築しました。一つ目は検証可能な移行ステップを生成するプランナーエージェント、二つ目はそのステップをグループ化するオーケストレーターエージェント、そして三つ目がそれらを実行するコーダーエージェントです。私たちのトップパフォーマンスなチームは、スタイルに関するルールやコーディングの好みといったベストプラクティスをコード化することで、単一のエージェントを超えたスケールを実現しています。このTensorFlowの移行の例では、異なるプレイブックがそれぞれのエージェントに与えられており、たとえばYouTubeのプロダクト領域での移行にはYouTube固有のプラクティスが使われるようになっています。
Nicole: もう一つ考慮すべき点が、エージェントの乱立、いわゆる「エージェントスプロール」です。たとえば、意味のある形で作業を追跡できるように、3体から5体程度のエージェントにとどめるべきだという意見もあります。私たちも概ねこれが最適な範囲だという点で一致しています。ただ、より多くのエージェント数を扱うマルチエージェントシステムの管理を支援するツールも、次々と登場してきています。ここまでお話ししてきた手法は、そうしたスケールへの対応にも役立つはずだと考えています。ここから最後のポイントにつながります。曖昧なプロンプトに頼って質の高い成果を期待することはできません。私たちには精密なエンジニアリングが必要です。ここで重要になってくるのが、プロダクト思考とアーキテクチャに関する意思決定が事前に文書化される、スペック駆動開発です。目標、制約、そしてその根拠は、タスクを実行するエージェントだけでなく、より広いチーム全体にとっても不可欠な文脈です。仕様書は、エージェントのロールやスキルと組み合わさることで、構築しているシステムの「何を」「なぜ」に関する真実の源になります。エージェントを大規模にガイドし、システムの理解と保守性を支えるために文書化されているのです。
4.3 GenAI活用の実践ヒント
Andrew: ここまで、隣接するスキルについても暗黙のうちに何度か触れてきました。実際、これらの能力はすべて常に相互に作用し合っているからです。先ほどのレビューエージェントは、この四つすべてを組み合わせている分かりやすい例だと言えます。
Nicole: それでは、私たちがエージェントとより効果的に協働するために、どうスキルアップしていけばよいのか。そして、皆さんの組織やシステムが、こうした新しい働き方を受け入れられるように準備するには、どうすればよいのか。まず強くお勧めしたいのは、評価(evals)に関するスキルアップです。検証が大きなボトルネックになっているからこそ、AIの出力をどう評価するかについて自信を持っている必要があります。ここでT字型エンジニアの全体像がまさに重要になってきます。現実的で、地に足のついた、関連性の高い評価を開発するには、AI、ソフトウェアエンジニアリング、そしてユーザーやビジネスに関するスキルの組み合わせが求められるからです。私たちの評価は、チーム全体で知識を共有するための重要な成果物でもあり、インテントを捉える方法の大きな一部でもあります。それらは「良い」とはどういうことかを定義する助けになります。
Nicole: 二つ目に、私たちのトップエンジニアは、自分自身の内省を行うだけでなく、エージェント自身にも継続的に内省させ、記録させています。これを私たちは「エージェントジャーナリング」のようなものだと捉えています。自分のエージェントが一日をどう認識していたか、システムのどこで詰まったのか、指示のどこで混乱したのか、どこで生産的だと感じたのかを見るのは、実に興味深いものです。こうした内省の記録は、私自身にとっても、そして私たち全員にとっても、AIとの協働の仕方をどう改善できるかについて洞察を与えてくれます。たとえば、使用する言語やフレームワークについて明確な指示を与えるといったことです。それだけでなく、エージェントを取り巻くエコシステム全体を改善することにもつながります。たとえば、あるエージェントが特定の社内ツールへのアクセスに一貫して苦労しているとしたら、それはツールのユーザビリティに解決すべき課題があるということかもしれません。
Nicole: 三つ目、これはすでに何度か触れましたが、私たちはエージェントのチームを構築したいと考えています。今こそ、単一のエージェントを超えて、厳格なルールとプロトコルを持ったバランスの取れたチームへとスケールしていく機会を積極的に活かすべき時です。
5. 隣接エンジニアリングと隣接非エンジニアリングのスキル
5.1 隣接エンジニアリングスキル
Andrew: それでは、隣接エンジニアリングという翼に話を移したいと思います。ここでは、サイバーセキュリティ、プライバシー、業界固有の規制、そしてデプロイのインフラといった領域が非常に重要になってきます。もし皆さんの組織が高品質な社内プラットフォームや強力なAPI、明確でしっかりとドキュメント化されたワークフローを持っているなら、AIは強力な協働者として機能します。しかし、断片化したツール群、サイロ化されたデータ、脆弱なインフラに苦しんでいるのであれば、AIは皆さんを救ってはくれません。単に技術的負債をより速く生み出す手助けをしてしまうだけです。私たちのDORAチームが行った素晴らしい研究が、まさにこの点を裏付けています。AIは増幅器であり、同時に鏡でもあるということです。既存の強みを増幅させると同時に、弱みをも映し出してしまう。この隣接エンジニアリングという翼こそ、放置すればAIが静かに、しかし致命的な負債を生み出しかねない領域なのです。
Andrew: そこで、これを緩和するための三つの原則についてお話ししたいと思います。一つ目は、先ほどご紹介した検索チームのPMのエピソードが、ここでも大いに関係してきます。ベストプラクティスを高品質な社内プラットフォームに直接組み込むことで、一行一行を手作業で書かなくても機能をリリースできるようになりました。これには数多くの隣接エンジニアリングスキルが必要です。たとえばデプロイ環境の理解、セキュリティ要件、信頼性要件についての理解に加えて、私たちがすでに議論してきた深いコアエンジニアリングスキルも欠かせません。私たちが特に誇りに思っている統計の一つは、AIによって書かれるコードの量が増加している一方で、障害の測定可能な増加や、システムの信頼性の低下は一切観測されていないということです。私たちが求めているのは、10倍のリスクを伴わない10倍の速度です。これを実現する一つの方法として、私たちは階層化されたリスク環境を作り出しました。アプリケーションごとに必要とされる環境が異なることを認識したうえでの取り組みです。たとえば、Google社内向けのアプリケーションであれば、10億人規模にスケールする必要はありません。ですから私たちのゴールは、プロトタイプから本番まで、より段階的かつ反復的な形で進めていくことです。こうした異なるリスクプロファイルを段階的に移行していくことで、影響範囲を適切に封じ込めながら、より速いフィードバックループを実現しています。これは、効果的な実験といった他の隣接エンジニアリングスキルにも関わってきます。機能がシステムの中をどんどん速く流れていく中で、それを適切に分離しながらユーザーに届け、そのパフォーマンスを測定可能な形で理解するにはどうすればよいのか。こうした環境や、重要なアーキテクチャ・デプロイ上の検討事項を考え抜くことは、私たちのエンジニアにとってますます重要な関わり方になってきています。
Andrew: では、実際にこうした筋力をどう鍛えればよいのでしょうか。私たちのトップチームが実践している四つのヒントを紹介します。一つ目は、非難のないポストモーテムの文化を強く推奨します。真に回復力のあるシステムを構築するには、障害やインシデントを記録し、読み、そして議論することを習慣化する必要があります。これは、エッジケースやスケールの限界、信頼性上の脅威に対する直感を養ううえで大いに役立ちます。また、エージェントをどう導き、どう指示するかを考えるうえでも、非常に貴重な文脈になります。たとえば、こうしたポストモーテムの文書を、Nicoleが話したエージェントの自己内省の記録や、オブザーバビリティのトレースと突き合わせることで、システムのどこでエッジケースが露呈しているのか、あるいはシステムの指示のどこが不明瞭なのかを見極めることができます。二つ目は、AIを構築のためだけでなく、ストレステストのためにも使うということです。バランスの取れたエージェントのロールという先ほどの話に戻りますが、明示的にレッドチームエージェントを立ち上げることで、悪意ある攻撃者の視点からシステムを見ることができます。エージェントに、システムをどう悪用するかを説明させることで、そうした攻撃の仕組みそのものに向き合わざるを得なくなります。ただ受動的に解決策を受け入れるのではなく、生成エージェントが見落としているかもしれない脆弱性を、自分自身とエージェントの両方が見抜けるように訓練していくのです。ここでもすでに触れましたが、システムやデータのマップをアナログな手法で描くという興味深い動きが再び高まっています。ホワイトボードはまさに引っ張りだこで、初期のアーキテクチャを考え抜くことに焦点が当てられています。パイプラインを手作業でトレースすることで、たとえばエンタープライズのコンプライアンスといったもののメンタルモデルを、一行のコードも書く前に構築することができます。ホワイトボード上でインテントをコード化することは、最初の前提に疑問を投げかけ、エージェントが実行に入る前に適切な文脈を持てるようにするための優れた方法です。最後に、オブザーバビリティはこのパズルの重要なピースです。機能がシステムの中を10倍の速さで流れているとしたら、それが実際の現場でどう振る舞っているかを監視できる必要があります。たとえば、私たちのキャリアの浅いエンジニアの一部が、不透明なパフォーマンス指標や、微妙なシステムの健全性の劣化によって行き詰まってしまい、自分たちがデプロイしている複雑な分散システムをどう診断すればよいか分からなくなっているという事例がありました。そこで私たちは、オブザーバビリティツールと統合されたデータエージェントへの投資を強化しました。このデータエージェントは、コード、エラーログ、パフォーマンスデータ、スタックトレースにアクセスできるものです。その結果、こうしたエンジニアたちが複雑なシステムをより適切に解釈し、理解できるようになったことが分かりました。これは、AIを構築のためだけでなく、理解のために使うという、もう一つの良い例だと思います。
5.2 隣接非エンジニアリングスキル
Nicole: ここからは、T字の最後の能力である隣接非エンジニアリングスキルについてお話しします。これは、ユーザーとビジネスのニーズとのより深い連携に関わるものです。エージェントが定型的なタスクの実行をより多く担えるようになった今、私たちのエンジニアには「何を」「なぜ」により重点を置くというミッションが与えられています。ただ、私たちの多くにとって、これは正直なところ居心地の悪いシフトでもあると認めなければなりません。私たちのDORAの研究では、多くの開発者が実際にアイデンティティの脅威に直面していることが浮き彫りになりました。私たちは歴史的に、コーディングという営みそのものから多くの価値を引き出してきたため、自分の価値をどう捉え、どう測るかを、意図的に見直していく必要があるのです。私たちは、自分たちの仕事が持つより広い価値に軸足を移していく必要があります。それは、実際の人間の問題やビジネス上の問題を解決することから生まれる価値です。私たちのエンジニアは、ますます「バリュートランスレーター」として振る舞うようになっています。ユーザーのニーズやビジネスのニーズを受け取り、それを精密な要件へと翻訳していくのです。ここで、パフォーマンス改善に関する機能要望を例に考えてみましょう。AIであれば、非効率なループを見つけて、リファクタリングすることはできるかもしれません。しかし、バリュートランスレーターはまず「誰にとって、どのような条件下でのパフォーマンス改善なのか」を問います。彼らは指標やユーザーからのフィードバックを見て、その変更を必要としている特定のユーザーセグメントを見つけ出します。そのうえで、実際にそのシナリオに影響する重要なコードパスを最適化するよう、AIを導いていくのです。これは、AIのリソースを正しい方向に向けるために、人間のセンスと判断がいかに不可欠であるかを示すもう一つの例です。ここでPeter Sengeの言葉を引用したいと思います。「最も効果的な人とは、自らのビジョンを保ち続けながら、同時に現在の現実を明確に見つめ続けられる人である」。これはまさに、私たちがここまで話してきたT字型エンジニアの姿を的確に捉えた言葉だと思います。彼らは、隣接するスキルのおかげで幅広いビジョンを形成する力を持ちながら、同時にエンジニアリングの深さのおかげで技術的な現実も深く理解しています。彼らは今日お話ししてきたシステムや実践を活用して、インテントを捉え、理解を維持し、私たちが構築を進める中で現在の現実という文脈を決して見失わないようにしているのです。
Nicole: さて、今日はT字型エンジニアについてお話ししていますが、よりT字型になっていっているのはソフトウェアエンジニアリングという職種だけではありません。私たちのプロダクトマネージャーやデータサイエンティスト、UXerにも、まったく同じ進化が見られます。先ほど、検索チームのPMについてのエピソードをお話ししましたね。安全で信頼性の高いプラットフォームを構築したのはソフトウェアエンジニアですが、もちろんPMたちも、自分たちの隣接スキルを広げてきています。彼らはもはやデザイナーから静的なモックが渡されるのを待つのではなく、アイデアから実際に動くシステムへと自ら進んでいっています。これによって、より機動力があり、より流動的なチームを作ることができます。それぞれの職能には依然として固有の強みと役割がありますが、その境界線は溶け始めています。たとえば、私が関わっている社内ツールの一つでは、PM、UX、エンジニアが全員コードを出荷しています。大きな課題については依然として一緒に取り組んでいますが、たとえばデザイナーの目により気になりやすいようなUIの些細な不具合については、そのデザイナー自身がそのまま修正して出荷してしまうのです。私にとって、これこそがこのT字型時代が持つ本当の力だと感じています。
Nicole: この話題だけで丸々1時間使えてしまうのですが、ここでは私たちが見てきた二つの簡単なヒントを紹介したいと思います。一つ目は、ユーザーからのフィードバックをすべてAIに要約させたいという誘惑に負けないことです。何百件ものユーザーフィードバックのログをそのままLLMに投げ込んで要約を求めるのは、非常に魅力的です。うまく使えばそのための余地もあるとは思いますが、アナログなホワイトボードセッションが増えているのと同じように、私たちは従来型の対面度の高いユーザーフィードバックセッションの増加も目にしています。私たちのエンジニアは、そこに深く関わることを本当に楽しんでいます。ユーザーの声に実際に宿る喜びや苛立ちを直接聞くことは、深い共感を育みますし、「なぜそれをやるのか」をより現実味のあるものにしてくれます。二つ目は、これも何度か触れてきましたが、スペック駆動開発です。仕様書こそを最終的なプロダクトの成果物として扱うということです。私たちのベストチームは、こうした仕様書を非常に大切に守っています。彼らの認知的なエネルギーの多くは、目標やビジネスロジック、エッジケースの制約について議論することに費やされています。この明確な言語化を早期に、そしてオープンな形で強制することで、チームは「なぜ」について確実に足並みを揃えられるようになり、エージェントもより繊細な組織的知識にアクセスできるようになります。誰もが光速でプロトタイプを作れる時代だからこそ、一瞬立ち止まってインテントを捉えることが、探求が単なる混沌に陥ってしまうのを防いでくれるのです。そして、こうした仕様書をコードと同じように扱っているからこそ、先ほど触れたレビューエージェントのようなツールを使って、実行に入る前に要件をストレステストしたり、論理的な矛盾がないかを確認したりすることが本当に可能になるのです。
6. 組織への提言とクロージング
6.1 リーダー・マネージャーへの3つの提言
Nicole: それでは、ここまでの内容を統合していきたいと思います。AIの間違いを見抜くために必要な深い専門性、エージェントの艦隊をオーケストレーションするためのスキル、システムを理解するための隣接エンジニアリング、そしてより広い文脈を与えてくれる隣接非エンジニアリングを組み合わせたとき、それこそがAIネイティブの時代を生き抜くために必要なものだと私たちは考えています。ここでお話ししているのは、人間とエージェントの双方にとってシグナルとノイズの比率を保ちながら、知識を捉え、翻訳していくスキルです。それによって、私たちは好循環を生み出す改善のシステムを持つことができます。今日お伝えしてきたフレームワークや能力、パターンが、皆さんが自分の役割をどう捉えるかについての有用な視点となり、あるいは何か試してみたいことのインスピレーションになれば嬉しく思います。
Nicole: 私たちはここで少し時間を取って、この会場にいるエンジニアリングマネージャーやリーダーの皆さんに向けてもお話ししたいと思います。エンジニアは組織の外で働いているわけではありませんし、一人きりで働いているわけでもありません。ですから、ここまでは主に個人の話に焦点を当ててきました。しかし、厳しい現実として、壊れたシステムの中でT字型の開発者を強制的に生み出すことはできません。私たちのDORAの研究が示す通り、そしてAndrewも触れた通り、AIは私たちの強みだけでなく、弱みも映し出す厳しい鏡になり得ます。整合性の取れたチームと強固なプラクティスがあれば、AIは価値の提供を加速させてくれます。しかし、断片化したツール群やサイロ化されたデータ、とりわけ非難の文化が存在する組織では、AIは皆さんを救ってはくれません。それは単に、そうしたボトルネックのすべてを露呈させるだけなのです。私はDemingのこの言葉が好きです。「悪いシステムは、良い人材にも常に打ち勝つ」。今まさに、私たちはエンジニアに対して、最も難しいアーキテクチャ上の意思決定に集中し、機械の出力を検証し、複数のエージェントの間で絶えずコンテキストスイッチを行うことを求めています。これは認知的に非常に消耗することです。10倍のアウトプットが10倍の認知負荷を伴ってはいけません。そうなれば、燃え尽きてしまいます。
Nicole: ですから、リーダーとして、エンジニアが安全に進化できる環境、つまり拡張されたT字型の役割を受け入れられるような環境を、どう作ればよいのでしょうか。私たちは三つの即座に取り組める変化をお勧めしています。一つ目は、生産性の測り方を再定義することです。プルリクエストの数、スループット、あるいは採用されたコード行数でチームを測るのはもうやめなければなりません。私たちが評価すべきなのは、成果と、満たされているビジネス上のニーズです。バランスの取れた価値の理解に基づいて、正しい成果に焦点を当てる必要があります。たとえば、もし速度だけを測定し、品質を一切測定しなければ、開発者はAIの出力を厳密に検証する時間を取らなくなり、その結果システムの不安定性が急激に高まってしまいます。私たちがお勧めするのは、バランスの取れた指標のポートフォリオです。これを始めるための良いリソースはたくさん存在しています。
Nicole: 二つ目は、この「生産的な苦闘」を積極的に守ることです。開発者がこうしたツールを学び、自分たちが構築しているシステムを理解するための時間を、業務時間の中に確保しなければなりません。アーキテクチャのウォークスルーを手作業で行ったり、新しいツールやアプローチを試したりすることを奨励し、ツールごとに問題への対処の仕方がどう異なるのかを学べるようにする必要があります。こうした重要なメンタルモデルを構築する余地を与えなければ、チームは単に認知的負債に溺れてしまうことになります。
Nicole: 三つ目は、徹底した心理的安全性を育むことです。私たちは今、実験の時代にいます。皆さんのチームは、失敗するようなエージェントによるワークフローを構築していくことになるでしょう。もし皆さんの組織文化がそうした失敗を罰するものであれば、開発者は自分たちがすでに持っているスキルや、これまでの安全なやり方に頼ってしまうようになります。私たちは、知的な失敗を称え、非難のないポストモーテムを作り出し、チーム全体がシステムの中で起きたミスから学べるようにする必要があります。ここまでお話ししてきたことはすべて、これまでも常に真実だったことです。ただ、私たちが繰り返し述べてきたように、AIはまさに鏡であり、増幅器なのです。
6.2 クロージングメッセージ
Nicole: 最後に、いくつかの点を明示的に確認し、改めて強調して締めくくりたいと思います。エージェントの労働力をマネジメントしながら複雑なシステムをアーキテクトすることは、疲れる話に聞こえるかもしれません。なぜなら、それは私たちを、この高い視座での意思決定の空間に、専ら留まらせることを強いるからです。ただ、その一筋の光として言えるのは、私たちの取り組みの性質が変わっていく一方で、私たちには依然として「作ることの喜び」が残っているということです。拡張されたT字型の開発者スキルセットに投資することで、皆さんはかつてないスピードで自分のアイデアが形になっていくのを目にすることができますし、それは皆さんを、本当に作りたいと思っているソフトウェアそのものに、より近づけてくれます。皆さんはソフトウェアエンジニアリングという職人技を置き去りにするわけではありません。むしろ、その最も高く、最もインパクトのあるレベルへと踏み出しているのです。そして最も大切なこととして、これは繰り返しになりますが、改めて申し上げたいと思います。ソフトウェアエンジニアという職能は消えてなくなるものではありません。ただ進化しているだけです。そして、もし何かあるとすれば、それはむしろこれまで以上に重要になっていくということです。
Nicole: ですから、私たちは左にシフトする必要があります。上にシフトする必要があります。そして、単なるコードの断片ではなく、システムそのものを設計することを考えていく必要があります。ご清聴ありがとうございました。