📚 学習法 11問

ドリル(反復練習用の課題)を進める中で、最初は理解できても後半になると解説を読んでも理解できないことがあり、AIに質問すると先に進めなくなってしまうため、完全に理解できない部分があっても立ち止まりすぎずに進めているが、この進め方で問題ないか、という質問です。

講師の結論は「大丈夫」です。ドリルはその名の通り、何度も繰り返すことで新しい技術や知識に慣れていくために作られたものであり、1回問題を解いただけですべてを理解できることは想定されていません。何度も薄く重ねていくことで、「まだよくわかっていないんだけどな」と思いながらでも前に進み続けることで、自然と復習にもなり、応用へと進んでいけるように設計されているといいます。

ただし、ドリルはあくまでドリルであり、実際にツールを使っているわけではないという点も強調しています。実際に自分の作りたいものを自分で作ってみること以上の学びは存在しません。今の段階でわからないことだらけなのは当然のことであり、ドリルを進めていく中で、いろいろな知識がつながってくる感覚も体感できるはずだと講師は述べています。

Git(変更履歴を記録・管理する仕組み)やGitHub(Gitのデータをオンラインで保管・共有するサービス)の重要性は理解できたものの、実際に何から始めればよいか分からないという質問です。

最初の一歩は、GitHub上で自分のリポジトリ(プロジェクトの保管庫)を作ることです。公開したくない場合はプライベート(非公開)なリポジトリで構いません。作成したリポジトリを、Git cloneコマンド(GitHub上のリポジトリを自分のパソコンに複製する操作)で手元に持ってきて、そこでコミット(変更を保存する単位で記録すること)し、プッシュ(手元の変更をGitHub側に反映させる操作)してみます。プッシュ後にGitHub上でも変更が反映されているのを確認できれば、最初の一周は完了です。

やり方が分からなくなったら、AIに直接聞くことが最も効率的な学び方だと講師は繰り返し強調しています。「Git・GitHubの重要性が理解できたので、次に何をすべきか教えてほしい」とAIに聞くだけで、自分に合った次の一歩が見えてきます。すべての人に完璧に伝わる説明を、講師が一人で用意することは現実的に不可能です。低コストで24時間365日、自分の理解度に合わせて説明してくれるAIに聞く方が、はるかに効率的です。

Gitのような概念は、一度の説明で完全に理解できるものではありません。講師自身も、Gitについて分からないことが出るたびにAIに聞きながら使っています。重要性を理解できた時点で、すでに学習の大きな山は越えています。あとは実際に手を動かし、疑問が出るたびに一つずつAIに聞いて解決していく、地道な積み重ねです。

プログラミング未経験の受講生が、AIにコードを書いてもらいながら課題に取り組む中で、AIが何をしているかをほぼ理解できておらず、作業後に「初心者でも分かるように整理して」とAIに聞いて理解を補っているという状況です。AI-Driven Rules(AI時代の行動指針)にある「理解できないものを作るな」という原則を、どの程度守ればよいのかという質問です。

結論として、今のやり方で問題ありません。そして今後もっと理解できるようになっていきます。「理解できないものを作るな」という原則自体は揺るがないものですが、プロのエンジニアであっても、AIが出したコードのすべてを事細かに理解しているわけではありません。以前のエンジニアが手作業で書いていた水準で1行1行を理解してはいなくても、AIを使った開発は問題なく進められています。

これは、合わせ調味料で美味しい料理を作るときに、調味料すべての製法を理解していなくても料理は作れるのと同じです。車の運転も、エンジンの仕組みをすべて理解していなくてもできます。AIの開発スピードは人間の理解のスピードを常に上回るため、1行1行をすべて理解することはプロのエンジニアでも行っていません。大事なのは、事細かな理解よりも、バグが起きにくい仕組みや構造を作れることです。

そのうえで重要なのは、AIが行ったことを事後的に確認し、疑ってみるプロセスです。「本当にこのやり方でよいのか」「なぜこの方法なのか」を、例えば中学生にも分かるレベルまで噛み砕いて説明してもらうと、誰でも理解できる言葉になります。そこで「もっとこうしたらいいのでは」という疑問をぶつけてみると、それが実は正しい指摘であることがよくあります。AIの書くコードは完璧ではなく、短期的な問題解決を優先した「パッチワーク」になりやすいためです。

