So-net無料ブログ作成

リコーでの8年間に出版した本の一覧 [プログラマー現役続行]

2000年から技術書の翻訳や自著の出版をしていますが、2009年9月1日にリコーへ入社してから出版した書籍です。出版順に、次の通りです。

ソフトウェア開発の名著を読む 【第二版】 (技評SE選書)

ソフトウェア開発の名著を読む 【第二版】 (技評SE選書)

  • 作者: 柴田 芳樹
  • 出版社/メーカー: 技術評論社
  • 発売日: 2009/10/21
  • メディア: 単行本(ソフトカバー)

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

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

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

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

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

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

プログラミング原論

プログラミング原論

  • 作者: アレクサンダー ステパノフ
  • 出版社/メーカー: ピアソン桐原
  • 発売日: 2010/12/24
  • メディア: 単行本(ソフトカバー)

Android SDK 開発クックブック

Android SDK 開発クックブック

  • 作者: ジェームズ・スティール
  • 出版社/メーカー: ピアソン桐原
  • 発売日: 2011/07/26
  • メディア: 単行本(ソフトカバー)

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

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

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

Objective‐C明解プログラミング―基礎から応用までステップ・バイ・ステップ方式でわかりやすく解説 (Developer’s Library)

Objective‐C明解プログラミング―基礎から応用までステップ・バイ・ステップ方式でわかりやすく解説 (Developer’s Library)

  • 作者: スティーブン・G. コーチャン
  • 出版社/メーカー: ピアソン桐原
  • 発売日: 2013/05
  • メディア: 単行本

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

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

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

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

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

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

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

  • 作者: Alan A.A. Donovan
  • 出版社/メーカー: 丸善出版
  • 発売日: 2016/06/20
  • メディア: 単行本(ソフトカバー)

8年間の在籍期間に、私的な活動として全部で10冊(自著2冊、翻訳本8冊)を出版したことになります。2013年にはピアソンの翻訳書籍からの撤退に伴い、ピアソン桐原社から出版されていた書籍がすべて絶版となりました。しかし、『プログラミング言語Java 第4版』『Effective Java 第2版』『プログラミング原論』は、後に他の出版社から再出版されています。

最後の2冊『Javaプログラマーなら習得しておきたい Java SE 8 実践プログラミング』と『プログラミング言語Go』は、社内教育であるJava8研修とGo言語研修のテキストとしても使ってきました。

技術書の翻訳の場合、一般的な勉強会で技術書を読むことと大きく異なるのは、英語から日本語、それに校正作業の過程で何度も読み返すということです。さらに、社内教育でテキストとして使う本に関しては、教えることにより、内容がかなり頭に残っていきます。

コメント(0) 

リコーでの社内勉強会の本の一覧 [読書会]

この2年弱は、社内での勉強会を開催していませんが、私が主催でリコー社内で開催した勉強会で読んだ本の一覧です。

【期間】2010年5月10日〜2010年10月15日
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

  • 作者: ロバート・C・マーチン
  • 出版社/メーカー: ソフトバンククリエイティブ
  • 発売日: 2008/07/01
  • メディア: 大型本

