ソフトウェア開発と人事戦略（1）

ソフトウェアエンジニアの生産性は、個人差が大きく10倍以上の差となると言われますが、マルチスレッド設計・プログラミングになると数十倍になります。つまり、エンジニアのスキルを上げる方が、圧倒的に組織としての生産性を高めることができるはずです。

日本のメーカーの多くは、新卒新人を採用する段階で、ソフトウェア開発に従事させる予定であっても、大学時代のコンピュータに関する学習やプログラミング経験をあまり問うことなく採用して、社内の研修やOJTで育てれば良いということになっていたりします。さらに、年功序列的制度の弊害により、能力に関係なく、横並びの給与体系となっています。

本来ならば、個人の能力差が非常に大きなソフトウェアエンジニアの採用に関しては、採用時点で米国のソフトウェア会社が行っているような採用面接を行い、ソフトウェア開発に関する能力があるのかを見極める必要があります。しかし、実際には、もう10年以上ソフトウェア開発を実際にしたことがない部長や事業部長が面接して採用する訳です。そして、あとは現場によろしくという次第になります。

日本のメーカーは、横並びの採用ではなく、ソフトウェアエンジニアに特化した採用を行うことで、ソフトウェア開発組織の生産性を向上できるはずです。そして、採用してしまってからソフトウェア開発に興味がない人に興味を持たせるような努力や無駄な集合教育をする必要がなくなります。

もちろん、単に採用を強化しただけではだめで、ソフトウェア開発組織そのものが良いカルチャーを持っていなければなりません（「ソフトウェア開発組織が持つべきカルチャー」）。そして、能力が高く、高い品質のソフトウェアを開発し、組織のカルチャーを良くする活動を行うエンジニアを高く評価する必要があります。

残念ながら新卒の採用は、戦略的に行われているというより、慣例に従って行われている場合が多いのではないのでしょうか。特に、ソフトウェア開発に従事させるのに、大学での学習や経験をほとんど問わないのにはどのような戦略があるのでしょうか。

新卒として就職した1984年に配属された部署には私を含めて20名の新人がいました。そして、当時、情報工学科を卒業した学生は日本でも少なかったのですが、20名のほとんどがコンピュータサイエンスを大学で学んでいたのです。戦略的に採用したのか配属したのかは当時新卒であった私には分かりませんが、今日では大企業であっても、ソフトウェア開発に関しては大学の専攻を問わないような採用が行われているのではないかと思うぐらい文系の学科も含めて様々な学科から採用しています。

（「ソフトウェア開発が好きでないサラリーマンエンジニア」）

本当に技術職を続けたかったの？

「本当は技術職を続けたかったけど、会社の制度上仕方なくマネージャになった」という人で、本当にソフトウェアエンジニアとしてソフトウェア開発を続けたかったの？と疑問符が付く人が多いです。ソフトウェア開発業界が面白い点の1つは、絶えることなく新たな考えやソフトウェアが登場することです。

したがって、会社ではマネージャ職であって直接手を動かして開発していなくても、学ぶことはたくさんありますし、自分が開発業務では経験しなかった概念や手法は書籍を通して学び続けることができます。

私自身は、直接自分で開発を行っている期間、コンサルテーションなど中心として、直接は開発していない期間を繰り返してきています。

1984年8月～1996年8月　開発していた期間
1996年9月～2003年1月　マネージャ、コンサルテーション等
2003年2月～2009年8月　開発していた期間、技術教育、マネージャ
2009年9月～　　　　　　　 コンサルテーション、技術教育
（そろそろ開発へ戻る時期かと考えています）

自分では開発しないマネージャや管理職であっても、ソフトウェア開発が好きなのであれば、何らかの形で学び続けることはできます。しかし、実際には、マネージャになったら技術のことは学ばない人が圧倒的に多いのではないのでしょうか。その結果、部下が必要な技術を学んでいるかということにも関心が薄くなっていくのだと思います。

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

