この記事は、2026/04/22 に行われた TechLead Conference 2026 にあった、和田氏と佐藤氏の Q&A セッションの内容をまとめたものです。
Slido を使ってオーディエンスから質問を募って回答したセッションだったのですが、その内容が大変勉強になるものだったため、ここにまとめておきます。

注意: この記事は筆者が会場で取ったメモに基づいて再構成したものであり、発言の正確な書き起こしではありません。文意を損なわないよう努めていますが、実際の発言とは表現や細部が異なる場合があります。内容に誤りがある場合は筆者の責任です。

まとめ

セッションでは AI 時代の勉強方向性、セキュリティと auto accept の両立、コードレビューのボトルネック問題、新卒・ジュニア教育の変化、理解容易性と変更容易性のトレードオフ、AI 活用の個人差への対処、サードパーティライブラリの価値の再考、そしてコーディングスキルのベースラインといった幅広いテーマが扱われました。

一貫していたのは「AI によってコーディングが速くなっても、それはもともとボトルネックではなかった」という制約理論に基づく視点と、「能力は外注できないが労力は外注できる」という AI との協業の基本姿勢です。教育については「質とスピードの原資は能力であり、教育に投資することは将来の質とスピードを作ること」という明確なメッセージがありました。また、AI 時代の開発は人間がチームを組んでエージェントと協働する「チームプログラミング」になっていくという展望が語られました。

AI 時代、エンジニアリングの勉強は広く浅くか、深くか

AI 時代の勉強の方向性として、フルスタックのようにエンジニアリングの分野を広く浅く勉強していくのがいいのか、専門分野に絞って深い知見を得ていくべきなのか、あるいは AI の使い方を学ぶべきなのか——という質問に対して。

和田氏： いきなり難しいですね。まず、広く浅くか深くかという問いについてですが、これは排他ではないと思っています。
まず、広く浅くはやったほうがいいと思います。ここ 2 年くらいでいうと、深掘りをしやすくなってきています。全体像として「どういうときに何が必要か」「どういう考え方があるか」といった問いを立てられれば、そこから連鎖的に深掘っていけるようになった。チャット型の AI を持っているようなイメージです。

これまでは、Google などの検索サイトに検索キーワードを入れられれば専門知識が得られた。でも、検索窓に入れるキーワードがわからないという壁がありました。もう一歩進んで、ふわっとした疑問から専門用語に辿り着けるようになってきた——これがチャット型の AI が出てきて、初学者教育という観点で大きく変わったところです。

ふわっとしたニーズや疑問から専門用語に辿り着けて、そこから深掘っていけるようになった。ということは、「ふわっとした問いを出せる」こと自体がやはり必要で、つまり AI に対して質問できるだけの全体感ですね。「こういう考え方がきっとあるはずだ」とか「こういう問題は誰かが既に踏んでいるはずだ」と思えること。ソフトウェアエンジニアリングにおける全体感——ライフサイクルの話もありますし、品質特性でいうと品質特性の中身のようなところもあります。隅々まで知っていなくていいので、都度ズームインして、AI と一緒に壁打ちしながら深掘っていけるような、広く浅い全体感を持っていることは必要だと思っています。

一方で、専門分野に絞って深い知見を得ていくということについては、自分の中でいくつか専門分野を持っていたほうが良いと思っています。かつ、それは実務に近いところが良い。皆さんもコーディングエージェントなどを使って AI と一緒にやっているとわかると思いますが、自分の専門分野に近ければ近いほど、AI が言っていることが正しくないときに気づけます。専門外であればあるほど、基本的に気づけません。自分の実務に近いところに関しては、AI が誤っている、あるいは他の考え方もある、という形で同格以上に議論できるだけの専門知識を持つことは、やはり大事だと思っています。

整理すると、広く深く全部を知っているのではなく、全体感を広く浅く掴んでいて、その都度 AI と一緒にズームインしていける。そして専門分野に関しては、きちんと同格以上の議論ができる。この 2 点がポイントです。

