独学の作法

こちらは 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代の人も少なくありません。

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

さらに言えば、営業職の人などはまた違うかもしれませんが、基本的に僕が出会ったプログラマーたちは皆、名刺交換などをしません。これはなかなか新鮮なカルチャーショックで、「そんなことしなくても、TwitterGitHubのアカウントがわかればそれでいいじゃん」という感じがあります。
(実際、僕は今年の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_ さんの「ぬか漬のすゝめ」です。期待できるタイトルですね。どうぞお楽しみに!