理解すべき対象として特に重要なのは、処理の流れ(プロセス)です。料理でいえば、材料を切って、調味料を計量し、フライパンを熱して炒めて味付けするという手順があるように、プログラムにも常にステップがあります。個々のコードの詳細ではなく、「どんな順番で何が行われているか」という大枠を追えるようになることが、次の理解へとつながっていきます。

AI-Driven Rules(AI時代の行動指針)にある「議論する前にプロトタイプを作れ」というルールと、「スピードを出すな、対話しろ」というルールが、一見矛盾しているように感じるという質問です。

この2つのルールは、扱っている物事の大きさ(ピント)が異なります。「議論する前にプロトタイプを作れ」は、AI時代に開発のハードルが下がったことを踏まえ、企画書を作り込んで議論を重ねるよりも、まず動くプロトタイプ(試作品)を作った方が物事が前に進む、という大きな方向性についての指針です。ここでいうプロトタイプはあくまで試作品であり、完璧なプロダクトを一気に作れという意味ではありません。

一方「スピードを出すな、対話しろ」は、それよりも小さいピント、つまり実際に開発を進めていく1つ1つのプロセスに向けた指針です。プロトタイプを作るといっても、自分がどんな技術で何を作っているのかを理解しないままAIにひたすら指示を出して完成を急ぐと、最後の詰めの段階でうまく動かない箇所にぶつかったとき、行き詰まって解決できなくなってしまいます。何が起きているか分からないままAIに指示をして完成させようとすると、結局プロトタイプすら完成できなくなるということが起こり得ます。

つまり、大きな方向性としては「議論よりもまず動くものを作る」ことが推奨される一方、その作る過程においては「自分が何をしているか分からないままスピードだけを追わず、AIと対話しながら理解を深めて進める」ことが求められます。単純化して言葉だけを比べると、「急いで作れ」と「落ち着いて作れ」という矛盾に見えますが、それぞれ指している範囲の大きさが違うため、両立します。

対話を重ねながら進めると、その回はスピードが落ちたように感じても、次に似たような開発をするときには「これをして、これをして、こうすればいい」という段取りがパッと浮かぶようになり、結果的にはスピードが上がっていきます。逆にこの対話の過程を省略してAIに運転をすべて任せてしまうと、見かけ上のスピードは上がっても、何かトラブルが起きたときにどうにもできなくなってしまいます。

受講生から、ドリルの不正解をGeminiに解説してもらいながら進めると1レッスンに30分以上かかってしまい、目安とされていた「1日5分」とはかけ離れているがどう進めればいいか、という相談が寄せられました。

まず前提として、本気AIドリルは新しい概念に体験的に触れるための入口であり、ドリルをやり切るだけでその分野のプロになれるわけではないと説明されました。10年以上プログラミング教材を作ってきた経験から、「誰にとってもわかりやすい万能な教科書」は作れないという結論に至ったといいます。あらゆる人のつまずきに対応しようとすると、注記だらけのかえって分かりにくい教材になってしまうためです。

学び方には大きく2つのタイプがあるとも説明されました。抽象的でも雰囲気をつかんだら次に進むタイプは学習の立ち上がりが早く、逆に一つひとつ細かく理解してから進むタイプは初速こそ遅いものの、後から込み入った問題に強くなる傾向があります。短期間で結果を出すという観点では、白紙を一箇所ずつ濃く塗るよりも、全体を薄く塗って何度も重ね塗りするほうが効率がよいため、「細かいところにこだわりすぎず、まず終わらせる」ことがすすめられました。

目安である「1日5分」は、学習習慣を続けてもらうための最低ラインであり、5分だけで十分という意味ではないとも強調されました。運営としての具体的な目標は「1ヶ月に2シリーズを終える」ペースです。1レッスンに30分かける丁寧な進め方も悪いことではなく、時間が取れる範囲で自分のペースで復習しながら進めることが大切だと締めくくられました。

