柴田 芳樹 (Yoshiki Shibata)

2010年に原著が出た本ですが、翻訳本が出たようです。

Go言語（http://golang.org/）のリリースに合わせて執筆された本として以下の3冊が出ています。

こちらは、kindle版はまだ購入できないようです。ソースコードやサンプル頁は、こちらからダウンロードできます。
http://www.qtrac.eu/gobook.html


Kindle版はこちらです:The Go Programming Language Phrasebook (Developer's Library)
サンプルコードやサンプル頁は、こちらからダウンロードできます。
http://www.informit.com/store/product.aspx?isbn=0321817141

この本は、Acknowledgments（謝辞）のページを読んでもらうと分かりますが、すでに私の方でほぼ翻訳が終わっています。しかし、残念ながら出版は未定です。

Kindle版はありませんが、電子版はこちらで安く購入できます：
http://www.diesel-ebooks.com/item/9781469769165/Balbaert-Ivo-The-Way-to-Go-A-Thorough-Introduction-to-the-Go-Programming-Language/1.html

一年間のプログラミング言語Java教育を行っていると、「ハッシュテーブルの季節」と私が呼んでいる時期が到来します。どういうことかと言うと、テキストである『プログラミング言語Java第4版』の第3.8節「Objectクラス」（86頁）にhashCodeメソッドの説明があるのですが、その内容に関する質問を解説するために「ハッシュテーブルとは何か」ということから説明しないといけません。特にその節の最後の段落でIdentityHashMapの解説があり、その節になると誰も理解できていないのが毎年の恒例となっています。

そもそも、ハッシュテーブルとハッシュコードを、大学時代あるいは会社に入ってから研修で習っていないのか、習ったけど内容が浅かったのか、習ったけど覚えていないのか、どちらにせよきちんと理解している人は毎年皆無に近いです。

拙著『プログラマ”まだまだ”現役続行』の第6章「コンピュータサイエンスの基礎力」で次のように述べています。

O表記が何であるかを説明できなかったり、ハッシュテーブルがなぜO(1)なのかを説明できないでソフトウェア開発を行っている人が、開発の現場では圧倒的に多いのではと危惧しています。実際、Javaを用いた開発でHashMapクラスを多用していても、その仕組みを全く知らずに開発しており、そのためにhashCodeメソッドを実装する理由を説明できない人ばかりだったりします。

現場の（若手）ソフトウェアエンジニアがハッシュテーブルを全く理解していないという現実に、私が初めて気付いて驚いたのが1998年か1999年頃です。残念ながら今でも状況は同じです。

今年も、1時間費やしてハッシュテーブルを説明しました。

（「ソフトウェア開発組織が持つべきカルチャー 002」）

エンジニアのレベルが分かる

コードをレビューすることで、コードを書いたエンジニアのレベルがある程度分かってしまいます。たとえば、以下のことが大体分かってしまいます。

• 使用しているプログラミング言語をどれだけきちんと学習しているのか
• コードの読みやすさにどの程度注意を払っているのか
• 必要な基礎知識を持っているのか
• マルチスレッドに関する知識は持っているのか
• etc

これらのことから、実際には本人がどの程度本を読んで学習しているのかとか、サラリーマンエンジニア（「ソフトウェア開発が好きでないサラリーマンエンジニア」）なのかとかもある程度分かってしまいます。

エンジニアのレベルが分かってしまえば、与えた仕事の難易度が本人に適切かも分かることになります（「技術者のレベルとソフトウェア開発の難易度（9）」）。

もちろん、分かると言ってもレビューアーの方がスキルレベルが高い必要があります。

ソフトウェア開発は人が行う活動であり、手を動かしてプログラミングするという点では一種の家内手工業です。そのため、従事する人のスキルによって生産性、品質、および、技術的負債というのは大きく左右されます。したがって、本質的には個々のエンジニアのスキルを長期的に向上させることを組織として行っていく必要があります。

しかし、スキル向上は目に見えないし数値として測るのは難しいため、長期的視点に立ったスキル向上のための活動をソフトウェア開発組織としては避けたりする場合があります。代わりに、スキル向上以外の対策を真剣に検討することになります。たとえば、コードの品質を測るために静的解析ツール（カバレッジ測定、複雑度測定、FindBugsなど）だけに頼って品質を向上させようとします。そして、ツールが示す数値が開発プロセス内でのフェーズ移行基準として決められたりします。

本来、それらの指標は、開発者自身が客観的に自分が作成したコードの品質を確認するのを助けるためのツールであり、基準値をクリアーすれば品質が高いことを保証するものではありません。たとえば、コードカバレッジが100%というのはコードの品質を保証するものではありません※。
※ バグがあったり、品質が悪くても、コードカバレッジを100%にすることは可能です。

開発者が自分のコードの品質を確認すると言っても、開発者自身のスキルが高くなければツールが示すコードの状態を正しく解釈できなかったりします。たとえば、FindBugsが警告している内容の本質が分からずに、警告を消すための誤った修正を行ったりすることになります。そして、スキルの低いエンジニアは、コードの品質以前に指標をクリアーすることに注力することになります。

結果として、そのようなツールの導入だけでは、思ったほど品質が上がらなかったりして、結局は「ソフトウェアエンジニアのスキル」問題に戻ってしまいます。毎年、経験の浅い新卒新人の人達がソフトウェア開発組織には入ってくる訳であり、一時的にはツールやプロセスなどでスキル問題を回避しても、また同じ問題に直面することになります。

「プロセス中心ではなく、スキル中心（3）」

2000年に『プログラミング言語Java第3版』の翻訳を始めてから、改訂版も含めて10冊の技術書を翻訳したことになります。

http://www001.upp.so-net.ne.jp/yshibata/#BOOKS

今月末までに英語原著が発売になる予定の技術書を、昨年末から3月まで翻訳していたのですが、売れるかどうか不明ということで出版は見送りとなっています。

それで、現在は別の技術書の翻訳を行っています。こちらは、出版することは確定しているのですが、ページ数が600頁弱とかなりの量です。

平日は、仕事をしながらの翻訳作業は長距離走です。毎日、出社前に2、3ページを訳して、週末は多めに訳すことを何ヶ月も続けることになります。

4月から私にとっては通算第16期と第17期になる「プログラミング言語Java」コースを開始しました。第16期は、月初めの金曜日で、第17期は月末の金曜日に開催します。今回は、4月から開始なので、来年3月に終了する予定です。

第16期は私が講師です。しかし、教育者としての技術者の育成も目的として、第17期は社内の中堅エンジニアが講師であり、私は補助講師という立場です。

ソフトウェア開発では、画一的に教育で教えられることだけで済むことはなく、コミュニケーションを取りながら、こまごまとしたことを指導や指摘を行っていく必要があります。

延べ1,000人以上に教育を行っても、日々の開発業務で指導を受けない人達が伸びていく可能性は低いです。現場のエンジニアとコミュニケーションを取ることなく、一人で教えて指導するには限界があると当初からあきらめてしまうと、組織としては実は全くエンジニアのスキル向上が行われないのかもしれません。たとえば、一人で教えられる範囲は限界があるからと当初からあきらめて、ウェブベースの教育コースを用意しても、コースを用意した側の自己満足に終わってしまうのではないかと思います。

1999年頃から様々な教育を行ってきましたが、確かに人によってはそれらの教育（特に「プログラミング言語Java教育」）をきっかけとして一人で成長していった人もいたかとは思います。しかし、教育を受けた中でも、成長していった人達の大多数は、日々の開発業務で直接私と一緒に仕事をした（若い）人達です。

日々の開発業務で一緒に仕事をするというのは、教育では教えきれないことも話しますし、コードや設計のレビューもしますし、一緒にデバッグしたりディスカッションしたり、さらに、一緒に飲む機会も多くなります。つまり、必然的に日々多くのコミュニケーションを取ることになり、様々なコミュニケーションの場を通して、私自身の考えや経験を伝えていくことになります。

(「教育と場」、「教育と場 （2）」）

知識教育だけではなく、良い行動パターンを促進する

「技術の伝承と良い習慣の伝承」とも関連しますが、日本の企業でソフトウェア技術教育（特に新卒新人の技術教育）を担当している部門やグループは、何を教えたかということで教育体系をまとめようとする傾向があると思います。しかし、個々の教育コースの内容を見ると浅かったりします。

ソフトウェア技術というのは、毎年新しいものが登場し続けますので、すべてを教育コースで教えることはできません。そのため、ソフトウェアエンジニアに身に付けてもらうことは、知識だけではなく、継続して自発的に学び続けるということです。

たとえば、2000年から行っている「プログラミング言語Java教育」は、単にJava言語の知識を学ぶというだけではなく、膨大な自分の時間を使って専門書をきちんと学習する習慣を身に付けてもらうことも目的としてあります。実際、一年間の最後の成果発表会では、「学習する習慣が身に付きました」と発表する人も多いです。

まともに書籍を読むことなく、いつもネットで調べるだけということでは、非常に偏った学習方法となります。私自身が1998年からずっと継続してい行っている朝の専門書の勉強会も、継続して学習するという習慣付けを身に付けてもらうことも目的としています。英語の書籍による勉強会は、知識を吸収するだけでなく、英語で技術書を読むことに抵抗感を無くして、英語で専門を読むようになってもらうためです。また、最低限知っていて欲しいと思う「コンピュータの基礎知識」を学んでおいてもらう必要があるために、いくつかの専門書を用いた勉強会を開催してきました。

コードをレビューするというのは、読みやすいコードを書くということを常に意識してプログラミングする習慣を身に付けてもらうことも目的としてあります。

ソフトウェア開発組織のレベルを上げるには、教育体系を整備するだけではなく、好ましい行動パターンを促進する施策を行うのが長期的には良いと思います。

かつて、私自身の行動パターンをモデルとしていくつかの項目に分類して、それを元にアンケートを作成して、約70名のソフトウェアエンジニアに回答してもらい調査を行ったことがあります。その調査では、どの行動パターンがエンジニアのレベルと最も高い相関を示すかを調査しました。調査結果は今は持っていませんが、いくつかの行動パターンがエンジニアのレベルと相関が高くなっていました。

何が良い行動パターン（習慣）であるかは、ソフトウェア開発組織の中で整理してみるのが良いかと思います。ソフトウェア開発力が弱い組織は、悪い行動パターンを繰り返していることが多いです。

知識の伝達の場

コードレビューは品質を向上させるだけでなく、様々な効果があります。その1つが、知識の伝達の場だということです。特に、レビューアーとしてレベルの高い人、つまり、様々なソフトウェア開発経験を経た人がいる場合、コード上の問題点を指摘する際に、なぜ、それが問題になるのか、修正しないとどのようなことが起きたり、将来起きるのかを説明できたりします。もちろん、それだけでなく、プログラミング言語に関しても初心者が知らない落とし穴や書き方を指摘することもできます。

初心者が何もかもすべて教えてもらえると期待してもらっても困りますが、ソフトウェア開発組織としては、きちんとしたレビューが行われることは、知識を伝達するという行為でもあるということを認識する必要があります。