チュートリアルは3周した。写経したコードは実行すれば全部動いた。なのに真っ白なエディタを開いた瞬間、カーソルが点滅するだけで一文字も出てこない。──それは、気合が足りないからでも、写経の回数が足りないからでもない。
「それ、まさに今の自分だ」と思った人は、たぶん少なくないと思う。私にも覚えがある。動画も本も一通り終えた。サンプルコードは意味もちゃんと分かる。それなのに、いざ「じゃあ何か自分で作ってみて」と言われた瞬間だけ、頭の中が真っ白になる。
「量が足りない」「完璧主義をやめろ」――それ、本当にそうか
この状態に対する定番のアドバイスは、だいたい決まっている。「インプットよりアウトプットが足りない」「完璧を目指さず、まず小さく手を動かせ」「写経の量が絶対的に不足している」。どれも間違ってはいないし、実際に効く場面もある。
だが一度、この助言を素直に最後まで信じてみてほしい。写経が足りないなら、何百本写せば「作れる」に変わるのだろうか。10本で無理だった人が、100本写経すれば急に手が動くようになるのだろうか。そもそも、写経を何十本と重ねてきたのに、真っ白なエディタの前で固まる感覚がまるで変わっていない――もしそうなら、量を増やしても症状が動いていないということだ。だとすれば、これは量の問題ではないのではないか。
同じように「完璧主義をやめて、雑でいいからとにかく手を動かせ」という助言も、半分は正しく半分はすれ違っている。手を動かせないのは、完璧な設計を求めているからではなく、そもそも何から手を動かせばいいのか、その最初の一手が見えていないからだ。雑でいいから作れと言われても、「何を」「どこから」作ればいいのかが分からなければ、雑にすら作れない。
つまりこの記事で言いたいのは、量を増やすコツでも、心構えの持ちようでもない。手が止まるのには、量や気合とは別の、もっと構造的な理由がある、という話だ。
チュートリアルが教えてくれなかった、たった一つのこと
チュートリアルや写経が悪いわけではない。文法やAPIの使い方、コードの読み方を身につけるうえで、非常に効率のいい学習方法だ。問題は、それが教えてくれるものと、教えてくれないものの境界線にある。
思い出してほしい。よくあるチュートリアルはこう始まる。「Todoアプリを作ります。まず入力フォームを作りましょう。次にリストの表示部分です。最後に削除機能をつけます」。ここで読者がやっているのは、AからB、BからCへと、すでに他人が分解し終えた手順を、順番になぞる作業だ。それぞれの部品の作り方は身につく。しかし「Todoアプリを作る」という漠然とした要求を、そもそも「入力・表示・削除」という3つの部品に切り分けたのは誰だったか。それは常にチュートリアルの著者であって、読者自身ではない。
何百本チュートリアルをこなしても、練習しているのは常に「分解済みの手順を実行する力」であって、「漠然とした要求を自分で分解する力」ではない。後者は前者をいくら積み重ねても身につかない、別の技能だからだ。写経の回数を増やしても手が動かない理由は、ここにある。増やしていたのは、そもそも今回必要な種類の経験ではなかった。
この見方は、突飛な思いつきではない。プログラミングの熟達を調べた古典的な研究に、Soloway と Ehrlich による「Empirical Studies of Programming Knowledge」(1984) がある。彼らは、熟達したプログラマーは「プログラミングプラン」と呼べるような、目的から手順を組み立てる定型の型を持っていて、初心者はまだそれを持っていない、と報告している。この論文自体は学習方法を比べたものではないが、プランが「目的を手順に分解する」力である以上、他人がすでに分解し終えた手順を読んだり写したりするだけで身につくとは考えにくい――というのが、この概念から素直に導かれる見方だ。
もう一つ、学習心理学には「望ましい困難」や「流暢性の錯覚(illusion of competence)」という考え方がある。認知心理学者のRobert Bjorkらが論じてきたもので、写経中に感じる「なるほど、わかる」というスムーズな感覚は、実は理解の深さの証拠にはならない、という指摘だ。答えを目の前に置きながら読むのはスムーズだが、そのスムーズさは、自分ひとりで同じ道を歩けるかどうかとは別問題だ。
難しい話に聞こえるかもしれないが、言っていることは単純だ。チュートリアルで身につくのは「なぞる力」で、作れないと感じているのは「分解する力」。両者は別の筋肉であり、片方をいくら鍛えても、もう片方は育たない。
では、何をすればいいのか
ここで注意したいのは、次にやるべきことも「写経を増やす」の延長線上には無い、ということだ。よく勧められるもう一つの方法に、「既存の教材のコードを1行だけ改造してみる」というやり方がある。ボタンの色を変える、項目を1つ増やす、といったものだ。これは確かに手を動かす練習にはなるが、分解の練習にはならない。なぜなら、「何を作るか」という仕様自体は、依然として他人が決めたものの中にとどまっているからだ。分解する経験は、仕様そのものを自分で決めるところから始まる。
だから最初の一歩は、驚くほど地味でいい。「これは自分で決めた」と胸を張れる、ごく小さなお題を、自分で立てることだ。難しい機能である必要はない。むしろ小さければ小さいほどいい。
たとえば、「毎日読んだページ数だけを記録するだけの、画面もないコマンドラインのメモツール」。仕様書は無い。何をどう入力させるか、どこに保存するか、全部自分で決める。あるいは「自分の好きな曲のタイトルを、実行するたびにランダムで1つ表示するだけのプログラム」。どんなデータの持ち方にするか、何個まで登録できるようにするか、それすら自分で決めていい。
大事なのは、完成した機能の立派さではない。「何を作るか」を決めたあと、頭の中で一度立ち止まって、「これを作るには、何から手をつけて、次に何をすればいいか」を、誰の手順書も見ずに自分の言葉で書き出してみることだ。そこで書き出した手順が、チュートリアルほど整然としていなくてもいい。むしろ最初は歪でいい。その歪な手順を自分の手で組み立てたという経験こそが、これまで一度もやっていなかった種類の練習になる。
写経を1000本重ねるより、こういう小さなお題を10個、自分で立てて分解してみるほうが、遠回りに見えて近道になる。エディタの前で固まっていたのは、努力が足りなかったからではなく、鍛えるべき筋肉を、そもそも一度も使っていなかったからだ。
教材選びで一つだけ言えるのは、次に選ぶなら「手順を最初から最後まで与えてくれるもの」より、「途中から少しずつ"ここから先は自分で決めて"と手が離れていくもの」のほうが、この記事で書いた"分解する経験"を積みやすい、ということだ。プロジェクト型の実践講座はその代表格で、どのくらい手取り足取りか・どこから自分で決めさせてくれるかは、実際に使った人のレビューを読むと見当がつく。
（参考：筆者は、開発者が技術記事の中で実際に薦めた回数から講座を分野別に並べた一覧を s-tasklog.com で作っています。教材選びの参考にどうぞ。）
※本文で触れた研究は、Soloway & Ehrlich「Empirical Studies of Programming Knowledge」(1984)、および Robert Bjork らが論じる「望ましい困難／流暢性の錯覚」の趣旨要約であり、具体的な数値・被験者数等の引用は行っていません。