第3回Java研修OB・OG懇親会を開催しました

4月18日（土）に、今年で第3回となるJava研修OB・OG懇親会を開催しました。昨年の第2回は、横浜キリンビール工場見学と懇親会でした。今回は、次のような2部構成としました。

　　第1部　15:30〜17:20　技術セッション （みなとみらい）
　　第2部　18:00〜20:00　懇親会（横浜中華街）

技術セッションでは、Java研修の修了生の一人が勤務しているAtlassianのオフィスで開催しました。

Atlassian社のご厚意で場所を提供していただいたのですが、技術セッションが始まる前にオフィスを案内をしてもらい、0次会のビールも提供してもらい、ビールを飲みながら技術セッションを始めました。

技術セッションは、以下の3部構成としました。

[1] Atlassian社の技術・製品紹介（by Java研修修了生）
[2] Skeed社の技術・製品紹介（by Java研修修了生）
[3] Java研修の振り返り（私）

第1部の終了後は、横浜中華街へ移動して、懇親会を開催しました。懇親会だけ参加した人もいて、総勢27名の懇親会でした。今回は、10年振りぐらいに会った受講生もいたり、今年修了生となった人もいたりして、楽しい交流会になったと思います。次回は、来年です。

デバッグを支える知識（2）

デバッグの基本的な方法については、「デバッグの科学的手法」に説明しています。それに関連して、デバッグでは、正しい知識を持っていることが重要であると「デバッグを支える知識」で述べています。

デバッグにおいては、知らない部分を適当にきっとこうだろうと断定して進めるのは危険です。たとえば、fopenとfreadを使用して1バイトをハードディスク上のファイルから読み込むことを考えてみてください。この場合、具体的にどのように読み込まれるかの仕組みを知らないのに、「最初の1バイトの読み込みでハードディスクから1バイトだけ物理的に読み込まれる」と仮定するのは非常に危険です。

この場合、ハードディスクからOSを経由してどのようにして読み込まれるのか知らないのであれば、「どのような仕組みで読み込まれるか分かっていません」という認識することが重要です。つまり、分かっていないからさらに調べたり学習したりする必要があるということを認識していることなります。

正しい知識を持たない部分を「きっとこうだろう」と間違った仮定をいつも繰り返していては、ソフトウェアエンジニアとしては成長しません。きちんとした学習をせずに知識がないにもかかわらず、思い込みでデバッグすることは、避けなければなりません。

『Javaパフォーマンス』読書会

Javaパフォーマンス

• 作者: Scott Oaks
• 出版社/メーカー: オライリージャパン
• 発売日: 2015/04/11
• メディア: 大型本

