トップ > text

ノンプログラマーに求められるもの

text beginner

ノンプログラマーがプログラミングを覚えることにより普段の業務負担を軽減させる、みたいな流れが徐々に活気を帯びてきたというか、この本なんてその象徴のようにも思えるのだけど

www.oreilly.co.jp
ふと我が身を振り返ってみると、ぼくが趣味でプログラミングをやってるのって、そういう理由というか目的というかモチベーションではあまりなくて、もちろん、そういう効果があれば嬉しいし、実際にはあちこちで発信しているように、プログラミングを習得すればするほど「今までこの作業ってVimやPerlやGitを使わずにどうやってたんだっけ……思い出せないし思い出したくもない……」と思うぐらい様々な負担が軽減、またはそもそも不要になっていたりするのだけど、でも気持ち的に、なんでプログラミングをもうかれこれ4年近く続けてやってきたのかっていうと、それはたぶん

《日々の業務があまりに地味かつ長期的で、目に見える効果というものがわかりづらくて、それはまるで人が年齢を重ねていくような、「昨日と今日の違いがほとんど認識できない」ぐらいの変化の無さだから、そういうものとはまったく逆の「一瞬で目の前の世界がガラッと変化する」ような体験を求めて、プログラミングとかテクノロジーとかに希望を託している 》

ということなんじゃないかなあ、と思った。

言い換えると、日々の業務の負担が減るっていうのはたしかに嬉しいことで、村上春樹いうところの「小確幸」なわけだけど、じゃあそれがわざわざ貴重な時間を割いてまでやる「目的」とか「欲望の対象」になるのかっていうとそれにはちょっと弱くて、欲望の対象としてはだから上記の「これまでに見たことのない風景を見てみたい！　味わったことのない気分を体験したい！」みたいな気持ちがあって、結局はそれに向かって一生懸命コンピューターに向かい合ってるという感じがする。

それはほとんど人生を賭けた、生きる意味やテーマのような営みだから、その手段はプログラミングでなくたって構わないとも言えるんだけど、さしあたって現時点ではその過程にプログラミングがあるからそれに時間をかけている、というような。

でも実際には、プログラミングというのは自分が手を動かして英数字などを打ち込んでいかなければ（少なくとも2017年の現時点では）身についていかないわけで、頭の中で「こうなってほしい！」とか念じるだけでは出来てくれない。

何を言いたいのかというと、これってやっぱり一朝一夕に習得できるものではなくて、どうしても時間はかかるということ。

で、それって何に似ているかというと、たとえばスポーツとか、語学とか、あるいは楽器の練習。高い楽器を買って、さあやるぞ！　となってもそれが身につくまではずっと自分の体を動かしてくり返し練習しなければならないわけで、さらにはそれを「趣味」でやるということは、普段の仕事は仕事として頑張った上で、その合間に、つまり本来なら娯楽を楽しんだりゆっくり体を休めたりできたはずの時間をつぶしてそれをやらなきゃいけない。

さらに言うなら、結局はそんなふうにわずかな時間を繋いでやっているだけだから、プロとしてやっている人たちとの差はみるみる開いていくわけで、いやそんなの当たり前なんだけど、でもどうしたって「自分より年下のあの人はあんなに出来るのに、なんで自分の上達はこんなにも遅いんだ……」って比べて思ってしまうのもまた自然というか。

つまり、趣味でやるっていうのは結構大変。上達の実感はいつも理想の遥か後ろを遅れてやってくるし、当初憧れたようには全然できないまま時間がどんどん過ぎていく。

それでもぼくがここまでそれを続けてきたっていうのは、だから「日々の業務の負担を軽減したいから」というだけのことではなくて、その向こうにある「なんか知らんけどスゴイ体験をしたい！」という感覚に揺り動かされてきたからだと思う。

そのある種の貪欲さというか、しつこさというか、諦めの悪さみたいなものに引っ張られてダラダラやっているうちに、結果として「なんか知らんけど業務もめっちゃラクになってる〜〜！」みたいなことがあるのかなと思う。

そんなことを踏まえつつ、冒頭に挙げた本のタイトルを見て思うのは、「コンピューターに退屈な作業をさせよう」なんて考えている自分自身はけっこう楽しい（退屈ではない）のだよな、ということ。

より具体的に言うなら、コンピューターにその作業をさせるためにちまちまコードを書いていく作業はけっこう楽しい。

さらに言うなら、そのコードを書く過程で素人なら必ずハマる。何度書き直してもうまく動かない。ちょっと、というかかなりイライラする。そして自分は自分で思っていた以上に馬鹿なんじゃないか？ という底知れぬ不安に襲われる。もう何度も棚から取り出しては戻した参考書の、ついさっき見たはずの正規表現のルールをもう忘れてしまって、誰にも向けられない憤りにうんざりしながらまた棚から引き出す。頭はぐちゃぐちゃに溶けて煮詰まっているけれど、なんか踏ん切りがつかなくて深夜まで同じ箇所を修正し続けてしまう。そしてあるとき、突然視界がひらけるようにプログラムが動く。……お…おおおおお〜〜〜〜！！ってなる。……でも周りには誰もいないから、実際にはその叫びは頭の中だけに響いてる。深夜の静かなリビングで、自分とターミナルの黒い画面だけがある。

その無音なんだか轟音なんだかわからない一瞬の魅力に囚われてしまって、その景色をまた見たくて続けてるのかなっていう。

上では何度か「趣味」と書いたけど、だからこのような日々を送るぼくにとってはプログラミングを「趣味」と呼ぶのはちょっと違和感がある。
もちろん仕事なわけではないし、ましてや天職とか使命とかいう大げさなものでもない。

そうではなく、なんか本職でも娯楽でもない、「2つめの仕事」みたいな感じというか。
日本語ネイティブの人が英語も日常生活を送れる程度には喋れる、というときの「第二言語」としての英語みたいな。

そういえば最近、ラムダノートの鹿野さんが書いた以下の記事で、
employment.en-japan.com

IT系エンジニアとして仕事で使っているプログラミング言語ではない言語、つまり第二言語を学ぼうというシリーズ記事

というのが始まっていたけど、ぼくがここで言うのはそれの人生全般バージョンというか、能力としての第二言語、本職を支える副次的な素養みたいな。
そういうものとして、育てていけるんではないかなあ、という感覚が少しある。

その意味では、こういう自分のような人たちを「ノンプログラマー」であれ「非エンジニア」であれ、語の頭に否定形（ノンとか非とか）を付けた呼称で表すことには以前から違和感があったけど、たとえば「セカンド・プログラマー」とか「オルタナ・プログラマー」とか、ぼくだったら編集をやっているので「エディター・プログラマー」とか、「*er Programmer」とか（読めない）、なんかそういう本職の方にフィーチャーした言い方がないかなあ、という気もしてくる。

「趣味」とか「アマチュア（愛好）」ではないのだよね。べつに愛でてるわけではなくて、自分だって早く風呂に入ってさっさと明日に備えて寝てしまいたいんだけど、どうしてもさっきwhileで無限ループした理由が腑に落ちなくて、何度もいろんな場所の変数の中身をプリントデバッグしていたらもう外が明るくなってきたとか、そういうのは愛好ではなくてもう狂気に近い。というか非常識。

上で挙げた鹿野さんの、以下のインタビューも面白かったんだけど

itpro.nikkeibp.co.jp

その最終回にあった以下のくだりが印象的で。

