承前
前回までの内容はこちら。
趣味でプログラミングをする人の誰もがそう、というわけではないのだけれど、ぼくが普段プログラミング入門しながら感じる悩みや問題をある種の傾向として記録し、それによってそれらの問題を解消しやすくしたい、というのがこれらの記事の目的のひとつではある。
何度も同じ問題にぶつかって「またこれか・・」と思うばかりではなく、その先に行きたい、そのための道具としての思索と言いますか。
前回までに大概のことは言ったが（とは前回にも言いましたが）、まだ抜けていたことがいくつかあったのでそれについて。
自分でハードルを立てて、それを跳ぶ
通常、仕事にせよ学業にせよ、「やらなければならないこと」というのはすでに周りによって用意されていて、いつまでに何を納品しなければいけないとか、どこの大学に入らなければとか、いつの試験にパスしなければとか、どこに就職しなきゃとかそういう大きなことから小さなことまでタスクの種類は様々あれど、自分で設定した課題をクリアする、というケースにはそんなに出会わない。
しかし趣味のプログラミングをしていると、たとえば配列に入った3つの要素を順番に取り出す、なんていうただそれだけのことでも、
#!/usr/bin/env perl use strict; use warnings; my @array = qw/orange apple grape/; print "$_\n" for @array;
$ perl fruit.pl orange apple grape
手元で動かして思ったとおりの結果が出てきたら「おお！」とか上がる。
他の人がどうかはわからないけど僕はそうなる。
誰かに投げ与えられた宿題をやるということではなくて、というか与えられた案件もやるしそれは大切なのだけど、趣味とは「べつにやらなくてもいい（誰にも怒られない）」もので、それでも自主的にやるということだから、筋トレとか読書とかもそうかもしれないけど、ただ純粋に自分のためにやることで、その自律性がもたらす面白さというのがある。
言い換えるなら、これは誰に設定されたわけでもないハードルを自分で立てて、それを跳ぶことに喩えられて、何回スッ転んでもまた自分で立て直して、跳べるまで繰り返すことができ、日常や仕事に支障が出るほどやるのがどうかはともかく、その行為じたいに対しては誰にも気兼ねすることなく、なぜならクライアントに頼まれた案件とかではないのでただひたすら自分が満足するまでやればいい、という自由さが生じてくる。
これはもちろん他の趣味の分野にも言えることだろうけど、それでもPC1台あればいつでもどこでも取り掛かれて、誰かとコミュニケーションが必須なわけでないという形態も含めてじつに敷居の低い＆豊かな楽しみであると感じる。
年齢と職業
前の記事でいくぶんしつこめに書いたこととして、「非エンジニアの定義」があった。
それはもちろんどこでも通用する汎用的な定義ではないけれど、少なくとも現時点でのぼくの実感を説明するためには必要なものなので、あらためてもう少し（できればより簡潔に）記したい。
まずぼくの言う「非エンジニア」とは職業的なもので、とくには「コンピュータ技術に関わる仕事で報酬を得ている人（＝エンジニア）」ではない人、ということになる。
だから、コンピュータ技術以外の専門性をもって生活をしている人は基本的にここに入る。
しかし、そういう非エンジニアが皆、趣味としてプログラミングをやりたがるわけではないから、非エンジニアでなおかつ趣味のプログラミングをやる人を「趣味プログラマー（アマチュア・プログラマー）」と定義したい。
一方、ここで一旦「趣味プログラマー」と定義した人の中にもさらにいくらかの立場の違いがあって、たとえば学生とか、あるいはIT会社に入ったばかりの初心者プログラマーも技術のレベル的にはここに重なりそうである。
事実、というかぼくの実感として、「プログラミング入門者（初心者）」という存在を人が想定するとき、多くの場合この辺はとくに切り分けられておらず、ごっちゃになっていることが多いと思う。
と同時に、別にそこ、分けて考えなくても問題ない場合が多いのでは、とも言えて、学生だろうと新入社員であろうと、あるいは別に職をもった趣味プログラマーであろうと、「これまでプログラミングをやったことない人がそれをイチから習得していく」という状況じたいは確かに変わらず、同じように扱ってもとくに問題ない場合というのはけっして少なくないとも思う。
しかしやはり、それでも残る大きな違いというのはあって、それはどれだけ効率的に、学びを単なる知識ではなく、自分で応用できる状態にしていけるか、言い換えれば「いかに無駄なく身につけていけるか」という点にあると思う。
物事を新たに習得するためにはそれを継続したり習慣化したり、それを許す環境を整えたりする必要があると思われるが、その環境というのが上記の学生、新入社員、別職業の趣味人、ではそれぞれ大きく異なると思われる。
（もちろんさらに、そのそれぞれの中でもまた千差万別の違いがあるだろうけど）
だからぼくは「プログラミング入門」ということを考えるとき、たんにイチから教える・教わるというだけでなく、こうした個別の環境（背景）の違いということを考えることで、より効率的な学習を促進できるのではないかと考えている。
それはこれまでのプログラミング入門書なりのあり方を否定するという意味ではなく、より幅広い選択肢を想定・用意することで、より多くの人をこの楽しみにいざなうことができるのではないか、という話である。
寺小屋
どこかにも書いたが（ここだった）、もし「プログラミング入門するならどの言語がオススメですか？」と聞かれたら、「近くにいるすぐ教えてくれる人がやってるのがいいよ」とぼくなら答えると思う。
ここで言う「すぐ教えてくれる人」というのは、もちろんというか喜んで教えてくれる人であって、こちらからも気兼ねなく質問できる相手のことである。
そして、もしそんな人そうそう都合よく周りにいませんから、みたいなことがあったらPerl入学式はオススメできる。
http://www.perl-entrance.org/
※前回の記事もご参照ください。
つまりぼくがPerl入学式を勧めることがあるなら、それはPerlが魅力的だから、ということよりもPerl入学式という場が「喜んで教えてくれる人」のいる「気兼ねなく質問できる場所」だからであって、他の言語や技術において、そういう場がよりアクセスしやすい形で存在しているならそちらをお勧めするだろう。
たとえばPerl入学式のような存在で、Rubyには「Rails寺小屋」というのがある。
http://rails.terakoya.io/
これはRuby on Railsに関するもので、対象者も多少なり限定されているようだけど（「高専学生 卒業生 教職員」と書いてある）、基本姿勢はPerl入学式に近い印象がある。
レポートはこちらなど。
http://www.machu.jp/diary/20140524.html#p01
http://igarashikuniaki.net/diary/20140524.html
あとはRailsGirlsとか。
http://railsgirls.jp/
Girlじゃなくても充実した資料を通して勉強できる。
あと同じくRuby系、上記のレポート記事を書かれたigaigaさんや@まちゅさんによる一橋大学でのRuby講義。
http://www.machu.jp/diary/20140501.html#p01
これはもちろん学生さんのみ受講できるものだけど（たぶん）、その講義資料は公開されていてこれが入門的に大変わかりやすい。
https://speakerdeck.com/machu
という具合に、リアル対面であれネット経由であれ、「あのー、わかんないんですけど」「ハイハイ、なに？」というある種のクイック・レスポンスによるやり取りを何度もしつこく繰り返し、しかしけっして双方の負担にはならずにできる環境を作れたら、その対象はどんな言語であっても（とまでは言えない気もするが）とくに構わないというか、むしろそういう継続や楽しみを後押しする環境を重視した方が結果的にはいいんじゃないかと思っている。
エラーの数が重要
これまでに一度も失敗したことがない、という人がいたら一見すごそうだが、何もしなければ失敗もないので失敗がないことは別にすごくも偉くもない。
成功するためにはトライが必要で、トライをすれば失敗する可能性も必ず生まれるわけだから、失敗を避けたければ成功ごとトライを避けなければならず、原理的に失敗の排斥は成功の排斥でもある。
何も考えず闇雲にトライすればいい、ということではないけれどトライの数は重要で、しかしトライの数を増やす以上にエラーの数を増やすことの方が重要であるとぼくは思っている。
もちろん失敗はどこまで行っても失敗なのであって、別に失敗を好きになる必要はないしそれを目的にするのも違うとは言えるが、あらゆる失敗を味わうことでこれから行おうとしているトライがどのような失敗をもたらしうるのか、という先を読みやすくなり、過剰に怯えてそのトライを躊躇する、ということも減るように思う。
ようは過不足なく未来の失敗を想定する力というものを養うことが、本来求めている成功を引き寄せるために必要ではないかと思っている。
たしかに致命的なミスは避けるべきで、投げやりになってしまったりましてやそのミスに他人を巻き込んでしまったりすることは望まれないが、そのような重大さの度合いを測るためにも失敗の経験は多くあって良いと思う。
そして多くの失敗を経験するということはそれだけトライしているということだから、重視すべきはどれだけトライしたか以上にエラー（失敗）の数だと言えると思う。
人生は限られているし使えるお金も無限ではないから、失敗すべきと言っても限度はあるわけだけど、それでもよくある言い回しで「一番の失敗は失敗しないことだ」的な、それはたしかにそうだと思う。
上記の寺小屋的な場所というのはそうした失敗を当然のこと（恥ずかしくもなければその人の価値を低めるものでもないこと）として許容し、どれだけしょうもないことをどれだけ繰り返し聞いても（まあ程度はあるにせよ）、その他の環境に比べればより高い沸点で、つまりそう簡単には投げ出さずに相手をしてくれる前提で存在しているので、有料であれ無償であれうまく利用できると幸せになれそうだと思う。
今回はここまで。また何か取りこぼしていることがあれば続きます。
