プログラミング学習の問題と対策

＜プログラミングの学習を始める目的＞
スクリプトにかかわらず初心者がプログラミングの勉強を始める目的は、
「もっといろんなことができるようになりたい」という理由からだ。

それに、最初は何もわからないから、
「プログラミングによって何ができるのか知りたい」ということも理由だろう。

--------------------
＜問題１：目的が失われる＞

勉強を始めると、基本的なコマンドや文法、たとえば分岐命令や変数から勉強していく。
でもこういった基本事項だけで、「プログラミングをすると言う行為」がどのように自分の仕事に役立つのかわかりにくい。

なんとなく、繰り返しの作業をやってくれたり、自動で処理できれば「便利そうだ」とは感じるが
通常のテキストには、応用例が少なく、またあったとしても習ってもいない事柄がたくさんあって、理解できない。

実際に自分の作業で、○○を出来るようにしたいと思っても、プログラムは一つ二つのコマンドでは簡潔せず、複数のコマンド、関数そして、ちゃんとした文法など、知っておくべきことがもっとたくさんある。

「自分がこうしたい」という具体的な例がすぐに思い浮かぶ人はいいが、
「プログラムにできること」がわかり、「自分の仕事」に結びつくようになるまでにやることが多すぎて、目的を見失い、興味を失ってしまう。


--------------------
＜問題２：応用力がきたえられない＞
だれがIf文をつかって「この変数の値は10です」と表示するプログラムを作りたいと思うだろうか？
そしてこの例から、何かプログラミングの可能性を感じられるだろうか？

比較演算子を使うことで、自動的に比較できるんだなとはわかるが、それをどのように応用できるかを考える前に次のステップに進み新たなことを学び始める。
多くのテキストは、その応用性をきたえることには、あまりページが割かれていない。
せいぜいそこでならったことの例が一つ二つあるぐらいだ。

このために、初級レベルの学習過程では、新しい知識をどんどん吸収することばかりに、時間が割かれ、創造力を使うチャンスがあまりなく、自分の仕事にどのように結びつけることができるかわからないまま勉強が進んでいく。

そして、ある程度知識を詰め込んだら、「では、自分でプログラム作ってみよう！」ということになる。そこまでにひとつひとつならったことをどのように応用すべきか真剣に考えて来た人ややりたいことが明確な人ならそれでいいだろう。

しかし、「プログラミングに何ができるのか知りたい」という動機で勉強しているのなら、「いきなりいわれても。。。。」となってしまう。
習ったことを自分の仕事に関係づけて、何に、どのように応用して良いかわかない。

応用力をつけるために、いままで推奨されていることは、
１）例の中にあるコマンドや、数値を少しかえて応用してみる。（応用力は、少しだけ求められる）
２）他の人のつくったプログラムを読む。（多くの場合、数ステップ上の作業であり、知らないコマンドや関数がたくさんでてきてそれを理解するのにも時間がかかる）
３）とにかく、ヘルプとにらめっこしながら、たくさんプログラムを作る。

といったことで、「即座に解決できる物ではない」というのが通説だ。


--------------------
＜プログラミング作業を分析してみた＞
プログラミングの学習を行っている間に、限界にとらわれず、想像を自由にふくらませ、応用力を高めることはできないか？

プログラミングの実際の作業は
０）アイデア
１）実作業に何がつかえるかをみつける。
２）実作業を分析し
３）アルゴリズムを考え
４）プログラミングし、（ここではコーディングのステップのこと）
５）デバッグする。
６）それを使う。
という過程を通る。


いろいろなコマンド、関数、文法を間違えることなくつかえるような細かなルールを身につけることは、実はデバッグのステップで主に必要とされることのではないかと思う。

「プログラミングで何ができるのか知りたい」という段階では、デバッグにわずらわされていると、自由に発想をふくらませることができなくなる。


「プログラミングに何ができるのか？」、「自分の仕事にどのように生かせるのか？」それらを知るには、
何かを習っている、そのときに生まれてくる発想を大切にしなくてはならない。

その段階では自信はなく、「このように使えるのではないか？」「こうできるのではないか？」というアイデアにすぎない。

それを実際に、使えるようになったときまで細かに覚えておくことは難しいし、
そのときの感情的なフィーリングは失われる。
（それを文章化することで、将来のためにそのアイデアを残しておくことはできる。）

そもそも、そのアイデアを表に出して検討しないと、「プログラミングで何ができるのか？」を知ることは出来ないと思う。

