人にプログラミングを教えるときのポイント

最近では、人にプログラミングを教えることはほとんど無くなってしまったのですが。
学生時代、情報学科に所属していた頃は、よくクラスメイトや後輩にプログラミングを教える機会がありました。
その頃の経験を元に、人にプログラミングを教えるときのポイントを、まとめてみたいと思います。
実際に人に教えるときの参考にしてみたり。
また、逆の立場になって、プログラミングを教わる(or理解する)ためのポイントのヒントとしてご覧ください。

1.何が解らないのか？は直接聞かない。
「解らない」と言って聞いてくる人に対して、「何が解らないの？」と聞いた場合に「それも良く解らない。とにかく解らない」と返されるケースって良くあると思います。
また、実際に「ここが解らないんだけど」という相手に、その内容を説明してもいまいちピンと来ず、深く聞いてみたらもっと根元の部分の勘違いが原因だったりすることもあります。
「解らない」を具体的にするために、何が解らないのかを直接聞くのではなく、その人が理解しているところを順番に説明してもらう所からはじめてみましょう。
例えば、「C言語の配列が良く解んない」という相手の場合
・配列自体は理解できているけど、for等のループ構文の理解が甘く、配列を利用したコードの多くが理解出来ない。
・配列の添え字が0から始まるという事に慣れておらず、不正な添え字(10個の配列に対して10、とか)を書いてしまい、エラーになってしまう。また、エラー文の読み方も良く判っておらず、エラー文から原因のコードにたどり着けない。
・そもそも変数への代入から理解できていない。
等々、その人それぞれの理解度の違いがあるわけです。
同じ質問でも、各人が求める解答は違っています。
面倒でも、まずは「何処まで理解出来ているのか？」をよく聞きましょう。

2.例え話を過度に行わない。
プログラム言語の初期の頃には、よく、変数を名前のついた箱として教える事があります。
この理解をずーるずると引きずっていると、ポインタやオブジェクト指向のあたりで躓く可能性が高くなります。箱の実際の場所が、なんて言われても良く解らないですよね？
例というものはとても有効です。特に、プログラミングのように現実に形の無いものを表すためには、使わざるを得ない物です。
しかし、使いすぎると、例と実態のマッピングがうまく出来ず、理解出来ないという結果に繋がってしまいます。
「aって箱がこうなって、それで～、箱が～箱が～…がー！！！」なんて言って混乱しているような相手に対しては、一度、解り易くメモリ空間上での変数の扱いを説明してみると、氷が解けるように理解してくれる事があります。
変数以外にも、例で教わり例に固執している所為で、実際の実装が見えずよく理解出来ない事はよくあります。
相手の理解を踏まえつつ、タイミングを見計らって、実際の実装を説明してあげましょう。
もちろん、タイミングを見誤ると、相手の脳内はさらに混乱するので、よく注意してくださいね。

3.「何故」も説明する。
よく解んないけど出来る事を覚えるより、「これを覚えるとこういう事が出来る！」って物を覚えるほうが、理解が早いものです。
オブジェクト指向の説明で、犬クラスがどーのこーのだの、車クラスがどーのこーのだの聞いても、「実際に何が便利になるんだよ。読みづらくなるだけじゃねーか！」なんて不満を覚える人もたくさん居ます。
そういう人のために、「何故この技術が必要か？」「何故この技術が生まれてきたのか？」という何故もしっかり説明してあげましょう。
例えば、Javaのコレクションクラス周りは、利用頻度も高く、クラス設計の説明としても有意義だと思います。
実際にコレクションクラスを使ったコーディングをしながら、継承の利点、インタフェースの重要さを教えてあげると、実際に使える技術として納得してもらえます。
そのままIteratorパターン、更にはその他デザインパターンまで教えることが出来れば最高です！が、大抵の場合、時間と互いの体力がそれを許しませんね……。

4.優良なコードは最高の教科書。
どんな教科書やどんな授業も、優良なコードには適いません。
人に教えるときは、是非、コードベースで教えてあげてください。
コードを読むことを嫌う人は、良いプログラマにはなれませんし、良いコードを知る事は、読みやすさの重要さに気づ、良いコードを書くための第一歩にもなります。
いろいろなコードを例に挙げ、コードを読むコツを教えてあげましょう。
その時に、どれだけ「素晴らしいコード」を提示することが出来るか、というのが、解答者の力の見せ所にもなります。
自分で素晴らしいコードを書くことはもちろん、良いOSSプロダクトやサンプルコードの出所を沢山知っておくことが重要です。

5.答えには良いソースを添えて。
ソースというのは、ソースコードではなく、情報源の事です。
質問に対して答えるだけではなく、自分がその答えとなる知識をどこから学んだのか、プラスして教えるようにします。
例えば
「PHPでカンマ区切りの文字列を配列に分割するのって、どうやって書くんだっけ？」
と聞かれたときに、ただ「explode」と答えるのではなく
「explodeって関数で出来るよ。公式の関数リファレンスみてみ？探し方は……」
と教えるとか。
「MySQL使ってるんだけど、このSQL、もうちょっと早く出来ないかな？毎回処理が重くって……」
と聞かれたときには
「インデックスが綺麗に使えてないんじゃない？MySQLのインデックスはこれこれこうなってて……。……だから、こんな感じで書けると思う。MySQLのチューニングだったら、この書籍がオススメだね」
等、書籍を薦めるとか。
最近であれば、Google Groups等に数多く存在している、優良なコミュニティを教えてあげても良いと思います。
こうする事により、言葉では伝え切れなかった内容を、質問者が自分自身で補完することが出来るようになります。

最後に。
上記にあげた5つのポイントは、すべて、一つの目標のためのポイントになっています。
その目標は
「質問者が、自分自身で解決出来るよう、問題解決能力を身につける事。」

何が解らないのかを自分で理解できるようになれば、答えを調査する事がより容易になります。
例え話と実体へのマッピングが重要だと気づけば、実際の実装への関心がより深まり、誤解も少なくなっていくでしょう。
すべての実装に「何故そうなったのか？」があるという事に気づけば、コード・設計の意図を読む事が重要だと、気づくはずです。
コードリーディングの力がつけば、独学で沢山のコードの知恵を身につける事だって出来ます。
良い情報源に多く触れ、情報源を自分で調べる事ができるようになれば、良い情報、悪い情報の判断だって自分でつけれるようになります。

プログラミングに限らず、エンジニアの知識なんて、すぐに新しいものが必要になります。
自分の周囲の人が誰一人理解していないような事を、自分だけで調査して身につけなくてはいけない。そんな時がいつか必ずやってきます。
そうなったとき、ちゃんと自分の力で解決できなければ、長くプログラマ・エンジニアである事は出来ません。
そのための、独学で学んでいく力こそが、真にプログラマが身に着けるべき力だと思っています。

……何でもかんでも、自分に質問に来られると鬱陶しい。なんていう自分本位な考えも、もちろんありますが(苦笑)

学校ならともかく、業務中に質問を受けたときは、時間リソースの関係で中々しっかりと教えてあげる事は難しいかもしれません。
でも、時間が許すのであれば、相手のため、そしていずれ相手と一緒にコーディングをする事になるかも知れない自分のため、じっくりと教えてあげてみてください。
情けは人のためならず。いつかきっと、良い結果を導いてくれますよ。