新人の場合は、これをこれから得ていくという話なので、焦らず学んでいくしかないと思います。ただ、学習の速度は、AI 時代になって上げられるようになってきました。これからの学習は AI 前提ですよね。AI をどうやってうまく使いこなして学んでいくか、自分のわからないところを放っておかずに進めていくかというところが大事になってくると思っています。

その意味で、私がいろいろな企業において勧めているのは、スコープを狭めてソフトウェアエンジニアリングという観点でいうと、「小さいソフトウェアの全部に関わる」ということをやりましょう、と初学者教育で伝えています。たとえば大きい会社に入ったり、歴史の長い——もう 5 年以上やっているような会社であれば、大体その会社に入ってやることは大きなものの一部を担うということになります。そこでしか得られない経験ももちろんありますが、どうしても全体感が得られにくい。だから、小さくていいので、自分しか使わないソフトウェアでいいので、その代わり最初から最後まで全部自分でやる。要件定義、設計、実装、テスト、デプロイ——とにかく全工程に関わる。ソフトウェアを最初から最後まで作るにはどんなことがあるのか、まず体験して全体感を得ましょうということを言っています。

佐藤氏： ちなみに、プログラミングは学んだほうがいいんですか？

和田氏： 僕は学んだほうがいいと思っています。 3 年、4 年、5 年くらいのスコープでいうと、コードが読めるかどうかで変わってくる。「自分でもできるけれど AI に任せる」のと「自分ではできないものを AI に任せる」のとでは、設計の感度やレビューの精度がやはり違ってきます。

ずっと先の未来の話はできませんが、近未来でいうと、AI との協業の基本姿勢は「汗をかいてもらう」ということです。僕はよく壇上で、「能力は外注できないけど労力は外注できる」と言っています。自分でも頑張ればできるものを AI に頑張ってもらう。自分が頑張ってもできないものは、AI に頑張ってもらえば一応できるけれど、できたものがどうあるべきなのかわからないし、できあがったものの良し悪しも判断できないから、結果としてふわっとした世界になってしまう。今後はだんだんそうなっていく部分もあるとは思いますが、それはそれとして、直近ではやはりそれではいけないと思っています。
なので、プログラミングは学んだほうがいいと思っているし、プログラミングを学ぶスピードはここ 2 年くらいで上がっているとも思います。

エージェントの auto accept を全員に推奨するのはセキュリティ上難しいが、どうクリアしているか

auto accept が基本だという話があったが、セキュリティのリテラシーが高くないメンバーも含めて全員にそれを推奨するのは、コンプライアンス担当としては難しいと感じている——そんな質問が寄せられた。

和田氏： これは難しい問題です。auto accept が基本というのは、あくまで私個人の話をしてしまったという感じで、僕は auto accept でフロー効率を取っていますということなんですね。それは、だいたいどうあるべきか知っているので、自分だったらこうする、AI がどうしているかをリアルタイムで確認しながら見ているだけという話です。リテラシーが高くないメンバーが auto accept すると、基本的には「AI がやってくれたから多分大丈夫」になってしまいますよね。

まず一つ押さえておきたいのは、auto accept はデプロイとイコールではないということです。デプロイの前に、たとえばリテラシーが高くないメンバーであれば他のメンバーのレビューを受けてからデプロイするという形になるので、そこがクオリティゲートになるだろうという話がまずあります。

セキュアプログラミングそのものについては、たとえば AI で言うとエージェントスキルのようなセキュアプログラミングを支援する仕組み、つまり AI にセキュアプログラミングをしてもらうための仕組みを導入していくのがやはりおすすめです。テストエンジニアよりもセキュリティエンジニアのほうが数が少ないので、セキュリティ周りは——品質の中にセキュリティがあるわけですが——いわゆる品質の適合性よりもさらに薄くなってしまいがちなんですね。なぜならチェックする人が少ないからです。だからこそ、ここは仕組みでカバーしていきたいところです。

具体的には、セキュリティスキャナーのような、そもそも AI が登場する前からあったものは当然今後も CI に組み込んでいきますし、それだけではなくて、もっとコードが生まれるタイミングで関与していきたいので、セキュリティのエージェントスキルなどを使っていく。

