昨今のプログラミング学習においては、いつでも気が済むまで質問に答えてくれる生成AIの登場により、以前よりも遥かに効率よく知識を得られるようになりました。多くのプログラミング学習者が、まずAIに質問し、素早く答えを得るという学び方を取り入れています。
その一方で、答えはわかるのに成長している実感がない、得た知識が次の課題に応用できないと感じる人が少なくありません。理解したつもりなのに使える知識として定着していないのはなぜなのでしょうか。
学習効率を低下させる生成AIの特性を理解し、生成AIを使うだけでは身につかない能力を育むことができる環境に身を置くことで、プログラミング学習をより効果的に進めることができます。
生成AIを使った学習で起こりがちな問題
生成AIの持ついくつかの特性が原因で、プログラミングの学習効果を下げてしまうことがあります。
生成AIは「わかったつもり」を生みやすい
生成AIは常に滑らかで整った文章で返答します。人間は「読みやすい文章 = 正しい・理解できた」と錯覚してしまうことがあり、このことから理解が曖昧なままでも内容を正しく捉えた気になってしまいます。
生成AIは誤った前提を否定しない
また、初学者が誤った前提で質問しても、AIはその前提を明確に否定せず、やんわり補足するだけの場合があります。
たとえば以下のようなケースです。
誤った質問: 入力チェックをフロントエンドでちゃんとやっていれば、バックエンド側のバリデーションっていらないですよね？
AIの回答: フロントエンドでのバリデーションはユーザー体験を向上させるためにとても重要です。そのため、フロントエンドで入力チェックを行うケースは多いです。ただし、セキュリティやデータ整合性の観点から、バックエンド側でもバリデーションを行うことが一般的です。
AIの回答の通り「フロントエンドでのバリデーションはユーザー体験を向上させるためにとても重要」ですが、「バックエンド側のバリデーションっていらない」は誤りです。ユーザーは誤解していますが、AIはその誤解を訂正せず「バックエンド側でもバリデーションを行うことが一般的」とだけ補足するにとどまっています。
このように、誤解を訂正せずに受け止めてしまうことで、理解の錯覚が強まりやすくなります。
生成AIはユーザーの「理解している部分・理解していない部分」を考慮しない
生成AIは、与えられた文章だけをもとに返答を生成するため、ユーザーが何を理解していてどこでつまずいているのかを考慮しません。
たとえば以下のようなケースです。
質問: Reactのprops drillingを避けるためにuseContextを使うのが良いと聞きましたが、どんな場面で使うのが適切ですか？
AIの回答: useContextは複数のコンポーネントで共有したい値がある場合に便利です。テーマや認証情報などでよく利用されます。
人間であれば、この質問から「props drilling = なにか悪いものであると短絡的に理解している可能性がある」ということを察して、質問された内容以上にいろいろと話しを広げてくれる人もいます。しかし、AIは質問文に書かれている内容だけをもとに回答するため、ユーザーの理解度を考慮した補足は行いません。
生成AIを使うだけでは身につかない能力
実際のプログラミングの現場で求められる能力には、人間同士のやり取りを通じてしか習得できないものがあります。
意思決定を下すために必要な能力
生成AIの補助のおかげでコードを書くスピードや試行錯誤の回数は劇的に増加しましたが、実装が速くなるほどボトルネックになりがちなのは「意思決定」です。しかし、意思決定のために必要な調査や比較、合意形成のために必要な能力は、生成AIを使うだけでは身につきにくいです。
良い意思決定を下すためには、まず十分な判断材料を集める必要があります。何を比較するか・どのように比較するかなどの調査方法の設計が重要になります。AIエージェントが調査計画を生成してくれることもありますが、その計画が妥当かどうかを判断するには調査の設計のスキルが必要です。
ある程度材料が揃ったら、材料をもとに比較し方針を決める段階に入ります。以下のような制約を考慮してトレードオフを判断します。
- 長期的な保守性
- プロダクトやビジネス上の要件
- 許容できるリスクと、許容できないリスク
こうした制約を明確に言語化するスキルがなければ、選択肢を正しく評価できません。生成AIは制約が曖昧なままでもそのことを指摘せず受け入れて回答を続けてしまうため、判断の前提が整理されているかどうかをチェックできません。
人間との議論を通じて明らかになる「理解の曖昧さ」
他の開発者と議論してみると、自分では気づけなかった理解の曖昧さが明らかになる場面があります。
- 質問にうまく答えられない
- 説明している途中で自分の矛盾に気づく
- 自分の前提が相手にまったく通じていない
- 「なぜその判断をしたのか」が言語化できない
生成AIはユーザーの説明に矛盾があっても、それを積極的に指摘することはありません。前提が曖昧でも「この質問の意図はこういうことだろう」と勝手に解釈して回答を生成するため、自分の理解の曖昧さが明らかになる体験がほとんど起きません。
一人で学ぶだけではなく、良い環境に身を置くことが重要
初学者が効率的に学習・成長するためには、ただ生成AIを使うだけでなく、以下のような学習環境に身を置くことが重要です。
- 技術的な議論を通じて、お互いの理解の曖昧さを指摘しあえる仲間がいる
- 設計や実装の判断理由を説明したり、他の人の判断と比較したりする場がある
- 仮説検証が不可欠な難易度の高い課題に取り組み、意思決定や合意形成を経験できる
もしすでにこのような環境に身を置けているのであれば、努力を継続することで大きく成長が期待できます。
しかし現実には、こうした環境に恵まれている初学者は多くありません。
- 技術について本気で話せる仲間がいない
- コードレビューの文化がなく、判断理由や調査プロセスを説明する機会がない
- 難易度の低い作業しか任されず、トレードオフ判断の経験が蓄積しない
現実の環境が理想的でない場合、外部の「良い環境」を探す必要があります。
「良い環境」を提供するために設計された学習プログラム
弊社（株式会社プラハ）では前述したような「良い環境」を提供することを目的とした学習プログラム「プラハチャレンジ」を2022年から運営しています。
前述したような問題を意識して設計されたわけではないですが、結果的に生成AIでは代替できない部分を伸ばすことができる構造になっています。
課題解決型カリキュラムで「調査・比較・検証・意思決定」のプロセスを経験できる
知識を一方的に与える座学ではなく課題を通して学ぶ形式になっており、課題の多くが調査・検証・比較を含む構造になっています。
たとえば以下のような課題があります。
ツリー構造をリレーショナルデータベースで表現する際（例えばslackのようなスレッドを表現する時など）に、以下のように親の ID だけを持つツリー構造を見かけることがあります。
```sql
TABLE Message {
id: varchar
parent_message_id: varchar
text: varchar
FOREIGN KEY (parent_message_id) REFERENCES Message(id)
}
```
上記の設計では`parent_message_id`にMessage自身のidを持つ、自己参照を用いています。
この設計だとどのような問題が生じるか、説明してください。
この課題に対して、参加者は以下のようなステップで取り組むことになります。
- ツリー構造をRDBで表現する方法を調査する
- ツリー構造の表現方法が複数あり、それぞれにメリット・デメリットがあることを理解する
- どのようなユースケースでどの設計が適しているかを考察する
- 調査内容と考察を文章でまとめ、チームメンバーと議論する
これにより、「生成AIにとりあえず質問する → 答えが得られたので納得する」という学習方法では得られない調査・比較・検証・意思決定のプロセスを経験できます。
ピアラーニングで理解の曖昧さに気づける
プラハチャレンジはピアラーニング中心のカリキュラムなので、ただ課題に答えたらおわり、というわけではありません。以下の進め方を前提としています。
- 課題に回答する
- チームで相互レビューする
- 回答結果についてチームで話し合う
- チームで合意が得られたら、次の課題に取り組む
他のメンバーと技術的な議論をするためには、まず自分の理解を言語化して説明する段階が必要です。また、他のメンバーから理解の曖昧さを指摘されることもあります。これにより、前述した理解の曖昧さを明確にできます。
メンターによる広い視点からのフィードバックが得られる
チームでの議論によって認知のズレに気づくことができても、それをどう修正すべきかであったりどの視点が不足しているかであったりは、初学者だけで判断しきれないことがあります。
そこで重要になるのがメンターによるフィードバックです。メンターは「正解を教える人」ではなく、学習者の説明や思考の流れから視点の不足を見抜き、それを補うための質問や指摘をする役割を担います。具体的には次のような内容を扱います。
- チームでは出てこなかった新しい視点を提示する
- 設計判断の背景にあるトレードオフやドメイン知識を、実際の経験に基づいて補足する
- 初学者では気づきにくい前提の飛躍やヌケモレを指摘する
メンターは、生成AIがやってくれない質問への回答以外の形で介入して学習をサポートします。
コラム: なぜこのような学習プログラムを運営しているのか
開発の現場、とくに新規事業やスタートアップでは「開発側の事情が仮説検証の足かせになり、事業が競争力を失っていく」という問題が頻発しています。この問題に対して「新規事業に特化して質の高いサービスを作れる集団があれば、この課題を解決できるのではないか」という仮説のもと創業されたのが株式会社プラハです。
とはいえ、プラハでエンジニアを採用して受託開発をするだけではこの問題を解決できません。プラハの開発ノウハウをカリキュラムとして社外に提供することで、所属を問わず幅広くエンジニアの開発能力の底上げに貢献するため始まった事業がプラハチャレンジです。
プラハチャレンジは「成長を支える環境への投資」という創業時からの理念を、そのまま事業として具現化した取り組みです。質の高い課題、議論できる仲間、レビュー文化、設計力を磨く仕組みなど、実務に近い環境を整えることで、受講生が本当に成長できる環境を作っています。
ありがたいことに、受講生の中からプラハに転職してくれる方がいたり、逆にプラハ側から声をかけさせてもらうこともあります。採用につながる可能性というインセンティブもあるため、受講生が本当に成長できる環境を作る = 受講生の成長がプラハにとっても価値になるという利害の一致が成り立っています。
参考記事
最後に、卒業生の方々がプラハチャレンジについて書いてくださった記事を紹介します。興味があればぜひご一読ください。
Discussion