カンファレンスは、若い人ばかり？（2）

2つのカンファレンスに参加しました。1つは、情報サービス産業協会（JISA）主催の 「SPES 2012 －サービス化により変わるシステム開発－」。もう1つは、日本Jenkinsユーザ会主催の「Jenkins ユーザ・カンファレンス 2012 東京」です。

SPES2012は、ソフトウェア開発がクラウドベースのサービス化によりシステム開発がどのように変わっていくかというテーマでのカンファレンスです。Jenkinsユーザ・カンファレンスは、その名の通りJenkinsに関するカンファレンスです。

カンファレンスの内容は、全く性質が異なります。そのためでしょうか、参加者の年齢層が明らかに異なっていました。SPES2012では、暑い日にもかかわらず、背広の上着を着用しているような人が意外と多く、40代、50代の人が多いカンファレンスでした。

一方、Jenkinsユーザ・カンファレンスは、20代、30代がほとんどで、私のような50代はほとんど見かけませんでした。ソフトウェア開発現場での改善という観点では、Jenkinsユーザ・カンファレンスの方が技術よりであり、実際に分かり易い内容でした。

私が20代、30代の頃は、勉強会やカンファレンスも少なく、インターネットも今日のようには普及していませんでした。その結果、若い人達が積極的に勉強会やカンファレンスへ参加する機会も少なかった訳です。そうして、40代、50代になった人達はSPES2012のようなカンファレンスには参加しても、技術寄りのカンファレンスには参加しないのかもしれません。

Jenkinsユーザ・カンファレンスに参加したような若い人達の多くが、20年後に若手に混じって技術寄りのカンファレンスに参加しているようになっていれば、日本のソフトウェア業界も大きく変わっているかもしれません。

私自身が日頃から感じていて、Jenkinsユーザ・カンファレンスの参加者による質問を聞いて再認識したことは、JenkinsなどのCIツールの導入を阻害しているは、現場のエンジニアではなく、ソフトウェア開発組織の管理職でないかということです。つまり、管理職がCIツールの導入の検討を指示して、予算（工数、機材費）を認めてくれればスムーズに導入できるかと思います。しかし、現実は、CIツールに関する知識や使用した開発経験もないため、管理職が指示することはなかったりします。そして、開発現場が上司に提案をして説得しなければならないことが多いということです。

現状は、このような開発組織が多いでしょうが、Jenkinsユーザ・カンファレンスに参加したような若い人達が10年後、20年後には積極的に改善を指示してくれるのではないかと期待しています。

（「カンファレンスは、若い人ばかり？」、「書籍『Jenkins実践入門』」）

Java研修 (2)

きっかけ

1998年5月に富士ゼロックス情報システム社へ転職した頃は、特に技術教育をするということは私自身はあまり考えていませんでした。一方で、社内のエンジニア向けの技術教育は、そのほとんどが有料の外部の教育コースを用意していますということになっていました。

社員が社員に対して技術教育をするような制度を整えるべきだと技術教育を担当していたグループに提案して、まず最初に私が行いますということで始めたのがJava研修です。

社内で募集を行い、研修場所としては親会社である富士ゼロックス社の新百合ヶ丘にある研修施設を借りて始めることになりました。その後、第10期まで続いた研修は、その同じ施設を借りて行いました。

第1期生に、テキストとして会社で購入して配布したのが英語版の『The Java Programming Language, Third Edition』でした。もちろん、英語で読んで予習できるはずありませんので、実際には私が翻訳を行っていた翻訳原稿を使用して教育を始めました。

作業はコンピュータに、人間は創造的活動を （2）

「ソフトウェアエンジニアの心得」の中で次のような言葉を引用しています。

どの言語でプログラムしようとも、プログラマとしてのあなたの仕事は、使えるツールを使ってベストを尽くすことです。優秀なプログラマであれば、低レベルの言語、あるいは扱いにくいシステムであっても克服しますが、優れたプログラミング環境は、できの悪いプログラマを救済してはくれません。

― Brian Kernighan, Rob Pike, 『プログラミング作法』

Java言語の普及が始まった1996年と比べると、今日の開発環境はEclipseやNetBeansの普及により格段に良くなっています。

このような開発環境が登場するまでは、リファクタリングは非常に面倒な「作業」でした。たとえば、メソッド名を1つ変更するにしても、複数のソースファイルからのそのメソッドの呼び出し箇所をすべて手作業で修正します。そして、コンパイルして修正漏れがないかを確認したものです。