「理解できないものを作るな」というAI-Driven Rules(AIと開発するときに定める行動指針)を意識していても、AIの提案の妥当性を判断できず、なんとなく分かったふりで承認してしまう、という悩みが寄せられました。

これは仕組みだけでは完全には防げない、人間の認知バイアス(思い込みによる判断のゆがみ)の問題であると説明されました。経験のない分野については、AIに限らず人から説明されても疑うことができず、そのまま受け入れてしまうのは自然な反応です(例

)。長期的にはこの状況を減らす唯一の方法は「場数を踏むこと」ですが、それを効率的に進める工夫として次の2つが紹介されました。

1. 自分の言葉で説明できるまで、とことんAIに聞く。言葉より直感的な図のほうが理解しやすい場合は、AIにアスキーアート(文字や記号だけで描いた簡易的な図)で説明してもらうのも有効。
2. 質問と本来の作業を同じチャットで混ぜない。Cursorの「フォーク」機能(1つのチャットの流れを複製して分岐させる機能)を使い、本来の作業は元のチャットで進め、技術的な疑問はフォークした別チャットで聞く。Claude Codeであれば、作業の流れを止めずに質問できる /btw(By the wayの略)というコマンドもある。同じチャットで質問と作業を続けると、AIのコンテキストウィンドウ(AIが一度に処理できる情報量の上限)やアテンション(注意力)の限界により出力の質が落ちるため、分けることが推奨されました。

さらに、AIのアウトプット量やスピードは非常に速いため、将来的には一行一行すべてを理解する必要はなくなっていくとも語られました。ただし今の段階では、「今回だけはどうなっているか興味を持って調べてみる」姿勢がすすめられます。長期的には、AIが出したものの重要なポイントだけを確認し、細部はAIに任せられるようになることを目指して、今のうちに原理を理解しておくことが土台になる、という考え方が示されました。

前の質問に関連して、「理解できないものを作るな」というAI-Driven Rules(AIと開発するときに定める行動指針)の解釈の確認と、開発時に自分が理解できているかを判定するためのチェックリストについて相談がありました。

解釈については「理解できるまでAIに聞く」で正しいと確認されました。一方でセルフチェックリストを網羅的な形で作るのは難しい問いであるとした上で、判断の目安として次の1点が示されました。

「処理の流れを自分の言葉で説明できるか」

プログラムは複雑でわけの分からないものが同時にたくさん動いているように見えますが、実際にはひとつひとつの処理の流れがあります。たとえば、ブラウザからサーバーにリクエストが送られ、サーバー側でNode.js(サーバー上でJavaScriptを動かす仕組み)がそのリクエストを受け取り、データベースから情報を取り出す、というように、ステップごとに処理が進んでいきます。このステップを自分の言葉で順番に説明できるかどうかが、理解できているかを確認する実践的な指標として紹介されました。

日々の業務に不満や不便を感じる場面がなく、AIで自動化・改善できそうな課題を見つけられない、というときにどう考えを深めればいいか、という相談でした。

講義で紹介した「アンラーニング」(当たり前だと思ってきたやり方を一度分解し、見直すこと)という考え方を活用することがすすめられました。具体的には、自分の仕事を全く知らない人に対して、自分が日々何をしているのか、なぜそのやり方をしているのかを、作業の最初から最後まで一つひとつ言葉にして説明してみるという方法です。実際にやってみると、自分では意識していなかった暗黙知(言葉にされていないが実際には頼っているノウハウや判断)がいくつも見つかるといいます。

自分の仕事に足りないことを考えるコツは、何も知らない人にゼロから自分の仕事の中身を説明してみることに尽きる、とまとめられました。ただし、いきなり相手に説明を始めると驚かれてしまうため、まずは仲の良い人に協力してもらい、時間を取って練習してみるとよいとアドバイスされました。

4つのペイン構成の採用管理ツール(講義のワークで使ったひな形)を活用して学習しているが、スクール終了後に自分ひとりでゼロから同じような動作環境を構築できるようになりたい、という不安と要望が寄せられました。

