高校教科「情報」シンポジウム2018秋(ジョーシン2018)講演
情報I、IIで扱うプログラミングへの期待
大阪電気通信大学 兼宗進先生
今回は、私が中教審の初等中等教育分科会で、新しい指導要領を策定する教科「情報」のワーキンググループで、小学校・中学校・高校の全体のカリキュラム作成に関わったことと、「小学校段階における論理的思考力や創造性、問題解決能力等の育成とプログラミング教育に関する有識者会議」に参加したという立場からお話します。新教育課程では小学校から高等学校で一貫したプログラミング教育が行われることから、タイトルでは「高校の情報I、IIで扱うプログラミングへの期待」となっていますが、内容には小学校、中学校のことも含んでお話します。
小学校のプログラミング教育の実施もいよいよ間近になり、現場の先生方の研修も始まりました。研修などで話を聞くと、「プログラミングは全くやったことがない」という先生が多いようです。小学校の体験は大切にしたいところです。体育などと同じで、初めにコンピュータ嫌いを作ってしまうと、もう取り返しがつきません。ですから、小学校では「楽しかったな、もっとやりたかったな」という気持ちを子どもたちに持ってもらえたらありがたいと思っています。
高校につながるプログラミング教育の流れとして見ると、小学校のプログラミング教育の特徴は、教科が指定されていないことが特徴かもしれません。算数や理科の一部では使う場面が具体的に指定されているものもありますが、全体としては使う言語や教材には指定がありません。そして、全学年の全教科で利用を推奨されていますが、どこでどのように使うかは、学校ごとのカリキュラム・マネジメントに任されています。
小学校の状況を見ていると、きちんとやろうと頑張っているところと、全く興味のないところに二極化しているかもしれません。校長先生や教育長などのトップが主体的に取り組んでいる学校では、全ての先生が研修を行って、学年や教科によらずプログラミングを取り入れてみようと動き始めている学校が出てきています。ここにいらっしゃる中には専門家の方も多いと思いますが、そういった方々が各地域でサポートをしてくださると、さらにうまく回っていくのではないかと思っています。
5年生算数の多角形を書くプログラムでは…
実際にどのような学習活動が行われるのかを、私が電気通信大学の久野靖先生と開発しているドリトル言語を例にして見てみます。
小学校5年生の算数で正多角形を学ぶときに、プログラミングを使って図形を描く活動が扱われる予定です。例えばタートルグラフィックスを使うと、「100歩いて90左回りを4回繰り返す」と書けば、そのとおりに動いて線を描きます。プログラミングとしては順次と反復の考え方を使っています。
順次だけでも正方形を描くプログラムを書けますが、同じことが何回も書かれているのは無駄なのでまとめてみよう、という流れで反復を学ぶことができます。
この学習では、「正方形を描く」「順次と反復を学ぶ」だけでなく、今までの「紙と鉛筆で定規やコンパスを使って描く」ことに加え、「手書きでは子どもたちには難しかった図形もプログラムを使うと自由自在に描ける」ことがわかる。そういう展開をしていただければと思います。
例えばこの星の形も、手で正確に描くのは大変ですが、プログラムを使うと全員が描けます。
余談ですが、星を描くときの角度は144度なのですが、この角度を子どもが発見するのは難しいため、「星に近い形」を描いてしまうこともあると思います。この例では曲がる角度は145度ですが、見た目ではちゃんと星型に見えます。ただ、タートルはきちんと元の場所に戻っていないので、繰り返して何個か描いてみると、少しずつずれていきます。この例のように、「コンピュータは正確な角度で何度でも疲れずに繰り返すことができる」という性質を体感しながら、コンピュータの楽しさが伝わるとよいように感じています。
先生の取り上げ方次第では、かなり高度な活動の経験もありうる
次に、小学生がどのくらいのレベルのことをするかという意味で、授業で使われた例をお見せします。左はスクラッチのプログラムです。ブロックでは構造が少し見にくいので、右側に言葉で書き起こしてみました。
流れを見ると、最初に赤が点灯されて、ずっと繰り返すループに入っています。ボタンが押されたら、2秒間待ってから赤を消灯して青を点灯する。5秒間待ってから青を消灯して、その後「0.5秒待って青を点灯する。0.5秒待って青を消灯する」を5回繰り返してから、最後に赤を点灯して終わり。
これは、横断歩道の歩行者用信号の点滅をプログラムに書いたものです。小学生の社会科でも理科でも使える身近で良い題材ですが、プログラム的には全然簡単ではありませんね。「ずっと繰り返す」無限ループの中に、「ボタンが押されたら」という分岐のif文があって、その間に普通の命令が続いた後で、「5回繰り返す」ループがある、という3重くらいの入れ子になっています。
この例は、ある小学校の4年生の授業で使われたものです。授業では先生が入念に準備して、前の時間までに条件分岐と反復の考え方を子どもたちはしっかり理解していました。そして、公開授業ではこれらを組み合わせたわけですが、子どもたちを観察すると、このプログラムの全体を理解できている子どもは4分の1ぐらいだったと思います。個々の考え方は理解できても、それらを組み合わせて考えるのは簡単ではないようです。
しかし、見方を変えると、今後は小学校でこれくらいのことをやった子どもが中学校や高校へ来るのです。高校や大学で「Hello, World」なんてやっている場合じゃないよ、ということになります。
小学校のプログラミングで学ぶことをまとめると、上図に挙げたように、プログラミング的思考を身に付けること、究極の他人である機械に簡潔・明瞭に伝えること、そしてコンピュータの性質を知ることが重要になります。そのためには、興味を持たせる題材をうまく使って、子どもたちにプログラミングの楽しさを味わってもらえたらと思います。
中学校では「計測・制御」と「双方向コンテンツ」が二本柱に
中学校のプログラミングには大きく二つの柱があります。
一つは、現行の指導要領でも扱ってきた、入力のセンサー値を読み取ってアクチュエータに伝えたり、何かを出力したりといった、ある意味特殊な、「計測制御のプログラミング」です。計測・制御のプログラムはあらゆる機器で利用されているものなので、「技術科」の性質上、今の中学生も必修で学ばなければならないし、これからも引き続き学ぶことになります。
ただ、新しい学習指導要領では、全てにおいて「問題解決」が強く打ち出されているので、単にライントレースカーを走らせる、というだけではちょっと弱いのではないか、もう少し高度なことができないかと個人的には思っています。
一例を挙げると、これは昨年の中学校技術科の全国大会の公開授業で紹介されたものです。車が走ってきて、壁があると感知していったん止まります。次に、車にピンポン球を乗せて走らせると、同じように壁が出てきたら、アームを動かして球を壁のところに落とします。単に線の上を走るだけでなく、ピンポン球を持っているかどうかという状態を保持して「球を運ぶ」仕事をするプログラムになっています。このように、中学校のプログラミングでも、工夫次第でけっこういろいろなことができるようになります。
新しい学習指導要領では、もう一つ、双方向性のあるコンテンツのプログラミングが必修になりました。先ほどのライントレースカーは、パソコンの外にある機器にプログラムを書き込んで動かすというものでした。双方向コンテンツのプログラミングでは、「自分のコンピュータと友達のコンピュータ」もしくは「自分のコンピュータとサーバーのようなコンピュータ」といった、コンピュータ同士の通信のプログラムを扱います。スライドの下の方にドリトルの教材例が見えていますが、今までは中学生が学べるようなプログラミング環境がなかったので、教材会社やフリーソフトを作っている研究者などが、いろいろな教材を作っているところです。
処理の手順と状態を整理して示すことが必要
ただ、単独でも難しいフローチャート的な処理に、さらに通信が入ったプログラムは、子どもの理解が難しかったり、先生もうまく教えられなかったりということが、どうしても起きてくると思います。ですから、これらを整理してわかりやすく示す方法が必要ではないか。その辺りについては、皆さんがいろいろ知見をお持ちと思いますので、ぜひ議論ができればと思います。
下図は、外部入力の処理を私なりに分類してみたものです。
古典的な大型のコンピュータの時代は、一番左のように処理を始めたらひたすら計算して、翌日ぐらいにプリンターに一気に結果が出て終わり、と言った感じで人間とのやりとりはありませんでしたが、今は真ん中の図のように、センサーからの入力が随時割り込んで来たり、何かの処理をやりながらモーターも動かしたり、といった並行処理も含めたプログラムが当たり前に使われるようになっています。
さらに、子どもたちに一番身近なコンピュータであるスマートフォンのプログラムは、一番右のように、人がボタンを押したり入力したりしたらそれに反応するプログラム、もしくはネットからデータが届いたら処理する、いわゆるイベント処理のプログラムになっています。こういった部分について、教科書を作られる方々には、プログラムを考える際にどの場面ではどの形で考えたらよいかということを、きちんと整理して示す必要があるのではないかと思います。
もう一つは、例えば先ほどのボールを持って動くロボットカーのように、同じ入力があったとしても、ある状態のときにはこれをするけれど、違う状態のときには違うことをするという動きがあります。これをプログラムの中にモデル化して埋め込んでいく方法は、技術的には確立しているのですが、それを子どもたちにどのように伝えていけばよいかということは、多分あまり整理されていません。今後、これも必要になると思っています。
中学校の先生方とお話ししていると、手順を教えるのか、状態を教えるのかというところで混乱しておられる面もあるように感じます。もちろん両方とも必要なのですが、その辺りの使い分けを先生方にお伝えする必要があると思います。
高校のプログラミングでは手順よりも「データ」を意識させたい
さて、いよいよ高校の情報I・IIのプログラミングに関するお話です。小学校・中学校はでは手順が中心でしたが、高校では「データ」を意識することも重要と考えています。
新しい学習指導要領では、プログラミングがいろいろなところに出てきますが、大きくは情報Ⅰの「(3)コンピュータとプログラミング」ですね。それから、「(4)ネットワークとデータの活用」でも、できれば使っていただきたい、と個人的には思っています。
また、情報Ⅱの「(3)情報とデータサイエンス」もプログラミングを使うとはされていませんが、もし、プログラミングに習熟した生徒がいたら、ぜひそこでも活用してほしいと思います。
さらに、「(4)情報システムとプログラミング」では、まさに情報のシステムを作ります。人が操作するパーソナルコンピュータではなく、コンピュータが自律的に動くシステムを扱いますから、コンピュータが連携して動くことをどのように構築していくか、というお話になると思います。
ところで、アルゴリズムのプログラミングはどう教えればよいでしょう。大学で教える情報科学の基礎としては、定番とも言える教え方があります。アルゴリズムも同様です。ただ、高校の授業ではもっと役に立つことをやりたい。問題解決に時間を使いたい。学生にはわかりやすく説明して、十分に理解してもらいたい。さらに自分でプログラムを作る時に、それを表現してほしい…等などとやりたいことや理想はいろいろあって、簡単ではありません。
「最低限学んでおくこと」と「後回しでよいこと」の選択が必要に
そこで、私の方で考えていることをお話しししようと思います。まず、定番的な進め方が重要と思いつつ、一方でどこかで割り切りが必要と考えます。例えば、データ構造で「配列」というものがあり、情報系の学生は必ずここから学び始め、プログラムを書くのですが、この「配列」を思い切ってやめたらどうなるでしょう。プログラミングで複数のデータを扱うと言えば配列なのですが、この配列のインデックスを省略できる言語を使ってはどうか、ということです。
例えば、簡単なAという名前の配列があって、そこに30、50、80、70、40という値が入っているとします。それに対して、いちいちa[0]、a[1]、a[2]、a[3]、a[4]というインデックスを付けて扱うということが、はたしてアルゴリズムの本質かどうかということです。
教科書を執筆したり検討したりする世代、40歳以上の方たちというのは、自分が学んだときのことを思い出して、「やはり配列から始めなければ」と考えると思うのですが、プログラミングの技術が発達していることを考えると、学ぶ内容や順番を前提を変えて考えることは重要です。
今後高校でプログラミングが必修になり、全ての生徒が学ぶことになった時、初めてプログラムを習い始める高校生が、最低限学んでおく必要は何か、後回してよいのは何かということについて、今まさにこの時点で、大まかな合意を取っておくべきではないかと思っています。
プログラムを比較すると、左側が古典的な整列のプログラムで、私たちには親しみやすいものですが、右側は探索アルゴリズムで、ある条件に合うものだけを取り出して、別の配列に入れる、というものです。初めてプログラミングを学ぶ生徒には、多少なりともわかりやすくなるかなと思います。
アルゴリズム自体を理解してからソースコードを考える
こちらは、コンピュータサイエンスアンプラグドのアルゴリズムの解説ビデオです。多数のおもりを、天秤を使って重さの順番に並べます。情報系の大学2年生レベルのアルゴリズムの考え方を、小学校3年生くらいで理解できます。
最初に出てくる男の子は、2つのおもりの重さを比べながら、一番重いものを選んで1個ずつ並べています。このようなアルゴリズムは、C言語でアルゴリズムの入門を学んでいる大学生でもソースコードから理解することは簡単ではありませんが、この動画を見れば小学生でも考え方を理解できると思います。
今回、高校生がプログラミングを学ぶのであれば、まずこのようなアルゴリズム自体を理解してほしいと思います。そして、「これをプログラムで書くならどうするか」につなげられるような進め方の工夫をしなければならないだろうと思います。
男の子がやっていたのは選択ソートでした。ソースコードは10行程度でプラグラムもそれほど難しくなく、大学生も多分理解できます。一方、後半で女の子がやっていた方法はクイックソートで、こちらはプログラムで書くと画面いっぱいになるほど複雑です。
女の子のやり方は賢くて、天秤の黄色の方に入れたおもり1個は固定で動かさない。そして、赤に入れたおもりが、黄色よりも重いか軽いかで分類しています。そして、最初に黄色に入れたものを真ん中に置いて、それより重かったグループと軽かったグループの中で順序を決めていっています。
最終的に比較した回数を比べると、男の子は55回、女の子は27回という違いが出ます。この数のおもりのときに効率が2倍違う、ということがわかります。
このビデオの例のように、「アルゴリズムを理解させるための教材や教え方」と、「アルゴリズムをプログラムで表す」ということは分けて考えたほうがよいと思います。今、世の中の教科書やネットに載っていること、あるいは大学や工業高校の先生が授業で教えているのは、「効率を考えたコーディングのためのソースコード」の書き方です。しかし、今後中学校や高校でアルゴリズムを教えるのであれば、「アルゴリズムの理解を目的にしたソースコード」を示す必要があると思います。ただし、そういったものは多分まだないので、ここにいる私たちが協力して作りましょう、と申し上げたいと思います。
データベースや通信のプログラムを扱う際に…
先ほどの、古典的なデータ構造を崩したいというお話の続きになりますが、データ構造を学ぶなら、やはり2次元配列はやっておきたい。しかし、「文字型の2次元配列には文字しか入れられない」し、「数値型の2次元配列には数値しか入れられない」ので、それでは使いみちが限られてしまいます。やはり配列とは違うデータ構造を使って、データベース的なデータ操作を扱わせてみたいところです。
先ほど小学校のプログラミングでご紹介したドリトルには、データをデータベースのように扱って、データベース演算ができ、さらにそれを統計処理してグラフにする、ということもできる機能があります。これを使うと、けっこう難しい処理も、青字の部分のようにコードで書くとそれほど難しくありません。確かに、慣れればエクセルの方が速いですが、「このボタンを押して、ここでメニューを選んで」…とわけもわからないままやっているよりは、プログラムで書いた方が速く、生徒の理解も良い、という成果が、使ってみた高校でも出てきています。
また、先ほど中学校の技術科で通信のあるプログラムが必修になるという話がありました。今、中学校の技術家庭科の教科書は3社が出していますが、教科書の事例集の言語にはScratchとドリトルとなでしこの三つが出ています。
ただ、プログラム名は出ていても考え方のモデルがあまり説明されていません。
ですから、双方向通信をWebのようにクライアント・サーバーのモデルでいくのか、Scratchのようなメッセージ通信のモデルでいくのか、あるいはドリトルのように共有メモリのモデルでいくのかということを、子どもの発達段階で何歳くらいならどこが理解できる、ということと合わせて検証することも重要ではないかと思っています。
手順を表すためのアクティビティ図ももっと易しくならないか
もう一つ、手順をどのように表すかという問題です。単独のプログラムではなくて「プログラム同士が」、あるいは「人とプログラムが」通信をするというやりとりがあるプログラムは、やりとりと処理を同時に表すことが非常に難しく、そこを中学生にわかるレベルでどのようにわかりやすく書いて伝えていくということが、非常に重要になってくると思います。
中教審などの議論の中で、フローチャートは処理を書けるがやりとりは書けない、シーケンス図はやりとりは書けるが処理は書けない、ではアクティビティ図はどうだろう、という議論があって、指導要領解説に入ったと思いますが、やはり中学生にアクティビティ図をそのまま教えるのは難しいように感じています。
そこで、教育用に簡略化したアクティビティ図を検討してはどうかと提案しています。こちらのスライドにあるのは、お客さんと自動販売機のやり取りを表したものです。基本的には順次だけで分岐や反復を使わずに上から下に処理が流れていき、処理の間でやり取りする横の情報に注目するものです。システム全体の設計はこの図で行い、個々の処理の実装はフローチャートなどで詳細設計すると、理解がしやすくなると思います。
もう一つ、最近始めたことをご紹介します。大学入学共通テストに情報Ⅰが入ってプログラミングが出題されるときに使える仮想プログラミング言語について考えています。入試や資格試験用の言語としては、センター試験の情報関係基礎で使われているDNCLや、処理系のPENがありますが、アルゴリズム記述を想定して、ブラウザで動くDNCLの処理系「どんくり」を作ってみました。
どんくりはサイトで公開していますので、ぜひ検索してご覧ください。作ってみてわかったのは、左側のDNCLのような日本語のプログラミング言語は、読むのはとても易しいのですが、カンマをどこに入れるかなど、書くのはけっこう面倒でした。
そこで「どんくり」では、左側のようにDNCLで書いたプログラムと右側のC言語風のプログラムをボタンで相互に変換して実行できるようにしてみました。日本語プログラムにもC言語の基礎にも使えるように思います。
学校教育でのプログラミングのための教材や環境作りを充実させよう
今日のまとめがこちらになります。実はコンピュータ教育、特にプログラミングの理解に関しては、日本だけでなく、世界でも意外と研究が進んでいません。今からでもやらなければならないことが、まだ山ほどあります。今までの知見を集めたり、新しい教育法や教育ツールを考えたり、ということがまだできるのではないかと思います。
ですから、大学の情報系の先生方には、ぜひ今までのお知恵をいただきたい。そして一緒にツール作って教材化していきましょう。高校の先生、教育委員会の指導主事の方、教科書関係の方々につきましては、すでに新しい学習指導要領に向けて作業されていると思いますが、今日お話ししたように、昔の考え方のプログラムと、今の考え方のプログラムや教育用のプログラムは考え方が違います。そこをうまく使っていくと、「これ無理だろう」と思われていた学習活動が可能になってきますので、ぜひその辺りも情報交換させていただければと思います。
[質疑応答]
Q1高校教員:新しい学習指導要領では、中学校の技術科でネットワークを利用した双方向性のあるコンテンツのプログラミングを学ぶ前後に、セキュリティやデバッグを学ぶことになっているのですが、その2点をどのように盛り込むか、何かアイデアがあったら教えていただきたいと思います。
A1兼宗先生:セキュリティに関しては、ドリトルでもチャットのプログラムでチャットのプログラムを作る時にも取り入れています。1対1のチャットであれば、自分のところに来たメッセージは相手のものだとわかりますが、グループチャットになると、メッセージの前にその人の名前を書いておかないと誰が書いたかわからなくなるため、ソースコードに名前を入れて、メッセージの前に付ける仕組みを使います。
そのとき、中学生くらいですといたずら心が旺盛で、わざと友達の名前を書いていたずらなメッセージを送るようなことが授業で起こります。それを先生方がうまくつかまえて、「今日こんなことあったよね。どうしたら防げたかな」と問いかけることで、パスワードや認証の必要性に気づかせる授業が考えられます。
セキュリティは奥深いものですが、先生が一方的に注意点を話すだけではお説教にしかなりません。ですから、このような害のない小さな事件を教室の中で起こして、その場で子どもたちに解決策を考えさせるのは有効ではないかと感じています。
デバッグに関しては、ドリトルを例にあげれば、自分でコードを打つので、おのずとデバッグっの行為は入ってきます。ブロックを並べる形の言語だと構文エラーは起きないため、意味的なエラーのデバッグということになると思います。
Q2大学教員:アルゴリズムを教えるときに、高校の新しい学習指導要領の中でアルゴリズムに使える時間は相当限られていますから、アルゴリズム自体を教えるというよりも、良いアルゴリズムを使うと手順が良くなるとか、そういうことを教えた方がよいような気もするのですが、その辺りはいかがでしょうか。
A2兼宗先生:私も全くそのとおりだと思います。例えば授業でプログラムを書かせるときに、「ひたすら長いプログラムを書く」形もあるとは思うのですが、例えばソートなどのように、「良いアルゴリズムを使うと、たった10行のプログラムであっても、10000行のデータをソートできる」といったコンピュータのすごさが伝わるような学習も必要なように思います。
Q3大学教員:まずコメントが一つありまして、先ほどセキュリティを知るというお話がありましたが、私自身、初等・中等教育でのセキュリティでは、認証と匿名性というのが子どもたちにとって一番身近なテーマであるので、そこがうまく教えられればよいという気がしておりますので、先生がおっしゃったような、チャットの認証というのはいい例で、あともう少し幾つかバリエーションがあればなというふうに感じました。
先生からお話があった、配列にインデックスを付けるのやめてはどうか、というお話ですが、私自身が工学屋なので、やはりインデックスは付いていてほしいのですね。そうしないと、後ろにつなげるときにつらいのではないかと思ってしまいます。多分、高校の数学でベクトルは数学Cに入って、全員必修でなくなってしまうという事情もあると思うのですが、後ろにつなげるためには、まだインデックスを捨てたくないなという、気持ちがあるのですが、いかがでしょうか。
A3兼宗先生:私も大学ではインデックスで教えていますので、その点は同感です。ただ、先ほどもお話があったように、アルゴリズムを情報Ⅰで教えられる時間は50分の授業で2回から3回くらいしかない可能性があります。その中で、本質は伝えるけれども、省けるところはとにかく極力省きたい、というのが本音です。
そこで「インデックスを使わずにプログラムを簡潔にできるか」などを考えているわけですが、挿入ソートであれば「どこに挿入するか」を指定する必要がありますので、インデックスを使ったほうがわかりやすいアルゴリズムもあると思います。あと、先ほど天秤を使った分銅の並べ替えで出てきたクイックソートでは「左右に分けるときに2つの配列を用意している」からわかりやすくなっていますので、「配列を1個だけを使う」といった従来の制約を外すことも有効と考えています。
Q4大学教員:最近、プログラミング言語のパラダイムが変わってきていますよね。今のコンピュータ・アーキテクチャからすると、この辺りをどのように教えたらよいのか、特にこの1、2年の悩みで、この辺りについてはどうお考えになりますか。
A4兼宗先生:全く同感です。難しいことは大学の情報系に進んだらそこでバリバリやってもらえばよいと考えると、高校では、「もっとやりたい。情報系に進みたい」という気持ちを持たせたいところです。そのためには簡潔にプログラムを書けることが大切で、「わざわざ昔ながらのインデックスを付けて嫌いにしなくてもよいのではないか」「高校では最近のイテレータやマップを扱えばよいのではないか」という議論も大切と感じているところです。
高校教科「情報」シンポジウム2018秋 講演より