事例258

また、神奈川県の情報教育部会には、毎年お世話になっています。今まではずっとデータサイエンス分野の発表していたのですが、今年初めてプログラミング分野の話をします。

実は、これまで授業でプログラミングはあまりきちんとやってきませんでした。 2015年～2019年には選択開講の「情報の科学」で、「ロボティスト」(※1)を3人に1台で行ったり(※2)、2020年からは「社会と情報」で1人1台micro:bitを少し取り入れたりした程度です。

今回は、今年初めてテキストプログラミングをきちんと指導してみて、うまくいくだろうと思ったら、予想外にいろいろな課題にぶつかってうまくいかなかった、ということをお話します。また今年は1学期にmicro:bit、2学期にPythonという組み方をしました。その辺り、年間指導計画的なお話もできればと思っています。

※1 アーテックロボ

※2 全国高等学校情報教育研究会　第10回大会発表資料

1学期に「楽しい系」→夏休みにScratchの自由研究→2学期にPythonでステップを踏んでみた

具体的な授業内容です。「情報I」は2単位なので、どの学校も授業時間は大体年間50時間くらいだと思いますが、プログラミングばかりやるわけにはいきませんよね。今日、他の方の発表でもありましたが、やはり使えるのは大体8～10時間かなと思います。

これをPythonに全振りせず、1学期に導入として、ドリトルやmicro:bitを使って、いわゆる楽しい系の実習、夏休みにScratchで自由研究、2学期にPythonを行う、という組み方をしました。

これには理由が3つあります。1つが生徒の中で認知的な「課題の分離」をしたかったことです。「Pythonは辛かったけど、プログラミングは楽しかった」で終われたらいいなと思っていました。

2つ目が、長い夏休みを有効活用したかったことです。そして、3つ目が、本校は文理選択が10月にあるのですが、「情報Ⅰ」の『プログラミング』と『データ分析』という、いわばメインストリームの部分が進路選択の後にあると、「実は情報系はミスマッチだった」とか、逆に「やっぱり情報系に行きたかった」ということが起こりえます。1学期に広く浅く「情報I」の全てが味わえるという流れを作りたかったので、このような組み方をしました。

1学期は、ここにあるように『デジタル化』の流れで「Sakura」の作曲を1時間やってから(※3)、「ドリトル」の日本語プログラムでゲームを作り(1時間)、さらに、micro:bitでブロックを組む(2時間)といった流れで行いました(※4)。

※3「まずはここから　プログラミング事例集」(東京書籍)

　　　https://ten.tokyo-shoseki.co.jp/ten_download/2018/2018018104.htm

※4 武善先生の資料はこちらから

　　　http://high.hinode.ed.jp/share/takeyoshi/class.html

※クリックすると拡大します

こういった「楽しい系」の活動を行ったタイミングで、定期テストをブロックプログラミングと、日本語プログラムを読むといった問題で行いました。まずまずの正答率でした。

※クリックすると拡大します

夏休みは物作りをしようということで、Scratchで作品作りを行いました。ここでは、とにかく楽しく物作りをしてもらおうということで、言語もScratchに限定せず、何を使ってもよいことにしたので、Nintendo Switchで作ってきた人もいました。

また、本格的にプログラミングをする時のために、タイピングに慣れておいた方がよいだろう、と思ったので、「寿司打」(※5)というブラウザゲームを使って、ゲーム的にタイピングを鍛えることもやっておいてもらいました。そして2学期、いざテキストプログラミングに入りました。

※5 https://sushida.net/

1学期と夏休みの経験を踏まえて、2学期はいきなりPythonから入ってみた

2学期は、時間数の問題と、「写経」をやってもあまり意味はないかな、と甘く考えていたので、Google Colaboratory(以下、Colaboratory)で環境構築をしたあとは、課題をColaboratoryで共有し、教科書のある程度のページ部分に関しては、基本的に自学としました。

