事例101

プログラミング「を」学ぶ、プログラミング「で」学ぶ

神奈川県の教育課程推進委員会情報部会では、2015年からプログラミングを取り入れた授業実践の研究を行っています。当時、研究推進委員に課せられたミッションが、「プログラミング教育をアクティブラーニングでやりなさい」というお題でした。その時一緒に実践研究をされたのが、相模原総合高校の大里先生と、生田東高校の大石先生でした。

大里先生の実践は、「『エイリアンとの交信』を題材としたプログラミングとアクティブラーニング」というものです。

プログラミング言語は、初めて接する生徒たちにとってはわけのわからないものだから、エイリアンと交信するという場面設定をして、VBAというプログラミング「を」楽しく学ぼうという授業です。

一方、大石先生は「暗号を解読せよ～プログラミングで学ぶ公開鍵暗号～」という授業をされました。

手計算で公開鍵暗号の解読の手順を検証した後、それをプログラミングに置き換えて自動で実行することによって、公開鍵暗号方式の解読困難性をプログラミング「で」学ぶものでした。

この２つの実践を調理に例えると、大里先生の授業は、様々な種類の包丁の中から、使いやすい包丁を選んで、その包丁を使うということを知ること。そして大石先生の授業は、調理の中で包丁をどのように使って、おいしい料理を作るかを考えることといえるでしょう。このように、「プログラミングを教える」と「プログラミングで教える」ということを、バランスよく行っていく必要があるのかなと思います。

こうした流れを受け、私は昨年度の全国大会で、「2進数から10進数の変換をプログラムで学ぶ」というプログラミング言語ドリトルを使った実践を発表しました。

発表の後に「なぜドリトルを使うのか? Excelで表計算すればよいのではないか」「わざわざプログラミングしなくても、紙の計算だけで十分ではないのか」という質問をいただきました。

その時は、それもそうかな、と思いましたが、やはりプログラミングを使う必要性があるという考えに至りました。

表計算というのは、プログラムという大きな枠組のごく一部です。ハンバーグを調理することにこのことを例えれば、Excelの基数変換は、冷凍ハンバーグをボイルしただけというイメージですが、それに対してプログラムの基数変換はハンバーグをゼロから作るイメージです。ハンバーグを作る過程で、材料を集めるところから始め、集めた材料を切ってこね、そして焼いて作るようなものです。ですから、求める値が出てくる裏でどのような仕組みが動いているのかを理解するためには、やはり自分の手でプログラムを書いてみることが必要ではないかと考えました。

また、手計算で何となく行っていた手順を、プログラミングという全く違うものに置き換えて、手順をもう一回組み直すからこそ、深い学びにつながるということもあると思います。自分が考えた手順をプログラミングの手順に置き換えて、見通しを持った試行錯誤することに意味があり、そこが深い学びにつながるのではないかと感じています。

それらを踏まえた上で、具体的な授業について説明していきたいと思います。

生徒にいちばん身近なLINEを題材にする

昨年度本校では、全国大会で発表した基数変換の授業、大石先生が発表された公開鍵暗号方式をプログラミングで体験する授業、そしてクライアント・サーバ型システムの役割をプログラミングで体験しようという、3つのプログラミングの授業を行いました。

「クライアント・サーバ型」というのは、指導要領にも書いてありますし、教科書にもしっかり載っています。でも、どうやって教えたらいいのか、という点に頭を悩ませている先生方も多いのではないでしょうか。情報の先生方に聞いてみても、「文言しか教えていない」「仕組みをどのように体系的に教えればいいかわからない」という声が、けっこうありました。それなら、これを研究授業としてやってみようと思ったわけです。

しかし、ネットワークの仕組みを体系的に教えるのはすごく難しくて、本当に試行錯誤の日々でした。考え抜いた末にLINEを題材として、クライアント・サーバ型を教えることにしました。なぜなら、高校生はみんなLINEを使っているので、身近な題材で、より興味を持ってもらえると思ったからです。

本当はLINEでなくてもいいのですが、何のためにプログラミングするのかを理解する上で、生徒の興味を引くきっかけとしてLINEを用いました。

