「動かないエンジニア」が一番危ない。AI時代は、先に慣れた者勝ち？【null先生・中島 聡・t-wada】
AIの進化に、あなたはどんな感情を抱いているだろうか。
「確かにすごいけど、まだ実戦では使えない」
「試してみたいけど、もう少し進化してからでいいかも」
未曾有の変革期の今、そう逡巡してしまうのも無理はない。
ただ、様子見をしているうちに、気づけば“使う人”と“使えない人”の差はとてつもなく広がっているかもしれない。そして数ヶ月後には、無視できない経験値の差となって現れるだろう。
本記事では、AIを積極的に活用しているテック界の著名人3名の言葉から、エンジニアが「この過渡期にどう在るべきか」を考えていく。
目次
null先生｜プライドもサンクコストも捨てる。毎日「AIの健康診断」を欠かさない中島聡｜AIはまだ「ジュニアエンジニア」。的確な指示とレビューで協業するt-wada｜忖度なく、客観的な意見をくれる。AIは理想の「壁打ち相手」
null先生｜プライドもサンクコストも捨てる。毎日「AIの健康診断」を欠かさない
Oculus Japanの立ち上げに尽力するなど、日本のVR黎明期を牽引したGOROmanこと近藤義仁さん。現在は、「LLM無職」の「ナル先生（null-sensei）」を名乗り、生成AIについての情報収集・発信に専念している。
そんなナル先生は、AI時代に重宝されるのは「性格が良くて、人当たりが良くて、そこまでコーディング能力は高くないけど、AIが使える人」だと語る。
ナル先生：職人気質の人はプライドがあるから、AIをバカにしがちなんですよ。さらに、サンクコストもあるから、それを途中で止められない。ずっとバカにし続けるしかない。「すごいすごい言ってるけど、こんなこともできないのかよ」って。
ただ「こんなこともできねえのかよ」が1週間でできるようになるのが、今のAI界隈なんですよね。プライドが高いと、そこに追いつこうとしない。これはかなりまずいです。
3年前のChatGPT GPT-3.5のイメージで「ハルシネーションが〜」とか言い続けていると、完全に取り残される。だから俺は毎日AI、しかも出たばっかりのツールや機能を触ってAIとの距離感を測る“技術的な健康診断”をしてる。
「今、どのツールが伸びているのか」「何が使い物になるのか」を、毎日チェックする。何もそれは特別なことではなく、これまでエンジニアなら誰しもが行ってきた行為だ。
ナル先生：「かつてのあなたはそうでしたよね？」って話です。それこそ俺は、中学時代からプログラミングをやっていて、アセンブラからやっていました。その頃、C言語が出たときに、ものすごくC言語をバカにする人が出てきたんですよ。
「中身を見ないと信用できない」「コンパイラが出すコードなんて信用できない」みたいに、Cの悪いところばっかり指摘する人が。もちろん最初のCってあまりよくなかったんだけど、結局、蓋を開けると誰もアセンブラなんて書かなくなっちゃって。だって楽だから。
その後も、ウェブでCを書く人なんていないし、PerlやPHPが出てきて、今はNode.jsとか、JavaScriptとかTypeScriptに進化していったじゃないですか。
ナル先生：だから同じなんですよ。皆さん、ここまで追っかけてきましたよねって。新しいものに触れて、バカにしなければ生き残れる。
逆に「AIの出すコードは使えねえ」みたいに言ってると、あっという間に捲られます。
まずは触ってみる。そして、その進化のスピードを肌で感じること。それが、AI時代をサバイブするための第一歩だ。
プライドも、サンクコストも捨てろ「健康診断」しないエンジニアは死滅するhttps://type.jp/et/feature/28625/
中島聡｜AIはまだ「ジュニアエンジニア」。的確な指示とレビューで協業する
では日々の業務において、エンジニアはAIとどう付き合えばいいのだろうか。
MicrosoftでWindows 95の開発に携わった伝説のプログラマー・中島 聡さんは、AIを「特定のライブラリに詳しいジュニアエンジニア」と捉えるのが、現時点での最適解だと語る。
中島さん：ソフトウエア開発でAIを使う際には、ゼロからコードを書かせる場合と、既存のコードに機能追加させる場合がありますが、私はどちらのケースでも「可能な限りスコープを絞って一つの仕事に集中させる」ようにしています。
いずれは、より大きなスコープの仕事を任せられるようになるかもしれませんが、現時点では、スコープを絞った方が質の高い仕事をしてくれる印象です。
中島さん：ちなみに、私はAIが書いたコードを全て自分でレビューし、完全に納得した上で取り込んでいます。そういった意味では、昨今話題の「バイブ・コーディング（Vibe Coding）」とは一線を画しており、「特定のライブラリに詳しいジュニアエンジニアを雇い入れて、コードを書いてもらっている」イメージに近いです。
この「シニア（人間）とジュニア（AI）の協業」という考え方が、現在の私の開発スタイルの基本です。
AIに丸投げするのではなく、あくまで人間が主導権を握る。タスクの範囲を明確にし、アウトプットをしっかりレビューする。少なくとも現段階では、そのスタイルこそが、AIの能力を最大限に引き出し開発効率を高める鍵だ。
ただ遅かれ早かれ、人間はAIに自然言語で指示するだけで、コードは全てAIが書く時代が来る。そのとき、エンジニアとしての喜びや達成感は失われてしまうのだろうか。
中島さん：AIがもたらす変革は、今の私たちがコンパイラに頼って自らマシン語を書かなくなったのと同じ、ごく自然な進化の姿に他なりません。
機械語でコードを書く楽しみがC言語に変わり、そしてPythonやTypeScriptで書く楽しみに変わってきたように、今後は「自然言語を使った指示でAIに仕事をさせる楽しみ」に変わるだけです。
結局のところ、エンジニアにとっての根源的な喜びは「自分の仕事によって、どんな価値を世の中に提供できるか」という一点に尽きるのであり、AIの助けを借りたところで、その本質は変わりません。
AIは、エンジニアから仕事を奪う存在ではなく、より本質的な価値創造に集中させてくれるパートナーなのだ。
「AIが書く時代」に中島 聡が実践する開発スタイルとは？https://type.jp/et/feature/28667/
t-wada｜忖度なく、客観的な意見をくれる。AIは理想の「壁打ち相手」
さらに進んで、AIを思考のパートナーとして活用する道を提示するのは『テスト駆動開発』（オーム社）の訳者として知られる、t-wadaこと和田卓人さんだ。
数々の企業で技術顧問を手がける和田さんは、AIを設計議論の「壁打ち相手」として活用している。
和田さん：「この機能を追加したい。自分にはこのような案があるけど、こういう懸念もある」と伝えて、「一緒に設計を考えてくれないか？」と持ちかける。そうすると、AIが時に否定もしながら、意見を返してくれますよね。それが、ものすごく面白くて。
技術顧問という立場で仕事をしていると、自分の設計に対して『和田さんが言うなら』と受け入れていただく場面がどうしても増えていきます。それ自体はありがたいことですが、もしその設計が間違っていたらどうなるか。より良い選択肢があるのに、それに気付けなかったとしたら？
自分の設計が誰にも疑われないというのは、技術者としての成長を考えると非常に危うい状況です。その点、AIは私のことなんて知らないし、正しく突っ込んでくれますからね。
自らAIに積極的に触れ、その可能性を実践を通して探る。そんな日々の中で和田さんは、「ソフトウェアエンジニアリングの本質」と向き合うことになったという。
和田さん：チームで開発し、数年以上にわたって保守するといった本格的なソフトウェア開発では、質の担保や、時間に耐えうるアーキテクチャーが欠かせません。ただ、AIで一気に生成されたコードは、確率的な出力なので再現性に乏しいことも多いです。
そう考えると、設計段階での深い議論や意図を伝えるドキュメント、運用まで見据えた長期的な視点にこそ、「ソフトウェアエンジニアリングの本質」があるのではないでしょうか。
変化の波は止まらない。だが、AIがコーディング作業を代替していくからこそ、エンジニアリングの価値はより高まっていく。
和田さん：AIで全部終わる、という話ではないんです。むしろ、これまで曖昧だった「ここからがソフトウェアエンジニアリング」という境界線が、今後より明確になっていくのだと思っています。
ソフトウェア開発に人が介在する余地は、まだある。いや、AIの進化によってやるべきことが増えている感覚すらありますね。
AIに仕事を代替されるどころか、人がボトルネックになるので、もっと忙しくなるかもしれませんよ（笑）t-wadaの焦燥と挑戦。AIとの協業で見えた、ソフトウェアエンジニアが「もっと忙しくなる」未来https://type.jp/et/feature/28309/