制御構造は1学期でやっているし、タイピングは夏に鍛えたから、そんな詰まることはないだろう、と思ってしまったのが、今から思えば失敗の原因の一つでした。

※クリックすると拡大します

授業では、一発目からPythonによるガチャシミュレーションを行いました。10連ガチャに関しては、鎌田先生の有名な実践があり(※6)、私も似たような実践を発表したことがあったので(※7)、これらと同じようなことをやってみた感じです。

ここでは、問題解決を意識して、一緒にライブコーディングをする形式で行いました。

※6 文部科学省「情報I」解説動画「【情報Ⅰ】コンピュータとプログラミング(2)「100連ガチャを

プログラムして作ろう！」

※7 https://www.sky-school-ict.net/ite/information/201204.html

※クリックすると拡大します

その次に行ったのが、表計算ソフトによる理論確率のシミュレーションです。

本校は6年制なので、高1、高2のことを4年、5年と呼んでいます。クラスごとの平均値を見ると、当たりの確率がばらばらになっている。では、厳密にはどうなるかということを表計算で示してみることにました。理論確率を出した後には、大規模な数でシミュレーションすると一致するのではないか、という流れで、カウンタとして変数を活用するプログラムを書かせました。

※クリックすると拡大します

ここまで終わった後、コンテンツ作りとして、前半0.5時間でおみくじと会話bot、後半0.5時間でじゃんけん作りを行いました。これに関しては、プログラムを一から書くということにこだわって進めました。

実際にじゃんけんを作るためには、やはり右側にあるような勝利判定表を満たす条件分岐が必要になります。一連の長いプログラムを作る上では、この辺りも考えさせました。

ただし、いわゆる「3を足して、3で割った余りを求める」という効率的なコードを書くところまでは要求していません。ここでは左側にあるように、「じゃんけんゲームを作るというのは、コンピュータにじゃんけんを教えるということ」にもこだわって、プログラミング能力とは、身近な概念を上手に言語化・理論化する能力であることを伝えようとしました。

※クリックすると拡大します

2学期の期末試験では、しっかりテキスト型のプログラムを出題しました。『情報セキュリティ』の単元も扱ったので、大学入試センターの「試作問題(検討用イメージ)」の暗号の問題もそのまま出しました。

左下が試作問題に対する本校の正答率、右下がスライドの左にあるような、いわゆる基礎的な一問一答問題に対する正答率です。

※クリックすると拡大します

Pythonの「目に見えない制御構造」がわかっていない→情報デザインをきちんと学ぶことが必要

さて、ここからが大反省会です。

まず、Pythonの制御構造が全然取れませんでした。1学期にブロックプログラミングでやったことを、ブロックではなく、テキストで自作するだけなのですが、なぜか取れない。目に見えない構造というものが取れないことに、結構苦労しました。

これは多分、「情報デザイン」の部分で可視化や構造化といったことを甘く見ていたためではないか、というのが反省点です。抽象化に関する実習としてピクトグラムは作っていましたが、文章をインデントで区切っていくような構造化の実習は行っていませんでした、多分、この辺が影響しているのではないか、と思います。情報デザインをきちんとやると、プログラミングにも効くかな、というのが今年の反省です。来年は「構造化」に関する実習をしっかりやろうと思っています。

※クリックすると拡大します

プログラミングには国語の力が必要→数学が苦手な生徒に、「プログラミング≠数学」のアプローチを

もう一つが共通テストの長文問題です。時間があればできる、という問題も多いですが、本校の解答状況を見ると、プログラミングに入る前の、文章を読み取るところで、すでにかなり点を落としています。

これは多分、プログラミングの能力というよりは、国語的な文章処理能力に課題がありそうだなと感じています。

もちろん、共通テストのために授業をやっているわけではありませんが、やはりこの対策はしたいと思っています。

