プログラミング学習における教わる側と教える側の心得
この記事は CODE BASE OKINAWA Advent Calendar 2022 最終日の記事です🙌
はじめに
合同会社春秋共同代表のジュリマツダです。
会社員、フリーランス、会社設立を通してかれこれエンジニア歴6年?くらいになりますが、プログラミングに関して常に”教わる側”と”教える側”の両方を経験してきました。
特にフリーランス時代に教えていた人たちの中には転職に成功した人も数名います。
今回はCODEBASEという沖縄のプログラミングスクールのアドベントカレンダーということもあり、『プログラミング学習における教わる側と教える側の心得』という内容で、これまでの経験を振り返ってまとめみようと思います。
教わる側の心得
ぼくはエンジニアになるまでに独学で過去3回挫折しています。
今思えば挫折して当然だなぁと思うことばかりでしたが、当時の自身の経験と教える側の立場から見た挫折する人の共通点をまとめてみます。
1. 継続すること
何事においてもそうですが、やはり継続は力なりです。
エンジニアというのは技術職ですので、小手先の知識やテクニックでは仕事ができません。どうしても長期スパンで見なければならないのです。
とは言っても、継続力という言葉があるくらいですから、継続することも能力の一つだと思います。
では、どうすれば継続できるようになるのか。
少々乱暴ですが、これは『人それぞれ』に尽きます。
1日2時間を毎日やる、3日に1回休みを入れる、朝にやるのか夜にやるのか、場所は自宅かカフェか、一人でやるのか複数人でやるのか…etc
学習を始めて早い段階でこれらを見つけることが継続するために必要かと思います。
ぼくの場合は4回目の挑戦ということもあり「これでダメならもう辞めよう」と決めていました。
また、その頃には周りに現役のエンジニアが多数おり、見ていて「続けていればいつかはなれるんだな」とあまり肩に力をいれずに学習していたのがよかったと今振り返って思います。
2. 素直にすぐ聞く
講師を務めさせていただいているCODEBASEでも多く見られますが、質問しない人は挫折する確率が非常に高いです。
過去に質問しない理由を数名に聞いたことがありますが、「こんなことも分からないのかと思われたらどうしよう」、「”分からないこと”が分からない」「自分ならできると思っている」など心理的ハードルや間違った自己効力感の高さが垣間見えます。
まずはその何らかの高いところから降りてもらわないといけません。
質問する人としない人の差をCODEBASEの講義内でも以下のようによく言っています。
同時期にプログラミング学習を始めたAさんとBさんがいるとする。
Aさんは15分自力で頑張るが分からなければすぐに質問する。
Bさんは1時間粘っても分からず質問せずでこちらが最後手を差し伸べる。
AさんはBさんよりも45分早く一つのことを理解して先に進む。
次第にAさんは理解したことが点から線となり、できることが増えていった。
一方Bさんは…(ご想像にお任せします)
これは過去にいくつも見てきた事例です。
Aさんの場合、質問することで解決するという成功体験の積み重ねによってどんどん成長していくと同時に、解決プロセスを自身でも再現できるようになり徐々に自己解決できるようになります。(ここで注意しなければならないのはクレクレ君にならないこと)
一方Bさんは1時間考えても解決せず最終的に手を差し伸べてもらい、その原因が単なるケアレスミスだった時、「自分はこんなこともわからなかったのか…」と自信をなくすでしょう。
ましてや、AさんとBさんがプログラミングスクールという場でお互いに近い場所にいる場合、BさんはAさんと自身を比較し始め、さらに自己嫌悪に陥ってしまったらもはや救いようがありません。
プログラミングは理解したこと・できることが増えると、扇状的に挑戦したいことややりたいことが増えていくように思います。
この扇を広げるためにも分からないことは素直に質問し、Aさんのように自走していけることを願っています。
3. 振り返りと復習が近道
勉強には予習と復習がつきものですが、個人的にプログラミング学習においては復習だけで良いと思います。
プログラミングはできることの積み重ねでしかなく、できないことの上に何を乗せてもできないと思っているからです。
これはぼくが昔に電気工事の仕事をしていたことからも、技術職全般に言えることかなと思います。
※もちろん、できないことをそのままにしても、別のことをやることでできないことができるようになる場合があることは理解しています
そして、復習とセットになるのが振り返りです。
振り返りをするからには当然目標があり、その目標に対して今足りないこと(できないこと)を認識し、できるようにする。
このサイクルが重要です。
これはぼくが教える人たちに毎回見せる図です。
目標に対して週単位で振り返りをし、振り返り時点でできること・できないこと、できるようになった要因・できないままでいる原因とその課題、続けるアクション・改善するアクションなど、スプレッドシート等でチェック・レビューできるようにしていました。
この振り返りを徹底的に行なっている人の成長は、それが直線的か曲線的かは人それぞれですが、しっかりと安定して伸びていく印象です。
逆に振り返りが疎かだったり、何かウルトラCなるものを狙って復習していない人は脱落してしまいました。(そもそもぼくとの相性もあると思います…)
まずは振り返りと復習を通じてできることが増えていく感覚、これを特に若い人には早い段階から掴んでいってほしいなと思います。
4. エラーは財産
プログラミング学習初期においては、何をやってもエラーになることばかりです。
当然、エラー画面に出くわしたら気持ち的に萎縮しますし、思考停止状態に陥ることもあるでしょう。
ですが、ここでエラーとの付き合い方次第で挫折するかどうかがほぼ決まります。
ぼくの経験上、まずエラー画面が出てきた時に完全に手が止まっている人は将来挫折する可能性が非常に高いです。
次に、エラー解決のために調べたりはしているのですが、答えやサンプルコードを見つけるのに必死で、間の解説を読み飛ばしている人も高確率で将来挫折します。
これらに共通する人の特徴として『結果(= 答え)重視』がその原因だと思います。
幸いなことにプログラミングでの間違い、例えばタイプミスや文法ミスなどはちゃんとコンピューターがエラーとして教えてくれます。
ぼくらエンジニアはこのエラーに慣れていたり、何回もやってるので解決方法を知っていたり、初見のエラーでも解決プロセスを何通りか持っているだけです。
逆に、エラーに出くわすことなく、教科書通りにトントン拍子で進んでしまう人の方が危険だと思います。
プログラミング学習初期は何事もできないことからスタートするので、結果(= 答え)にこだわってもあまり意味がないです。
むしろエラーに出くわした時こそ『プロセス重視』です。
エラー内容が分からなかったり、解説記事やドキュメントを読んでも理解できなかった場合、それこそ分かる人に素直に聞いた方がいいでしょう。
このエラー解決が一番の成長トリガーであり、その積み重ねが財産となって”できる”ようになるのだと思います。
5. エンジニアになるための絶対的方法はない
教わる側の心得の最後としてこれを紹介したいと思います。
まず、プログラミングを習得するための方法論、勉強法はもちろん一つではありませんし、人によってその方法が合う合わないがあります。
生後8ヶ月で歩く赤ちゃんがいれば、1年経っても歩けない赤ちゃんがいるのと同じように、誰一人同じ人はいないからです。
大事なことは自身に合う勉強法を見つけることです。
そのためには”できること”と”理解すること”を別物と捉えなければいけません。
例えば、野球でホームランの打ち方を教えてもらい、スイングの軌道や力の入れ方、バットのどこにボールを当てるのかなど、頭では理解していても実際には打てないのと同じです。
この”できること”と”理解すること”が揃った時に初めて技術を習得したと言えるでしょう。
では、この”できること”と”理解すること”の内どちらを先に身につけるべきか。
これは本当に十人十色ですが、ぼくの経験上、以下の2タイプに大別できると思います。
できるようになってから理解する(実践→理論型)
理解してからできるようにする(理論→実践型)
1.の『実践→理論型』は、まずはサンプルコードをそのまま模写するように書き、その挙動や結果を体感値として持っておきます。その後にドキュメントや書籍に載っている理論を自身の体感値と答え合わせをすることで理解します。
このタイプは言語化があまり得意でない人にとっては適した手順だと思います。
まずは手を動かして「あ、こんな感じ(←ここの言語化が弱い)で動くんだ」という感覚を、理論や解説を通して「あ、こういうことだったのね」と理解し定着するイメージです。
ここでもう一回コードを書いて再確認すると定着率はさらに高まるでしょう。
一方、2.の『理論→実践型』はその逆で、まずはドキュメントや書籍に載っている理論から入って理解し、その後に実際にコードを書くことで、先ほどの理解が補助輪となってできるようになります。
このタイプは一見賢いように見えますが、自身が理解できるような解説や言い回しでないと理解できないので注意が必要です。
プログラミング系の書籍やドキュメントには端から端まで専門用語が出てきますので、分からない用語が出てきた時にはその都度調べるなり人に聞くなりした方がいいでしょう。
繰り返しになりますが、どちらのタイプが適しているかは自分自身で見つけなければなりません。
そのためにはやはり量が必要です。
まずはどちらも試してみて、どちらがよかったか、定期的な振り返りによって判断してみましょう。
それでも分からなければ、学生時代の勉強の仕方や性格など、あらゆる角度から総合的に照らし合わせてみて、「こっちの方が合ってそうだなぁ」という雰囲気で判断してもいいと思います。
どんな人にでも適用できる絶対的方法論はないので、ここで紹介した2タイプ以外の、自分のスタイルを見つけていってほしいと思います。
ちなみに、ぼくが初学者の頃は『実践→理論型』でやっていましたが、パターン認識能力がなく、解説記事などに出てくる言葉も難しかったので見事に挫折しました。
『理論→実践型』に切り替えてから自然と定着するようになりましたが、このことに気付いたのはエンジニアとして就職した後のことでした。
しかし、フロントエンドを触る時は『実践→理論型』でやる場合もあり、その都度切り替えています。
教わる側の心得のまとめ
以上が教わる側の心得5つでした。
今回は割愛させていただきましたが、プログラミング学習ではインプット量が膨大になりますので、それと同程度のアウトプット量が大前提にあります。
なので時間がかかるのは仕方のないことですし、必ず”いつかは”できるようになるので、自己投資だと思ってどうにか挫折しないように続けてみてください。
また、CODEBASEの最終講義でいつも話すのですが、プログラミングという未知の領域に足を踏み入れています。
そんなやったこともないことを1週間、1ヶ月、半年以上も続けている自分自身を褒めてあげてください。
ぼくの経験上、自分で自分を褒められる人は続けられていますし、ちゃんとエンジニアになっています。
教える側の心得
会社での教育係やプログラミングスクール講師、個人的活動を通じて、下は小学生から上は70代、これまでに約200人以上の人たちにプログラミングを教えてきました。
どの人に対しても、ぼくが教える側として大事にしていることがあります。
それは『自走力をつけさせる』、つまり『自分で育つ人』にさせることです。
”教える”というよりは”育てる”の方が意味的に合っているかもしれません。
ここでは『自分で育つ人を育てる』ために、これまでの経験を振り返りながらまとめてみようと思います。
1. 公式ドキュメントの読み方を教える
ぼくが新卒1年目の時、実装で分からないことがあり先輩エンジニアに質問すると、「まずはドキュメントを読んで」と言われていました。
部下や後輩を持つエンジニアなら、このアドバイスは一度でも口にしたことがあるのではないでしょうか。
たしかにドキュメントを読むことは大事ですが、このアドバイスは少々乱暴だと思います。
多くのドキュメントは日本語が難しかったり、そもそも日本語訳されておらず英語のみだったりするので、まずはそのドキュメントの読み方、使い方を教えてあげなければいけません。
実際にぼくが教える時は、公式ドキュメントを一緒に読み合わせ、用語の解説や概念の具体化、現場ではどのような使われ方がしているかなどを説明しています。
そうすることで教わる側から質問が出てくるようになりますが、この質問はその人の興味や関心、さらに知りたいというモチベーションから出てくるものなので、そこが一番の成長トリガーとなります。
結果的に、教わる側にとって当初欲しかった情報とそれに付随する情報がインプットされるのでより理解が深まります。
また、プログラミング言語やフレームワークのバージョンによっては書き方が変わるとこともしばしばあります。
例えば、Laravelではヘルパ関数の書き方が5.6と5.7で変わっていたりします。
同じドキュメントでも、バージョンを指定しないと欲しかった情報に辿りつけなかったり、ミスリードの原因になります。
これはある程度経験を積んだエンジニアにとっては至極当たり前のことですが、教わる側にとってはその”当たり前”が通用しませんので注意が必要です。
「馬鹿と鋏は使いよう」という言葉があるように、まずは道具の使い方を教えてあげましょう。
教わる側はドキュメントの読み方や使い方を覚えれば、徐々に自走できるようになっていきます。
2. その人に合った伝え方でなくてはいけない
プログラミングの世界ではよく”概念”や”抽象(化)”という言葉が出てきますが、教える側のみなさんはこれらの言葉をどういう風に教えていますでしょうか。
これについて正解はないと思いますが、教わる側として、またぼく自身も含めて様々な教え方を見てきた中でのぼくなりの答えがあります。
それは『抽象度と具体度を相手に合わせる』です。
教え方が下手な人は自分の抽象度と具体度で説明しようとします。
「あの人の話す内容はいつも抽象的」、「もっと具体的に言って」みたいなあのやりとりです。
聞く人(教わる側)が理解できる抽象度合いのレベルがMAX3だとすると、話す人(教える側)はそれを超えていてLv.10だったりします。
両者の間にこの差が発生することで、上記のようなやりとりが発生します。
教える側はこの差を埋めるために自身の説明の抽象度を下げる、つまり具体度を上げることになりますが、これが一番難しいです。
抽象と具体に関する本などでは、このことを「具体と抽象の行き来」と言ったりします。
プログラミングやそれらにまつわる技術の話は抽象度が高いものばかりなので、教える時もどうしても抽象度が高くなってしまいます。
どの程度の抽象度だと相手が理解できるのか、教える側はこの線引きを意識しなければなりません。
そのためには、コミュニケーションを重ねて相手を知ることから始まります。
細かいことまで挙げればキリがないのですが、ぼくが線引きをする際に、特に重要視している相手の要素以下で紹介します。
性別
年齢
性格
職業(学生も含む)
コミュニケーションの癖(内容が抽象的になりがちかどうか)
『実践→理論型』と『理論→実践型』のどちらか
これらの要素から、図を用いて説明するのか、例え話で説明するのか、擬人化して説明するのか、etc…。
こちらも根気が必要ですが、ここは相手との抽象度が合うまでトライ&エラーを繰り返します。
うまくピッタリハマれば徐々に教えることもスムーズになり、最終的にはコードレベルで会話ができるようになります。
ぼくはコードレベルで会話ができるようになることを目標としています。
抽象度と具体度を相手に合わせることはビジネスシーンの基本でもあります。
とは言ってもコミュニケーションの話ですし、人間が相手なので、まずはそんなに気を張らずに相手がイメージできる程度の内容で教えてあげればいいと思います。
3. ”方法”だけでなく”経験”も教える
CODEBASEではぼくのような講師以外に、受講生をサポートするコーチという存在がおり、CODEBASE卒業生が務めることになっています。
講義に臨む時、コーチ陣によく以下のことを伝えます。
「理解させようとしなくていいので受講当時の経験を話ししてください」。
教える側と教わる側とでは、立場上、どうしてもパワーバランスが教える側に傾きます。
そのため、教わる側は教える側に対して「なんでも知ってる」、「聞いたら教えてくれる」と思いがちです。
また、教わる側は教わったことをうまく理解できない時は不安や自信喪失、自己嫌悪になりがちです。
この作用をうまく利用します。
当然ですが、エンジニアになる前は誰しも”未経験者”です。
デキるエンジニアも最初は何も分からなかったことでしょう。
そこで、何もできなかった当時の体験談・経験談を話すことで、教わる側に「あ、この先生(コーチ)もこんな時期があったんだ」と、安心させてあげることができます。さらに失敗談を話すとより効果的ですし、親しみやすさや身近さも感じてもらえるでしょう。
ちなみにですが、ぼくは3回挫折したにもかかわらず、その後にもまだHTMLでcssを読み込む際のlinkタグを忘れていました。
(これはCODEBASE内では有名な話…だと思っていますw)
方法論を示すのはその後です。
しかし、ここで気をつけなければいけないのは方法論を押し付けないことです。
例えばプログラムのデバッグをする時に、ログに吐き出す方法か、Ruby on Railsならirbやpry、Laravelならxdebugなどのデバッガーを使用するかは人によって異なります。
先ほどの『その人に合った伝え方でなくてはいけない』で説明したことに通じますが、その使用感やデバッグのしやすさなど合う合わないがあります。
方法論を示す時は、その方法によって何を達成したいのか、目的としていることは何か、まず本質を明確にしてあげなければいけません。
その上で、教える側が補助輪の機能を果たしながら教わる側と一緒にその方法を試すことで、「やればできるんだ」という成果とその成功体験を積ませることが大切です。
教わる側にとって、その一連のプロセスが自走するための大事な経験になります。
4. 口出しするな。ただ見守ってやればいい。
ぼくの経験上、教えることが好きな人はすぐ口出しする傾向があるように思いますが、それは”教えることが上手”とは全くもって違います。
口出しするというのは、教わる側が考えている最中に先に解説したり、書いているコードの間違いを先に指摘したり、そもそも答えを教えてしまったり…etc。
これらが引き起こすこととしては、先に答えを示すことによって、自走するための成功体験に結びつくプロセスを奪ってしまっていることです。
相手が諦めかけたり、心が折れかけたり、嫌になりそうな時だけ口出ししたり手を差し伸べてあげればいいと思います。
ですが、ここで注意しなければいけないことは絶対に「なんでできないの？」と言わないことです。
こちらは単にできない理由を聞いているつもりですが、教える側は「こんなこともできないのか」と拡大解釈をしてしまう恐れがあります。
そうなってしまうと萎縮しはじめ、こちらは見守っているつもりでも、教える側にとっては監視されていると思われてしまいます。
ちなみにぼくが新卒の時、先輩エンジニアに同じことを言われましたが、「あなたの教え方が下手だからです」と答えました。
それ以来、その先輩エンジニアに教わることはなかったです。(正しくは”教わりにいく”ことがなかった)
今思えば最悪の新入社員ですが、当時の教わりにいかないという判断は正しかったと思います。(その前の発言は反省しています…)
基本的に相手が質問するまでは黙って見守ってあげましょう。
質問することも一つのスキルですので、それを身につけさせるためでもあります。
また、その人に合った教え方を見つけるための情報収集でもあります。
ですが、教わる側はよく「これであっていますか？」と正解を求めてきます。
ここでも、「ちゃんと見てるのでまずはやってみてください」と言ってプロセスを奪わないようにしましょう。
教わる側には、少なからず教える人が見てくれているという安心感と喜びがあります。
5. できたことはちゃんとFBし大胆に褒める
教える側の心得の最後としてこれを紹介したいと思います。
ぼくの経験上、教わる側ができたことに対してフィードバック(以下、FB)がちゃんとできる人は教えるのがとても上手です。
FBと言っても色々ありますが、共通していることは”一緒に”喜んでいることです。
それは両者でプロセスを共有できているからだと思います。
また、できたことをその場で一緒に振り返っています。
抑えるべきポイントを振り返り、何が良くて何が悪かったのか、継続するアクションと改善するアクションを洗い出しています。
先ほども書きましたが、教わる側は教える人が見てくれているという安心感と喜びがあり、こちらの顔色を見ています。
ポジティブなFBは積極的にし、できたこと・理解したことはちゃんと成功体験として植え付けてあげましょう。
そして褒めることもまた大切です。
ですが何が何でも褒めればいいというわけではありません。
特に難しい課題をクリアした時やずっとできなかったことができるようになった時、自力で解決できた時こそ褒めるべきです。
これは教わる側にとって自信に繋がります。
この自信を積み重ねていくことこそが自走するための最大の要因だと思います。
それでもなかなか自走できない場合は、褒めるに値する成果を少し下げてもいいでしょう。
とにかく、まだ自信に結びついてないことに取り組んでいてそれができた時は盛大に褒めてあげましょう。
教える側の心得のまとめ
以上が教える側の心得5つでした。
これらはプログラミングに限らず、何かを教える立場の人全般に言えることだと思います。
繰り返しになりますが、教えることのゴールは『自走力をつけさせる』、つまり『自分で育つ人』にすることだと思っています。
そのためには時間がかかります。
部下や後輩、生徒を持つ人は自分の時間を取られることになってしまいますが、一人一人と向き合ってほしいと思います。
あくまで主役は教わる側です。
教える側は補助輪の機能に徹しましょう。
あとがき
これまでお読みいただきありがとうございました。
さくっと書くつもりが9000字を超えていることに自分でもびっくりしています。
というのも、今までぼくが教えてきた人たちの中で、特にエンジニアにならせてあげられなかった人たちがいるので、自戒の意味も込めて書きました。(本当にすみませんでした…)
自分で書いておいてなんですが、この記事の内容通りではなく、教わる側も教える側も自分のスタイルを見つけてほしいという思いが強いです。
あくまでぼくの経験と感覚から導き出した一つの答えだということをご理解ください。
最後に、ぼくが講師を務めさせていただいているCODEBASEですが、プログラミングスクールはもちろん、定期的にイベントも開催していますので興味ある方はぜひ覗いてみてください。
それではみなさま、メリークリスマス！🎉🎉🎉
この記事が気に入ったらサポートをしてみませんか？