プログラミング講師のテクニック集

ソフトウェア開発の仕事をしていると、例えば自社の新入社員研修などで講師の仕事を求められる場合もあると思います。勉強会などでも自分が前に立つ機会はあるでしょう。

そんな場合に読める内容として、この記事では私が講師の仕事で心掛けているテクニックを箇条書きでまとめてみたいと思います。

ここに書くのはある意味小手先のものが中心で、もっとベースになる「技術を教える」ための考え方については 「技術を教える技術」 に書いています。併せて読んでみてください。

なお、この記事の内容は「全部やらなければならない」というものではなく、「何か参考になりそうなものがあれば使ってみてください」という程度の内容です。人によって考えが違う部分もあると思います。

ということを踏まえた上で、以下テクニック集です。

研修の要件を確認する

ソフトウェア開発に要件があるように、研修や勉強会（以下、両方合わせて「研修」と書きます）にも要件があります。

例えば、同じ 30 人程度の規模の新入社員研修でも、「落ちこぼれる新人が出ないように丁寧にやってほしい」という案件もあれば「競争心を養うために上に合わせてガンガン進めてしまってほしい。その結果何人か脱落しちゃっても構わない。」という案件もあります。

社内外の勉強会やその他の研修でも、参加者や人事担当者の求めるゴールというものが存在するはずです。

研修には学校の学習指導要領のような全国的に決まった要件や進め方が存在しない以上、どのようなスタンスで、どのような内容を教えて、結果何ができるようになってほしいか、というのはそれぞれ場合によって異なります。

ゴールが違えば、当然進行のスピードや盛り込む内容、さらには言葉選びなどコミュニケーションの取り方まで変わってきます。

受講者や研修企画者は何を求めているのか、予め確認しておきましょう。

研修の進め方を説明する

人間何事も、先が見えていないとそれだけで不安になったり集中できなくなったりするものです。

テキストの目次ページを軽視せず、この研修では何をどこまで学ぶのかを最初に明確にしておきましょう。

また内容だけでなく、進め方についても予め説明があると安心です。

座学と作業の時間配分はどれくらいなのか、何分おきに休憩が入る予定なのか、受講者自身が何かを発表する系のワークがあるのか、何時に終わるのか、質疑応答の時間は用意されているのか、など、研修によって変わり得る部分を中心に、最初に一通り説明すると良いでしょう。

それにより、研修全体の進み方を踏まえた上で今自分が何をしているかが明確になり、内容が理解しやすくなります。

テキストの流れに沿って説明する

受講者は、目の前にテキストが用意されていれば自然と「この研修はこのテキストに沿って進むんだな」と考えます。

一方で講師をやっていると、特に自分ではない誰かがテキストを作っている場合、テキストそっちのけで「自分の考えるより良い教え方」を追求しがちです。その結果としてページが前後しての説明になったり、ページを飛ばしたり、テキストの文章とは違った言い回しで説明してしまう場合があったりします。

そうなってしまうと、受講生としてはテキストと講師のトークのズレに混乱して理解が難しくなるだけではなく、例えば話の内容に忘れた場合にテキストのどこを読み直せば思い出せるのか分からなくなったり、研修後にテキストを見返しても研修の内容と違うことが書かれていたりと、研修の要件で想定される知識が身につかない問題も発生します。

いかにテキストが個人的にイケてないと感じたとしても、それを否定したり無視したりすることは受講生にとってデメリットの方が大きくなってしまいます。

テキストに反発するのではなく、テキストの意図を汲み取って最大限活用し、その上で自分の知識や解釈を付け加えるのが良いでしょう。付け加えであれば、受講者は「テキストに書いてないことまで教えてくれて得をした」と感じられるはずです。

その上で、テキストのイケてない部分はあとでこっそり直します。

語尾の「〜です」と「〜だと思います」を明確に使い分ける

特にソフトウェア開発の分野では、「事実」と「意見・解釈」を区別するのはとても重要です。「事実」は誰がどう説明しても変わらない部分で、特にその技術の開発者がそうであると説明している部分です。

例えば、

「Git は無料でオープンソースなバージョン管理ツールです」

