2018年に発表された論文「Ten quick tips for teaching programming（意訳 : プログラミングを教えるための簡単な 10 Tips）」を読んだ．直近は技術講師（インストラクター）として4年間ほどクラウドなどを教えていて，コースによってはプログラミングを教える機会はあるし，2018年までは2年間ほど TechAcademy で Ruby / Rails 講師をしていたし，キャリアとして「今まで」も「今後」もプログラミングを教える続けると思う．そこで，今までの教授戦略を振り返るためにも本論文に興味を持った！
(PDF) Ten quick tips for teaching programming
本論文に載っている 10 Tips は以下で，日本語訳は意訳してみた！
- Tip 1: Remember that there is no geek gene（ギークの遺伝子は存在しない）
- Tip 2: Use peer instruction（ピアインストラクションを活用しよう）
- Tip 3: Use live coding（ライブコーディングを活用しよう）
- Tip 4: Have students make predictions（生徒に予測をしてもらおう）
- Tip 5: Use pair programming（ペアプログラミングを活用しよう）
- Tip 6: Use worked examples with labelled subgoals（ラベル付けしたサブゴールを活用しよう）
- Tip 7: Stick to one language（プログラミング言語は1つに固定しよう）
- Tip 8: Use authentic tasks（わかりやすいお題を活用しよう）
- Tip 9: Remember that novices are not experts（入門者は専門家ではない）
- Tip 10: Don’t just code（プログラミングだけじゃない）
Tip 1: Remember that there is no geek gene（ギークの遺伝子は存在しない）
プログラミングスキルは生まれつきのものではなく，練習によって獲得できるし，向上できると書いてあった．その通りだと思う！インストラクターとして，プログラミングに向いている生徒や向いていない生徒という偏見は持たず，それぞれのペースで一歩一歩学んでもらうことが重要だと思う．プログラミングを学ぶ時期に遅いなんてことはないし，誰しもプログラムは実装できるようになる💪
Tip 2: Use peer instruction（ピアインストラクションを活用しよう）
マンツーマンなら1人の生徒に集中して教えられるので学習効率は高まるけど，教育の現場では複数人（数名 / 数十人 / 数百人）に同時に教えることが多く，どのように学習効果を高めるかという教授戦略が重要になる．本論文では Eric Mazur によって普及された「ピアインストラクション」を使うと書いてあった．ピアインストラクションの詳細は Wikipedia などを見てもらうとして，簡単に紹介すると，講義中に生徒同士がお互いに相談しながら進めるアクティブラーニングの手法の一つと言える．インストラクターの講義を聞く従来のスタイルよりも生徒中心で学んでもらうアプローチになる．
本論文にもWikipedia にも載っているけど，ピアインストラクションは一般的に複数のステップで構成される．何かしらの問題を出して，まずは個別に考えて回答して，次にグループディスカッション形式で考えて回答する．本論文には問題を出すときのポイントが載っていて，全員が正解するような難易度の問題ではあまり意味がなく，正解率が 40% ~ 60% ぐらいになる問題を作るべきと書いてあった．間違えることは悪いことではなく，同じ問題を個人とグループで考えることで，より理解を深められる．本論文には「ループと整数比較の問題例」が載っていた．プログラミング入門者を集めたら確かに回答はバラけそう💡
// 実行すると Yes は何回表示されますか？ // a) 10 // b) 5 // c) 4 // d) 3 for (int i = 1; i < 10; i++) { if (i < 3 || i >= 8) { System.out.println("Yes"); } }
Tip 3: Use live coding（ライブコーディングを活用しよう）
プログラミングを教えるときに「スライド」を使うのではなく，インストラクターが「ライブコーディング」をするべきと書いてあった．具体的に以下のメリットが挙げられていた❗️
- ライブコーディングなら「もし○○のときはどうなる？」という生徒の疑問に答えながら柔軟に進行できる
- スライドだと「高速道路」になってしまう
- ライブコーディングをすることによって「もともと教えようとしていたこと以外」も観察してもらえる
- コードを実装する順番／エディタ操作／ショートカット操作など
- スライドを使うよりも教えるペースが遅くなることによって理解できていない生徒を置き去りにしてしまうリスクを減らせる
- インストラクターが「どのように間違えてどのように解決するのか」という流れを見せられる
- プログラミング入門者は多くの時間をデバッグに費やすのに講義だとそこが学べない😱
- インストラクターがその場で間違えることで「全然間違って良いんだ！」ということを教えられる
僕自身の講義でもプログラミングを教えるときは，できる限りスライドは使わず「自分で実装したプログラム」を使うことを重要視している．また「ライブコーディング」をすることもあるけど頻度はそこまで高くなく，今後はもっと活用していこうと思った！そして「どのように間違えてどのように解決するのか」というメリットを読んだときは「ドットインストール」を思い出した．ドットインストールのビデオでは予定していなかったであろう typo や構文エラーなどが出て，エラーメッセージなどを見ながら直すという場面がたまにあって素晴らしい！
さらに本論文にはライブコーディングのデメリットも明確に書いてあった．まず，インストラクターがプログラミングに慣れてなく，タイピングが遅かったり，メモを見ながらライブコーディングをするとグダグダになって逆効果になってしまう．またライブコーディングだとは言え，ゼロから実装すると伝えるべきポイントとズレる可能性もあるので，ボイラープレートのような雛形を作っておいて，そこから実装をはじめる．
Tip 4: Have students make predictions（生徒に予測をしてもらおう）
ライブコーディングなどを見せるときに，単に見せるのではなく生徒に実行結果を予測してもらうことで，より効果を高められると書いてあった．個人的な経験からも考えながらデモを見るのは本当に効果的で重要なプラクティスだと思う．Cyber-Dojo の predict? 機能も似ている．
Tip 5: Use pair programming（ペアプログラミングを活用しよう）
ペアプログラミングはプロダクト開発だけじゃなく教育でも優れていると書いてあった．「ピアインストラクション」にも関連するけど，生徒同士がお互いに相談をしながらプログラミングを進められる．またペアプログラミングを活用するときの注意点として，ペアプログラミングを支配してしまうような生徒がいる可能性もあるので，ペアは固定にするのではなく交代しながら全員ペアになれるように工夫するべきと書いてあった．関連して，ペアプログラミングの効果に関しては過去記事にまとめてある！
Tip 6: Use worked examples with labelled subgoals（ラベル付けしたサブゴールを活用しよう）
プログラミングは構文を覚えれば実装できるわけではなく「どういった流れで実装するか」も重要で，入門者にとって流れを考えるのが難しかったりする．そこで，コンテンツの中に「ラベル付けしたサブゴール（ガイドのようなもの）」を追加することにより，プログラムを実装する流れを理解しやすく，また今後プログラムを実装するときにも役立てられるようになる．本論文には以下の例が載っていた．
⭕ 従来
- [1.] "AccelerometerSensor1" をクリックします。
- [2.] "AccelerometerSensor1.Acceleration- Changed" ブロックをドラッグします。
- [3.] "cowbellSound" をクリックします。
- [4.] "cowbellSound" をドラッグします。"AccelerometerSensor1.AccelerationChanged" の後に再生して接続します。
❌ ラベル付けしたサブゴールあり
- ブロックのイベントを処理する
- [1.] "AccelerometerSensor1" をクリックします。
- [2.] "AccelerometerSensor1.Acceleration- Changed" ブロックをドラッグします。
- ブロックの出力を設定する
- [3.] "cowbellSound" をクリックします。
- [4.] "cowbellSound" をドラッグします。"AccelerometerSensor1.AccelerationChanged" の後に再生して接続します。
Tip 7: Stick to one language（プログラミング言語は1つに固定しよう）
特に入門者はプログラミング学んでもすぐには応用できないため，学んでいるプログラミング言語を変えず，固定することが重要と書いてあった．そこそこプログラミング経験があると，構文などに違いがあっても考えながら進められるけど，入門者には難しすぎる．さらに混乱してしまうし，うまくプログラムを実装できず自信を失ってしまうこともある．
この Tips は僕自身も TechAcademy で Ruby / Rails 講師をしていたときに経験があって納得感があった．せっかく Ruby を勉強しているのにフロントエンドを実装するために JavaScript を学ぶ必要があるし，ネット記事などを読んで最近は Go なども流行っていることに気付き「全部学ばないといけないのですか？」と質問をもらうことも多かった．僕は当時から「エンジニアならテクノロジーの変化に柔軟に対応しましょう！」なんてことは言わないようにしていて，意図的に「まずは今回学んでいる Ruby に集中しましょう！」と伝えていた．本論文に載っていた「自信を失ってしまう」という側面もあるけど，個人的な経験だと「今まで Ruby を学んだ時間は無駄だったのか？」と頭を悩ませてしまう方が多かったように思う．
Tip 8: Use authentic tasks（わかりやすいお題を活用しよう）
プログラミングを実装するときのお題として，より身近に感じられる「わかりやすい（イメージしやすい）」お題を活用すると良いと書いてあった．以下に本論文に載っていた例を挙げた．「単純に数列から最大値を見つけるお題」よりは，「学校の先生が生徒のテスト結果を分析して最高点を見つけるお題」の方が，わかりやすく魅力的に感じる．プログラミングに対するイメージを「難しくて退屈なもの」から「簡単でエキサイティングなもの」に変化させることも重要と書いてあった．
- 数列から最大値を見つける（コンテキストがないお題）
- 生徒の最高点を見つける（コンテキストがあるお題）
個人的にはプログラミングを実装するときのお題として CodeKata を参照する機会がそこそこある．全てとは言えないけど，例えば「Kata01: Supermarket Pricing」などはコンテキストがあってイメージしやすいお題になっていると思う．
Tip 9: Remember that novices are not experts（入門者は専門家ではない）
「入門者は専門家ではない」というのは当たり前のことで「トートロジー（小泉進次郎構文？）」のようにも聞こえる．内容としては，入門者は専門家と同じように考えられないし，学んだ構文やアルゴリズムを思い出すだけでも難しく，一般的に「簡単」と言われるお題だとしても壁を感じてしまう．よって，生徒のレベルに適したお題や説明を意識する必要があると書いてあった．
Tip 10: Don’t just code（プログラミングだけじゃない）
最後の Tips には，プログラミングを教えるときに「必ずしもプログラミングをしなくて良い」と書いてあった．入門者にとっては，構文やアルゴリズムを組み合わせて考えるなど，経験者にとって簡単なことでも圧倒されてしまう．よって，具体例としては「Parson's Problems」を使って，プログラムを実装せずにドラッグアンドドロップで試行錯誤できるプラクティスなどを活用することも効果的であると書いてあった．Parson's Problems に関しては前回の記事にまとめてある！
まとめ
2018年に発表された論文「Ten quick tips for teaching programming（意訳 : プログラミングを教えるための簡単な 10 Tips）」を読んだ．今までプログラミングを教えるときに意識していたことが正しいと確認できて良かった．また Tips 3（ライブコーディング）や Tips 10（Parson's Problems）は今後積極的に試したいと思った．
