プログラミングせずとも"プログラミング的思考"を鍛えられるか？
※この記事は、2019/02/05に弊ブログ「Motologue」で公開した記事に加筆修正したものです。
日本においてプログラミング教育が必修化となる２０２０年を目前に、小学校では様々な取り組みが始まっています。
今回は様々な取り組みから事例紹介を織り交ぜつつ、僕自身のプログラミング学習の経験をもとに「プログラミングせずとも"プログラミング的思考"を鍛えられるか？」ということについて書きます。
結論からお伝えすると、"できなくもないが難しい"かなと。なぜこの結論に至ったか、さっそく書いていきますね。
そもそも「プログラミング的思考」とは何か？
書くキッカケになったのは、先日Twitterで見かけたこのツイート。栃木県の「プログラミング教育」の取り組みについて触れてありました。
👆のようにScratchを使った教育事例が紹介されていた模様。（リンク先のNHKのページはすでに削除されています。）
ちなみにこの「炊飯器」題材は、小学校の「家庭科」における事例です。なぜ炊飯器なのか？なぜ家庭科なのか？という文科省の狙いついては、文科省の調査官にインタビューしてる記事を見つけたので是非ご覧ください。
さて、子どもたちは「炊飯器」を使ってこんなことをします👇
児童は、水加減や浸水時間、火加減、蒸らしなどの炊飯に関する一連の手順について、コンピュータ上で並べ替えと条件設定を行います。
Scratchの画面と照らし合わせるに、紫色の手順ブロックの並べ替えと「中火」などオレンジ色の値の穴埋めを行っているということですね。調査官へのインタビュー記事を読むと、並べ替えや穴埋めをとおして「プログラミング的思考」を育成できる、とも解釈できます。
ところで「プログラミング的思考」とはなんでしょうか？
自分が意図する一連の活動を実現するために、どのような動きの組
合せが必要であり、一つ一つの動きに対応した記号を、どのように組
み合わせたらいいのか、記号の組合せをどのように改善していけば、
より意図した活動に近づくのか、といったことを論理的に考えていく力
もう少しギュッとすると「課題解決に必要な手順を抽出し、創造する思考」という感じだと思います。（佐々木の独断と偏見です🙏）
「プログラミング的思考」は「論理的思考」と「コンピューテーショナル・シンキング」を組み合わせた思考ともいわれており、先ほど「創造」という言葉を使ったのもそういう理由です。「手順」を並べ替えるだけでなく、そもそもの「手順」自体を発見できるかもとても大事なんですね。
だからこそ、"並べ替えや穴埋めをとおして「プログラミング的思考」を育成できる"はほんの一部に過ぎないと感じます。なぜなら、既に結論が出ている（手順が揃っている）ものを並べ替えるだけなら、「お米の炊き方」を知ってるか？の知識を問うてるに過ぎないからです。
「プログラミング的思考」についてこちらの記事も参考になると思います。
とはいえ、「炊飯器」事例を否定したいわけではなく。個人的には穴埋め問題も全然ありだと思ってます。ただ、子どもたちが"それ即ちプログラミング"と認識し、おもしろくない…と飽きられることは回避したいなと。
「プログラミング的思考」をどう鍛えるか？
穴埋めは理解度をはかるひとつの方法であることは間違いないですが、どうしても「暗記」になりがちなんですよね。
でも、ある意味仕方なくて。プログラミングは算数や理科みたいに「正解」がハッキリあるわけではないにも関わらず、これまで学んできた学習方法は「正解」を見つけることです。なので穴埋めを目の前にすれば「とりあえず暗記」になるのは無理もありません。
しかし、暗記だけだと特定のパターンにしか対応できないという自体が発生しやすいです。（ちなみに僕は高専のとき、プログラミングの期末テストに暗記で挑み、案の定痛い目に遭いましたとさ…）
では、プログラミング的思考はどうように鍛えていけばよいか？
まずやることは、"「正解」を見つける"という思い込みを壊すことです。
なかでも手っ取り早いのが実際に動かすことかなと。頭で考えすぎず、実際に動いた結果を見て、逆算的に理解するのがなんやかんや一番鍛えられるかなと思います。あくまで僕の実体験ベースですが。
ただ理由もきちんとあって。
プログラミングのいいところは必ず何かしらの結果が得られるとこです。エラーも結果のひとつ。この点が単なる座学と大きく違うところなんですね。であれば、それを活用する学習方法で立ち向かうほうが効率がいいんです👍
変に最初から概念ばかり説明したり、ボトムアップで知識を積み上げる形ではなく、まず動かしてみる。動かせるほうが脳もイキイキしますから🧠
やっぱりレベルが上がってくると頭だけでは理解できない処理って出てくるんですよね。まあそうですよね、コンピュータの気持ちになったことなんてないんですから（笑）
「こう書くとどう動くのかなあ？」とコンピュータの気持ちになることで「こういう動きになってるのか」と見える化して理解できますし、もう少し細かく伝えないと思い通りにならないんだなと気づくこともできます。
コンピュータの気持ちになるためにオススメなのが「フローチャートを書く」ことです。たとえば👇の事例なんかは「フローチャート」の一例です。とある目標を満たすための手順を考えるんですね。手順を考えることで「パターン」を見つけることができるようになってきます。勘所なども掴めてきます。
ただ、やっぱり「動いた結果」を見ないことにはコンピュータの気持ちに完全に寄り添うことは難しいです。これが冒頭でも伝えた"できなくもないが難しい"の最たる理由です。
フローチャート書く👉動かす👉思い通りにならない👉フローチャート見直す👉動かす👉動いた👉勘所掴む
これを繰り返すことが重要なんですね。勘所を掴むことで「推論」から「結論」を導き出すことができるようになりますし、慣れてくればフローチャートを書かなくでも、頭の中で書けるようになりますから。でも、そこには「動いた結果」がやっぱり必要なんだろうと思います。
とはいえ、頑なに「まず頭で理解したい」派がいることも事実です。
そういうときはメンターを見つけてください。メンターには、僕みたいな現役SE、講師だったり、情報系の大学生やプログラミングスクールの先生など、プログラミングに従事してる人であればあるほどいいと思います。
できるメンターは「正解」を提供するのではなく、質問者が既に持っている知識と関連付けて教えてくれるので、「頭で理解できた」気になっちゃうんですよね。なので「まず頭で理解したい」派には願ったり叶ったりです。
「わかった気にさせる」ことは「新しいものではないという認識をさせること」なんだと思います。最所さんの言葉を借りれば、キャズム超えです。
身近なもので「プログラミング的思考」してみる
気づけば3000字が近づいてきたのでそろそろまとめに入りますね。
タイトルでもあり、本記事のメインでもある「プログラミングせずとも"プログラミング的思考"を鍛えられるか？」については"できなくもないが難しい"ですが、まずやれることは推測する経験を積むことだと思います。
先に紹介した手順の並べ替えや穴埋めもそのひとつの方法であると言えると思いますが、そもそものお題（今回の場合ならお米の炊き方）から見つけてみることが何より大事なんじゃないかと。
例えば「なんで自動販売機は硬貨の種類を見分けられるのだろう？」とか。
そういう身近な出来事に疑問を持ったり、課題を発見したり、することに取り組むことで、ごくごく自然な流れで「推論」を立てられるようになり、実際に検証したい衝動に駆られ、自発的にプログラミングに取り組むようになる気がします。やはり道具なので、使いたいと思えることが一番大事です✊
＊
今後も「プログラミング教育」に関する事例や、そこに対する個人的な見解を述べた記事を書いていこうと思います💪
僕自身もキッズプログラミングを開催したり、海外のプログラミング事情を調べたりもしているので、「プロラグミング教育」についていろんな方と意見交換したいと思っています。気軽に声かけてください。Twitter DMは開放してるので、いつでもご連絡ください。
ぜひTwitterのフォローもよろしくお願いします👇
最後まで読んでいただきありがとうございました🙏
▼ キッズプロラグラミングや海外の「プログラミング教育」事情はこちら ▼
この記事が気に入ったらサポートをしてみませんか？