AIに奪われない「技術力」はどう磨く？ AIエージェント元年、トップエンジニアが変化のど真ん中で語った成長のヒント4選

NEW! 2025.12.27 スキル

「今年一番ハマったもの」を問われたら、あなたは何と答えるだろうか？将棋棋士の藤井聡太竜王・名人は、とある番組でその問いに「バイブコーディング」と答えたそうだ。同意するエンジニアは、きっと少なくないはずだ。

振り返ると2025年は、DeepSeek-R1、Claude 3.7、OpenAI o1シリーズの台頭が象徴するように、まさに「AIエージェント元年」だった。ソフトウエア開発の進め方そのものが、劇的に変わり始めている。

この変化のど真ん中で、エンジニアはどう成長すればいいのか。何を学び、どのようなスキルを積み上げれば、AI時代を生き抜く「強いエンジニア」になれるのか。

今年一年、エンジニアtypeではその答えを探るべく、様々な著名エンジニアにインタビューを行ってきた。今回はそれらの記事の中から「もう一度読みたい4本」を、エンジニアtype編集部の今中ヤスタツが厳選して紹介する。

第一線のエンジニアたちの言葉を通して、「これからの成長戦略」を読者に贈りたい。

t-wadaが説く、今あえて「自分の手」でコードを書く理由
「技術力」とは何か？まつもとゆきひろが明かす不変の三要素
『プロになるJava』著者・きしだなおきが語る「実装」の価値
牛尾剛が考える、バイブコーディング時代の必須スキルとは

t-wadaが説く、今あえて「自分の手」でコードを書く理由

「バイブコーディング」に代表されるAI活用が広がるほど、私たちは「書く」ことから解放されていく……ように見える。だが、t-wadaこと和田卓人さんは、その熱狂に水を差すようにこう言い切った。

バイブコーディングは、あくまでも「ソフトウエアエンジニア以外の人々」に対する革命です。これまで障壁となっていたコーディングという作業が、AIを用いることで簡単に突破できるようになり、ソフトウエア開発の裾野がどんどん世界中に広がっていきました。

当然、裾野が広がれば広がるほど、その頂上は高くなります。プロフェッショナルなソフトウエアに求められる品質やインパクトは、これまで以上に高くなっていくのです。私たちは、その頂上が高くなった世界でどう戦っていくのかを考えなければなりません。

バイブコーディングは、われわれソフトウエアエンジニアのためのものではなかったのです。

AIに任せる部分が増えるほど、人間側の理解と判断が重要になる。そこで和田さんが提示するのが、あえて自分の手で書く「オーガニック・コーディング」だ。

皆さんは、最初から正しい設計ができたことが、これまでの開発経験の中でどれだけありましたか？

正直なところ、私は一度もありません。

「よし、完璧だ」と思ってコードを書き始めたその3秒後に「理解が浅かった」と気付くことは、いくらでもあります。コードを書き進めることで対象領域への理解が深まり、設計への良いフィードバックが返ってくる瞬間というのを、私たちは何度も経験しているはずです。

人間の設計判断能力を上げていくために必要なフィードバックは、自らの手でコードを書くことによって一番多く得られます。AI時代であっても、あえて「オーガニック・コーディング」（人間が自分の手でコーディングする）を行うことは効果的な選択です。

Google Cloudの調査チーム・DORAが25年9月に公開した「DORA Research:2025」によれば、AIは増幅器であり、人や組織の能力を映す鏡だ。いくらAIが進化しようとも、鏡に映る自分を鍛えなければ、開発スピードや組織の能力は上がらない。

AIの登場によって、プログラミングスキルはいらなくなるどころか、むしろもっと必要になります。自分に分からないものを、レビューすることはできません。労力は外注できますが、能力は外注できないのです。

AIを使って開発の進捗を高めるだけではなく、AIを駆使して自分の能力を上げていくことも忘れずにやっていくべきでしょう。

AIが書いたものを理解し、判断し、品質を担保できる力は、AIの出力を眺めているだけでは身に付かない。AI時代に「あえて自分の手でコードを書く」ことの重要性を、和田さんは教えてくれた。

「技術力」とは何か？まつもとゆきひろが明かす不変の三要素

もはやAIがコードを書く時代に、エンジニアの「技術力」とは何を示す言葉になるのだろうか。Rubyの生みの親・まつもとゆきひろさんは、むしろ「変わらない」と言う。

「技術力」の本質は、AIの登場以前から何も変わっていないと考えています。

例えば、コンピューターが誕生した当時のプログラマーたちは、プログラムを紙に書き、それを数字に変換して、物理的なスイッチでコンピューターに入力していました。彼らにとっての「技術力」には、機械語やアセンブリ命令を正確に扱う記憶力や、複雑な操作手順を的確に実行する力も含まれていたはずです。

やがて、FORTRANのような高級言語と、それを機械語に変換するコンパイラが登場しました。1950年代、その仕組みを「人工知能だ」と評する声もあったほど、当時のプログラミング体験を一変させる革新でした。結果、私たちプログラマーはアセンブラを一行一行書かなくても、より複雑で、より本質的な問題解決に集中できるようになったのです。

特定のスキルは、ツールの進化と共に淘汰される宿命にあります。しかし、「何を解決すべきかを考え抜き、その解決に向けて技術を使いこなす力」は、どれだけ技術が進化しても求められ続けるものだと思います。

