書籍『ソフトウェアテスト技法ドリル』

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

• 作者: 秋山 浩一
• 出版社/メーカー: 日科技連出版社
• 発売日: 2010/10
• メディア: 単行本

秋山さんから、昨日送られてきました。まえがきには、次のように冒頭で述べられています。

　本書は、配属されて間もない、テスト技術者の卵から、実際にテスト設計を何度かしたことがあり本も数冊読んで勉強した中級テスト技術者で「もっとテストが上手になりたい！」と思っている人を対象としています。
　また、TDD（Test-Driven Development：テスト駆動開発）を行い、テスト用のプログラムを先に書くという習慣がついているソフトウェア開発者の人で、さらに効果的なテストケースを書いて、TDDを開発のためだけでなくその後の保守フェーズにおいても活用していきたいと考えている人にとっても参考になるようにとの思いで執筆しました。

『ソフトウェアテスト技法ドリル』

内容としては、ソフトウェアエンジニアも知っておくと良いかと思います。特に、まえがきにも書かれていたように、テスト駆動開発では、テスト設計も重要な活動の一つです。この本は、会社内で勉強会形式でソフトウェアエンジニアが集まって議論しながら読んだり、例題に取り組んだりすると、効果的かと思います。

秋山さんは、多くの企業に対して、テスト設計のコンサルティングもされていますし、Hayst法の生みの親の一人です。http://hayst.com/には、Hayst法を含めて、様々なテストを中心とした書籍も紹介されていますので、参考にされると良いかと思います。

著者の秋山さんが参加される勉強会も開催されるようです http://atnd.org/events/8378 。

防御的プログラミング（２）

防御的プログラミングに関して、いくつか記事を書いています。

• 防御的プログラミング
• 防御的プログラミングとテスト駆動開発
• 防御的プログラミングしない後ろ向きの理由
• 防御的プログラミングしない後ろ向きの理由（２）
• 防御的プログラミングとカバレッジ

防御的にプログラミングするというのは、公開ＡＰＩの仕様にその内容を反映するということです。つまり、不正なパラメータが渡された時に、どのように振る舞うか（どのような例外をスローするかとか）を仕様書に記述する訳です。しかし、開発組織として防御的プログラミングの重要性を認識していない場合には、次のようなことが起きています。

• 開発者の多くが言葉としての「防御的プログラミング」を聞いたこともない。
• ＡＰＩの仕様書には正常な場合の処理内容しか書かれておらず、不正なパラメータが渡された場合の振る舞いが何も記述されていない。
• 結果として、APIの実装コードでは不正パラメータの検査されていない。あるいは、検査はしているが例外をスローすることなく、単純にリターンしている。※

「防御的プログラミング」は「銀の弾」ではありませんが、ソフトウェアエンジニアの道具箱に入っていていつも使用すべきものです。この道具を持たないでソフトウェア開発を行っている組織は、膨大な時間を障害調査に費やしている可能性が高いです。

※　検査はしているが単純にリターンしていると、その不正と思われる値が本当に不正なのか、正常値の範囲の一つなのかが不明瞭となります。

正誤表を更新

プログラミング言語Java (The Java Series)

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

正誤表を更新しました。まだ、私の手元には、第3刷が送られてきていないのですが、印刷中かと思います。

今回ホームページを最新のGWT（Google Web Toolkit）でコンパイルし直したものに入れ替えてあるのですが、気のせいでしょうか、ロードが速いような気がします。

MessagingTool

昨日の勉強会の後の懇親会でちょっとだけ話題になったので、リンクを探してみました（ホームページのサーバーにはずっと置いてあったのですが、外部からはリンクが貼ってなかったため参照できませんでした）。

Welcome to MessagingTool

MessagingToolとは、1987年頃から当時のXerox社のワークステーション上で動作するハックとして開発され、米国Xerox社では広く使われていましたし、ボーイング社などにも提供されていました。最初のバージョンはMesa言語で書かれておりXerox社独自の通信プロトコルを使用していました。1991年に私がSunOS上でも動作するようにC言語で書き直し、通信プロトコルもTCP/IPもサポートするようにし、Xeroxグループ内で配布していました。1996年にJavaを学習するために、Javaで書き直し、2004年ぐらいまではちょくちょく手直ししていましたが、この種のチャットツールが富士ゼロックス社内で2007年に全面使用禁止になった頃から自分でも使用しなくなってしまいました。

このMessagingToolは、私にとっては、「Breakable Toys」の一つでした。

上記リンクは、内容は古いままとなっています（時間にゆとりができたら全面的に書き直したいとは思っています）。

書籍『知識労働とソフトウェア開発』

知識労働とソフトウェア開発 (技評SE選書)

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

著者の荒井玲子さんから、直接自宅に送られてきました。この本は一人で読むよりは、会社の中で読書会をして、自分達の開発状況と照らし合わせならが読まれるとよいかと思います。内容の紹介は省略しますが、「あとがき」に次のように述べられています。

