最近は業務の中で、若いフロントエンドエンジニアにプログラミングを教えることが多い。
何か質問されたときに明確な答えをすぐに言えれば、それを伝えるだけで済む。しかし大抵はその答えを知らない。なぜなら、質問を受けた時点では状況や目的や前提までは把握していないからである。だいたいは「こうすればいい」という単純な話ではないので、実際のところ、原因を見つけ出す道筋ぐらいしか提供できないことも多い。
しかし、短絡的に答えを教えるより、答えを見つけ出す方法を伝えるほうが、将来的にも糧になると思っている。
結果や手法自体は、技術の進歩に伴い、役に立たなくなる可能性がある。しかし、答えを導き出す考え方やプロセスは、技術が変わっても長期に役立つ。プログラムのロジックを考える能力があれば、多少言語が変わっても適応できてしまうのと同じである。
だから、私がサポートする際には、質問者の問題を解決するということも大前提ではあるが、長い目で見て役に立つような教え方をしていきたいと思っている。
とはいえ、私の経験上、原因を探る時にやることはだいたい同じで、以下の3つに集約できる。
- 原因を絞り込む。（処理をコメントアウトするなどして、可能性をつぶしていく）
- 処理の流れを確認する。（意図しない処理の流れが原因のことがあるから）
- 思い込みを捨てる。（一度だけの処理と思っていても、二度三度処理されていることがある）
あとは見つかった原因をどう解決するかである。こういった基本的な考え方やプロセスが見に付き、自分自身で原因究明と問題解決ができるようになるためのサポートを行っていきたい。
