【連載】榎本裕介の “教育×Google Workspace” 最前線
Google Workspaceを教育現場の最前線で活用されている昭和学院中学校・高等学校 教諭（理科・情報）博士（工学）榎本裕介先生にお話を伺いました。
現場の先生方がかかえる、ICT活用についてのいろんな悩みに回答いただきます！
はじめに
共通テスト新教科「情報」の発表もあり、多くの学校でプログラミング教育の需要が高まっています。実践事例や教材の紹介は他の方々に任せるとして、今回は私が実際に「情報の科学」の授業においてプログラミング教育をしてみて見えたものを紹介します。
プログラミング教育を通して、情報科以外の先生方にも大きく関わる、生徒の学びの姿勢について多くの気づきがありました。私は理科教諭として教壇に立ちながら、興味本位でプログラミングの勉強を始めてハマり、情報科の免許を取りました。遊びの延長として学べるものであると強く実感しています。そしてその学びの過程には、日本の近代教育の誤りを修正できる機会が多くあることが分かりました。多くの人が未知のものとしてとらえているプログラミング教育の先にあるものを知ってください。
Google Colaboratoryはプログラミング教育を加速させる
Google Colaboratoryはウェブブラウザさえあれば動作するプログラミング言語Pythonの実行環境です。実施が決定した大学入試共通テストの新教科「情報」においてもその試作問題の文法がPythonに近いと話題になりました。
YouTubeやDropboxなどがPythonで作られていることも有名で、数あるプログラミング言語の中で高校生がPythonを学ぶことにデメリットは見当たらないと思います。
Colaboratoryを使えば端末へのインストール作業は不要です。生徒はGoogleアカウントにログインするだけで使えます。Google Classroomを経由すればGoogleドキュメントなどと同様に「各生徒にコピーを作成」の形で配布することもできます。「新しいアイテムを添付」では追加できないので、事前に教員のGoogleドライブに配布用のColaboratoryファイルを作成しておきましょう。教員側で準備したコードがすでに書かれたファイルを生徒に渡し、課題としてそれが実行できる状態で提出させることができます。また、配布した時点で教員側に閲覧権限が付与されるので、授業中に生徒がどんなコードを書きながら進めているのかを見ることもできます。
生徒自身にとっても、学校で学んだあとに自宅で別のPCを使っても同じプログラムを動かせることは良い蓄積になります。大学でプログラミングを学んだものの、大学でのPC教室の実行環境が再現できず、卒業後に同じことができなくなるという話はよくあります。学んだことを確実に蓄積していけるGoogleアカウントに紐づいたファイルと実行環境は、とても価値あるものだといえます。
プログラミングでしかできないことの体験を目標にする
プログラミングを独学するための書籍の多くは、文字列の表示や四則演算など、基礎から一歩ずつ説明されていることが多いです。これを高校生の授業において踏襲するのは非常に危険です。なぜなら、独学しようとする人たちと、必修科目の授業として履修する高校生たちでは動機の強さが違います。「そんなのプログラミングなんて面倒なことをしなくてもいいじゃん」という至極まっとうな反論が生徒たちから出てしまえば、学びへ向かう姿勢はどんどん崩れていきます。将来ゲームクリエイターになりたい、という強い動機があるのであれば、基礎の四則演算もその先を見据えながらコツコツ進められるでしょう。しかし手計算や電卓でできそうなことを延々と授業で扱っていては、生徒たちの意欲は継続できません。「将来役に立つから」「やらないと将来困るから」なんていう退屈な決まり文句ではなく、生徒たちが今学びたいと思わせることが大切です。
たとえば、この図は練習用に用意されたアヤメ3種の花弁とがくの大きさのデータセットを、たった３行で可視化したものです。方眼紙にちまちまと点を打ってグラフを描くことを強いられてきた生徒たちにとって、膨大なデータが一瞬でグラフになることは「人間にはできないこと」の実感を持てるでしょう。実際にはGoogle検索で検索ボタンを押した結果のほうがとんでもなく複雑な処理を一瞬でしていて、生徒たちは日々接しています。しかし、テクノロジーの発達によってどんどん「複雑な処理が行われている感」が出ないようになりました。教師ができることは、要所要所で生徒たちのモチベーションが下がらないように、プログラミングによってできることを示しながら生徒の成長に合わせて適切な目標を設定することです。
プログラミング教育を通して学びの姿勢を修正する
プログラミング教育によって得られるものはエンジニアの養成だけではありません。私は情報の授業のなかでプログラミング教育を実践してみて、現代の教育によって定着してしまった誤った学びの姿勢が修正できると考えます。
実際に直面したプログラミングに挑戦する際の生徒たちの姿から、生徒がその行動に至る要因を分析しました。
「これであっていますか？」と実行前に質問する生徒
プログラミングの教育的に良い点として、自分が書いてみたコードが正しいかどうかは極めて公平に結果が返されることです。他の教科の解答を添削するには専門的・体系的な知識を持った教員が判断する必要があります。私自身の本業は理科・生物です。たとえば物理の大学入試レベルの記述問題の添削をするとなると、どこにどう部分点をあげるか公平な判断がなかなかできません。実際に、簡単に見える中学物理であっても、自分で考えた基準を物理を専門とする教員に「こういう基準でいいですかね？」と相談したことも、そこで指摘されて基準を変更したこともあります。何が正しいかを判断するには専門的な知識が必要になるもので、その知識を学ぶ途中の生徒にとって、誤った判断基準で添削してしまうことは学びの大きな妨げになります。その心配から、教員から問題集の解答を丸付けする生徒に対して「論述問題は先生が丸付けするから採点しないで」なんていうやりとりがありそうです。そんなことが繰り返されれば、生徒が「正解は先生に判断してもらうしかない」と考えがちになるのは、仕方ないことなのかもしれません。本来であれば生徒は、まずは自分の考えを持ち、何度も「これであっていますか？」と教員に質問し、何度却下されても次の案をぶつけることが正しい学びの姿だと私は考えます。さらには、教員の示す１つの模範解答を見たときに「こんな考え方じゃダメなんですか？」と別案を出せるのが理想です。しかし、現状の日本の学校教育ではその姿勢を身に付けることなく、ただ１つの正解の提供を待つ子どもを量産してしまっているように思えます。その結果がプログラミング教育の過程で見られる「これであっていますか？」と実行前に質問する生徒なのかもしれません。
プログラムを何度実行しても失うものが無いはずです。しかし、実行ボタンを押すことなく悩み続ける生徒をたくさん見てきました。不正解を恐れ、自力で挑戦するという発想を失ってしまった結果です。逆に言えば、プログラミング教育を通して本来あるべき学びの姿勢を取り戻すことができるかもしれません。まずは自分の考えを持ち、達成できるまで策を講じて何度でも挑戦し、そこから何かを学び取る。現代の子供たちが失いかけている学びの姿勢がプログラミングを通して身につくと期待できます。
エラーを起こしても、消しては同じコードを書いて繰り返し実行する生徒
Google Colaboratoryに限らず、プログラミングをする際に誤ったコードを実行するとエラーメッセージが表示されることがほとんどです。複数行あるコードでもどの行でエラーが発生したのか、どんな種類のエラーが発生したのかが返されます。エラーメッセージは英語であることがほとんどなので、高校生にとっては少し面食らうことがあるかもしれません。しかし、日本語を母国語としてプログラミングをする同志はたくさんいるので、エラーメッセージをそのままGoogle検索にかけるだけでも詳しい日本語の解説とともに解決策が見つかるかもしれません。また、エラーメッセージはごく単純な英文ですので、中学生で学ぶ程度の英語力があれば読むことができるでしょう。しかし、不思議なほど多くの高校生たちはこのエラーメッセージと向き合いすらしません。高校での定期考査の返却の際、教員から答案をもらうと恐る恐る点数だけを見て、一喜一憂したあとには二度と答案を見ない生徒、いませんか？定期考査に限らず問題演習という形で自身の知識を試す際には、不正解になったときこそが成長のチャンスです。今ある知識の構成を再編し、より体系化するチャンスです。何がどう間違っていたのか、どこを修正すれば正解になるかを考えることで、一歩ずつ正しい知識に近づきます。その成長を目的として実施されているはずの定期考査が、いつしか存在意義がねじ曲がり、よい点数を取ることが目的にすり替わってしまっているのかもしれません。そうした文化が何十年も重なった結果、不正解を直視しないのが当たり前になってしまったように思えます。
一方で、思考停止して反復練習を続け、ひたむきに努力することを良しとする工業化時代の教育制度が問題視されながらも、深く根付いているのが今の学校です。違和感を持っても文句を言わず、指示されたことをただ繰り返すことを褒められて育った生徒たちは少なくないでしょう。エラーを起こしても、消しては同じコードを書いて繰り返し実行する生徒は、それらの産物だと私は分析しています。実際に、ケアレスミスで書くべきコードを誤り、ただ消して書き直してみるだけで問題が解決することはあります。エラーコードの解消のための１つの問題解決策として「もう一度やってみる」は悪くはありません。しかし、それを３回も４回も繰り返すのは不毛な時間の浪費に見えますが、一定数の生徒たちは文句も言わず繰り返し、同じエラーメッセージを表示させます。「先生、何回やってもうまくいきません」と言います。そのセリフの裏には、何度も挑戦すれば解決するという期待があるのでしょう。そこで教員が「こうすれば良いんだよ」と正解を教えてしまっては生徒の成長の機会を奪うことになります。「なんていうエラーが返ってきている？」と生徒に問いかけ、それと向き合う姿勢を身に付けさせましょう。そして、解決策を生徒が思いつくまで我慢し、サポートします。解決で着た際にはすかさず「次に同じ失敗をしないように書き留めておくのはどう？」とアドバイスし、その失敗を生徒の成長に繋げることが教員の役目です。
自分で書いたコードに説明のコメントが書けない生徒
プログラミングをするとき、プログラムの実行に関係の無い自由なコメントが書けます。これの重要性に生徒が気付くと、他教科の学習にも繋がる意識改革ができます。上述の通り、書いたプログラムが正しいかどうかはコンピュータがすぐ結論をくれます。しかし、重要なのはその成果物が完成したことではなく、完成に至らせる思考力が身についたかどうかです。そのためには「なぜそのコードを書いたのか、来週の自分が見て分かるようなコメント」を書くよう指導します。真面目な生徒ほど１行１行翻訳するように細かく書きがちですが、大切なのは動機です。
たとえば空っぽのリストを作ってから、その先の繰り返し処理でそのリストの中に要素を追加する、というプログラムがあります。そのとき「空のリストをつくる」とコメントを残しても、それはコードそのものを見ればわかる話で、あまり意味がありません。「後でここに条件を満たしたものを入れるために準備しておく」といった、なぜそのコードを書いたのかが分かるように説明することが重要です。授業の中で生徒同士で教え合うことを推奨するなかで、教師が見抜きにくいのが学び合っているのか、ただ結論を聞いているのかです。他の生徒に教わり「なるほど！ありがとう！わかった！」と声をあげる生徒、本当に腑に落ちて理解できていてほしいものです。ところが実は提出物を完成させるだけが至上目的となっていて、ただ友人の模範解答をコピーしているだけかもしれません。そうしたときにコメントを書かせると、本当に理解できたのかどうかが見抜けます。教員が見抜くためというより、自分が自分のコードにコメントを書けないことに気付いた生徒自身が、何のために正解を追い求めていたかをやっと理解してくれます。「正解したからこれでいいじゃないですか」と思考停止する生徒を「君が成長しなければ意味がない」と、学びの土俵に引き戻すのが教師の役割です。課題に正解して点数をもらうことを目的にしてしまっている生徒は非常に多いです。生徒から、真顔で「授業はテストで点を取るためにやっているんですよね？」と聞かれたこともあります。そんな考えを持ってしまっていれば、コメントなんて書かずにただ正解の解答例を繰り返し書いて覚えるような勉強方法に走ってしまうでしょう。自分自身が理解し成長するためという本来持つべき目的があれば、せっかく腑に落ちたことを忘れてしまうのはあまりにもったいないです。なるほど、と納得した瞬間の思考は人それぞれです。本人にしか書けないものです。それをコメントに書き留める習慣がつけば、数学の証明問題でも、英語の長文読解問題でも、「なぜ自分はそう解答したのか」を書き留めながら学習する習慣ができます。
おわりに
私はプログラミングを覚えてたった数年の、素人に毛が生えた程度です。少し扱えるようになったからこそプロのエンジニアとの差をはっきり分かるようになりました。しかし、その少し扱える程度になるだけで世界の見え方は大きく変わります。実験科学のポスドクとして働いていた時代に、もしプログラミング的思考が備わっていれば、もっと研究が進んだだろうと思い返すこともあります。確実にプログラミングの素養は様々な領域において発展を促すものです。また、社会の望むIT人材の養成という目的だけでなく、学びの姿勢の改善のためにも有効であることを全教科の教員が知り、生徒たちを前向きにプログラミングへ向かわせてほしいと切に願います。
お問い合わせはこちら
本コラムに関するお問い合わせはこちらからよろしくお願いいたします。
