プログラミング入門を支える技術
- こちらはPerl入学式アドベントカレンダーの21日目の記事です。
- 昨日は@karkador73さんの「Perl入学式に参加して、いろいろ刺激を受けた件」でした。
- さて、本日の記事では、ぼくが普段プログラミングに触れながら考えていることのうち、あまり他では聞かないというか、むしろ通常言われるセオリーみたいなものとは逆な気もするけど、人によっては役立つかもしれない視点というか、方針について、いくつか書いてみたいと思います。
- 先に簡単に自己紹介をしておくと、ぼくは普段はフリーの編集者として過ごしていて、今はおもに坂本龍一さんの音楽全集「schola（スコラ）」の制作に携わっています。
- じつはたまたま本日12/21（水）、1年ぶりとなるシリーズ最新刊が発売されました！！
- いやー、偶然だなあ。（ハハ）
- 公式ページのどこかにぼくの名前もあります。（→公式ページ）
commmons: schola vol.16 Ryuichi Sakamoto Selections: Japanese Pop Music
- アーティスト: V.A.
- 出版社/メーカー: commmons
- 発売日: 2016/12/21
- メディア: CD
- この商品を含むブログを見る
- それ以外だと、去年の夏頃に山口県のYCAMという文化施設のWebサイトのリニューアル・プロジェクトに参加したりしました。（→参考記事）
- そんな中、プログラミングは趣味として、2013年の春頃に始めました。そして同年夏からPerl入学式に生徒として通い始めて、翌年から生徒出身のサポーターとして活動に加わっています。
- だから、というわけでもないですが、この記事で想定している「プログラミング入門者（初心者）」は、とくにITの仕事をしているわけでも、それを志しているわけでもない、「一般人だけど趣味で始めてみた」というような人です。
- よって、IT企業の新人さんや、そうした進路を検討している情報系の学生さんなどはちょっとズレますが、部分的には参考にしてもらえるところもあるかもしれません。
- また、上記のような初心者に「教える立場」の人にも、参考になる要素があるかもしれません。
Contents
1. 明確な目標はなくてもいい
- 少なからぬ書籍やネットの記事において、「まずは学習を始める前に、プログラミングでどんなものを作りたいか、具体的にイメージしてみよう！」なんてことが言われます。
- その心はと言うと、「目標が曖昧だと何をやればいいかわからなくて、無為に時間が過ぎるから」とか、「ゴールがはっきりしていれば必要な学習内容に集中できるから」ということのようですが、そこまで聞いても、ぼくにはこれは奇妙な方針だと思えます。
- もしあなたの目の前に、初めて見る精巧な機械をポンと置かれて、「使い方は後で教えるから、まずはこれで何を作りたいか具体的にイメージしてみよう！」と言われたらどう思うでしょうか？
- プログラミングの初心者とは、プログラミングに関する知識がない（または少ない）人ですから、まだそれを教わっていない段階で、「それを使って何ができるのか」を想像させるというのは矛盾があります。
- しかし現実には、そうした要求をする「教える人」が少なくないように見えます。なんでだろう？ と以前は不思議に思っていましたが、これはおそらく、「教える側にとって都合がいいから」ではないか、と今は思っています。
- たしかに生徒さんの方から、「ぼくは掲示板を作りたい！ Twitterアカウントでログインできて、画像も投稿できるようにしたい！」などと具体的なリクエストを言ってくれれば、「なるほど、じゃあそのためにはこの言語を覚えて、この知識を身につけて……」という具合に、何を教えたらいいのか、自然と決めやすくなるかもしれません。
- 一方、「いや〜……とくに何を作りたいとかはないんだけど、とにかくプログラミングをやりたいというか……」などとぼんやり言われてしまうと、教える側としては、提示できる選択肢が無限に広がってしまい、「もう少し具体的に注文してよ！」という感じになってしまうのかもしれません。
- しかし上記のとおり、初心者が知っている「プログラミングで実現できること」なんていうのは、「ない」か、あってもせいぜい数種類しかないはずで、しかもそのなけなしの選択肢ですら、本人が「本当にやりたいこと」かといえば、怪しいものだと思います。
- 今書きながら気づきましたが、これっていわゆる「顧客が本当に必要だったもの」問題を想起させます。
- ぼく自身のことを振り返ってみると、最初に「プログラミングをやりたい」と思ったときに頭にあったのは、「黒い画面になんか打ち込みたい」とか、「英数字でカッコよく構成されたあれ（ソースコード）を書きたい」みたいなものでしかなかった気がします。
- それは「先に作りたいものをイメージしよう」と助言してくれる人が期待する答えからは程遠いものかもしれませんが、それでもぼくが一番求めていたのは、そんな曖昧で、とらえどころのない憧れのようなものだったと思います。
- 「作りたいもの」なんてなくても、プログラミングの学習はできます。後述のとおり、すぐに（最短ルートで）求めるものに出会うことはできないかもしれませんが、続けていれば必ず、どんな曖昧な憧れであっても、近づいていくことができます。
- 少なくとも、ぼく自身は入門から3年半が経った今、かつて思い描いていた上記のようなことは普通にできるようになりました。
- 一応責任をもって、「作りたいものがなくてもプログラミングの学習をスタートする方法」を示しておくと、「入門書を読みながらサンプルコードを動かしていく」という方法があります。Rubyなら「たのしいRuby」、Perlなら「かんたんPerl」か結城浩さんの入門書、Pythonなら、未読ですが「独習Python入門」あたりが良さそうです*1。
- もし希望する言語がないのであれば、上記のようなプログラミング入門書の中で、一番表紙の雰囲気が好きなものにするといいと思います。
- 動画サイトの「ドットインストール」も良い選択肢だと思います。無料ユーザーにもたくさんのコースが開かれているので、明確な目的がない入門者でも自分の好みに近いレッスンを選びやすいですし、動画1本につき3分なので、ちょっと試して合わなければすぐ次を試したり、スキマ時間に気軽に始めたりすることもできます。
- 念のために付け加えておくと、初めから「プログラミング自体は目的ではなく、自分のやりたいことを実現するための手段である」と、明確に目標を意識化できている人は上記の限りではありません。
- また、すでに初心者的な段階を終えて、「プログラミングでどんなことができるのか」ということをある程度想像できる人であれば、「先にゴールを定めてから学習に取り組む」という方法も有効かもしれないと思います。
2. エラーは無理に読まなくていい
- プログラミングの入門初期には、「本やネットに書いてあるとおりに実行しているはずなのに、想定どおりの挙動をしない」ということが多々あります。
- そのようなときに、入門者はコンソールに出てくるエラーをろくに読みもせず、自分で書いた（あるいはコピペした）コードをじっくりまったり読み返しては、何度も同じエラーを出し続ける、ということがよくあります。
- そしてこのとき、教える側の人は、「エラーメッセージをちゃんと読んで！」と言います。これはまったく正しいアドバイスで、その点に文句はないのですが、そのアドバイスが果たして有効に働くのかと言えば、あまり有効ではないとも思います。
- 初心者にとって、コンソールに出てくるエラーというのは、もはや文字ですらない帯状の模様です。
- その中のどれが英語で、どれが数字か、という見分けさえすぐにはつきません。
- もし初心者と熟練者が、同じエラーメッセージを同時に覗き込んでいたとしても、両者が見ているのは別物です。おそらく熟練者は、行番号や主要なキーワードを真っ先に見つけているはずですが、初心者はそのメッセージにおける「どの単語がどの単語より重要なのか」という優先順をつけることができません。
- また、普段からプログラミングをしている人は、エラーメッセージが出てきた時点で、「またコイツか……」とばかりに「以前にそれを見たときのこと」を思い出したり、仮にそれが初めて見るエラーメッセージだったとしても、かつて経験したエラーをもとに原因の「仮説」を立てたりしているはずですが、初心者にはそうした過去の蓄積が少なく、経験していたとしてもすぐに忘れてしまっているので、結局毎回メッセージの行頭から、見慣れない文言を一つひとつ読み解いていかなくてはいけません。
- またそれと似た話で、「初心者はエラーメッセージが英語だから読みたがらない」ともよく言われますが、ぼくは「英語」はあまり関係ないと思っています。
- もし「Undefined subroutine ..」の代わりに、「指定されたサブルーティンが定義されていません」などと丁寧な日本語のメッセージが出てきたとしても、経験の浅い初心者には英語と同様の難解さがもたらされるでしょうし、逆にその日本語を理解できるなら、英語であっても理解できるはずです。
- つまり、問題は英語の能力や、本人のやる気の有無にあるのではなく、初心者は「なぜエラーが出たのか？」という文脈を想像できないがゆえに、エラーメッセージを「目に入れる」ことはできても、その意味するところを「読み取る」ことができないのだと思います。
- そうした前提を踏まえつつ、ぼくが思うのは、「エラーメッセージなんて、慣れれば自然に見るようになる」ということです。
- エラーメッセージは、プログラマーが離れたいけど離れられない悪友のような存在であると同時に、忌憚なく、しつこくミスを指摘し続けてくれる親友でもあるので、やがて自分が何をやっているのか理解しながらコードを書けるようになれば、進んでその声に耳を傾けるようになるはずです。
- 逆に言えば、苦しい思いをしてまでエラーを読んで、プログラミングに忌避感を抱いてしまうぐらいなら、気が済むまで何度でも、それを見慣れて頭に染み込むまで、同じエラーを吐き出させ続ければよいと思います。
- ここでも一応付け加えておくと、これは「初心者にエラーを読めとか言うな」という話ではありません。むしろ読むように言うべきですが、ただ、もしあまり積極的にエラーを読まない初心者がいたとしても、それは怠慢や指導者への反抗心によるものとは限らなくて、上記のような理由があるからかもしれないよ、ということです。そして、教える側がそのように思えれば、無用な軋轢を避けやすくなるのではないか、みたいな話です。
3. 先生が間違っているかもしれない
- このアドベントカレンダーの本体である「Perl入学式」は、プログラミングの初心者（またはPerlの初心者）に、無料でプログラミング言語Perlを教える有志による講座ですが、講義に使用する資料（教科書）もすべてメンバーがイチから作成しています。（→今年の資料）
- ぼくもその作成者の一人ですが、メンバーの中に職業としてプログラミングの講師をしている人は一人もおらず、みな自分の仕事の合間に時間を持ち寄って取り組んでいるので、残念ながら（というか）、資料中の不備や間違いも絶えません。
- 一方、講義を受講する生徒さんにとって、ぼくたちスタッフはいわば「先生」ですから、基本的には「間違っていない」ことが前提になります。
- よって、資料の中に誤記や、意味の通らない説明、問題文などがあっても、生徒さんによっては「わからない自分のほうが悪い」と思ってしまい、実際には教える側のミスなのに、それに気づかないまま少なからぬ時間を過ごしてしまう、ということも起こりがちです。
- そしてこのようなことは、じつはプロが作った入門書や技術書でも起こることで、たとえば本の途中から、それまでに一度も説明していない用語や概念を使って話を進めてしまい、それ以降は読者を置いてけぼりにしてしまうような本もよくあります。
- 商業出版物でもそんなことが起きてしまう理由には、そうした技術書が必ずしも「執筆のプロ」によって書かれているわけではない、ということがあるのではないかと思います。
- 小説家や評論家、あるいは各種のメディアに寄稿する本職のライターなどは、みな執筆のプロですが、プログラミングなどを扱う技術書では、執筆で生計を立てているわけではない、それぞれの専門的な分野で活躍する人が文章を書く、ということが多々あり、それは言い換えると、「執筆のプロではない人が執筆している」という状況です。
- 言うまでもなく、そうした状況が悪いわけではなく、そうでなければ生まれなかった名著も数え切れずあるはずですし、むしろそのような「執筆のプロではない人が書いた良書」を生み出すために、「編集者」と言われる人々が読者と執筆者の間に入り、わかりづらい表現や各種のミスを修正して回るわけですが、とはいえ編集者にできることにも限りがありますから、やはり書き手が執筆のプロであるかどうか、という点はどうしても影響してくるところだろうと思います。
- ちなみに、個人的に思う「執筆のプロ」とそうでない人の一番の違いは、「読者の視点で自分の文章を読めるかどうか」という点にあると思います。それは「読者に対する想像力」とも言えるもので、たとえるなら、幼稚園の先生が何人もの園児たちを引率して外を歩くとき、園児がちゃんと自分についてきているか、つねに振り返って確認しながら先頭を歩く姿に似ています。
- ぼく自身はこのような、「読者がちゃんとついてきているかどうか」を想像しながら文章を書ける人が「執筆のプロ」だと思っています。
- 話を戻すと、書店で売られている本だからといって、必ずしも安心して身を委ねられるわけではない、ということです。もし入門書などを読み進めているときに、よくわからない説明などに出会ったら、「自分が悪いはず」と思いすぎず、「この著者の表現がわかりづらいのではないか？」と疑ってみることも必要だと思います。
4. 最短ルートはないけど遠回りもない
- よく経験者からの助言で、「自分はAの勉強より先にBの勉強をしていたから、効率がよかった」とか、「私は間違ってAの勉強から始めてしまったけど、時間の無駄だった。Bからやればよかった」といったふうに「学習の最短ルート」を示すような話を聞くことがありますが、ぼくはこういう話はちょっと怪しいと思っています。
- 上記の「A」「B」には、「HTML」や「JavaScript」、「C言語」や「データベース」といったプログラミングの学習対象を適当に入れてみてください。
- というのも、これがもし資格試験のように、過去の出題データをもとにして、その後の傾向をある程度予測できる分野であれば、効率的な学習の最短ルートを分析したり、体系化したりすることも可能かもしれませんが、一度しかないその人の人生から導き出される「別の方法をとっていれば云々」というタラレバの話は、実際にはとくに検証されたわけでもない、根拠のない思い込みに過ぎない可能性があるからです。
- もし、「Aが駄目だったからBを試したらうまくいった」という人がいたとしても、それはもしかすると、「先にAを試したことが助けになって、その後のBがうまくいった」のかもしれませんし、いずれにせよ、その人が時間を遡って、他のすべての条件を同一に揃えて、別の方法を検証することは原理的に不可能です。
- さらに言えば、100人の学習者がいれば、100通りのスタート地点があり、100通りのゴールがあるはずです。仮に、誰かにとって最短ルートの方法が見つかったとしても、それが他の人にも同様に作用するかと言えば、そのような保証はどこにもありません。
- つまり、学習において、事前にわかる最短ルートなんて存在しないということです。
- と同時に、最短ルートがないということは、遠回りもない、ということです。それが無駄な努力だったなんて、証明できる人はいません。
- 学習というのは、続けるかぎり能力が向上するものだとぼくは思います。その「能力」の定義は時間の経過とともに変化するかもしれませんが、途中でやめてしまわないかぎり、その成果は生まれ続けるはずです。
- というか、途中でやめてしまってすら、無駄になるとは言えないでしょう。どうもプログラミングを学ぶことは、あたかも無条件に良いことであるかのように語られがちですが、「やってみたらあまり興味を持てなかった」という人がいてもそれはそれで自然なことですし、そういう場合には、もっとその人に向いたことに自分の人生を費やすべきかもしれないですから。
5. 自分に合った方法は自分で作るしかない
- 事前に考えていたトピックは上記の4点でしたが、最後にひとつ思い出したので、それを書いて終わりにします。
- ここまでに書いてきたことも含めて、基本的に他人が示してくれる方法というのは、ユニクロで売っている既製服のようなものです。
- ユニクロは、あなたの体型に合わせて服を作っているわけではありません。人間の体型を数種類の「大体のかたち」に分けてそれを作り、お客さんはその中から「自分の体型に近い服」を買っています。
- 他人が示してくれた学習の方法は、世界に一人しかいないあなたのための方法ではありませんから、うまく機能しないこともあるでしょう。
- むしろ、機能しないことばかりかもしれません。
- これは学習に限らないと思いますが、自分のパフォーマンスを最大限に発揮するには、既存の方法を参考にしながらも、最終的には、自分だけにフィットした、オーダーメイドの方法を作る必要があるのだと思います。
- その方法は、他の人にはフィットしないかもしれませんし、もしかするとほんの数ヶ月後のあなたにすらもう合わないかもしれませんが、「今までいろいろ試したけど、どうしても長続きしなかった」という場合には、この考え方が役立つかもしれません。
- 本日の記事は以上です。
- 明日のアドベントカレンダーは、吉祥寺.pmの主宰でもある@magnolia_k_さんです。
- 今年のPerl入学式 Advent Calendarは、例年に増して多彩な人たちが参加していて面白いので、ぜひお楽しみください。
*1:その後に買って読んだら面白かったです。関連記事 → 変数は「箱」か？（3） - the code to rock