さらに言えば、AI 時代の開発はチームプログラミングになっていくだろうと考えています。つまり、人間が 2 人 1 組、3 人 1 組、4 人 1 組でコーディングエージェントとやりとりをする時代になっていくだろうと。なぜかというと、コーディングエージェントが次々と出してくるさまざまな要求やコードに対して、全部リアルタイムに判断できるだけの力を持った一個人というのは、いないと思われるからです。これからはさまざまな得意分野を持った人間側が、3 人とか 4 人のチームを組んで、コーディングエージェントとリアルタイムで強度の高い仕事をしていく。即断即決で回していくという時代になっていくだろうと考えています。

エージェントのほうはそもそも並列分散が得意なので、人間一人に対してエージェントが多数で押し寄せてくると、もう人間側は対応しきれません。だから人間側も複数人の体制で、強度の高い仕事をしていきましょうという感じなんじゃないかなと思っています。

リテラシーが高くないメンバーについては、仕組みでカバーすることもできるんですが、それ以上に教育が組み込まれていないといけません。リテラシーが低いまま AI 時代にいろいろやっていけるかというと、やっていけないと思うので。これまでの開発には教育が自然に組み込まれていたんですね。コードレビューがそうでしたし、ペアプログラミングがそうでした。コードレビューをやらなくなると、教育の場が一つなくなってしまうじゃないかという話なので、再びモブプログラミングやアンサンブルプログラミングのように人間側が複数になって、その中で議論したり、セキュリティに強いプログラマーがリアルタイムにコーディングエージェントに対して指摘しているところを目撃することで、セキュアプログラミングへの感度を高めていく。そういう OJT としての強い場をつくっていくというのは、今後あり得る方向性の一つなんじゃないかなと思っています。

佐藤氏： 確かにモブプログラミングという話が出ていましたが、うちの会社でも AI の使い方にかなり個人差が出ていて、うまく使えている人とまだ使いこなせていない人がいます。みんなで一緒にやる場面があれば、そうしたノウハウも共有できるのかなと感じました。

和田氏： そうですね。たとえばこれまでも、ペアプログラミングをしていてジュニアがシニアと一緒に作業しているとき、シニアがショートカットを駆使してマウスを使わずにコードを書いているのを見て、そういう世界があるのだと知るとか、だんだん教えてもらいながら身につけていくとか、そうやってうまくなっていくわけです。それと同じことが AI エージェントの時代にも起きる。他の人が使っているところや、プロンプトやスラッシュコマンドで何をやったのかというところから学ぶものがたくさんある。そこはやはり変わらないと思います。

佐藤氏： 一人でたくさんのエージェントを動かさなきゃと思っていると、ちゃんと活かしきれていないと感じてしまうけれど、何人かのチームでやっていれば、「ちょっと今休むからやっておいて」とチームメンバーに託すこともできるのかなと思いました。

コーディングエージェントが書いたコード・テストはすべてチェックするのか

和田氏： コードおよびテストコードをすべてチェックしているか、という問いに対しては、チェックしています。ただし、これは性格上そうしているという部分もあります。

先ほどの話にもつながりますが、ボトルネックは確かに移動しています。コードレビューはボトルネックの一つです。しかし、制約理論をベースに考えると、そもそもコーディングというのはこれまでボトルネックではなかったんですよね。コーディングエージェントが出てきたことによって「ボトルネックが解消された」と言われがちですが、そもそもコーディング自体はボトルネックではなかった。ボトルネックではないところを改善しても意味がない、というのは我々がたくさん学んできたことです。

コードレビューはボトルネックの一つだったので、そこはなんとかしないといけない。 2026 年のソフトウェアエンジニアのテーマの一つが、コードレビューというものをもう少し形を変えていく、別のところにいろいろ引っ越させていきましょう、というものになっています。それはいろいろうまくいったりいかなかったりしながら進んでいくでしょう。

