プログラミングを教える側になって気づいた、成長した人の特徴の話
今回の要約
教える側になって一番意外だったのは、詰まる人のほとんどが知識不足じゃなかったこと。「forは分かります」だけど応用・実戦で手が止まることが多い。その理由は知識が足りないじゃなく、持ってる知識をどう組み合わせるかが浮かばないところと、成功体験がなくイメージ掴めないところでした。逆に、伸びが早い人には●●●を先にする傾向があった。
自己紹介
こんにちは。現役8年目のエンジニア兼PMをやってる、やむぅ。です。普段はフリーランスエンジニアとして8人の開発チームのPMをやりつつ、個人開発したサービスをいくつか運営してます。個人的にプログラミングを教えたりもしてます。
教える側になって驚いたこと
独学とかでプログラミングを学習してる人の半分以上は、知らないことがあって進めない状態ではなかったです。知識はひとまず入ってる、けど足りてなかったのは、それを組み立てるイメージ力でした。
教える前の僕は、独学の時の偏見もありますが詰まってる人は大体知識が足りなくてうまくいかないと思ってました。だから逆に教える時は説明できる量を増やせばいいと最初の頃思ってました。でも実際に教えていく中で、「今詰まってて」や「ここどうしてもうまくいかなくて」の状況はそこじゃありませんでした。
とはいっても、僕が見てきた人数は正直まだそんなに多くないです。教えている人たち、相談で話した人、あとは会社の後輩とかメンバーです。
これわかる！の人が、課題で止まる原因
「Javaのclassは分かります。ただ、この課題でクラスに落とし込めなくて」
これ、実際に受けたことある質問です。で、この人はclassの意味をちゃんと説明はできる。クラスの中にインスタンスが〜とか関数やると〜も理解している。知識としては十分ですよね。
もっとイメージしやすい例でいうと、初心者の課題でよく出るこれです。
*
***
*****
*******「ピラミッドを出力してください」という課題。最初こんな感じので止まる人、めちゃくちゃ多いんじゃないでしょうか。
しかも本人にfor文を説明してもらうと、普通に説明できる。「回数分くり返すやつです」と動きも答えられる。なのにいざこれをやろうとすると「ん？」となる。
止まってるのは、たぶんこの部分です。
「4行くり返すんだな」はわかる
でも「ピラミッドを`*`でどう表現するんだ」という発想が出てこない
もっといえば「1行で`*`を何個出すか」と「`*`じゃないところどうするか」がむずい
そもそも行番号と `*` の個数が連動してる、という関係に自分で気づく必要がある
for文を知ってることと、目的の形を作るためにforを組み込むことは、思考として別物になっている印象です。前者は暗記と理解で終わるけど、後者は「完成形から逆算して分解する」という手順を経て発見する。ここを練習してないまま応用課題に入ると、知識があっても開発できないです。
似たような状況はかなりあります。皆さんの中でも「そんなんあったわ」な人いるかもです。
「オブジェクトは理解したが、お問い合わせフォームで使う意味わからない」
「ToDoアプリを作れって言われたんですが、何から手をつければいいかわからない」
「チュートリアルは全部やりました。でも作りたいサイトができるイメージわかない」
この例は全部、組み立てられないなやつです。
大学2年で独学を始めた僕も、Progateを2周して「余裕じゃん」と思ったあと、自己紹介サイトを作ろうとして絶望した記憶があります。
これ、HTMLが書けなかったんじゃなくて、どう組み立てたらいいかとか必要な知識をそれに落とし込めなかったとか、そもそも構築の仕方で正しい方法がわからなかったからでした。
インプットを増やしてもあんまかわらん
最初、僕はこれを説明不足だと思ってました。なので解説を厚くした。図も足したし、動きも見せたりした。
でも結果、変わらなかったです。同じ課題の、同じ場所で止まってしまう。
そこでようやく気づいたんですけど、ざっくりイメージですが一般的な教材って知識(部品の使い方)の説明だけなのが多くて、組み立て方や実際の開発への応用例は教えてなかった。部品の説明をいくら丁寧にしても、組み立ての練習にはならないので、そりゃ応用や実践への落とし込みにイメージ掴めないままになっちゃう。
詰まる原因は、組み立ての経験値不足
詰まりの正体は、大きく2つです。知識をうまく落とし込めないことと、完成イメージが掴めないこと。どっちも知識量の問題じゃないです。
知識をうまく落とし込めない時
料理でたとえると分かりやすいと思ってます。
教材でやってるのは、包丁の使い方とかにんじんを切る練習です。これはこれで必要なんですけど応用でいきなり「チャーハンを作ってみよう」をさせられる。
しかも学習者側は、「なんとなくで焼いた炒飯」を作ってみたりしてそれがあんましっくりこず失敗したなと感じてしまう。だから作れないと「包丁の使い方が甘いのかも」と思って、また包丁の練習（＝教材の周回）に戻る。ここが一番もったいないポイントだと思ってます。戻る場所が違うからです。
完成イメージが掴めない
もう1つがこれです。知識はインプットできたけどそれを実際に使うサンプルや事例がなく、応用させるイメージがわかない。
これがけっこうきつい。今まで「合ってるかどうか」を答え合わせで確認してきた人が、いきなり答えのない場所に放り込まれる。すると「これで合ってるのか分からない」が不安になって、書く前に止まっちゃう。
「これで合ってますか」と何度も確認しに来る人、実際います。悪いことじゃないです。むしろ真面目な人ほどこうなる傾向にある。ただ、確認が取れるまで手を動かさない癖がつくと、進む速度が確認待ちの速度に固定されちゃうんですよね。
で、実務でも正解はないです。僕がPMとして見てるチームでも、最初から綺麗な実装が出てくることはまずない。動かして、レビューして、直す。その前提で作ってます。正解は先にもらうものじゃなくて、動かしたあとに分かるものという感覚を、学習段階のうちに持てるかどうかはけっこうデカいと思ってます。
もしこういった応用問題でうまくいってない人、こういう状態が続くとこんな風に思ってくるかもしれません。
「自分にはセンスがないのかも」
「これ、本当に就職レベルに達するのか？」
僕はこれ、能力・センスの話じゃなくて型・イメージを掴んでいるかどうかだと思ってます。一回サンプル見る・経験したかどうか。普通にやってくと組み立ての練習をしないまま組み立てを要求されてるので、できなくて当たり前なんす。向いてないんじゃなくて、練習してる場所がズレてるだけです（少なくとも僕が見てきた範囲では）。
成長した人に共通してた5つのこと
伸びた人は、頭の回転が速かったわけでも、勉強時間が長かったわけでもなかったです。共通してたのは、書く前の動きと事前準備でした。
正直、最初は「地頭かなあ」と思ってた時期もあります。でも見返すと全然そうじゃなくて、やってる手順のほうが違ってた。しかも真似できる範囲のことばっかりでした。
1. 書く前に、やりたいことを整理
伸びる人は、着手前に「何できたらいいか」を整理・言語化してます。
×「ToDoアプリ作る」
○「タスクを追加機能は…,表示は…」
これ、地味に見えて効きます。やることの詳細が決まってないと分解ができない。そうなるとさっきの「何すればいいかイメージつかない」ので手をつけられず固まってしまう。
2. 日本語で手順に割ってから、コードを書いてた
これが一番差がついてたところです。
さっきのピラミッドなら、コードを書く前にこう書く。
行数分くり返す
その行で出す `*` の数を決める（行番号と同じ数）
その数だけ `*` をつなげて出力する
先頭にスペースつける
ここまで日本語で書けてれば、あとはそれぞれの部分を実装して繋げるだけ。逆に言うと、書けなかった行が今のあなたの本当の詰まりどころです。2番が書けない人は、for文の知識じゃなくて「行番号と個数が連動してる」という関係に気づけてない。そこだけ掴めば進めます。
ToDoアプリなら「画面に入力欄とボタンを置く」「押したらリストに追加する」「一覧を表示する」。この粒度まで割ってから書き始める人は、まず止まらなかったです。
いきなりコードから書き始める人は、頭の中で設計と実装を同時にやってることになるので、そりゃ重いです。分けたほうが普通に楽になります。
3. 正解を追い求めない
伸びた人は、綺麗に書こうとしてなかったです。とりあえずベタ書きで動かして、動いてから直してた。
変数名が `a` でも一旦OK（これは学習序盤ならギリOK、後半はこれダメ）
同じ処理が3回出てきてても一旦OK
ファイルが1個に全部入ってても一旦OK
動くものが1回できると、そこからは「直す」作業になります。ゼロから考えるより全然楽です。
逆に、最初から正しく書こうとした人は沼にハマりやすく、課題と関係ない箇所で時間かけてしまい萎えることが多いです。
4. 詰まってる位置を言語化できる
質問の解像度と伸びる速度は、体感かなり相関してます。
×「分かりません」
○「一覧の表示まではできて、削除ボタンを押したときの要素の消し方が分からないです」
後者が言えると、回答者視点だとどんなこと知りたいか的確に話すことができる。しかも本人の中に「詰まりを特定する」という手順が残る。前者だと、まずどこまでできてるかを聞き出すところから始まるので、時間もかかるし本人にも何も残らないです。いってしまえば「投げやり・押し付けられてる」と感じられてしまい双方にとって悪影響となる。
これ、AIが来てからさらに効くようになった気がしてます。ClaudeやChatGPTは答えを出すのは得意なんですけど、ざっくり「動きません」と投げると、ぼんやりした答えが返ってきます。「ここまでできてて、ここでこのエラーが出る」と投げると、一発で解決します。結局、AIを使いこなせてたのも、詰まりの位置を言える人でした。
PMとしてメンバーを見てても同じで、任せやすいのは「コードかくの早い人」じゃなく「これ大丈夫なん？」に自分で答えられる人です。どこまで確かめたかを言える人。いや、綺麗事ではなくて、レビューする側の実感です。
5. まず作り切る
完璧を目指すよりトライ数を重視しましょう。精度は正直どうでもいいです。
伸びた人は、小さいものを何個も完成させてました。逆に、大きいものに1回挑んで途中で止まった人は、型が1個も溜まらないまま時間だけ過ぎてました（これ、僕も昔やりました）。
構想力って才能じゃなくて、完成させた回数だと思ってます。 1個目が一番しんどくて、3個目くらいから明らかに軽くなります。
やってみて欲しいこと
新しい教材を買う前に、作るもの・完成条件・手順3行を書くほうが効果あります。ここを抜かして教材を足しても、たぶんまた同じ場所で止まります。
完成条件を1行、手順を3行
まず皆さんにやってみて欲しいのがこれです。
やることを1行で書く：「誰が、何をできるようになるか」まで入れる。例：「Todoアプリを作る」
完成条件を状態で書く：「一覧が表示できる」「チェックボックスで取り消し線」とかでOKです。自分で判定できる形にするのがポイントです
手順を日本語で3行に割る：「入力フォームを置く」「登録した内容を保存する」「一覧に表示する」。それぞれMax30分で終わるサイズまで落とす
そのあと、まず一つ目だけ実装します。全部は考えなくていいです。
書けなかった行が、本当の詰まりどころ
で、たぶん洗い出した手順のうち1つくらい書けないやつがでてくるはずです。そこが今のあなたの学習対象になります。
「保存する」が書けないなら、必要なのはfor文の復習じゃなくて、データの保存方法です。「一覧に表示する」が書けないなら、配列を回して画面に出すところ。こんな風にして言語化してもできない部分を、そこだけ調べればOKです。
この作業の何がいいかというと、調べる範囲が勝手に狭くなることです。「Reactを全部やる」から「配列を画面に出す方法だけ調べる」に変わる。着手できるサイズになります。
相談乗ります
そのうえで、自分ひとりだと決めきれないところは必ず出てきます。特にこの辺は、経験がないと判断材料そのものがないので、独学で粘っても答えが出にくいです。
そもそも手順に割れない
割った手順が合ってるか分からない
自分の題材が就職やレベル感に見合ってるか分からない
このどれかなら、書いてみて詰まった1行だけ持ってきてもらえれば、どこで組み立てが切れてるか一緒に見れます。
あとは、そんな感じで不安だなとか、具体的にどうすればいいん？な人向けに、エンジニアやってる僕が相談受け付けるよってのをやるので、気になったら覗いてみてください。
まとめ
教える側になって分かったのは、初心者が止まるのは知識不足じゃなくて、持ってる部品をどう組み立てるかが浮かばないことでした。あと、正解例がないとイメージ掴めないよねということ。この2つです。
そして成長につながってたのは、教材を増やすことでも勉強時間を伸ばすことでもなく、書く前の準備でした。完成形を1行で決める。日本語で手順に割る。汚くても動かす。詰まった位置を言えるようにする。小さくても作りきる。地味です。でも、ここをやってる人は普通に進んでいくし、やってない人は何周しても同じ場所で止まります。
「応用ができない」の正体は、理解が浅いからじゃなくて、日本語で手順を書いてないだけかもしれない。もし今止まってるなら、一回そこを疑ってみてからやってみてください。
あわせて読みたい記事：
いいなと思ったら応援しよう！
よろしければ応援お願いします！ いただいたチップはサービス開発と運営費に使わせていただきます！