私の自己紹介のところで必ず使っているスライドがこちらです。「何が特徴か」と言えば、特徴がないこと。「何が個性か」と言えば、個性がないこと。好きな関数はAVERAGEという、いわゆる普通の教員です。

そんな普通の教員がびっくりしたニュースが、今年3月に大学入試センターから公表された大学入学共通テスト「情報」の「サンプル問題」です。たぶん、先生がたも気にして見ていらっしゃったと思いますが、こちらの問題が出てきたとき、現場は揺れました。

まず「実際に生徒はこの問題に対応できるのか」と。さらに、「この問題に対応するためには、どう授業をすりゃいいんだ」という声が出てきて、つまりまとめると、「我々は受験に対応できるのか?」ということになるのです。これについては、「情報Ⅰ」の不透明さも手伝って、不安に思われる先生が多いのではないかと思います。

私も、やはり不安な部分は感じますが、実際に「サンプル問題」を解くには、ということを考えていくと、できれば授業のスタイル崩さずして、その普段の授業で身に付いた力を使って、「サンプル問題」、もしくは共通テストのような問題に対応できることが、一番負担感なくできるのではないかなと思います。

では、実際にどんな授業をしていけばよいのか、というのが今回の私の報告です。

プログラミング演習をこなしながら、こういったテストに対応できるようにするには、どのようなことを授業の中で扱っていかなければならないのかを、授業の実践を通して考えてみました。

最初に、やはり「サンプル問題」がどんな問題かというのを、もう少し丁寧に見ていく。それに基づいて単元指導計画を立てて、実際に授業を行う。そして生徒がどんな力が身に付いたかということを評価する、という形で回すことにしました。

まず出題内容です。今回は、第2問のプログラミングの領域の部分だけを取り上げました。

この問題には、問1、問2、問3という形で3つの問題が入っています。まず問1では、配列の添え字、配列の要素ごとの計算という形で、配列操作の基本が取り上げられています。

これを、プログラミングの知識の項目ごとにまとめました。「変数」と「表示」の辺りはおおむね問題ないと思いますが、問題が「条件分岐」です。「条件分岐」のところは、数値での分岐で、実はelseがなくて一択のみ、という形になります。「繰り返し」の部分については、ループカウンタを0からnまで回すといった基本的なループの扱いです。

さらに、「配列」についても取り上げられていますが、0から順番にアクセスするという比較的基本的な内容で、あまり複雑なプログラミングの知識は求められていないのかな、と思います。少なくともサンプル問題のこの内容は、現行の「情報の科学」のプログラミングの単元で、しっかりと対応できるのではないかと思います。ですので、まずそこをしっかり教える、しっかり身に付けさせるというところが求められるのではないかと考えました。

実際の授業の実践について説明します。

授業対象にした生徒は、特別にプログラムを学んだ人たちではありません。過去にプログラミング教室に行ったことがある人もいないと聞いています。

学習環境については、神奈川県がGoogleのアカウントを生徒全員に配布していますので、そちらに乗った形で、Google ColaboratoryとGoogle Classroomを使っています。

重点指導ポイントとしては、やはり「繰り返し」処理にしっかり力を入れることを計画しました。本校のカリキュラムの関係で、「情報」が3学年に設置されていますので、実際に問題を解いたのは3年生の生徒です。9クラス、333名に対して行いました。

学習環境のGoogle Colaboratoryは、アカウントを持っていれば使えるというところと、グラフィカルなものがノーアクションで可能です。実際に授業をやってみて特に問題がなかったので、しばらくはこれでやっていこうかなと思っています。

実際に授業をしてみての振り返りです。まず今回の授業の評価の指標としては、課題の提出率、「サンプル問題」の正答率、単元振り返りの全体の要約という、この3つで見ていきたいと思います。

まず課題の提出率です。学び合いの時間を設定したためか、比較的高めになっています。

若干、応用問題のところについては少し低い部分がありますが、それでも8割を超えているというところで、提出率についてはおおむね良い学習状況であったと思います。

こちらがサンプル問題の正答率になりますが、問1、問2、問3をそれぞれ全問正解したという、全問正答率について表示しました。

問1、問2については、全問正解した人が65%ということで、ここまでは問題なかったと思うのですが、最後の問3は、いろいろ引っかかる要素があって、正答率がガクンと落ちたというところがありました。

単元振り返りを文章で入力をしてもらったものを、ユーザーローカルのテキストマイニングで要約を行った結果がこちらです。

「基本構造でさまざまなことが使える」という回答と、「覚えるだけでは応用がきかない」というものが多かったです。あと、「今回のテストで、プログラムの実用的な使い方がわかった」ということも見えたようで、単元で伝えたかったことについては伝わったのかな、と考えています。

最後に改善点です。やはり、この問3の正答率の低さが引っかかりました。これについては、正直なところ生徒たちには申し訳なく思うのですが、自分自身ちょっとうまくいかなかったかな、と思っています。

その要因を考えてみたのですが、プログラミングの授業は、課題があってプログラムを作ったら完成です、という段取りになりますが、その時にプログラムが動いたらOK、と考えている生徒が少なからずいたのではないか、と反省しています。

言ってみれば、「どう動いているか」という細かいところまでは追えていないけれども、何となく動いている気がするからOK、といった提出の仕方も透けて見えるというような状況でした。

これを改善するためには、未完成のプログラムを載せておいて、そのプログラムがなぜうまく動かないのか、というところをしっかり考えて、どのように改良したらよいか、という形の課題の出し方にすると、幾つか改善できるかな、と思っています。

最後に、今回は「揺れる現場」ということで紹介をさせていただきましたが、「どんな授業をすればよいか」ということについては、私はプログラムの過程を考えさせるような授業設計にすれば、少なくとも対応はできるのではないか、と考えています。

したがって、これを「揺れる現場」ではなく、できれば「高め合える現場」という形で、先生がた同士で、さまざまな実践例をどんどん挙げて、お互いにいいものを公開し合うことによって、より良い授業改善という形で結んでいければと思っています。