【期間】2010年9月9日〜2012年12月10日
Linux Kernel Development (3rd Edition) (Developer's Library)

Linux Kernel Development (3rd Edition) (Developer's Library)

  • 作者: Robert Love
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2010/07/02
  • メディア: ペーパーバック

【期間】2010年11月3日〜2011年11月23日
言語設計者たちが考えること

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

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

【期間】2012年1月19日〜2013年7月13日

コンピュータの構成と設計 第4版 下 (Computer Organization and Design: The Hardware/Software Interface, Fourth Edition)

コンピュータの構成と設計 第4版 下 (Computer Organization and Design: The Hardware/Software Interface, Fourth Edition)

  • 作者: デイビッド・A・パターソン
  • 出版社/メーカー: 日経BP社
  • 発売日: 2011/11/17
  • メディア: 単行本

【期間】2014年1月21日〜2015年4月4日
RESTful Web APIs

RESTful Web APIs

  • 作者: Leonard Richardson
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2013/09/27
  • メディア: ペーパーバック

【期間】2015年4月27日〜2015年11月30日
Javaパフォーマンス

Javaパフォーマンス

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

英語で読んだ本が2冊でした。

コメント(0) 

clibと呼ばれるライブラリー開発の思い出(3) [clib]

(前回はこちら

記憶が定かではないですが、2000年の後半からカラーデジタル複合機の新たなコントローラソフトウェアの開発が始まりました。一枚のコントローラボードですべてのサービスを動作させるということで、ほとんどのサービスは新規に開発するというプロジェクトでした。

開発に先立ち、オブジェクト指向で開発を行うということで、当時FXISにいた私、荒井礼子さん、皆川さんの三人で富士ゼロックスのソフトウェア技術者(200名以上)に以下のことを行いことになりました。
  • C++教育を含むオブジェクト指向に関する基礎教育(一週間?)
  • 実際の開発成果物のレビューを含むコンサルティング
ほとんどのソフトウェアエンジニアは、デジタル複合機に関するドメイン知識はありましたが、オブジェクト指向言語(C++)やオブジェクト指向開発は初めてということで、基礎教育をFXISへ発注してもらって実施しました。

教育を受けただけでは、正しく実践できる保証はないため、これもFXISへ発注してもらい、希望する開発グループに対してコンサルティングをすることになりました。実際、私自身は、この頃から、2002年8月に米国へ赴任するまで、多くのレビューを行っていました。特に2001年には、週に3日とか4日は、朝から一日中レビューをしていました。

同時に開発に先立って私が書いたのが、『Code Review Guide』と『C++ Coding Standard』です。

『Code Review Guide』では、コードレビューのやり方を書いてあるのですが、特徴的なのは、開発者が単体テストを実施する前に、コードレビューを実施するということです。開発者がテストしてしまった後にコードレビューを実施して読みやすさに関する指摘をしても、コードを書き直してもう一度テストするというのは心理的な抵抗が強くなってしまうので、テストする前にレビューするように規定していました。当時は、自動テストではなく、手作業によるテストの時代でした。

『C++ Coding Standard』は、C++での様々な命名規則、クラスやインタフェースの宣言方法、定数の宣言方法、実装の隠蔽方法、禁止事項などを書いたものです。これは、IM200開発でのC++の経験に加えて、1996年から独学で学んだJavaの知識の多くをC++へ盛り込んだものとなっていました。

おそらく、2000年の夏頃からclibのAPI設計を始めたのだと思います。まず、書いたのは、『メモリ管理ライブラリ』のAPI仕様書です。次に、『メモリ管理ライブラリ』に基づく『スレッドライブラリ』のAPI仕様書を書きました。『スレッドライブラリ』には、単なるマルチスレッドプログラミング用のAPIだけではなく、コレクションライブラリも含めました。『メモリ管理ライブラリ』と『スレッドライブラリ』を総称して「clib」と呼んでいました。

clibは、製品で使われるOSであるVxWorks版が実装されただけでなく、さらにWindows版とSolaris版が実装されて開発者に提供されました。clibだけで実装されるライブラリであれば、Windows上でもSolaris上でも実装・デバッグできるようになっていました(最終的な商品では、VxWorks用にソースコードがクロスコンパイルされます)。

一方で、私自身がいくつかの開発グループのコンサルティング(主にクラス図やコードのレビュー)を行っていましたので、共通に必要と考えられる機能は、順次『スレッドライブラリ』へ追加していきました。追加した機能で最も実装が複雑だったのは、ReaderWriterLockでした。

clibはC++用のライブラリでしたが、Javaの影響を色濃く反映したものになっていました。特に、「インタフェース」概念の導入、「インタフェースの実装」を除く「クラスの多重継承の禁止」、staticファクトリーメソッドの推奨などです。

次回は、『メモリ管理ライブラリ』について書きます。

コメント(0) 

clibと呼ばれるライブラリー開発の思い出(2) [clib]

(前回はこちら

アーキテクチャ概要

Fuji Xerox DocuStation IM200 / AS200は、OSがSolaris 2.3であり、その上に、スキャナー、プリンタ、ファック装置、パネルなどのデバイスを抽象化してAPIを提供するプロセス群、それらのプロセス群と通信するvoyagerと呼ばれるプロセスがありました。一つのプロセスであるvoyager上でコピーやファックスなどのサービスが動作するようになっていました。

voyagerの中は、最下位層にMAE(Multifuction Application Environment)と呼ばれるレイヤがあり、MAEがサービスの起動から、割り込み処理、デバイスの排他制御などの基本機能を提供していました。各サービスは、ユーザからの指示があると、MAE上でスレッドとして都度起動されるように設計されていました。サービスを実装しているスレッドは、さらに子スレッドを生成することができ、それらをまとめてMAE上で管理していました。

コピーなどのサービスが完了すると、生成されたスレッド群はすべて終了します。MAEの実装は、ほぼすべてを私一人で設計・実装しました。このような動作環境でしたので、新たに実装したnew演算子とdelete演算子によるメモリ管理は、次のような機能を持っていました。
  • スレッド単位の管理:スレッド単位で、割り当てられたメモリを管理する
  • メモリ破壊検出:new演算子で返した領域の前後のメモリ領域を破壊した場合には、delete演算子がその破壊を検出する。
  • 割り当てられたメモリへのマーク付け:割り当てられて解法されていないメモリ領域にマークを付ける機能
  • スレッドごとのメモリ割り当て順序管理:スレッドごとに、個々の割り当てられたメモリがそのスレッドでの何番目の割り当てなのかの管理
システムが定常状態のとき(つまり、何もサービスが動作していないとき)に、「割り当てられたメモリへのマーク付けの機能」を使ってすべてのメモリにマークを付けます。その後に割り当てられたメモリにはマークが付けられていません。

システムの定常状態で、割り当てられているすべてのメモリにマークを付けて、その後にコピーなどのサービスを実行します。そして、実行後にマークが付けられていないメモリの一覧を表示することができました。つまり、サービスの処理の中で割り当てられて、サービスが終了したときに解放されていないメモリの一覧が表示されます。しかし、その一覧は、メモリのアドレスと、それがどのスレッドで何番目に割り当てられたかしか分からない実装になっていました。それでも、全く情報が無いよりはよかったのですが、リークしているメモリがどこでnewされたメモリなのかを調べるのが面倒でした。この面倒さを解消する仕組みは、当時私は思い付かなかったようです(clibでの改善1)。

もう一つ、当時苦労したのはダングリングポインターです。つまり、すでに解放済みのメモリを指すポインターです。解放されたメモリを参照していることをデバッガで調べるのが容易ではありませんでした。なぜなら、解放はされているが、メモリの内容(オブジェクト内容)がそのままなので、動作したりすることがあるからです。この問題の解決を容易にする仕組みも、当時私は思い付かなかったようです(clibでの改善2)。

IM200はペーパーユーザインタフェースを持つ新たなデジタル複合機でしたが、そのペーパーユーザインタフェースのソフトウェアの代わりに、別のソフトウェアを搭載したのがAS200(自治体窓口証明発行システム)でした(基本的なデジタル複合機の機能は同じソフトウェアが動作)。AS200固有の機能はすべて富士ゼロックス情報システムが開発していたのですが、そこでもメモリリークに悩まされていて、私が作った新たなメモリ管理でリンクし直したら、容易にリークが分かるようになって安定させることができました。

こうして、Fuji Xerox DocuStation IM200と AS200は、1995年の暮れから1996年にかけて完成して製品化されました。新たなサービス(課金)モデルを目指して開発されたIM 200は、残念ながらあまり売れませんでした。その代わり、AS200は対象が市役所向けでしたが、売れて、リコーへOEMまでしていました。AS200は、当時(1996年)の製品としてはめずらしく大型のタッチパネルを持ち、競合機種と比較してもダントツの商品に仕上がっていました。市役所向けとは言え、市場を席巻されてしまっては、AS200の導入と同時に普通のデジタル複合機も置き換えられてしまうのと、同じ機能を後追いで開発することは無理だと、当時のリコーの誰かが判断したのではないかと思います
※ リコーに転職してから、このOEMの件を開発部門のさまざまな人に聞いても、誰も知らないとう返事でした。おそらく開発部門を巻き込まずにOEMで仕入れて販売したのだと思います。
IM200に関しては、後継機の開発を行わないことが1996年に決まり、私は、その年の8月に富士ゼロックスを退職して、日本オラクルへ転職しました。その後、ジャストシステムを経て、富士ゼロックスの子会社である富士ゼロックス情報システムへ入社したのが1998年5月でした。

そして、1999年には、新たなカラーのデジタル複合機開発の検討が富士ゼロックスで始まろうとしていました。その頃に提案されたソフトウェアアーキテクチャに私が異議を唱えたのが1999年の暮れでした。私からの異議がきっかけで、二つのソフトウェアアーキテクチャの検討が2000年の前半の半年間に、多くのマネージャやエンジニアを巻き込んで行われました。そして、最終的には、私が提案したソフトウェアアーキテクチャは却下されて、今の富士ゼロックスのデジタル複合機に搭載されているソフトウェアアーキテクチャが採用されました。

ここから、clibの開発が始まります。それは、2000年夏です。

つづく

株式会社リコーを退職します [転職]

2009年9月から働き始めた株式会社リコーを8月31日付けで退職します。丸8年働いたことになります。現在57歳であり、定年退職までにはまだ2年と少しありますが、「セカンドキャリア制度」(早期退職制度のようなもの)の適用を受けて退職します。

8年間の会社での業務や退職理由については述べませんが、業務以外の私的活動の成果をまとめてみると次のようになります。
現在翻訳している技術書は最終校正段階ですが、8月までには出版にならないので、出版は次の会社へ働き始めてからとなります。

最終出社日は、8月31日(木)です。そして、9月からは長年勤めた複写機業界(富士ゼロックスが12年、富士ゼロックス情報システムが11年、リコーが8年の合計31年!)を離れて、私にとって6社目となる会社で働き始めます。

第4回Java研修OB・OG懇親会 [プログラミング言語Java教育]

7月22日(土)に、第4回Java研修OB・OG会をHP本社8Fのカフェテリアで開催しました。今回は、Java研修修了生だけでなく、Go研修修了生および現在Java研修を受講している人達も対象とした拡大版でした。

第3回と同様に2部構成にしました。私も入れて技術セッションには45名が参加し、懇親会には42名が参加しました。

  第1部 15:00〜17:10 技術セッション
  第2部 17:10〜19:30 懇親会

技術セッションでは、まず、「Node.js 日本ユーザーグループ」の会長である古川陽介さんからNode.jsの話をしてもらいました。古川さんが使っているTwitterのプロフィールのアイコンが、Java研修の最終課題用に作成されたものであることを知りました。

20247635_10211555245811368_2830317892286980961_o.jpg

2件目は、修了生が3名働いているクラウド会計ソフトを提供しているfreeeを西出さんに紹介してもらいました。

freee.jpg

3件目は、GROOVE Xに勤めている荒木さん(Tour of Goの日本語サイトの運営者)からロボット関連の話をしてもらいました。

Atoto.jpg

4件目は、ホンダのR&Dセンタ−Xに勤めている東さんから、ホンダおよびR&DセンターXの紹介をしてもらいました。

ここで、技術セッションの予定時間が過ぎたので、会場のカフェテリアでお酒を飲みながらの懇親会です。

懇親会.jpg

このカフェテリアは、TVドラマ「半沢直樹」の第6話で撮影に使われた場所でした。

半沢直樹.jpg

懇親会の途中で、私が「Java・Go研修を振り返って」と題した話をしました。

振り返り.jpg
この後、LTを2件と、場所を提供してくれたHPおよびDCX Technology社の紹介を加藤さんから行ってもらいました。

OG会.png

Java研修を始めた2000年の頃は、私は40歳であり、受講生との年齢差も15歳程度でした。17年が経過し、最近では、受講生の父親と同じか年上という状況になっています。

この17年間で、正確な数字はないのですが、Java研修およびGo研修で、200名以上の修了生を送り出し、さまざまな企業で活躍しています。そして、私事ですが、8月31日付けで株式会社リコーを退職し、9月から新たな会社で働き始める予定です。

clibと呼ばれるライブラリー開発の思い出(1) [clib]

2000年にclibと呼ばれるC++用のライブラリーを開発しました。それは、今でも富士ゼロックスのデジタル複合機で1000万行を超えるコントローラソフトウェア(*)と呼ばれる制御ソフトウェアで使われているライブラリです。メモリ管理機構とマルチスレッドプログラミング機構を統合したようなC++のライブラリです。
(*)http://www.atmarkit.co.jp/ait/articles/1507/06/news009.html

clibは、私がそのAPI仕様をすべて設計し、実装は他の優秀なエンジニア2名に行ってもらいました。API仕様には、防御的プログラミングも含めて、メモリ管理機構での細かな動作仕様も書いていました。

このライブラリに関して、忘れないうちに一連のブログ記事として書きたいと思います。しかし、記憶は嘘をつきます。したがって、事実とは異なった私の記憶の嘘が含まれているかもしれません。

Fuji Xerox DocuStation IM 200/AS 200の開発

時代は、1991年1月17日まで遡ります。その日、私はXerox社のPARC(Palo Alto Research Center)にいました。米国に駐在していましたが米国内で転勤することになり、新たに従事するPARCのプロジェクトの話を聞くためにLAから出張していました。その日は、湾岸戦争が勃発し、PARCの廊下で戦争が始まったと伝えられたことを鮮明に覚えています。

そのプロジェクトは、PARCではPageMillプロジェクトと呼ばれていました。富士ゼロックス社からの駐在員は私一人でした。2年間、米国でそのプロジェクトに従事したあと、製品化のために1993年5月に日本に帰国しました。4年半の米国駐在を終えて富士ゼロックスへ戻り、PageMillプロジェクトの技術の製品化を行うDS企画開発室に配属になりました。

当時、富士ゼロックスはワークステーション事業から撤退を決めており、その開発室にはそれまでワークステーションを開発していた優秀なソフトウェアエンジニアが集められていました。それでもほとんどが私と同じ歳か一つ下ぐらいでしたので、30代前半のソフトウェアエンジニアが集められていました。

この製品化プロジェクトで特徴的だったのは、以下の通りです。
  • 集められたソフトウェアエンジニアは、私も含めて誰一人としてデジタル複合機の開発に従事したことがありませんでした。
  • CPUにはSPARC、オペレーティングシステムはSolaris 2.3という構成でした。
  • 私を含めて全員が、初めてのマルチスレッドプログラミングでした。
  • 誰もほとんど使ったことがないC++で開発することが決まっていました。
この開発では、さまざまな問題に直面し、都度解決していきました。

C++での開発

C++で開発することが決まっていたのですが、当時、C++を学べば学ぶほど困ったなと思っていました。それは、APIを設計するときに、ヘッダーファイルに実装の詳細を記述しない方法がないように思えたからです。実際には、ある書き方を考え出しました。その書き方の詳細については、「API設計の基礎」に書いていますので、参考にしてください。

ビッグバンインテグレーション

継続的インテグレーションという言葉がない時代でしたので、ビッグバンインテグレーションを行っていました。しかし、2週間ごとのインテグレーションは必ず失敗するという状況でした。この問題に対処するために導入したのは、夜間ビルドです。つまり、毎晩自動ですべてをビルドするということです。毎晩ビルドが成功するようになるまでは、数週間を要しました。

当時、ビルドはかなり時間を要していました。そして、夜間ビルドが毎晩成功するわけではありませんでした。毎朝7時過ぎに出社後は、夜間ビルドが失敗していたら、原因を修正して、ビルドをやり直すということを行っていました。また、複数のワークステーションを駆使して行う分散ビルドも自分で開発したツールで行っていました。

メモリ破壊とメモリリーク

開発がある程度進んで、最も大きな問題となったのは、「メモリ破壊」と「メモリリーク」です。コピーができるようになっても、1ページのコピー動作ごとにメモリが2MBもリークしていたのです。

当時、purifyが登場していましたが、ほとんど使えませんでした。マルチスレッドでは正しく動作しなかったの、purifyを使用すると動作が恐ろしく遅くなるため、普段の開発では使えませんでした。

この時、問題を解決するには、メモリ管理を自分で行う必要があると私は判断しました。そして、C++のnew演算子とdelete演算子を独自に実装し、メモリ破壊やメモリリークを検出する機構を入れ、問題を解決することにしました。

つづく

AITCセミナー [プログラマー現役続行]

2017年6月16日(金)に、AITCセミナーで、「ソフトウェアエンジニアの心得 / Go言語の紹介」と題して2時間の話をしました。案内は、こちらです。

「ソフトウェアエンジニアの心得」はQ&Aを入れて2時間30分でいつも話すのですが、約1時間で話をしたため、省略した部分も多かったです。

「Go言語の紹介」は、Go言語の特徴をデモを含めて行ったのですが、45分だったので、用意した資料をすべて話すことはできませんでした。資料は、こちらです。

参加者は約40名程度で、セミナーの後は懇親会で、90分ほど参加者と色々と話をすることができました。

第4回Java研修OB・OG懇親会を開催します [プログラミング言語Java教育]

2年振りにJava研修OB・OG懇親会を開催します。過去の3回の開催記事は以下の通りです。
第4回は、参加資格をJava研修の修了生に限定せず、Go研修の修了生、および現在開講している第25期のJava研修受講生を含めます。

【開催日】 
  7月22日(土)

【場所】
  カフェテリア River South (東京都江東区大島)

【時間】
  • 第1部 15:00〜17:00 技術セッション
  • 第2部 17:00〜18:00 懇親会
【参加資格】
技術セッションでは、「Node.js 日本ユーザーグループ」の会長である古川陽介氏(Java研修第8期修了生)によるNode.jsの紹介を含め、修了生が活躍している企業のサービスや技術の紹介を行ってもらいます(古川さんの最新のインタビュー記事はこちら)。

懇親会は、同じ場所で引き続きビュッフェ形式で開催します。

参加を希望される修了生は、私宛にメールで問い合わせください。登録サイトの情報および詳しい案内を送ります。

ソフトウェア開発組織が持つべきカルチャー(17) [ソフトウェア開発組織が持つべきカルチャー]

コードカバレッジを品質基準としない

API設計の基礎」の3.8節「コードカバレッジと防御的プログラミング」では、次のように述べています。
テストコードによるコードカバレッジは、そのソフトウェアの品質を担保しません。コードカバレッジが100%だから、品質が高いとは限りません。バグがあるコードでも、テストでコードカバレッジを100%にすることはできます。
ある機能を持つモジュールを開発する場合、そのモジュールのAPI設計が重要になります。APIの仕様には機能や使い方はもちろんのこと、不正なパラメータの場合の振る舞いが記述されていなければなりません(参考:「API設計の基礎」)。

そして、テストコードとしては、その仕様を検査するテストを書くことになります。①適切なAPI仕様、②それに基づく適切なテスト、そして実装です。実装がテストに合格したら、コードカバレッジを計測するわけです。コードカバレッジでは、コードの実行割合ではなく、実際に実行されたコードがどの行で、どの行が実行されていないかを見る必要があります。もし、実行されていないコードがあれば、その理由を考えます。テストが不足しているのであればテストを追加しますし、不必要なコードを書いていればコードを削除するかもしれません。あるいは、防御的プログラミングのために実行されないコードなら、そのままにしておくかもしれません。

このような開発では、①の「適切なAPI仕様」が記述されているかが、まずは重要です。私自身は、多くのAPIのレビューをしてきましたが、適切にAPIを定義できないエンジニアが多いです。ソフトウェアの経験年数が浅いためにできない人もいれば、ソフトウェアの経験年数が長くてもできない人もいます。この①ができていなければ、コードカバレッジは無意味です。残念ながら①の品質を静的に解析できるツールはありません。経験を積んだスキルの高いエンジニアにレビューしてもらうしかないのです。

②の「適切なテスト」では、仕様通りであるかに加えて、入力パラメータの組み合わせが網羅されているかも重要です。不正なパラメータの検査、境界値分析、同値分割などを適切に取り入れる必要があります。①がきちんとされてない場合、②のテストは正常なケースだけだったり、テスト範囲が狭かったりします。不適切なテストを実行した結果のコードカバレッジも、再び無意味です。したがって、ソフトウェアエンジニアは、テスト設計に関する技法もきちんと学ぶ必要があります。

コードカバレッジの数値が、ソフトウェアの品質を担保するわけではありません。しかし、①と②は静的に測定するのが困難なので、コードカバレッジの数値を単体テストの品質基準にしてしまっているソフトウェア開発組織が多くあるのではないでしょうか。たとえば、80パーセント以上のコードカバレッジをもって単体テストを完了とするとかです。そして、その数値だけが一人歩きを始めます。つまり、開発者や組織が、その数値をクリアするという視点だけで活動してしまうのです。極端な場合には、ソースコードを解析して、高いコードカバレッジとなるテストコードを生成する有償ツールを使って目標値を達成することまで行われたりします(もちろん、品質は向上しません)。結果として、①の「適切なAPI」を定義できなくて、②の「適切なテスト」を設計できないソフトウェアエンジニアを大量生産してしまいます。

残念ながら、コードカバレッジの数値目標を長年追っているようなソフトウェア開発組織では、①や②をきちんと行えるソフトウェアエンジニアが少なく、あるいはいなかったりして、①や②をきちんとレビューするという品質向上の活動ができなくなったりしています。