私がオーム社でやっていた本の作り方は、会社から見れば特殊な作り方です。私しか作れない本が増えてきてしまった。会社からは「ほかの社員もできるようにしてほしい」と言われて広めようとしたのですが、うまくいきませんでした。私たちと一緒に仕事するときはバージョン管理などの仕組みを使ってくれるのですが、そうした社員も自分から使おうとはしなかった。

この最後のところ。「自分から使おうと」するかどうか、というのは、ようは上に書いたような「気づいたら時間を忘れて夢中になってた」みたいな感覚があるかどうか、ということだと思う。

そういうのがなきゃ駄目、という話ではなくて、というか誰にだってそういうのはあるはずで、単に対象がプログラミングかそうでないか、という違いがあるだけだろう。

とくにまとめもオチもないのだけど、つまりはプログラミング、結構大変。ぼくの場合は大学も美大で、授業でプログラミングとかなかったし、初めてパソコン＆ネットに触ったのは28才で、初めてハローワールド！出したのは38才。だから世代や環境が違えばまったく上とは別のことが言えるかもしれないけど、いずれにしてもこういう人がこういうことを続けるには、「目的」とか「目標」とか「覚悟」とかではなくて、自分でもコントロールできないそういうある種の過剰さみたいなものが必要なのではないか、という気がしている。

CGIを乗り越えて

perl text

長年の課題

手元の記録によると、僕は2013年の5月1日に渋谷へ打ち合わせに行って、その帰りにプログラミング関連の本を3冊買い込んでいる。

おそらくは心身のストレスがすごく溜まって、その反動のように、なかばヤケになって「仕事に全然関係ないことを全力でやってやる！」みたいになっていたのだとおぼろげながら思い出す。

実際には、その前からもプログラミング入門の意志を持ってはいたけれど、僕がその勉強を2013年の5月から始めた、とよく言うのは、ひとまずそれらの書籍購入が理由なのだと思う。

とはいえ、その後もしばらくの間は手探り状態というか、本格的に学びたいようであり、もっと機が熟すのを待ちたいようでもあり、あるいは具体的にやりたいことがあるようであり、無いようでもあり、という日が続くのだけど、そんな中で何となく見えてきた目標は、たとえば「gitを使えるようになりたい」とか、「tDiaryをインストールして日記を書きたい」とかだった。

gitは当時、僕がよく目にするプログラマー同士の会話でしょっちゅう名前が挙がっていたりして、自分も使いたいと思ったということだろう。

一方のtDiaryは、2005年頃から使っているはてなダイアリーとの繋がりで、以前からその存在を知ってはいたけれど、その雰囲気のやわらかさとは相反するような「玄人っぽさ」が感じられ（使ってる人は皆その道のプロ、みたいな）、いつかは自分でそれを設置してみたい、もしそれが出来たら、自分も一段階次のレベルへ進んだと言えるはず、みたいに感じていたのだと思う。

その後、gitの方はなんだかんだで最低限の操作はできるようになったものの、tDiaryの方は何度トライしても、そのたびに「ああ、駄目だ。まだ俺には難しすぎる。わからなすぎる」と挫折した。

tDiaryは今なおどんどん進化を続けていて、単に「tDiaryで日記を書きたい」というだけなら、特別な技術的知識はほとんど無くても使えるようになってきているようなのだけど、僕の目的は「技術力がついたことの証としてtDiaryを自力で設置する」ということだから、公式サイトのドキュメントをもとに標準的なインストールができなければ目標を成し遂げたことにはならないし、それが何度やってもできなかった。

CGIがわからない

さて、ではtDiaryの設定が「難しい」と僕が言うとき、具体的に何が難しいのかと言うと、いろいろある中でも一番の難関は「CGIがわからない」ということだろう。

CGIというのは、知ってる人にはあまりにも前提的な技術であるかもしれないけど、現時点でそれについて何も知らない人が、一からそれを学ぶためには、これという入り口が実はない。

「そんなの、ネットを検索すればいくらでも情報が出てくるだろう」と思われるかもしれないし、実際に情報自体は少なくないのだけど、その大半は、いにしえの環境やWindowsマシンによる操作を前提にしたものであって、2015年を生きる僕の、さらにはMacによる操作を前提にしたCGI入門の記事なんてそうそうない。というか、ない。

よって必然的に、そうした古かったりWindows前提だったりする記事を自分の環境に読み替えて、サンプルコードなどを実行してみるわけだけど、それですぐに動くなどということはまず無くて、またそのエラーをもとに検索を重ねても、あちこちをたらい回しされるばかりで解決には至らず、やがて気分的にも体力的にも徒労がつのり、結局毎回「ああ、駄目だ。まだ俺には早かった」となってしまう。

この「自分の環境にフィットした情報がない」「試しても動かない」ということが、僕にとってのCGIの難しさだった。

CGIを勉強する意味

そのようなことを言うと、「というか、そもそも今、CGIを勉強する必要なんてあるか？」と笑われるかもしれないのだが、もちろん勉強する意味はある。

たしかに、CGIはもう必要とされていない技術かもしれないし、今後作られる新たなプロダクトでそれが採用されることも少ないかもしれない。

しかし問題は、CGIそれ自体を使うかどうかではなく、CGIを扱う能力を持てるかどうか、なのである。
言い方を変えれば、CGIすら理解できない人間に他の何がわかるのか？ ということだ。

CGI自体の知識は無くて良いとしても、それを「理解しようとしても出来ない」という人に、それ以外の技術を理解できるはずがない。

だから問題は、「使うか/使わないか」でもなければ「知っているか/知らないか」でもなく、CGIを「理解できるか/できないか」であり、僕は「CGIを理解できる」という能力を、いわば免許/パスポートのように手に入れて、それを持って次のステージに行きたいと思っている。

念のために言うと、それは「CGIを理解するまで他のことをしない」という意味ではない。むしろ、RubyなりGoなりDockerなりという進行形の技術に目を向けつつ、その一方でCGIの仕組みもちゃんと知っておきたいということだ。

さらに言っておくなら、「CGIなんてもう使わないよ。勉強する意味なんてないよ」と言う人の多くは、自分ではしっかりCGIを理解しているに違いない。そしてその人自身がCGIの技術を習得する前の状態に戻れない以上、その勉強が不要であると証明することは困難だ。

CGIについて触れずに充分なプログラミング技術を学習できる方法があるのであれば、その方法の中のどの要素がCGIを代替しているのかを明確に示すべきであるし、それがないまま学習者の向かう先を否定しても、相手の気持ちをくじくだけだから、どうか優しく見守ってほしいと思う。

直接的な乗り越え

CGIをようやく克服できたのは今年の2月の初めで、以下のムックの冒頭に書かれていた小飼弾さんの記事と、このブログではよく紹介している結城浩さんのPerl入門書に書かれていたCGIの項目がきっかけになった。

Web開発の基礎徹底攻略 (WEB+DB PRESS plus)

Web開発の基礎徹底攻略 (WEB+DB PRESS plus)

新版Perl言語プログラミングレッスン入門編

新版Perl言語プログラミングレッスン入門編

といっても、単純にこれらの中に書かれているコードをそのまま実行しても、やはりそれまで同様、すぐには動かなくて、いろいろ自分なりに手を入れて、ようやく動かすことができた。

そしてその過程を後から振り返ると、結局のところ、僕の環境でCGIが動かなかった原因は、以下の要素が単発ないし複合的に生じていたことに尽きると思う。

1. サーバーの設定でCGIの実行権限を適切に設定していない。
2. ファイルのパーミッション設定で実行属性が付いていない。
3. PerlスクリプトでCGI.pmを使う際にyumのperl-CGIがインストールされていない。