では全量検査するかというと、当然しなくてもよいというタイミングや判断がやってくると思っています。たとえばテストコードをコーディングエージェントに書かせるとき、テストケースの網羅性を上げていく段階では、コードを全部見るというより「どういうテストケースを書いたか」を AI に報告させて、何をやろうとしているのかを見て、コード自体は見ないというやり方があります。僕個人ではあまりやっていませんが、僕が見ているチームではやっているところもありますし、それはそれでいいという話だと思います。

基本的に、コードレビューというのは最終成果物の詳細なレビューであり、情報の密度が高い。レビューの代わりになるものがあればそれでよいわけです。たとえば現場でやっていることとして、テストコードのレビューよりテスト結果のレビューのほうを先にやります。なぜかというと、テストコードの分量よりテスト結果の分量のほうが少なく、情報がギュッと凝縮されるからです。テスト結果をレビュー可能なフォーマットで出せれば、テストコードのレビューの代わりにテスト結果のレビューができる。さらに、テスト結果のどこを見ているかというのをスキル化すれば、自分以外の人でもテスト結果のレビューができるようになる。そうやって少しずつスケールさせていくという方向性はあると思います。
僕が全部チェックしているのは、まあ、趣味ですね。

リソース効率を上げても意味がないのはなぜか

和田氏： リソース効率というのは、たとえばプログラミングをするのが人だった時代の話でいうと、「どれだけ暇な人がいないか」「全員がひっきりなしにコードを書いている状態」を、仕事としてうまくいっていると捉える考え方でした。並列開発の度合いを高めれば高めるほどよい、並列開発できる仕組みにしよう、と。GitHub が出てきたとき何が良かったかというと、プルリクエストという形で並列開発ができるようになり、それが可視化されたことでした。

しかし、その結果何が起こったか。プルリクエストを作る人に対して、レビューしてマージできる人の数のほうがずっと少なかった。結果として、シニアエンジニアの前にはレビュー待ちのプルリクエストが積み上がっていく。シニアエンジニアが一番いいコードを書けるはずなのに、コードを書くのを諦めてレビューに全振りするしかないという状態になってしまった。これがここ 15 年くらいで起きたことです。

つまり、コーディングはボトルネックではなかった。どうせシニアエンジニアがレビューしないとマージできず、かつシニアエンジニアが関与していないコードだから品質も高くない。その結果、手戻りが起こりまくって大変なことになっていたわけです。「GitHub があればうまくいく」という期待を持っていたけれど、実際はそうではなかった。

そこで我々は『ザ・ゴール』などの制約理論の話を思い出して、「どこがボトルネックなのか」と問い直した。コードレビューがボトルネックである。コードレビューして、デプロイして、学びのループを回すというところが大事なのだから、その手前でいくら大量に作っても、制約理論でいえば在庫の無駄、トヨタ生産方式でいえば作りすぎの無駄にあたる。我々はすでにいろいろなものから学んできたはずなんです。

大事なのは全体のバリューストリームマッピングです。価値がどう流れて、最終的に付加価値生産性につながっていくか。価値を届けるべき人にどう届くのか。たとえばカスタマー向けのサービスを作っているのであれば、カスタマーの何らかの価値につながるところまで行って、初めてパイプがつながる。そのパイプの太さや本数が大事なのであって、パイプの中をいかにうまく流していくかのほうが大事だよ、というのを、我々ソフトウェアエンジニアはここ 20 年くらいで学んできた。それを再度きちんと再認識しましょう、ということだと思います。

佐藤氏： TOC がベースということですか？

和田氏： TOC とか、トヨタ生産方式とか、アジャイルソフトウェア開発が出てきてから再発見されたアイデアですね。

新卒・ジュニアエンジニアの教育はどう変わるか

和田氏： まさに今、各企業で教育が難しくなっているというのは実感としてあります。今は 4 月で新人研修のシーズンですが、私の仕事柄さまざまな企業の新人研修に関わるなかで、年々難易度が上がっています。前提が変わりまくってしまっているからですね。