プログラミングは国語の能力の問題であることは、授業でもずっと強調していますが、生徒の認知はどうしても、プログラミングと関係する教科というと、数学しか挙がってきません。授業ではさんざん数学じゃない、と言っていたのですがダメでした。また、本校は数学を苦手とする生徒が多いので、「数学だから、もう諦めた」という空気になってしまう時が度々ありました。そのため、来年は理論確率と経験確率の比較はやめて、いかに数学色をなくしてシミュレーションをするか、という方向にアプローチを変えようと思っています。

※クリックすると拡大します

「写経」はやらないとダメ。タイピングは特殊記号の入力をしっかり押さえる必要あり

また、「写経」はやらなければダメでした。生徒は、「情報」が入試に入ることになっても、英語や数学のような予習はやってくれない、ということがよくわかりました。家でやっておいてね、と言っておいたにもかかわらず8割ぐらいが正直に「やりませんでした」と答えてくれたので、事前に課題を出しておいたとしても、写経の時間を1時間は取ろうと思います。そうすると、やはりプログラミングに10時間は必要かなと思いました。

もう一つ。タイピングの練習をした効果もあってか、タイピング速度の点で詰まる生徒は、ほぼいませんでしたが、やはり特殊記号が打てません。Shiftキーとの組み合わせなども、そうです。授業でどれだけ言っても、最後の最後まで全角で(　)を打ってしまって、それでエラーを起こして嫌になってしまう生徒が多かったので、そこは割り切って、特殊文字タイピングの時間を取ってやらなければいけないかなというのも反省です。

※クリックすると拡大します

「プログラミングの何が面白いか」で感想に差が。micro:bitとPythonで楽しさに大差はない。

最後に、「プログラミングを学んでどのような力が付いたと思うか」という問いに対する生徒の解答です。「面白かった」と答えた層と、「面白くなかった」と答えた層とで、けっこう明確な差が出ました。

「面白くなかった層」は、ただの機械いじりとしてしかプログラミングを捉えられていません。これは面白くなるところまで行けなかったから、とも考えられますが、やはりプログラミングをどのように捉えるかというところが、興味・関心と関係することが如実に出たかなと思っています。

※クリックすると拡大します

先ほどの井手先生の発表(※8)でも、micro:bitとPythonの授業の比較がありました。私自身も、「1学期に楽しくmicro:bit、2学期にPythonをしっかり」と授業を組み、この比較をしてみたのですが、生徒に「楽しかった授業は何ですか」と聞いても、実はmicro:bitとPythonで大差はありませんでした。この辺りも、次年度どうしようかなと思っています。

というところで、プログラミングをやってみて反応はどうだったのか、こうしたらうまくいくのではないか、といったご意見を広くうかがえたらと思っています。ありがとうございました。

※8 「情報Ⅰでのmicro:bitを使用したプログラミング実践報告」

[質疑応答]

Q1:

私も実は、授業をmicro:bitで5回、Pythonで5回やりましたが、micro:bitでやった変数や条件分岐や反復構造を、Pythonでもいけるだろうと思ってやってみたら、やっぱりそこで躓くということがありました。前にやったものであっても、概念が変わるとなかなか思うようにいかないというのは私も感じたところでした。その中で先生が感じられた、生徒の一番大きな躓きはどこでしたか。やはり配列でしょうか。

A1武善先生:

私がやった感じでは、あまり配列では躓かなかったです。ある程書き換えだけで済ませたこともあって、配列の概念は、わりあいすっと入っていった感じがします。

やはり躓いたのは、二重以上の入れ子です。複数の生徒が、最後まで理解できていなかった気がしました。micro:bitのブロックでは躓かなかった生徒がテキストでは躓くので、間にもう一つステップが必要なのかな、ということ、そしてmicro:bitのブロックができても、共通テストの問題は解けない可能性が高いな、ということを感じました。

Q2-1:

私は課題プログラムをGoogle Colaboratoryで作って提出させていますが、その際、基本的に正解かどうかをチェックするために、全く同じプログラムになるようなものしか出題できていません。