逆順で説明すると、3番はそれこそ今後作られるプログラム/プロダクトにはあまり関わらない知見かもしれないけど、結城浩さんの書中にあったサンプルコードに、 CGI.pm をuseしているPerlスクリプトがあって、それが動かない原因を探し続けて、ようやくこれに行き着いた。

同書はきわめて明快＆簡潔に書かれているので、これでわからなければ読者のほうが悪い、というぐらいのものだけど、それでも本の通りに書いたコードが動かないので、逆に原因を絞り込みやすかったとも言える。

特徴的なのは、後述の2点がサーバー設定の問題であるのに対し、これは「CGI.pm」というPerlのモジュールがちゃんとインストールされているかどうか、というPerlの問題であったことだろう。

CGIとPerlがよく結び付けられて語られることもあって、「CGI」という技術全般の話と、Perlモジュールの「CGI.pm」の違いを知らないまま、ずっとこんがらがっていた。

わざわざ「yumのperl-CGI」と断っているのは、plenv経由でセットアップしたcpanmでCGI.pmをインストールしてもスクリプトは動かなくて、yumのperl-CGIを入れて初めて動いたからなのだけど（僕の環境ではplenvでsystemの他に5.20.0が入っていたので、その両方にcpanmでCGI.pmを入れたが動作しなかった）、この辺についてはまだ充分に理解できていないので、今後より詳しく把握したい。

いずれにせよ、その結城さんのサンプルコードはトータル10行程度の最高にシンプルなコードだったから、それだけにこれが動かない間は頭が混乱し続けたし、動いたときにはものすごく嬉しかった。

また、2番のファイルのパーミッションについて理解できたのは、上記の弾さんの記事がきっかけで、ここにもサンプルコードが併記されていたのだけど、その説明文の中に

chmod a+x date.cgi

で実行属性を付ければ（略）アクセスできます。

という記述があった。

chmodというコマンドについてはドットインストールのUNIXコマンド講座で見かけていて、そこでは777とか644といった番号による設定が重点的に説明されていたけど、基礎はこれを見るだけでも充分理解できる。

それを知った上で、上記の説明を読んでいたので、ここでようやくCGIのファイルには実行属性というものが必要なのだと明確にわかった。

腑に落ちるまでやる

とはいえ、CGIを動かそうというときに一番問題になるのは、やはり1番のサーバーの設定に関することだと思う。

サーバーと言ってもいろいろあるだろうけど、ここではapacheのことを念頭に置いて言うと、個人的にはとにかく /etc/httpd/conf/httpd.conf ファイルの中の

AddHandler

と

ExecCGI

の2点さえ各自の状況に応じて適切に記載できれば、CGIは動くと実感している。

……なんて、最大限簡潔に書いてはみたけれど、何しろその2点（AddHandlerとExecCGI）の書き方というのは、内実を知らない人にとっては無限大の組み合わせ・選択肢を考えることができてしまい、それに加えて、ネット上には太古の昔から脈々とアップされ続けてきた玉石混交のapache情報が入り乱れているので、迷子になるなと言うほうが無理がある。

そのような状況にあって、じゃあ僕自身はどうしたのかと言うと、ネットで調べて集めまくったhttpd.conf の書き方を一気に記載してみて、もしそれで動いたら、そのうちどれを元に戻しても（書かなくても）動くのか、あるいはどれを記述しなかったら動かなくなるのか、ということを一つ一つ調べ（比べ）続けた。

その際には、実行する環境によってバラつきが出ないように Vagrantでサラの環境を作って、条件を合わせて何度も試して、それでようやく自分なりに納得することができた。

CGIに関する情報は上記のとおり、古かったり断片的だったり、あるいは今のぼく自身がそうであるように、生半可な知識のままアップされてしまった情報だったりして、正直、まったく役に立たなかったり、場合によっては関係のないところへ誘導されてしまうことも少なくなかった。

それは正しい情報を僕が間違って解釈したから、ということもあるかもしれないし、情報自体が間違っていたこともあるかもしれないけれど、どちらにしても言えることは、他人が上げた情報はあくまで「参考」にするものであって、最後に頼りになるのは、自分の中で芯から腑に落ちた理解であるということだ。

この「自分の中に作り上げた理解」が土台にあれば、もしその理解を逸脱する現象が生じても、それらの差分を通して、つまり自分が知っていることと実際に生じている状況との「違い」の中にエラーの原因があると見込んで、追求していくことができる。

逆に言えば、そのような差分を抽出するための土台・基盤ができるまでは、「どの情報を信じたらいいのかわからない」という状況を漂い続けることになるし、結局のところ冒頭に書いた「ああ、駄目だ。まだ俺には早すぎる。難しすぎる」という挫折の数年間は、そうした土台がないゆえの漂流時代でもあった。

大局的な乗り越え

直接的なCGIを理解するきっかけは上記の2冊だったけれど、より大きな意味で、僕をその克服へ導いてくれたのは、サーバー/Linuxの独習だったと思う。

僕はまだまだそれらについてよく知らないが、それでもLinux操作の基礎に触れ、それに対する無知の度合いや、苦手意識や忌避感を薄れさせていく中で、「今生じているこの問題の原因は、もしかしたらこれではないか？」という予想を、以前より早く、高い精度でつけられるようになってきた。

そのような、いわば得意意識（苦手意識の反対）が育ってくると、今度は何回トライに失敗して、そのたびに力尽きて倒れてしまっても、しばらくしてから「もしかして……あれが原因かも？」と、湧き立つような新たな仮説とともにムクリと体を起こすことができ、その繰り返しのうちについには正解へ辿りつけるようになる。

もしサーバーの勉強を始めていなかったら、CGIまわりの用語や概念はまだ不明なものだらけで、トライしてもいまだに「早すぎる」となっていただろう。
僕にとってサーバーの勉強は、CGIを理解するためのものではまったくなかったけれど、巡り巡って、それが一番の助けであり力になったのだと感じる。

サーバーの勉強をなぜ始めたのかと言えば、それ系の話をしている人たちが実に楽しそうで、刺激と面白さに満ちた時間を過ごしているように見えたからで、自分もそれに加わりたいと思ったからだった。

これについては、以下の記事の最後にその心境を非常に上手く表している引用文を抜粋している。

楽しそうだから、と思って始めた勉強が、別のところに存在していた長年の懸案・課題を解決する助けになった、というのは我ながら良い話だと思うけど、このCGIの克服と、サーバーに関する微々たる得意意識の獲得とが、さらには冒頭に示した「tDiaryを動かす」という積年の目標をついには果たすことへ繋がっていくのだから、その話はもっと面白い。

その辺りの具体的なことについては、また時間ができたら書きたい。

初心者の粗い目盛り

text beginner

どんな分野でもそうだと思うが、それについてよく知らない人は「すごいこと」と「そうでもないこと」の区別がつかない。

100メートルを5秒で走る人がいたら誰が見ても速いが、世の中はそこまでわかりやすいことばかりではないというか、むしろわかりにくい違いの方が多い気がする。

プログラミング入門の当初、ことあるごとに挫折を感じていたが、それはようするに僕の理想の置き方が不適切だったからで、そうそう簡単にできるはずがないことを、簡単にできるという前提で捉えてしまっていたから、必要以上に落ち込んでいたのだと思う。

初心者は傲慢か

初心者による、ある種の質問や、そのときの態度が、傲慢に見えてしまうことが僕にはあって、たとえば Yahoo!知恵袋 なんかで「大至急！」みたいに言ってる人を見ると「おいおい・・もう少し頼み方というものがあるだろう」と思ってしまう。
しかしながら、それはその質問者がどんな場面でも傲慢な人だからそうなっているというよりも、そうした「区別のつかなさ」「認識の粗さ」が表れているということだとも思っている。