「この時代にゆっくり育てる余裕があるのか」という空気が広がり始めていて、質問にもあった「小さなステップアップをしてもらう時間がなくなっているように感じる」というのは、まさに今の社会全体の温度感や雰囲気になっているところのほうが、どちらかというと問題です。実際には、小さなステップアップをしてもらう時間はあるんですよ。あるのに、それをやっていると他社に後れをとってしまうんじゃないかとか、何らかの焦りのようなものが常にある。ここは 2 、3 年前よりは明らかに変わってしまいました。

圧倒的な物的生産性を目の前にして、これがあればより早く、より高速に生産すれば価値が出るんじゃないかと思って、時間を全部生成に全振りしようという話になっている。個人が AI にゴリゴリコードを書かせてしまうからそう見えるんですけど、落ち着いてみると、さっきまで話していたように、ボトルネックはそもそもそこにないんです。はっきり言うと、顧客の獲得やニーズの発見、あるいはそもそもお金を払ってくれるお客さんを探すとか、本当の問題を探すとか、こちらのほうがずっとボトルネックです。誰にもいらないものをものすごく高速に作っても、意味がないですね。つまり、関係のないところを高速に生成する手段を得て、それがすごく派手に見える結果、われわれちょっとおかしくなってしまっている。そこはもう少し落ち着いていったほうがいいし、教育自体は中長期的に効いてくるので、時間をかけてよいと思っています。

僕の別の講演で「質とスピード」という講演があるんですけど、質とスピードはトレードオフじゃないというのが結論です。質を下げればスピードが上がるとか、その効果はないよという話なんですが、その講演の結論は「質およびスピードとトレードオフなのは教育である」という話なんですよね。教育というのは質およびスピードを落として取りに行くものですが、教育した結果何が得られるかというと、将来のスピードと質が得られる。なぜなら質とスピードの原資は能力だからです。だから、教育に投資できるというのは大事なことなんですよ。将来の質とスピードを作っていくために人を育てていくことが大事ですし、その意味だと、教育自体はさきほどのチーム戦のような形で、若いエンジニアを一人にしない、ちゃんと教えていくということです。

ここ 2 、3 年「新人教育が大変だ」という話が続いていたと思うんですけど、今年、回り回ってちょっと落ち着いてきて、もう基礎をちゃんと教えるほうが結果的に割に合うという空気感に各社なってきています。新人研修なのだから、そもそも進捗も物的生産性も求められないし、ここでゆっくりがっつり腹を据えて教えられなくて、どこでやるんだという話なんですよね。難しい難しいとなったのが回り回って、きちんと基礎をやろうというモードになってきている。これは好ましいことなんじゃないかなと思っています。

佐藤氏： 将来の質とスピードを上げるためには、今の質とスピードを教育のために下げるということですね。

和田氏： そうです。いいことです。

佐藤氏： プログラミングもやっぱり書かないと覚えないかなと思うんですけど、読んでいるだけだとなんとなく理解した気になっていて、やっぱり書いたほうがいいですか？

和田氏： 新卒研修や新人研修というスコープでいうと、手で書いてもらうというのが好ましいこととして復活してきていますし、私もそうやっています。なぜ今あえて手で書く必要があるのかをきちんと現在の課題に絡めて説明したうえで、「だから AI をオフにしましょう」と伝える。みんなびっくりするくらい書けないんですけど、それも含めて手で書いていくことによって、学びのスピードではなく学びの強度を取っていくような感じでやっています。

理解容易性と変更容易性のトレードオフをどう言語化し、スキルに落とし込むか

和田氏： 理解容易性と変更容易性のトレードオフについて、まず皆さんにお伝えしたいのは、基本的には常にトレードオフではなく、どちらを取るかではなく、基本的にどちらも良くなっていくということです。わかりやすければ変更しやすいし、変更しやすいなら大体わかりやすい。ただし、高いレベルに行った先にどちらを取るかの世界があったりします。そのときにどちらを取るかというのは簡単な判断ではありません。どのくらい変更されやすいか、どのくらい外部依存があるか——最近いい本を見かけて、『ソフトウェアの結合バランス』だったかな、ちょっと正確な書名が怪しいのですが、去年のベストセラーで、めちゃくちゃいい本です。あの辺にそういった判断基準も書いてあります。

