徒弟制度的な教育

若手のエンジニアがソフトウェアエンジニアとして成長する過程では、多くのことを学んでもらう必要があります。そのためには、継続した学習を習慣としてもらう必要があります。しかし、本人が技術書を読んだり、プログラミングしたりして技術書の内容を確認したりということで、勝手に伸びていく人は非常に少ないと思います。

今日の日本企業における若手技術者の成長には、徒弟制度的にコミュニケーションを通しての指導が必要となります。つまり、経験がある人が、経験の浅い人の学習を促すと同時に、本人の理解度を確認したり、補足の説明をしたり、誤りを指摘したり、コードの悪い点を指摘したりというコミュニケーションを必要とします。私自身の過去の経験から行ってきたことをその観点から振り返ってみると次のようになります。

• プログラミング言語Java教育　この教育は、ブログ内で何度も紹介しており、基本的に予習で不明であった質問に回答するという形式です。質問に答えると言っても、質問の意図を聞くことで、何を理解していないのか、何を説明してあげる必要があるのか、あるいは、何か基礎的な知識が不足していて、そこから説明してあげる必要があるのかを考えて回答を行います。そして、場合によっては、Javaとは関係のないコンピュータの基礎的な事柄を説明することが多々あります。
• アルゴリズムとデータ構造（書籍『プログラミング作法』）教育　「プログラミング作法」教育で述べていますが、勉強会ノートをベースとして、書籍『プログラミング作法』の第2章「アルゴリズムとデータ構造」を学習してもらいます。勉強会ノートには、第2章に関して104個の説明ポイントがあり、それに答えてもらうと同時に練習問題を行ってもらいます。そして、それらの説明ポイントの解答や練習問題のプログラミング結果を本人に説明してもらいます。その説明で不足している点や、本人が正しく理解していないと思われる部分に関しては、ホワイトボードに視覚的に書いて説明してもらったりします。つまり、本人の理解レベルを把握し、理解が不十分な点をどうしたら本人に理解してもらえるかを考える訳です。
• 技術書の勉強会　非業務の勉強会は10年以上行っていますが、その勉強会でも同じように参加者が理解できていないくて、私が経験していたり知っていたりすることは説明します。勉強会には、私自身も学ぶことを目的としたものや、これだけの内容は若手に知っておいてもらいたいという内容の勉強会がありますが、どの場合でも、内容の理解に関して質問したり、説明したりを行うことになります。
• 日々の開発業務を通してのレビュー　業務なので当たり前かもしれませんが、設計レビューやコードレビューを通して、作成者が何を考えているかとか、どこまで見通して考えているのか、コードの読みやすさに対する本人の認識度を把握するために、質問したり説明を求めたりして、指導することになります。

これらの活動には、夜の部の飲み会が伴うことも多々あるのですが、要は本人のレベルを把握しながら、本人のスキルを上げるために多くのコミュニケーションを伴う活動だということです。

日本企業では、ソフトウェア開発を行う業務であっても、大学でコンピュータに関する基礎知識を学んでいなく、ほとんどプログラミング経験がない人を採用する傾向が強いです。そして、入社後の集合教育で「必要なことは教えている」はずという淡い希望で、集合教育後に開発現場が新人を受け入れます。そして、開発現場は、地道な教育活動を「時間が無い」という理由で放棄しているのに、集合教育できちんと教育してくれという都合の良い要求だけをしたりする場合があります。それに加えて、開発現場は、今使っている技術と関係ないことは不要なことだと考える傾向が強いため、それだけを教えて配属してほしいと要求したりすることがあります。

ソフトウェア開発は、簡単な活動ではなく、非常に複雑な活動です。そのため、きちんとしたソフトウェアエンジニアとなってもらうためには、多くのコミュニケーションを伴う徒弟制度的な教育が必要となります。そのような活動を、人数が多いからとか時間がないからとかの理由で放棄してしまったり、自学習を行ってもらって理解度をテストで確認することで行うとしても、おそらくきちんとした技術者は育たないと思います。