若手プログラマーが陥る「AIがあれば十分」という誤解
最近、若手プログラマーの育成を任されている技術リーダーから、こんな相談をよく受けます。「GitHub Copilotを使えばコードは書けるんですが、なぜそのコードなのか説明できない」「エラーが出たときに、AIに聞く以外の対処法を知らない」という状況です。
私自身、30年前にプログラマーとしてキャリアをスタートしました。1994年から2001年までの8年間は、まさにプログラマー(PG)として現場でコードを書き続けた日々でした。当時はペアプログラミングという概念もなければ、StackOverflowもない。もちろんAIなんて影も形もありませんでした。
AIツールの登場で、確かにコーディングの効率は劇的に上がりました。でも同時に、プログラマーとしての本質的なスキルが見えにくくなっているとも感じます。「コードが書ける」ことと「プログラマーである」ことは、実は別物なんです。
[EXPERIENCE: ここにTech-Tの実体験を300〜500字程度で入れる予定]
当時の私は、COBOLで銀行の基幹システムを実装していました。1997年頃、ある大規模な取引履歴テーブルの検索処理で、どうしてもレスポンスが3秒を超えてしまう問題に直面しました。要件では1秒以内という厳しい制約があったんです。
先輩に相談しても「自分で考えろ」と突き放される。マニュアルを読み漁り、SQLのEXPLAIN文で実行計画を何度も確認し、インデックスの張り方を変え、WHERE句の順序を入れ替え、最終的にはテーブル設計そのものを見直す提案をしました。結果的に0.8秒まで改善できたとき、達成感よりも「なぜ最初の設計ではダメだったのか」という本質的な理解が深まった感覚がありました。
この経験が、後のキャリアで何度も私を救ってくれました。AIがコードを生成してくれる今の時代でも、「なぜこの処理が遅いのか」「なぜこの設計ではスケールしないのか」を理解する力は、結局人間が持つしかないんです。
AI時代だからこそ見えにくくなった「学びの過程」
現代の開発現場では、GitHub CopilotやCursorといったAI支援ツールが当たり前になりました。コメントを書けば関数が自動生成され、エラーメッセージを貼り付ければ修正案が提示される。これ自体は素晴らしい進化です。
でも、私がPG時代に経験した「なぜそうなるのか」を自分の頭で考え抜く過程が、今の若手には圧倒的に不足していると感じます。AIが答えを出してくれるから、その答えに至るまでの思考プロセスを経験しないまま次に進んでしまう。
1999年頃、私はPowerBuilderというツールで在庫管理システムを作っていました。あるとき、データウィンドウ(PowerBuilder独自のデータ表示機能)で数万件のデータを表示すると、画面が固まる問題が発生しました。
当時はGoogle検索すらまともに使えない時代です。英語のマニュアルを辞書片手に読み、サンプルコードを一行ずつ追いかけ、「ああ、一度に全件取得しているからメモリを圧迫しているんだ」「ページング処理を実装すれば解決するのでは」という理解に辿り着くまで、丸3日かかりました。
今ならChatGPTに「PowerBuilder データウィンドウ 大量データ 対処法」と聞けば、10秒で答えが返ってきます。でも、その3日間で得た「メモリとパフォーマンスの関係」「データ取得の設計思想」という理解は、AIからの回答だけでは絶対に得られないものでした。
コードが書けることとシステムが作れることの違い
もう一つ、現代の若手プログラマーに欠けていると感じるのが「要件を実装に落とし込む力」です。これはPGとSEの境界領域にある能力で、私のPG時代8年間で最も鍛えられたスキルでもあります。
2000年頃、私はVisual Basic 6.0でクライアントサーバ型の販売管理システムを担当していました。お客様からの要件は「売上集計画面で、担当者別・商品別・期間別の3軸で自由に切り替えられるようにしてほしい」というものでした。
一見シンプルな要件ですが、実装レベルに落とすと複雑です。どのタイミングでデータベースにアクセスするのか、3軸のどの組み合わせでもパフォーマンスを維持できるインデックス設計は何か、画面のユーザビリティとしてどのUIコンポーネントを使うべきか。これらは全て、プログラマーが判断しなければならないことでした。
AIは「担当者別集計のSQLクエリ」は生成してくれます。でも「3軸の切り替えをどう実装すべきか」という設計判断は、結局人間がやるしかありません。そしてその判断の質は、実装経験の深さに比例します。
なぜプログラマーの「本質的スキル」が育たなくなったのか
では、なぜ現代のプログラマーは、コードは書けてもシステムが作れない、AIに頼りすぎて本質が見えない、という状況に陥るのでしょうか。30年の経験から見えてくる構造的な原因があります。
即座に答えが得られる環境が思考を停止させる
私がPG時代に経験した最大の学びは、「分からないことと格闘する時間」そのものでした。エラーメッセージの意味が分からない、パフォーマンスが出ない、要件をどう実装すればいいか見当がつかない。そういう状態で、数時間、時には数日悩み続けることが日常でした。
この「悩む時間」が実は極めて重要だったと、今になって分かります。悩んでいる間、脳はずっと問題と向き合い続けています。マニュアルを読み、コードを追いかけ、仮説を立てては検証し、また仮説を立て直す。この繰り返しの中で、プログラミング言語の仕組み、データベースの動作原理、OSのメモリ管理といった基礎的な理解が深まっていったんです。
現代は、その「悩む時間」が極端に短くなりました。エラーが出たら即ChatGPT、実装方法が分からなければCopilotに任せる。答えが10秒で得られるので、悩む必要がないんです。
でも、その10秒で得た答えは「今回の問題の解決策」でしかありません。次に似たような問題が起きたとき、また同じようにAIに聞くしかない。自分の中に知識として蓄積されないんですよね。
抽象化レイヤーが増えすぎて根本が見えない
もう一つの構造的な問題は、現代の開発環境が高度に抽象化されすぎていることです。私がCOBOLを書いていた1990年代は、メモリ管理もファイルI/Oも、全て自分でコードを書いていました。だからこそ、「このループは何回回るのか」「このファイルアクセスでディスクI/Oが何回発生するのか」といった根本的な動作を意識せざるを得なかったんです。
今のフレームワークは素晴らしく便利です。ReactでもVue.jsでも、数行のコードで複雑なUIが実装できる。ORMを使えばSQLを書かなくてもデータベース操作ができる。でも、その裏で何が起きているのか、若手プログラマーは知らないまま使っているケースが多いんです。
例えば、ORMで「全ユーザーの全投稿を取得」という処理を書いたとき、裏で何千回ものSQLクエリが発行されるN+1問題が起きることがあります。これは、SQLとデータベースの基本的な動作を理解していれば防げる問題です。でも、抽象化されたORMだけを使っていると、この問題の存在にすら気づかないまま本番リリースしてしまう。
私のPG時代は、抽象化レイヤーが薄かった分、根本的な動作原理を理解せざるを得ない環境でした。それが結果的に、30年経った今でも通用する基礎力になっているんです。
「動けばOK」という短期視点の評価基準
もう一つ見逃せないのが、現代の開発現場における評価基準の変化です。アジャイル開発やスプリント単位での成果測定が一般的になり、「今週中に動くものを作る」ことが最優先されるようになりました。
この短期視点自体は悪いことではありません。でも、その結果として「コードの品質」や「プログラマーとしての成長」が後回しにされている現場を多く見てきました。AIが生成したコードをコピペして動けばOK、なぜそのコードなのか理解していなくてもスプリントは完了、という状況です。
私のPG時代、特に金融系の基幹システム開発では、コードレビューが非常に厳格でした。1997年頃、私が書いたCOBOLのバッチ処理を、先輩が2時間かけてレビューしたことがあります。「このIF文のネストは深すぎる」「この変数名では何を格納しているか分からない」「このループは別サブルーチンに切り出すべき」と、一行一行指摘されました。
当時は正直、面倒だと思いました。でも、その厳格なレビューを通じて「読みやすいコード」「保守しやすい設計」「バグが入り込みにくい書き方」という感覚が身についたんです。これは短期的な成果では測れない、長期的な成長でした。
AI時代の開発支援ツールと、それでも変わらない本質
ここまで、私のPG時代と現代の違い、若手プログラマーに不足しているスキルについて語ってきました。では、AI時代の開発支援ツールをどう活用すべきか。そして、それでも変わらない「プログラマーの本質」とは何か。現場目線で語ります。
GitHub Copilot:コード生成ではなく学習パートナーとして
GitHub Copilotは、コメントや関数名から自動的にコードを生成してくれるAI支援ツールです。私も現在の業務で使っていますが、使い方次第で「成長を止めるツール」にも「学習を加速するツール」にもなると実感しています。
多くの若手は、Copilotが生成したコードをそのまま使って終わりにします。でも私がお勧めするのは、生成されたコードを「なぜこの書き方なのか」という視点で読み解くことです。
例えば、Copilotが配列の重複を削除する処理で「Set を使った実装」を提案してきたとします。そこで立ち止まって考えるんです。「なぜSetなのか」「forループで1つずつチェックする方法との違いは何か」「パフォーマンスの差はどれくらいか」。
実際に私は、Copilotが提案したコードを一度削除して、自分で書き直してみることがあります。そして両者を比較して、「ああ、こういう書き方もあるのか」「この場合はCopilotの方が読みやすいな」と学んでいます。
私のPG時代は、先輩のコードを読んで学ぶしかありませんでした。Copilotは、ある意味で「世界中のプログラマーの知恵を集約した先輩」です。でも、その先輩から学ぶかどうかは、使う側の姿勢次第なんですよね。
Cursor:AIとの対話で設計思考を鍛える
Cursorは、AIとチャットしながらコードを書いていくエディタです。Copilotよりもインタラクティブで、「こういう機能を実装したいんだけど、どう設計すればいい?」という相談ができます。
私がCursorで重視しているのは、「なぜその設計なのか」をAIに説明させることです。例えば、「この関数を非同期にすべき理由は?」「このデータ構造を選んだ根拠は?」と質問を重ねます。
これは、私がPG時代に先輩から受けた詰問と同じです。1998年頃、私が書いたVisual Basicのコードを先輩がレビューして、「なぜここでグローバル変数を使ったんだ?」と聞かれました。答えられなかった私に、先輩は「理由がないなら使うな。グローバル変数は保守性を下げる」と教えてくれました。
Cursorとの対話も同じです。AIが提案した設計に対して「なぜ?」と問い続けることで、設計の背景にある思想や原則を学べます。そしてそれは、次に自分が設計するときの判断基準になるんです。
ただし注意点があります。Cursorの回答を鵜呑みにしないこと。AIも間違えますし、現場の制約(既存システムとの整合性、チームのコーディング規約など)は考慮してくれません。最終的な判断は、やはり人間がやるしかないんです。
Claude/ChatGPT:エラー解決ではなく原理理解のために
Claude や ChatGPT といった汎用AIチャットは、エラーメッセージを貼り付けて解決策を聞く使い方が一般的です。これ自体は効率的ですが、私はもう一歩踏み込んだ使い方をお勧めします。
エラーが解決した後、「なぜこのエラーが起きたのか」「根本原因は何か」「同じエラーを防ぐにはどうすればいいか」まで聞くんです。そして、その回答を自分の言葉でメモに残します。
私のPG時代は、エラーと格闘した経験を「障害ノート」に手書きで記録していました。「1999年3月、OracleでORA-01555エラー。原因はロールバックセグメント不足。対策は…」といった具合です。このノートが、後の開発で何度も役立ちました。
現代版の障害ノートとして、AIとの対話履歴を整理して残すのは有効です。ただし、AIの回答をコピペするだけでは意味がありません。自分が理解した内容を、自分の言葉で書き直すプロセスが重要なんです。
30年前も今も変わらないのは、「知識は経験と紐づいて初めて身につく」ということ。AIが教えてくれた原理を、実際のコードで試して、失敗して、理解する。この過程を飛ばすと、結局何も残らないんですよね。
30年現場にいた私が思うこと
私のPG時代8年間は、決して華やかなものではありませんでした。COBOLの無味乾燥な構文と格闘し、英語のマニュアルを辞書片手に読み、先輩の厳しいレビューに何度も書き直しをさせられる。AIどころかインターネットもまともに使えない環境で、泥臭く学ぶしかなかった時代です。
でも、その8年間で得た「なぜそうなるのか」を考え抜く力、要件を実装に落とし込む設計思考、バグの根本原因を追求する姿勢は、30年経った今も私のキャリアの土台になっています。SEになってもPMになっても、結局はプログラマー時代に身につけた基礎力が全ての判断の基準になっているんです。
AI時代の今、コードを書くこと自体のハードルは劇的に下がりました。でも、「プログラマーである」ことの本質は変わっていません。それは、問題の本質を見抜く力、技術の背景にある原理を理解する力、そして要件とコードの間を往復しながら最適解を探る思考力です。
私が金融系の基幹システムで学んだ厳格な品質管理の考え方は、今の中小企業の現場でも応用できます。当時は「過剰品質だ」と感じたコードレビューや設計ドキュメントの作成が、本番障害ゼロを支えていました。中小企業が同じレベルでやる必要はありませんが、「なぜこのコードなのか説明できる」という基準だけは持つべきだと思います。
明日から始められる小さなアクション
もしあなたが若手プログラマーで、AIツールに頼りすぎていると感じているなら、こんな小さなアクションから始めてみてください。
今日AIが生成したコードを1つだけ、自分の言葉で説明してみる。誰かに説明するつもりで、「このコードは何をしているか」「なぜこの書き方なのか」「他の方法との違いは何か」を、メモに書き出してみるんです。
説明できないなら、それは理解していないということです。そこでもう一度、そのコードを調べ直す。変数を変えて動かしてみる。わざとバグを入れてどうなるか試してみる。この「手を動かして確かめる」プロセスが、プログラマーとしての成長の核心なんです。
技術リーダーの方なら、若手のコードレビューで「なぜこの実装を選んだの?」と一言聞いてあげてください。答えられなかったら、一緒に考える時間を作る。AIが提案したからという理由ではなく、自分の判断基準を持てるように育てる。これが、AI時代のプログラマー育成だと私は思います。
私のPG時代、先輩が教えてくれたのは「答え」ではなく「考え方」でした。「このエラーはどうすれば直りますか?」と聞いても、「マニュアルの何ページを読め」としか言われない。最初は不親切だと思いましたが、今になって分かります。あれは、自分で答えを見つける力を育てようとしてくれていたんです。
AI時代だからこそ、「自分で考える力」の価値が上がっています。AIは優秀なアシスタントですが、あなたの代わりにプログラマーにはなってくれません。コードを書くのはAI、考えるのは人間。この役割分担を意識できるかどうかが、これからのキャリアを大きく左右すると思います。
30年前、COBOLのコンパイルエラーと格闘していた私には、AIがコードを書いてくれる未来なんて想像もできませんでした。でも、あの時に学んだ「なぜ?」を問い続ける姿勢は、技術がどれだけ進化しても色褪せていません。あなたも、AIを使いこなしながら、その奥にある本質を見失わないでください。それが、プログラマーとして長く現場に居続ける秘訣だと、私は信じています。
コメント