単に、友達のディスプレイを見ながらその通り打ったり、明らかに授業で教えていないし、多分本人もわかっていない構文をPythonで調べてそれを写したのだろう、という人もいたりします。その辺りは、どんな感じで指導されているのか、教えていただけますでしょうか。

A2武善先生:

ありがとうございます。正直言いまして、何も対策しませんでした。友達のコードを写すのは、まだマシな方、というのが今年やった感覚です。逆に、写すというのは実はすごく難しいのですね。

授業では、私がライブコーディングして見せて、「さあ、やってみよう」ということになると、インデントを無視してベタベタ打ってしまう生徒が多かったです。

ですから、友達のコードを写して動いたにしても、インデントを下げられるという時点で、制御構造は理解しているという証拠になるかなと思います。オンデマンドで「写経プログラミング」の発表がありました。コードを写せる人というのは、結構優秀なのかなと思います。

Q2-2:

ありがとうございます。私も以前に研究授業でプログラミングの授業を見てもらった時に、「プログラムはコピーしても、そのプログラムの説明文を書きなさい」というステップを入れると、本当に理解しているかがわかる、ということを指摘されたことがありました。

Q3:

先ほどインデントのブロックの構造がわからない、という話がありましたが、そうするとキーボードの使い方も問題になると思います。

例えば、うちの学校の生徒を見ていると、文字は打てるけれどいろいろな記号が打てない、制御キーが打てない、といったものですね。Pythonもそうですが、インテンドをTabキーではなくて、スペースキーを4回打って済ませる人がけっこういるのではないかと思います。要するに、機械としてのコンピュータを扱う能力がうまく育っていないのではないかと感じるのですが、そういう感触はありますか。

A3武善先生:

Colaboratoryは割と優秀で、Tabキーを打ったら自動でスペースを4つ入れてくれますよね。設定でスペースを2個にするか4個にするかも決められます。今回、私は出来るだけ作業を簡略化しようと思って、授業の中ではTabとスペースの話を細かくしませんでした。ですので、スペースキーでインデントを済ませた生徒の方が多かったように思います。しかし、すなわち単にスペースを空けるというだけの作業であっても、本校生徒は躓いていました。このことから、PCスキルの問題ではないのではないかな、と見ています。

ただ、今お話ししていて、これはやはりデザインが鍵なのかな、と思いました。スペースキーで入力してしまうから、文章の改行とか、文頭は1マス空けるみたいな、国語のルールのようなものに勘違いされたのかな、という気がしています。Tabキーを使うことにしたら、区切りをつける魔法の操作であることをむしろしっかり意識することができるかもしれないと思いました。

Q4:

私のところでは、コードを書くときに記号になっても平気で全角で打つ生徒がいます。1学期に半角の記号のことを教えているのに、すっかり忘れているのですね。生徒の中で、半角と全角の違いが定着してない人がいるのが気になるのですが、その点はいかがでしょうか。

A4武善先生:

私のところも同じです。ですので、後半の授業ではやり方を生徒の実態に合わせました。例えば、ガチャのプログラムで「当たり」などと表示するときに、日本語で「当たり」と表示しようとするとどうしても全角を混ぜなければならなくなるので、日本語で表示するのをやめて、「atari」のように全てローマ字に変えました。そして、「もう左上の半角/全角キーはないものとして扱いなさい」という言い方をしたら、これ以後かなりマシになりました。

このときになって、初めて生徒が「じゃあ、( )はどうやって打つんですか」と疑問に思ってくれたようです。それまで何回もShift+8とかShift+9とか説明してきたつもりでしたが、全然認識してくれていなかったことも発覚しました。その後は比較的スムーズに進行し、プログラミングの授業としては成立したものの、この逃げ方だとコンピュータに対する理解は深められないかも、というのは反省です。

Q5-1

今、小学校6年生の理科でmicro:bitを使っているところが多いですが、高校でまた使うとき、小中学校の経験は生きているものでしょうか。先ほどの半角/全角の問題なんて、小中学校でしっかり押さえればよいのに、と思ったのですが。その辺りはどうなのでしょうか。

