はじめに
対象読者: AI時代に、プログラミング初心者への教え方で悩んでいる人
この記事で伝えたいことは、次の3つです。
- AIが前提になった今、これまで通りの「基礎を学んで、とにかく動くものを作る」という教え方ではうまくいかない
- これからの初心者教育では、コードの書き方より先に「思想」を渡したい
- ここでいう思想は大げさなものではなく、「コードや設計はこうあってほしい」という自分なりのこだわり・意思のこと
なぜそう考えるようになったのか、自分の失敗と体験から順番に書いていきます。
1年前に教えた後輩たちの「現実」
私は大学生(学部3年生)で、とあるプログラミングサークルに所属しています。昨年からは先輩として、初心者の後輩たちにモバイルアプリ開発などを教えるようになりました。
初心者向けの勉強法としてよく言われるのは、「最低限の基礎を学んだら、あとはとにかく動くプロダクトを作ってみるといい」というものです。私自身もそうでした。2年ほど前にFlutterを学んだときは、動画を参考に基本の書き方を覚え、その後の個人開発で力をつけました。
そのときの個人開発は、
コードを書く → エラーにぶつかる → 疑問が生まれる → 手が止まる → 自分で調べて理解する → またコードを書く……
の繰り返しでした。この試行錯誤が自分にとって大きな財産になったので、後輩にも同じように、基礎を学んでから個人開発で実践的に学んでいくことを勧めました。
ところが、この1年でコーディングエージェントは大きく進化し、もはやコードを自分で書く必要すらなくなりました。そんな時代に、初心者はどうやって動くプロダクトを作るのか。
私が一番多く見たのは、「AIにざっくりとした機能のイメージを伝えて、コードを丸ごと生成させる」やり方です。
そうして1年後、後輩たちが直面した現実は、こういうものでした。
動くプロダクトはたくさん持っているが、理解は最低限の基礎のまま。
AI禁止も「1行ずつ理解」も、成長にはつながらなかった
なぜ彼らに力がつかなかったのか。よく言われる答えは「AIに実装を丸投げして、コードの理解を怠ったから」。これは正しいと思います。
そこで私は対策を打ちました。AIによるコード生成を禁止する。あるいは、生成されたコードを1行ずつ理解させる。けれど、どちらも初心者の成長にはつながりませんでした。
便利だと分かっているAIを禁止されてまで、プログラミングを続けられるモチベーションを全員が持てるわけではありません。かといって、生成済みのコードを後追いで理解しようとしても、自分が書いたものではないので腹落ちしないのです。
ここに大きなヒントがある気がしました。「動くだけのコード」が学びにならないのは、AIのせいというより、理解の取っかかり（＝思想）を持たないまま、コードを後から眺めているからではないか。では、その思想はどうすれば手に入るのか。
鍵は「思想を持ってAIを使う」こと
その答えのヒントを、自分が参加した2つのバックエンド開発プロジェクトで得ました。
① 思想を持てなかったプロジェクト
ひとつは、アーキテクチャもテストコードもある程度組まれた、開発途中のプロジェクトへの参画です。使われていた言語やフレームワークは触ったことがなく、キャッチアップもほどほどに、まずはIssueをこなすことが求められました。
そこで連発したのが、「既存実装を参考に、このIssueを実装して」というプロンプトです。生成されたコードは読み、セルフレビューをしてからPRを出していたので、個々の機能が何をしているかは理解できていました。でも、
- なぜこのような実装になっているのか
- このコードは全体の中でどんな立ち位置なのか
このあたりをまったく理解しないまま、プロジェクトを終えてしまいました。
② 思想を持てたプロジェクト
もうひとつは、まったくのゼロから、技術選定やアーキテクチャの決定を自分で行えるプロジェクトです。こちらも、使う言語やフレームワークはお世辞にも経験豊富とは言えない状態からのスタートでした。
ただ今回は、アーキテクチャやデータベース、エンドポイントの設計をしっかり学び、考え抜いてから実装に取りかかりました。すると、AIへのプロンプトやレビューに、自分の意思やこだわり、つまり「思想」が宿ったのです。
こうなると、AIの言うままにコードを受け入れることはなくなります。AIの提案に自分の設計意図をぶつけて直させたり、自分の判断が本当に正しいのか不安になって調べたり。そういう行動が増えて、学びの機会が一気に増えました。
2つの違いが教えてくれたこと
ここで、冒頭の問いに戻ります。なぜ①は学べず、②は学べたのか。
違いは、思想を「先に」持っていたかどうかです。思想を先に持っていると、2つのことが起きます。
ひとつは、思想が物差しになることです。AIの出力をそのまま採用するか直すか、自分で判断するしかなくなります。そこで引っかかりや疑問が生まれ、調べ、学んでいく。逆に思想がなければ、出力されたコードを照らし合わせる基準がありません。だから後から1行ずつ読んでも、腹落ちしないのです。
もうひとつは、コードに思想が宿ることです。たとえAIが書いた行でも、その設計判断の一つひとつには自分の意思が乗っています。だからこそ、出来上がったコードに「自分のものだ」という所有感が生まれる。これは、①で味わった「自分が書いたものではないから腹落ちしない」感覚とはちょうど逆です。所有感があるから腹落ちし、もっと良くしたい、もっと深く知りたいと思える。こうして理解が進んでいきます。
①で私がやっていたのは、まさに後輩たちと同じ「後追いの理解」でした。物差しもなければ、所有感もない。一方②では、設計を通じて手にした思想が物差しになり、その思想が宿ったコードに所有感が生まれていた。この差だったのだと思います。
念のため補足すると、ここでいう思想は、技術哲学のような大層なものではありません。
- 責務分離・API設計・ディレクトリ構成・テスト・保守性などを「自分はこうしたい」と思える、こだわりや意思
もちろん、0→1の案件と既存コードへの参画とでは、キャッチアップのしやすさは大きく違います。それでも本質は同じで、そのプロジェクトに宿る思想を自分の中に落とし込めたかどうか、に尽きます。①のプロジェクトでも、既存設計を読み解いて、このコードを書いた人がどんな思想で開発していたのかを読み取れていれば、それに従ったり自分の思想とぶつけたりして、他人の思想ごと自分のものにできていたはずです。
では、初心者に思想をどう渡すか
ここで現実的な壁にぶつかります。私はこの思想を、最初の個人開発ではエラーや実装の試行錯誤の中で、後のプロジェクトでは設計や要件をWebサイトや書籍、AIとの壁打ちで決めていく過程で身につけてきました。
ところが初心者には、このどちらも難しい。試行錯誤は今やAIに奪われてしまいましたし、設計や要件をゼロから決めるのは荷が重すぎます。
そこで、我々経験者の出番です。初心者が思想を自力で手に入れられないなら、最初の種だけはこちらから渡してあげればいい。
具体的には、初心者がAIで実装に入る前に、次の3ステップを挟みます。
- ちょっとだけ座学をする。設計や考え方など、思想の出発点になる知識を、少しだけ先に学んでおく
- その内容をプロンプトに埋め込んでもらう。学んだ思想を、AIへの指示に反映させる
- AIの出力を座学の内容と照らし合わせる。「習ったこととズレていないか？」を確認する時間を取る
これは一見、最初にダメだった「1行ずつ理解させる」のと似ています。でも、決定的に違うのは順番です。後追いの理解には照らし合わせる基準がありませんでしたが、この3ステップでは座学で得た思想が先にあるので、AIの出力を測れる。だから引っかかりが生まれ、調べる動機になり、学びになるのです。
座学の知識がそのまま思想の種になり、プロンプトやレビューを通じてコードに宿る。さらに、その知識を初心者が自分でもっと深く調べはじめたら、もう思想を一人で育てられている証拠です。
初心者に最初の一粒を植えて、花を咲かせる手伝いをする。それが、AI時代の経験者の役割なのだと思います。
おわりに
この記事は、昨年後輩たちに教えたことの反省から生まれました。
AIに試行錯誤を奪われた分、今の初心者のプログラミング学習は、かつてより難しくなっていると思います。だからこそ、教える側にできることもまた変わるはずです。先輩として何ができるのか、これからも一生懸命に探していきたいです。
ここまでお読みいただき、ありがとうございました！