プログラミングを子どもたちと学んでいく上で、必ずしも、すんなり行くわけではない。どんなところに躓きやすいのか、ポイントを４つ挙げてみた。

１．【キーボードでの入力（コンピュータとの対話）】

テキストプログラミングをしていく上で、まず、子どもたちが最もはじめに遭遇するハードルは「キーボードでの入力」である。

初めて学ぶ人の気持ちになって考えてみよう

そもそも、「半角」と「全角」の区別がつかない。そして、「コロン（：）とセミコロン（；）の違いなど、記号の使い方」が不規則で、見分けがつきづらい。「ピリオド（．）で文字をつなぐのか、スペースで文字をつなぐのか」両方の場合があって混乱する。

など、普段プログラマーが無意識のうちに使っていて、顕在化していない「暗黙のルール」に馴れるところから子どもたちのプログラミング学習の旅は始まるのだ。

また、そもそも、特に小学校１年生〜２年生くらいでは「ローマ字」自体を覚えていない場合が多く、さらに「日本語」を「ローマ字」に変換することが難しい。

様々な点において「キーボード」での入力はハードルとなるため入力方法を学ぶところからプログラミングの学びを始めなければならない。これはブロックプログラミングにおいても同様で、「数字を入れる」ためにiPadでは「数字モードに変更するために幾つか手順が必要」だったりするため、逃れることはできない。

２．【動きとプログラムの紐づけ（記号接地と構成）】

プログラムに書かれていることが、どんなことを意味しているかを理解することが次のハードルである。認知心理学の分野や人工知能の分野では「記号接地問題」として有名なトピックであり、赤ちゃんがなぜりんごを「りんご」という言葉（音声）と紐づけられるのかという問題は古くから研究されている。

プログラミングにおいてはこの「記号接地問題」が「キーボード入力」のハードルの次にやってくる。一つ一つのブロックに関しては簡単に理解をすることができるものの、作りたいものの目標なしに、ランダムにどんどんブロックを増やしていって組み合わせると「なにか動くもの」はできるのだが、意図したものはできない。

中身をブラックボックスのままにしておくのではなく、ブロックやコードの意図的な組み合わせをつくるような学びにするにはどうすればよいのだろうか？

初めて学ぶ人の気持ちになって考えてみよう

一つ一つの組み合わせを考えながらプログラムを組むことはあまりに着実で面倒だ。ちゃっとつくっちゃったほうが楽だ。

一つ一つの組み合わせを考えるためには、全体像を考えながら前後との関係を含めて考え、ブロックを選び出すため「認知的負荷」が明らかに高い。

この課題を解決する手段として「全体像を紙に書いて明確化させておく」というプロセスをはじめに子どもたちと行うことで、認知的負荷を下げることができる。紙に書いてあることで記憶をして思い出す作業を何度もせずとも一目瞭然だからだ。

例えば、ゲームを作る、お話を作るという「プロジェクト」の文脈をつくることで、子どもたちが「自分の意図したものを常に参照しながらワンステップずつつくる」ための条件をつくることができる。

３．【ブロックのかたまりを見つける（抽象化）】

ブロックの組み合わせによって「つくりたいものを創り出す」ことはできるようになった。その次にやってくるのはブロックの抽象化だ。

算数でよくあるような問題だが、「間に存在する１〜２ステップをすっ飛ばした答えを求める問題」である。例えば、「繰り返しを使ってこの１辺１０歩の正方形を書こう」という問題と同じだ。

初めて学ぶ人の気持ちになって考えてみよう

いままでのプログラムは簡単だったから、こんども同じやり方でやればすぐにプログラムは動くんじゃないか。

詰まってしまうのは、「簡単に答えが出る」と思っている子だ。つまり、スタートからゴールが一直線ですぐに答えが出ると思っていることで、解決策への具体的な方策が浮かばず、そのまま思考停止してしまう。

繰り返しをつかって四角形を描くには、「１０歩の直線を書いて90度曲がる」という操作を四回繰り返す必要がある。簡単に描くと下記のようになる。

# Codemonkeyで10歩の正方形を描く方法
4.times ->
    step 10
    turn 90

しかし、ここにたどり着くまでには、「.times ->」というループの使い方と、「何回繰り返すか」を認識することと、「何を繰り返すか」がわかっている必要がある。

ループ関数はブロックの塊を発見することがいちばん大切なステップだ。こうなったときには「急がば回れ」ループを使わずに描く方法を試してから、ループをつくる方法を活用するように、間にワンステップを挟むことで理解が深まる。

# ループ無しで一度書いてみる。
step 10
turn 90
step 10
turn 90
step 10
turn 90
step 10
turn 90

ループなしを眺めると同じパターンが繰り返されていることが見えてくる。そこで「ループ」の使い方を伝えれば子どもは自然にループを使って書けるようになる。こういったことを繰り返しているうちに、頭の中でパターンを発見することがだんだんできるようになってくるだろう。

４．【場合分けを考える（条件分岐）】

場合分けを考える難しさは抽象化の末にやってくる。抽象化が帰納的推論であるならば、場合分けは演繹的推論だ。

例えば、インベーダーゲームをつくることを考えてみよう。勝利条件と敗北条件を考える時、ヌケモレが出てしまうことがある。

初めて学ぶ人の気持ちになって考えてみよう。

勝つためには、敵キャラをすべてたおしたとき、負けるためには、敵キャラからのビームを受けた時で設定しよう。

勝利条件と敗北条件を考える必要があるのは当然のことながら、実は他の場合があることを忘れてはいけない。敵キャラに全く弾が当たらず、逆に敵キャラからのビームをまったく受けずにいたらどうなるだろうか。だんだん近づいてきて通り過ぎるが、終わらない。

第三の条件を忘れてしまっているとき、どのようにその必要性や解決策を導き出せるようになるかといえば、２つの方法があり、「実際にゲームを作ってみて動きを確かめる」ことか、「プログラムの設計図（HCPチャートやフローチャート）を書く」ことか、どちらかを行っていけばよい。

試行錯誤を繰り返していくうちに「思い浮かばなかったヌケ」に気づくことができるようになるし、その末に待ち受けている大きなプロジェクトでは、「ヌケを作らない工夫」として設計図を書くようになるだろう。

以上のようによく子どもたちが躓くポイントを見てきた。こういったチェックポイントを克服していくことで子どもたちのプログラミングスキルは伸びていく。これが、学びを設計する上でも重要な４つのポイントだ。