はじめに
AIにリサーチをさせていた。結果が返ってくるまで数分かかる。待っている間、Xを開いた。
流れてきたタイトルに、手が止まった。「プログラミングが好きな人は、もうIT業界に来るな。」
リサーチは終わっていた。結果を確認しないまま、記事を読んでいた。小学生の頃から黒い画面に向かい続けてきたエンジニアが、生成AIの登場によって「自分の手で作る喜び」を奪われつつあると語っていた。「心の中で何かが音を立てて崩れる」という表現があった。
共感したのか、と聞かれると困る。共感しなかったのか、と聞かれても困る。たぶん、どちらでもある。読み終えて、エディタに戻った。さっきまで何をしていたか、思い出せなかった。
反論したいわけではなかった。ただ、何かが引っかかっていた。「プログラミングが好き」という言葉だ。この人の「好き」と、私の「好き」は、同じものを指しているのだろうか。
コーヒーを淹れた。飲みながら、書くことにした。
「好き」の中身を分解する
元記事の筆者と私の違いは、能力でも経験でもない。「プログラミングが好き」という言葉が指す範囲が違うのだ。
言葉は同じでも、中身が違う。「好き」と言ったとき、何を思い浮かべているか。キーボードを叩く指先か、頭の中で組み上がる構造か、動いた瞬間の達成感か。同じ「好き」でも、その中身は人によって違う。中身が違えば、奪われるものも違う。
プログラミングという行為には、少なくとも3つのレイヤーがある。——もちろん、これは私の視点からの便宜的な分類だ。元記事の筆者にとっては、まったく別の分け方があるかもしれない。「書くこと」と「考えること」は分離できない、という人もいるだろう。書きながら考える。考えながら書く。その不可分さこそがプログラミングだ、と。それでも、ここでは一旦この枠組みで話を進める。
- 身体感覚：キーボードを叩く感触、コードを書く行為そのもの、画面に流れる快感
- 知的作業：問題を分解し、設計し、実装する思考プロセス
- 創造行為：何かを作り、動かし、世に出す達成感
元記事の筆者が愛していたのは、単なる身体感覚ではないように思う。「自分の指先から生まれるロジックが、動かなかったものを動かす」——その創造の主体性だ。自分の手で書いたコードが動く。その実感が奪われたから「楽園が消えた」と感じている。AIが書いたコードをチェックする「検品係」では、創造の主体は自分ではない。
これは「間違った好き」ではない。彼の文脈では、それが正解だった。小学生の頃から黒い画面に向かい続け、自分の手でコードを書くことで世界を動かしてきた。その積み重ねの上に立っている。私が「設計が好き」と言えるのも、私の文脈があるからだ。どちらが正しいという話ではない。
私が好きだったのは、2だった。課題があったら適切なサイズに分割して、「この問題はこう実装すれば解決するな」と構造が頭の中で閃く。そこからコードを書き続けていく。その一連のプロセスが好きだった。
AIがコードを出力するようになって初めて、自分の「好き」が何だったのか見えた。コードを書けなくなったとき、喪失感を感じたか？ 感じなかった。むしろ「これで設計に集中できる」と思った。そのとき気づいた。自分が好きだったのは、タイピングではなく、考えて、作って、また考える、その繰り返しだった。
では、何が奪われ、何が残ったのか整理しよう。
奪われたもの：タイピングの時間、実装の試行錯誤、ググって解決策を探す時間。 残ったもの：設計を考える時間、AIの出力を評価する時間、「もっと良い方法はないか」と考える時間。
私にとって、後者こそがプログラミングの核心だった。もっと言えば、コードを書く時間に追われて後回しにしていた「設計」や「トレードオフの検討」——いわゆるソフトウェアエンジニアリングの領域に、ようやく時間を使える。だから、「奪われていない」と言い切れる。
正直に言う、めちゃくちゃ楽しい
今、めちゃくちゃ楽しい。作りたいものがある。指示を出す。コードが出てくる。レビューする。直す。動く。
——以前なら「面倒だな」と後回しにしていたアイデアや知識が、数分で形になる。
さっき書いた「ソフトウェアエンジニアリングの領域」——設計、トレードオフ、アーキテクチャ。そこにやっと向き合えている感覚がある。
楽しい。素直に、楽しい。これを「検品係」と呼ぶなら、私は世界一楽しい検品係だ。
コードレビューが好きで良かった
思えば、私はコードレビューが比較的好きだった。他人のコードを読んで、「この人はこう考えてるんだろうな」というのが見えると嬉しい。なぜこの設計にしたのか、どこで迷ったのか。コードの向こうに思考が透けて見える瞬間が好きだった。知らない言語機能や、思いつきもしなかった構造で課題を解決しているのを見ると、良し悪しにかかわらず楽しい。正解かどうかより、発見の方が全然面白い。正解とは常に文脈の中にしかない。
チームの習熟度、プロダクトのフェーズ、パフォーマンス要件、保守する人間の数。同じ課題でも、文脈が変われば最適解は変わる。だから「このコードは正しいか」という問いより、「この文脈でなぜこう書いたのか」という問いの方が面白い。そして、その問いに答えようとする過程で、自分の中の「正解」も揺らぐ。揺らぐことが学びだ。
AIが出力したコードをレビューしていると、これが想像以上に勉強になる。
先日、AIに「CSVパーサーを書いて」と頼んだ。返ってきたコードを見て驚いた。私なら正規表現でゴリ押しするところを、状態機械で書いている。エスケープ処理も完璧だ。「なるほど、このアプローチがあったか」と笑った。
逆に、「いや、これは現場では使えない」と思う瞬間もある。過剰に抽象化されていたり、エラーハンドリングが甘かったり。その判断力こそ、レビューを通じて研ぎ澄まされる。——もっとも、私の判断が正しいとは限らない。AIの提案を「使えない」と却下した翌週、まったく同じアプローチを別の記事で「ベストプラクティス」として紹介されているのを見たこともある。
ただ、これは15年やってきた人間だから言えることだ。状態機械の良さが分かるのは、正規表現ゴリ押しで痛い目を見たことがあるからだ。「なるほど、このアプローチがあったか」と唸れるのは、比較対象を持っているからだ。経験ゼロの人がAIの出力から体系的に学べるかは、正直分からない。むしろ、学べない可能性の方が高い気がする。
コードレビューが苦手な人には、AIとの協働は苦行かもしれない。でも、レビューが好きな人間にとっては、無限に相手がいるジムのようなものだ。疲れない、休まない、いつでも付き合ってくれる相手。しかも、毎回違うアプローチを見せてくれる。
「検品」と「協働」の違い
元記事は「検品係になった」と嘆いている。創造の主体でありたかった人にとって、この表現は正確だと思う。自分が書きたかったコードを他者（AI）が書き、自分はそれをチェックするだけ。主体と客体が入れ替わっている。
ただ、私の場合は少し違った。
携帯電話は私のことをめちゃくちゃ記憶している。連絡先、スケジュール、位置情報、検索履歴。私より私のことを知っているかもしれない。でも、携帯電話を使っているとき、「主体を奪われた」とは感じない。道具として使っている感覚がある。生成AIは違う。コードを書く、文章を書く、設計を考える——これまで「私がやること」だった領域に、AIが入り込んでくる。携帯電話が記憶を代替しても主体性は揺らがなかったが、生成AIは創造を代替しようとする。だから主体性が脅かされる感覚が生まれる。
それでも、私は自分が主体だと思っている。なぜか。
答えは、関わり方にある。
「検品」と「協働」の違いは何か。検品は受動的だ。ラインを流れてくる製品をチェックし、不良品を弾く。渡されたものをチェックするだけ。協働は能動的だ。方向性を示し、フィードバックを与え、成果物を一緒に作り上げる。
私がAIとやっているのは後者だ。具体的に言うと——
- 「こういう設計で書いて」と指示を出す（方向性）
- 出てきたコードを見て「ここはこう直して」とフィードバックする
- 「いや、アプローチ自体を変えよう」と軌道修正する
- 最終的な成果物が完成する
このやりとりは、人間同士のペアプログラミングと構造的に同じだ。相手が人間かAIかの違いしかない。検品係は受け身だが、私は能動的にAIを導いている。方向を決め、判断を下し、軌道修正をかける。この能動性が、主体性を保つ鍵だ。
AIとの関係を一言で表すなら、「相棒」ではなく「優秀だが判断できない後輩」が近い。指示を明確にすれば良い仕事をする。曖昧にすると、意図しないものが返ってくる。
筆者が言うように、書く時間は減った。でも、考える時間は増えた。どう分割するか。どう設計するか。AIが出してきたコードのどこを採用し、どこを直すか。
そして、仮にこれが「検品」だったとしても、私はその過程でかなり学んでいる。「こんな書き方があるのか」と何度も唸った。特に経験の浅い言語では顕著だ。自分で書いていたら絶対に思いつかないイディオムを、AIは平気で出してくる。検品のつもりが、いつの間にか授業を受けている。
ただし、ここには落とし穴がある。
AIが出したコードをそのまま使って「動いた、終わり」で済ませると、何も残らない。効率は上がる。成果も出る。でも、1週間後に「なぜこう書いたの？」と聞かれても、答えられない。因果を辿れない。自分が責任を持って出力したコードのはずなのに、説明しようとすると言葉が出てこない。
以前、「AIエージェントと協働しながら学習する方法」という記事で詳しく書いたが、学びには「摩擦」が必要だ。エラーが出る。原因がわからない。仮説を立てる。試す。失敗する。また試す。この摩擦の中で、経験が意味に変わる。学習とは、経験を意味に変換する行為だ。AIが摩擦を消してくれると、経験が意味に変わる機会も消える。
だから私は、AIが出したコードを「なぜこう書いたのか」と考える時間を意図的に作っている。効率だけを求めるなら不要な時間だ。でも、この「不効率な時間」が学びを生む。摩擦は削減対象ではない。設計対象だ。何を学び、何を省略するか。その選択を自分でしている限り、主体は私だ。
これを「検品」と呼ぶか「協働」と呼ぶかは、本人の姿勢次第なのかもしれない。
——と書いて、自分で読み返して思った。「姿勢次第」では何も言っていないのと同じだ。
具体的に、検品を協働に変えるための3つのポイントを挙げてみる。
- 意図を言語化する: 「こう書いて」ではなく「この問題を解決したい。制約はこれ」と伝える。AIに考えさせる余地を残す。
- 出力から学ぶ: AIが出したコードを「動くかどうか」だけでなく、「なぜこう書いたか」を考える。知らないパターンがあれば調べる。
- フィードバックを重ねる: 一発で完璧を求めない。「ここを直して」「いや、やっぱりこっち」のやりとりを楽しむ。
この3つができれば、検品は協働になる。逆に言えば、「動くか確認するだけ」なら、それは検品だ。この3つを実践するかどうか。それが検品と協働を分け、主体性を保てるかどうかを分ける。
——と偉そうに書いたが、これが「正解」かどうかは分からない。私の文脈ではうまくいっている。でも、別の文脈では別の答えがあるはずだ。締め切りに追われているときは「動けばいい」になるし、疲れているときは「なぜこう書いたか」なんて考えない。理想と現実は違う。ただ、「こうありたい」という指針があるのとないのとでは、違うと思っている。それすらも、私の文脈での話だ。
ただし、これは私のケースだ
ここまで書いてきて、一つ断っておきたいことがある。
これは私の話だ。コードレビューが好きで、設計を考えるのが好きで、タイピング速度に自信がなかった人間の話だ。
もし元記事の筆者のように、「自分の手で書いたコードが動く」その実感こそが喜びだったなら——この記事は何の慰めにもならないだろう。創造の主体でありたかった人に、「検品も楽しいよ」とは言えない。
その人たちに「考え方を変えろ」と言うつもりはない。「自分が書きたかった小説をAIに書かせ、誤字脱字を直す校正者のような気分」——元記事のこの表現は、痛いほど分かる。創造の主体性を奪われた感覚は、姿勢や考え方でどうにかなるものではない。彼の文脈では、それが真実だ。私が「楽しい」と言えるのは、私の文脈がたまたまそうだったからに過ぎない。
「でも、結局プログラマーの仕事は減るのでは？」という反論もあるだろう。
正直、分からない。AIの進化は私の想像を超えている。5年後にどうなっているか、予測する自信がない。
そして、ここは誤魔化さずに言っておくべきだと思う。「楽しい人がいること」と「職業として持続可能かどうか」は、まったく別の話だ。ドライバーが100人必要だった時代から、10人で済む時代へ。私が楽しくても、市場が縮小すれば、その楽しさを職業にできる人は減る。元記事の筆者が問うているのは、たぶんそっちの話でもある。
この問いについて、エンジニアに許された特別な時間の終わりというスライドがある。エンジニアがドライバー席から助手席へ移る時代が来ている、という話だ。AIが「副操縦士（Copilot）」から「操縦士（Pilot）」へ進化しつつある。続編のたかが特別な時間の終わりでは、9ヶ月後にその予測が現実化しつつあると報告されている。
私がこの記事で書いてきた「協働」も、結局は助手席からの関わり方なのかもしれない。ドライバー席に座っていた時代は終わりつつある。それでも、助手席には助手席の仕事がある。呑気なドライブデートを思い浮かべたかもしれないが、全然様相は違う。
ラリーのコ・ドライバーは、ただ座っているだけではない。本番前にコースを試走し、コーナーの角度、直線の距離、路面の状態、危険なポイントをすべてペースノートに書き込む。本番では猛スピードで揺さぶられる車内で、そのノートを絶妙なタイミングで読み上げる。「左3、50m、右2、クレスト注意」。ドライバーは全コースを暗記できない。コ・ドライバーなしでは走れない。
AIとの協働も似ている。事前にコードベースを把握し、設計を考え、制約を整理する——これがペースノートの作成だ。本番では、AIが猛スピードでコードを生成する中、「次は右だ」「ここは危険だ」と指示を出し続ける。曖昧な指示を出せば、車は崖から落ちる。
ただし、その車は時速200kmで走っている。のんびり景色を眺める余裕はない。コ・ドライバーとして生きる。それがこの時代の選択だ。
——と書いたが、この比喩にも限界がある。ラリーではコ・ドライバーの仕事がなくなることはない。しかし、AIとの協働では、その保証がない。今は「設計」「評価」「判断」が人間の仕事として残っている。だが、AIが設計し、AIが実装し、AIがレビューする世界が来たら？ コ・ドライバーの席さえ、自動運転に置き換わるかもしれない。この記事は「設計や評価は人間に残る」という前提で書いている。その前提が崩れたら、私の話は無効になる。
ただ、「だから今やっても意味がない」とは思わない。今この瞬間、プログラミングが楽しいなら、それでいい。未来のことは、未来の自分が考える。
——もっとも、この「楽しい」を大声で言うのは少し気が引ける。誰かが失った「楽しさ」の上に、私の「楽しさ」が成り立っているかもしれないからだ。元記事の筆者が読んだら、どう思うだろう。「お前はたまたま運が良かっただけだ」と言われたら、反論できない。
おわりに
書き終えて、コーヒーを淹れ直した。冷めていた。
あの日から何日か経った。書いている間、ずっと考えていた。私は本当に「楽しい」のか。それとも、楽しいと思いたいだけなのか。正直、分からない。分からないまま書いた。
元記事の筆者が読んだら、どう思うだろう。「お前はたまたま運が良かっただけだ」と言われるかもしれない。反論できる気がしない。私の「好き」と、あの人の「好き」は、たまたま違った。彼の文脈では彼が正しく、私の文脈では私が正しい。それだけのことだ。どちらかが間違っているわけではない。
明日もたぶん、AIにコードを書かせる。レビューする。直す。動かす。それを「楽しい」と感じるかどうかは、そのときになってみないと分からない。
ただ、少しだけ違うことがある。
「プログラミングが好き」という言葉を使うとき、自分が何を指しているのか、前より意識するようになった。摩擦は削減対象ではない。設計対象だ。——この言葉を、自分に言い聞かせるようになった。
そして、自分の「正解」も揺らぐことを知った。書く前と書いた後で、考えが変わっている。元記事の筆者の気持ちが、前より分かる気がする。揺らぐことが学びだと書いた。この記事を書くこと自体が、そうだった。
「IT業界に来るな」と言われた君へ。
私は「来い」とは言わない。言えない。生成AIがいつか道具になる日までは。ただ、私は来てよかった。少なくとも、今日は。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
技術が人類を幸せにするかみたいな問いは常に面白いです。
