プログラミング実習：考えない生徒たち：マーク式の限界
大学入試センター試験「情報関係基礎」の過去問を実際にコーディングするという記事を書いてきたが，実際に授業で実施した。言語はCindyscript。
なお，この授業はプログラミングを始めてから11コマ目である。
題材は2009年の素因数分解の問題だ。
まず，過去問を解く。想定は20分。できた者からコーディングにかかる。65分授業なので45分使うことになる。コーディングして動かしてみれば正解かどうかもわかるはずだ。問題の正解はしばらくしてから示す。
担当クラスのうち，1クラスは短縮50分授業だったため，問題は事前に配布して宿題とした。説明のあと実質は45分くらいだから，65分授業のクラスとほぼ同じだが，クラス内でのコーディングのスタートが揃う。
さらに，筆者のうっかりミスから，条件が変わり，図らずも3通りの条件での実習となった。その結果，マーク式問題の限界と思えることがらが明らかになるとともに，生徒の思考形態が普段以上に見えてきた。
(1) テキストに空欄入りのコードが書いてあり，それを実際にコーディングするとき，考えながらコーディングをするのではなく，テキストを写してから考える。
(2) アルゴリズムの説明があっても，コーディングできない。
(3) 選択肢から選ぶとき，必ずしもアルゴリズムが理解できているとは限らない。
(4) プログラミング言語の書式の違いにちゃんと対応できない。
(5) 「相談しながら進める」という学習形態は，必ずしも「考える」ことにはつながらない。
以下に，その事例を示していく。
(1) 考えながらコーディングをするのではなく，テキストを写してから考える
コーディングするにあたっては，問題の言語と実習の言語で違いがあるのでテキストを用意してある。
まず，センター試験の問題と，テキストを比べておこう。最初の，配列Yakusuの初期化だ。
・図１ 配列 Yakusu の初期化
問題に倣ってやる。
まず，Yakusu=1..100; として，リストYakusu を用意しておく。
「i を２から100まで1ずつ増やしながら」は repeat() を使えばよい。
繰り返しは，「２から」なので，repeat の start オプションを使って
repeat(回数,i,start->2,
とする。回数は何回にすればよいかを考え，次を完成しなさい。
1: //HRNO 氏名
2: Yakusu=1..100; // リスト Yakusu を用意
3: repeat( ,i,start->2, // 回数を入れる
4: Yakusu_i=0;
5: );
パソコン室では教師機から生徒機をモニタできるので，進行状況をモニタしてみた。想定される活動は，問題文の
繰り返しは，「２から」なので，repeat の start オプションを使って
repeat(回数,i,start->2,
とする。
を読んで繰り返しをする回数を考え，
Yakusu=1..100;
repeat(99 ,i,start->2, と書き進めることだ。
「2から100まで1つずつ」なら，「2から始めて（start->2）99回」くらいは小学生でもわかりそうなことだ。(repeat の増分は初期設定で1）
ところが，回数を入れず
Yakusu=1..100;
repeat( ,i,start->2,
Yakusu_i=0;
);まで書いている者が多数いる。さらにその先まで書いている者もいる。
つまり，テキストに書いてあるものをただ写しているだけで，何も考えていないのである。
(2) アルゴリズムの説明があっても，コーディングできない
問題は，素数の判別表を使って，k=100 を素因数分解するプログラムである。判別表の意味がわかればどういう手順で素因数分解ができるかがわかるはずだ。その方法も書いてある。
まず，その判別表を作っていく。判別表とはつぎのものだ。番号がそのまま100までの整数を表す。値ははじめはすべて0。まず2の倍数のところに「2」を書き込む。次に，3の倍数のところに「3」を書き込む。値が0のところは，ある数の倍数ではないものだ。したがって，値が0であれば，その倍数のところに値を書き込み，そうでなければスキップする。すると，次の4は飛ばして5にいくことになる。このようにして，次の表ができる。
100の値が5になっているのは，「素数5の倍数」として5が入ったものだ。100の約数のうち，5より大きい10や20などは素数ではないので，「100の約数のうち最大の素数」ということになる。このことも，次のように本文の問題中で問う形で書かれている。「ス」のところだ。
テキストには次のように書いてある。
21: k=100;
22: while(セ,
23: print(Yakusu_k);
24: k= ソ ;
25: );
選択肢は次のページにある。ところが，次のページにある設問を略したので，選択肢ごと削除してしまった。これが前述のうっかりミスである。
最初にやったクラスAからは，何も質問が出なかった。
次にやったクラスBからは，「選択肢がありません」という質問が出た。選択肢を全部板書するのが結構大変なので，問題の不備として，回答欄に入れるべきコードをそのまま板書した。セ が k>0，ソが k/Yakusu[k] である。つまり答えをそのまま示した。
その後にやった50分のクラスCには欠落したページを印刷して配布した。
これで，条件の異なる3つのクラスになった。
A : 選択肢がなく，アルゴリズムを考えてコーディングする。
B : 解答が示されている。
C : 選択肢が示されている。
その結果がどうだったか。
B，Cのクラスには大きな違いはなかったが，Aクラスはほとんどできていなかった。正答者／提出者は次の通りである。保存時のトラブルなどにより提出していない生徒が数名いるので，分母が少なくなっている。
A：5／30 B：21／34 C：19／34
では，B,Cクラスにあまり違いがないということをどう考えるか。「選択肢」というちょっとしたヒントがあればできる，ということだろうか。
(3) 選択肢から選ぶとき，必ずしもアルゴリズムが理解できているとは限らない
B,CクラスとAクラスの違い。選択肢があり，そこから選ぶことができればコーディングできた。しかし，選択肢がなければコーディングができない。それにしては，その差が大きすぎないか。
Bクラスは正解が与えられている。Cクラスは，正解を選択肢から選ぶ。
では，なぜ選択肢から選べるのか。選択肢は次のようになっている。問題部分も再掲するので比べてみよう。
セは，「商が1になるまで」だから，「1」がある0番を選べばよい。ソは，「素数で割っていけばよい」だから，3番に決まる。
つまり，ちゃんとアルゴリズムがわかっていなくても選べてしまうのだ。
どのクラスでもアルゴリズムをちゃんと理解した生徒は，実は少ないのではないか。Aクラスは選択肢がないから書けなかった。Cクラスは選択肢があって，わかっていなくても選べたので書けた。ということではないか。
というのは，全体がちゃんと書けた生徒の数がCクラスはBクラスより少ないのである。これは，あとの(5)で示す。
(4) プログラミング言語の書式の違いにちゃんと対応できない
問題を解くにあたって，センター試験のコードと，授業の CindyScript とのコードの違いを次のように説明している。（口頭ではなく問題文に記述）
・配列はCindyScriptではリストに相当する。n番目の要素を表すのに「Yakusu_n」ではなく，「Yakusu[n]」と表されている。
したがって，Yakusu[k] は，Yakusu_k としてコーディングしなければならない。したがって，[ ソ ] には k/Yakusu_k がはいる。ところが，これを生徒は，問題のコードのまま k/Yakusu[k] と書いているのである。直前に print(Yakusu_k); があるにもかかわらずだ。
その人数は次の通り。（Aはほとんどできていないので除外）
B：11 C：6
選択肢から正解を選ぶことはできても，意味がわかって選べたわけではないので，実際のプログラミング言語でコーディングするとできないのだ。
(5) 「相談しながら進める」という学習形態は，必ずしも「考える」ことにはつながらない。
(1) に書いた，繰り返しの回数の件を再度とりあげる。
「i を2から100まで1ずつ増やしながら」を「i を2から始めて99回繰り返す」に変えることだ。
（再掲）
3: repeat( ,i,start->2, // 回数を入れる
4: Yakusu_i=0;
5: );
2から100までだから99回。では，この99回はちゃんと数えられたのか。99にできた生徒の数は次の通り。
A：22／30 B：32／34 C：12／34
Cクラスが奇妙に少ない。実習は相談しながらやっていいので，正解もしくは不正解がそのまま伝播している可能性があるのだ。間違いで多いのは98。これを書いた者を震源地として，無批判に写した可能性がある。Cクラスは100としたものが結構いた。ちゃんと考えていないのである。
もうひとつは「かかった時間」。コーディングの時間は45分。行数は26行。文字数では320文字程度。空欄はもとの問題と同じで6箇所だけである。
問題を解くのに30分かかっても，コーディングの時間は30分はある。Cクラスはそろって45分だ。（ちゃんと宿題をやってあれば，の話。そこはチェックしなかった）この分量を30分ないし45分でできないのだ。
また，途中で正解を示したが，それからでも15分ある。15分あれば修正できそうなものだ。
正解できた（すべて正しくコーディングできた）生徒数は次の通り。
A：4／30 B：18／34 C：4／34
問題を解いて，ちゃんと理解ができたならこんなことにはならないだろう。ほとんどが示されているにも関わらずである。正解を告げても同じこと。
最初に述べた通り，テキストに書かれているコードを，ただ写しているだけで，意味を考えながら書いているわけではない。相談して，誰かのものを無批判にコピーしている。「意味を考えながら書いているわけではない」ということは，図らずも，選択肢のページを渡し忘れたAクラスの出来が如実に示している。
考えない生徒をふるいにかけるのに，マーク式は限界がある
このことは多くのことを示唆しているだろう。
(1) マーク式の問題ができてもわかったことにはならない。
(2) 理解度を測るのであれば，わかっていないと選べないような選択肢にする必要がある。
(3) アルゴリズムを示してもコーディングができるわけではない。
(4) プログラミング言語の違いは，簡単なものでも移植できるとは限らない。
たとえば，配列の [k] とリストの _k の違い，繰り返しの「から，まで」と「回数」の違い。
(5) プログラミングの実習では，穴埋めから入るとしても，徐々に空欄を増やして，考えながら書かせるような教材を作っていく必要がある。
(6) 紙の上で解かせるだけでなく，実際にコーディングさせないと理解度は測れない。
(7) 相談しながら進める，という形態（今，さかんなグループ学習）が，思考力を高めることにはつながっていない。
(1)(6) は，教科「情報」に限らず，マーク式試験の限界だと言える。
(4) は，授業でVBA，Scratch，ドリトルでやっていると若干不利になるだろう。教育用には優れているCindyscriptも，リストのインデックスが1からなので，ここで外れる。共通テストの試作問題はインデックスが0からだ。
すると，進学校ならPython か JavaScript ということになる。（Julia という話もあるが）。
(3)(4)(6) は，学習指導要領に書かれた，「アルゴリズムやプログラムの記述方法の習得が目的にならないよう取扱いに配慮する。」で，本当にいいのか，ということにつながる。コーディングできないということはアルゴリズムが本当には理解できていないということではないのか，ということだ。「習得が目的」ではないにせよ，ある程度習得しなければ，考えたアルゴリズムが正しいかどうかの検証ができないではないか。
(5) (7) は授業の進め方，教材の作り方，つまりは教材研究が重要になるということだ。
来年，2021年度は移行期間である。この移行期間のうちに，現行の「社会と情報」「情報の科学」になくても，プログラミングをできるだけ取り入れていくのが望ましい。たとえば，初めの方にある「情報のディジタル化」で，文字コード，RGB コードなどを扱うときにも，プログラミングが使える。1，2年をかけて，教える教員の方のスキルを高める必要があるのだ。