継続して学習する
　多くの人は、社会人となった数年は、業務をこなすために様々な学習を行います。しかし、残念ながら業務をこなせるようになってしまうと、多くの人が学習する習慣を失ってしまいます。その結果、最初の数年で習得した非常に狭い範囲の知識だけでソフトウェア開発を行うことになります。
　その状態で、マネジャーに昇進し、自分では直接開発しないとうだけの理由で学習しなくなってしまう人が多いです。そして、40代になった時に、技術的には何も若手を指導できない状態になってしまいます。
重要なことは、若い時から学習を継続することです。たとえ、自分では直接開発しなくても。管理職であっても、技術の学習を継続することで、実際に自分ではその技術を使用しなくても、若手に使用させることもできます。
　また、新たな技術などを若手から業務中に説明してもらうだけで、分かった気にならないことです。どれだけ若手がきちんと技術を理解しているかを把握するためには、自分も技術の学習を継続しておく必要があります。

レビューを行う
　ソフトウェア開発では、エンジニアの報告を聞くだけでは、きちんとしたソフトウェアを開発しているかは分かりません。実際に、書かれたコードを見ないと分からないのです。したがって、自分で直接開発しなくなっても、レビューアーとして設計レビューやコードレビューを行うことは重要です。
　レビューを行うことで、エンジニアのスキルを正しく把握することが可能となりますし、現場での問題点も見えてくるかもしれません。そして、直接開発しなくても、レビューを行うことで、自分のスキルレベルを保つことが可能となります。
　自分が長年使用してきた技術を用いたソフトウェア開発でのレビューであれば、経験を生かしてレビューすることができます。しかし、その状態は、数年と続かない可能性は高いです。なぜなら、使用される技術が長い年月の間に変わってしまうからです。そのために、継続的にレビューを行うためには、使用されている技術に関して、学習が必要となってきます。
　たとえば、ずっとC言語で開発していたが、新たなプロジェクトではJava言語を使用するとなると、様々なことを学習しなければなりません。オブジェクト指向設計から始まって、Java言語そのものの学習や、Java言語で必読書とされる書籍を読むとかです。そうしなければ、開発現場でレビューすることは不可能となります。

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

これらすべてを行う必要はないかと思いますが、「本当は技術職を続けたかった」と言うのであれば、マネージャになってもどれか1つは続けてもらいたいものです。

コードレビューの視点 009

修正後も自分で見直す

コードをレビューした際に、様々な指摘をします。そして、記録を重視する組織では、必ず指摘事項をすべて記録して議事録として発行します。一方、ペアプログラミングでは記録することより、最終的なコードの品質が高くなることが目的です。どちらも品質の高いソフトウェアを開発することがその目的の1つです。

実は、議事録として発行するというのが意外とくせ者です。どういうことかと言うと、担当者は指摘事項を修正しただけで修正が完了したとして、再レビューへ持ってくることがあることです。そして、議事録にある指摘事項を1つずつ確認しようとします。

でも、実際に修正されたコードを見ると、さらに指摘すべき項目が多く見つかったりします。特に、最初のコードレビュー時における指摘は、頭の中で指摘した内容が修正された状態をイメージするだけであり、ペアプログラミングのように目の前に修正結果が見える訳ではありません。

その結果、コードレビュー後に指摘事項に従って担当者がコードを実際に修正してみると、さらに改善すべき点が見つかるはずです。しかし、残念ながらスキルレベルの低いエンジニアほど、指摘事項だけを修正して、自分ではもう一度見直すことなく再レビューへ持ってきてしまいます。

私自身の性格もあるのかもしれませんが、再レビューでも最初から目を通します。議事録に書かれた指摘事項が修正されていることを再レビューで一つ一つ確認することは好みません。特に指摘事項の数が多いほど、もともとのコードの質が低いのであり、修正後のコードをもう一度見直す必要があります。指摘事項を修正したかは、担当者が自分で行えば良いことです。むしろ、修正後のコードに何か指摘されるような問題はないかを担当者が自分自身で確認する習慣と実際に確認することが重要です。

違和感 （2）

