Check our Terms and Privacy Policy.

低学年児童のためのプログラム教育教材の作成とそのための実践:第一版 (4th)

プログラミングという概念は、手続きを書くことと同義ではありません。 本企画では、主に低学年児童向けにプログラムそのものの概念の把握から、プログラミングの考え方の多様性とデータ構造の重要さを理解できるような講習を行ない、かつ教材および資料の作成を目指します。

現在の支援総額

0

0%

目標金額は1,950,000円

支援者数

0

募集終了まで残り

終了

このプロジェクトは、2017/10/06に募集を開始し、 2017/10/30に募集を終了しました

このプロジェクトを見た人はこちらもチェックしています

低学年児童のためのプログラム教育教材の作成とそのための実践:第一版 (4th)

現在の支援総額

0

0%達成

終了

目標金額1,950,000

支援者数0

このプロジェクトは、2017/10/06に募集を開始し、 2017/10/30に募集を終了しました

プログラミングという概念は、手続きを書くことと同義ではありません。 本企画では、主に低学年児童向けにプログラムそのものの概念の把握から、プログラミングの考え方の多様性とデータ構造の重要さを理解できるような講習を行ない、かつ教材および資料の作成を目指します。

このプロジェクトを見た人はこちらもチェックしています

▼ご挨拶

2020年度から小学校からのプログラミング教育の必修化が行なわれることになりました。
ですが、現状において用いられているプログラミング言語やプログラミング環境、そして教材には、一部を除いて不安があります。
それは、主に手続き型を前提としたものであるからです。

手続き型、関数型、論理型、およびオブジェクト指向 (クラス・ベース、およびプロトタイプ・ベース) のプログラミング言語を使用してきた経験から、手続き型に限らない、プログラミングについての基礎的な部分の理解を低学年児童 (あるいは児童・生徒) に促す教材を用意したいと考えています。

ご支援をいただきたい方々として想定しているのは、次のような方々です:
- 低学年児童 (あるいは児童・生徒) の保護者
- 教諭
- 市や県の対応会議、あるいはそのメンバー
- プログラミングに造詣のある方
- プログラミンング教育に興味のある方
- そしてもちろん、そのほかの方々

もちろん、教材の本来の対象は低学年児童 (あるいは児童・生徒) ですが、ご支援のお支払の関係から、ご支援いただきたい方々という枠からは外れるものとします。

本クラウド・ファンディングが成立した場合、本企画の実施期間は、ご支援がこちらに届くのに先行して2017年11月から、2018年4月までを予定しています。

なお、ご支援の受付期間内に、内容についてのなんらかのご質問がある場合、活動報告へのコメントとしていただければと思います。
随時、あるいは個別に回答させていただきます。

▼この企画で実現したいこと

本企画では、実際に低学年児童 (あるいは児童・生徒) 向けの講習を行ない、そのフィードバックを反映した低学年児童 (あるいは児童・生徒) 向け教材、指導用教材、および各回の講習後のミーティングの内容などを含んだ資料の作成を目指します。
なお、リターンとしての指導用の教材は、低学年児童 (あるいは児童・生徒) 向け教材、資料のいずれにも含まれます。

本企画に先行するものとしては、『ルビィの冒険 こんにちは! プログラミング』 〔リンダ・リウカス著,鳥井 雪訳,翔泳社,2016年.〕という書籍があります。
前半は物語形式で、ところどころ知っているに人はクスリと笑えるネタが挟まっています。
後半がプログラミングの入門という内容で、解説と課題があります。
ですが、それらの解説や課題は児童を意識したものではあっても、その構成は、プログラミングの入門についての他の書籍とおおむね似たものになっています。
ただし、あまり具体的な内容ではないとも言えるかと思います。

対して、『コンピュータ使わない情報教育 アンプラグドコンピュータサイエンス』 〔Tim Bell, Ian H. Witten and Mike Fellows 著, 兼宗 進 監訳, イーテキスト研究所, 2007.〕 という書籍もあり、10個ほどの具体的かつ体験的な課題が収められています。目的は児童・生徒のためのコンピュータ・サイエンスについての教育ですが、対象はむしろ教員であり、指導の際のネタ本という側面が強い書籍です。また、それぞれの課題の背景には、コンピュータ・サイエンスの比較的高度な内容が存在している点も特徴でしょう。

ところで、「ご挨拶」にて、現状において主に手続き型の言語や環境を前提にしていることに不安がある旨を書きました。
この点については、Viscuitという言語−−あるいは環境−−を用いている教室などもすでに存在します。
ですが、Viscuitという言語−−あるいは環境−−の性格上、教室においても適切な指導や活用が行なわれているのかは疑問があります。

