プログラミングを覚えたいという老若男女に分け隔てなく伝えたいこと、それは「ひたすらプログラムを書いてください」という言葉に尽きる

「ちょうど一年前に~、この道を通った夜から、昨日の事のように~今はっきりと想い出す~」などとTHE 虎舞竜ロードなんか思い出しちゃったりする世代なのであるが、およそ1年前にプログラミングに関する書籍の選び方に関する記事を書いてみた。まったく反響もなく(笑)、まあそれはそれでいいんだけど、プログラミング初心者・プログラム初学者がどのようにしてプログラムを学習していくのか、というのは、IT系の業界がこれだけ伸びてきて、かつコンピュータサイエンスがこれだけ発達してきても未知数の部分が多い気がする。もちろんこれにセオリーなどないわけだが、私なりの考えをまとめてみたい。

ぶっちゃけて言ってしまえば、子供の頃に興味を抱き、その興味の赴くままに進んできた私からすると、プログラミングに対する抵抗は一切なく、むしろ水や空気と変わらぬ程度のものでしかない。
もっとも今では生活の糧を生み出すための原動力となっている点では大きいといえるが、事務担当の社員が事務を特別なものと思わず普段の生活の中でこなしているのと同じように、職業プログラマはプログラミングを特別なものと思わずに普段の生活の中でこなしているにすぎない。

問題は、趣味でプログラムを学習したいがどうしても独学に限界があるとか、仕事上どうしてもプログラミングを余儀なくされる場面があるが余力の範囲で学習しながら書き進めても壁にぶち当たるだけで遅々として前に進んでいかない、といった具合の方だろう。

数学が苦手な人が数字が出てきただけで苦手意識を全力で発揮して逃げ出したりアレルギー反応をおこしたりするように、あるいは私のように、どんなに努力をしても時間を費やしてもなかなか頭に入っていかない外国語学習のように、どうにもならない自分の中の壁が存在する場合もある。
つまり、どんなにプログラミングを学習しても、自分の中の何かしらの壁にぶち当たって先に進まないということだ。

私は「バカの壁」という本は読んだことは一度もないが、あらすじを読む限りではおそらくそういうことに類する作用が働いてしまい、プログラム学習を阻害するひとつの要因になっているのではないだろうか。

この壁を壊すための唯一の条件は「プログラミングに興味を持つこと」でしかない。この条件を満たせない限り、凡人ならおそらく一生涯プログラミングをすることがない、あるいはできないと思う。

逆にプログラミングに興味を持った瞬間から、その人は猛烈な勢いでプログラミング学習が進んでいく。

この「興味を持つ」瞬間というのを振り返ると、おそらくプログラミングに限らず誰しもが幼い頃に経験をした「小さな成功」の積み重ねなのだ。

プログラミングというと、膨大なプログラムを一人で淡々と書き連ねていくようなイメージを持つ人もいるかもしれない。あるいは巨大なアプリケーションやITシステムを想像して、それがどのように構成されているのかすら想像を絶するものを思い浮かべながら、そんなものは自分ではつくれないと思うかもしれない。

そんなものはプロでも一人でさくさく作れたものではない。

1冊のプログラム学習本の、ある1ページの小さなプログラムを真似て、そうした小さなプログラムを書いては改良し、書いては改造し、書いては壊し、壊したら修正し、修正したものとオリジナルを見比べて何が違うのかを比較検討し、その違いを見つけ、自分が何を成し遂げたのかを理解し、喜びを感じる……こんなことの繰り返しで、人は着実に自信をつけていく。

さきの「去年書いた」記事と重複するが、とにかく、プログラミングを習得するためには、プログラミングの時間をひたすら取りつづける、ということだ。

英語学習で重要なのは、常に英語に触れていることだという。
常に英語に触れているのは難しいなら、毎日何時間でもいいから英語に触れる機会を設ける。
英語に触れている継続的総時間数こそが、英語を自分のモノにする重要なファクターであると、とある英語学習本に書かれている。

これは英語に限った話ではなく、あらゆることに共通する内容ではないか。
そしてプログラミングでさえ、その例外ではないのだ。

小さなプログラムを書くことを継続していくこと。
どこかのウェブの、あるいは本の、サンプルプログラムでいい。
最初はそのプログラムを見ながら手入力をし、動くことを確認する。動かなければ、サンプルと見比べながら誤字脱字がないかをチェックする。サンプルプログラムが意味する内容を、ウェブのドキュメントや参考資料などを見ながら確認し、何をしようとしているのかを理解する。

次の日は、そのプログラムをもう一度見直す。
今度は、自分の思いのままにそのプログラムを改造する。
文字列を変えてみる、変数の数を減らしたり増やしたりしてみる、条件を追加してみる、繰り返してみる、別の書き方をしてみる……などなど、である。
改造しているうちに、いろいろなことが分かってくる。数を変えたら、表示される回数や内容が変わるかもしれない。文字列を変えても何も変わらないかもしれない。条件に一致しないかもしれない、一致してしまうかもしれない。繰り返しが1回足りないかもしれない、1回多いかもしれない。いろんな些細なことが現れてくる。自分と想像したものと違う結果が現れるかもしれない。

それを、楽しむのである。
何が、違っているのか。
何を、壊してしまったのか。
ジグソーパズルの一部をもう一度引き剥がしてバラバラにし、もう一度ピースを埋め直してみるかのように、一度プログラムを壊してみるのだ。
壊すことで、中身が分かる。
壊すことを恐れない。
それが、プログラミングを楽しむ、理解する、先に進んでいく、秘訣のひとつ。
私はそう考えている。

