55歳

早いもので、すでに55歳になってしまいました。大学一年生の18歳の時に、大学のコンピュータセンターでコンピュータに触れてから、37年が過ぎたことになります。当時は、大学に行かなければ、コンピュータが使用できない時代でした。

今日では、電車の中やスターバックスで、MacBook Airを使用しながら、翻訳作業をしたり、メールを読んだり、プログラミングをしたりと様々なことができます。昔、「Star Trek: The Next Generation」を米国で見ていた1990年頃は、登場するタブレットは、どうやってメインのコンピュータと通信しているのだろうかとか、操作パネルがすべてタッチ式というのは本当に来るのだろうかと思っていましたが、今では、普通に自宅でiPadを使用しているわけです。

1988年から1993年までの米国暮らしでは、日本の両親とは国際電話で話し、2002年から2003までの（短かった）米国暮らしでは、父親とは電子メールでやり取りしていました。そして、ここ2年ぐらいは、iPadのFaceTimeを使用して顔を見ながら両親と話すことが多いです。

昔、Star Trekで見た世界は、一部を除いて、今では実現されているものが少なからずあります。しかし、大学に入った頃と今も変わらないのは、プログラミングは、頭の中で考えたことを、人が手を動かしながら行うということです。パンチカード、ラインエディタ、スクリーンエディタという時代から、マルチウィンドにEclipseやNetBeansなどのIDEへと、プログラミングの道具は、目覚ましく発展しました。しかし、創造的部分は、やはり、人の頭の中で行われるわけです。

その創造的な活動を、何歳になっても続けていきたいと思っています。

継続した学習（4）

「継続した学習」では、中途採用の面接で私が行っている「継続した学習の習慣の確認」の方法としての、書籍一覧での確認の話を書いています。

継続して学習するという習慣は、非常に重要なのですが、新卒新人で入社した場合には、配属された職場の先輩達の習慣に大きな影響を受けることがあります。先輩が、業務としてのソフトウェア開発を遂行する上での最低限の学習しかせずに、既存のコードの書き方をまねるだけで、細かな点に注意を払わないようであれば、新人で入ってきても、同じような習慣になってしまう可能性が高いです。

その結果が、中途採用を募集しても、ほとんど書籍を読まない人達ばかりが応募してくるという状況かもしれません。あるいは、複写機メーカーということで、そのようなソフトウェア開発者達が応募してくるのかもしれません。組み込みシステムを開発している人達は、必要なプログラミング言語を学んだ後は、新たなことを学ばない傾向が強いと私は感じています（2000年の頃に、実際にアンケートで調査したことがありますが、C言語しか知らない人は、本を読まない人が多い傾向にあるという結果でした）。

同じ会社であっても、所属する組織によっては大きな差があるかと思います。中途採用と同じアンケートを実施したとしたら、おそらく、組織ごとに大きなバラツキがでるのではないかと思います。あるいは、個人ごとに異なる結果になるかもしれません。たとえば、私から影響を受けた人達、特に、1年間の厳しいJava研修を修了した人達とそうでない人達には、学習習慣に大きな差が出ているかもしれません（Java研修では、1年間で合計で約1,000ページの技術書を読まないといけないので、継続して予習を行わないと修了できません）。

テスト駆動開発プロジェクトの経験（5）

（前回からのつづき）

ソフトウェア開発におけるテストの自動化やテスト駆動開発などは、それほど古い訳ではなく、2000年以降に徐々に採用されてきています。そして、今も、自動テストを整備することなく、テストを手作業で行っているソフトウェア開発も多いと思います。

その意味で、社会人となって従事するソフトウェアプロジェクトが、テスト駆動開発になっているのか、手作業でテストを行う開発なのかは、ソフトウェアエンジニアのスキルとして大きなギャップを生み出すかもしれません。

テストファーストでの開発では、最初にAPIを考えることが求められます。たとえば、小さな機能であっても、その機能を提供するAPIをどうするかを最初に考えます。そして、それから、テストコードを作成し、テストが失敗することを確認します。そして、実装を始めるわけです。

特に、これにきちんとした防御的プログラミングとしてのパラメータ値の検査を行うことをAPIに明確に記述することで、そのためのテストも作成します。また、すべての機能をテストするためには、どのようなテストを作成すればよいかを悩みながら考えるわけです。

一方、手作業でテストする開発では、意外とありがちなのは、APIを考えるのですが、正常のパラメータしか渡ってことないという前提で実装を始めて、正常ケースだけを実装してしまうことです。そして、実装が終わったと思った後に、部分的なテストだけを書いて、実装が終了したと判断するわけです。

テストファーストによる開発は、本を読んだら身に付けられるかというと、そうではありません。テストファーストによるテスト駆動開発では、ソフトウェアエンジニアに対して多くのことをきちんと行うことが求められます。APIを考えて、テストを苦労して作成して、それから実装するということを意識して繰り返すことで、無意識に行えるようになるまで開発経験を積んで行く必要があります。そのような状態になって初めて、未経験者に対して指導ができるようになるわけです。

