継続した学習（2）

継続した学習を行うために、あらかじめ平日に1時間とか学習する時間を決めて、地道に学習を続けて行く必要があると思います。平日は全く学習しないで、週末に行うというのは、長続きしないのではないかと思います。

年間を通してみれば、全く学習をしない週があったりするかと思います。しかし、学習は、短距離走ではなくマラソンであり、地道に継続していく必要があります。週1回で1時間程度の技術書の勉強会であっても、続けていくことで、最後には読み終えます。それは、週1回といっても、継続して開催し続けるからです。

個人の学習という点では、基本は平日に毎日続ける方が、1日、2日、何らかの理由（飲み会とか）でできない日があっても、次の日にはまた行うことになります。しかし、週末だけというのは、長続きしないかと思います。その理由としては、私なら次のようなことが挙げられます。

• 長時間集中が続かない
• 週末なので予定や用事が多い

それよりも、平日に1時間とか決めてコンスタントに続けている方が、長期的に見れば、継続した学習の習慣化にもなりますし、多くのことを学ぶことになるかと思います。みなさんは、いかがでしょうか？

訳者まえがき 『APIデザインの極意』

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

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

訳者まえがき

私自身がJava 言語を学び始めたのは、1996 年の夏でした。その後、Java 関連の技術雑誌の記事を執筆したり、2001 年に『プログラミング言語Java 第3 版』を翻訳したりしました。しかし、それまでは、API 設計に関しては、初心者の域を出た程度でした。API 設計に対する私自身のレベルを大きく押し上げてくれたのが、2001 年に翻訳したJoshua Bloch 氏の『Effective Java プログラミング言語ガイド』でした。そして、Jaroslav Tulach 氏のこの『API デザインの極意』（Practical API Design）は、さらにAPI 設計に対する私のレベルを大きく押し上げてくれました。Tulach 氏の言葉を借りれば、私の水平線を大きく押し広げてくれました。

API 設計は、大学で体系的に教えられることはないですし、企業でも教えられることはないと思います。その結果、日本企業においては、いわゆるSDK と呼ばれるソフトウェアを外部へ提供していても、必ずしも優れたAPI になっていないことがあります。私自身も、数多くの悪い設計のAPI を見てきました。しかし、なぜ、そのようなソフトウェアが量産されるのでしょうか。それは、何が良いAPI で何が悪いAPI であるかを分からないレベルのソフトウェアエンジニアが開発しているからかもしれません。あるいは、きちんとしたレビューを受けていないのかもしれません。あるいは、レビューできちんと指摘できるレベルのソフトウェアエンジニアがいないのかもしれません。

きちんとしたAPI 設計を学ぶには、ある程度独学で書籍を通して学習して、実践して習得していくしかありません。その意味では、Joshua Bloch 氏の『Effective Java』は必読書と言えますし、デザインパターンなども学ぶ必要があります。しかし、残念ながら、API を発展させていく観点でAPI 設計について書かれている書籍は、まれです。

この本には、オープンソースプロジェクトであるNetBeans のアーキテクトとしてTulach 氏が経験してきたことがまとめられています。Tulach 氏が行った様々な誤りが説明されており、それらの経験からAPI の発展を考慮した設計とはどのような設計かが説明されています。また、どのようにして、NetBeans の非推奨のAPI を終焉させてきたかも述べられています。そして、最後に、この本に述べられている方法論をアジャイルAPI 設計（Agile API Design）と呼ぶことにすると述べられています。

この本は、プログラミングの初心者向けではありませんし、Java に関する知識が必要であり、『プログラミング言語Java 第4 版』の内容の知識が必要です。多くのJava プログラマが不慣れと思われる箇所に関しては、『プログラミング言語Java 第4 版』の該当箇所を訳注として示しています。

この日本語版が、API 設計に対する読者のみなさんの水平線を押し広げることの助けになれば幸いです。

『APIデザインの極意』の内容紹介記事

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

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

ThinkItで書籍の内容の一部がそのまま紹介されています。第1回は、「現代的なソフトウェア構築の技芸 -合理主義、経験主義、無知-」と題して紹介されています。

書籍『A Practical Approach to Large-Scale Agile Development』

A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development Series)

• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2012/11/15
• メディア: Kindle版

大規模な組み込みシステムに対するアジャイル開発の適用例を述べた本です。副題に、「How HP Transformed LaserJet FutureSmart Firmware」となっているようにHPでのプリンターやMFP（Multi-Function Products）（いわゆる、コピー、プリント、ファックなどが一台に搭載されたデジタル複合機）の開発において、いかにしてアジャイル開発を適用したかを述べた本です。どのくらい大規模かというと、コード量にして1,000万行以上、開発者数400名以上という大規模なものです。

アジャイル開発に移行する前のHPでは、どのような問題を抱えていたかというと、次のような問題を抱えていたと述べられています。