A5-1武善先生

本校は、小学校課程も中学校課程も持っていますが、公立の中学校から進学して来る生徒もいます。micro:bitをやったという生徒は、実はまだ出てないですが、Scratchをやってきた子というのはたくさんいて、彼らはmicro:bitの授業に入るときは、非常にすんなりいきます。経験のない人とは明らかに違います。

ただ、やはり「変数」等を理解している生徒は少ないです。Scratch経験者も、情報科としては基本的な、例えばmicro:bitを用いたカウントアップ・カウントダウンのようなものでも、難しく感じるようです。逆に、いわゆるセンサ系を使う内容は、中学校の技術科と親和性が高いからか、経験者はすんなりと授業に入ってきます。ですから、「変数」等の理解では壁を感じることもありますが、それ以外のforやifのような制御構造については、経験の差が出ると感じています。

Q5-2

そうすると、高校の先生には、「この生徒はここまで学んできている」という情報が流れたほうがいいですよね。中学校の技術科は、学習指導要領がゆるゆるなので、具体的にどこまでやってきたのかが見えにくいですが、その辺りを整理して提供する仕組みができれば、高校の先生にとっては有益ですよね。

A5-2武善先生:

素晴らしいと思います。ぜひそういった仕組みができればよいと思います。

実はプログラミングの授業を始める際に、生徒にアンケートを取るのですが、生徒たちはやはり時数の問題もあるのか、「プログラムはやったけど、言語の種類はわからない」とよく言います。「Scratchはこういうネコのキャラクターのものです。micro:bitはこのような小さいコンピュータです」等と写真と一緒に示すと、ようやく、「ああ、これならやった」と言ってくれる、という程度です。

このように、生徒から「何をやった」ということをはっきり調査することは難しく、先生方や学校から情報が発信されると、非常にありがたく思います。

Q-6:

Google Colaboratoryを使って、ベタ打ちのテキストを配布して、それをTabキーだけ使ってプログラムの形にしていくという活動は、生徒にとっては、単なる文字列がプログラムに変わっていく魔法のように感じられて、非常にいいなと思いました。

このとき、プログラムは言語なので、まずは読み解く力を付けないといけないのに、どうも今、皆が焦ってしまって、プログラムを書かせることを先にしようとし過ぎて、本質が伝わらなくなっている、というのがプログラミングの現状かなと感じています。その辺りいかがでしょうか。

A6武善先生;

昔、どなたかの発表で、プログラムのホップ・ステップ・ジャンプというお話がありました。まずは「つづりミスを直す」問題、次に「ベタ打ちテキストにインデントを付けて動くようにする」問題、最後に「実際のプログラムを書く」問題、といった感じです。今回の実践は、それを真似させていただきました。これは良かったなと思いました。

実は、ベタ打ちテキストを書き換えるという活動の方が、プログラムを理解する本質に近い気もします。というのも、Colaboratoryは優秀で、for文やif文を書くと、勝手にインデントを入れてくれてしまうのです。

このため、上から順にベタ書きしようとすると、生徒はインテンドを下げるということを意識せず書けてしまうことになります。しかし、ベタ打ちで書かれたものを直させる活動では、ここは下げなければいけないな、ということを必然的に考える必要があります。このことから、ベタ打ちを直すことのほうが、プログラミング教育の本質に近いのかもとも思いました。

もう一つ、授業で工夫をしたのが、最初に書かせるプログラミングをfor文にしました。教科書を見ると、当然のように変数から始まりますが、それだとあまり面白くないかなと思ったからです。コンピュータのいいところは、簡単なことを大量に一瞬でやってくれるということなので、最初に「名前を100回表示しよう」といったことをやってみて、魔法感を味わってもらった後に、ifや変数をやってみる、というつくりに、工夫してみました。

神奈川県情報部会実践事例報告会2022オンライン　ポスターセッションより