So-net無料ブログ作成

業務を通した学習の落とし穴 [プログラマー現役続行]

業務を通した学習の落とし穴

 新たな技術を習得するのに最も効率的な方法は、業務で使用している技術について学習することです。業務で使用していますので、すぐに業務に役立ちますし、多くの時間その技術に接しているため、効果的に学習することができます。
 業務を通じての知識の蓄積は効果的なのですが、落とし穴もあります。それは、業務をこなすのに最低限必要な事柄だけしか学ばないで終わってしまうことです。  たとえば、何年もC言語を使用して組込みシステムを作ってきたエンジニアで、ポインタの使用方法を知らない人がいるとは想像できないかもしれませんが、実際には知らない人がいます。なぜ知らないかというと、グローバル変数を多用した設計しかしたことがなく、構造体であっても、決してパラメータとしてそのポインタを渡す設計をしたことがないからです。

『プログラマー”まだまだ”現役続行』(p.104)
長年同じ種類の開発を行っていて、自分は何でもできると思っても、それは、「井の中の蛙大海を知らず」だったりすることがあります。C言語でポインタが分からないのは極端な例かもしれませんが、関数ポインターを使用してオブジェクト指向的プログラミングをしたり、あるいは、いわゆる抽象データ型(Abstract Data Type)を実践したりしている人は意外と少ないです。さらに、ITronなどの組込システムだけで長年開発を行ってきた人の中には、簡単なファイルの読み書きなどのUnixシステムプログラミングさえ、まともにできない人がいたりします。
業務がこなせるようになったら

 業務をこなせるレベルになったら、さらに、その技術を深く理解するために、関連する書籍を何冊か読むとよいでしょう。今度は、ある程度その技術を理解して習得しているため、理解も容易になります。この段階で、その技術を作り出した人たちが執筆した技術書を読むと、必ずといっていいほど、自分が知らなかったことが解説され ていたりします。
 また、自分の理解が間違っているとしたら、それを正して、さらに深く理解するチャンスとなります。自分がきちんと理解していたとしたら、その本の誤った記述に気づくかもしれません。このようにしっかりと学ぶことで、その技術に関しては質問されても答えられるようになることを目指してください。
 直接自分が担当している部分の技術だけではなく、その基盤となっている技術も同時に学ぶことも重要です。
 たとえば、最近はリナックスが広く普及してきており、リナックスカーネルに関する書籍も出版されています。もし、業務でリナックスを使用しているとしたら、リナックスのコマンドやツールの使用方法を学ぶことも重要ですが、一般的なOS(Operating System)に関する勉強や、リナックスカーネルに関する勉強もしておくことが重要です。
 「〇〇に関しては、△△君に聞けば答えてくれる」といわれるようになってください。質問されたときに、必ずしも即答できないかもしれませんが、その場合でも、どの書籍をどのように調べればよいかを適切に知っていて、調べられることが重要です。

『プログラマー”まだまだ”現役続行』(p.104)
継続して学習をする習慣は、若い頃から身に付ける必要があります。社会人となって2、3年もすれば会社の開発業務はこなせるようになり、その結果、学習をやめてしまう人が増えます。特に、C言語での開発しかしていない人の場合には、その傾向が強いです。2000年の頃に私が200人程度のエンジニアに対して教育を行ってアンケートを取った時にも、C言語での開発しかしていない人は、本を読まない人が多かったです。
読んだ本から実力がわかる

 その人がどのような態度で学習してきたかは、「どのような本を読んだことがありますか?」とか、「最近読んでいる本は何ですか?」と聞くことでわかってしまいます。
 あるいは、「この一年間で何冊技術書を読みましたか?」とか、「何冊購入しましたか?」という質問でもわかります。
 一冊も購入していないとか、読んでいないという人は、ソフトウェアの開発経験年数が10年以上であっても、あまり信用できなかったりします。

『プログラマー”まだまだ”現役続行』(p.114)

ソフトウェア開発経験が長いということは、それだけ、スキルが上がっていることが周りから期待されます。しかし、それがふたを開けてみると、本も読まない、実際にソフトウェアを設計したり実装したりすると、まともに設計できなかったり、自分で作成したプログラムでさえも説明やデバッグがうまくできなかったりしたら、周囲からも信頼されなくなります。そして、その失った信頼を取り戻すのは、長年の間に意識せずに身に付いてしまったソフトウェア開発に対する悪い癖を直す必要があるため、容易なことではありません。

第19期「プログラミング言語Java」コースを開講 [プログラミング言語Java教育]

私にとって通算19期目になる「プログラミング言語Java」コースをリコーITソリューションズ社内向けに今日から開始します。第19期は、10名でスタートです。