冒頭に書いたように、その対象に熟達していない人は「難しいこと」を難しいとは思わない。TVで野球なりサッカーなりを見ているとき、平気で「なんであんな球が捕れないんだ（打てないんだ）」とか「なんであそこで決められないんだ」とか言うのも、良し悪し以前に、プレイする側のプロではないからだろう。

先日ここに抜書きした「ハリネズミ」もそれにあたる。

ハリネズミ型思考とランダムな歴史（ダニエル・カーネマン『ファスト＆スロー』より） - new draft

ここで言う「ハリネズミ」は、対象を1個の大きな世界観で捉え、その世界観（因果律というか）ですべての説明がつくと思っている。
そしてそれができるのは、対象を「よく知らないから」だと思われる。

対象を知るにつれ、じつは様々な状況、事例があり、一つや二つの論理では説明のつかないことがある、ということがわかってくる。そしてその中で、「一見簡単に見えるが実際には難しいこと」や、「見た目はすごいことをやっているようだが実は何もしていないに等しいこと」などの違いがだんだんわかってくる。

たいしたものに見えない

以前に読んだリーナス・トーバルズの自伝的著書に、こんなくだりがある。

　こうしてついに、二つのスレッド――AAAAAAAとBBBBBBBを切り替えることができるようになった。つまり、片方のスレッドからデータを読んで、画面に書き込み、もう一方がキーボードから読み込み、モデムに書き込むのだ。こうして、自分のターミナル・エミュレーターができあがった。
　（略）
　かなり得意だった。
　ぼくはサラに、この偉大なる業績について知らせることにした。ぼくが見せると、サラはAAAAAAAとBBBBBBBが並んだ画面を五秒ばかり眺め、それから「いいんじゃない」と言うと、それがなんなのよ、という感じで部屋を出ていった。それで、ぼくにも、これがたいしたものに見えないのだとわかった。たいしたものに見えないかもしれないけど、裏ではたいしたことをやっているんだよ、と人に説明するのは絶対に無理な話だ。君が道路をアスファルトで舗装したとして、それを誰かに見せた時と同じ程度の感動しか与えられない。
　
（『それがぼくには楽しかったから』P105、小学館プロダクション）

プログラミングにかぎらず、世の中には、知るにつれて見えてくる複雑な姿というものがあって、それを知れば知るほど、もう単純に説明することはできなくなってくる。

それについてよく知らないうちは、対象はツルンとした真球のように見えるけれど、よく目を凝らして、近づいていくと、表面には大小様々な穴が空いていたり、しわが刻まれていたり、あるいは日々それらが移動したりしていて、そうした要素からたくさんの情報を読み取れることがわかってくる。

「＊＊なんて、ようするに＋＋でしょ」という単純化／抽象化をできるのは、そうした複雑の極みを自分の中で消化しきった人か、まったくそれを知らない人のどちらかであると思われる。

関心がないのか、それとも知り始めた段階なのか

話を戻すと、初心者というのは、対象のそうした複雑な様相を知らないから、遠くからのパッと見た印象しか述べることができない。
それ自体は仕方のないことだけど、問題なのは、そうした言説が、その対象に対してまったくリスペクトを持たず、知ろうともしない人による言説とほとんど同じように見えるということだ。

対象に関心のない人は、いつまで経っても、その「複雑な姿」を知ることはない。関心がないことが悪いのではなく、関心がない対象に対して、それと気づかないままに言及するという行為が、その対象をよく知る（愛する）人たちの気分を時に害してしまうことが問題だ。

その対象をよく知る人は、対象の複雑な様相を知っているから、「そんな単純なものじゃないよ」と感じる。よく知らないくせに、そんな風に簡単に片付けないでくれよ、という気分になる。

一方、初心者というのは、対象に関心がないわけでも、愛情がないわけでもないが、にもかかわらず、持っている認識は関心や愛情がない人とほとんど同じ状況にあるから、その時点で言う内容や態度は避けがたく、愛情がない人のそれと近くなりがちだと思う。

このような時、周りの熟達者たち、つまりその対象をよく知る人たちには、それが初心者ゆえの単純化であるのか、そうではないのか、という違いを見分けることが役立つだろう。

進歩とは「不可逆な目盛りの増加」

そのような、初心者による避けがたい単純化について考えるたび、僕は「粗い目盛り」ということを考える。

ある種の家電で考えるとわかりやすいが、たとえば、人類初の扇風機に付いた機能は、おそらく「ON/OFF」の2択しかなかったはずだ。

しかし今は、風の強さだけでも「強・中・弱・微風・リズム」などの多種から選べるし、その上で首振り、リモコン操作、タイマー設定なども出来るようになっている。それらすべてが本当に必要な機能なのかという問題は別にあるとしても、とりあえず「ON/OFF」の2択だけに比べたら便利だし、そうした複数の選択肢は実際に求められている。

進歩とはそういうもので、初めはONかOFFかの両極しかなかったのが、徐々にその中間の段階、さらにそれらの中間の段階、というふうにパラメータ（目盛り）が増えていく。

アジサイの花を見たときに、赤・青・黄の3種類しか色の名前を知らない人だったら、「青い花だな」と言うかもしれないけど、紫色を知っている人なら「いや、紫色だよ」と言うかもしれないし、あるいは「いや、藤紫色が近い」と言うかもしれない。

熟達者はこういう色の種類を多く知っているし、そうでない人は何を見ても「赤OR青OR黄」のいずれかで表現することしかできない。

初心者が熟達者になっていく過程というのは、だからそうやって目盛りの数を増やしていくことだと僕は思う。

それは単に知識（知っている色の数など）を増やしていく、ということではなく（それを目的にする、ということではなく）、対象を適切に把握するために必要な道具・環境として、必要なことなのだと思う。

熟達の度合いが増すにつれ、「かつて手にした今は不要な目盛り」も出てくるには違いないし、それが上述の、「熟達者による単純化」を指すけれど、一度刻まれた目盛りは二度と完全には（それが刻まれる以前のようには）消えないだろう。

独学の作法

Perl入学式 text beginner

こちらは Perl入学式 Advent Calendar 2014 の6日目の記事です。
昨日は @trapple さんの「超テスト入門〜サブルーチン復習とrequire, use」でした。ついにコードが出てきましたね！

はじめに

前回の記事では、プログラミング初心者を「子供/大人」に分けて（便宜的にですが）、「大人」の入門者が陥りやすい問題や、それでも続けることの良さは何か、ということについて書きました。

今回は少し視点を変えて、普段から職業としてプログラミングに関わるプログラマーと、僕のように本業を別に持つ趣味プログラマー（非エンジニア）の違いから、後者の「普段プログラミングから離れた状況にある人」が、学習を継続するにはどうしたら良いか？ ということについて、徒然に書いてみたいと思います。

非エンジニアを待ち受ける難関

前回書いたように、僕の場合、ぼんやりとした興味から始まって、何とかプログラミング入門へのとっかかりを掴んだまでは良かったのですが、いざ学習をスタートしてみると、そこにはいくつもの困難が待ち受けていました。

なかでも、大きなものは以下の3点です。

1. サポーター（教えてくれる人）との文化の違い
2. 普段はプログラミング以外のことをしているため、せっかく学んだこともすぐ忘れてしまう
3. とにかく本やネットに書かれている説明が「わからない」

以下ではそれらの点を中心に、非エンジニアのプログラミング入門者が遭遇する課題と、その対策について考えていきます。

1. サポーター（教えてくれる人）との文化の違い