あるいは、現在でもメジャーな言語は手続き型であろうと思います。
であるなら、その部分を不安視する必要はないという考えもあるかと思います。
しかし、現在メジャーな言語においては、元はLisp−−あるいは関数型言語−−におけるものであった “lambda” (無名関数) や “map” などが言語仕様に組み込まれるなど、従来の−−あるいは古い−−言語の型を超えた実装が行なわれています。
具体的に “lambda” (無名関数) や “map” を使えるようになることは目指しませんが、低学年児童 (あるいは児童・生徒) が、プログラミングについて複数の概念が存在することを理解することは無駄ではないでしょう。
あるいは強く言うなら、プログラミングとは手続き型の方法のことであると低学年児童 (あるいは児童・生徒) が思い込んでしまうことは、あるいはそのように理解するように強いられることは、 従来の−−あるいは古い−−言語の型を超えた実装が行なわれている現在、適切あるいは妥当な教育方針ではないと考えます。

プログラミングとは手続き型のことではないという点について別の言い方をするなら、プログラムとはデータ構造とアルゴリズムのことであると言えるかもしれません (『アルゴリズム+データ構造=プログラム』 〔N. ヴィルト, 日本コンピュータ協会〕)。
データ構造とアルゴリズムは密接に関係しており、片方がもう片方を決めると言ってもいいでしょう。
ですが、アルゴリズムという言葉に注目すると、それは手続き型を連想させるかもしれません。
これらを鑑みて、本企画では、アルゴリズムと同様にデータ構造−−つまり、データをどのように表現するか−−に重点を置いたものを目指したいと考えています。

手続き型に限らない簡単な例や、このようなとらえ方もあるという例は、後ほど活動報告にて紹介したいと思います。

本企画では、パズルやゲーム−−特に目的とルールが明確なパズルやゲーム−−を複数用い、アンプラグドな環境において、その解き方にいくつかの考え方があることを−−そしてそのためには、いくつかのデータの表わし方があることを−−、低学年児童 (あるいは児童・生徒) 自身が発見的に、あるいは体験に基いて理解できる教材の作成を目指します。
付け加えるなら、『コンピュータ使わない情報教育』のような内容を、『ルビィのぼうけん』のように児童・生徒向けに、という内容を実現したいと考えています。
複数のパズルやゲームを用いるのは、低学年児童 (あるいは児童・生徒) が「繰り返すこと」、「飽きないようにすること」とともに、教材における「抜けや落ち」を回避するためでもあります。
教材に反映するパズルやゲームは、本企画で実施する講習を通して決めていきたいと考えています。

本企画では、実際に低学年児童 (あるいは児童・生徒) を対象とした講習を行ない、その成果物として低学年児童 (あるいは児童・生徒) 向けの教材と、指導用の教材、および各回の講習後に行なうミーティングなどをもとにした資料を作成することを目指します。
なお、指導用の教材は、低学年児童 (あるいは児童・生徒)向けの教材にも、資料にも含める構成にしようと考えています。
指導用の教材を資料にも含めることについてはリターンとも関係しており、リターンとして資料を選んでいただいた場合でも、教材についてある程度の予想あるいは理解が可能であるようにしたいと考えたためです。

本企画が実行できた場合、第二版、第三版へと、成果をフィードバックしていく予定です。
第二版、第三版においては、タブレットやPCを用いたプラグドな環境も検討していきたいと考えています。
現在、一先ず第三版までを想定しています。
また、第二版、第三版と、教材および資料の配布数も増やしていきたいと考えています。
その場合、ご支援の単価 (?) は下げていきたいと考えています。

▼教材の想定している概要:

●はじめに:
  教本の概要や、教材の考え方を紹介する。

●第一章: プログラムに触れてみよう(仮題)
  トランプあるいは自作カードを用い、数当てゲームを試してみる。
  ここでは具体的な話には入らず、低学年児童 (あるいは児童・生徒) が
  「何かをした」ということで〆める。

●第二章: プログラムってなんだろう?
  プログラムとはなんなのか、どういうものなのかの定義の概略をいくつか紹介する

●第三章: 数当てゲーム
  第一章の数当てゲームを再び題材にして、
  どうやったかを書き出し、自分自身で何回か試してみる。
  また、自分が書き出したやりかたを、他の人に試してもらう。
  うまくいく時、うまくいかない時を確認し、書き出したやりかたを修正し、
  いつもうまくいくやり方を見付ける。
  また、自分が考えたやりかたと、他の人のやりかたとの違いを理解する。
  ここで、木構造を紹介する。
  手続き型以外の考え方を紹介する。

●第四章: 並ベ換えてみよう(仮題)
  ソートを題材にし、第一章、第三章の数当てゲームと同様に、
  問題を解いてみる。
  また、ここでは、配列、および木構造を紹介する。