では「技術を用いて問題を解決する能力」は、具体的にどのようなアクションを取れば養われるのだろうか。まつもとさんの答えは、至ってシンプルだった。

「とにかく、ソフトウエアをたくさん作ってみる」ことに勝るものはありません。私自身もそうやって技術力を身に付けてきました。

30数年前の私は、「まあまあ書けるよね」という程度のプログラマーでした。今、こうして偉そうなことを言えるのは、そこから30年以上の間、ずっと現場でプログラムを書き続けてきたからです。

たくさん失敗し、さまざまなツールを使い、数え切れないほどの問題を解決してきました。その繰り返しの結果が、今の私を形作っています。

経験から得た知識こそが、技術力の土台になる。まつもとさんのインタビューを読めば、途中で投げ出さず、最後までやり切る実行力の大切さを再認識できるはずだ。

『プロになるJava』著者・きしだなおきが語る「実装」の価値

コーディング作業をAIが代替しつつある中で、これからエンジニアは「実装」よりも「設計や要件定義」に力を入れるべきだ、という意見を耳にする機会が増えてきた。だがその意見に関して、「実装はAIに任せて、人間は設計だけという単純な分業にはならない」と待ったをかける人物がいる。

LINEヤフーのJavaスペシャリスト・きしだなおきさんだ。

AIが得意なのは「正解・不正解を機械的に判定できる領域」です。小さな正解を積み重ねれば大きな正解になるような問題、例えばアルゴリズムの最適化や処理の高速化などは、今後ますますAIが得意になるでしょう。

一方で、ユーザビリティーやセキュリティー、メンテナンス性、並列性といった領域は違います。部分的に正しいものを積み上げても、全体が正しいとは限らないからです。ユーザーインターフェースもそうですよね。個々のコンポーネントが使いやすくても、組み合わせたフォーム全体が必ずしも快適とは限らない。こういう領域では、論理的な思考で全体像を見渡す人間の役割が不可欠なんです。

単なる基本機能だけなら、AIを使えばすぐに作れるが、ユーザーが「心地よい」と感じる細部の作り込みは、まだ人間が実装する必要がある。「サービスの価値は、まさにその手触りに宿る」と、きしださんは語る。

実装することは、設計力を鍛えるトレーニングにもなります。手を動かしながら「二手三手先を考える」ことで、設計の不備に気づいたり新しいアイデアが生まれたりする。AIにコードを書かせて、人間は判断だけをする役割に押し込められてしまうと、このリズムが失われてしまうんです。

なので僕は「実装は絶対に不可欠だ」と強く言い切るよりは、「実装してみることで自然に興味や知識が広がっていく」と伝えたいです。

実際にコードを書いていると、最初の目的から少し外れた疑問や新しい課題に出会うことがありますよね。その寄り道が、新しい知識を得たり視野を広げたりするきっかけになる。そうした偶然の発見こそが、エンジニアの成長を後押ししていくと思います。

自らの手でコーディングすることの中にある「偶然」にこそ、AIには決して代替されない価値が宿る。きしださんの言葉は、誰もが一度は体感した「コーディングの楽しさ」を今一度思い起こさせてくれた。

牛尾剛が考える、バイブコーディング時代の必須スキルとは

「なぜ自分は、周りの優秀な同僚たちと比べて開発スピードが遅いのか」

米マイクロソフトで活躍するエンジニア・牛尾剛さんは、自身のエンジニア人生の大半でその悩みと向き合い続けてきた。導き出した解決策は「とにかく手を動かし、量をこなす」というもの。それが、成長への唯一の道だと信じて努力を重ねてきたという。

だが、25年の春先、その考えが覆される決定的な事件が起きる。牛尾さんは、数週間かけて実装した新機能を、もう使われていない古いアーキテクチャ（デッドコード）の上に書いてしまったのだ。

自分がかけた時間も労力も、全部ムダだった……。目の前が真っ暗になるとは、まさにこのこと。

結局のところ、自分に足りなかったのは、「速さ」でも「努力」でもなかった。決定的に欠けていたのは、「システム全体の理解」。どんなに素晴らしいコードを、どんなに時間をかけて書いたとしても、その土台となる文脈の理解がなければ、その努力は一瞬で無に帰してしまう。

「ただがむしゃらに書く」ことの危うさと、その前に何か重要なステップが抜け落ちていることを痛感した出来事でした。

この体験以降、牛尾さんは成長のアプローチを180度変えた。「いかに速く書くか」から「いかに深く、正確に読むか」に焦点を移したのだ。

まず取り組んだのは、問題となっていたリポジトリの主要開発者2名に絞り、彼らのPRを最初の一つ目から順番に、全て読んでいくこと。これが、「ディープコードリーディング」です。

これはその名の通り、ただ流し読みするのではありません。一つのPRに対し、「100%完全に理解する」ことだけを目標に定めます。例えば、最初のPRを読むのに、自分は丸2日間を費やしました。

具体的には、GitHub Copilot AgentのようなAIツールを、専属の家庭教師のように活用します。コードを一行ずつ追いながら、少しでも疑問に思ったことは、全てAIにぶつけていきました。

ひたすらに手を動かすのではなく、徹底的に読むことに集中したことで「学習効率が格段に上がった」と牛尾さんは語る。

コードを書く力と同じく、あるいはそれ以上に、コードを読む力が重要になる。バイブコーディング時代、エンジニアが大切にしたい価値観の一つだ。

編集／今中康達（編集部）