記憶と記録を辿ってみると、僕が初めて「Perl入学式」に行ったのは、去年の9月7日（土）でした。
以下のツイートを見て、


ああ、これはタイミングがいいな、と勢いに任せて申し込みました。

「タイミングがいい」というのはどういうことかと言うと、僕はその少し後に開催予定だったPerlの一大カンファレンス「YAPC::Asia Tokyo 2013」のチケットをすでに取っていて、しかし同イベントへの参加は初めてで、かつ知り合いもまったく居ない状況だったため、おそらく会場ではいわゆる「ボッチ」状態になって、ひどく場違いな、居づらいような気持ちになるのではないか……という不安を抱えており、そんなときに上記のツイートを見つけて、「Perl入学式」のサポーターはYAPC::Asiaに慣れたプログラマーたちだと知っていたので、YAPC::Asiaの前に彼らと知り合っておけば、同会場で味わう孤独からの苦痛も緩和されるのではないか、と思ったわけです。

果たして、YAPC::Asiaの前に「Perl入学式」に行ったことがボッチの苦痛を緩和したかと言えば、「そうであり、そうでなし」という感じでした。
というより、事前に「Perl入学式」に行っても、YAPC::Asiaのボッチ感覚は容赦なく（ある意味では、想像以上に）襲ってきて、それ自体は紛れもなくつらいものでした（笑）。

ただ、数百人規模の参加者が集まるYAPC::Asiaで感じる孤独感と、十数人の参加者から成る「Perl入学式」で感じるそれとではだいぶ様子が違いますから、ほんの短い期間のうちに、その両方を知ることができたという意味では、やはり先にPerl入学式に飛び込んでおいたのは良いことだったろうと思います。

さて、今サラッと書きましたが、僕は最初の「Perl入学式」においても、ボッチのつらさを感じていました。
といっても、それはべつにネガティブな意味でもなく、誰だって初めての場に一人で飛び込んだら、そうなるに決まっています。
もしも最初から見ず知らずの自分を大歓迎してくれる場があったら、ちょっと警戒した方がいいぐらいです。

ですから、孤独感それ自体は構わないのですが、その感覚をもたらした一番の理由は何だったのか、という点がおそらく重要で、それはきっと「文化の違い」というか、具体的には、「共通の話題がない」という点にあったのだと思います。

共通の話題がない

第一に、僕はその時38才で、しかしサポーターの皆さんは業界の若手が中心なので、せいぜい30代前半。20代の人も少なくありません。

それに加えて、ぼくはフリーの（ちょっと変わった媒体の）編集者で、普段でさえ共通の話題を持てる人など相当限られているのに、そうしたエンジニアの皆さんと共有できる情報などそうそうあるはずもありません。

さらに言えば、営業職の人などはまた違うかもしれませんが、基本的に僕が出会ったプログラマーたちは皆、名刺交換などをしません。これはなかなか新鮮なカルチャーショックで、「そんなことしなくても、TwitterやGitHubのアカウントがわかればそれでいいじゃん」という感じがあります。
（実際、僕は今年のYAPC::Asia 2014にも参加して、少なからぬ人たちと多くの話をしましたが、その間に交換した名刺はせいぜい1〜2枚でした）

つまり、同じ社会人同士であったとしても尚、ちょっと居る場所というか、住んでいる世界というか、水が違うというか、そんなところがあります。

そのように、世代・職業・慣例がことごとく異なるために、「こちらがこう投げたら、普通こう返すよな」と思うとおりに行かないことが続出します。

時間をかける（しかない）

では、このような状況に直面したらどうすればいいのかというと、結局「時間をかけて馴染むしかない」ということになると思います。

これに関連して、少し意外で、しかしちょっとホッとしたのは、今年のYAPC::Asia 2014 の最後にトークをされた @typester さんが、プログラマーのコミュニティに参加し始めた頃、先輩のハッカーたちの輪になかなか近づけなかったと言っていたことで、へえ、@typester さんですらそうだったのか、と思いました。

実はそのような話は他でも時々聞くことで、だから「文化が違う」とか「共通の話題がない」といったことに対しては、「まあ、そういうものだよな」とか、「誰でもそうらしいね」みたいに飄々と受けとめていくのが妥当なところだと思います。

ちなみに、その今年のYAPC::Asiaに関する感想は以下で書きましたので、よろしければぜひどうぞ。

また、前回も紹介しましたが、以下のスライドの最後の方では、僕とプログラミングの世界との距離感がだんだん縮まってくるように感じた経験について記しています。
https://speakerdeck.com/note103/hazimarifalseperl

2. 普段はプログラミング以外のことをしているため、せっかく学んだこともすぐ忘れてしまう

こちらはほとんど読んだままですが、僕はプログラミングに趣味として取り組みながら、普段はお金を稼ぐための仕事をしていますから、プログラミングの勉強をできる時間はとても限られています。

「普段仕事しているから、やりたいことは少ししかできない」という状況は誰でも同様でしょうし、これは当のプログラマーですら、仕事のために書いているプログラムと、自分自身やコミュニティのために書いているそれとでは異なるはずですから、結局状況は一緒なんだよと言うこともできますが、それでもやはり違うのは、本業がプログラミングにまったく関係ない人の場合、「頭の中」をガラッと、しかも何度も、入れ替える必要があるということです。

僕の場合はまだ、Macを使って仕事をしていますから、恵まれている方かもしれません。
もしこれが、コンピュータすら使わない仕事をしている人であったら、大変な度合いはもっと大きいかもしれないと想像します。

効率的な「素潜り」

これはもしかすると、僕個人の性格というか、気質に関わることかもしれませんが、とくに普段の仕事に対して、中途半端に取り組んでしまうと、どうにも効率が悪いです。

それは喩えてみると、「素潜り」に似ています。
水深5メートルまで潜った後に、一旦息継ぎのために海上へ出て、それからあらためて、「あと3メートル潜る」ということはできません。
もし5メートルまで潜って、プラス3メートル潜りたいと思ったら、そこでは息継ぎを我慢して、さらに深く潜らなければいけません。一旦海上に出たなら、また水深1メートルからやり直しです。

つまり、本業であれ、趣味であれ、それに集中すればするほど、仕上がりには良い影響が表れます。
そして、その両方を成立させようとしたら、どちらも中途半端になってしまうわけです。

そんなこと、あまりにも当たり前で、初めからわかっているつもりでしたが、いざ直面してみると、けっこう真剣に悩まされました。

仕事の手を抜くわけにはいきませんが、それでは他のやりたいことが出来なくて、何のための人生だかわからない。
かといって、学習を充実させようとすると、高まっていた仕事の集中力を一旦リセットしなければならず、プログラミングの基礎を復習しているその脇で、さっきまで時間をかけて作っていた本業の成果がみるみる色褪せていくことがわかります。

むずかる大人

もう一つ、これに並んでよく悩まされたのは、ストレスフルな、苛立ちの感情でした。気がつくと、一度学んで覚えたつもりの構文やルールをすっかり忘れていて、それまでに幾度となく見返したはずの参考書を、また頭から1ページずつめくって調べ直す……といったことがたびたびありました。（まあ、今もそうですが）
これは大変な苦痛をともなうもので、その憤りの矛先が自分でしかないということがまた、さらなるストレスを連れてきます。
よく子供が「むずかる」という表現がありますが、まさにその状態です。

こんな時には、ドラクエの「ふっかつじゅもん」のようなセーブ機能が人間にもあればいいのにな、とよく思います。今やっているプログラミングの課題は70%まで進んだから、一旦保存して仕事に移って、戻ったらまた70%の続きから再開できる、というような。