（原文）Git is a free and open source distributed version control system

https://git-scm.com/

これは（少なくとも現時点では）「事実」です。公式サイトの1行目に書かれているので、誰もこれを否定することはできないでしょう。否定できないので、当然そうであるという顔で話題に出せますし、それを前提にその先の学習を進められます。

一方で

「Git は一番イケてるバージョン管理ツールだと思います」

これは「意見・解釈」です。人や場合によっては Git ではなく Subversion が良いと言うかもしれませんし、そもそも「イケてる」の定義が曖昧で主観的です。モノによっては宗教戦争に発展することもあるでしょう。

「意見・解釈」は「事実」と違い、他の意見や解釈が存在することを前提に、なぜそのように言われているのかを調査し考えることが、その技術の理解のために重要になります。

しかし、受講者がその分野に明るくない場合、それが「事実」なのか「意見」なのかを内容から区別するのは困難です。そんな時に受講者が頼りにするのが語尾の「〜です」「〜だと思います」の違いだと思います。

講師によっては自信や説得力を示すためになんでもかんでも「〜です」で断定したり、逆にクセで「〜だと思います」を連発してしまったりします。

それがどちらだったとしても、「事実」と「意見・解釈」を誤解してしまうとその後の学習やコミュニケーションに支障をきたしてしまうため、講師としては意識してこの2つの語尾を使い分けると良いでしょう。

受講者の知識をアンケートしない

研修で「この中でプログラミングをやったことある方ってどれくらいいらっしゃいますか？」のようなアンケートをとる場面がよくあります。主に受講者の理解度によって研修の進め方や説明を調整するのが目的だと思います。

しかし、私の個人的な経験上、このアンケートが役に立つことはほぼありません。

たとえば 30 人の新入社員にアンケートした結果、そのうちの 29 人はプログラミング経験者、残りの 1 人は Hello World もやったことがない、ということが分かったとして、では講師は Hello World を飛ばして説明してしまって良いのでしょうか？手が挙がらなかった 1人を置いていってしまって良いのでしょうか？

その答えは「要件による」です。

最初に書いた通り、研修には常に「要件」があります。その要件が「プログラミング経験のない1人を置いていってしまって良い」という内容であれば、最初からアンケートをとるまでもなく全員にプログラミング経験がある前提で進めてしまえば良いですし、逆に「誰も取りこぼしを出してはならない」という要件であればやはりアンケートをとるまでもなく最初から丁寧にやれば良い話です。

例外は「満場一致」で同じ回答があった場合ですが、経験上、例えば 5人のクラスであっても満場一致になることはごく稀です。

それよりも、もし1人だけ手を挙がらない人がいた場合、その人が「自分のせいでクラスの進行が遅くなってしまっている」という後ろめたさや劣等感を感じてしまうリスクが発生します。

アンケートをとることによって研修の進行を調整できる（かもしれない）メリットは確かにありますが、経験上、多くの場合に満場一致せず当初の予定通りの進め方になることや、一部の受講者が手を挙げられなかったことによるリスクが発生することを考えると、「とりあえずアンケートをとってみる」のはあまりオススメできない、というのが私の意見です。

もちろん、「受講者の状況を把握してその後のサポートに活かす」「ただ知りたいだけ」「退屈な座学の気分転換として差し込む」など他の目的がある場合はこの限りではありませんが、そうだとしても全員に結果が共有される「挙手」という手法が最適かどうかは立ち止まって考える必要があるかな、と思います。

「何のための技術なのか」を説明する

こだわりの強い開発者ほど、なにかひとつの技術に対して好き嫌いがあり、悪口を言わせたら一晩飲み明かせるような場合もあるのではないかと思います。

しかし、それを研修で出してはいけません。

世の中の全ての言語、フレームワーク、製品、技術にはそれが作られた背景や理由が存在します。また同じように、一つ一つ技術やサービスのインターフェースや仕様にも、そのような形になった理由というものが存在します。

ある開発者にとっては「自分は絶対使わない」「気に入らない」と思っている技術でも、他の開発者にとってはベストソリューションであることもあるはずです。単純にその技術の良さを理解できていない可能性もあるでしょう。