プロジェクトの成功要因の根底には、プロジェクトマネジメント技術やソフトウェア開発技法などの「技術」だけでは説明のつかない部分が、たしかに存在しています。やはりプロジェクトは「人」であり、ソフトウェア開発はピープルウェアなのです。「参加してよかった」というプロジェクトが増えるほど、人材はより多く、より効果的に育成されます。これまで参加したプロジェクトのうち、「参加してよかった」と思えるプロジェクトはいくつありますか？あるいは、プロジェクトメンバーが「参加してよかった」と思ってくれるプロジェクトをいくつつくりましたか？

『知識労働とソフトウェア開発』、325頁

自分自身を振り返ってみると色々なプロジェクトに従事してきました。大学時代から富士ゼロックス在籍までを振り返ってみると以下の通りです。

• 大学4年～修士2年： 研究室のプロジェクトでしたが、HOLENETと呼ばれるシステムの開発です。詳細は、書籍『マイクロコンピュータ ネットワークアーキテクチャの基礎』の第4章「事例紹介HOLEMENT」に書かれています。私自身は、5セットの通信ボード（Z-80, 2KB ROM, 64KB RAM, HDLC/SDLCコントローラ、DMAコントローラ、割り込みコントローラ）を組み上げて、ハードウェアのデバッグを行い、ROMに基本ソフトウェアを書き、RAM上で動作する通信プロトコルスタックの実装をZ-80アセンブリ言語で、ほぼ一人で行っていました。私にとっては、非常に楽しかった最初のプロジェクトです。
• 1984年～1986年： 就職して本格的にC言語を学び、Unixを使用しはじめた頃です。Fuji Xerox 6060 Workstationと呼ばれる製品開発でした。UnixクローンであったIdrisを採用し、今日のUnixで当たり前になっている機能（共有メモリー、共有ライブラリー、メッセージ通信、etc)を追加していました。私は、XNS(Xerox Network Systems)と呼ばれるプロトコルスタックの設計・実装を担当していました。最初は、出てきたばかりのチップ化されたEthernetコントローラのドライバーを書き、その上で動作するトランスポートプロトコル層の設計、開発サブチームのリーディングを行っていました。製品は、1986年5月に発売になったので、約2年弱の短期のプロジェクトでしたが、自分自身も成長したと思います。製品開発だけでなく、開発効率を向上するための各種ツールを作り始めたのもこの頃です。
• 1985年～1988年： Fuji Xerox 6060 Workstationを開発している最中で、社会人2年目の時に課長に呼ばれて開発するように指示されたのが6060 Workstation上で動作するIBM 3270 端末エミュレータです。製品として販売するのではなく、社内のサポートシステム（FWSS）のオンライン化のための端末として開発したものです。私を含めて社員2名、協力会社数名で私がリーダで開発しました。当初の開発は2年弱で終わったと思いますが、その後の機能追加は私一人で行っていました。サポート部門と様々な調整を行いながら、虎ノ門営業所でのオンライン・トライアルから始まり、全国展開までと大変でしたが、楽しく良い経験をしたプロジェクトでした。当時のCMの動画はこちらです。
• 1988年11月～1991年4月： 私にとって初めての海外生活を送ったプロジェクトです。Xerox StarワークステーションをSunOS上に移植するプロジェクトです。その中で私が担当したのは、VP Documentと呼ばれる文書作成ソフトウェアの移植とチームのビルド担当です。米国のエンジニアと一緒に仕事をする初めての機会でした。言葉の問題もあり、色々と大変でしたが、自分自身も成長できたプロジェクトでした。
• 1991年5月～1993年4月：　Xerox PARCで始まったプロジェクトへ技術者として参加しました。同じチームの研究者達は優秀であり、私自身として実績を残すのに必死な部分もあったかと思いますが、非常に楽しいチームでした。
• 1993年5月～1996年4月： Xerox PARCでの研究成果を製品化するプロジェクトで、日本に帰国してから従事したものです。Fuji Xerox DocuStation IM 200 / AS 200として製品化されたものです。このプロジェクトでは、白黒でしたがコピー/Faxの機能を持つデジタル複合機をSolaris 2.3上でC++で開発しました。その中で、スキャナー/プリンター部分のデバイスAPIの仕様策定および実装、その上で動作するジョブ制御のアーキテクチャの設計および実装を担当しました。プロジェクトの後半ではビルドも担当していました。このプロジェクトで学んだものとして大きいのは、C++言語、マルチスレッドプログラミングです。また、このプロジェクトで開発効率を上げるために取り組んだのは、夜間自動ビルドです。それと、システムを安定化させるためのメモリ管理モジュールの導入です。コードも私一人で約7万行ぐらい書いた記憶があります。
  このプロジェクトでは、多くの開発者が30代ということもあり、飲み会が非常に多かったです。最低でも週に2回ぐらいは行っていたと思います。