先日募集した『Javaパフォーマンス』の社内読書会を4月27日(月）から始めます。参加者は、私を入れて5名と非常に少ないです。

この人数が少ないかというと、他の書籍の社内読書会でも最後まで続いた人達なので、特に少なくはないです。朝の読書会では、当初は参加者が多いです。しかし、普段から朝早く起きられる人でないと続かないため、結果として、少人数になってしまいます。

レベル２：見習い

「ソフトウェア・スキル・インデックス」では、7つのレベルを定義しています。その中で、レベル1である初心者は、次のように定義しています。

指導を受けながら実践ができる

拙著『プログラマー”まだまだ”現役続行』では、次のように解説しています。

　ある程度の基礎知識を身につけたら、ソフトウェアの開発では、本人の経験を積ませるために、難易度の低い開発業務を行ってもらうことになります。このレベルでは、ＵＭＬを学び、クラス図やシーケンス図を描いたり、実際に多くのコードを書いたりします。
　しかし、クラス図やシーケンス図を描けるということは、うまく設計できるということとは同義ではありません。したがって、成果物を常にチェックして、ソフトウェア開発業務を行わせる必要があります。
　ソフトウェア開発では、デバッグを回避することはできません。したがって、デバッグの方法についても、間違った考え方や憶測でデバッグしているようでは、その後の成長は望めません。
　このレベルでは、バグの原因が何であると推測できるか、その推測からバグの現象を説明できるかとの仮説を立てさせて、その仮説を証明するには、どのような方法で確認すべきかを、常に論理的に思考させる必要があります。そして、その確認方法（デバッグ文の挿入など）で仮説が否定された場合には、再度別の仮説を立てて検証させていきます。
　本人がどのようにバグを調査したかを確認するのは、重要です。誤った考え方でたまたまバグを発見した、あるいはバグが再現しなくなったというようなことを繰り返すと、成長が望めません。したがって、「バグを修正しました」と報告されたときは、論理的に説明できているかを常に本人に問うことが必要です。
　デバッグには、論理的に推論する力だけでなく、その推論を支える膨大な知識が必要です。初心者や見習いレベルの場合には、その両方が欠けています。
　論理的思考は日々の指導で、知識は継続した学習で、それぞれ身につけていきます。トレーナーは、見習いレベルの人材を、この二本立てで育成していく必要があります。ここでも、不適切なトレーナーや先輩に育成させると、本人も成長しないことになります。
　見習いレベルから初級職人レベルになるには、一、二年は要するかと思います。

情報工学系の修士課程を修了していれば、この見習いレベルの指導は必要ないかと思っていましたが、どうもそうではない人達も日本の大学を卒業した人達にはいるようです。ここで述べているように論理的にデバッグができて、説明ができないようでは、おそらく次の「レベル3：初級職人」の域には、一生到達しないかもしれません。

プログラマー”まだまだ”現役続行 (技評SE選書)

• 作者: 柴田 芳樹
• 出版社/メーカー: 技術評論社
• 発売日: 2010/09/04
• メディア: 単行本（ソフトカバー）

『RESTful Web APIs』読書会 終了

RESTful Web APIs

• 出版社/メーカー: O'Reilly Media
• 発売日: 2013/09/12
• メディア: Kindle版

2014年1月21日（火）から始めた『RESTful Web APIs』読書会ですが、開催しない週があったり、転勤で勤務場所が変わったりして、かなり進捗が悪かったのですが、今日、終わりました。最終会の参加者は、私を入れて3名でした。翻訳が出ていない本の読書会でした。

アウトプット力が低下してきている？

最近は、「検索の時代」になったため、大学でのレポートで、検索して、コピペして、仕上げる学生が多いのではないかと思います。確かに、大学で出される課題レポートであれば、検索して答えが見つかる可能性が高いと思います。しかし、企業内の文書作成では、そもそもネットで検索しても答えなどないものが多いです。たとえば、社内で作成されたソフトウェアフレームワークの仕組みを調べて、文書を作成する仕事が与えられたとして、ネットでは検索できません。

そうなると、フレームワークを調べる能力に加えて、それを分かりやすく文書にすることができないとだめです。しかし、残念ながら、そのような文章作成を学生時代行っていないため、レビューで「こんなことから指摘しなければならないのか」と思う低レベルの日本語の指摘もしなければなりません。例としては、「話し言葉」と「書き言葉」の違いとかです。たとえば、「機器へコマンドを送信する」ではなく「機器へコマンドを投げる」と、普段の会話で本人が使用している話し言葉でそのまま書いてきたりします。

ネットで検索すること悪いことではありませんし、昔と比べてはるかに多くの情報を簡単に調べたり手に入れたりすることができます。一方で、アウトプットは意識して行っていく必要があります。

初心者だからと言って、汚いコードを書くことが許される訳ではない

いつも講演や教育で話をしている「ソフトウェアエンジニアの心得」の講演スライドの中に次の一文があります。

初心者だからと言って、汚いコードを書くことが許される訳ではない

会社で給与をもらいながらソフトウェア開発に従事する場合には、資産を残すことが求められます。

ソフトウェアエンジニアの責任は、何年も使われ続けるビジネス資産を作り出すことです。ソフトウェアエンジニアが、他人の書いたコードを理解することができない場合には、そのコードはあっさりと捨てられ、一から書き直されてもおかしくはないでしょう。残念なことに、このような書き直しは頻繁に起きています。コードを読みやすく保守性を高めることは、コードを正しく動作させることと同じくらい、あるいはそれ以上に重要です。正しく動作しないコードは、動作するように修正することはできます。保守できないコードは、がらくたに過ぎません。

Taligent’s Guide to Designing Programs

どこかの建築会社に自分の家の設計・建築をお願いして、完成したら、出来上がりがひどい箇所があった時に、そのことを指摘して、「経験の浅い新人が担当したのでそうなりました」という言い訳されたらどう思いますか？

プログラミング経験が浅いという事実によって、会社におけるソフトウェア開発で、汚いコードを書いて残すことが許される訳ではないのです。しかし、実際には、何が良いコードで何が汚いかを初心者が判断することは難しい訳です。そのため、新人が書いたコードであっても、開発組織としてレビューを行い、きちんとした品質に仕上げさせる必要があります。

このことは、コードに限った話ではありません。作成してもらう文書もそうです。当然、作成された文書をレビューして、説明不足や分かりにくい日本語表現などを指摘したりして修正させます。

ところが、最近は、大学でもそのような文書作成の指導を受けてこないようで、何度も何度も分かりにくい日本語を指摘されて、修正を指示された結果、文書作成そのものが終わらなかったり、完成までに非常に長い期間を要したりします。その場合、レビューでレビューアがOKを出さないので、自分の仕事（文書作成やコーディング）が終わらないのであり、自分の責任ではないと考える人がいたりします。

若手に対するレビューは、単にアウトプットの品質を担保するだけのものではありません。数年後には、その人が次の若手をレビューして指導できるようになることも期待しているのです。もし、数年後に次の若手を指導できるようにはならないと判断されたら、レビューを通した指導もされなくなるかもしれません。

【社内連絡】『Javaパフォーマンス』読書会参加者募集

Javaパフォーマンス

• 作者: Scott Oaks
• 出版社/メーカー: オライリージャパン
• 発売日: 2015/04/11
• メディア: 大型本

ブログに書いていますが、社内向けの内容です。

JavaDay Tokyoの会場で中身を見たのですが、なかなか良さそうなので、社内で読書会を開催したいと思います。

希望者は社内の私のメールアドレスに、以下の件名のメールをください。

件名：　『Javaパフォーマンス』読書会参加希望

なお、同時に書籍の購入も手配しますので、購入希望の有無をメール本文に記入してください。

開催日：　毎週、月曜日　朝7時40分から8時45分
開始日：　2015年4月27日（月）
場所：　私が勤務している海老名リコーテクノロジーセンターのC棟19Fの会議室
申込み〆切：　2015年4月17日（金）
対象者：　リコー社員に限定しませんので、関連会社、業務委託、派遣の人も参加可です。
進め方： 最初から読んでいきます。

この読書会そのものは、非業務扱いです。また、他拠点を接続しての開催は行いません。

Kindle版『Java SE 8 実践プログラミング』

Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング

• 出版社/メーカー: インプレス
• 発売日: 2014/09/22
• メディア: Kindle版

やっとKindle版が発売されました。

Java誕生10周年の頃

Javaが誕生してから今年で20年になり、今日は、Java Day Tokyo 2015が開催されます。私も1996年からのJavaとの付き合いになるので19年が過ぎたことになります。

10年前の2005年には、日本ではJavaOne Tokyoが開催されて、Java誕生10周年が祝われました。JavaOne会場では、バースデーケーキも登場し、壇上でハッピーバースデイも歌われました。

JavaOne Tokyo会場

2005年のJavaOne Tokyo

前年の2004年には、Java SE 5.0が登場し、ジェネリックス、enum、アノテーションなどが追加されました。写真の左から2人目は、その5.0のコンパイラを一人で書いたNeal Gafter氏です。

この年には、Joshua Bloch氏とNeal Gafter氏が執筆した『Java Puzzlers』が出版されました。『Java Puzzlers』の日本語版は、このJavaOneに間にぎりぎり間に合い、会場では100冊が販売され、Joshua BlochやNeal Gafterがサインしていました。

Joshua Bloch氏のセッション

Java Puzzlers 罠、落とし穴、コーナーケース

• 作者: ジョシュア・ブロック
• 出版社/メーカー: ピアソン・エデュケーション
• 発売日: 2005/11/14
• メディア: 大型本

おそらく、日本版にだけ収録された「付録Ｃ」がなければ、もっと多くの部数が会場で販売されたはずです。しかし、付録Ｃは、日本語版に向けて新たに執筆された付録であり、英版には収録されていません。

JavaOneの前日には、Joshua Bloch氏とNeal Gafter氏、および、Java Puzzlersの翻訳レビューを手伝ってくれた人達とディナーを食べています。

Joshua Bloch氏とNeal Gafter氏

テーブルの上には、私のTiger本があるので、その時に贈呈したのだと思います。この時以来、二人は来日していませんので、日本で二人と食事をしたのは、この時が最後です。写真を良くみると、Joshua Bloch氏は、『Java Puzzlers』のTシャツを着ています。Neal Gafter氏は、カエルのTシャツです。彼は、カエルが好きなので、カエルがプリントされたTシャツを着ていることが多いです。

Java SE 5.0に対応した『Effective Java, 2nd Edition』が発売されたのは、さらに遅れて2008年です。

Book Storeで平積みされたEffective Java

写真は、2008年5月にサンフランシスコで開催されたJavaOne会場のBook Storeに平積みになった『Effective Java, 2nd Edition』です。

Java 8に対応した第3版については、まだ何も聞いていません。しかし、ある日突然、「Yes, it's Effective Java time again」というタイトルのメールが、Joshua Bloch氏から送られてくるのを楽しみにしています。