実現するには、それを実作業にあてはめ、使えるかどうか確認することが不可欠だし、それがプログラミングの応用力というものだと思う。

それには、実作業に「何がつかえるか」をみつけ、
実作業の分析をし、アルゴリズムを考える必要がある。
それは最終的には一つ一つのコマンドや関数、変数レベルにまで落とし込めるが、最初は概略でもよいと思う。

そのあとにプログラミングとデバッグの作業がくる。

プログラミングをするには、たしかにプログラミングとデバッグができなくては、ちゃんと動くプログラムは作れない。
しかしプログラムを作るために発想し、ラフなアルゴリズムを考えるという作業は、プログラミングとデバッグができなくても、可能だ。

エラーがおこるかどうかは、この時点ではあまり関係ないとも言える。

もちろん、通常はプログラミングの過程でエラーがあるなら、アルゴリズムを考えるレベルまで戻ることもあるが、ここではラフなアルゴリズムを考えるところまでのとどめる。


--------------------
＜解決策＞
どのようなことができるか考えてみた。
大切なのは、初心者レベルで
「プログラムに何ができるのか」を知ることであり、
「アルゴリズムを考える力」（応用力）を身につけることだ。

勉強している間にひらめいたアイデアを書く。
実作業でどのような「プログラム/スクリプト」を使うことができるか考えてでてきたアイデアを書いておく。
いま習っていることが、実作業にどのように役に立つか考えて書き留める。
完璧には無理でも実作業をプログラミング的に分析して、考える。
フローチャートを作って、アルゴリズムを考える

といったことは可能だが、実際に簡単なMelスクリプトを作るときにフローチャートまで書く人はそれほどいないだろう。


そこでプログラミングの勉強中に、もっと簡単にできるようにと考えたのが、以下のような方法だ。

if (A<10)>
スフィアを右へ移動する。
}

と言う風にプログラムの中で、自分のやりたいことをそのまま書いてしまう方法。

目的とすることをそのままプログラム内に書いてしまうので、なんとなく目的にあったプログラムを書いた気分が味わえる。ｗ

スフィアのどのアトリビュートをどの軸上でどのぐらい移動するかという「具体的で細かなこと」は考えない。
それはもっと細かなアルゴリズムで、プログラミング言語に自分をあわせる姿勢であり、自分の発想を失わないようにする姿勢ではない。

これはある意味、数学やプログラムにおける「抽象的な記号論的おきかえ」を利用したものだ。

もちろん文法的にはエラーになる。

しかし、どうせ習ってもいないコマンドや関数をヘルプとにらめっこしながら書いていってもエラーは起きる可能性が高い。　

それにそれを直すのはデバッグの作業で、
「プログラムで何ができるのか」をみつける作業ではない。


これは自分が分析し、みつけたアルゴリズムを、具体的なプログラミング内のどこに位置づけるかという練習になる。
何より、知識が不足していても発想を妨げない。
「文法」、「初心者」と言った規制にとらわれず、「アルゴリズム」も自分にあったレベルでよい。
自由に自分の考えを展開できる。

習ったことが増えてくれば、できるところは、ちゃんと書くようにすればよい。

他にも
「パーティクルが煙のように舞い上がる。」
「雨が、はじかれる」
「車が爆発する」
「おもしろいメッセージを出す」
「赤い色が点滅する」
というふうにいろんな表現が可能だ。

どのようにおおまかな表現でもよい。
そのとき生まれた発想を大切にすればよい。
必要ならあとで、さらにこまかなアルゴリズムにかみ砕いていけばよい。


これを記述するのに、コメント「//」を使うと、
あとで、どの位置にその記述内容がくるべきかを見つけるのに注意がとられて創造性にストップをかけてしまう。
また本当のコメントと混同してしまうことも考えられるのでコメント//を使わないことにした。

2月24日追記：

コン基礎の教え方の宝庫（7） 堅苦しいアルゴリズム研修を盛り上げる

ITエンジニアがアルゴリズムを考える場面が、大きく分けて2つあることも説明しておきましょう。
1つは、プログラムのアルゴリズムを考えることです。
もう1つは、業務のアルゴリズムを考えることです。

「ラフなアルゴリズム」という書き方をしていたが、「業務のアルゴリズム」という風にいいなおしたほうがより適切な表現かもしれない。
自分の業務（CG）を考えながらプログラミングをするということだから。