技術的な知識を学ぶのは、書籍を読んだり、ウェッブで調べたりすればできるのですが、ソフトウェア開発では、普段の行動パターンとして、求められることも多くあります（「ソフトウェア開発組織が持つべきカルチャー」）。そのような行動は、実際に自分で経験していく必要があります。

その意味で、最初からきちんとしたテスト駆動開発のプロジェクトとに従事すると、新人であっても様々なことをきちんと行うことが求められ、本人が意識しなくても、強制的に身に付くわけです。しかし、そのような開発でない場合は、数年、あるいは、10年以上もソフトウェア開発を経験して、中堅となっても、テスト駆動開発を推進できないし、しないソフトウェアエンジニアになってしまう可能性は高いです。

Jenkinsを導入していても、ビルドを自動化しているだけ、何もテスト書いていなければ、テスト駆動開発ではないわけです。その意味で、テスト駆動開発の経験を問われた時に、Jenkinsを導入したことがあるという回答では不十分であり、期待する答えではないわけです。

Go Conference 2014 autumn

「Go Conference 2014 autumn」が11月30日に開催されます。

http://gocon.connpass.com/event/9748/

今回は、Go言語の生みの親であるRob Pike氏が来日して話をされるようです。私は、一般参加申し込みを受け付け開始と同時に申し込んだので、13番目に受け付けられました。一般参加枠の200名は、20分弱で埋まってしまったようです。

Go言語の勉強会を開始したのが、1.0が正式リリースされるかなり前の2010年の夏でした。もう、あれから4年が過ぎましたが、Go言語も徐々に広まってきているようです。

Rob Pike氏と言えば、次の書籍を読まれた人も多いのではないでしょうか。

プログラミング作法

• 作者: ブライアン カーニハン、ロブ パイク
• 出版社/メーカー: アスキー
• 発売日: 2000/11
• メディア: 単行本

Go言語の本は執筆されていないので、サインをもらうならこの本でしょうか。

アプレンティスであることはどういうことか

アプレンティスシップ・パターン　―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

• 作者: Dave H. Hoover
• 出版社/メーカー: オライリージャパン
• 発売日: 2010/07/08
• メディア: 単行本（ソフトカバー）

この本からの抜粋です。

アプレンティスであることはどういうことか

　アプレンティスであることは何を意味するのかを議論した際に、私達がインタビューした1 人であるMarten Gustafson は、「今まで行ったことや今行っていることをより良く、さらに賢く、もっと速く行う方法が常にあるという態度を基本的に持つことだと思います。徒弟制度は、より良い方法へと発展し、より良い方法を探し、より良く・さらに賢く・もっと速く行う方法を学ぶことを強制する人々、会社、 状況を探す、状態・プロセスです」と上手く表現しました。あなたに解決方法を与えてくれる人々に依存せずに、問題に対処する建設的な方法へと導いてくれる内面的な動機に多くの価値があると私達は考えます。Dweck は次のように書いています。「それは、安易な成功で得られる内面的な量ではありません。高い知性について人々に話すことで、人々に与えられるものではありません。見かけ上の賢さではなく、挑戦することを楽しみ、間違うことを熟練職人への道のりとして活用することに価値を置くことを教えることで、自分自身のために身に付けるものです」（Self theories、p.4）。
　理想的な状況は、同僚のアプレンティス、ジャーニーマン、それに1 人の熟練職人から構成される小さなチームの中にあなたがいることです。しかし、私達が考える徒弟制度は、このような組み合わせを必要としません。あなたの徒弟制度は、あなたの管理のもとにあり、徒弟制度の結果は、究極はあなたの責任です。徒弟制度の進む方向と進歩は、あなたが決めるのですが、あなたに良き指導者がいることと指導者達の質も、あなたの職人気質に対して長く影響を与えます。
　見習い期間は、ソフトウェア職人としての旅の始まりです。その時期に、職人気質を伸ばすことに関して、主に自分の内面と意志にあなたは注力することになります。同僚や経験のある開発者から面倒をみてもらうことで恩恵を得ますが、自分自身を成長させることを学び、学ぶ方法を学ばなければなりません。自分自身へ焦点を当てることと成長の必要性は、アプレンティスであることの基本です。
　アプレンティスは、最後には、継続した学習が主で責任が少ない立場から、より広く外部への責任を持つ立場へと卒業します。そして、この卒業は、後で回想する時にだけ分かるものであると私達は信じがちです。ある時点で、アプレンティスのところに熟練職人かジャーニーマンが来て、コミュニティにおけるあなたの仕事や役割は、ジャーニーマンの仕事や役割ですと伝えられます。このような場合、アプレンティスはそれ以前より多くの責任を負うようになっています。「煮えカエル」のように、徐々に明確な区切りがなく、1 つの段階から上の段階へと移っていきます。この移行は人によっては、他人よりも長く要するかもしれません。人によっては、この移行は、専門的なキャリア以上に時間を要するかもしれません。

『アプレンティスシップ・パターン』（p.9）

ソフトウェアエンジニアと英語力（5）