しかし実際には、70%のところで一旦やめて、仕事から戻ったら、進捗は一気に何十%も減退しています。
もしもそのまま続けていたら、その課題については100%まで完了できたのに、などと思い始めてしまうと、暗澹とした気分になってきます。

「ふっかつのじゅもん」はない

そういった状況に対する態度として、今は「諦めるしかない」と思っています。
随分あっさりした結論ですが、趣味と本業の反復横跳びをする以上、非効率は前提であり、少なくともこれまでのところ、それでもいいから、というつもりでやっています。

しかし、救いもなくはありません。たしかに、趣味と仕事の往復をする間に、せっかく溜めた資産は減ってしまい、少なからぬ徒労を感じますが、それがまったくのゼロに戻るということもないからです。

鉛筆で書いた文章がすべて消しゴムで消されたとしても、元の文章が大量であったり、筆圧が強かったりすれば、すべてを消しきることはできないように、懸命に学習したことがすべて無駄になる、ということはあり得ないと思います。

確かに、前回ストップしたのとまったく同じ場所からリスタートできれば、効率的ではあるけれど、現実はそう上手くはいかないのだし、まったくのゼロに戻ったわけでもないのだと認識を切り換えると、いちいち落ち込むことは少なくなります。

3. とにかく本やネットに書かれている説明が「わからない」

そうした非効率さの話ともつながりますが、最初のうちはとくに、何をやっても上手くはいきません。
これは冷静に考えれば、「学習の進み方が遅いために、結果が出るのも遅くなる」という至極当然のことだと考えられますが、本人は焦ります。
何しろ、仕事にも影響が出かねないぐらい取り組んでも、なかなか成果が目に見えないわけですから。

僕はよく、自分自身を表す喩えとして、「吸い込みの悪いスポンジ」という表現をします。
スポンジに、上からヒシャクで何度も水をかけるのだけど、いつまでもカラカラのままで、まったく水分が中に入っていかない。自分はまさに、それだなと。

そしてこれに対して、僕にできることは、素材自体はもう仕方ないのだから、あとはしつこく水をかけ続けるか、スポンジに重りを括りつけて水中に沈ませて、時間が来たら引き上げる、みたいなことしかやりようがないと考えています。後者を現実の場面に置き換えると、「まとまった時間をとって集中的にやる」みたいなことになるでしょうか。

教える側もいろいろ省略している

一方、本などが「わからない」という状況は、たしかに自分自身の（能力が足りていないがゆえの）問題でもありますが、実際には、その本自体の不充分さによる場合も少なくないと思います。

一つの本が説明できることは、常にその対象（題材）の一部に過ぎません。それは人為的な理由によるものかもしれませんし（前回の記事に書いた「初心者の視点を持てないパラドックス」など）、ページ数が充分でないから、という物理的な理由によるかもしれません。

よって僕としては、もし一つの本について「よくわからないな」と思ったら、それを「自分のせい」だと即断するのではなく、セカンドオピニオン的に、同じ対象を扱う別の本（またはネットの記事）を読んでみることをお勧めします。

本に書かれている説明は、川の両岸をつなぐ飛び石のようなもので、もし飛び石が均等かつ細かく置かれていれば、人は歩いて対岸へ渡ることができますが、途中で途切れていたら、それ以上先には行けません。
複数の本（あるいはネット上の記事など）を参考にすると、その抜けていた隙間が埋まり、求めていた対岸へ渡れることがあります。

技術書というジャンルは、通常の書籍に比べると単価が高いので、そうそう買い込むことはできないかもしれませんが、特定の内容を信用しすぎない、という姿勢には役立つ面があると思います。

ハマることを許す

ところで、「Perl入学式」では、受講生に対してよく「一人で考え込むのもいいけれど、ある程度考えてわからなかったら聞いてしまった方が早い。だから遠慮せずにサポーターに質問してください」という呼びかけを行います。

これは確かにその通りで、一人で何時間かけて考えても、辿りつきようのない発想というものはあって、そこで時間をつぶすのはもったいない、と考えることは妥当です。
とくに、これが仕事上のことであったら、目的は悩む過程よりも問題解決ですから、一人で抱え込むことは会社に損失を与えることにもなりかねませんし、その意味でも「すぐに聞く」という習慣を持つことは悪いことではないでしょう。

しかし僕個人としては、「わからない」という状況でじっと考えこむ時間は、旅の車窓からそれまでに見たことのない景色を眺めるように、新鮮な感覚を味わえる貴重な機会でもあり、状況によっては、「本人がハマりたければいつまでもハマっていればいいのではないか」とも思います。

問題なのは、結局それがわからなかったときに、嫌になってすべてを放り出してしまうことであって、何時間ハマったところで、それが本人にとって楽しく、仮に解答を見て自分のダメさ加減を思い知ったとしても、再び立ち上がり次の問題に取り組めるのなら、それで良いと思います。

あまりにも長い時間、わからない状態に身を置きすぎてしまうと、そのこと自体にうんざりしてしまうことはありえるので（これは薄着で寒中に居るうちに風邪をひくことに似ています）、諦め時の見極めは難しいかもしれませんが、楽しめるうちはいくらでも考えていればいいのではないか、と。

Perl入学式の講義資料

最後に、Perl入学式では数年分の講義資料を公開しています。
Handout - Perl入学式 | Perl Entrance

Perl入学式は東京・大阪・福岡で定期的に開催されていますが、地理的にも、仕事の都合的にも、現実的に参加が難しいという人もいると思いますので、そのような場合には、ぜひ独習に使ってもらえたら嬉しいです。

一方、この資料は、あくまで勉強会におけるワークショップ（実際に手を動かしてわからなければ直接質問する）とセットで使用することを念頭に置いて作成していますから、これだけで完結するものとしてではなく、また上では、書籍やネット上のテキストを信用しすぎないようにと書きましたが、それはある意味伏線で（笑）、この資料も完璧ではないという前提で、時には同じ題材を扱う他の資料と併読しながら、有効に活用してもらえたらと思います。

ちなみに、Perlは歴史の長い言語で、ネット上には玉石混交、あまり真に受けない方がいいような情報も多くあると聞きますが、個人的には、「玉」も「石」も両方知って初めて「玉」の価値がわかるとも思いますので、とりあえず何でも手を出して、どんどん失敗していけば良いのではないか、と思います。

まとめ

では、今回のまとめです。

  • 非エンジニアの場合、教えてくれる人との文化の違い（カルチャーショック）や、
  • 「二兎追うものは一兎をも得ず」的な非効率に悩まされることもあるが、それらは不可避の前提であり、同時に、時間をかければ徐々に解消できる（はず）。
  • 本やネット上の説明ではわからないことも多いが、それは説明が（原理的に）不充分であるせいかもしれないので、複数の資料を参考にしてみよう。

みたいなことでした。

以上で Perl入学式 Advent Calendar 2014 第6日の記事はおしまいです。
最後までお読み頂き、ありがとうございました。

明日は、@tomcha_ さんの「ぬか漬のすゝめ」です。期待できるタイトルですね。どうぞお楽しみに！

38才からのプログラミング入門

text Perl入学式 beginner

こちらは Perl入学式 Advent Calendar 2014 の4日目の記事です。
昨日は @xtetsuji さんの「いつもの風景」でした。 お寿司いいですね。

はじめに

さて、「Perl入学式」はプログラミング初心者およびPerl入門者のための無料の勉強会です。
最近の傾向としては、他のプログラミング言語の経験はあるけれどPerlには馴染みがないから来た、という参加者も少なくないようですが、僕自身はプログラミング自体まったくの初心者という段階から参加し始めました。