ひな形を配布している理由がまず説明されました。ほとんどの受講生は、開発の概念さえ理解していればゼロから作っても問題ないものの、一部の受講生は見た目の細かい調整にハマってしまい、微調整を延々と繰り返すうちに何をしているか分からなくなってしまうことがあるため、その手間を省く目的でひな形を渡している、とのことです。

自分が作りたいものを、これまで紹介してきた技術(Next.js〈Webアプリを作るための開発の枠組み〉、shadcn/ui〈見た目の部品を組み合わせられるUI部品集〉、Tailwind CSS〈見た目を効率よく整えるためのスタイル指定の仕組み〉など)を使うようAIに伝えれば、ゼロから作ってもいい感じの見た目にはなるといいます。ただし、たとえばshadcn/uiだけで見た目が完璧に仕上がるわけではなく、配布したひな形も細かい微調整を重ねて作られています。この微調整自体は難しい工程ではなく、「この文字はもう少し大きくして」といった指示を言葉で伝えるだけの作業だといいます。

自分専用のツールやスキルをゼロから作って磨き上げていく作業は、誰であっても一発で完璧にはならず、コツコツと積み上げて改善していくものだと強調されました。配布されたひな形自体も、そうやって少しずつ作られたものだといいます。同じように自分で作りたい場合は、ひな形のフォルダの場所をAIに伝え、「ここにあるもののようなものを作りたい」「こういうカスタマイズをしたい」と伝えれば、AIがそれを参考にして作ってくれる、という進め方が紹介されました。

第6回の講義内容について、半分以上理解できなかった、わからない用語や概念が出てくると思考が停止してしまう、というフィードバックが寄せられました。

まず、わかりにくかったという意見に対して率直に謝罪があった上で、第6回はそれまでの回で扱った内容をより詳細に伝える回であったため情報量が多く、今何の話をしているのか分からなくなってしまった、という点は明確な改善の余地があると認められました。今後の講義では改善していくとされました。

一方で補足として、第5回・第6回・第7回・第8回は、新しい概念に触れたばかりの受講生が講義だけですべてを納得するのは難しい範囲であり、今がちょうど「モダンなWebアプリケーション開発を一気に学ぶ」山場に当たると説明されました。第7回・第8回ではデータの保存を扱いますが、新しい概念を学ぶという意味では第5回・第6回のほうがやや多く、これから先、講義がどんどん難しくなり続けるということはないとされました(第9回・第10回は文章コンテンツ作成がテーマになり、Webアプリ開発の小難しい話は減る予定)。

第5回・第6回の復習をしたい場合は、本気AIドリルのNext.js編(Webアプリを作るための開発の枠組みを扱うドリル)が用意されています。すべての概念を細部まで理解できていなくても、たとえば「Next.jsを使うといい」「shadcn/uiを使えばいい」という程度にふんわり理解しておくだけで、次に自分で何かを作ろうとするときに活かせるとされました。

最後に、「わからない」という感覚は、概念そのものが理解できていないのではなく、実際に手を動かして動かした経験が少なく、慣れていないことから生まれる不安であることが多いと説明されました。すべての仕組みを細部まで理解できていなければ使えないわけではなく、ざっくりとした役割と、どんな処理が行われているかを理解しておけば十分だという考え方が改めて示されました。受講生には、自分のできる範囲でわからなかったことを調べ、ドリルに取り組み続けることがすすめられました。

回答は大きく2つに整理されています。

1つ目は、明確な目的意識を持って、自分が本当に作りたいと思うものを開発し続けることです。誰かに与えられた課題ではなく、自分自身の「作りたい」「解決したい」という意識を軸に置き続けることが、学びを止めないための土台になります。

2つ目は、仲間を見つけることです。できれば一緒に開発する仲間や、一緒にAIを学ぶ仲間、それも利害関係のない、直接オフラインで会える身近な人であれば、なお良いとされています。すぐには見つからないかもしれませんが、1人だけでモチベーションを維持し続けるのは難しいことです。いろいろなコミュニティに顔を出すなど、自分から動いていけば、必ず同じ志を持った仲間と出会えるはずだ、と締めくくられています。