Kent Beck 氏 略歴（当日投影資料P.12より）

AIへの不安は自然な反応か

川口氏：最近、多くのプログラマーがAIに対して不安を抱いているように感じます。この恐怖は自然なものなのでしょうか？

Kent氏：これまでとまったく同じ方法でプログラミングをつづけることはむずかしいでしょうね。AIに不安や脅威を感じる理由は、プログラマーたちの脳が注意を促しているサインだと思います。

このサインには、真正面から向き合うべきです。

川口氏：向き合う、ですか。

Kent氏：ええ。非常に有能なプログラマーでさえ、「AIは次に来る単語を予測しているだけだ」などと、AIを侮っているところをよく見かけます。

私からしてみれば、この反応は恐怖の裏返しにほかなりません。

私たちはみんな、自分の仕事がどう変わるのか不安に思っています。不安であるなら、いま私たちにできることを考え、とにかく試してみるとよいと思います。

それを繰り返すことで、急速に変化する状況にも対応できるようになりますよ。

AIで“プログラミングの楽しさ”をとりもどせた

川口氏：AIを学習の補助に使うという話もありますよね。私も最近、財務の知識を学ぶためにChatGPT を「知的スパーリングパートナー 」のように使ってみましたが、すごく有用でした。

Kentさんは、AIとどのように関わっていますか？

Kent氏：私がAIを使ってもっともよかったと思っているポイントは、プログラミングの楽しさを取り戻せたことです。

この20年ほどで、私はプログラミングの楽しさをすっかり忘れていました。ライブラリをアップデートしたら別の何かが壊れる、というようなことにうんざりしていました。

それに、面白いアイデアが浮かんだとしても、開発をはじめるまでの準備に4時間もかかって諦めてしまっていました。

川口氏：AIがその問題を解決してくれたのですね。

Kent氏：Genie AI（※） を 使えば、Python のセットアップ方法などを知らなくても、プログラミングをすぐにはじめることができます。

すばらしいことですよね。頭のなかにあるプロジェクトのアイデアを、次々と形にできるのですから。

（※）Genie AI：GitHub CopilotをはじめとするAIエージェントについて、Kent Beck氏が愛情を込めて語るときの呼称。

川口氏：かつては、自分が習得したツールを隅々まで知り尽くしたプログラマーに対して憧れのようなものがありました。Kentさんは新しい言語やツールを次々と試したいとおっしゃっていますが、それはなぜでしょうか？

Kent氏：学院時代に、ある経験をしたことがきっかけです。はじめてUNIX にふれたとき、学生たちは大きく2つのグループに分かれました。

1つのグループはいくつかの基本コマンドを覚えて、あとは自分の研究に集中する。そしてもう1つのグループは、新しいツールを見つけるたびにそれを学び、自分の研究に応用していく。

最初の1ヶ月は前者のグループの方が成果を上げていました。しかし2ヶ月目には、後者のグループが、はるかに多くの成果を上げるようになっていたのです。

私はつねに学びつづけたいし、発見しつづけたい。だから、見つけられる限りのコーディングを支援するAIツールを試しています。

それにいま、私たちは技術革命のまっただなかにいて、「どのツールが最適解か」なんてわからないですよね。だからこそ、探求する価値は非常に大きいと思っています。

プログラマー不要論と人間の新たな役割

川口氏：とはいえ、「もうプログラマーは必要ない」という極端な声も聞こえてきます。この点についてはどうお考えですか？

Kent氏：短期的な目で見ると、そうかもしれませんね。ですが、長期的に見れば、プログラム開発のコストは劇的に下がるでしょう。

そうすると、これまで採算が取れなかったようなアイデアでも、ビジネスとして成り立つようになる。結果として、より多くのプログラマーが求められることになると思います。

川口氏：なるほど。仕事がなくなるのではなく、仕事の内容が変わるのですね。

Kent氏：私たちが操作するレイヤーが変わるだけなのです。

かつてメモリ管理をしていたプログラマーがJava を使いはじめてその作業から解放されたように、AIの活用によって私たちはより高いレイヤーを、あるいはよりハードウェアに近い低いレイヤーを、同時に操作できるようになります。

もちろん、仕事の性質は変わりますが、プログラマーの需要はむしろ増えるでしょう。

速度と品質：AI時代のソフトウェア開発課題

川口氏：会場から質問が来ていますね。「AIによってコードの生産速度は上がりますが、その分テストと品質がより重要になるのではないでしょうか？」というものです。

Kent氏：その通りです。速度が上がれば、品質を担保する仕組みがより重要になります。私の経験上、AIを搭載したコーディングツールは驚くほどはやく、しかしときに予測不能なコードを生成します。

そのため、人間がコードを理解し、テストできるようにすることがいままで以上に大切になります。

信頼性の低いコンポーネントを使って、信頼性の高いシステムを構築するにはどうすればよいか。それは、AIに適切な制約をかけることです。

私はAIと対話するとき、「このデザインは却下します」「このコードの重複を解消してください」というように、AIが提示する解決策を制限することにより多くの時間を使っています。

川口氏：つまり、AIが提案するあらゆる可能性から、価値のあるものを選び取る役割が人間に求められるということですね。

Kent氏：そうです。こうした取り組みは、実は新しいことではありません。

Sun Microsystemsにいたころ、私たちは高価で信頼性の高いハードウェアを売っていましたが、Google は信頼性の低いハードウェアをソフトウェアで束ねることで業界を変えましたよね。

AIの世界でも同じような変革が起きるのです。

デザイン思考とオブザーバビリティ

川口氏：では、将来的に「AIがコードを書き、人間はテストを書くことに集中する」というような分業はあり得るのでしょうか？