実は、このメソッド名を変更するという行為は「作業」に過ぎません。したがって、今日ではIDEを利用することでコンピュータが行ってくれる作業であり、人が行う必要がなくなっています。残念ながら、それだけでできが悪いプログラマが少なくなることはないのです。なぜなら、人が行う「創造的な活動」部分がそれでも残っており、それによって差が生まれるからです。

その創造的な部分とは、この場合は「適切なメソッド名を考える」ということです。さすがに、この部分は、IDEは考えてくれません。したがって、人が考えなければなりません。

作業はコンピュータに、人間は創造的活動を （1）

「書籍『Jenkins実践入門』」の記事の最後に、「作業はコンピュータに、人間は創造的活動を」という表現を使っています。

ソフトウェア開発者の中には、「手でコピペした方がプログラムを書くよりも早い」と言って、元データが数多くのExcelファイルに書かれている場合に、使用しているプログラミング言語用ファイルへの変換を手作業で行ったりする人がいます。そのあげくに、「転記ミス」が原因の障害を発生させてしまったりします。このような状況では、実際には手作業が早いのではなく、そのような処理を行うプログラムを書いた経験がないので、本人にとっては手作業の方が早いと思えるのが本当の理由だったりするのです。

もし、本当に手作業が効率的な手段だったとしたら、単価が高いソフトウェア開発者が行う仕事ではありません。さらに、数ヶ月後あるいは数年後に似た作業が必要になった場合に、さらに単価が高くなっているかもしれないその開発者は手作業で行うという発想しか持たず、再び時間をかけて手作業で行うことになるかもしれません。つまり、ソフトウェアエンジニアとしても、その開発者は何も成長していないことになります。

会社での開発業務を通してのプログラミング練習しかしていないようなソフトウェア開発者であれば、練習を兼ねて自動で変換するプログラムを作ってみようと思ってもらうぐらいでも良いのではないかと思います。でも、そう考える人は、最初から手作業で行うことは考えないのかもしれません。

このようないつも手作業しかしないようなソフトウェア開発者が増えてしまうと、自動化するという発想がなくなり、テストも含めてやたら手作業ばかり行うソフトウェア開発組織が出来上がってもおかしくないかもしれません。

Java研修 （1）

2000年から行っているJava研修ですが、その概要、生い立ち、教育内容の変遷などを何回かに分けて書いていきます。

目的

• 一人では読みこなせない書籍の学習を通して、最初の言語（Your First Language）として、Java言語を体系的に修得
• 自分の時間を投資する学習
• 自分の時間で「練習、練習、練習」（練習問題やGUI課題をこなす）

予習

• 予習範囲を事前に学習し、不明点を質問表としてまとめる
• 予習範囲の練習問題およびGUI課題のプログラミングを事前に行う

教育当日

• 質問表に沿った解説、および、練習問題・GUI課題の確認を行う
• 月に1回（1日）開催し、年12回で終了する

定員

• 12名

テキストは、現在は以下の3冊です。

プログラミング言語Jav a第4版

• 作者: ケン・アーノルド
• 出版社/メーカー: ピアソンエデュケーション
• 発売日: 2007/04
• メディア: 単行本

Effective Java 第2版 (The Java Series)

• 作者: Joshua Bloch
• 出版社/メーカー: ピアソンエデュケーション
• 発売日: 2008/11/27
• メディア: 単行本（ソフトカバー）

Java 2 Standard Edition 5.0 Tiger―拡張された言語仕様について

• 作者: 柴田 芳樹
• 出版社/メーカー: ピアソンエデュケーション
• 発売日: 2005/04
• メディア: 単行本

これらの書籍は全部合わせると1,000頁以上になります。したがって、一人ではなかなか読みこなせないですが、教育を受けることで一年間で読み通してもらいます。それも、業務時間ではなく、自分のプライベートな時間を使って読んでもらいます。

実際のプログラミング課題としては『プログラミング言語Java第4版』の練習問題すべてとGUI課題である「デジタル時計」を作成してもらうことで、プライベートな時間に「練習、練習、練習」を行ってもらいます。『プログラミング言語Java第4版』の一部の問題（interpret）は、GUIで作成してもらいます。

ソフトウェア開発では、会社での開発現場でプログラミングの練習をしている人が圧倒的に多いです。それも製品のソフトウェア開発でです。しかし、そのような業務としての開発だけの練習では、業務で使ったことがない機能は、それが簡単なことであっても難しく感じたりします。この研修では、リフレクションも含めて一通り学習と練習を行ってもらいます。人は、一度使ったことがある技術は、簡単に思えるものです。そのために、「練習、練習、練習」を行ってもらいます。

コードレビューの視点 011