日本の組織というのは、建前で言えば、上司が部下の育成責任を持つことになっています。そして、上から下へと順に育成責任が落ちていきます。つまり、新卒新人の育成はOJTトレーナーである数年先輩の責任、その先輩の育成はさらに上位の職位の人の責任と順に育成の責任が連鎖していきます。

ソフトウェア開発に関して、この育成責任の連鎖が建前通り機能して、きちんとしてソフトウェア技術者集団となっている組織は数少ないのではないでしょうか。それは、ソフトウェア開発そのものが非常に複雑な物を、家内手工業的に頭の中で考えて手を動かして開発しているからです。数週間や数ヶ月行っても熟練工にはなれません。

『ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード』や『アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得』では、ソフトウェア開発では、徒弟制度的な育成が必要であることが述べられています。Richard Gabrielは、「ソフトウェアを書くことは芸術であり、本当にうまくなるには10年を要する。」とも述べています。

さらに、ソフトウェア技術は止まることなく発展していますし、身近に使えるコンピュータさえマルチコアのCPUが当たり前となってきています。そのため、高度なマルチスレッド設計を含めて、数年だけ先輩である人に現場の若手の育成を任せるのは限界があるのではないかと思います。

(「違和感」)

11冊目の翻訳本 （3）

「ソフトウェアエンジニアの心得」の教育や講演でよく聞かれる質問で、「翻訳するようになったきっかけは何ですか」というものがあります。

1999年でちょうど40歳になった頃に漠然と考えたことは、「2000年からは雑誌に記事を書いたり、翻訳したり、本を書いたりという外向きの活動をしたい」ということです。でも、何か始める訳でもなく、ただそう思っただけでした。

1999年12月だったと思うのですが、Javaカンファレンスという団体の個人会員だったので総会に出席する際に、当時私が開発のサポートをしていた若手を一緒に連れて行って公開講演と懇親会に参加しました。懇親会の席で技術評論社の編集の人と話す機会があり、『The Java Programming Language, Second Edition』が翻訳されていないことや他の話をしました。

懇親会後、当時技術評論社から出ていた雑誌『Java PRESS』に投稿してみようと思って書いたのが、『Java PRESS, Vol.11』に掲載された

「The Java Programming Language, Second Edition」について

です。幸い、採用していただけることになりました。

わずか1ページだけの記事でしたが、記念すべき私の最初の雑誌の記事でした。経緯は全く覚えていないのですが、同じVol.11にもう1本記事「AWT/Swingにおけるイベント処理のメカニズム」を書いています。こちらは、12ページ書いています。それ以降は、多くの記事を『Java PRESS』向けに書いています。

そのVol.11の記事がピアソンの担当者の目に留まって、翻訳の予定はないことを電子メールで知らせていただきました。その後、メールのやり取りの中で、「柴田さんも何か翻訳してみませんか」という誘いを受けたのです。それで、やりますということで、当時出版される予定の『The Java Programming Language, Third Edition』を翻訳することになりました。しかし、実際に出版された本が送られてきてびっくりしたのは、第2版よりもページ数がほぼ倍になっていたことです。

11冊目の翻訳本 （2）

4月から始めた翻訳作業ですが、やっと40%程度終わった感じです。最近は、できるだけ以下の生活パターンの中で翻訳作業をしています。

• 3時30分過ぎに起床して、5時まで翻訳作業
• 通勤電車の中で校正作業（座れた時だけ）
• 7時15分過ぎから9時前までスターバックス@海老名での翻訳作業

月曜日と木曜日は、会社で朝に勉強会を開催しているので、スターバックスでの作業はなしです。仕事で外出時は、長い時間電車に乗る場合には、電車の中でもノートPCを開いて作業したりしています。夕活はほとんどなしで、まっすぐ帰宅することが多いです。

出版社によってはLaTeXでの入稿を受け付けないところがありますが、翻訳は基本的にLaTeXで行っています。そのために、本文の翻訳および索引作りまで基本的に私の方で行って出版社へ納品します。