ここ2, 3週間ほど、プログラミング入門研修の受講生たちをみていて、「プログラミング全然分からん」（「完全に理解した」の次の段階というワケではなく）となってしまう理由と対策をあれこれ考えてみたメモです。次の研修での進め方や教え方に活用できると良いと思い、ひとまず箇条書きでメモしています。

分からなくなる瞬間

プログラミング初学者が突き当たる一番の問題は「分からない」状態になることです。「分からない」状態になるとその後の内容も「きっと前のが分からなかったんだからこの先はもっと分からない、、、」となってしまい、プログラミングに対する苦手意識が生まれます。そんな状態の受講生の質疑応答をしながら、どのような時に「分からない」状態に陥ってしまうかを考えてみました。

• 「だから何？」と感じたとき
  • （受講生）「これって何につかうんですか？」
  • （受講生）「これ覚えて何になるんですか？」
  • メリットや存在意義、使い所や具体的な使われ方が分からないと、頭に定着しない
  • 理解できないと「暗記しなければならない」モードになる
  • 暗記してもテキストの記載内容を復唱できるようになるだけで、実践で使えない。
  • というかそもそも暗記できる分量ではない。
• キャパを超えたとき
  • （受講生）「何も分からないです、、、」
  • 学んだことが消化できないまま次の知識が入ってくると、消化できていない方の内容が気になって次が入ってこない。
  • 一度落ち着いて内容を咀嚼できるだけのキャパを残しながら進めてあげるのが大事。
• イメージができないとき
  • プログラミングは目に見えないものが多いので、イメージが大切。
  • イメージがないと、用語や説明の暗記になってしまう
• はぐらかされたとき
  • はぐらかされると余計気になる。自分の学んでることが正しくないんじゃないかと思い、頭に入らなくなる。
  • （講師）「ほんとは厳密じゃないんですけどね、、、w」
  • （講師）「実際は違うんですけどね、、、w」
  • （講師）「〜のようなものですね」
  • （講師）「〜な場合もありますね」
• イメージと実際の動作・テキストの記載内容に矛盾がある場合
  • 自分の理解が間違っていたんじゃないか？となってしまう。

理解しやすくするために

「分からない」状態にならないよう、教える側ができる工夫を以下に書き出します。

• 「問題」->「解決策」の順番に話す
  • なぜその技術や考え方が存在するのかを理解できる。人は「なぜ」が理解できると脳が受け入れやすい。
  • マーケティング手法にも「なぜ」に訴えるものがある。
• 一息で説明する量を調節する
  • 説明を聞きながら頭を動かして消化することはできない。ある程度話したら間を置いたり受講生のペースで手を動かす時間を作ったりする。
  • プレゼンのテクニックの一つに、「15秒刻みで話す」というのがある。
• 絵に描く・比較をする
  • 特にプログラミングに関する内容は目に見えない概念が多いので、積極的に絵を描いて視覚的に伝える。
  • 四角とか丸でもいい。具体的な形があるものであればそれを書く。同じ形が連続して出てくるより、一つ一つ違った方が記憶に残りやすい。
  • イメージを基にして実際のプログラムを読むと、説明もしやすく理解もしやすい。
• なぜ今は「おまじない」にしておくのかを説明する
  • 受講生がキャパオーバーしないよう、一つ一つ丁寧に説明せずに「おまじない」にしておくのは悪くない。
  • ただし、「いつ」おまじないじゃなくなるのか、おまじないじゃなくなるためのキーワードは何か、なぜ「おまじない」にしておくのか、などを簡単に説明することは重要。
  • 説明が難しいからといって笑ってごまかさない。ごまかすと余計に気になる。
  • 「ちゃんと理解するには前提知識が必要」「今理解してなくてもとりあえずは問題ない」を伝える。
• 可能な限り実際に近い説明をする
  • 人は既に理解していることに紐づけられると新しいことを理解しやすい。
  • たとえ話はその人が理解しているものの中で、一番実際に近い厳密な内容を選ぶのが大事。
  • 「既に理解していること」は人によって違うので、常に「どこまで理解しているか」を探りながら最適な説明方法を探す。
  • 質問されたらどこまで理解しているか質問し返すのが大事。
  • 実際に触れる具体的なサービスを見ながら説明するのも効果的。

その他気をつけること

• 質問されたとき、すぐに否定・訂正しない
  • ひとまず受講生に最後まで話してもらう。
  • 話が止まってもまだ何か考えていたら待つ
  • 明らかに間違ったコードを書き始めても、最後まで書き切らせてエラーを見ながら訂正・説明を始める。
  • とにかく受講生がどこまで理解していて、どこが理解できていないかを明確にしてから対応を始める。
  • もしかしたら話している・コード書いているうちに自分で気づくかもしれない。
    • 人の指摘より自分で気づいた方が定着しやすい。
•  話し方を平坦にしない
  • 平坦な話は引っかかりがないので頭に残らない
  • どこが大事か分からないとどこから理解すれば良いのか分からない。
• 重要なものだけ発言する
  • 受講生に与える情報量を増やしすぎない
  • 受講生が見ているテキストに載っていない「ちなみに」話をしすぎない
• 手を頻繁に動かせるように進める
  • プログラミング学習は自分で手を動かして実感するのが大事
• 議論・会話をする
  • 自分の考えや理解を整理する
  • 単語の使い方を理解するだけでも効果がある。
• 暗記する必要がないことを伝える。
  • 「イメージ」と「索引」
  • 「覚えておいてください」という表現を使わない
• 質問されたら、まず理解している内容を可能な限り話してもらう
  • 話しているうちに理解が進むことはよくある
  • 上手な質問のしかたをついでに身につけてもらう
• 楽しさを伝える
  • これができるようになったらどれだけ面白いものが作れるかを伝える
  • 何事も成果を出すためにはモチベーションが大事
• 「できる人」の考え方を見える化する
  • ライブコーディング
• 人によって理解までのプロセスが違う。
  • とりあえず聞いた通りにやってみる人
    • 研修中の姿勢だけみると、このタイプが一番「できる」ように見えてしまう。
  • ちゃんと理解しないと手が動かせない人
    • 研修中は遅れがちだが、あとで一気に伸びる可能性アリ
  • いろいろ考えた結果変に手が動いちゃう人
    • 考えを整理する手助けが必要。本当に大事なことから順番に。
    • ライブコーディングなどでできる人の思考回路を見せる
• 疑問に思ったことはやってみる
  • 人によっては「こう書いたらどうなりますか？」「これで大丈夫ですか？」を自分で試す前に質問してくる。
  • それを講師が「良い」「悪い」で返答してしまうと、受講生はそれが「正解」だと捉え、自分で試行錯誤しなくなる。
• 話をあっちこっち飛ばさない
  • 講義をしながら何か言い忘れたことに気づくとやってしまいがち
  • 聞いてる側としては、話がとぶとそれまでの内容がすべて飛ぶ

まとめ

• 受講生の知識や発想を可能な限り増やすのは大事。でもキャパオーバーでプログラミング自体を諦めてしまっては本末転倒
• 人によって最適な教え方は違うので、教えることよりも話を聞くことの方が大事。
• これを学んだ結果どんな良いことがあるのかを具体的にイメージできるようにする。

以上です。詳しくは随時別の記事に書きたいと思います。