事例66
プログラミングで基数変換の仕組みを理解しよう
～コンピュータアンプラグドの「点を数える」をドリトルで表現しよう
神奈川県立茅ヶ崎西浜高校 鎌田高徳先生
「仕組みをプログラミングさせること」を目指す授業
昨年度から本校は二つの研究指定をいただいています。まず、神奈川県からはプログラミング教育研究推進校ということで、情報科だけでなく、他教科にもプログラミングを普及させようということを校内で取り組んでいます。それと同時に、昨年度から国立教育政策研究所の教育課程研究で、共通教科情報の研究指定を頂いています。今回はこの二つに関する取り組みの中からお話しします。
まず、私が今回の発表を通して全国大会で発信したいのは、これからの情報教育はプログラミングだけを学ぶのでなく、プログラミングを通して情報の科学的な理解、特に仕組みの理解をゴールとすべきではないのかということです。もちろん、これが答えだとは思いませんが、今後情報I・IIとなったとき、「科学的な理解」の内容がどんどん入ってきます。そうなると、やはりこの「科学的な仕組みをプログラミングさせること」がゴールかもしれないと考えて、去年から研究をしています。
今回の発表の流れです。「情報の科学的な理解」を深める。その過程として「アンプラグド」を使う。そして今回のポイントは、「プログラミング『を』ドリトルで教える」ことと、「プログラミング『で』基数変換を学ぶ」ことを切り分けて考え、それをどう「評価」するのか。実際、プログラミングをどのように評価するかについては、あまり発表事例がありません。すべての生徒のコード一つチェックする必要はあるのかなど、神奈川県で議論してきた内容を発表します。そしてプログラミングで「できなかったこと」は何かについても、かいつまんで紹介したいと思います。
包丁＝ドリトルの使い方を知らなければ、調理＝プログラミングはできない
一つ目の「プログラミングで科学的な理解を深める」について説明します。これは、本校が受けている国立教育政策研究所(国研)の共通教科情報の研究主題で、問題解決的な学習の指導です。つまり、先生が指示した通りのことを生徒にさせるのではなく、先生は題材や問題解決のテーマを与えて、生徒に自分たちで問題解決したいと思わせるという授業をしていくことです。
ですから、教科書に書いてある題材をそのままやらせるようではダメで、生徒たちに「やりたい!」と思わせる「身近で、切実で、課題解決可能」な題材の工夫が必要です。特に注目しているのが意欲の向上です。
そこで今回目を付けたのが基数変換、つまり2進数から10進数の変換です。教科書どおりに教えたら、たぶんとてもつまらない授業になります。そこで、基数変換のプログラムを作る、ということをしたら、生徒たちの反応が見事に変わりました。今回はそれを発表したいと思います。
私はプログラミング教育を調理に例えて考えています。「プログラミング『を』教える」ことと「プログラミング『で』教えるのか」ことは、二つとも大切で、どちらも抜けてはならないと思います。
「プログラミング『を』教える」というのは、調理に例えると「こういうふうに包丁を使えば、うまく切れるんだよ」という、包丁の使い方です。今回でいうと、ドリトルの使い方です。
一方で、使い方を覚えただけでは社会で役に立たないので、包丁＝プログラミングを使って何かを作ってみる、ということで、今回は基数変換を教えることにチャレンジしました。この二つのバランスが取れていないと、本当の授業の意味はないと思っています。
昨年度から、本校の「社会と情報」にてプログラミングを使った実践を行っています。今大会の分科会Bで大石先生が発表された公開鍵暗号方式解読や、分科会Fの小松先生が発表されたドリトルのチャットの実践を参考にしたクライアントサーバシステムを理解させる授業で、ドリトルやVBAを使って授業を行いました。結果として、生徒たちは教科書の紙面で学ぶよりも、実際にプログラミングを使うことで仕組みがわかった、と答えてくれています。
なぜ基数変換を題材としたのは、情報科の先生が必ず授業で扱うけれど、普通にやったらつまらなくなってしまうと、自分で思っているからです。手計算だけでやらせても理解が深まったか疑問でしたし、１年経って、生徒たちがどれぐらい基数変換を覚えているかもおぼつかない。だから、印象に残る題材の工夫をしようと思って、この研究を行いました。
まずアンプラグドで仕組みを理解する
プログラミングを導入するときは、ねらいが非常に大切です。私自身もそうですが、教師は授業において「ねらい」や「評価」より「方法」に目が行きがちです。なぜドリトルを使うのか。なぜプログラミングを使うのか。これをやらないと、手段が目的化してしまいます。
ですから、我々がプログラミングを使った授業を設定する上で重要なポイントが「なぜプログラミングを使ったのか」というねらいを明確にすることです。
今回は、「基数変換の手計算の手順を理解して、プログラミングの手順に置き換えること」を目的としてドリトルを使いました。
それをどのような流れで行ったのか、説明をしていきます。
はじめはアンプラグドから入りました。兼宗先生が書かれた本にあるような、アンプラグドコンピュータサイエンスを使って、２進法カードどパターンを考えさせるものです。この部分の説明は割愛しますけど、ネットにありますので、ぜひご覧になってください。
カードを使って手順を理解したら、練習問題を解かせます。
ツリーが付いているところが1、付いていないところは0と考えて、どんなメッセージを送っているのか、カードを使って考えなさい、というものです。有名な問題ですよね。
仕組みの理解の確認と定着のためには、このような演習が必要かなと思っています。最初の授業では、このような問題で手計算まの手順まで練習させます。
ドリトルの使い方に慣れることで「写経」を避ける
手計算まで理解してアンプラグドで手順も理解しても、いきなり基数変換のプログラミングには入りません。まずはドリトル自体の使い方を学ばせます。包丁の使い方を知らないと料理ができないように、ドリトルの使い方を知らないと、プログラムを自分で考えて作ることはできないと思ったからです。
下図がその内容です。まずはドリトルで四則演算の計算機を作らせました。X＋YのXとYに数値を入れて、プラスボタンを押したら、答えのZが出てくるというものです。コードでは、たった9行です。生徒は非常に盛り上がりました。自分が打った文字で、一つひとつフィールドと呼ばれるものが出てきて、さらには「+」のボタンをポチッと押して…と一行ずつスモールステップでやっていき、できたらお互いにチェックし合うのですが、たったこれだけで、すごい盛り上りです。
最初の計算式は、計算イコールX＋Yだけですが、ここまで作ったら、「じゃあ、今度はBMI(※)の計算方式を作ってみよう」ということで、ネットで調べさせて、BMIの計算方式、つまりY/(X*X)に作り替えさせてみました。
※Body Mass Index:肥満指数
生徒たちの感想は、「こんな大変なものでスマホやコンピューターが動いているのか。こういうものを開発した人ってすごい」とか、「普段スマホでボタンを押すだけで、できることというのは、こういう計算で成り立っていることがわかった」とか、あるいは「プログラムの操作は必要だけど、一瞬でできるのがすごいというプログラム特性を理解することができた」というものでした。
実は昨年度、同じような実践をしたときは、四則演算のところをしませんでした。すると、生徒たちは最終的に基数変換のコーディングが「写経」になってしまった反省があります。だから、やはりプログラミングで基数変換を教えるとか、仕組みの理解をさせるためには、簡単な四則演算やBMIの計算のような「包丁の使い方」を理解しさせておかないと、自分で考えた手順でプログラミングができないことになってしまうのです。
結局、手順をプログラムに置き換えることをねらいとして授業をやっている以上は、写経を防ぐためにも、まずプログラムコードの書き方を覚えて、先生と同じものを打たずに、自分たちで考えて、プログラミングができるところまで足場作りに時間をかけないといけないと思います。
本題の基数変換では必ずテストをする場面を作る
ここまでを踏まえた上で、本題の基数変換をどのように教えたかを説明します。
今回は、事前に生徒にプログラムを配っておきます。二つフィールドがあって「11」という数字があります。「10進変換」を押したら「3」になる、というものです。
授業の頭に、「前回BMIをやったよね。今日はこれを配るよ」と言って、まずプログラムを配って、正しく動くかテストします。今度は11ではなくて10を入れたらどう変わるか、ボタンを押してみます。そこまでやったら、「では、フィールドを追加してみましょう。今は2ビットまでしかなかったので、今度は3ビットのものを作ってみよう」と呼びかけ、カード4の変換まで対応したプログラムを作っていきます。
具体的には以下の3つコードをスモールステップで書かせます。
（1）カード4のフィールドを追加するコード
（2）カード4のフィールドの値を読み込むコード
（3）カード4の計算式を追加するコード
ここまでは一斉にやって、3ビット以上は自分たちでどんどん増やしていかせます。
ここでのポイントは、必ずテストを行わせるということです。フィールドを追加して、読み込ませて、計算するということころまでプログラムさせますが、作ったらその都度テストしないと、正しくプログラムできたかどうかわかりません。
また、テストの機会を設けないと、試行錯誤が生まれないので、自分で手順が正しいか確認しませんし、わからなければ他人のものを写経しておしまいになってしまいます。
ここでは、入力した2進数のデータを用意しておいて生徒たちに全部打たせて、計算結果を出して、隣の人と答えが一致しているのかを互いに確認させて、テストが正しく実施されているかお互いにチェックすることでコードエラーを防ぐようにしました。
この過程で、プログラムのテストをさせるだけではなく、ペアを作ってチェック項目に沿って相手のプログラムをチェックさせます。この活動には、プログラムは習熟差が大きいので、それを防ぐという意味もあります。
最終的に7ビットまで作ったのは、ASKII（アスキー）コードを読み取らせたかったからです。本来であれば8ビットまで行うつもりでしたが、コードの数を減らすために７ビットまでにしました。2進数の数字を用意しておき、10進数の数字に直して文字コード表に対応させ、メッセージを読み解きます。プログラムを作れば、一回一回手計算しなくても正しくプログラミングができておけば、簡単に解読できます。
ここまでのプログラミングを１コマで行いました。
プログラミングの評価をどのように行うか
最後に、これをどう評価するかという問題です。
プログラムの実践で、どのように評価するかということについては、実はなかなか報告がないと感じています。私は、授業の最後に行うアンケートで、スライドのように「プログラムを使わなくても理解できたのか」「プログラミングを使って理解できたのか」「基数変換自体が理解できなかったのか」の3項目で質問しました。
生徒たちからは、「プログラミングを使って理解できた」が79％、「使わなくても理解できた」というのは10％で、合わせて89％の生徒が授業でわかったと言っています。
それぞれの生徒の意見です。「プログラムを使わなくても理解できた」という10%の中には、中学校の頃Scratchをやっていたという子もいました。「プログラムを使って理解できた」という79パーセントは、「やっぱりアンプラグドとか手計算だけじゃなくて、プログラムに置き換えると、よりわかりやすくなった」と言っています。こういった意見が聞かれたことで、やはり手計算だけ、アンプラグドだけでなく、違うものに手順を置き換えさせることで、理解が深まったのではないかと考えています。
生徒たちの中には理解できなかった生徒も、もちろんいました。なぜこの1と0の羅列を入れたら、その数値になるか理解できなかったという人たちです。この人たちは、1ビット、2ビット、3ビット…と増えていくときに、なぜ数字が1、2、4、8、16と増えていくのか、わからなかったようです。やはりアンプラグドのところからつまずいている生徒もいたので、そこが課題かなと思っております。
プログラミングをどう評価するかということですが、皆さんは生徒200人がプログラムの授業をしたら、全員分のコードが正しく打てているのか確認されますでしょうか。これは、我々が今後プログラミング教育をする上で必ず考えなければならない問題です。
「全員分を集めて全部コードをチェックすることは、課題を与えた者として当然だ」という意見もあると思いますが、今後プログラムの授業が増えていくにつれて、毎回このような評価をしていたら、まさに評価地獄です。神奈川県の先生方と話していたとき出てきたのは、「それなら、もともとエラーがあるプログラムを次の時間に配付して、修正できたらテストをしてみればいい」という意見が出ましたので、次の時間では、あえて計算式が間違ったプログラムを配って、テストをさせて、うまく修正できるかをやってみました。
そうすると、先ほど「基数変換が理解できた」と答えた人はは89％でしたが、1週間後にプログラムを修正できた人は73％で、できなかった人が27％いました。つまり、「できた」と思っていた中で16％程度はデバッグ、すなわちプログラムの修正ができなかったわけです。これをやったことで、理解をきちんと深めるためには、やりっ放しではなくて、定期的に演習が必要であることを感じました。
「できなかったこと」の発生理由を考える
最後に「できなかったこと」です。
昨年度は、内容を欲張りすぎて10進法から16進法までやりました。兼宗先生とも相談して、「256（にごろ）を超えたらエラーが出てくるね。商と余りに分けて配列を作って、10進法から16進法の変換はどうやったらうまくいくかな」と考えさせたのです。
そして生徒たちに、どういう計算手順を考えたらよいか聞いたら、そもそもプラグラムでどう計算すればよいのか、全くわからない。あるいは「32進法を作ればいい」とか全然違う方向に行ってしまって、これは大失敗でした。紙と手計算なら、生徒は10進数から16進数の変換は簡単にできますが、プログラムでやるとできなかったというのは、「プログラミング『を』教える」ことをおろそかにしたからですね。これが昨年度の反省点です。
やはりしっかり手順を置き換えるためには、「包丁の使い方＝ドリトル」をしっかり教えておくことが必要です。ですから、科学的な理解をプログラムで深めるのであれば、しっかりプログラムのやり方を覚えて、手順を自分で表現できるようになってから入らないと、深みがある授業にはならないと思っています。
まとめです。「プログラミング的思考」とありますが、今回の私の発表で言えば、手計算で基数変換をすることと、プログラムを作って問題解決することの間にあるのが、プログラミング的思考ではないかと思います。これがテストであり、試行錯誤であると。
これはドリトルでなくても、エクセルでもJavaScriptでも作ることができ、簡単です。皆さんもご自分の学校で使っているもので、基数変換の手順をプログラムで組ませてみてはいかがでしょうか。
やはりプログラミングには、今後プログラムの仕組みや特徴といったものまでどんどん入っていくと思います。我々、教科は情報ですので、いろんなコンピューターの仕組み、原理、そういった手順をプログラムで組ませていくことで、情報の科学的な理解をどんどん深めていくことができるのではないかと思っております。
[質疑応答]
Q1(高校教員)：2点お聞きします。1点目は、エラーのあるプログラムを修正することができた生徒には、最初からプログラミングが理解できていて修正できた人と、プログラミングは理解できていなかったがエラーは直せたという生徒もいたかと思いますが、そのあたりはいかがでしたでしょうか。
もう一つは、基数は私も大変苦労して教えていますが、最終的には一の位・十の位・百の位という言い方ではなく、十の位というのは10の１乗の位で、百の位は10の2乗の位だったら、それを2進数、3進数、4進数に落とし込んでいくというのを、教科書的に、最終的にはアナログでやらないと、子どもたちはそこへ持っていけないような気がするんですが。
鎌田先生：まず1点目については、今年度はプログラミングを理解できている・いないというデータとの関連付けはしていないので、来年度はその関係もぜひ確認したいと思っています。
2点目については、これはまだやったばかりで、私自身も、今ご指摘いただいた部分や、手計算では簡単にできるものが、プログラミングになると急に難しくなったりするといったところが、やってみて初めて見えてきたところです。そこは面白いところだと思いますので、ぜひ参考にさせていただきたいと思いますし、教科書内容ともっと関連付けた実践を広めていきたいと思っています。ぜひ皆さんも実践されてみて、ご意見や生徒の状況を教えていただければと思います。
Q1’:友達が作ったプログラムを直すというのは難しいのでしょうか。
鎌田先生：友達のプログラムについては、テスト段階で、数字が違ったらどこがどう違うのかということについて、友達同士でフォローアップはさせています。ただ、友達が打ち直してしまうのだけは絶対にさせないようにしています。それをやってしまうと、まさに「写経」以下になってしまうので、それだけはやめたいと思っています。
それともう一つ、この修正させたのは、皆さんが言う写経ですよね。「写経」の悪いところは、生徒が本当に理解しているかどうかわからないことです。そこにデバッグをさせたというところのテストの意味があるかなと、今のところはこのデバッグのテストが効果的であると思っています。ただ、誰もプログラミングの評価ってこうすればいいというモノは出てないのです。。だから私は今回、私なりに感じた形を提案させていただきました。
Q2(高校教員)： プログラムから計算をさせるのにあたって、なぜエクセルの数式ではなくドリトルを使われたのでしょうか。エクセルを使って、数式を入れるだけでもできると思いますが。
鎌田先生：いろいろな理由がありますが、一つは本校がプログラミング教育研究推進指定校でもあるので、プログラミングを使って理解を深められないかと考えたことです。もう一つは、逆に私からお聞きしたいのは、エクセルってプログラムなのでしょうか。エクセルでなさる先生もよくいらっしゃいますが、エクセルだとけっこう簡単にできてしまいますよね。細かい手順まで指定しなくてもできてしまうのがエクセルです。
プログラムの特性というのは、コードを正しく一つひとつ正しく打たなければならないところとか、どの数値を読み取り、どのようにその数値を計算の手順として組み込むのかまで作らないといけなかったりするので、より深く理解できるのではと考えております。
一番の理由は、先ほど授業の狙いのところでお話しした「手順を置き換える」ということです。計算手順をプログラミングに置き換えて考えるときに、ドリトルは日本語で簡単に表現できるので、本校の生徒にとって非常に取っつきやすいということもあり、今回はドリトルを使いました。
実は昨年度、同じことをJava Scriptでやろうとしたら、生徒からすごい反発が来ました。理由は「英語の授業じゃない」。やはり英語に苦手意識が英語にある生徒たちには、ドリトルの方が導入として授業に入りやすいと実感しています。
Q3(高校教員)： 先ほどわざとバグのあるプログラムを使うというお話がありましたが、プログラミングのエラーにはいろいろな種類がありますよね。今回は拝見した限り、論理的なエラーかと思いますが、例えば生徒が実際にやったときに、どの種類のエラーがどの程度出たかを集めて、テストするときもそれらを含むようなものを作るなどしていただけるとありがたいです。今後、私たちが実際にやってみるとき、注意しなければならない点があると思いますので、ぜひそういった研究もお願いします。
鎌田先生：今ご指摘があった部分は、未着手でした。たぶん、ほかのプログラム実践も同様かと思いますが、生徒がつまずくところはほとんど一緒ですよね。生徒が実際にプログラムを書くとき、どこでつまずいたのかのデータを集めて、来年度以降の授業改善に生かしていきたいと思います。建設的なご意見、ありがとうございました。
※第10回全国高等学校情報教育研究会全国大会（東京大会）（2017年8月8日・9日）の講演より