Kent氏：テストはもちろん重要ですが、人間はデザインについても多くの思考を巡らせる必要があります。

例えば、「なぜこの2つの機能はわかれているんだ？もっとシンプルに統一すべきではないか？」といったデザイン思考は人間にしかできません。

川口氏：テストの概念も変わってきているのでしょうか？

Kent氏：テストの領域でも大きな変化が起きています。

例えば、ユニットテスト で扱われるような「正しいか／間違いか」の二元論的な正しさだけでなく、本番環境でしかわからない特性、つまりオブザーバビリティ （可観測性）もまた重視すべきです。

システムがどう動いているかをリアルタイムで観察し、理解する能力が、これからソフトウェアの品質を担保するうえでは重要になるでしょう。

「名前のない品質」とJUnitの普及

川口氏：会場から寄せられた質問をもう1つ。

「製品開発において、建築家クリストファー・アレグザンダーが提唱した『名前のない品質 （“QWAN―Quality Without a Name”）』を感じた経験はありますか？」ですね。

Kent氏：「名前のない品質」とは、「本当に人々の役に立つものがもつ、言葉では表現しがたい、全体が調和した性質」ですね。私の経験でいえば、1つはJUnit そのものです。

Javaが登場し、誰もが手探りで開発していた時代に、JUnitは当時のプログラミング環境や人々の理解度、開発方法に完璧にフィットしていました。

後に循環依存といったアーキテクチャ上の批判も受けましたが、それはJUnitが当時のニーズに的確に応えていた証拠とも言えます。

川口氏：そのJUnitですが、当時は開発者がテストを書くという文化がほとんどなかったにもかかわらず、野火のように広がりましたよね。なぜあれほどまでに受け入れられたのでしょうか？

Kent氏：1つは社会的な認識を変えたためでしょうね。

当時、テストを書くのは二流の仕事と見なされていましたが、プログラマーとして評価されていた私とエーリヒ・ガンマ が「これから活躍するプログラマーはテストを書くのが大好きなんだ」とビジョンを語ったんです。

もう1つは、フィードバックがはやく有用だったためです。Javaの登場で開発サイクルがはやまり、品質管理部門にテストを依頼していては間に合わなくなりました。

プログラマーが自らテストを書きはじめたのは、よりよいテストを求めたというより、自分のコードが正しいかどうかのフィードバックを、とにかくはやく得るためだったのです。

そしてJenkinsのようなツールもまた、テストを継続的に実行することで、その価値をさらに高めてくれました。これは技術と社会が共進化した好例です。

デプロイのリスクと成果測定の本質

川口氏：フィードバックといえば、多くの組織に「金曜日にデプロイしてはいけない」という暗黙のルールがありますよね。これについてはどう思われますか？

Kent氏：「なぜ金曜日にデプロイしてはいけないのか」、つまり「どういったリスクを恐れているのか」を突き止めることがもっとも重要だと思いますよ。

リスクが高いように思われるかもしれませんが、Facebook には、需要がピークの時間帯にデプロイするというルールがありました。

もっともシステムに負荷がかかっているときにこそ問題を表面化させ、すぐに対処するためです。

川口氏：開発の成果測定についても質問が来ていますね。「ソフトウェア開発の規模が拡大し、ツールへの投資も増えていますが、その成果測定はむずかしいですよね。

投資を正当化するために成果を測定せざるを得ない状況についてどう考えますか？」というものです。

Kent氏：どんな指標であれ、システムにプレッシャーをかけると、システムは望ましくない形で歪んでしまいます。

問題は測定そのものではなく、プレッシャーです。プレッシャーをかけるよりも、「エンジニア1人当たりの利益」といった、みんなが重要と考える指標の方がよりよいです。

川口氏：では、数字をどのように使えばいいのでしょうか？

Kent氏：数字は、システムを歪める圧力としてではなく、「なぜこの数字になっているのだろう？」と全員で話し合うための「対話のきっかけ」として使うべきです。そのほうが有益です。

AI革命を人間関係の深化へとつなげる

川口氏：最後の質問です。「ソフトウェアの生産性において、社会科学や心理学といった工学以外の知識は重要でしょうか？」こちらは、いかがでしょうか？

Kent氏：非常に重要だと思いますよ。なぜなら、私たちはソフトウェアを通じて社会を築こうとしているからです。問題の最終的な解決方法は、技術だけではなく、社会的な関係性のなかに見出されることがあります。

多くのソフトウェア開発は、「リソースが足りない」という前提で行われますが、私は「リソースは十分にある」という前提からはじめ、より多くのリソースを生み出すことに時間を使うべきだと考えています。

川口氏： XP自体も、技術的側面だけでなく社会的側面が重要だという思想に基づいているわけですね。

Kent氏：その通りです。XPは、ペアプログラミング やイテレーション といったプラクティスで知られていますが、その本質は「プログラマーのための、安全な社会的儀式の集まり」です。

AIの登場によって、私たちは孤立する危険性もありますが、逆にお互いをより深くつなげるためにAIを使うこともできます。

AIによる技術革命を乗り越えたとき、私たちがお互いにより深い人間関係を築けている。これが私にとっての理想です。

川口氏：Kentさん、本日は示唆に富むお話をありがとうございました。最後に、会場のみなさまにメッセージをお願いします。

Kent氏：思いつくこと、すべてを試してください。そして、何か面白いことを学んだら、どんなに小さなことでも構わないので、まわりの人と共有してください。

そうすれば、私たちはみんなで新しいツールに適応できるだけではなく、より効果的に使えるようになります。この大きな技術革命の時代を、お互いのつながりを深めながら乗り越えましょう。

イベント登壇資料はこちら

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）