結果として、変更しやすさと読みやすさ——つまりわかりやすさがトレードオフになるとき、これまで人間はやはり労働時間に制約があり、疲れるし、集中力も低下するし、その代わり気づきがあるという、AI とは違う特性を持っていました。AI のほうはひたすら黙々とやるし、物量が出ます。だから、物量を出せばなんとかなるような設計を選択するというのは、近年は選択肢に入ってきています。

あるいは、ディスポーザビリティ（disposability）——つまり「捨てる」という考え方ですね。メンテするのではなく、捨てて作り直すくらいの単位でモジュールを構成するというやり方もあります。AI は作業した履歴から仕様が残っていて、もう一回やり直せと言えば文句を言わずにやるわけですから、これまでの人間の特性とは違うものが行動を変えていく。だからよりドライになるんですね。たとえば、せっかく作ったけどやっぱり気が変わったのでやめますとか、これ全部捨てて作り直してくださいとか、もう一回ゼロからやり直したいですとか——人間相手にはできないような判断を AI 相手にはできてしまう。そこはやはり制約や前提が変わったところです。人間には頼めないものを AI には頼める。AI は体力が無限にある、お金はかかるけれど——そういったことをアーキテクチャや設計判断に組み込んでいくという話です。

具体的な話でいうと、設計判断としてスキルを設計するときに、グッドパターン・バッドパターンのような例示をやったりします。そのときに、このプロジェクトでは理解容易性も変更容易性もレベルは高いのだけど、高いうえでどちらのソリューションを取るか迷うという場面がある。そこで、こちらではなくこちらを取る、という具体例をグッドパターン・バッドパターンの形でスキル化して、プロジェクトに入れていくんです。一般論ではなくて、どちらかというとプロジェクト固有の判断を形にしていくという進め方です。

たとえば、理解容易性と変更容易性でいうと、ベタ書きにするか共通化するか。デザインパターンの中には、理解がちょっと難しくなるけれど変更しやすくなるような構造を持ったパターンがあります。ソフトウェアエンジニアリングの歴史でいえばそのパターンを取るべきなのだけど、このプロジェクトではそれではなくて、割と愚直なほうを選びます。なぜなら——という形で説明していく。テストコードの書き方にしても、理解容易性と変更容易性は基本的に両立させるんだけど、変更容易性を高めるとなると何らかの抽象を入れるとか共通化を進めるとかになる。しかしこのプロジェクトではその必要はない、その代わり文句を言わずに全部書き直せ——そんな感じのことをやっていくという話ですね。

「AI を使えない」と諦める人にどうアプローチすればいいか

和田氏： 社内で AI の活用を進めていくと、利用者のレベル差に戸惑う場面が出てきます。この場に来ているような方々は何かしら関心を持てていると思いますが、ちょっと試してみて「AI 使えないな」で諦めてしまう人は確かに存在します。そういう人たちにどうアプローチするかという話ですね。

これはやはり先ほどのチーム単位の話とつながっていて、個人レベルで試してもらうだけではなく、実際に使っている場面を見てもらう、知見を共有する、隣で一緒にやる、チーム間で共有する、あるいはエージェントスキルという形で共有するといったやり方が有効です。

それからもう一つ、部門や現場レベルでよくやっているのが、損得で訴えるというアプローチです。「これからのエンジニアは AI を使いこなさなきゃダメだ」という言い方ではなくて、「こっちのほうが楽だよ」「こんなに便利だよ」という見せ方をする。だから、やはり実際に使っているところを見てもらうのが大事だなと思っています。

レベル差の問題については、これは各企業でものすごくあるんですよ。AI の利用状況をデータで取ってみると、グラフの形がまるで違う。めちゃくちゃ使っている人もいれば、全体としてはロングテールな分布になります。使いこなしに差が出るのは当然のことですが、ここ 3 年くらいでエージェントスキルが出てきたことによって、うまく使える人のやり方をチームで共有しやすくなってきたなと感じています。こうした仕組みづくりが大事ですね。