●第五章: 迷路を解いてみよう(仮題)
  迷路を題材にし、第三章などと同様に、問題を解いてみる。
  また、ここでは、配列、および木構造グラフを紹介する。

●第六章: パズルを解いてみよう(仮題)
  パズルを題材にしたもので第三章と同様のことがらを試す。

●第七章: 動くものには状態がある(仮題)
  webページやリモコンなどを題材に、ここではオートマトンを紹介する。

●おわりに
  第一章から第七章までの内容をまとめる。

想定している内容は上記のとおりですが、大きく変更される可能性があります。

▼資金の使い道

60,000円: 会場費 (計10回を予定)。

60,000円: 講習の広告費など。

60,000円: 小道具の準備費:
  トランプ、パズル、ゲームなど。いずれも教材用:
    1,000円 x 10個 (講習の参加人数) x
      5種類 (講習に用いるパズルやゲームの種類)。
  5種類のパズルやゲームから3個を目途に、教材に反映するものを選びます。

100,000円: 小道具制作費:
  小道具の利便性のための加工、
  講習で用いるデモや説明用の小道具の制作、
  その他の独自の小道具の制作など。
  外注の検討を含む。

50,000円: 参考資料購入費。

560,000円: 協力者の人件費:
  開場設営・受付の手伝い、講習のアシスタント、
    事前ミーティング、事後ミーティング:
    1,500円/時 x 8時間 x 3人 x 10回 = 360,000円。
  講習の記録の整理および分析の手伝い: 100,000円:
    次の講習に向けての、教材と資料の下読みを含む。
    教材や資料に使うイラストの購入や外注の検討を含む。
  教材と資料の作成の手伝い: 100,000円:
    教材と資料の下読みを含む。
    教材や資料に使うイラストの購入や外注の検討を含む。

960,000円: 当人の人件費:
  160,000円 x 8ヶ月: 960,000円。

100,000円: 雑費および予備費。

実際の金額は、上記金額からCampFireの諸手数料 (13%) を引いた、つまり0.87をかけた値になります。

▼リターンについて

本企画実施期間:2017年11月~2018年4月

本クラウド・ファンディングが成立した場合、本企画の実施期間は、ご支援がこちらに届くのに先行して、上記のように2017年11月から2018年4月を予定しています。

また、以下に示す教材、資料、ご質問への回答、ワークショップなどは、いずれもご支援いただいた方へのリターンです。

2018年5月中を目途に、教材の第一版 (指導用教材を含む) 、および/あるいは教材のもととなる記録や分析をまとめた資料 (指導用教材を含む) をお送りします。

本企画では、リターンとしての教材や資料は電子媒体のみを想定しています。
これは、印刷にかかる費用を削減するためです。
ただし、クリエイティブ・コモンズの「表示 - 非営利 - 改変禁止 4.0 国際」による制限、加えてクリエイティブ・コモンズの範疇からは外れますが、独自に「メールやクラウドを含むネットへのアップロードの禁止」という条件をつけさせていただきますので、遵守いただけるようお願いいたします。
この「メールやクラウドを含むネットへのアップロードの禁止」は、支援していただいた方が教材や資料を所有するという権利を確保するためのものです。
なお、プリント・アウトや紙媒体のコピー、またはUSBメモリなどの物理媒体でのコピーを、支援していただいた方がそれ以外の方に配布することは禁止しません。
プリント・アウトや紙媒体のコピー、またはUSBメモリなどの物理媒体でのコピーの配布は、職場などの範囲において必要かもしれないと考えています。

本企画の実施期間中は、Campfire、あるいは他のサイトにて適宜進捗などの報告を行ないます。本企画実施期間中においても、それらを参照の上、ご質問をいただければ、随時あるいは個別に回答したいと考えています。

企画の期間中、あるいは終了後において、ワークショップ、ミーティング、会議などにお呼びいただいた場合、内容に関しての講演を承ります (交通費などの実費は別途とさせていただきます)。
その際の講演時間などは、ご相談の上、決めさせていただきます。

▼最後に

需要があるのか、また短期間なので不安ですが、よろしければご支援をお願いいたします。

 

最新の活動報告