ただ、ひとくちに「初心者」と言っても、「子供の時期から学ぶのか、大人になってから学ぶのか」では大きな違いがあると感じます。
よって以下では、自分の体験にもとづいて、後者の「大人」（とくには30代以降の社会人）がプログラミングに初めて触れることについて、徒然に書いてみたいと思います。

極私的な入門記

僕は現在、39才＋7ヶ月で、来年の春には40才になります。そして、プログラミングをやってみようと思い立ったのは去年の5月、38才になってすぐの頃でした。

僕はちょっと変わった書籍（CDブック）の編集者で、それまでもMacでInDesignやエディタ（当時はCotEditor）を使用していましたが、ターミナルに触ったことはほとんどありませんでした。（何かの拍子に間違って立ち上げるぐらいで、アプリケーションがどこにあるかも知らなかった）

上では「思い立った」と書きましたが、いきなり「やってみたい！」と思ったわけではなく、以前から何となくやってみたいなあ……とは思っていて、たぶん元々 Remember the milk や delicious のようなWebアプリケーションを使っていたり、Firefoxのアドオンを充実させてみたり（よくわからないままGreasemonkeyをいじったり）、ブックマークレットの一部を書き換えてカスタマイズしてみたりはしていて、またその一方で、@N さんの『ぼんやりと考えたこと』や渡辺千賀さんの『On Off and Beyond』といった読み応えのあるブログ、あるいは37signalsの『Rework』や『リーン・スタートアップ』のような技術者寄りの本も実益をかねてというか、ライフハック（業務効率化）的な見地から時々読んだりしていたので、気がついたら自分が楽しんでいるもの、触れているものが、エンジニア/プログラマーたちのそれと重なってきていたというか、それで半ば必然的に、自分でもプログラミングをやってみたいという気持ちになったのかな、とも思います。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

  • 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢　健二,松永　肇一,美谷　広海,祐佳　ヤング
  • 出版社/メーカー: 早川書房
  • 発売日: 2012/01/11
  • メディア: 単行本
  • 購入: 21人 クリック: 325回
  • この商品を含むブログ (35件) を見る
リーン・スタートアップ

リーン・スタートアップ

入門書のパラドックス

さて、そのように志したプログラミング入門ですが、いざとなると、どこから始めたらいいのかわかりません。普通に考えると、まあ、本を買いますね。『ノンプログラマのための〜』とか『ゼロからわかる〜』とか、そういういかにも敷居が低そうな、読者を責め立てなさそうな、間違っても全力で否定してきたりしなさそうな書籍を選びます。

しかしながら、そういう本が本当にわかりやすいかというと、これは微妙です。というのは、そうした本の作り手を非難する意味ではなく、至極原理的な問題として、「初心者のための本を作る人は初心者ではないがゆえに初心者の気持ちがわからない」という、ジレンマというかパラドックスというか、そういう有史以来の難問があるわけです。

立ち直りや改善を邪魔するもの

ここで冒頭の話に戻ると、こうしたつまづきに直面したとき、子供と大人とでは生じる対応が異なると思います。

子供は毎日が失敗の連続ですから、簡単に癇癪を起こしたりもする一方、そこからの立ち直りや順応も早いものですが、30代も半ばを過ぎた大人で、何らかの職についていて、たとえば自分の部下や同僚に指示をする立場にもあるような人の場合、すでに人生のスタイルというか、ノウハウというか、固定観念とも言えるオレオレ・ルールが出来上がっていて、どうしても簡単に方針を切り替えたり、順応したりということがしづらいものなのだと思います。（というか、まあ、僕がそうだったわけですが）

それは言い換えると、過去の様々な成功や失敗の体験に縛られて、妥当な判断ができなくなるということでもありますが、同時に、「望まない状況をつい我慢してしまう（できてしまう）」ということでもあると思います。

普段の生活や仕事において、これは不合理で非効率で理不尽だなあ、と感じることがあっても、それを変えないまま何となく乗り切ってしまった経験があると、その後も「こうしたらもっとラクになるのでは？」といった改善の発想をしづらくなるのではないかと。

そしておそらく、大人のプログラミング入門に際して一番足を引っ張るのは、この「つい非効率に耐えてしまう」というやつではないかと僕は考えています。

ショートカットキーとコマンドの組み合わせを使えば一瞬で終わるはずの作業を、延々と何百・何千のコピペ作業で乗り切って（？）しまい、挙句の果てにはそこから達成感・充実感すら得てしまうのがここで言う「大人」であって、これが子供ならば、途中で投げ出して別の方法を考えるなり、別の遊びに飛びつくなりするでしょう。

そしてやがて、我慢の限界に達してしまった「大人」の方はどうなるかと言えば、日毎に訪れる本業の忙しさや煩わしさも手伝って、「こんなのくだらないや」とばかりに入門は断念、という結果に終わることも少なくないのではないかと想像します。

プログラミング学習の利点

しかしそれは、もったいない。プログラミング入門は、「コピペ何百」の習慣から抜け出す絶好のチャンスであり、自分の人生（という名の限られた時間）をより深く味わうための入口になりうるだけでなく、その人の作業が効率化されることにより、周りの人々にも好影響がもたらされるきっかけにもなるからです。

そしてまた、本業がエンジニアではない人がプログラミングの世界に入ることにより、普段プログラミングを生業としている人たちにも、それまでになかった新鮮な空気が送り込まれる可能性が生じます。

普段プログラミングをしている人たちは、書籍編集の世界がどのように動いているかについてはほとんど知らないでしょう。その時、僕はそれについて彼らに何かを教えることができるかもしれませんし*1、それにかぎらず、日々の本業を通して得た知識や経験を持って、エンジニアの世界に何かしら貢献することができるかもしれません。

それは本業が美容師や医師や漁師であっても同じことで、様々な現場で育まれた経験や考え方を持つ人々が、プログラミングという、理知的で論理的な裏付けによって支えられた（時には黒魔術とも呼ばれはするにせよ）世界やその法則を通して、一つの場を共有することができるのです。

なぜ Perl か？

プログラミング言語Perl（パール）は、その貴重な第一歩を踏み出すに相応しいパートナーであると思います。
同じLL（Lightweight Language）と言われるRubyやPHPも同様に入門言語として適していると思いますが、僕の印象では、Perlはより手作り感覚に満ちた道具というか、仕組みが見えやすいようなところがあって、言い換えれば、最初にこれを押さえておくと、後からいろいろ応用が利きそうで、その点においてお勧めできます。

喩えて言うなら、Perlは木工細工やブリキの玩具、複雑と言ってもせいぜいモーターを使った科学工作的なもので、すでに商品として仕上がったものであっても、自分で分解して、また戻す、という楽しみ方ができそうです。
（といっても、Rubyやその他の言語をよく知っているわけでもないので、それらと比べてどうという話ではなく、その意味ではあまり説得力もないのですが）

なぜ Perl入学式 か？

そしてまた、ここでようやく再登場する「Perl入学式」は、そのPerlの基礎を学べる勉強会であり、東京・大阪・福岡の三都市で定期的に開催されていること、無料であること、また受講する条件として年齢や所属などの制限を設けていないことなどから、類似する講座などに比べてもとくに参加へのハードルが低くなっていると思います。

講師（あるいは「サポーター」）は、現役のプログラマーや前年度までの卒業生から成り、彼らは必ずしも手練のベテラン技術者や講師業のプロなどではありませんが、そうであるがゆえに、ちょっとした（わざわざ聞くのも申し訳ないような）疑問についても気軽に相談することができます。

