Google I/O 2026

わたしはdisruptされる側なので、それを前提に行動する必要がある。しかしそれを前提にした行動が何かは不明である。なぜならほぼ全てのホワイトカラーは早晩disruptされるからである。期間の問題に過ぎない。

ここに自分の飛躍がある。時間差で運営して乗り換えていけばいいのに最終的にダメなら全部ダメと考えている。

価値判断が要求されるものやWETなものほどdisruptの速度は遅いが、されないとは到底思えない。水商売(人気商売)が代替されないtop tierに感じるが、その技術は全く育てていないし、考え方のレベルで慣れていない。自分のルールを変更することになってしまう。

私たちはずっと、テクノロジーを「使いこなす職人」の側にいた。一生懸命に身につけたスキルで世の中を変えようとしてきた。だが、そのスキルがいらなくなる、ということを、今のAIは見せつけている。私たち自身がDisruptされる側に立たされている。それを、I/Oという開発者の祭典の場で、Google自らが宣言しているように、私には見える。

この1年で、その感覚には加速度がついてきた。コードを書くという作業のかなりの部分が、もう専門技能ではなくなりつつある。ソフトウェア開発という行為そのものが民主化される方向に進んでいる。専門職としての開発者は不要になるのではないか、という想いを、私は今日さらに強くした。

IOの内容はわからないがこの感覚は常に感じている

ただひとつだけ、はっきり言えることがある。私は今日、モヤモヤしている。明確な答えを持っていない。

ここも自分の感覚と近いのではないか

Addy Osmaniは、...Chrome周りでの発信で広く知られていた...そのAddyが、今やエージェンティックコーディングの世界のオピニオンリーダーだ。役立つSkillsなども精力的に出してくれていて、私も日々参考にしている。

そのAddyが、こう言った。「今起きていることは100パーセントのアイデンティティのシフトであり、メンタルモデルのシフトである。コードの道筋に対するコントロールを、手放さなければならないからだ」。彼はさらに踏み込んだ。20年もソフトウェアを書いてきた人間にとって、これは気持ちのいいものじゃない。きつい。私たちはこのきつさを、まだ十分に語れていないとも言った。

Addyの話は「きつい」で終わらなかった。彼はきつさを認めたうえで、私たちがどこへ向かうかへと話を進めた。

これはむしろ、私たちを「プログラマー」から「エンジニア」へと押し上げる、ある種の強制力になる。彼はそう話した。同じfireside chatに登壇していたCiera Jaspan（Software Engineer）も、近いことを言っていた。「Programmers → Engineers」というのが、彼女が前向きに使った表現だ。シニアの定義も、もはや「他人が書けないコードを書ける」ことではない。「コンテキストを理解している」ことだ。

昨日の私は「使いこなす職人」という言葉を使った。今日、その職人は、構文を握る職人から、コンテキストを掴み、トレードオフを判断し、システム全体の構造に責任を持つ「エンジニア」へと押し上げられようとしている。

Cieraが紹介した自分のチームでの実話が、それを裏付けた。ある一週間、彼女のクロスファンクショナルなチームが、全員でAIの使い方を探った。週末に集まってみると、おかしなことが起きていた。ソフトウェアエンジニアたちはコードを書かずにドキュメントを書いていて、UXリサーチャーたちは逆にコードを書いていた。彼女はこれを「みんなが他人の仕事をジュニアレベルでやり、自分の仕事をシニアレベルでやっていた」と表現した。

...これまでの開発基盤やプロセスは、結局のところ「人間の処理速度」に合わせて組まれている。AIエージェントのスループットで開発が走るようになれば、その前提は通用しなくなる。だから根本から組み直さなければならないところが、いくらでも出てくる、というのだ。

https://www.youtube.com/watch?v=dgBLVm2L1P4

Demisの指摘は単純だ。人類はまだ、解決できていない領域を山ほど抱えている。創薬、医療、基礎科学。AIですら、まだそこに革命を起こせていない。

彼は、開発者不要論にこう反論している。

なぜみんな、そんなことを確信したように語っているのか、わたしにはまったくわかりません。

もしエンジニアの生産性が3倍、4倍になるのであれば、単純に3倍、4倍のことをやりたいだけです。

創薬研究からゲーム開発まで、まだやりたいことが山ほどあります。そうした（新規）プロジェクトに振り向けられるエンジニアが増えるなら、大歓迎です。

「開発者は不要になるのか」という問いの立て方は、間違っている。問うべきは、開発者の重心がどこに移るのか、だ。

どんなDevelopmentにも、先ほども書いたように、もともとResearchの要素は多少混じっていた。新しい問題に直面したとき、何が問題かを定義し、仮説を立て、解法を試す。それが「Dの作業」のなかに溶け込んで、意識されてこなかっただけだ。これからは、そのR比率を意識的に高めていく。

その向こう側にあるのは、ベストプラクティスがない領域を切り開くResearcherとしてのエンジニアだ。