授業の最初に、「あなたの端末から友達の端末まで、LINEのトークのメッセージはどうやって届いていると思う？」という問いかけをすると、生徒たちは、端末から端末まで、一直線でつなごうとします。

ポイントは「送信役」「サーバ役」「受信役」の３つを設定すること

具体的な授業の方法です。生徒を3人一組にして横に並べ、真ん中の人をサーバ役とし、左右に送信役と受信役を置きます。

役割を３つに分けたのと、それぞれ違うプログラムを書くこと、つまり、違う活動を行うことで、一連の流れが体験できました。

その後、「送信ボタンを改良しよう」「受信ボタンを作ろう」という、次の段階に進みます。いきなり全部作るのではなく、最初に役割を分けてその流れを確認した後、送信ボタンや受信ボタンの機能を改良し、さらにうまく動くようにしていきます。このように、一つずつ流れを確認して、プログラムを少しずつ書き換えるごとにどのように実行結果が変わったか毎回確認させるという段階を踏んだことで、生徒たちもしっかり理解できたのではないかと思います。

プログラミング教育の評価をどうするのか

この授業の評価ですが、プログラミング教育の中で、コードの評価だけをしていても不十分だと思います。生徒からも「友達のコードを写させてもらえば、同じ評価になるのがおかしい」という声があがり、それなら、プログラミングでクライアント・サーバ型を理解できたかということを評価すべきという結論に至りました。

そこで、この授業を行ってから、試験期間をはさんで2週間後に、ネットワーク図を書くというテストをしたところ、生徒たちはものの見事に忘れていました。

このように、復習テストをやってみて、プログラミングでもコード以外の評価が必要だと、改めて考えさせられました。評価というのは、生徒が受け取ったときに、納得できる評価であることが重要です。コードを書いてもらうのも確かにいいのかもしれませんが、それだけではない形の評価も考えていかなければいけないのかなと思っています。

プログラミング「で」学ぶことから広がる可能性

下図は、去年の「基数変換」と今年の「クライアント・サーバ型」の授業をどの程度の生徒が理解したか、その割合を比較した表です。今年は「理解した」の割合が増えていて、特にクライアント・サーバ型の理解が75%と高かったので、さらに改良して、よりわかりやすい授業にしていきたいと思っています。

高校教員A : 大変参考になるお話でした。「コードを評価しない」というところは、なるほどなと思いました。クライアント・サーバ型を理解したかどうかを、どのように評価されているのでしょうか。

鎌田先生 : 最初に配った端末とサーバだけが描いてあるプリントで、自分のメッセージが、友達まで届くまでの流れが正しく描けているかどうかで評価します。

まず、送信者がメッセージをサーバに送り、受信者が受け取るときにサーバにメッセージを要求して受け取る、この一連の流れが描けていれば、クライアント・サーバ型の仕組みは理解できていると判断できます。クライアント・サーバ型は、受信者が要求してからメッセージを送るというところがポイントです。

高校教員A : もう一点伺いたいのですが、LINEの説明では、メールが飛んでいくようなイメージになっていますが、実際のLINEとは、若干違うような気がします。生徒たちが抱く概念と、実際がずれているところは、どのように説明したらよいのでしょうか。

鎌田先生 : 今回は、「メッセージは端末から端末へ直接行き来しているわけではない」というところに主眼を置いたので、複雑にならないよう、あえて簡略化しました。今回の学習では、ここまででよいと思っています。

高校教員B : 「プログラミングで学ぶ」というのが素晴らしいと思ったのですが、「プログラミングを学ぶ」というのも、最初にある程度必要だと思います。この授業の前に、プログラミングをどこまで学んでいってここにつながっているか教えてください。

鎌田先生 :  1学期ではドリトルで四則演算を行う演習をして慣れさせています。また、先ほど紹介した2進数から10進数への基数変換のプログラムの学習をしていて、そこでもドリトルを使いました。ドリトルの使い方はある程度わかるという状態で、この授業に臨みました。

第11回全国高校情報教育研究会全国大会事例発表より