絶対的に正しいやり方を書いているわけではなく、筆者環境でうまく行った・行かなかった事例を反省・分析したものである。
今季は（というより、ChatGPTまたはGPTsが出てから）AIを教育現場でも活用しよう！という動きが活発だったので、その話をしていく。
タイトル回収
特にZ世代の傾向として「タイパをはじめ効率的かどうかを重視する（＝無駄を避ける）」傾向があるので、やってみせて真似をさせる方法が彼らにとって学びやすい状態である事が多い。
本題（補足）
タイトル回収で結論を述べたが、これだけだと分かりにくいので実際に直面した課題ごとに分析していく
AIは考え方を教えてくれない
これが一番の問題。
教育システム用にカスタマイズしたGPTsだと「こういう教え方をした方がいいよね」という知見がアナログなりデジタルなりで知見はあるので、それらの振る舞いをLLMの回答にに載せるということはできる。
ただし、AIの失敗が見た目に失敗なのかどうかが、受講生目線でわかりにくいのが問題。
たとえば、講師が指導・解説中に「あ、間違えた！」という瞬間がある場合は、見た目や言動、なんなら表情で失敗したことに気付くし、相応のリアクションもある。
ただし、AIの場合はハルシネーションが発生しても自発的に修正はしない（しにくい）ので、新人目線では回答がハルシネーションなのかどうかは当然わからない。
「AIが講師をやればいい！」という意見は私も賛成だし、徐々にそうなってほしいが「ユーザーに指摘を受ける前にAI自身が間違いを間違いだったと気付いて、すぐに修正し正しい案内を伝える」という運用が必要になる。
極端に言えば、AIが生成した結果が正しいか判定する仕組みは結局必要になる。たとえAI1が生成したものをAI2がチェックをして、修正した内容をAI1に投げ返して判断して、どちらも問題ない状態を作って、とやると擬似的にダブルチェック環境は作れそうだ。
（実現させる場合は、AIを複数運用するので単純にコストが倍、さらに倍になる事も想定しておきたい）
AIの回答が分からなかった場合に新人は次のアクションを起こせない
toC向け研修で多いのがこのケース。
toBでも発生するが、主に「マンツーマンの個別指導か、グループ研修か」という観点で見ると解決アプローチが変わってくるのもこのケースだ。
つまり「AIに聞いても自分には分からない回答をされてしまう」ため、頼れる人を探している状態とも言える。
補足：「そうじゃないでしょ」と思った方向け
あなたはできる方です。
できるようになる努力をしている人には色々な種類がおり、AIがいるのにプログラミングの学習ができない人は残念ながら存在する。
まず、本来の対応としては分からないなりに自力で解決方法を探してもらう、というのが実践的であり、ITエンジニアとして就業するなら現実的な選択肢になる。
ここに思考のズレはない。私もそう思う。
が、悪く言えば学習意欲がない（受け身の姿勢。わかりやすく言えばお客様意識でプログラミングスクールに入校・入塾された）方ほど他責になりがちで「困っているのだから解決しろ」というメッセージが飛んでくる事も残念ながら０ではないのが実情だ。
いかんせん「お金を払って勉強する」という考え方ではなく「お金を払ったので問題解決してもらえる」という考え方をする人は少なからず存在する。
結婚相談所が分かりやすいので例に挙げるが「お金を払って出会いの場と、出会った後の人間関係構築を助けてもらえる」と考える人と「お金を払ったので結婚できる」という考え方をする人の違いである。
今現在、本稿を閲覧している方は間違いなく自力で調べて、または紹介されて閲覧されているので問題ないが、「あなたは仕事として業務を得たら、現場社員に１から教育しろというのか」と思われている事を認識させたいが、実際問題として費用を支払う側になると「神様」という意識が生まれてしまうのも日本人なら仕方ないか。
何はともあれ「プロとしてお客様の困りごとを解決する」という意識は学習・研修段階でも持つべきであるのだが、悲しいかなマインドセットを教えるプログラミングスクールは私が知るところで皆無だ。
（以下、傾向の話であるため反例あり）解決方法を教えるのは良い方法ではない
残念ながら幻想である。少なくとも、Z世代の指導においては。
なぜなら、自分で試行錯誤するフェーズは「ある程度状況を理解できてから」という意識がある。
そして、一面的には正しい。
社会人経験者なら理解できる話で、学生にわかりにくい話の一つに「答えは自分で生み出すもの」が挙げられるだろう。
学校社会において勉強でもテストでも必ず答えがあり、答えのあるものを正しく求める。そして、それが評価される世界に10年超もいれば自ら新しいものを自発的に生み出していこうという意識は普段から培わないとなかなか出てこない。
では、自力で考えて解決に導くために、解決方法となるキーワードや考え方、気付きなどを自らたどり着けるように促していくやり方をするだろう。
これが従来よく取り入れられていた、エンジニア界隈での教育方法だと思われる。
このやり方は実績が多く、また効果を生み出してきたため教育手法として手順や使い方もフレームワークとして確立されている。
しかし、このやり方は当時良かった方法で、今も通用する面もあるが、必ずしもこのやり方を続ければ良いということではない。
過去うまく行った方法にいつまでもしがみつくのは停滞以外の何物でもない。
新しい教育手法が良いとは私も思わないが、教育者としては受講者にあった学習方法を模索する事をやめてはいけないと考えている。
解決方法ではなく、講師の考えを開示し実践する
いわゆるハンズオン形式での解説だが、重要なのは「受講生は講師のライブコーディングを見て、考えを学ぶ」というアプローチだ。
ライブコーディングをそのまま実践すると「早すぎてついていけなかった」というコメントが飛んできて何の学びにもならない。いわゆる動画コンテンツと違って、ライブの場合は受講生の理解速度に講師が合わせられないからだ。
そこで、ライブの良さを考える。ライブの良い部分はインタラクティブ性だ。具体的には、講師から発信するのではなく、受講生から発信するものを講師は迅速に受けて解決アプローチを検討できる。
その上で、動画コンテンツの良さである「受講生の理解速度に合わせる」を実践する。
講師がやるべきは「ライブコーディングを行なって課題を完成させる」ではなく「ライブコーディングを行いつつ、理解度を確認する」ということである。
これを実践する手法として、受講生によるレビュー駆動開発を取り入れたハンズオン学習である。
レビュー駆動開発(Review Driven Development)とは？
まず、受講生はレビューができないし、コードも読めない。
この前提で、講師はライブコーディングを行うのだが、予め受講生には完成系のコードを渡しておく。
そして「これからコードを書く。わざと間違えて書くので、何が間違えているのか指摘してみてほしい」と言付けておく。そうしないと「この講師は大丈夫か？」と見られてしまうからだ。
そして、ライブコーディングを行う環境のコードと比較できるようにする。できればGitHubのPull Request画面レベルで開示したいが、リアルタイムに反映する仕組みは難しいのでVSCodeあたりでdiffを取ってみせると良い。
そして、講師にはぜひライブで間違えたり躓きを意図的に作ってほしい。
最初は配列のループを1から始めてみたり、繰り返しの条件の「<=: 以上」と「<: より大きい」を変えてみたり、初期値を入れたり入れ忘れたり。
受講生とのコミュニケーションのレベルが上がってきたら、意図的にシンタックスエラーを書いたり、nullオブジェクトのプロパティ・キーを参照してみたり。
受講生には完成のコードがあり、講師は間違えたコードを書くことで、受講生にとっては答えがわかっている状態でエラーの内容や、おかしい状態が見れることになる。
これだけでもかなり心理的安全性が高まり、エラーがどういうものなのかを傍目に知る事ができる。
自分が同じ状況になった時に、どのように解決するか目の前で実践されているので鮮明なイメージを持つ事ができる。
ステップアップ（複数人でもできる）
この方法はモブプログラミングである。
まず、受講生にある課題を与え、AIを使っても良いので完成形のコードを作ってもらう。
ドライバーとなる講師は、完成形のコードを見ながら、１から手打ちをしていく。
この時、完成形のコードをコピペで貼り付けるのではなく、一行ずつ書いて実行していって、結果がどのように変わっていくかを見ていくというやり方だ。
そのため、デバッグプリントやブレークポイントを多用することになる。
つまり、AIは完成形のコードを上から書くが、実際の開発においては完成イメージがわかない状態で上から順番に綺麗に書くことは不可能だ。
そのため、分かるところから徐々に進めていくという流れを見せる。複雑そうな問題も、一つずつ処理することで問題ないと思わせる事が狙いである。
自分で考えることは大切だが、どのように考えて行動するかのイメージをまずは持たせる事が先決だ。
あなたが勉強中の受講生である場合
講師のやり方でわかりやすい！と思った場合は本稿を使う必要はないが、講師の教え方が自身に合っていないと感じた場合、自分が理解しやすい方法をぜひ提案・教えてほしい。
本稿のやり方があなたに合っている可能性もあるはずなので、学び良い環境づくりのために講師とやり方を試行錯誤するのも一手だ。
特に費用を払うプログラミングスクール生であれば、なおさら貴重な予算を割いたのだから活用しきるつもりで環境を使い倒そう。
筆者は10代前からプログラミングを学ぶ事が早すぎるとも、80歳を超えてから学ぶ事が遅すぎるとも思わない。
いつでも学び始められるし、事業化・副業化する方法はどこからでもできると考えている。
ただし、覚悟してほしい。
日本だけでなく、世界中のエンジニアが味方でありライバルでもあるし、技術の進歩は想像を絶するほど早い。何の冗談でもなく、毎日・一生勉強し続けなければならない業界でもあるし、それは当たり前だと思っている人が多いし活躍しているのがIT業界である。
休みがない、とは言わないがあなたが休んでいる間にもボトム層からトップ層に至るまで効率的に勉強を続けている可能性が高いという意識は常に持ってほしい。
筆者が10年以上エンジニアを続けていれる理由
まず、コードを書くことを仕事だと思いながらイヤイヤやっているという感覚はない。たとえ炎上プロジェクトに入ったとしても。
システム設計を考える（オタク特有の「ぼくがかんがえたさいきょうのなんとか」考察に近い）のも楽しいし、実際に組むのも好きだ。
とはいえ、転職回数は20代のうちに二桁に突入したので、どちらかというと人付き合いや契約などで衝突があったり、会社が描くビジョンに共感できないというケースばかりだった。
（それで結局フリーランスとして独立するのだが）
これは今も続いていて、積極的に勉強会や技術者コミュニティに貢献しようという意欲すらある。
後進育成をしっかり行うことで、将来の自分を助ける事になると本気で考えているからだ。
とはいえ、この考え方はかなり特殊で、全てのエンジニアがこのような考え方でいるわけではない。
読者自身にとって合うメンターを探せばよいと考えている。そのメンターが本稿であり、私であれば幸いである。