• 開発リソースの10%は、「Build Boss」と呼ばれるチームごとの専任のフルタイムのコードのインテグレーション担当者であった。それに加えて、全体をビルドするチームも存在していた。
• 全体をビルドするチームも1日に1回か2回しかビルドを行えなかった。
• 非常に時間を要するビルドプロセスだったので、開発者が1つの変更を入れても、システム全体で正しく動作するのを確認できるようになるまで1週間を要していた。
• 開発リソースの20%が、すぐに不要になったり、提供されない、将来の機能提供に関する詳細な計画に費やされていた
• 開発リソースの25%は、既存のコードと機能を新製品へ移植することに費やされていた。
• 開発リソースの15%は、手動によるテストに費やされていた。そのため、製品計画に製品を頻繁に追加できなかった。
• 開発リソースの25%は、顧客要求に対応するとか、製品間の一貫性を維持するための現行製品のサポートに費やされていた。

そして、残りの5%のリソースしか、新たな価値創造のための活動に費やせなかったという状況だったようです。

結果が、どうなったかは、次のスライドの11ページ目にまとめられています。
http://www.agileleadershipnetwork.org/wp-content/uploads/2012/12/Young-LargeScaleAgielDevelopment-2012-01-20.pdf

また、著者の一人によるプレゼンテーションの動画もあります。
"A Practical Approach to Large Scale Agile Development" - Gary Gruver at Spark 2013

実際の製品開発をどのように行っているかを企業が公表することはないため、多くの企業は、製品のベンチマークは行っても、開発プロセスのベンチマークを行うことはないです。結果として、開発プロセスが、井の中の蛙となってしまうことがあります。この本は、組み込みシステムであっても、自分達の開発プロセスをベンチマークする上で、優れた材料を提供していると思います。

2年前に記事「継続インテグレーションは強みではなくなった」を書いています。その記事を書いた頃には、HPは、はるかに先を行っていたということになります。

コードレビューの視点 013

IDEが生成したコメントをそのままにしない

EclipseやNetBeansを使用して、新規にクラスを生成しようとすると、以下のようなコメント行が挿入されたりします。

/*
 * To change this license header, choose License Headers in Project Properties.
 * To change this template file, choose Tools | Templates
 * and open the template in the editor.
 */

あるいは次のようなコメント行だったりします。

// TODO code application logic here

初心者なら、IDEが生成したこのようなコメントを放置するかもしれません。そして、コードレビューで指摘されて削除したり、修正したりすることになるわけです。

初心者でない場合には、より悪い状況です。まず、開発経験が何年あっても、細部に注意を払えないエンジニアだと私は判断します。そして、そのような人がレビューアーとしてレビューしたコードの品質はたかが知れているので、初心者をレビューする立場になっても、きちんと指導できないと判断します。さらに、そのようなコメントを削除したり修正しなさいという指示は、その開発者への信頼口座からの引き落としになります（「信頼残高へマイナスである指示」）。

第22期Java研修を開講

私にとって、通算第22期になるJava研修を今日から開講します。研修の定員は12名なのですが、今回は受講生は6名です。22回の中で最小人数での開講となります。過去、最も多い時には、20名で始めたこともありますが、最後は10人以下になることがほとんどです。

今回もテキストは、従来通りです。『プログラミング言語Java第4版』『Effective Java第2版』、それに、拙著『Java 2 Standard Edition Tiger』です。内容としては、Java 5.0ベースとなります。

Java 8の時代に、いまさら5.0と思われるかもしれませんが、Java言語そのものは今までの18年間で段階を経て発展しているため、その発展に関する知識がないと、Java 8そのものをきちんと理解できなかったり、実際の開発業務では、古いバージョンによる開発を強いられたりもします。

6名で開始して、何名が修了するかは分かりませんが、第22期が終わる時には、リコーグループで延べ100名の修了生を送り出したことになるはずです。そして、第23期は、Java 8ベースの教育に衣替えすることになるでしょう。

技術書のレビュー

来年1月に発売予定の書籍『Core Java for the Impatient』の原稿のレビューを、現在行っています。英語の原稿が章ごとにPDFで送られてきて、それを読んで気付いた点などをコメントして返す作業です。

今月下旬に発売される『Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング』の著者であるCay S. Horstmann氏の次の本です。本人とは会ったことはないですが、翻訳を通して知り合ったことになります。

今までに、技術書の翻訳を通して、著者と多くのメールのやり取りをして知り合い、次の本の執筆時にレビューアとして英語原稿をレビューさせてもらった本は、以下の通りです。

• プログラミング言語 Java 第4版
• Java Puzzlers 罠、落とし穴、コーナーケース
• Effective Java 第2版

Horstmann氏は長年『Core Java』を第9版まで執筆されているので、歴史的な理由（小話）が書かれているのは、読んでいて楽しいです（今月発売になる『Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング』にもいくつか書かれています）。

ソフトウェア開発組織が持つべきカルチャー 015

1つの言語をきちんと学ばせる

長年行っているJava研修は、「Java研修の目的」でも書いたように、その目的の1つは、言語をきちんと学ぶことです。その言語として、Javaを選択していることになります。しかし、新卒新人で入社して従事するプログラミング言語には様々なものがあります。