書籍を通してプログラミングを学ぶ場合、たしかに本そのものは読者を否定することはありませんが、限られた情報しか掲載できない媒体の性質上、それだけをもとに成長していくことは困難です。（本からのみ多くを学べるのは、すでにその分野にある程度習熟した人でしょう）

一方、時間の捻出や体調管理といった、いくらかの現実的な調整が必要であるとしても、「Perl入学式」のような場を合わせて利用すれば、それまで上手く言語化できなかったような曖昧な疑問についても、現場のサポーターたちと細かく認識を共有することができ、入門初期の幾多の困難も乗り越えやすくなるはずです。
そしてこの恩恵に最も与れるのは、僕の考えでは、子供よりも、固定観念にとらわれてしまった大人の方です。

ブログを書こう

勉強を進めていく際には、共に受講する同期の生徒の動向や、進度も大きな刺激になるでしょう。
そして、この刺激をより活性化させるために、ブログを書くことは非常に役立ちます。一見するとあまりにも愚かに思える、顔から火が出るほど恥ずかしい失敗も、ブログに書いてみると、「案外大したことないな」と思えますし、それを読んだ別の人には思いがけず役立つ知見になったりします。

今回のAdvent Calendarは、Perl入学式に関わる人たちが普段どんなブログでどんなことを書いているのか、一望できる良い機会だと思います。ぜひ引き続きチェックしてみてください。

まとめ

長くなりましたが、ここまでの話を簡単にまとめると、

  • もし大人になってから「プログラミング入門」を志したなら、まずは身にしみついた「思い込み」や「不毛な我慢」を捨て、
  • 初めは本だけを読んでいても大してわからないので、「Perl入学式」のような場で直接質疑応答を重ね、
  • そこで得た学びをブログに書いて、それを繰り返し、少しずつ成長していく中で、
  • 今度は自分が持っている非エンジニアならではの観点や、本業で育んだ知見をフィードバックし、コミュニティに貢献していこう。

みたいなことでした。

なお、僕のプログラミング入門に関わるあれこれについては、以前に発表した以下のスライドにもまとめてあります。
https://speakerdeck.com/note103/hazimarifalseperl

つい先日、その発表時のイベントについて、Perl入学式のサポーターであり、昨日の執筆者でもある @xtetsuji さんがブログを書かれていましたので、よろしければ合わせてどうぞ。
YAPC::Asia Tokyo 2014 Reject con #yapcasia #yapcasiareject | #interest_ae

以上で Perl入学式 Advent Calendar 2014 第4日の記事はおしまいです。
明日は、@trapple さんの「超テスト入門〜サブルーチン復習とrequire, use」です。お楽しみに！

*1:これはじつは言葉の綾で、最初に書いたとおり、僕が作っている本はちょっと特殊な物なので、僕も一般的な書籍編集についてはほとんど何も知りません。

昨日買った本（NginxやVim scriptやSoftware Design）となぜプログラミングを学ぶのか

vim text book

以下にザックリ書いたけど、この1年ずっと携わっていたプロジェクトがようやく収束に向かいつつありまして、

おかげでというか、昨日数カ月ぶりに散髪にも行きましたが、その帰りに近所で唯一テック系の本がそこそこ揃っている書店で3つ買ってきたのでブログに残しておきます。

最初はこれ。

Vim script テクニックバイブル ~Vim使いの魔法の杖

Vim script テクニックバイブル ~Vim使いの魔法の杖

発売当初に同書店で買うつもりで立ち読みしたんだけど、スタープレイヤーが何人も参加しているにもかかわらず、どのテキストを誰が書いているのか、とかが明示されておらず、巻頭言（というか）もチーム名で記載されていたりして、ぼくは「何が書かれているか」より「誰が書いているか」を重視するタイプなのでそのときは棚に戻して見送った。

で、しかし知りたいことが書かれているだろうとは想像されており、これまでは「そんなに急いで読みたいわけでもないから」と冷静に後回しにしていたけど、上述のようにさしあたって急ぎの仕事も収まり、多少余裕ができたから、ということで「誰が書いているか」はわからないものの「何が書かれているか」への興味の方が勝ったようで、ようやく買った。

他に買ったのが、これとこれ。

マスタリングNginx

マスタリングNginx

Software Design (ソフトウェア デザイン) 2014年 11月号 [雑誌]

Software Design (ソフトウェア デザイン) 2014年 11月号 [雑誌]

このところISUCONがすごく盛り上がっていて、
http://isucon.net/
ISUCON4 まとめ : ISUCON公式Blog

以前から「サーバーってなんだろ・・知りたい・・」とかすごい思っていたこともあり、機運に乗る感じでそれっぽいのを買ってみた。

最初に買う本としてはなんかちょっと違う気もするけど、どうせ1〜2冊で全部わかるなんてことがあるはずもなく、5番めに買うか2番めに買うかの違い程度のことだろうから気にせずコレ、と思える＆たまたまその店にあったのを買った。

ぼくがプログラミングに興味を持った理由には、自分が毎日使っている道具の裏側・仕組みがどうなっているのか知りたい、知らないまま使うのが不安で仕方ない、もしそれが壊れたり、それの挙動に対して不満がつのったときには自分でも何とかできるようになりたい、などの欲望が一つあって、また一方で、そうしたものを作る現場の人たち（ようはプログラマー、エンジニア、Perlモンジャーにルビースト、Vimmer等々）が毎日嬉々としてそれ（仕事なのか何なのかよくわからないそれ）をやっている姿を見て、ああうらやましい、ぼくもそこに入りたい、というかそんな感覚や雰囲気を味わいたい、というのがあって、それでやり始めた、というのがあるので、「お前、Nginxとか知ってそれからどうすんだよ（笑）」とは自分でも思うけどでも面白そうだからってだけだよ、と言うしかない。

最近思ったが人生に「あとで読む」はない。いや、あとで出来るときもあるが基本的には思いがけず幕切れを迎えたり中途半端に終わるのが人生で、たとえば「80まで生きていいよ」なんて誰も約束してくれないから常にそれが最後の瞬間だと思っていないと勿体ない。
ああ、ずっとやりたかったあれ、あのときに手を出しときゃ良かった、なんて死ぬ前に思っても遅い。人生は後々完成させるものではなくつねに完成させていなければならない。

プログラミング入門時に到来する避けがたい痛みについて

text beginner

久しぶりに正規表現で「これどうすんだっけ」と思ったので『雅なPerl入門』（第二版）を開いたけど（調べた結果自体は想定した通りだった）、入門初期はこの頻度が多すぎてかなりストレスだったことをあらためて実感した。この強力なストレス、いかんともしがたい自分への苛立ちみたいなものが入門初期の大きなヤマで、これを乗り越えられるかどうかがその後を左右する気はする。

教える側が「俺も通ったわーその道」と思ってもそのストレスを現に逃れがたい事実として感じているのは当事者の方なのでそれを軽視しないことがより適切なコーチングにも繋がるとは思う。歯痛や腹痛に苦しむ他人を見て、「俺もよくなるわーそれ」と思っても同時に同じ痛みを感じられないのと同様。

ちなみに乗り越えられるかどうかに対してこれ、という解決策はナイというか、あるかもしれないけどそれ自体にはあまり意味はなく、というのも結果的にクリアした人たちの用いた方法というのは、ある程度の傾向はあるとしても具体的にはマチマチだろうと思われるから。たまたま乗り越えた、という人もいれば仕方なくやってるうちに慣れた、という人も少なくないと想像する。ここで言っているのはだから乗り越える方法、とかではなくその痛みを軽視はできないということ。