プログラミングは答えを見る勉強法でいい｜現役エンジニアが教科書で学ばない理由と正しい答えの見方

プログラミングの勉強で答えを見るのは、ズルではありません。むしろ、現役エンジニアの多くは教科書よりも「動くサンプルコード」を見て覚えてきました。大事なのは見方で、答えは何度見てもよいけれど、書くときは伏せる、時間で区切る、エラーをヒントにする、の3つを守ることです。この記事では、答えを見る勉強法の具体的な手順と、伸びない人がやりがちな見方、つまずいたときの質問の仕方までをまとめます。

この記事は、テックジム代表が配信しているメルマガ「グラさん通信」の内容をもとに、加筆・再構成したものです。

プログラミングの勉強で答えを見るのはズルですか？

結論から言うと、ズルではありません。受験勉強で赤本（過去問集）を解いたときのことを思い出してみてください。筆者（テックジム代表）は「どうせ最初は解けない」という前提で、わからなければすぐ解答を見ていました。どうせ何回も解くのだから、そのときに解ければいい、という考え方です。

2回目、3回目と解いていくと、正答率は自然に上がります。答えそのものを丸暗記しているわけではありません。解き方の流れをうっすら覚えていて、それを手がかりに解けるようになるのです。

これを最初から「意地でも自力で解く」とやると、膨大な時間がかかります。プログラミングも同じです。とくに初心者のうちは、自分でゼロから考える時間より、正解のコードを見て「こう書けば動くのか」と知る回数のほうが、上達に効きます。

現役エンジニアは教科書で学んでこなかった

筆者がそう考えるようになったのには、きっかけがあります。

スマートフォンのアプリが出始めたころ、アプリ開発の本も学校もほとんどありませんでした。それでもエンジニアたちは、あっという間にアプリを作れるようになりました。どうやって学んだのかというと、プラットフォーム側が公開したサンプルコードです。動くコードを手元で動かし、書き換え、壊して、直す。その繰り返しで覚えていきました。

筆者はその時期にiOSアプリ開発のスクールを立ち上げ、約3,000名の受講生を教えました。その中で「本当に授業や教科書は必要なのだろうか」という疑問を持つようになりました。

もう一つのきっかけは、テックジムの共同創業者との出会いです。彼は教育系ベンチャーのCTOをしていたころ、毎週土曜日に学生を集めてプログラミングの勉強会を開いていました。やり方は自習形式で、サンプルのコードを渡して「ここをこう変えて」という仕様変更を繰り返させるだけ。それでも学生たちは、3か月後には開発の現場で働いていました。この育て方をカリキュラムにしたのがテックジムです。

答えを見る勉強法の正しい手順

答えを見てよいとはいっても、見ながら書き写すだけでは身につきません。手順は次のとおりです。

問題（作りたいもの）を読み、まず自分で書いてみる
手が止まったら、時間を区切る。目安は1問15分。15分で書けなければ答えを見る
答えのコードは何度見てもよい。ただし、書くときは答えを伏せる
書いたらすぐ実行する。実行する前に長々と見直さない
エラーが出たら、エラー文を読んで直す。わからなければもう一度答えを見る
動いたら次の問題へ進む。細かいタイプミスで詰まったものは「おおむね書けた」として、復習のときに解き直す
同じ問題を日を置いて2回目、3回目と解き直す

ポイントは3つ目です。答えは「見る」ものであって「写す」ものではありません。見て、伏せて、思い出しながら書く。トランプの神経衰弱のように、覚えたつもりで書いてみて、外れたらまためくる。このやり方は神経衰弱式コーディングで詳しく紹介しています。

6つ目の「捨て問題」の考え方も大切です。試験に捨て問題があるように、プログラミング学習ではタイプミスのようなケアレスミスに時間を取られるのは本質ではありません。そこで止まるより、先に進んで、復習のときにきちんと直せば十分です。時間の区切り方はプログラミング学習は15分刻みが最強も参考にしてください。

「よく考えてから」より試行回数が大事な理由

職場で「よく考えてから質問しなさい」と言われた経験がある人は多いと思います。けれども、プログラミングの学習では「よく考えて」より「よく調べて」「よく試して」が正解だと筆者は考えています。