好き嫌いという理由で、誰にとってどんな場合にどの技術がベストソリューションなのかを考える機会を受講者から奪うことにメリットはありません。

研修として伝えるべきは、その技術が生まれた背景や使われる理由、その一方で改善を求められている課題を淡々と伝えることです。それを伝えることが、受講者が冷静に技術を理解、評価し、他の類似技術と比較してさらに理解を深める第1歩になるからです。

それを伝えた上で、「個人的な意見」として自分の好き嫌いを少し入れるくらいがちょうど良いでしょう。

重要でない「ちなみに」話をしない

いろいろ知っている講師ほど、講義をしていて「あれも、これも」となってしまい本筋を脱線して「ちなみに」話を入れがちです。

そんなときに思い出したいのは、受講者はすでに初めての内容ばかりでパンクしているかもしれない、ということです。

特にプログラミング未経験者向け新人研修などで顕著ですが、受講者にとってその研修の内容は端から端まで未知のものです。テキストの内容ですら理解が追いつかないという場合も少なくないでしょう。

そんな状態で、さらに追加情報を与えてしまうとどうなるかは考えるまでもありません。

とは言え、講師としても「テキストに書いていないけど重要な部分」は補足したいですし、別にパンクしていない余裕ある受講者にとってはもっと多くの知見が欲しい場合もあるでしょう。

そんな時は、「余裕のある人だけ聞いてもらえれば良いのですが」などのクッション言葉を入れて、「別に今頭に入れなくても問題ない」感じを演出した上で話をすると良いでしょう。余裕ある人にとっては有益な情報として取り入れられますし、余裕のない人にとっては聞き流して問題ないと安心できます。

最悪なのは、「ちなみに」話がさらに「ちなみに」話に入り込んでしまって、今何を学習する時間なのか講師も受講者も迷子になってしまうことです。

「ちなみに」話をする場合は、横道に入っていること、必ずしも聞かなければならない訳ではないことを双方が認識できる形で話したいところです。

ハンズオンでは自分の操作を言葉に出す

これは慣れていないと難しい問題なのですが、ハンズオンなどで受講者の前で PC を操作したりするときに、つい作業に集中して無言になってしまう場合が多々あります。

講師本人にとっては「画面見れば何やってるか分かるよね」という意識があるのかもしれませんが、実際に受講者目線でその作業を見ていると、「え、今何したらどうなったの？」と混乱する事態が少なからず発生します。

例えば IDE の「Ctrl + クリック」で変数やメソッドの定義元にジャンプする動作は、前のスクリーンだけ見ている受講者側は「なぜかいきなり開いてるファイルが変わった！」と感じてしまいます。

他にも、例えばビルドボタンをポチッと押して講師が黙ってビルド待ちしてしまうと、受講者は今何待ちの時間なのかが分からず、どこを見れば良いのか分からず、自分が作業についていけていないのではと不安になってしまいます。

そんな不安や混乱を感じさせないよう、何か手元の作業を見せる場合は必ず一つ一つの動作を言葉で説明すると良いでしょう。

「ちょっとここで定義を確認したいので、Ctrl 押しながらクリックして、こうすると定義元が表示されますので、この部分を読むと、、、あっ、なるほどこう書いてあるんですね。じゃあここはこうですねー。」

という具合に、何をしたくてどう操作をして、結果どうなったから次に何をして、という「頭の中」と「手の動き」を見せることで、受講者にとっては状況を把握できるだけでなく「現場の開発者が何を考えて何をするか」が理解できるメリットがあります。

どうせ口は暇にしている時間ですので、手を動かしながら口も動かせるよう意識してみると良いでしょう。

まとめ

ということでひとまず以上です。

最初に書いた通り、ここに書いたのはあくまで個人的な工夫や今まで自分が指摘されて直した点であって、絶対的に「守らなければならない」ものではありません。

ここに書いた内容のどれかが、ある日突然「今度社内で研修やるからみんなに教えてよ」と言われてしまった開発者への何かしらのヒントになることもあるかな、と思ってまとめてみました。

何かの参考になれば嬉しいです。