多くの開発組織では、言語教育が表面的なものだったり、きちんと学習させることがなかったりします。言い換えると、開発者個人に任せていることが多いのではないでしょうか。実際、私自身も振り返ってみると、社会人となってからの言語学習は、すべてが独学です。そのため、その独学で身に付いてしまった変な癖を直すには、長い時間を要しています。

1つの言語をきちんと組織として学ばせることは（特に若い段階で）、非常に重要です。特に、開発に使用しているプログラミング言語をきちんと学ばせることは重要です。ある時期、Rubyで開発（実際にはJRubyを使用）することにしたある開発では、私も含めて、担当する開発達と一緒に、きちんとした言語の本を全員で読むということを行ったこともあります。また、C++で開発していた60名規模のある開発組織では、新卒新人には『C++ プライマー第4版』を先輩が指導する形式で本1冊を学習させていました（私は全くその教育には関与していませんでしたが）。

1つの言語をきちんと学ばせた後は、さらに新たな言語の学習は、本人の責任でよいと思います。

継続した学習

ソフトウェアエンジニアとして継続して学習をする習慣を身につけることは重要です。そのことは、多くの書籍で述べられていますし、私のブログでも何度も述べています。中途採用の面接でも、「継続した学習の習慣」を確認しています。

どうやって確認しているかと言うと、非常に簡単です。面接前の控え室で、一枚のアンケートに答えてもらいます。そのアンケート（A4の表裏）には、書籍の一覧が掲載されています。

• プログラミング（ソフトウェア開発）一般に関する書籍の一覧
• 言語別に、いわゆるバイブル本を含む書籍の一覧
• 現在読んでいる書籍の自由記入欄

基本的に、読んだ書籍にチェックを付けてもらう簡単なものです。そして、30代や40代の応募者のほとんどが、書籍のチェック欄に何も付いていないことが多いです。

最近は、面接官が私である旨を応募者に伝えてもよいと、リクルーティング会社へ事前説明しています。その結果、面接の直前に私の『プログラマー”まだまだ”現役続行 』を読んでくる人がいたりします。しかし、それだけだったりします。

ほとんど書籍を読んでいない人は、今まで使用してきたいというプログラミング言語に関するちょっとしたことを質問しても答えられない人が多いです。ある意味、「サラリーマンエンジニア」だったりするわけです。そして、多くの場合、人事の担当者に準備してもらったホワイトボードが無駄になります。簡単なプログラミングの課題や技術的説明をしてもらうために用意してもらっているのですが、使う機会はあまりありません。

Java研修の目的

2000年にJava研修を始めた時の目的は、社内の技術者が社内の技術者を教えるというコースを立ち上げるということでした。そのための、最初として、私が始めたわけです。

現在も続いているJava研修ですが、現在の目的は異なっています。現在の目的は、以下のことを学ぶことです。

• Java言語をきちんと学び、将来、他の言語を学ぶ上での基礎を身につける（『プログラミング言語Java第4版』）。
• API設計の基礎を学ぶ（『Effective Java 第2版』）。

これらを若い段階で時間を費やして学ぶことで、その後に、他の言語を学び・プログラミングする場合のベースを作るということです。

たとえば、最近の言語は、リフレクションの機構を持っているものが多いですが、Java言語のリフレクション機構をきちんと理解していれば、他の言語でも、何ができて、何ができないかを理解することが容易になります。また、他の言語で開発するとしても、Java言語でできる設計手法をなんとか取り込めないかと考えるきっかけにもなります（Programming into a language）。

Java研修の大きな欠点は、受講の強制力がないことです。ある意味長所でもあるのですが。研修のための予習は、平均すると月に50時間は軽く超えます。そして、その予習はプライベートで行わなければなりません。したがって、受講を希望する人だけを対象としており、会社として強制的に参加させることはないです（ただし、途中で脱落する人もいますが、私の部下になった新卒新人は、必ず参加してもらいます）。

予習は、プライベートな時間に行うので、受講生は様々な工夫をしながら予習しているようです。最近なら、スターバックスなどの外で予習する人が多いようです。人によっては、自宅がよいという人もいます。そして、一年間は、継続して学習するという習慣を維持し、一人では最後まで読み切ることはできない3冊のテキスト（合計で約1,000頁）を読み終わることになります。練習問題やGUI課題のプログラミングも合計するとおそらく10,000行以上書いていると思います。

最終回の成果発表会では、「デジタル時計が出ていて、Javaで書かれていること」という条件で、集大成となるGUI課題を作成してきてもらいます。みなさん、力作を作ってきます。研修の第2回目で簡単なデジタル時計を作成するのですが、なぜ、そんな簡単な課題に苦労したのかと思えるほと、素晴らしいアプリケーションを最後に見せてくれます。

今週の金曜日から第22期が始まります。第22期からは、年に1コースに限定するための期となります。まだ、終わっていない第20期と第21期が終われば、第22期だけとなり、月に1コースだけとなります。一方で、今月末から『Java8基本技術習得』コースを開講し、最新のJava8について学ぶコースとなります。ただし、受講対象は、今までのJava研修を修了した人達だけです。