英語の書籍を用いた勉強会では、基本的な中学校で学ぶ英文法から完全に忘れている人がいたりします。たとえば、「使役動詞」です。英語の技術書では、「使役動詞」が多く使われます。代表的なのは、makeです。

使役動詞としてのletを間違えることはあまりないですが、makeを間違える人は多いです。つまり、makeを「作る」ということしか覚えていないと、読み取れない英語は多いです。

使役動詞としてのmakeは、「make + 目的語 + 動詞の原形」という形式になり、「・・・を[に]〜させる」という意味になります。『くもんの中学英文法―中学1〜3年 基礎から受験まで (スーパーステップ)』には、次のような用例が掲載されています。

I made him go.（私は彼を行かせた）
She made me eat carrots.（彼女は私にニンジンを食べさせた）

もう一つ技術書で多く使用される使役動詞は、haveです。「have + 目的語 + 動詞の原形」となり、『くもんの中学英文法』には、次のような用例が掲載されています。

I made him go alone.（私は、彼を一人で行かせた）
I had him go alone.（私は、彼を一人で行かせた）

英語で読み慣れていないエンジニアにとって難しいのは、makeと目的語まで読んでも、その次に動詞の原形があれば使役として使用されていることを理解する必要があることです。「動詞の原形」ではなく、「補語」としての「名詞」や「形容詞」が続くと使役動詞ではなくなってしまいます。さらに、「make + 間接目的語 + 直接目的語」という用法もあるので、頭から読んで、どの用法かを判断する必要があります。

成立しないキャリア

先日、Twitterでつぶやいたことですが。

ソフトウェア開発は、事務作業ではなく、創造活動です。基礎知識を学んで情報処理などの試験に合格して、数年間の実務経験を積めば、それで定年まで過ごせるというキャリアは成り立ちません。

ソフトウェア開発は、自分で考えて手を動かしてプログラミングして動くものを作ることを繰り返す訳であり、「物作り」という創造活動です。

一方で、物作りの能力を問うのではなく、様々な知識を問うための試験があります。情報処理技術者試験に始まり、様々なベンダー試験や、技術領域ごとの試験があったりします。しかし、このような試験に合格したらソフトウェア開発の実務ができる訳ではありません。あくまでも、最低限の知識を勉強したことを証明しているにしか過ぎません。弁理士試験のように、その試験に合格していなければ、実務ができないものとは、全く異なる性質の試験なのです。

言い換えると、試験に合格して、それからソフトウェア開発を仕事で行うことで実務経験を何年か積めば、その後のキャリアが安泰になるということは、ソフトウェア開発では絶対にあり得ません。

技術書のレビュー（2）

Core Java for the Impatient

• 作者: Cay S. Horstmann
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2015/02/23
• メディア: ペーパーバック

「技術書のレビュー」で、上記書籍の英語原稿のレビューをしていることを書きましたが、やっと終わりました。技術書のレビューの場合、Chapterごとに原稿が送られてきて、レビューすることが多いです。本によっては、著者から直接PDFが送られてくることもありますが、今回は、米国Pearson社の担当エディターから送られてきました。レビューでは、気付いた点をPDFの注釈として記入し、著者と担当エディターへ送り返すという手順となります。

この本の目次は、以下の通りです。

Chapter 1 Fundamental Programming Structures
Chapter 2 Object-Oriented Programming
Chapter 3 Interfaces and Lambda Expressions
Chapter 4 Inheritance and Reflection
Chapter 5 Exceptions, Assertions, and Logging
Chapter 6 Generic Programming
Chapter 7 Collections
Chapter 8 Streams
Chapter 9 Processing Input and Output
Chapter 10 Concurrent Programming
Chapter 11 Annotations
Chapter 12 The Date and Time API
Chapter 13 Internationalization
Chapter 14 Compiling and Scripting

Chapter 1からChapter 12までで437頁ありますので、索引等が追加されれば、470頁程度になるのではないでしょうか。

この本には、私が翻訳した下記の本と同様に、各Chapterの最後にたくさんの練習問題があります。

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

• 作者: Cay S. Horstmann
• 出版社/メーカー: インプレス
• 発売日: 2014/09/22
• メディア: 単行本（ソフトカバー）

今まで、私が原著段階で英語の原著をレビューした書籍は、すべて翻訳していますが、今回は翻訳の予定はありません。

今までに、私が英語の原稿段階でレビューをした本は、以下の4冊です。

EFFECTIVE JAVA 第2版 (The Java Series)

• 作者: Joshua Bloch
• 出版社/メーカー: 丸善出版
• 発売日: 2014/03/11
• メディア: 単行本（ソフトカバー）

プログラミング言語 Java 第4版

• 作者: ケン アーノルド
• 出版社/メーカー: 東京電機大学出版局
• 発売日: 2014/05/10
• メディア: 単行本

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

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

プログラミング言語Goフレーズブック

• 作者: David Chisnall
• 出版社/メーカー: ピアソン桐原
• 発売日: 2012/10/04
• メディア: 単行本（ソフトカバー）