第10期からの正式名称は、「プログラミング言語Java基本技術習得」コースとなっています。プログラミングの初心者向けのような名称ですが、実際は全く違っていて、「虎の穴」コースです。

勉強会を開催する [プログラマー現役続行]

最近、別々の会社で(偶然?)同じ話を聞きました。それは、会社で勉強会を開催できないということです。理由は単純で、会社への入館・退館として自動的に記録されている時刻と申請する勤務開始時刻(あるいは終了時刻)の間に開きがあるのはダメだということです。たとえば、30分以上の開きがあるのは認められないということです。

通常、このような開きは、絶対駄目ということはなく、正当な理由を申請して、それを上司が承認すればよいことになっていたりします。しかし、それさえも上司が手続き上面倒ということで、ダメだということが本当の理由のようです。しかし、そのような職場は、その上司そのものが勉強会を開催したり、参加したりしないということが実際には起きています。

拙著『プログラマー”まだまだ”現役続行』の第12 章「30 代、40代の人たちへ」の「勉強会を開催する」では、私自身は、次のように述べています。
勉強会を開催する

 設計レビューやコードレビューに加えて、若手のエンジニアが学習を継続する習慣を身につけさせるために、率先して勉強会を開催することが重要です。それは、業務外としての勉強会です。
 上司が継続して学習することを示さない限り、部下が自発的に学習をして、きちんとソフトウェアを開発してくれると期待するのは無理です。そのためには、率先して勉強会を開催していく必要があります。
 マネジャーや管理職になった後に主催する勉強会というのは、3種類に分類されます。一つ目は、若手のエンジニアに最低限学んでほしい事柄を選んで、それに関連した技術書を選んで開催するものです。二つ目は、実際に開発で使用されている技術に関する技術書を選んで開催するものです。その場合、自分が知らない技術であっても積極的に開催することです。三つ目は、自分が学んでみたい技術に関する技術書を選んで開催するものです。
 私自身、最低限これだけは学んでほしいという意図で、勉強会をいくつか開催してきました。コンピュータの基本的な仕組みの理解のための『Introduction toComputing Systems』、基本的なデータ構造とアルゴリズムの理解のための『Practice of Programming』(『プログラミング作法』)、Linux Kernel の仕組みの理解のための『Linux Kernel Development』、デザインパターンの理解のための『Head First デザインパターン』、オブジェクト指向設計の原則を学ぶための『アジャイルソフトウェア開発の奥義』、良いコードを書くための『Implementation Patterns』(『実装パターン』)や『Clean Code』(クリーンコード)などです。
 自分では実際にあまり使ったことがない技術であっても、現場のエンジニアに使わせたりすることがあります。そのような場合にも、その技術をきちんと学ばせるために勉強会を開催したりもしてきました。たとえば、JRubyを用いて開発をさせていたプロジェクトでは、Ruby言語をきちんと学習させるために『プログラミングRuby 言語編』の読書会を開催しました。当然、日々開発に使用している現場の若手エンジニアのほうがよく知っていたりするのですが、私が読んで疑問に思うことは、そのエンジニアに聞いて説明してもらったりもしました。
 もちろん、自分が興味ある技術に関する技術書の勉強会も行ってきました。
 マネジャーや管理職に昇進して、実際に自分が開発をする比重が減ったから、勉強会が主催できないとか参加できないということはありません。非業務で始業前に行うことは、管理職という立場であっても当然できるのです。
『プログラマー”まだまだ”現役続行』(p.240)

平日に自発的な勉強会を開催するには、会社の会議室を利用するのが便利です。会社の外で場所を探して勉強会を開催するのは意外と難しいです。そのため、会社で勉強会を開催してはいけないとなると、必然的に勉強会そのものが消滅してしまいます。

平日の朝に行う勉強会は、私自身は現在は開催していません。その理由は、開発拠点が多すぎて、参加希望者が地理的に分散しているため、それらの拠点を結んでの通信設備の準備などが面倒なのとホワイトボードに書きながらの議論がやりにくいからです。その代わりに、月に1回、土曜日に開催するようにしています。幸い、地域の住民にも公開している会社の施設があり、その施設の会議室を利用して開催しています。

要は、上司が「勉強会を開催する」あるいは参加するのであれば、上記の勤怠問題は、その上司がきちんと対処してくれると思います。勉強会に参加しない上司が、勉強会を実質的に禁止するような制度の運用を押しつけてくるようなソフトウェア開発組織では、ソフトウェアエンジニアの個々の成長だけでなく、組織の成長も期待できないかもしれません。