英語の綴りには注意する

普段、英語を読むことがほとんどない人が書くプログラムでは、やたらと英単語の綴りの間違いが多いことがあります。

分かりやすい例で言えば、Java研修でGUI課題として「デジタル時計」を作成してもらうのですが、「DegitalClock」というクラス名で作成する人が必ず2、3割はいます。業務で開発してもらっているソースコードのレビューでも英単語の綴り間違いを指摘することが多いです。まだ、それでも綴りが間違っているだけなら良いのですが、それ以前に、意図を表す適切な名前になっていないこともあります。

コメントを除いて、日本語やローマ字でプログラミングすることはまれだと思います。英単語の綴りに自信がない時は、辞書で確認するように心がけてください。

11冊目の翻訳本 （4）

The Go Programming Language Phrasebook (Developer's Library)

• 作者: David Chisnall
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2012/05/09
• メディア: ペーパーバック

出版されることになり、この本の翻訳本が私にとっての11冊目の翻訳本として繰り上がることになりました。

コードレビューの視点 010

コメントアウトされたコードは削除する

大学時代や就職した頃はソースコード管理を使用することなくソフトウェアの開発を行っていたので、不要になったコードも後で必要になるかとか、あるいは、参考になるかということで、コメントアウトしていることが多かったような気がします。

今日、普通のソフトウェア開発であればSubversionやGitなどのソースコード管理システムを使用している訳でからコメントアウトしたコードを残している理由はほとんどありません。古いバージョンを取り出してくれば削除された部分を見ることはできます。

逆に、コメントアウトして残す場合には、残している意図もコメントとして残す必要があります。しかし、何らかの意図があって残されていることはほとんどなく、コードレビューでは削除を指示することが多いです。

マルチスレッドプログラムのデバッグ

「コードレビューの視点 003」では、「マルチスレッドプログラミングに注意する」と題して、次のことが必要だと述べました。

• マルチスレッドプログラミングに関する基礎知識をすべてのソフトウェアエンジニアがきちんと習得していること
• 書かれたコードは、マルチスレッドプログラミングに関する豊富な知識と経験を持つ人がきちんとレビューをする
• 書かれたコードは、自動テストが実行できるようになっていて、様々なプラットフォーム（単一コアから複数コア、あるいは、マルチプロセッサー）で長時間ランニングテストを行う。さらに、同時にシステムに別の負荷（CPU、HDなどへの負荷）をかけたランニングテストも行う

そして、テストが止まっている場合には最優先デバッグすることも重要だと述べました。しかし、重要ことを書き忘れていました。デバッグは、テストが止まったままの状態でデバッガーをプロセスにアッタッチして行うということです。デバッグ文を入れてもう一度再現テストをして再現したらデバッグ文から推測するということではありません。

実際に止まっている状態で、すべてのスレッドがどこで待ちになっているのか、一体何が起きたのかを徹底して調査する必要があります。そうすると、コードレビューでは想定していなかったようなスレッドの動きが起きている場合あります。その時になって初めて、その動きが発生する可能性のある1つであることを認識できたりします。

手作業で製品テストを行うような開発では、どうしても、テスト部門（QA）はテスト項目の消化をスケジュール通りに行いためにシステムがハングすると、バグレポートを出して、リブートし残りのテストを行う傾向があったりします。

私自身が1993年から1996年に開発に従事したFuji Xerox DocuStation IM 200は、白黒ですがコピー/Fax機能に加えてペーパーユーザーインタフェースという機能を搭載したデジタル複合機でした。Solaris上にC++でマルチスレッドプログラミングしていました。テスト部門でのテストでハングした場合には、開発に連絡があり、調査を担当する開発者は自分の席からテスト部門の機器に接続して、デバッガーを立ち上げて調査をします。

基本的にデバッグして原因を解明するまでは、何時間でもデバッグを続けます。その間、テスターから「リブートして良いですか」と問い合わせがあるのですが、基本は「まだ待ってください」と答えてデバッグしていました。

2003年から2009年まで従事したプロジェクトでは、もっと大規模なシステムでマルチスレッドプログラミングを行っていたのですが、この時も、止まった状態でデバッガーで調査するのが必須でした（このプロジェクトは、私が過去に経験した最大規模のテスト駆動開発を行っていました）。

マルチスレッド設計・プログラミングによるシステムは、作り方によっては、一人、いや、複数のエンジニアの想像を超えたことが起きる場合があり、常に再現するとは限りません。したがって、止まった時にきちんとデバッグすることが必須です。そして、そのようにデバッグできる環境も含めて、開発環境を整備することが求められます。