楽器やスポーツを思い浮かべてください。ピアノを練習していると、ある日ふいに右手と左手が同時に動くようになる瞬間があります。バッティングでも、何百球と打ち込むうちに「コツ」がおりてきます。理屈を考え抜いたからではなく、繰り返した回数が一定を超えたからです。

プログラミングも同じです。筆者が長年たくさんの受講生を見てきた実感では、上達が遅い人に共通するのは、キーボードを打つ量が圧倒的に少ないことです。画面の前でじっと考えている時間が長く、手が動いていません。試行回数が少ないうちは、どれだけ考えても理解は追いついてきません。逆に、ある程度の数をこなしていれば、理解は後から一瞬でやってきます。

AIの機械学習が、たくさんのデータを読み込んでから初めて賢くなるのと似ています。人間の場合もまず回数、理解はその後です。

現場目線のプログラミング学習のコツや業界の裏話を、テックジム代表が毎週メルマガ「グラさん通信」でお届けしています（読者1万人超・登録無料）。

グラさん通信に無料で登録する

Scratchのように「説明を読まずに動かす」と楽になる

子ども向けのビジュアルプログラミング「Scratch（スクラッチ）」を触ってみると、よくできていると感心します。日本語の説明を読む必要がほとんどありません。ブロックを組み立てて実行し、思ったように動かなければ組み直す。それだけで、プログラムの構造がなんとなくわかってきます。

歴史の教科書を読むより大河ドラマを見たほうがすんなり頭に入るのと同じで、人は解説を読み込むより、実際に動かして反応を見るほうが覚えやすいのです。

この考え方は、大人がPythonなどの文字で書くプログラミングを学ぶときにも使えます。

決まった書き方（構文）は、意味がわからなくても神経衰弱だと割り切って書く
変数や引数など、変えてよいところだけを入れ替えて試す
すぐ実行する。どうせエラーが出るので、そのエラー文をヒントにする

Scratchで「思ったように動かない」にあたるのが、テキストのプログラミングでは「エラー文」です。英語で書かれていて身構えがちですが、訳してみると、どこで何が起きたかを教えてくれる意味のある文章です。どこかの解説ページを読むより、エラー文のほうがよほどヒントになります。エラーとの付き合い方はエラーメッセージは怖くないにまとめています。

実はこれ、現場のプログラマーの仕事の進め方そのものです。動くサンプルコードを見つけてくる（いまならAIに書かせる）、作りたいものに合わせて書き換える、実行する、エラーを手がかりに直す。動くコードを改造していくだけなので、教科書はいりません。Scratchの学び方と、その先の言語選びについてはスクラッチの次はPython？も参考になります。

答えを見る勉強法で伸びない人の共通点

同じように答えを見ていても、伸びる人と伸びない人がいます。伸びない人によくある見方は次のとおりです。

伸びない見方	どう変えるか
答えを見ながら書き写す	見たら伏せて、思い出しながら書く
答えをコピーして貼り付ける	必ず自分の手で打つ。打った回数が力になる
答えを眺めて「わかった」で終わる	伏せて書けるかを試す。書けなければわかっていない
1行ずつ意味を理解しようとして止まる	わからない部分は飛ばして先に進む。何度も書くうちに理解がおりてくる
調べ始めると止まらない	調べものは1回1分を目安に切り上げ、エディタに戻る
文法を丁寧にノートにまとめる	検索すればすぐ出ることは書き写さない。ノートは考えを整理する図を描くときだけ使う

とくに多いのが「いちいち理解しようとする」ことです。テックジムで教えている学生エンジニアは、受講生に「理解しようとしないで」とよく言っていました。理解しようとして理解できないと、そこで止まってしまうからです。「やっているうちにわかる」と開き直って手を動かしていると、ある日急にわかることがよくあります。筆者はこれを「理解の自動化」と呼んでいます。

ほかにもやりがちな学び方の落とし穴は、間違ったプログラミング学習方法で紹介しています。暗記しようとしなくてよい理由はプログラミングに暗記は不要もあわせてどうぞ。