以上が、大学から富士ゼロックス在籍までの従事したプロジェクトです。幸運なことにすべて「参加して良かった」プロジェクトです。私を含めて、参加したすべての技術者がプロジェクトを通して成長したと言えるものだったと思います。

Jolt Awards （２）

先日「Jolt Awards」を紹介しましたが、再度チェックしてみたらもう一冊本がProductivity Awardとして紹介されていました。

Hello World!: Computer Programming for Kids (And Other Beginners)

• 作者: Warren Sande
• 出版社/メーカー: Manning Pubns Co
• 発売日: 2009/03
• メディア: ペーパーバック

子供向けのプログラミングの本です。Amazon.comでのレビューでは高い評価が付いています。Kindle版がなかったので、紙の本を注文しました。この出版社は、本を買うと、後で電子版ももらえるのでKindleやiPadに入れて持ち運ぶことができます。

【社内連絡】『言語設計者たちが考えること』読書会参加者募集

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

毎週水曜日に開催しています『アジャイルソフトウェア開発の奥義』読書会が10月には終わりそうなので、次回は、Jolt Awardを獲得した以下の書籍の読書会を開催します。

希望者は社内の私のメールアドレスに、『勉強会参加希望』と題したメールをください。

開催日：　毎週、水曜日の1回　朝7時40分から8時40分
開始日：　11月3日（水）
場所：　私が勤務している事業所（海老名）の会議室および大森事業所（テレコン）
書籍：　『言語設計者たちが考えること』（各人購入してください）
申込み〆切：　10月8日（金）
定員：　10名以下（申込み順）
進め方： 基本的に最初から読んでいきます。事前の予習は不要です。

業務ではありませんので、非業務扱いです

業務時間外の勉強会ですので、参加資格は社員に限定していません。誰でも参加可能です。

言語設計者たちが考えること

• 作者:
• 出版社/メーカー: オライリージャパン
• 発売日: 2010/09/27
• メディア: 大型本

まとめて書籍を購入しますので、購入を同時に希望される人は、申し込みのメールに「書籍購入も希望」と書いてください。

書籍『Continuous Delivery』

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

• 作者: Jez Humble
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2010/08/06
• メディア: ハードカバー

まだ、第2章を読んでいる最中です。

内容としては、非常に良い本です。しかし、その内容を理解するには、書かれているのと同じような開発経験がある程度必要かもしれません。

Subversionなどのソースコードコントロールを用いた開発、自動テストの実行を含む自動ビルド、コミットと同時にビルドが始まる継続的インテグレーション、こまめなコミット、etc。当然、それに伴う開発者のメンタリティの変化。

オブジェクト指向や手続き的言語による開発に関係なく、ある程度以上の規模のソフトウェア開発にとっては今後ますます必要になってくると思います。

しかし、残念ながら、上記の様々な活動を含む開発環境を重視することなく、「何とかなるだろう」という程度でプロジェクトを進めているソフトウェア開発組織が多いのではないでしょうか。そのような組織が立てるスケジュールは、結果的に「絵に描いた餅」になる可能性が高いです。

なぜなら、いわゆる「ビッグバーン」インテグレーションを行い、安定化させるのに何日、あるいは、何週間と費やし、そして、その後も品質が安定しない状態が継続するからです。※

※今時、このような開発をしようとしている開発組織の数は日本全体で減っていると信じたいですが、自分の身の回りだけでも2つは知っています。

第11期、第12期「プログラミング言語Ｊａｖａ」コース（２）

「第11期、第12期「プログラミング言語Ｊａｖａ」コース」で書きましたが、受講生は28名から18名に減りました（減らしました）。今年の1月と2月から始まったコースですが、どちらも来年の1月には終わる見込みです。

受講生から良く聞かされるのは、「明日は、Java研修」ですと事前に上司に言っても「何それ？」と言われる人がいるようです。毎月1回で年12回の参加なのに、上司が部下が受講している研修を把握していないというのは、それだけ部下の育成に関心が無いということなのかもしれません。

来年の社内向けコースに関しては、私自身は開催する予定はありません。強い要請があれば開催するかもしれませんが、始めると一年間のコースとなるので、来年は行わない予定でいます（「転職（5）」）。

Principles of Software Delivery

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

• 作者: Jez Humble
• 出版社/メーカー: Addison-Wesley Professional
• 発売日: 2010/08/06
• メディア: ハードカバー

第1章に書かれているPrinciplesです。

• Create a Repeatable, Reliable Process for Releasing Software
• Automate Almost Everything
• Keep Everything in Version Control
• If It Hurts, Do It More Frequently, and Bring the Pain Forward
• Build Quality In
• Done Means Released
• Everybody Is Responsible for the Delivery Process
• Continuous Improvement

しばらくは、これらのPrinciplesを広めるための活動が業務の中心です。※

※　このようなPrinciplesをサポートする開発環境を整備しないと、とてもソフトウェアを開発する気になれないので、行うしかないのが現状です。