もし今の時代にプログラミングと出会っていたら、エンジニアを目指していたか

佐藤氏： ちなみに和田さんが今の時代にプログラミングと出会っていたら、エンジニアを目指していましたか？

和田氏： 難しいですね。たらればの話になってしまうので、正直わかりません。

サードパーティライブラリが提供できる本当の価値とは

サードパーティライブラリの本当の価値はよく設計されたテストなのか。サプライチェーンアタックのリスクが増しているなかで、大規模でないライブラリの内製化が進んでいるのではないか。今、サードパーティライブラリが提供できる価値は何か——という質問ですね。

和田氏： これも最近大きく変わってきているところです。手元で再実装してしまおう——いわゆる車輪の再発明をあえてやろうという時代になってきています。
サードパーティライブラリが提供できる価値は何かといえば、きちんと設計・実装・テストがされていて、ドキュメントが書かれていて、利用者がたくさんいるということに尽きます。みんなが使っているから良いものであろうという期待値を提供できるし、多くの人が使っていることで不具合も早期に見つかるだろうという期待ができる。

ただ、最近の状況でいうと、AI エージェントは増幅器だという話をしましたが、これは攻撃者にとっても増幅器なんですね。サプライチェーンアタックの激しさが一層増しているので、防御の意味も含めて社内で再実装するという流れは確かにあるし、ある種やむを得ないところかなと思っています。

さらに最近では、オープンソースソフトウェアの slop fork という問題が起きています。OSS には普通テストコードがあるわけですが、テストコードさえあれば AI にゴリッと再実装させられると分かってしまった。その結果、モラルが崩壊してしまったんですね。個人的には大変悲しい出来事です。

一方で、サードパーティライブラリの全機能を自分たちが使っているかというと、そうでもないんですよね。だいたいその中の一部が欲しいだけで、「みんなが使っているからきっと動く」という信頼のもとに導入している。であれば、その一部を再実装して使うところだけ作り、その代わりにちゃんとメンテナンスをしてアップストリームの変更を追いかけていく。短期的にはそういう状況になっていると思います。中長期的にどうなるかは正直まだ分からないですが、そういう流れは確実にあります。

佐藤氏： 結構いろんな価値観が変わってきていますよね。心がザラザラしますね。

和田氏： 本当にそうですよね。少し前にも話題になっていました。

アンラーニングの時代に、コードを書く技術としてどれくらいのベースラインを押さえておけばいいのか

コードを書く技術の重要性が下がるという話があったが、コードの書き方を知っていないと AI とのペアプログラミングがうまくいかないのではないか。コードを書く技術としてどれくらいのベースを押さえておけばいいのか——という質問ですね。研修で書いても実践で書かなければすぐ忘れてしまうかもしれない、というのも含めて。

和田氏： これはまだ明確な答えが出ていないところなんですが、個人の考えとしては、コードの書き方はもっとたくさん知っていてほしいし、コーディングのスキルは AI がコードを書く時代にもどんどん伸ばしていてほしい。なぜなら、それがそのままコーディングエージェントを使いこなすスキルにつながっているからです。

ただ、事実として自分でコードを書く機会が減っていくなかで、スキルが上がっていきますかという問題はあります。だからこそ、自分にストレッチをかけるというか、自分の手を動かしてコードを書く機会を作る。あるいは AI エージェントが書くコードに対して主体的に関与する、その割合を意識的に保つことが大事だと思っています。ここは引き続き大切にしていきたいところです。

一つ補足すると、自分でコードを書かないバイブコーディングというレベルにおいてさえ、コンピュータサイエンスの知識と言語化のスキルが結果の差として有意に出てくるという研究があります。コードをまったく見なくても、プログラミング能力と言語化能力は統計的に有意な差として現れるんですね。ここでいうプログラミングのスキルとは、対象を分解して構造化し、経験を言葉にして伝えるスキルのことです。問題を分解するスキル、順序付けるスキル——そういったところはこの先も変わらず大事だと思っています。