「コンピュータを使わない、コンピュータとプログラミング入門」を、9月10日、山梨県大月市 市立図書館にて開催します。近郊の方の参加、見学をお待ちしています。

▼資金の使い道の箇所の960,000円: 当人の人件費:　　160,000円 x 8ヶ月: 960,000円。 ここですが、「8ヶ月」は記載ミスです。 一応「本企画の実施期間」に書いてあるとおり、本企画は6ヶ月を予定しています。 ですので、160,000円 x 6ヶ月: 960,000円です。 低学年児童のためのプログラム教育教材の作成とそのための実践：第一版 (2nd)に書いている月単価より上がっているのは、期間が短くなった分、エフォート（全業務に対しての、この業務に割り当てる労力）が上がっているためです。現在、エフォートは60%から65%を予定しています。

低学年児童のためのプログラム教育教材の作成とそのための実践：第一版 (2nd) サクセスせずに終了した、前回のクラウドファンディングです。こちらの活動報告も、ぜひご参照下さい。

「小学校段階におけるプログラミング教育の在り方について（議論の取りまとめ）」に、このような箇所がある:|　こうした人工知能が、与えられた目的の中での処理を行っている一方で、|　人間は、感性を豊かに働かせながら、どのような未来を創っていくのか[略] こうした箇所も、本能的に拒絶の対象となる。もっともこれは、この文書に限ったことではないが。 というのも、つい先日までは、「人間の特徴は知性である」と言われていた。ところが、人工知能がそれなりの性能になったとたん、「感性」にあっさり切り替えている。言うなら、好きなようにルールを変えているように思える。こんな人たちの言うことを−−この有識者会議に限らないが−−、どうやって信用すればいいのだろう。 また、こうもある:|　小学校の6年間の間に、子供たちは、幼児教育を通じて身に付けたことを生|　かしながら、身近な生活の中での豊かな体験を通じて、具体的な物事を捉|　え、次第に抽象的な思考力を高めていく。 小学生においては、抽象概念を操作する能力が個人により大きく異なる。つまり、クラスなどを単位として「次第に抽象的な思考力を高めていく」ことはできない。抽象概念を操作する能力が高い児童にとっては、つまらないことをやらされるに過ぎない。 |　また、「主体的･対話的で深い学び」の実現に資するプログラミング教育と|　することが重要であり、一人で黙々とコンピュータに向かっているだけで|　授業が終わったり、子供自身の生活や体験と切り離された抽象的な内容に終|　始したりすることがないよう、留意が必要である。 これもまた、抽象概念を操作する能力が高い児童にとっては、教員からのいやがらせにしかならない。おそらく、「なぜ理解できない児童・生徒に合わせなければならないのか？」と思うだろう。 あるいは、指導要領やアンチョコ、そして指導用ICT教材において “for” ループを使うべしとされているところで、イテレータを使ったり、 “map” と “lambda” を使う児童がいたらどうだろう。まぁ、イテレータはともかく、 “map” と “lambda” は指導用ICT教材には含まれないかもしれないが。それでも、それらを使ったとしよう。へたをすると教諭の理解を超えているかもしれない。その時、どういう指導が行なわれるだろうか。おそらくは、「こうあるべし」という指導が行なわれるだろう。児童はどう思うだろうか。やはり、「なぜ理解できない教員に合わせなければならないのか？」と思うだろう。 このような、「なぜ理解できない誰々に合わせなければならないのか？」という問題を回避するためには、教諭に相応のプログラミング能力、より正確にはコンピュータ・サイエンスの知識が要求される。だが、本来急がしかったり、昔はデモシカ先生と呼ばれたりした教諭には、それに対応する能力はない−−例外となる教諭はいるが。なんとか、対応する気になってくれれば、児童・生徒にとっても得るものは多いと思うのだが。 さて、この記事の最後になるが、同文書の最後にこのような箇所がある:|　効果的なプログラミング教育の実施が、都市部だけではなく全国で偏りな|　く可能となるよう、官民連携したコンソーシアムなどを通じて体制を整え|　ていくことが求められる。 つまり、業界団体が「こうあるべき」と示していくことになる。これは小学校などにICTが導入さた際と同じ構図であり、まともなものになる可能性は高くはない。それを避けるためには、個々の教諭がコンピュータ・サイエンスにある程度の理解を持つことが必要だ。業界団体に好きなように操られる方が楽でいいと言うなら、そして児童の不利益を無視するなら、それでもいいだろう。 だが、保護者や教諭の方々は、面倒と思わずにコンピュータ・サイエンスを勉強して欲しいと思う。kuzu/NULLでは、本企画のリターンとは別に、その要望に応える準備がある。  

たとえば、 “y = ax^2 + b” のグラフを描画するのであれば、 “x” を適当な範囲で動かせばいい。この場合、 “x” と “y” という要素が存在するのみで、データ構造らしいデータ構造は不要だ。 あるいは、円周上にいくつか場所を取り、その一つにはロボットを、残りにはバッテリーなり宝物なりを置いておき、ロボットに円に沿ってそれらを回収させるような場合、ロボットが進む向き (右に何度曲がるなど)、あるいは原点からの移動角度を持っていればいいだろう。バッテリーかなにかにぶつかったときは、環境がもっている「当たり判定を使う」としてだが。これも、向きあるいは角度だけがあればいいので、データ構造らしいデータ構造は不要だ。 もし二次関数の接線を引くということになれば、 “[[ x0, y0 ], [ x1, y1]]” くらいは必要になるだろう。あるいはロボットの集めるバッテリーや宝物に種類があるとすれば、 “[ 種類, 個数 ]” の並びくらいは必要になるだろう。 だが、よくある、「A君はimをj分で歩きます。B君はkmをl分で歩きます。B君はA君よりm分遅れて出発しました。B君がA君に追い付くのは、B君が出発してから何分後でしょう」というようなものは、プログラミング的思考に基づくなら、A君、B君については “[時刻, 時速, 距離]” くらいのものは作り計算させるのが妥当だろう。プログラムとして書かないとしてもだ。 まだ例を出していないので、わからないという人もいるだろう。適切なデータ構造を使えば、問題を解くのがとても楽になる。たとえば迷路を出してみよう: これは、「入口」、「分岐点」、「行き止まり」、「出口」に注目すると、次のように書ける。 番号はユーザが勝手につけたものだから、どこが出口なのかはすぐにわかる。この場合、⑩が出口だ。すると、⑩を木に追加した瞬間に⑩から遡っていけば、入口に到達できる。たとえて言うなら、そんな具合だ。迷路を二次元のデータとして描くよりは、問題が解き易くなる。 適切なデータ構造を用いるということは、問題を適切にモデル化することでもある。そこを無視する理由はない。無視するなら、そうとうなあれとも言えるだろう。「小学校段階におけるプログラミング教育の在り方について（議論の取りまとめ）」には、データ構造についての言及はない。つまり、よりにもよって相当なあれが集まったということだ。 保護者や教諭の方々は、面倒と思わずにコンピュータ・サイエンスを勉強して欲しいと思う。kuzu/NULLでは、本企画のリターンとは別に、その要望に応える準備がある。