逆に、絶対にしてはいけないことがある。

それは、コピペだ。
コピペは自分を衰退させる。
特にプログラミングにおけるコピペは、何の意味も持たない。
コピペした瞬間に、学習は崩壊する。仕事であれば、なおさらだ。

ウェブや本を見てもいい。
それらを真似してもいい。多くの事が模倣から始まるのだ。真似しながら学ぶことは大切だ。
しかし、コピペは絶対にだめだ。
書籍のCDからのコピペもだめだ。ましてやウェブからのソースコードのダウンロードを使ってコピペもダメだ。

プログラムを見ながら、ぜんぶ、最初から最後まで、自分で入力する。
まるで精神修行かと思うかもしれないが、そうではない。
漢字の書き取りを手でひたすら書いて覚えた小学生の頃を思い出してみたい。
大人の今から思えば、さまざま知識や権利欲求やフィルタが入りこんで「あれは価値がない」「単なるいやがらせ」「精神論」などと考えてしまう人も、もしかしたらいるかもしれない。
しかしあの頃の私たちは、確実に「単に書いた」のではなく「書きながら理解した」はずなのだ。
漢字を書きながら声に出して読んだし、間違ったら消しゴムで消して書き直したし、うまく行幅や行末に合うようにマス目に書き込むバランスを調整することも覚えただろう。

単に機械的に書いたのとは、訳が違う。

サンプルプログラムを手で入力するということは、そういう意味がある。
面倒くさいと思ったら、おそらく、その人は、プログラミングに興味がないのだ。
センスがないのだ。
プログラミングは、すべて手作業なのだ。
機械作業は、絶対にない。
最近では多くのことが、簡素化・簡略化されている。
しかし、相変らずプログラミングは手で行うのだ。
自分の頭で考えながら、コードをひとつひとつキーボードを経由してコンピュータに入れていくその作業は絶対に不可欠で、頭の中にある自分の妄想したプログラムコードをコピー&ペーストすることは、今の技術では残念ながらできない。いや、残念ではないのだと思うが。

プログラミングが手工業である以上、サンプルコードを見ながらひたすら入力していくことの意味は、でかい。
そして一度入力したものを自分の手で変えていくその作業も、自分の手作業なのだ。

そしてもう一つ言えること。
それは「基本はかならず覚える」ということだ。

昨今ではプログラミングの面倒くさいことをすべて内包して短時間で完成品を作ることも難しくない「フレームワーク」という便利なものがある。
これらはプロダクトを考える上ではとても重要であり便利であり、大幅なコストパフォーマンスの向上を期待させるテクノロジーである。これらを使うことは重要であり、特に今の「早く完成、すぐ衰退」というライフサイクルの早い時代には求められるものだろう。

しかしITはまだ未熟だ。
車のメカニカルなことはまったくわからなくても車は運転できる。
しかし、プログラミングは違う。
基本的なプログラミング能力がない人が、いくら便利なフレームワークを持ってきたとしても、使えない。
車もフレームワークも便利な道具ではあるが、そのギャップはでかい。
フレームワークという道具は、人を確実に選ぶ。
プログラミングの基礎力がない人が使うと確実に破綻するプロの道具だ。
アマチュアの道具たりえない。いまだ、そのような道具にお目に掛かったことは無い。

今後はアマチュアでもすぐに使えるような、そうしたものが生まれる可能性はあるかもしれない。
しかしあえて断言しておこう。

プログラミング基礎の理解がない人には、使えない。
だからプログラミングを本当に興味を持って学習したい人に、しっかりとした言葉を送りたい。

・サンプルはおおいに使え。
・だがコピペするな。自分で入力しろ。
・ひたすら書け。考えながら、ひたすらプログラムを書け。
・書いたプログラムは改造しろ。動かなくなったら正常動作まで書き直せ。
・小さな成功を繰り返せ。小さいプログラムをいくつも書け。
・小さなプログラムを、日々培った知識で中くらいのプログラムに育てろ。
・基礎を理解せよ。入門書ではないリファレンスを手元に置くことも重要だ。
・繰り返して成功しながら、自分の興味を増大させていけ。かならず習得できる。

きっと、こうしたことが楽しめない人や、もっと最初からアトラクティブなプログラムもしくはアプリケーションといったものがすぐにできるものと想像している人にとっては、面白くない行為でしかない。
サッカーや野球をプレイせずひたすら素振りやシュート練習をしているだけのものに感じるかもしれない。
そこが「興味を持つ」かどうかの分かれ道だとも言えよう。

しかし、考えてみてもらいたい。
ルールも知らない人が、サッカーでいきなりグラウンドに立ってチームを勝利に導けるだろうか。球との距離感もなくヒットやホームランを出せるだろうか。
どんなことでも、基礎をないがしろにした段階で目的達成は困難となる。天才なら、そうしたことも可能かもしれない。
逆に基礎とは甚だ単調でつまらないものである。しかし、アトラクティブなものでも壮大なアプリケーションでも、そうした基礎の上に成り立っている。その「基礎」の部分にどれだけの興味や好奇心を見出せるか、という点に尽きると考えている。

そうした興味や好奇心を生み出すための「準備運動」として、私はぜひ「ひたすら小さなプログラムを書き続ける」を提唱したいのである。


プログラムはなぜ動くのか 第2版 知っておきたいプログラムの基礎知識おうちで学べるプログラミングのきほんプログラミング作法コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)ていねいに基礎を固めるプログラミングの入門書 (日経BPパソコンベストムック)

コメントを残す

メールアドレスが公開されることはありません。