King’s College Londonを休学して、日本に帰国してプログラミング教育の仕事を公務員としてやっています、鵜飼です。
KCLのMichael KöllingのところでもResearch FellowをやっているNeilが、「プログラミングを教えるときの10のポイント」という論文をCC BY 4.0で公開していたので紹介させてください。
- ギークの遺伝子なんてないことを心に留めよう
- ピアインストラクションを使おう
- ライブコーディングをしよう
- 生徒に実行結果の予想をさせよう
- ペアプログラミングをしよう
- (教材を作るときに)操作のステップを分割し、それぞれに名前をつけよう
- 一つの言語をまず学ぼう
- ホンモノのタスクを使おう
- 初心者とエキスパートは違うということを忘れない
- コーディングだけじゃないよ
ちなみに、この論文はK-12だけを対象に書かれたものではなく、あらゆる年代の人にプログラミングを教える人を対象にしたティップスです。K-12向けには以下がよくまとまっています。（とNeilも書いていますね）
1. ギークの遺伝子なんてないことを心に留めよう
よく、「プログラミングには得意不得意がある(some kids get it, and some kids don’t)」とか、さらには「プログラミングには向いていない子がいる」とか聞きますね。 大学のコンピュータサイエンスの授業の成績分布が、とても良く理解できる生徒と何もわかっていない生徒にくっきりわかれる、という話も聞きます。本当でしょうか？Patitsasらの最新の研究によると、実際にはそんなことはなく、くっきりと成績の分布が分れてしまったコンピュータサイエンス入門のクラスは、5.8％に過ぎなかったそうです。
この論文では、「プログラミングには得意不得意がある」という迷信は、プログラミングを学びだしたときに躓きがちな生徒でなく（意識的か無意識的かにかかわらず）、スムーズに学ぶ生徒の方へ教える時間や熱意を費やすことにつながり、ひいてはコンピュータサイエンス分野での性別格差にも繋がっていると論じています。
2. ピアインストラクションを使おう
1対1で物事を教えるというのは理想的ですが、現実的には10人、40人、場合によっては100人の人に同時に教える必要もありますよね。ピアインストラクション (Peer instruction)は、そういった1対多で学ぶ環境において、1対少人数でのメンタリングを実現する方法です。
論文の中に詳しくステップが書かれていますが、良く考えられた複数選択肢から答えを選ぶ形で、40–60％の生徒が正答できる質問を投げ、個人で考えた後でそれぞれの意見を2–4人程度の少人数がグループでディスカッションすることで、学び合いを促します。（例えば、以下の様な質問を想定しているとのこと）
3. ライブコーディングをしよう
スライドを使うのではなく、プログラミングを教える人は生徒の前でプログラムを書くべきです。これには沢山メリットがあり…
a. 「もしこうしたらどうなる？」という生徒の興味や疑問に応じて説明できる
b. 暗黙的に知識の伝承ができる。例えば、プログラムはトップダウンで書くのか、ボトムアップなのか。どんなショートカットキーを使っているのか。
c. 教える側がゆっくり教えることにつながる
d. どうやって間違いを見つけてデバッグをしているのか、見ることができる（そしてそれは多くの場合教科書に書かれていない！）
e. 【一番大事】教える側もミスをするということが可視化されるので、生徒もミスをして良いんだ、と思い、ミスを恐れなくなる
とはいえ、「おまじない（例えばライブラリのインポートなど）」や繰り返しの多いコードを書く必要があるケースは、その全てのライブコーディングで書くと教えるポイントからずれてしまうので、裏にライブラリを作っておいたりする工夫も必要だそう。
4. 生徒に実行結果の予想をさせよう
ライブコーディングをするときには、ただライブコーディングをするのではなく、実行する前に生徒に結果の予想をさせると良いそうです。物理教育の研究結果でも、ただ実験を見るだけ、というのに教育的な効果がほとんどないだけでなく、むしろ実験結果を間違えて覚えているケースすらあり、有害にもなりえるんだとか。
5. ペアプログラミングをしよう
ピアインストラクションにもつながりますし、あまりにも一般的なので省きますが、ペアプロは教え合いにつながります。
6. (教材を作るときに)操作のステップを分割し、それぞれに名前をつけよう
プログラミングの教科書で、よくプログラムを書くステップ（最初にこれをやって、次にこれをやって）が書いてあるやつがありますが、ただステップを並べるのではなく、そのステップ幾つかの塊に名前をつけて（例えば、「変数を作って初期化する」など）おくと、他のプログラムを書くときにその知識を使いまわすことが容易になるそう。
7. 一つの言語をまずは学ぼう
ある程度プログラミングに関する理解が深まるまで、一つの言語を深く学ばないと、生徒が混乱したり自信をなくしたりするので、他の言語を学ばせることはやめましょう。もちろん、多くのケースで例えば一つの手続き型の言語から他の手続き型の言語に移行したとしても、多くのプログラミングに関する知識は細かい文法が違っても使いまわせるものの、それができるようになるには一つの言語に慣れてからじゃないと難しいですし、プログラミングの概念そのものの理解を妨げます。
8. ホンモノのタスクを使おう
抽象的なタスク（例えば、「配列の中から最大値を選んでください」）と、より現実的な問題に近いタスク（例えば、「生徒のテストの点数が入っている配列から、最も良い点を選んでください」）のどちらがプログラミングを学ぶときのタスクとして良いのでしょうか？
Bouvierらの研究によれば、プログラミングの理解という観点ではどちらも違いがないそうですが、この論文では現実世界に近いタスクのほうが興味関心を持ってもらいやすいと述べています。とはいえ、それはそのテーマに興味がある人には面白いですが、そうじゃない生徒のプログラミングへの興味を減らす危険性もある（例えば「シューティングゲーム」をテーマにした場合、女の子は興味をなくす可能性があるなど…）ので、コンテキストの選択はしっかり考える必要があります。
9. 初心者とエキスパートは違うということを忘れない
初心者は、エキスパートと全く違う形でプログラムをし、違うアプローチやツールが必要になるケースがあることを忘れてはいけません。例えば、エキスパートにリストをなめて平均値を出して、とお願いしたら一瞬でできるでしょうが、初心者ではそうはいきません。まず、文法を思い出し、リストをなめる方法を探し、変数を使う方法を思い出してやっと形になるのです。
文学を教えるときに、難しい昔の小説をゆっくり読めば誰にでも理解できるというものではないので、より平易な単語で書かれ、大きく印刷されたものからはじめるように、プログラミングでもただエキスパートがやっていることをゆっくりやればプログラミングが学べる、というわけではないのです。
10. コーディングだけじゃないよ
上のポイントにもつながりますが、ただプログラムをスクラッチから書くということだけが、プログラミングを学ぶ方法ではありません。例えば、1行ごとに分けられたプログラムを順番に並べ替えるという手法を取ることで、細かいシンタックスエラーやライブラリがどう動くのかなどに惑わされずに重要なポイントを学ぶこともできるはずです。
プログラミングを誰かに教えている人なら、どこかに少しでも新しく学べる部分があるのではないでしょうか。是非、平易な英語でかかれているので原文も読んでみてくださいね。