もっと見る
  • 課題の一つして考えている「数当てゲーム」についての解説を公開しました。 もっと見る

  • なぜアンプラグドなのか 正直に言えば、アンプラグドであることにこだわりがあるわけではありません。講座としては、OSのバージョンなどなど細かいことを気にするのが手間だからという程度の理由です。 「それではあんまりな理由だ」と思われるかもしれません。 そこで、すこしましな理由を挙げると、アンプラグドでかまわないからと言えるでしょう。アンプラグドな環境で試したことを、PCやタブレットでも試してみたければ、講座のあとでもできることですから。 ですので、環境が整えば、アンプラグドでない講座も検討の範囲には入っています。 なぜパズルやゲームなのか プログラミングや情報工学の教科書や課題には、たくさんのパズルやゲームが載っています。 それは、パズルやゲームが、プログラミングや情報工学の多くの問題を的確に現しているからです。問題そのものもですし、問題の解き方についてもです。 この点においては、講座がアンプラグドであることはむしろ利点でもあります。というのも、ちょっとしたバグによって混乱するような事態を避けられるからでもあります。 パズルやゲームという問題の解き方を形式的に考えたり書いたりする際には、疑似コードという方法もあります。その言語を実行する環境が存在しないプログラミング言語を使う方法です。 こちらについては、ちょっとした疑似コードの用意がありますし、必要なら疑似コードの規格も公開できるかと思います。      * * * * と言うわけで、「なぜアンプラグドなのか」については、それで困らないからです。 「なぜパズルやゲームを使うのか」については、そこにプログラミングや情報工学の重要な問題がシンプルな形で存在するからです。 もっと見る

  • プログラムとはなんなのかということについては、ヴィルトの「Algorithm + Data Structure = Program」という著書があります。ここで、「Algorithm + Data Structure」とありますが、AlgorithmとData Structureはかならずしも分離できるものではありません。また、逆に、必ずしも一体のものでもありません。ですが、片方を選ぶともう片方も決まってくるという傾向はあります。場合によっては、あるデータ構造を選ぶと計算が速くなったり、プログラムを書くのがとても楽になったりします。 このAlgorithmについては、「Algorithm = Logic + Control」とも言われます。 「Algorithm + Data Structure = Program」のほうはまだわかりやすいかと思いますが、「Algorithm = Logic + Control」のほうはわかりにくいかもしれません。 AlgorithmとData Structureの場合のように、LogicとControlもかならずしも分離できないと考えていいのではないかと思います。そうした場合、処理 (おおむね “文” とします) の並びや、入れ子が、データをどう処理するのかというLogicに相当すると考えてみます。 では、Controlはどうなのかというと、 “文” に含まれると言えば含まれますが、 “if” だとか、 “while” だとか、手続き型の言語の場合であれば順次実行あたりがおよそ相当するのではないかと思います。これらは、 “文” として書かれるので、Logicの一部とも言えるかもしれません。あるいは、 “if” などは、それ単体ではあまりどうこうということはできず、言うとすれば複合文として記述され、また実行されます。この複合文であるというところがControlの特徴かもしれません。 複合文がControlだと考えると都合がいいのが、関数呼び出しや再帰もControlであると考えやすいという点が挙げられるかもしれません。 問題は (?)、Prologですが。 P(なんとか). という事実の場合、それは単純なLogicだと考えましょう。この事実がベースにあって、 P(x) :- Q(x), R(x). というようなルールが書かれます。この場合、まず Q(x),R(x) という部分は、 Q(x) であり、かつ R(x) であるということになりますが、この Q(x),R(x) の部分は、そのままLogicだと考えていいと思います。と同時に、 Q(x) と R(x) が同時に成立しないと P(x) は成立しないというControlでもあるとも考えられるかと思います。あるいは、 Q(x);R(x) と書くと、 Q(x) か R(x) のどちらかが成立すればいというControlであるとも考えられるかと思います。ただ、ユニフィケーション自体にLogicとControlが含まれるとも考えられるので、他の言語ほどにはLogicとControlが目には見えないかもしれません。 さて、「Algorithm = Logic + Control」であるなら、「Algorithm + Data Structure = Program」は、「Logic + Control + Data Structure = Program」と言えることになります。Scratch、ScratchJrなどでは、Data Structureの部分が見えにくいように思います。 また、ScratchやScratchJrだと — あるいは他の場合も — 、プログラムが動いたからいいという立場をとるとか、そういう立場を取らざるをえないように思います (これは、もちろん指導者にもよりますが)。プログラムを書いた経験がある人ならわかると思いますが、この立場はプログラムの検証という面から見るとかなり甘いものです。というか、プログラムを開発中の仮のテストではそれでもいいとしても、そのテストで済ませるというのは、甘いというよりも危険とも言えます。 「Logic + Control + Data Structure = Program」であるとしたら、それに応じた、プログラムの設計と検証を込みでのプログラミング教育が必要ではないかと思います。 もっと見る

コメント

もっと見る

投稿するには ログイン が必要です。

プロジェクトオーナーの承認後に掲載されます。承認された内容を削除することはできません。


    同じカテゴリーの人気プロジェクト

    あなたにおすすめのプロジェクト