1. はじめに
Twitterで、以下の議論を見かけた。
「初心者がプロとして食っていくためのショートカット、いちばんいいやつでたのむ」 - Togetterまとめ
これ自体とても面白い話なのだけど、これを読みながら思い出したのは、そこにも登場されている西尾さんの『コーディングを支える技術』のコラム「何を学べばよいかがわからない理由」で、同書は名著で良書だったけど、その内容の良さ（自分が求めている事とフィットする感じ）とは少し別の部分で「ん〜、そうかな？」と思った以下のくだりだった。
「何を学んだらいいですか？」――これはよく聞く質問です。しかし、それに答える前にまず質問させてください。「あなたは何を作りたいのですか？」目的が明確でなければ、適切な手段をアドバイスできるはずがありません。
（P26-コラム「何を学べばよいかがわからない理由」）
じつはこれと同じような話を別のエンジニアの人たちがしているのを以前にも見たことがあり、そのときにも「ん〜、そうかな、どうかな」と思い、ある程度突き詰めて考えたことがあったので、「おお、またこの問題か」と思った。
2. 僕の場合 / ぼんやりした目的を探る
僕は昨年5月から趣味として、仕事以外の少なからぬ時間をプログラミングに割くようになったけど、そのときに、初めに手を付けるプログラミング言語を「Rubyにしようか、Pythonか、Perlか・・あるいはPHP！ いや、JavaScriptというのもあるらしい・・いろいろあるな〜！」とか迷うのがけっこうワクワクするというか楽しくて、だからわざわざ誰かに「今だったらRubyから入るのが良いですかねえ？」なんて聞いたりはしなかった。
これは単純に、普段の僕の生活環境でプログラマー、エンジニアと言える人がすぐ近くにはいなかったからかもしれなくて、もし気軽に聞ける先輩がいれば参考意見として聞いたかもしれないけど、でもその回答をどこまで拠り所にしたかはわからない。
というか、これから「何を勉強してもいい」という、広大な可能性の荒野を前に胸をふくらませているときに、他人に対して「右に行くのがいいですか？ 左ですかね？」なんて聞く理由がない。どこに行ったって誰にも迷惑をかけるわけでもなければ文句を言われるわけでもないのに、なんでそこで他人の意見が必要になるのか、とも思う。
だから僕個人としては、そもそもの「何を学んだらいいですか？」という質問がこの世界に本当に存在しているのか、それってもしかすると「なぜ人を殺してはいけないんですか？ と子供に聞かれた」的な話で、架空の思考実験みたいなものでしかないんじゃないか、そうであるならさらにゼノンのパラドックスのようなもので、現実ではない言葉の上での話にしかならず、本気で考えても無駄なんじゃないか、とすら思うのだけど、でも仮に、本当にそういうことを聞いてくる人がいるとしたら、それはもう「インタビューするしかない」のではと思う。
ようは質問者に聞き返す、ということで、だったら西尾さんの上記コラムと同じ回答では、と思われるかもしれないし、たしかにそこまではそうなんだけど、聞き返す内容は「何を作りたいの？」ではなく、「どんな感じになりたいの？」である。
多くの場合、曖昧な質問をしてくる人は対象に関する認識が曖昧だから曖昧な質問をしてくるわけで、「何を作りたいのか」などと聞いたところでそんなことを本人がわかってるわけがない、というのが僕の見方である。というか、「何を学べば良いかはわからないけれど、それを学ぶことで何ができるかはわかっている」などということがあるだろうか？
つまり、「何を作りたいのか？」という逆質問は、ちょっと具体的すぎて有効ではない（と思う）。もし何らかの回答が返ってきたところで、それは取り繕うようにその場で考えられた浅い（本当はそんなこと思っていなかったかもしれない）内容かもしれず、それを根拠に話を進めても無駄になる可能性がある。
だからもっと曖昧に、相手が持っているはずの程度の、「ぼんやりした目的」をそのまま把握しようとすべきだと思う。
想像するに、初心者というのは、プログラミングを通して「よくわからんけどあんな感じのことがしたい」とか「誰々みたいになりたい」とか「こんな風な生活を送ってみたい」とか、そういう雑で希望に満ちた未来像は持っているはずなので（希望を見出していないならそんなことやろうと思うわけがないので、基本的に明るい未来像は持っているはず）、その辺をくみとることができれば、その後のやり取りがけっこうしやすくなるのではないかと思う。
たしかに、教える側にとっての「ある程度明確な目的が分からなければ教えようがない（＝わかれば教えられる）」という理屈は大変わかりやすく、それが間違っているわけでもない。
しかしやはり、それは質問された側の論理というか、都合にすぎなくて、より大局的に見た場合の解決すべき問題への対応としては、少し的を外しているとも思う。
繰り返すが、もしも僕自身が先輩にプログラミングに関する何かを聞くことがあるとすれば、そんなに曖昧な質問はたぶんしなくて、たとえば「本のとおりにやったんですけど、こんなエラーが出て、でも本にはそんな説明ないんですけど何がおかしいんでしょうね？」とか、「Go言語って興味あるんですけど、予備知識としてどんなことをわかっておいた方がいいですかね？」とか、「Dockerを使うとこれまで他の何で出来ていたことがベターに代替できるんですか？」とか、そういうことなら聞いてみるかもとは思うけど、逆にもし誰かから「何を（どんな言語や知識から順に）学んだらいいですか？」とか聞かれたら、やはり「ええと、もう少し具体的に、君の欲望の中身を教えてくれるかな？」と聞き返さざるを得ず、さらにはそれを聞いてくる相手ごとに個別にやる必要があるようにも思う。
※いくつかの質問者＆回答のパターンを掲示しておいて、質問者がいたらそのうち自分に近いやつを読んでおいて、みたいなことはできるかもしれないけど。
3. 土台となる環境を厳密に揃える 〜Perl入学式での経験より〜
とにかく初心者というのは「自分でも何がわからないのかがわかっていない」生き物で、それは僕も然りだったので、だからこそというか、「なるほど、これがわかってなかったから最初の一歩が踏み出せず、でもその後にそれがわかったから次に行けたのだな」と後から思えることもあるので、以下ではそれについても含めて書いてみる。
と言っても結構シンプルな答えでもあって、結局のところ、僕が現在でもプログラミングを多少なり続けられているのはPerl入学式のおかげと言える部分が大きくて、
Perl Entrance
とくにはこの資料の、
workshop-2013-01/02.introduction/slide.md at master · perl-entrance-org/workshop-2013-01 · GitHub
この部分が大きな一歩になったと思っている。
https://github.com/perl-entrance-org/workshop-2013-01/blob/master/02.introduction/slide.md#plenv
見てもらうとわかるが、plenvというツールを使ってシステムのデフォルトのPerlとは別に新しいPerlをインストールする、という方法の説明なのだけど、これがまさにそのときの僕が求めていた作業で、そのときの僕の状況は「考えられるかぎり新し目のPerlで土台となる環境を整備し、そこから一つ一つ新たなことを知っていきたい」というものだったからそれにとても合致した。
で、その少し後に「Hello, world!」の書き方講座があるけど、
https://github.com/perl-entrance-org/workshop-2013-01/blob/master/02.introduction/slide.md#hello-world
これを出力できたときにどれだけ嬉しかったことか。それまでにもRubyやJavaScript、あるいはPerlですら、Hello, worldは何度かターミナルに出力していたけど、そのたび「んーむ、なるほど・・。で、これが何？」という感じだったのが、このときに初めて「おお、できた」という感じになった。メタかつベタに喩えると、これが僕の本当の意味での「Hello, world!」だった。
では、前者の「で、何？」という不全感と、後者の「おお」感との違いは何かと言ったら、それは自分でもよくわかってはいないけど、でもやっぱり、plenvでまず環境をきっちり整備して、その上で一つ一つ明確な手順を踏んで出力したことにより、自分から「見えない部分」というのが最小化され、何が起きているのかをある程度把握しながら進められたことにより、ある種の納得感（腑に落ちる感覚）を得られたのではないか、という気はする。
たぶん、Perl入学式主催者の側からしても、まさかplenvを採用したことがそんなにもその後の僕のプログラミング道中を左右するとは思っていなかったと思うけど、もちろんそんなことは僕だって想像していなくて、だからもし事前に「具体的に、何をしたいの？」と聞かれても「まずplenvで5.16.3をインストールして〜」などと言えるはずがなく、よって「初心者にはこう対すればいい」ということはなかなか言えない。
ただそうは言ってもいくらかの、「初心者には大体こう言っておけばうまくいく」という傾向のようなものはそうした経験からも抽出できるかもしれず、それを考えてみると、結局のところPerl入学式の何が僕にとって画期的だったのかと言うと、WindowsですらVMware+Ubuntuをインストールさせた上で、参加者全員にplenvでPerl 5.16.3をインストールさせて、スタート地点の環境を一律に揃えた、という点にあると思う。
これをやることで、上記のように不確定要素が最小化され、どんなアクションをするにせよ、すべてそこからの差分で正誤を見ていくことができる（見ていきやすくなる）ようになった。
初心者というのは「何が良いのか」もわからないけど、「何が悪いのか（何をしてはいけないのか）」もわからないので、知ってる人からしたら「それはあり得ない」というようなアクションを平気でやったり、あるいはどうでも（どっちでも）いいようなことについて「これ、やってもいいんだろうか」とか不安に思っていたりする。知ってる人が想像もつかないようなことを、疑問に思っていたりする。（ターミナルってどこにあるのか、シェルとは何か、コンソールとは何か、バックスラッシュってどうやって出すのか、円記号が出ちゃうんですけど、とかそういうのを筆頭にいろいろ）
そういう様々な不安、不確定要素というのが、みんなの環境が一律の横並びになることによって、「あの人はできてるのに自分にはできない。ということは、あの人と自分の現時点の違いを見れば、それが間違いの理由ってことになる」ということが明確になる。
これがもし、おのおの自由な環境下での実行だったら、土台からして違うので、どこに本来の差異が生じているのかを見つけることは（とくに初心者にとっては）困難になる。
よって、どうしても通常飛ばされがちなこういう土台をきっちり細かく示すことが、その先を進めやすくする大きな助けになるだろう、とは経験的に言える。
4. 硬派への憧れ 〜誰の真似をしたいのか〜
ただし、そういう「環境構築」が大変だから、といって、そういう工程をスッ飛ばせば（簡略化すれば）初心者にとって良いことなのか、というと少なくとも僕の場合はちょっと違う。
たとえば最近だと、こちらで紹介されているような、
WebブラウザだけではじめるRuby/Railsプログラミング - Qiita
ブラウザから何でもできるから、これなら手元で構築しなくてもよいでしょ、というサービスなどがあるけど、僕の場合は（ここまでにはまだ書いていなかったけど）大元の欲望として、「エンジニアの真似事がしたい」ということがプログラミング学習の大きなモチベーションのひとつとしてあるので、普段、他のエンジニアやスーパーハッカーたちがこれを使っている、というのでないなら食指は動かない。
上記のQiitaを書かれたまちゅさんのブログによると、
WebブラウザだけではじめるRuby/Railsプログラミング - まちゅダイアリー(2014-05-18)
未経験者がプログラミングを始めようと思ったときに、最初に大変なのは開発環境を構築すること。本当はプログラムを書きたいのに、慣れないシェルの画面と格闘して…と、そこで挫折しちゃうのはもったいない。
という流れでそれを書かれたようなのだけど、そしてそれ自体はまったく問題ないのですが、僕個人としてはその「慣れないシェルの画面と格闘」するのが一番楽しいところというか、ゾクゾクするところなので、そこをショートカットさせないでほしい、というのがある。
むしろ僕としては、以下の記事で紹介されているような、
本の虫: ステレオタイプなLinuxカーネル開発者
ここで言われる「硬派」なエンジニアへの憧れがあって、なんだっけ、『マトリックス』でコードの流れを見ているだけでその向こうの映像がわかる、みたいなシーンがあったけど（説明が雑すぎるけどわかるはず）、まさにその「コードだけで全部やる」という感じになりたい。だからもちろんGitHubだってGUIクライアントなんて使わない。よく、デザイナーとエンジニアのGitHub上での協業を促進するためにデザイナーにはGUIクライアントを勧めればよい、みたいな話を見る気がするけど、それはデザイナーを馬鹿にしていて（というのは言いすぎ）、デザイナーにだって硬派を夢想する人はいるはずで、その人から硬派への道筋や憧れを奪ってはいけない。
5. まとめ
だいぶ脱線したかもしれないが（実際にはしていないが）、話を戻すと、原則的にはインタビューが必要というか、ある程度の背景がわからない状態で何かを勧めるなんて時間の無駄である。
でもそのインタビューで求められる答えは、「これこれこういうWebアプリを作りたくて、機能はこんな感じで、想定ユーザー数は・・」とかいった具体的なことではなく、その初心者がどういった希望や欲望を、プログラミング習得後の未来像として抱いているのか、といった大変曖昧なものだと思われる。
たしかに投げかけられる質問が具体的であればあるほど教えやすく（効率的な回答をしやすく）はなるけれど、この曖昧な欲望を踏まえて助言をしなければ、「この帽子、キミに似合うと思っておみやげに買ってきたよ」「ありがとう。でも趣味じゃないからいらない」みたいな、誰もトクしない事態になりかねない。（硬派指向のデザイナーにGUIクライアントを勧めるようなもの、ということ）
さらにはそうした前提の上でも、どのような初心者に対してであれある程度有効な助言や協力はできるかもしれず、それはたとえば「前提となる環境をきっちり揃えておく」ということであり、これにより、もしその初心者の手元で想定外のエラーが出たとしても、すぐにその理由を見つけ出しやすくなる。これは教える側にも教えられる側にもメリットが大きいと言える。
大体以上です。
