本棚
私が読んだなかで
仕事関連の、お勧めの本を紹介しているページです。「
参考文献」タブにリストした本は外しています。
※ 少しずつ追加していく予定です。
※ カテゴリとして「ソフトウェア開発・テスト関連」と「その他」に分かれています。
ソフトウェア開発・テスト関連
［１］鈴木裕信，加藤光明：『
The BUG』，オーム社，1995年．
ソフトウェアエンジニアリングの入門書として最適な一冊です。どんなバグがあったのか、バグはなぜ発生するのか、バグを防ぐためのアプローチにはどのようなものがあるのか、そして、現場はどうなっているのかといった話題を素敵なイラスト付きでおもしろく、分かりやすく伝えています。
15年前の本なので、アジャイル、XP、UML、PSP、TSP、チームビルディング……といった話題はありませんが、現在でも十分に役に立つ本と思います。
リンク先の目次にあるように日本の各社のソフトウェアテストの方法と、取得しているメトリクス、そして結果分析について実際はどんな感じで行っているのかについて垣間見られる本です。
基本的に企業は、そのようなノウハウやデータを出したがらないので、本として知っているのはこれだけです。そういった意味では希少価値のある本なので７９，８００円という価格も妥当なのかもしれません。個人で買うには大変ですけどね。
ただし、各社とも決して特別なことをしているわけではないので、これまで見たこともない技術が書かれているということではありません。
ソフトウェアエンジニアが数学科出身だったのは遠い昔の話です。いまや、文系出身の超一流アーキテクトの方もいらっしゃいます。でも、プログラミングにあたり、数学を知っておくのは決して悪いことではありません。
本書は、「前提としている知識は＋－×÷だけ」ですが、実に数学的な考え方が身につく本で、面白い話題も多くためになります。
もちろん、テストエンジニアさんにもおすすめです。
ソフトウェアの設計に必要な理論と実践的な知識が「モデリング（構造）」と「再利用」の２つの軸でまとめられています。
基礎的な論理・集合の話から書いてあって「空間・時間・通信モデル」の理解が深まったのでよかったです。
モデリングの話以外にも例えば「操作性」の話のところで「ユーザ・フレンドリ」について、
1. 友人は私の（遊びの、仕事の、人生の）目的を理解してくれる。
2. 友人とは話しやすい。私の話を良く聞いて、わかってくれるし、よく覚えておいてくれる。
3. 友人の話はわかりやすく、役に立ち、自分が高められるような気がする。
4. 友人は心がひろく、私の誤りを親切に指摘してくれるし、また許容してくれる
といった比喩で、操作性の良し悪しが、
1. 言葉や対話の意味が明確であること。
2. 優れたマンマシン・インタフェース
3. 例外処理・異常処理への対応
で決まることが書いてあったりして分かりやすいです。
また、「言葉」をきちんと定義することの大切さが語られていて、その「定義原理」は非常に参考になりました。
（簡単に言うと「次期ＸＸ」なんていう言葉は期待だけが込められていて内容が定義されていないので、だめだといった話です。
現状のシステムのどこの部分をどのように改善したり拡張したりするかを明確にしないといけないと…あー、耳が痛いけど確かにその通りです！）
シャノンの情報理論や有限オートマトンを比喩を用いて易しく説明している本です。「だいたいこんな感じ」といいかげんに覚えていることの本質を整理してくれるということで、とても良い本だと思いますが、コンピュータを勉強している人、または、コンピュータの仕組みを理解しようと強く思っている人じゃないと読みこなすのは大変だと思います。
『HAYST入門』でシステムを階層化する効果を説明しているページがあるのですが、この本を参考にさせていただきました。参考文献へは入れ忘れです（実は私の持っている
新書版の方には階層化の図が無くてどの本に載っていたか見つけられなかったんです）。すみません。
デシジョン・テーブルはソフトウェアテストの基本であるにも関わらず、使えるレベルまで書かれた本はあまりありません。本書は、基本からしっかりと書いてあってとても興味深くおもしろかったです。
本書に書かれている、シュミットとカバナの「デシジョン・テーブルを作成する上での六つの基本ルール」は、デシジョンテーブルに限らず使える基本ルールだと思いますし、テスト設計する上でも重要なポイントだと思いました。
［６］の「デシジョン・テーブル入門」よりも上級者向けの本です。
デシジョン・テーブルを普通に使う人にとっては必要ない知識かもしれないけれど、デシジョン・テーブルを教える人にとっては知っていて損はない話がたくさん載っています。テーブルとテーブルを繋げる話（オープンテーブル、クローズテーブル）や、Don't careの数から論理抜けを検算する方法、テーブルの圧縮方法等々、実用性は微妙なところはありますが、別のところに応用できそうなアイデアもあって私としてはとってもお得な気分になりました。
デシジョン・テーブルからプログラムを自動生成するツールの話が載っていて、今では、廃れてしまったのかなと思ってググッて見たら、
こんなページを発見しました。フリーでディシジョン・テーブルから各種言語へ変換してくれます。おもしろい。
ソフトウェアテストの入門書として最適の一冊です。
筆者のホームページを見ても分かるのですが、ソフトウェアテストという仕事が好きで誇りを持っている人が書いた本です。とてもおもしろく読み進めることができますし、内容は多数の論文の裏を取ってあって正確（初版には誤植？はありましたが）です。また、随所に筆者の考えが述べられていて迷ったときの指針になります。
まだ読んでいない方は、
こちらで50ページも読むことができますのでとりあえず見てみましょう。
『The Art of Computer Programming』の第4巻「組合せアルゴリズム」の分冊シリーズの一冊目です。原始既約多項式のアルゴリズムが載っていたので購入したのですが、私にはちょっと難しいです。
Tom Demarco (Author), Timothy Lister (Editor)が選別した論文集"
Software State of the Art: Selected Papers"に採択された31編の論文から、12編がさらにセレクトされた論文集です。
特に、Weingerg, Boehm, Millsがおもしろかったです（すばらしいという意味では12編全てすばらしいものでした）。
ソフトウェアエンジニアリングの歴史は短いもののやはり先人の積み重ねがあって、現在があるわけなので、どんなことが研究済みで結果はどうだったのかについて知ることが重要だとよく分かりました（アジャイルがどんなところから生まれてきたのかといったことが分かります）。
残りの19編の中には、田島・松原による「日本のソフトウェア産業」、「日本のソフトウェア産業の内幕」や、板倉・高柳の「プログラム規模見積もりのモデルとその評価」という当時の日本人の論文が採択されているようです。
「本書は、システム開発の専門家ではなく、むしろ開発を依頼する利用部門の方々を対象にしたつもりである。」と書いてありますが、コンピュータの本質、ソフトウェアの本質、人間と社会の性質、そしてモデル化についてこんなに分かりやすく易しくおもしろく書いてある本を私は知りません。
システム開発の専門家だって、絶対に勉強になります。
海外製のソフトウェアを日本語化する際に発生する問題について、技術・翻訳・業務の3つの視点から解説している本です。ローカライズの現場では単なる翻訳の問題の他に、機能変換が必要であり、そこのところを理解していないとテストができません。
本書に書かれている内容は、極わずかであり、これだけを知っていても実践では苦労するのですが、少なくともこれくらいは知ってからテストに入らないと大変なことになると思います。
松尾谷徹氏が開発したCFD法（Cause Flow Diagram……この本が出版された頃はCase Flow Diagramと表記されていた）の説明が載っている唯一の本です（2007.8時点）。ただし、この本を読むだけではCFD法についての概念は分かるようになりますが、使えるまでにはなりませんので注意してください。
本書は、
第1章 ソフトウェアプロセス
第2章 プロセスプログラミング
第3章 ソフトウェア設計技術の発展の経緯
第4章 設計技術
第5章 オブジェクト指向による設計技法
第6章 ソフトウェア検証技術
第7章 運用と保守の技術
第8章 開発支援技術
の8章で構成されています。わずか、218ページしかない本にこれだけのテーマとなるとポイントを絞って書いていると思うでしょうが、そんな甘い本ではありません。それぞれの章に詰め込む詰め込む。それも知らないといけないような文脈で私の知らない単語がどしどし出てくる、くる、くる。あー。もう疲れましたよ。でも、本当に勉強になった一冊です。
［14］Tom DeMarco, Timothy Lister，松原友夫(翻訳)，山浦恒央(翻訳) ：『ピープルウエア 第2版』，日経BP社，2001年．
ソフトウェア開発やソフトウェアテストという仕事は、人（とチームワーク）が命です。「人」を題材としているので1987年初版（すでに20年！）のこの本は今でも色あせることはありません。
『HAYST入門』の著者の一人である仙石太郎が野中郁次郎先生の指導を受けながら進めているナレッジ・ワークプレイス改革も「活力ある個」と「ダイナミックな場」をキーコンセプトとしている点で本書の延長線上にある活動ということができると思います。
［15］Robert L. Glass，山浦恒央(翻訳) ：『ソフトウエア開発 55の真実と10のウソ』，日経BP社，2004年．
1954年からソフトウェア技術者として業界をリードしてきた論客が書いた本で、ソフトウェア開発で忘れてはならない（しかし忘れがちな）ことがコラムとしてまとめられています。翻訳者の山浦さんの名調子でとても読みやすく、ユーモアたっぷりに書かれているので一気に読めてしまいますが、内容は深く考えさせられるテーマばかりです。
真実やウソと断定した根拠となる論文や書籍の紹介がついているので、疑問に思った内容について調べることが容易になっています。
［16］柴田芳樹：『ソフトウェア開発の名著を読む』，技術評論社，2006年．
本書は、Software Peopleでの連載に加筆修正されたものです。内容は、３部に分かれていて連載の順番ではなく、
第一部 ソフトウェアは「人」がつくる
・プログラミングの心理学
・人月の神話
・ピープルウェア
・デッドライン
第二部 実践する開発者
・ソフトウェア職人気質
・達人プログラマー
第三部 読みやすいコードを書く
・コードコンプリート
・プログラミング作法
という構成になっています。
そして、どれも単なる本の内容の紹介ではなく、柴田さんの経験が織り込まれていているところが特徴となっています。
ここで紹介されている８冊は、どれも必読の書ですが、全部を読むのは大変です（実は私もデッドラインはまだ読んでいません！）。
柴田さんの２００ページ足らずの新書でエッセンスを学び、興味の湧いたものから読んでみるという使い方もできそうです。
また、読んだことのある本でももう一回読み直してみようかなぁという気にさせられました。
［17］Robert Dunn，渡部研一(翻訳) ：『ソフトウェアの欠陥除去技術』，日経BP社，1985年．
開発者向けに書かれた本ですが、広範囲の話題を取り扱っているので、テスト中心の仕事をされている方も参考になる記述が多いと思います。エラーシーディングの話題を取り扱っているのも、古い本ならではでしょうか。
本書に「欠陥の所在と検出の技法」という節があるのですが、確かにそれぞれのフェーズでやるべきことをやっていくことが大切だと思います。最後のフェーズだけで品質保証しようとしたら運に頼った莫大なテストが必要となりますから。
即効性を期待して読むとがっかりするかもしれませんが、よい本だと思います。
［18］玉井哲雄，松田茂広，三嶋良武 ：『ソフトウェアのテスト技法』，共立出版，1988年．
本書の内容は、ソフトウェアテスト全般に渡っていて、
第1章 ソフトウェアのテストとは
第2章 テストデータの選定
第3章 テストの管理
第4章 プログラムの静的解析と検証
第5章 テスティング・ツール
第6章 ソフトウェアの品質保証
付録 例題プログラム
となっています。
第4章の「プログラムの静的解析と検証」が48ページ（全体の1/4）もあって内容も難しいのですが、その他の章は易しく書かれていました。ただし、原因結果グラフのところの説明は間違っている（これだと結果がTRUEしかでないディシジョンテーブルになってしまう）ので注意してくださいね。
私も質問をされることが多い「テストの完了基準」についてこの本では、
1. テスト期間による基準
ある日数テストしたら終了、またはテスト終了日がきたら終わる
2. 工数による基準
テストに投入する工数によって終了を判断するもの
※ 期間よりは「作業量」に着目している点がベター
3. テスト項目数、テストケース数による基準
プログラムの特性からテスト項目数を決定しそのテストが終了すれば終わり
4. テストカバレージによる基準
カバレージ（C0,C1,s0,s1など）を計測し基準値以上になったら終了
※ 「作成された」プログラムの「構造」にだけ着目していることに注意が必要
5. 発見エラー数による基準
テストを実施する前にバグ数を予測し目標に達したらテストを終了
6. 発見エラー数の収束による基準
単位時間上がりに発見されるバグ数が少なくなってきたら終了
※ 信頼度成長曲線（バグ収束曲線）のこと
とまとめていました。また、「一口にテストの完了基準といっても、テストは通常、何段階かに分けて実施するものであるから、それぞれの段階ごと（単体テスト、統合テストなど）に考える必要がある。」としていました。
たしかに、１や２の基準を馬鹿にしがちですが、単体テストフェーズや統合テストフェーズでは、ほおっておくと今も基準として使われていますし、出荷判定においても大きな判断材料のひとつであることを認識しておくことが重要でしょう。
［19］SQuBOK策定部会 ：『ソフトウェア品質知識体系ガイド―SQuBOK Guide』，オーム社，2007年．
SWEBOKのように、ソフトウェア品質に関するアレコレが集約された本です。
内容は、パブリックコメント募集用のβ版をみるとだいたいわかるのですが、うれしいことに書籍になって別物といってもいいくらい、超大幅加筆修正されていました（だから、β版を手にして満足している人も一度、書籍版を見てみようね！）。
こうして、ソフトウェア品質知識体系が識者の手によって、比較的入手しやすい書籍や論文へのリンクがしっかりとられたガイドとしてまとめられたっていうことは本当に価値のあることです。
将棋の羽生善治が、インターネットに対して「高速道路」という比喩を使いましたが、SQuBOKは、ソフトウェアに関する品質知識を得るための「高速道路」だと思います。
ソフトウェア品質に携わる人の机に常備、参照、活用し、まずは先人レベルを理解し、参考文献に当たってその域に到達しましょう。
それにしても、保田勝通の『ソフトウェア品質保証の考え方と実際』、参照されすぎです。(^_^;)
もちろん、日本のソフトウェア品質知識が網羅的に実用レベルで書かれている最高の本なので当たり前のことなのですが、ここまで参照されていると保田本を改訂してセットで売ったらどうって思っちゃいました（実現性はともかくとして）。
［20］Bruce A. Tate，角谷信太郎(翻訳) ：『JavaからRubyへ』，オライリー・ジャパン，2007年．
本書は単に「JavaからRubyへ」の移行を実践するためのガイドにとどまらず、新しい技術の導入に当たって、どうすればよいのかについて書かれています。
『HAYST法入門』に「第12章 HAYST法の組織的展開」という章があるのですが、それを補完してくれます。
新しい技法やツールの導入や展開で悩んでいる人は必読と思います。
また、本書の中に、
本質的複雑性とは、取り組む仕事に必要な複雑性です。 たとえば、納税申告を扱うアプリケーションは、少なくとも税法と同程度には複雑です。
非本質的複雑性、あるいは偶発的複雑性と呼ばれる複雑性は、環境にもちこまれた複雑性のことです。
という一文があるのですが、確かにその通りだ！と思いました。
［21］清水吉男：『「派生開発」を成功させるプロセス改善の技術と極意』，技術評論社，2007年．
ソフトウェアエンジニアリングの教科書には「新規開発をどう上手くやるか」について書いてありますが、私たちが日々格闘している「派生開発」については「保守」としてひとくくりにされ、十分な記述がありません。
もちろん、新規開発のノウハウが役立つ部分もあるのですが、筆者の清水吉男は「派生開発の現場では、時間に追われバグを見つけ次第直すという間違ったプロセス」にメスを入れています。
つまり、派生開発においては、
o 変更要求仕様書
o トレーサビリティ・マップ
o 変更設計書
を作るプロセスを提案しています。これらは、実践的で非常に役立つノウハウと思います。口語調で話が整理されていないためちょっと読みにくい点がちょっと残念です。
［22］Ivars Peterson，伊豆原弓(翻訳) ：『殺人バグを追え』，日経BP社，1997年．
一見、おどろおどろしい表紙のこの本、タイトルもなんだかサスペンスっぽくフィクションかと思いきや、米国「サイエンス・ニュース」誌の数学・物理関連のライターである筆者がジェット機墜落や、放射線治療機器の過剰照射などのバグについて膨大な取材を重ねて書いたドキュメンタリーでした。
ミルズへのインタビューなどもあってなかなか興味深かったです。
そして、それぞれの事故から色々なことを学んでいます。たとえば過剰照射については、
セラック25の事故から学ぶべきことは、個々のソフトのバグに注意しても、安全なシステムは作れないということだ。この事故の基本的な間違いは、ソフトウェア工学の手法がお粗末だったことと、安全確保をソフトに頼る機械を作ったことである。個々のコーディングのエラーより、ソフト全体の危険な設計の方が重大な問題である。
としています。
本書の最後の方に、ある次の文章には全く同意なのですが、今もって不十分と言わざるを得ません。
われわれは、顧客として、またユーザとして、コンピューターのしくみと、その能力の限界について知る必要がある。完璧なものは期待できないが、生命に直接かかわるシステムには、安全性の向上を求めるべきだ。また、品質の向上を求めないことが危険であるという認識をもち、コンピューター･システムに対して何をどれほど信用するべきなのか、かしこい選択と決定をする必要がある。
銀行、航空会社、スーパーマーケットなどの企業に対し、なぜコンピューターが誤作動したのか、なぜ間違いが起きたのか説明を求め、納得のいく回答を得る必要がある。問題がそのまま続いたり、こうした懸念が軽視されたときは、ほかの企業を選ぶ覚悟をするべきだ。
私たちは、失敗からもっとたくさんのことを学ぶことができるはずです。
［23］日科技連ソフトウェア生産管理運営委員会 ：『ソフトウェア品質管理事例集』，日科技連出版社，1990年．
1980年代の日本の優れた事例が詰まっている本です。1392ページというボリュームがあり、ソフトウェアテストについては実験計画法の応用の論文が中心に収録されています。
もちろん、ソフトウェアテストだけではなく、設計レビューの方法やプロセス管理の仕方についても実データを持った素晴らしい論文が多数収録されていますので17年前の本ではありますが、非常に参考になります。
こういった事例集も最近のものが欲しいですね。
［24］日科技連ソフトウェア品質管理研究会 ：『21世紀へのソフトウェア品質保証技術』，日科技連出版社，1994年．
「“ソフトウェア品質学のState of the Arts”を語る書」というのがキャッチフレーズ（©飯塚先生）です。"State of the Arts"とは言うまでもなく、商品安全などで使われる言葉で、「そのときの最善の技術水準」を意味します。[10]で紹介した『ソフトウェアエンジニアリング論文集80's』は、Tom DemarcoとTimothy Listerが選んだ"State of the Arts"ですが、この本は、いうなれば菅野文友が選んだ"State of the Arts"なのかもしれません。[23]とあわせて参照すると良い本です。
［25］山口正明 ：『ファンクションポイントCOSMIC-FFP法実践ガイド』，日科技連出版社，2007年．
この本は、サブタイトルにあるように「組込み系・リアルタイム系に最適なソフトウェア規模・工数の見積り方法」と言われているCOSMIC-FFP法を例をあげながら説明している実践ノウハウ本です。
私はHAYST法で、FV表という機能検証一覧表を作ってテスト分析をすることを進めているのですが、本を出した後にも改良を進めていました。
それは何かと言うと、FV表の各行に、
・ ユーザ視点での評価ポイント（市場リスク）
・ 開発視点での評価ポイント（技術リスク）
を追加することです。
そのようにしておくと、各行（各機能）の市場における重要性や開発の困難さが数値で見積もられているので、その後のテスト計画がしやすいというメリットがあります。「ユーザ視点での評価ポイント」は、高橋寿一の記事や雑誌にあるようなリスク評価なのですが、「開発視点での評価ポイント」については、
・ ユーザが入力する信号因子の数
・ 機能に影響する誤差因子の数
・ （その機能が）記憶媒体から読み込むデータの数
・ ユーザへ与える出力の数
・ 記憶媒体へ書き込むデータの数
を明らかにしてそこから求めればよさそうだと思いつきました（機能の内部のロジック的な複雑度は予想できませんが、組込み系なら問題なかろうと）。 ところが、この本を読んだら、COSMIC-FFP法で機能規模(CFSU)を見積もる時に使用している要因とほぼ同じだったんですね。orz
誤差因子こそありませんが、COSMIC-FFP法では、
・ 信号因子数 → エントリ（E)
・ 読み込むデータ数 → リード（R）
・ 出力数 → イクジット（X）
・ 書き込むデータ数 →ライト（W）
からFPを見積もってたんです。
考えることは同じですね。
［26］Peter G. Neumann，滝沢 徹 (翻訳), 牧野 祐子 (翻訳) ：『あぶないコンピュータ』，ピアソンエデュケーション ，1999年．
本書はACMの季刊誌Software Engineering Notesに掲載されたコンピュータ事故を、分析したもので、
第１章 危険の性質
第２章 信頼性と安全性の問題
第３章 機密保護の弱点
第４章 原因と結果
第５章 機密保護と完全性の問題
第６章 プライバシーと快適生活への脅威
第７章 システム指向的見方
第８章 人間指向的見方
第９章 示唆と結論
と分野別にまとめた章立てとなっています。
事故については、原因が詳細に書いてあるものもあるのですが、どちらかというと新聞報道レベルのものが多いのがちょっと残念でした。また、『殺人バグを追え』のように物語になっていないので、読み進めるのには根性が必要です。 しかし、失敗に学び、再発防止を行うことをしなければ進歩ありませんよね。そういった意味で非常に重要な本だと思いますし、本書を読むことで探索的テストの勘所をつかめるのではないかと思います。
今ググッたら本書の元になった、筆者がモデレータを務めている"Forum On Risks To The Public In Computers And Related Systems"が今も機能していて、情報が集められていることに感動しました。
継続は力なり！
［27］Tom Gilb, Gerald M. Weinberg，木村 泉 (翻訳), 米澤 明憲 (翻訳) ：『計算機入力の人間学』，共立出版 ，1986年．
30年以上前の本で、副題に「打鍵入力信頼性技法」とあるように、当時のキーパンチャの労働内容とそれに対するシステム設計改善方法について書かれています。
そんな、カードリーダへのタイプミスを軽減させる方法なんていう本を読んだってと思われる方もいるかもしれませんが、今のシステム設計にも大いに役立つ内容でした。
例えば、ソフトウェアテスト関係で言えば「第7章 入力検査の適応制御」という章があるのですが、そこでは「異常に大きな入力値が与えられた場合にシステムはどういう挙動をすべきか」というテーマが扱われています。
プログラミングの過程で限界検査は組み込まれていても、現実的なデータを与えられた時に、その最大値で処理をするととんでもないことになる場合があります。2005年12月の「ジェイコム株大量誤発注事件」は記憶に残っていると思います。
このような、人が見れば間違っていると気づくようなものについてどういった設計をしたら良いのかについて、37ページかけて慎重に議論されていて非常に参考になりました。この本に書かれている対策と、実際に日本で行われた対策を比べるとおもしろいです。
［28］深谷直彦・古川善吾・西康晴・大西建児・湯本剛・秋山浩一・小野塚荘一・片山徹朗・高橋寿一・大月美佳・松尾谷徹 ：『ソフトウェアテストの最新動向』，情報処理 Vol.49 No.2，2008年．
「ソフトウェアテストの最新動向」に関する特集記事です。
「ソフトウェアテスト総論」、「テストプロセスとテストプロセス改善」、「組合せテストの設計」、「UML2.0 Testing Profile/Eclipse Test & Performance Tools Platformの解説」、「並列プログラムのテスト」、「Test-Driven Development (テスト駆動開発)開発手法としてのテスト」、「テスト／デバッグ技法の効果と効率」についてそれぞれ初心者でも分かるように書かれています。
［29］エルフリード・ダスティン，成田 光彰 (翻訳) ：『ソフトウェアテストを改善する50の実践手法』，日経BP社，2008年．
この本は、同値分割・境界値分析のようなテスト技法の話ではなく、ソフトウェアテストの仕事を、10のステージに分けて、それぞれに対しベストプラクティスを紹介すると言うものでした。目次（各ステージ）は、次の通りです。
第1章 要求フェーズ
第2章 テスト計画
第3章 テスト・チーム
第4章 システム・アーキテクチャ
第5章 テストの設計とドキュメンテーション
第6章 単体テスト
第7章 自動的テスト・ツール
第8章 自動的テスト：精選したベスト・プラクティス
第9章 非機能的テスト
第10章 テストの実施を管理する
前著の『自動ソフトウェアテスト』と同様に、非常に実践的で泥臭い話が満載されています。たとえば、「項目12 テスト準備時間と実行時間を見積もる」では、開発者の人数からテスト担当者の人数を決定する「対開発者比率法」を紹介しています。
これは、まぁ、現場では良く使われる方法なのですが、その時に何を考慮しなければならないのかについてきちんと書いてあるものは少ないのではないでしょうか。
また、自動テストについては、専門家だけあって2つの章に分けて、しっかりまとめられています。でも、なりよりも私が一番気に入ったのは第9章の「非機能的テスト」です。非機能要件のテストの勘所が押さえられています。
というように、とても良い本ですし、初心者でも十分に読みこなせると思うのですが、難点が2つあります。
一つは、絵が少ないので本を読みなれている人でないと眠くなってしまうのではというおそれです。すごく初級の話（いや、それも大切なのですが）と、ダスティンならではの視点の深い話が混在しているので眠くなってはハッっと目覚めると言う繰り返しでした。
で、もう一つは、翻訳の質の問題です。「第9章 非機能的テスト」っていう訳一つをとっても「第9章 非機能要件に対するテスト」と書かないと正確に伝わらないだろう……と思います。章のタイトルからしてそれですので、推して知るべしで日本語として変なところがたくさんありますし、句読点の位置も変で読みにくい箇所も多いです。
それが残念でしたが、テスト技術者は頑張って読むべし……と思います。
［30］Joel Spolsky，青木 靖(翻訳) ：『BEST SOFTWARE WRITING』，翔泳社，2008年．
"Joel on Software"の著者として有名な、Joel Spolskyが選者となって、2003年から2004年に掛けて発表されたソフトウェアに関する読み物の中で最良と思われるものを29篇集めたエッセイ集です。
いくつか首をひねるようなものもありましたが、多くはとても興味深い話でした。
自分が一番面白いと思ったものは、
・ グレガー・ホペ － スターバックスは2フェーズコミットを使わない
です。
ホペの主張を要約すると、「よくよく観察すると、スタバのシステムは優れた非同期メッセージングアーキテクチャであることが分かった。我々は、コンピュータの世界からシステムデザインしがちだが、現実の複雑なビジネスプロセス（多くは、2フェーズコミットなんていう手法を知らない人が作り上げたもの）から学ぶことができるのではないか」というものです。なるほど。昆虫の世界の観察＆活用に似てるなと思いました（って話飛んでる？）。
ソフトウェアテスト関連では、
・ ラリー・オスターマン － ラリーのソフトウェアエンジニアリングの第2法則: テストメトリクスでテスタを評価することはできない
がありました。
ところで、Joelのエッセイの翻訳プロジェクトがあるんですね。
ここで日本語で読めたりします。知らなかったー。
［31］大西建児，丹羽隆，町田欣史，田呂丸直純，秋山浩一，珍田晋之介，鈴木三紀夫，池田暁，細川宣啓，佐々木方規 ：『ソフトウェアテスト入門 押さえておきたい<<要点・重点>>』，技術評論社，2008年．
『ソフトウェア・テストPRESS』Vol.1～4と『エンジニアマインド』Vol.5の掲載記事からソフトウェアテストに関する入門的な記事を再編集した本です。
にしさんによる「刊行に寄せて」と、各記事の時候の挨拶等の省略および誤字脱字の修正と、著者紹介のところにオススメ本が掲載されている他は（つまり内容は）雑誌掲載記事とほぼ同じものですので雑誌を全て持っているという人は買わなくていいかもしれませんが、買って後輩にプレゼントしたら喜ばれるかもしれません。
Vol.2に掲載された直交表の記事も採録いただきました。←「HAYST本より分かりやすいです」というコメントを何度もいただいているやつです。
上で、「後輩にプレゼントしたら」と書きましたが、まさに10人の先輩が後輩に自分が大切と思ったノウハウを惜しみなく伝えている、そんな本です。 それぞれの記事に熱気があってヨイです。
［32］Tom DeMarco，渡辺 純一(翻訳) ：『ソフトウェア開発プロジェクト技法』，近代科学社，1987年．
原著は、1982年にYourdon Inc.から出版されたTom DeMarcoの"CONTROLLING SOFTWARE PROJECTS"という本で、本書は1987年にIBMの渡辺純一氏によって翻訳されたものです。
ロバートグラスの『ソフトウエア開発 55の真実と10のウソ』に、デマルコの言葉として、"You can't manage what you can't measure"というウソが広まったのは私の本の冒頭からだけれど、そこでは実際は"You can't control what you can't measure."と書いているんだ。といったことが紹介されていました（本書の訳も正しいもの「測定できないものはコントロールできない」）。
このページによると、controlは「コントロール」（プロジェクトに影響を与えるなんらかの事象……厳密には「変更（change）」と呼ぶ……が生じた場合に、適切に対処すること、それに伴う作業）、 managementは「マネジメント」（プロジェクトをうまく成し遂げるために行う作業）と訳すのがよいそうです（管理と訳すとごちゃごちゃになってしまうから）。
さて、本書に戻ると、日立の田島・松原論文など日本の論文が3篇も引用されていたり、第IV部（48ページ）が「ソフトウェア品質」だったりで興味深いものでした。
もちろん主題の、メトリクスを計測してコントロールに役立てようと考える人には必読の書だと思います。
［33］保田勝通、奈良隆正 ：『ソフトウェア品質保証入門』，日科技連出版社，2008年．
1995年に出版された『ソフトウェア品質保証の考え方と実際』という品質保証を仕事にしている人なら必読の本が、重要な部分が絞り込まれ、初心者にも読みやすく全面的に書き直されていました。
前著を何度も読んだ私にとっては、重複が多かったり、知りたいところについては（探針とか）さらにサマライズされていたりするのでちょっと不満なところもあるのですが、辞書的な本を通読できる本にしたという意義は大きいですし、もし、前著を読んでいない（ソフトウェア関係の）人がいたら是非読んでいただきたいと思います。
［34］中里博明、武田知己 ：『二項確率紙の使い方』，日科技連出版社，1957年．
探針テストの区間推定の精度を近似式（奈良さんの資料によると不良5件以上の時に適用すると書いてありますが、サンプリング件数が少ない時にも正規分布の近似式はずれが大きいと思います）よりも上げることができるという「二項確率紙」なるものの使い方を知ろうということで購入しました。
1957年2月5日に初版出版という歴史ある本で、入手したものは1993年3月29日、改訂第22刷でした。序文が南極探検中の西堀栄三郎＠ケープタウン港というのがすごいですね。
それで、区間推定の仕方ですが、11ページから12ページにかけてその方法がずばり書いてありました。
確かに近似式より精度は高いし、計算が不要と言うところがすごいのですが、グラフのメモリの上限から、標本数（探針テスト数）、標本テストでのバグ数とも、100件以下で無いと使えません（使えるけれど精度は恐らく近似式より落ちます）。
それから、この本には仕組みがほとんど載っていないので、消化不良感が大です。
でもね。いいことが書いてあったんです。
それは、
正規分布による近似法 ＜ 二項確率紙 ＜ F分布による方法
の順で区間推定の精度が高くなるということ。
この本が書かれた1957年には確かにF分布による方法は面倒だったと思うのですが、いまや我々はEXCELを持っています！！
ということで、EXCEL 2003でさくっと作ってしまったものが、こちらです。
黄色いところに値を入力すると下の方の値が変わります。
※ この本には書いていなかったのですが、EXCELではベータ分布を使ったほうが計算誤差が少ないとのことなので、そちらも追加しました。
［35］中島震 ：『SPINモデル検査―検証モデリング技法』，近代科学社，2008年．
初心者向けSPINの実用書です。
SPINとは、"Simple Promela Interpreter"の略で、"Promela"は、Gerard J. Holzmannが作った並列処理を伴う状態遷移（オートマトン）を記述できる形式仕様記述言語のことです。
この本は、実例（Promelaプログラムサンプル）を通してソフトウェアの振る舞いの形式記述法を学び、SPINでそれを動かしてデッドロックや、プロセスのプライオリティ逆転等々のモデルチェッキングの方法を学ぶことができます。
SPIN自体は、プログラマが振る舞いの検証を行うために使うツールと思いますので、いわゆる第三者検証を実施しているテスト設計を行う人が使うことはないと思いますが、SPINでどんなことが検証できるのかを知っておくことは悪くないと思います。
また、特に9章の「検査対象の大きさを適切に保つ……抽象化の方法」は普通のテスト設計にも非常に役に立つと思います。この章の始めに、抽象化が重要であることは容易にわかるが、抽象化によってシステムがもともと持っていた性質が消えてしまっては元も子もない。という文があるのですが、じゃあどういう観点で抽象化していくのと言う答えがこの章にあります。節名だけ書くと、
9.2 データ値に着目した抽象化
9.3 制御の流れに着目した抽象化
9.4 連続時間の抽象化
です。
山本訓稔さんがリーディングされている「Model Checkingを適用した実践的非同期制御検証」は、要するにモデル設計フェーズで作成しているxUMLからPromelaを自動生成するツールを作ったってことです。
こうすることで、xUMLからC++へ変換されるC++の3万行のコードに対して、300万もの状態を自動検証したことと同等の効果を得ることができ、きわどい欠陥を検出できています。
つまり実用段階の技術となってきているのですね。
［36］安藤利和 ：『Java/Eclipseソフトウェアテスト・チュートリアルブック』，秀和システム，2003年．
ソフトウェアテストと言うよりも、ソフトウェアデバッグ（開発行為としてのテスト）のチュートリアルといった本なのですが、そもそもどのようにソフトウェアを書けばテスタビリティが向上するのかといった初級者向けの話が平易にかかれていることと、privateなメソッドや、abstract宣言したクラスをどうやってJUnitでテストするのかといった具体的なことが書いてある貴重な本です。
［37］大村 平 ：『統計解析のはなし』，日科技連出版社，2006年．
1980年に出版された本で、初版は32刷も重ねたベストセラーです。私が購入したものは2006年に出た改訂版の方です。
「探針テスト」→『二項確率紙の使い方』→「F分布」という流れで本屋さんで統計に関する本を片っ端から物色し、一番易しく書いてありそうということでこれにしました。
結果は大正解！
大村 平の本はどれも初学者に優しいですね。
統計解析の基本的な考え方について、特に何故そういった計算をしたいのかを独習することができます。
計算についても、四則演算と√を知っていればなんとかなります。
目次は、次の通りです。
１．前口上
２．素人探偵ものがたり－推定のはなし、その１－
３．名探偵ものがたり－推定のはなし、その２－
４．名行司ものがたり－検定のはなし－
５．代表選手の言い分を聞く－抜取検査のはなし－
６．ばらつきをばらす法－分散分析のはなし－
７．総身に知恵はまわるのか－相関と回帰のはなし－
８．複雑さをばらす法－多変量解析のはなし－
９．なんでも数字で表わす法－数量化のはなし－
付録
［38］William C. Hetzel，鳥居 宏次(翻訳) ：『プログラム・テスト法』，近代科学社，1974年．
1972年にノース・カロライナ大学で開催された、世界初のソフトウェアのカンファレンスの論文をまとめ、それにテストの概要を加えたもので、 1974年に翻訳本が出版されました（日本で初めてのソフトウェアテストの本）。
論文集のところは、さすがに使える情報が少なかったのですが、Hetzelがまとめた「テストの原理」は今でも通じるものです。
◆◆◆
計算機プログラムにおけるテストの原理
1. セグメンテーション
複雑で大きな問題を、数多くの小さな部分的な問題に分割し、それぞれを別個に取り組むことを指しています。
1951年に、Wilkesがサブルーチンを使い始めてから、1968年のDijkstraによるストラクチャード（構造化）プログラミング、1971年のParnasのモジュラー・プログラミング、そして、Millsのトップ・ダウン・プログラミングとセグメントに分けるということがプログラミングの複雑度を下げる原理として注目されていました。
テストにおいてもこの原理が成り立ち、テストを階層的に構造化しようというアイデアです。小さな単位のテストは小さなモジュールの開発が終わった直後に実施できますから、結局はプログラムの改良とテストを並行して実施できるという経済性が得られるとしています。
2. 可テスト性を持つ設計
「テストを可能とする設計」というアイデアです。全体の設計とコーディングの過程を通してテストは計画されなければならないという認識が出てきたと書いてあります。
また、テストが可能なように問題の仕様を決めることで、暗黙的に理解される（と考えられがちな）仕様を排除し、仕様のあいまいさと誤解をなくすというものです。
そして、スタブを用意して全ての開発が終わらなくてもテスト可能にすることで、セグメンテーションの効果を発揮することができます。
3. シミュレーション
ソフトウェアの動作環境をソフトウェアでシミュレートしようということです。そうすることで、容易に特別な環境を用意できます。
また、サブモジュールをテストするために主モジュールをシミュレートするといったことが行われていたようです。
4. サンプリング
品質を評価するときに、全体のプログラムを詳細に解析するのではなく、サンプルした部分だけを分析して得られた結果に対して外挿を行うといった方法や、エラーシーディングによる統計的テスト方法といったことが提案されています。
5. 論理的簡約
プログラムを「論理的性質を温存しながら」単純化、簡約化するというものです。例としては、フローチャートや有向グラフへの変換をあげています。今で言うところのモデルを作るというものに通じますね。括弧で囲んだ部分、つまり「性質を温存する」というのがモデル化のポイントだよなぁとあらためて思いました。
6. 標準化
コーディング規約や、インターフェースの標準化を行うとテストの問題を簡単化できるということです。
7. 自動化
自動テストですね。テストデータの自動生成、デシジョンテーブルを利用した新しいテストケースの選択、カバレッジ測定の自動化等々です。
◆◆◆
さて、テストの原理に続き、残問題の例として、「テストの完全性を測定するよい尺度がない」ことと、「形式仕様記述などのあいまいさのない仕様言語の実現の難しさ」が挙げられていました。
こちらも、進歩はしていますが解決はしていませんね。
［39］Pascal Dennis，松尾 英俊(翻訳) ：『アンディ先生と私』，センゲージラーニング，2007年．
製造業のノーベル賞と称される新郷賞（2006年度）を受賞した本で、一言で言うと、瀕死の自動車工場がトヨタ生産方式で立ち直る様を物語風に描いた本です。
外国人からトヨタ生産方式ってどうみえるのだろう？と思って買ったのですが、物語としてはあまりおもしろくない本でした。
とはいっても全くだめな本だったかと言うとそんなこともなく、たとえば、次の文章とか（良く聞く話といえばそうなのですが）心に残りました。
「何かを変えるってことは舟旅だ、トムさん。だけどほんの一握りの人間しか、舟の漕ぎ手のことを考えない。ましてや、漕ぎ手になろうなんて思わない。同じように、誰も今ある物事を変えたくはない。見ている方が楽だからな。そして、反対するのも一握りの人間だ。不満を言ってる者たちだな。
ポイントは、漕ぎ手(10%)と、見物客(80%)と文句を言っているやつ(10%)。誰が誰かを見極めることだ。ものを変えたければ、まずは漕ぎ手を助ける。不満を言う者たちはほっておけ。まあ、こいつらが他に害をもたらしたら問題だがな。そのうち、計画がちゃんとしていたら、今度は見物客が漕ぎ手になるよ」
現実問題では、そんなに達観できないので不満しか言わない人に怒りを覚えるのですが（^_^;）。
［40］Dennie Van Tassel，戸田 巌(翻訳) ：『実践プログラミング技法』，日刊工業新聞社，1976年．
Myersより前に書かれた本です。
原題は、"Program Style, Design, Efficiency, Debugging, and Testing"でこちらには、"Testing"という言葉が入っています。
全体としては、FORTRAN, PL/I, COBOL時代の初級者プログラマに向けたノウハウ集といったところで、コメントの書き方から始まって非常に丁寧に書かれています。
「プログラムのテスト」という章では、Dijkstraの「テストは、バグのないことを示すものではなく、バグの存在を示すものである。」という言葉から始まり、「プログラムの設計とコーディングは、習得できる技術である。したがって、いまこそプログラムのテストを芸術としてのテストから科学としてのテストへ移行すべきときである。」と主張されています（もっとも、これが実現するのはMyersの本を待たないとならないのですが）。
歴史的検証から、この本にあった用語をリストすると、
・ レッグテスト(leg tests): プログラムのロジックの各枝(leg)を網羅するテスト。
・ スモークテスト(Smoke test): プログラムが実行できるか否かのチェックを目標とする最初のテスト。
・ 計画形テストデータ(controlled test data), 無作為型テストデータ(random test data): 前者はまれにしか起こらないような特殊状態をもテストできるように作成できるという点で有利であるが、ユーザが認識した問題だけがテストデータに含まれるということが欠点である。したがって、無作為テストデータを使うことも、見落とすべきではない。
・ テストジェネレータプログラム(test generator program): テスト中で使われるテストデータの"パターン"を作成するもの。
・ ダミーモジュール(dummy module): エントリとリターンポイントのみを持つスタブ。
・ 代用モジュール(substitution module): 上位モジュールのテストに必要な値を返すスタブ。
・ テストライブラリ(test library): 製造用ライブラリ(production library)に、テストエイド(test aid)または、デバグエイド(debug aid)を埋め込んだサブルーチンより成るもの。
・ 冗長テスト(redundancy testing), 復帰テスト(regression testing): 再テストと同じ。
・ ブラックボックス(black box): 規定の入力に対する出力を確認するテスト。
・ 専門馬鹿(professional idiot): 侮蔑した意味ではなく、ポイントをついた誤りデータを作り出す、すなわち、馬鹿者が投入しそうなデータを作る能力がテストグループ員に必要。
・ 承認テスト(acceptance testing): テストグループによって行われたテスト。
といったものが書かれていました（現在と意味が違うものもありますが）。
あと、おもしろいと思ったのは、システムのテスト法なのですが、ユニットテスト⇒モジュールテスト⇒システムテスト⇒製品試験⇒現場試験⇒商用試験のステップを踏むようにと指導していて、今より後工程のステップが細かい点です。ひょっとしたら今より十分テストがされていたのかもしれません。
この本では、「プログラムのテスト」の章の前に「プログラムのデバグ」という章があるのですが、そこで、両者の違いについてこんな風に定義していました。
プログラムに誤りがあるという前提に立って行われるのがデバグである。そのプログラムが正しく動作すると思われるようになったら、それはもうテストの段階である。テストの段階であってもプログラムがデバグ段階へ後戻りしてしまうことはよくあることである。テストによって誤りの有無を調べ、誤りがあることがわかるとデバグを行ってその誤りの位置を見つけ出すことになるからである。このことからわかるように、両者の境界をどの時点からどの時点までと決めることは困難である。しかし、プログラムを製造する際には、この2つを意識することが必要であることを明らかにするためにも、2つの段階を設けておくべきである。
なかなか、よい説明だなと思いました。
［41］Dorothy Graham, Erik Van Veenendaal, Isabel Evans, Rex Black，秋山 浩一 (翻訳), 池田 暁 (翻訳), 後藤 和之 (翻訳), 永田 敦 (翻訳), 本田 和幸 (翻訳), 湯本 剛 (翻訳) ：『ソフトウェアテストの基礎』，センゲージラーニング，2008年．
JSTQB（ソフトウェアテスト技術者資格認定）の上位組織であるISTQBのFoundation Level試験にそった内容が書かれている本です。
翻訳を開始したのは4月初めで、全ての翻訳が終わったのは6月25日です。
5回の打ち合わせと650通を超えるメール。Rex Blackの日本語版に向けた序文と、高橋寿一の推薦の言葉からできています。
ということで思い入れが非常にある本なのですが、冷静に一読者として見てもこれまでにないかなりよくできたソフトウェアテストの基礎を学習できる本じゃないかと思っています。
以下、具体的にどこが良いのかについて書いてみます。
第1章は、テストとは何ぞや？という章なのですが、運転免許試験とソフトウェアテストを比較して説明しているところがわかりやすく良くできていると思いました。この類似性の指摘は、ソフトウェアテストに対する正しい認識を与えるのに効果があると思います。
第2章は、ソフトウェアライフサイクルを通じたテストの構成の話です。反復型ライフサイクルや、RAD、アジャイル開発に対してテストをどのように実施すべきかについて書かれた部分が参考になりました。
第3章は、静的技法なのですが、レビューについて非常に具体的かつ詳細に書かれていて実践の助けになります。私はこの章を担当したのですが何度も読むことになったのですごく得をした気分です。
第4章は、動的技法です。こちらも具体例によってシラバスで求めていることのレベルがわかってよかったです。また、「何故そうするのか」についてかなりじっくりと書いてあるので応用が利くと思います。
第5章は、マネジメントの章です。テストアプローチ、テスト戦略のリストが興味深かったです。
・ 分析的（Analitical）
・ モデルベース（Model-based）
・ 方法論的（Methodical）
・ プロセス準拠または標準準拠（Process-or standard-compliant）
・ 動的（Dynamic）
・ コンサル的あるいは指示的（Consultative or directed）
・ 影響回避（Regression-averse）
の7つを紹介しているのですがなるほどなぁと参考になりました。
第6章は、ツールの章です。「組織にツールを導入するときに最初に検討することは、ツールについてではなく、組織についてです。」という文章にはっとさせられました。
第7章は、試験対策と模擬試験です。ISTQBがどのような問題を出すのか、また、それに対する対策はといった受験生にとって一番興味があることへの回答がずばり書いてあります。
ということで、私自身、知らなかったことが多かったですし、テスト全般をいい感じにカバーしている本なので、JSTQB Foundation Levelに合格している人にも読んで欲しいです。
［42］水野 貴明、石井 勇一、新藤 愛大、岸田 健一郎、荻野 淳也、安井 力 、田中 慎司 ：『Webアプリケーションテスト手法』，毎日コミュニケーションズ，2008年．
Webアプリケーションの開発者向けのテスト自動化を助ける本です。
1章で、テスト駆動開発の重要性を述べ、続く、2章で大まかなテストの流れの解説したあとは、Perl, Flash, PHP, Ruby on Railsと、それぞれの開発言語ごとのTDDのフレームワークと単体テスト用ツールの紹介が続きます。
そして、7章で、Seleniumを用いたブラウザ操作の自動化、8章で負荷テスト、9章でセキュリティ、10章でユーザビリティテストとそれぞれの入門的な話が載っていました。
特に、水野 貴明が担当した、1, 3, 9, 10章は読みやすかったです。
Webアプリケーションを開発している組織で、テストの自動化が行われていないところがあったら読むことをお勧めします。
もうちょっと、ソフトウェアテスト自身についての説明（ページが足りないということであれば書籍やWebの紹介）があるとよいのにと思いました。
同値分割すら書かれていないので、初心者の開発者が効率の悪いテストコードを書いてしまうんじゃないかとちょっと心配です。
［43］Marc McDonald, Robert Musson, Ross Smith, 宗 雅彦 (監修), 溝口 真理子 (翻訳), 依田 光江 (翻訳) ：『ソフトウェアの欠陥予防』，日経BPソフトプレス，2008年．
副題に「テストより確実な品質改善法」なんてついているけど気にする必要はありません。原著にはそのような副題は付いていませんし、本書の述べている「最高の戦略」でも、
これは、将来の欠陥を予防する戦略です。潜在的な欠陥を予期できるテクニックに焦点を合わせ、可能性のある不具合を積極的に取り除き、低減するために、これらのテクニックを使用します。この戦略において、テストの主たる利用はソフトウェアの品質を「確認」することです。
となっています（テストがいらないってわけじゃあありません！）。
本書は、Microsoft Windows Defect Preventionチームの仕事の内容だそうで、欠陥予防に投資することが経済的に理にかなっていることの説明や、Vista開発時のゲームを使ったモチベーションアップの方法、テストしやすいソフトウェア、リスク分析、欠陥分析、FMEA/FTA/故障モデリング、予防タブ等々について書かれていてとてもためになりました。
ちょっと高い本なので、購入に迷われる方もいらっしゃると思いますが、そんな時には、各章のまとめが半ページから1ページ程度で非常によく書けているので、そこを立ち読みして判断されると良いと思います。 例えば、一番短い第6章のまとめは、
ソフトウェア全体のテスト容易性を高めるには、SOCK（単純性、観察性、制御、知識）のそれぞれを強化してください。必要以上に複雑すぎず、観察しやすく、制御しやすく、考えられる振る舞いについてテスト開発者に知識と予測性を与えるプロジェクトは、テスト容易性の高いプロジェクトです。テスト容易性を高めると、自動テストのコストを軽減でき、ソフトウェアが要求を満たしているかどうかを見極めるテストの信頼性と正確性が向上します。ソフトウェアのテスト容易性を高める最も現実な方法は、仕様書のインスペクションプロセスを行うことです。そこでテスト容易性のチェックリストを使用することにより、初めからテスト容易性を意識したソフトウェアの全体設計や詳細設計が推進されます。
です。
この本に、Wモデルと言う言葉はでてきませんが、Wモデルを実践するに当たって必要となる考えや、仕事の参考になるテクニックがたくさん載っています。
強いて難点を言えば、これだけのことをしてもVistaは失敗したということは、この本に書かれていない要求獲得が如何に大切かと言うことですよねぇ。(^_^;)
［44］Michael S.Deutsch, Ronald R.Willis, 成田 光彰 (翻訳) ：『ソフトウェア品質工学』，日経BP社，1990年．
副題は、「技術・管理両面からの総合的アプローチ」です。
内容ですが、「品質工学」といってもタグチメソッドではなく、"Software Quality Engineering"を成田光彰氏が素直に翻訳したものです。
この本では、SVD(System Verification diagram)＝システム検証ダイアグラムを紹介していました。
これはどのようなものかというと、機能要件を一連の刺激・応答エレメントの関係を明らかにしながら、図式化するものです。
各刺激・応答エレメントは個々の要件に対応しており,要件番号または参照パラグラフ番号が付されている.刺激は入力イベントとその時点のシステムの状態を示す条件修飾子からなる.同様に,応答は出力イベントと条件修飾子からなる.ただし,出力イベントの条件修飾子は入力イベントの結果発生する条件を示す.
とありました。
SVDに興味をもたれた方は、こちらが参考になるかもしれません。
［45］山村 吉信 ：『えー、全部テストするんですか?』，三元社，1999年．
保守テスト（いわゆるちょい変えの時にする回帰テスト）をどこまでやればよいのかについて書かれています。
第1章では、ソフトウェア開発をめぐる諸問題と解決策とされている方法の持つ問題点が書かれています。たとえば、形式的手法については、
形式的手法の難しいところは「形式的手法に対して、作る前には何を作るのかを指定することは難しい」という単純な事実から来ているのである。
と説明していますし、ISO9000やCMMに対しては、
実施するには技術を蓄積できる開発グループが必要である。ところで、要員が短期で移り変わる外注化の中では、そんな蓄積など夢のまた夢である。かくして普通の現場に工程管理を持ち込むのは至難の技となる。
と書いてあります。 どちらも、鋭く問題点の本質を突いていると思います。
そして、そのような現状に対して筆者が提案する解決策は、
① テストの網羅性（C0,C1,C2）を計測しよう（テストの努力義務を明らかにしよう）
② サンプリングテストの結果から統計的にバグ数の区間推定を行ったり、信頼度成長曲線により残バグ数＝リスクを認識しどこまでテストしたらよいかについて指針を与えよう
③ 文書管理をきちんとしよう
の3点であり、基本的な考え方としては自分と近いものを感じました。
1番目の、テストの網羅性については、「C言語のコメント（/* ～ */）を取り去る76行の（コンパイルして確認できる）C言語プログラムと、その状態遷移図」を例として、具体的にC0,C1,C2について説明しているところがとても良い(*)と思いました。ミューテーションテストとエラーシーディングについては、そんなに効果があるとは思えないのですが、まぁ、技術の紹介と言う意味で価値はあります。
※ C0をアド・ホック・テスティングと呼んだり、C2の定義がちょっと疑問だったりしますが……。
2番目のエラーの区間推定と信頼度成長曲線については、私は探針テストの勉強の中で理解していたのでよい復習になりました（というか先に読んでたらもっと楽だったなと思いました）が、現場の人がこの本の説明を読んで理解して使えるかというと、そこまで丁寧には書かれていないので残念です。また、「どのような場合にエラーの区間推定と信頼度成長曲線」を使用することができるのかといった統計処理を行ううえでの「前提」についての説明が不足しているところが問題です。そこのところは、くどいほど説明すべきと思います。
3番目の文書管理については、IEEE 829にそったものです。ただし、うわべの紹介にとどまっているのが残念です。どうして、そのような記録・管理が必要なのかについて突っ込んで書いて欲しかったところです。
ということで、厳しいコメントもしましたが、全体的にいうと私はこの本好きです。この本をみんなが読んで、いいところ、疑問なところについてディスカッションするネタとして使えるのではないかと思います。
［46］やねうらお ：『ひなた先生が教えるデバッグが256倍速くなるテクニック』，技術評論社，2008年．
内容は、ソフトウェア開発をしたことがある人なら全て経験しているであろうデバッグに関するテクニックがあれこれ書かれています。簡単なテクニックからはじまり、徐々に高度なテクニックに移り、ちょっと難しいなと思ったあたりから、コードレビュー的な視点で何がいけないのかが丁寧に書かれ、最後に集大成のデバッグが待っているという（プログラムから離れて10年の私でも）楽しく読み進められる本でした。
もちろんこの本にも難点（納得がいかない点）もないわけではありません。230ページ2行目の仮引数とローカル変数の書き間違えといった誤植系が多少あることと、いや、そんなことはどうでもいいことなのですが、それよりも、問題は191ページです。
「ところで、ケニチ君。次のプログラムをどう思う？」
if (10<=b1) {
} else {
init();
}
といったところ。
詳しくは本文を読んでもらうとして、ここで筆者が言いたいことは、「コピペしてきたソース（上に引用したelse部しかないif文）をきれいに書き直してしまうと、コピペしたこと自体が判らなくなるので、最悪のリファクタリングだ」ということです。まぁ、議論は分かれると思いますが、私は賛同できないなぁ。
［47］佐藤 武久 (著), 金藤 栄孝 (著), 大槻 繁 (著), 二木 厚吉 (監修)：『ソフトウェアクリーンルーム手法』，日科技連出版社，1997年．
本書は、入門書ではありますが、ソフトウェアクリーンルーム手法についての考え方、進め方が一通り学べるとても良い本だと思います。
# ボックス構造モデルについては、『ソフトウェアエンジニアリング論文集80's』のMillsの章の方が詳しいです（当たり前ですけど）。
ただ、10章と、11章に出てくる「ホーア論理」と「ダイクストラ法」については全くといっていいほど理解できませんでした。
知人に、そのあたりについては、ゾーハ・マンナの『プログラムの理論』で勉強したと聞き、そちらも読んでみたのですが、難しい。
［48］梶原 武久：『品質コストの管理会計』，日科技連出版社，2008年．
品質コストとは、企業が品質向上にかけているアクティビティを、
◆ Input
・ 予防コスト（教育やプロセス改善など）
・ 評価コスト（テストなど）
と
◆ Output
・ 内部失敗コスト（市場導入前の欠陥対応など）
・ 外部失敗コスト（市場導入後の欠陥対応など）
に分けて集計し、つまりは品質向上アクティビティをお金に換算し、比較できるようにしているところがポイントです。
品質コストには、2つのコストモデルがあり、TQMの観点では、最も品質を上げた状態が最少のコストになるというコストモデルを採用していたので、重視されてきませんでした（Demingは「品質コスト分析を行うな。製品を"正しく"生産するために、単に"川上"に投資せよ。」と述べています）。
他にも、例えば、久米均は、「企業経営にあたっては目に見えないものが目に見えるものと同様に重要であることが少なくなく、目に見えるものだけで物事を考えることは経営を誤ることにもなりかねないのである。」という見解を1984年に示しています。
つまり、ブランド力の低下といった目に見えないコストがあるので数値にとらわれて経営活動を見誤るよりも、品質第一で失敗コストの極小化を狙ったほうがよいという主張です。
ところが現在、何故、品質コストがまた企業で使われだしたのか？
本書はその点について、上場会社への1,043社への質問調査票の結果（366通の回収）を分析し明らかにしていきます。
結論としては、パフォーマンスフロンティアに達してしまった企業においては財務的な視点で品質管理活動への投資額を決定しないと過剰もしくは過小な資源投入が起きやすいからということでした。
パフォーマンス・フロンティアとは、複数の業績次元において、特定の技術、設備、生産方式などを所与とした時に実現可能な最大の業績水準の組合せを意味するものだそうです。
要するに改善が進んでいないうちは、個別最適をやっていても効果が出るのですが、そのうちに、個別最適では効果が出なくなってきますよね。それがパフォーマンス・フロンティアで、複数の部門活動をトレードオフしながら活動を進めないとならないのですが、その時に品質コストといった共通の全社的な指標が役に立つというのです。
他にも色々と勉強になってとても良い本でした。
［49］板倉 稔, 植野 俊雄, 齋藤 謙二郎, 佐藤 光彦：『スーパーSEによるプロジェクトの解明』，日科技連出版社，2003年．
この本には、プロマネの現場が描かれています。
初めに「物語」で描かれ、続く章でそこで挙げられたポイントを一つ一つ解説していくという形式をとっています（『サラサラの組織』の本と同じ手法ですね）。
品質については、上流で取ることと、お客様の目線で考えることの重要さが強調されています。
以前、板倉さんと話していた時に「テストは大切な技術です。だけど、テストで品質が取れることを強調しすぎると安心しちまってだめなんだな。だから、最近のテスト偏重の流れが気にいらねえんだ」って言っていたことを思い出しました。
テストもまた、銀の弾丸や魔法の杖ではないことを具体的に分かりやすく伝えていくこともし続けないとならないんでしょうね。
［50］日経エレクトロニクス・ブックス：『欠陥ゼロのソフトウエア開発』，日経BP社，1995年．
IBM Systems journal, Hewlett-packard journal, IEEE Software, Computerの各誌に掲載されたクリーンルーム関連の論文がまとめられています。
特に、クリーンルームを導入する際のポイントについて、初期導入、本格導入、高度導入のそれぞれについて、
・ 管理とチーム作業
・ ユーザとの関係
・ 増分開発
・ システム仕様定義
・ システム設計と実装
・ 正しさの検証
・ 統計的テストと信頼性の保証
・ 工程の改善
の局面ごとにまとめられた表があるのですが、参考になりました。
ところで、Harlan D. Millsの「構造化とオブジェクト指向を統合したボックス構造化手法」の今後の課題のところに、
現在のボックス構造化理論は、順次処理システムの設計と検証に対応している。最新の研究で、ボックス構造化手法を並列処理システムの設計と検証まで拡張した。しかし、リアルタイム・システムの開発の複雑さを完全に扱えるようにするためには、さらに研究が必要である。
とありました。この論文が書かれた1993年から15年経っているので解決されているのでしょうか？
本の紹介は、「本棚２」へ続きます。
その他
［１］ドキュメントシステム：『
謎のMS‐DOS―彷徨えるパソコンビギナーの羅針盤』，オーム社，1992年．
この本が出版された1992年は、Windows 3.1が発売された年ですが、ディスプレイの解像度が低かったこともあり、巷では未だ、ファイラから直接アプリケーションを起動するといったことが多かったような記憶があります。
パソコン通信もWTERMなんかを直接MS-DOSから起動して巡回していたような気がしますし。
ですからMS-DOSの本としては最後に買った一冊なんですね。
他のMD-DOS本は捨てて残っていないのですが、未だにこの本だけは割と手の届きやすいところにおいてあるのは「ピルモちゃん」という登場人物のせいかもしれません（笑）。たま～に、MS-DOSコマンドを叩く必要ができた時役に立っています。
［２］結城浩：『
数学ガール』，ソフトバンククリエイティブ，2007年．
数学（特にオイラー）が好きな人はきっと楽しく読めると思います。
学生時代を終えて早20年以上経ちました。私自身、それでも数学は仕事に使っている方かと思うのですが、この本に書いてあるような、数列とか母関数による証明といったパズルや、ミステリーを解く的な楽しみとはご無沙汰です（笑）。
ということで、数学のおもしろさをあらためて思い出させてくれた一冊なのでした。
この本は、学術研究の実態（いわゆる象牙の塔）の話からはじまり、DNAの発見、分子生物学、動的平衡、そして、時間を加味した生命観で締めくくられます。そして不思議なことに、コンピュータや組織作りにも応用できそうな話なんです。
たとえば動的平衡の本質である「絶え間なく壊され続けられながらも、もとの平衡を維持することができる」については、いつの日か、そういったシステムを作ることができる日が来るのかと夢みます。
そして、最後の「時間を加味した生命観」というのは、「一部を破壊したDNAを胚に戻すことで、生命活動に重要なたんぱく質を生成できないようにしたマウスは、その重要たんぱく質を作ることができないにもかかわらず、他のマウスとなんら変わらず元気に育つ」という話なのですが、それは、受精してから、それぞれの個体は進化と言う過程を経て生まれてくるからではないか、つまり遺伝子欠損があってもその進化の過程（受精してから生まれてくるまでの過程）で欠損が埋め合わされて、適応したかたちで生まれてくるからではないかと書かれています。
ここを読んで思ったのが組織に対しても同じことがいえるのではないかということです。
例えば会社と言うレベルでみると、確かにトヨタはすごい会社ですごい仕組みがあるかもしれないけれど、それは時間をかけて適応させながら作りこまれたものであって、その結果だけを別の会社に移植しても決して上手く機能しないし、逆に、そのすごい仕組みがなくても別の仕組みで順調に成長している会社もありますし……。
自分は、改善活動や問題解決をするときに、現状の把握やベンチマーキングをしてきたけど、それだけ（瞬間をとらえるだけ）では不足していてもっと「時間」というファクターを加味して物事を観察し、良くしていかないといけないなぁと思いました。
そこには、「その結果にいたる時間の流れを凝縮させる力と、それを再現させる力が必要」なんだろうと思いました。
書名は「マネジメントシステムの審査・評価に携わる人のためのTQMの基本」と長いのですが、シンプルに「ＴＱＭの基本」とした方がすっきりするし内容と合っているように思います。というのは、審査に携わらない人でも本書に書かれているレベルのTQMの基本についてはしっかりと理解しておいた方が良いと思うからです。
もちろん、石川馨が書いた品質管理の本をじっくり読むのも勉強になるのですが、こういった本で一通り基本を学ぶのもいいと思います。特に中條 武志先生が書かれた第１章の「ＴＱＭのフレームワークと基本原則」が素晴らしいです。
また、この本を読むと、設計、製造、生産には厚いけど、企画や顧客データの分析はまだまだ抜けているなぁということが分かります。それとソフトウェアへの適用の話も……。
この本は、2003年7月に日本工業調査会から報告された「負のスパイラル」に対する問題提起に対する筆者の回答を雑誌連載をまとめたものです。 「負のスパイラル」が発生する原因の代表的なものとして
① 組織側の認証さえとれれば良いという考え方
② 審査側の安くて簡単に認証すれば儲かるという考え方
③ 審査側としては、審査員の質の低下
④ 質の良い審査員の採用・維持・確保が困難になる
⑤ 組織側からは審査コストに見合う利益が必ずしも得られていないという評価
が挙げられているのですが、これらは今でも消えていないような気がします。
ということで、この本は、ISO9001を嫌々やっている人に是非読んでもらいたい一冊です。
どうせやるなら楽しく、かつ、お客様のためになるやり方をしないと時間の無駄ですからねー。
初版は１９７９年ですが内容は少しも古くなく、現在でも役立つ話ばかりです。
表題にある「忍術でもええで」は、上役（幅役）が部下に何かを命ずる時には「目的だけを伝えて、手段は本人に任せなさい」ということです。 そうすることで責任感や創造性を引き出し、部下からアイデアがでてきたら「ほう！それはいい考えじゃ」とまずはほめて調子に乗らせ、能力をどんどん発揮させるようにするといいという教えです。 今で言うと、WhatとHowの関係でしょうか。
ところで、ブレイクスルー思考（日比野省三）という方法がありますが、西堀流では「考えてみりゃ」という言葉で同じことを言っていました。
知識に切迫感さえでてきたら自動的に知恵が出てくると思うだろうが、もう一つ足りない。それは、いわゆる“考えてみりゃ”という言葉で表される。この“考えてみりゃ”ということは、今まで考えていたような習慣などを一度全部棚上げして、コトの本質というものを考えてみることである。
これは、Why（上位にある根本の目的）を考えようということでしょう（もちろん体系立てて整理され、ブレイクスルーを実現するためのシステムになっているところが日比野 省三のすごいところです）。
薄い本なのですが至るところに知恵があり実に勉強になりました。
［７］富士ゼロックスQC研究会：『疑問に答える 実験計画法問答集』，日本規格協会，1989年．
実験計画法は、因子・水準の選定さえ終われば、あとは、EXCELなどのツールを使って直交表に割り付け実験結果をEXCELシートに書き込めば、あっという間に結果が得られるものです。
でも、それだと応用が利かないんですよね。元々、社内教育用のテキストだけあって、本書では誰もが疑問に思うことについて易しくとことん解説しています。ソフトウェアのテストでもパフォーマンスチューニング問題などで実験計画法を使う際には役に立ちます。
［８］田口玄一：『研究開発の戦略』，日本規格協会，2005年．
田口玄一博士が、品質工学の定義を試みている本です。生産性に対する考え方……どうすれば皆が幸せになるのか……から始まって、品質の定義、ノイズについてと話は進みます。第2章以降は数式が難しくてちょっと難解なのですが、式は飛ばして地の文だけ読んでもおもしろいです。
私の持っている本は、出版された2005年の品質工学研究大会で買ったので田口先生のサイン入りです（ちょっと自慢……笑）。
［９］イアン・スチュアート (著), 青木 薫 (翻訳)：『2次元より平らな世界』，早川書房，2003年．
イアン・スチュアートという数学者が書いた本です。教科書のようなものではなく、高校生くらいの人を対象に物語的に最新の幾何学に親しんでもらおうとかかれたもののようです。
1884年のイギリスでE・アボットという人が『二次元の世界』という本を書きました。その本は、「二次元の世界の住人からみた三次元世界」といった内容だったそう（残念ながら未読）なのですが、この本はその続編にあたります。
ただし、２次元世界に住むヴィッキー・ライン嬢が旅する幾何学の世界は、３次元にとどまらず、フラクタル、トポロジー、射影幾何学と遠近法、有限射影幾何学、変換群と不変量、非ユークリッド幾何学、確率関数空間（量子論）、相対性理論、重力の幾何学（ホーキング）、ブラックホールとホワイトホールを使ったタイムマシン、ファインマンダイアグラムとペンローズ・マップ、統一理論、ひもと膜の幾何学まで幅広くなっています（要するに120年間でそれだけ幾何学が進歩したって事ですね）。
私がこの本を読んだきっかけは直交表を作る時に必要となる「有限射影幾何学」の概念を簡単に伝えられるようになるといいなぁと言うものでした。
で、それは、この本での射影の説明である
平行な線路は地平線上で一点で出会うように見える
といった文章を読んだときに一歩前進したのでありました。
つまり、「有限な格子でできた幾何学から、さらに射影することで平行ベクトルを取り去ったら直交したベクトルしか残らない」と、直交表の作り方を言葉で書くとそういったことです。
後半はちょっと無理やり（詰め込み）感が強いのですが、雪の結晶の縁の次元が1.26186……つまり、フラクタルの次元って整数じゃないんだ……といったことに驚いたり、なかなか楽しい本でした。
［10］梅田望夫：『ウェブ時代をゆく』，筑摩書房，2007年．
『ウェブ進化論』の完結篇です。
この本の中に本当に自分がやりたいことを探そうという話があるのですが、そこで筆者は、自分の志向性について、
ある専門性が人から頼りにされていて、人からの依頼で何かが始まり急に忙しくなるが、依頼が無いときは徹底的に暇であること。
というように説明しているのですが、結構私自身の志向性（本当になりたい姿）と近いなぁと思いました。 筆者はまた、
「エリート」でもなく「大衆」でもない人。。人口の割合で行くと10%位の「あるレベルの知を持った人たちのサロン」がWebではないか。
……略……
良く生きることへの意欲を持ち何らかの分野で秀でた人が、「パブリックな意識」を強く持ってそこに関与していくこと。
といっています。
ウェブに対して「つながった脳」という感覚を持てるかどうかというのがウェブ時代をゆくためのキーポイントのような気がしました。
そのための情報発信の仕方、コミュニケーションのとり方が重要なんだろうなとあらためて思いました。
［11］司馬正次：『ブレークスルー・マネジメント』，東洋経済新報社，2003年．
筆者である司馬正次は2002年にデミング賞本賞を受賞され、2004年に本書で日経品質管理文献賞（デミング賞とともに表彰される）を受賞されています。
筆者は、問題解決には、Control（維持管理）とReactive（現状対応）とProactive（未知探索）の3つのパターンがあるといいます。
Control（維持管理）は、生産工場の現場で直行率（市場に出せる良品の率）の管理や、自分たちの活動で言えば残業時間を月20時間以内に収めよといった活動に当たります。右下のグラフで書いたようにパフォーマンスやバリューを一定に保つ活動です。
Reactive（現状対応）は、いわゆる改善活動でPDCAを回すものです。
筆者は、KJ法のW型解決モデルに、問題解決のVを加えた、WMモデルを提唱しています（KJ法＋PDCAを一枚の図に収めたもの）。
そして、Proactive（未知探索）が、パラダイムシフトを起こして、次の波に乗っていく活動に当たります。同じことを続けていても時代は変わっていくのでパフォーマンスは落ちていく、したがって、次の波に乗っていかなくては組織は解体してしまうと言うのです。
本書では、パラダイムシフトを起こして組織活動をブレークスルーするためには具体的にどのようなマネジメントをしたらよいのかについて事例を挙げながら分かりやすく解説しています。
［12］田口玄一監修：『品質工学便覧』，日刊工業新聞社，2007年．
2007年11月に、品質工学会15周年を記念して出版された品質工学の便覧です。
第１編と第２編が、学会誌に発表された田口先生の論文の要約で、第３編が事例集、第４編は、田口先生との座談会の収録という構成です。ソフトウェアのテストについても載っています。
座談会のところは、田口玄一博士の言葉で品質工学の歴史を伝えていて興味深いものでした。
学会誌を読み返す手間が軽減されるので「便覧」という言葉はぴったりですね。目次はこちらに載っています。
［13］畑村洋太郎：『みる わかる 伝える』，講談社，2008年．
「失敗学」で有名な畑村先生の「観察力、理解力、伝達力を鍛える本」で、大切なことがとてもわかりやすく書かれています。
一番、気に入ったのは「ベストの伝え方はむしり取らせる」という章で、そこには次の文章が書かれていました。
このように本当に知識が欲しくなるときに、その人の頭の中には知識を獲得するための受け入れの素地ができるのだ。
伝える側の多くの人は「伝え方をなんとかすれば」という「レバ」の視点で考えている。でも実際は、相手の頭の中に受け入れの素地がつくられて知識を欲しがる状態にならないことには、知識がきちんと伝わることはない。受け取る側が知識を「受け取りたい」と思う状態をつくることが大切なのである。「レバ」ではなく「タイ」の視点で考えなければならないのだ。
……略
だからもしあなたが伝える側だったら、最初に考えることは、知識をむしり取れるような状況を作ることなのである。
もちろん、この後に、伝える側のテクニックの話も書いてあり、それはそれで素晴らしい内容なのですが、「受け取りたい」と思う状態を作ることは本当に重要だよなぁとあらためて思いました。
［14］ロバート・メンデルソン (著), 弓場隆(翻訳) ：『医者が患者をだますとき』，PHP研究所，2008年（原著は1979年）．
診療・研究・教育の三つの分野で業績をあげ、数々の栄えある賞を受賞したアメリカ医学会の重鎮とも言える医師が1979年に書いた痛烈な医療批判本で、30万部を超える大ベストセラーになったそうです。
現代医療の9割は不要と言い切り、その理由として、
・ 研修医に研修をさせるために不要な治療を行っている
・ 製薬会との癒着
・ 健康補助食品業界との癒着
・ 無意味な定期健康診断
・ 効果よりもリスクの方が高い予防接種
などを例に挙げています。これらは最近は改善されているとは思います。
ただし、帝王切開で生むことや、病院で面会謝絶のまま亡くなることへの人間性の面からの批判など今でも通じる話も多いです。
また、患者を診ずに、血液検査や心電図の数値だけをみて医療方針を決めたり治療に当たる、、、といった話は、どこかの業界のメトリクス信者や統計信者にも通じるものがあるかもしれません（自分も気をつけなくてはならないなぁと思いました）。
医療といえば、最近、ずっとチェックしているWebページがあります。 それは「日々是よろずER診療」というページなのですが、ここでは、時間外診療の中に潜む「地雷」……すなわち、誤診……にスポットがあたっています。
医師の悩みが少しだけわかるような気がします。
［15］野矢茂樹：『入門!論理学』，中央公論新社，2006年．
「～でない」「かつ」「または」「ならば」の意味を学ぶことができます。
そんなの日本人なら誰でもわかると思うと思うのですが、例えば、最初の「～でない」にしても実は難しいんだということが良くわかります。
どうむずかしいのか。
例えば、二重否定というものがあります。
それは「『太郎には盲腸がない』ことはない」といったように2重に否定する文章（上の例なら「太郎には盲腸がある」という意味になる）なのですが、この場合普通に考えると「二重否定＝肯定」（not (not A) = A)になりますが、必ずそうなるかというと、そんなことはないよということが書かれています。
「『ここは富士山ではない』ではない」という文章があったとき、ここは必ず富士山でしょうか？ 富士山であるともないとも言える曖昧な場所では富士山と言い切ることはできません。
そんなことが次第に難しくなりながらたくさん書いてある本です。仕様書を読んだりテスト設計をしたりする時に役に立つかもしれません。
［16］デビッド・ホイル (著), 角田陽子(翻訳), 住本守(監訳)：『品質マネジメントの核心』，日本規格協会，2008年．
David Hoyleはイギリス人で、ISO9000のコンサルタントなのですが、私が知っているのは、2001年に出版された『ISO9000:2000監査へのプロセスアプローチ』という本です。薄い割に本質を突いていてISO9000の2000年版改定の意図と対応の指針になりました。
そこで、この本が出ることを知ってAmazonで予約して買ったのですが、、、読むのに一月以上かかりました。
一つには、堅い本ということもあるのですが、内容が濃くて考えさせられるところが多く少しずつしか読めなかったのです。
また、監訳者の住本守の訳注も素晴らしく、両方を読んでは「う～ん」と考えるの繰り返しでした（訳注は20しかないのですが、その20が考えさせられるポイントだったりします）。
例えば、本文で、David Hoyleが
品質マネジメントがゴールマネジメントとするならば、そこにはリーダーシップ、戦略、計画、財務、マーケティング、販売、人的資源マネジメント、エンジニアリング、教育、訓練などを網羅するモデル及び技法があると期待するだろう。もしくはそれがリスクマネジメントとするならば、そこにはリスクアセスメント、確率論、管理手法論、問題解決を網羅するモデル及び技法があると期待するだろう。
といい、訳注で住本守が、
・ 品質マネジメントの視点
組織にとっての品質マネジメントとは、価値を生み出し目標を達成するという組織の存在意義が根本に存在し、本質的にはゴールマネジメントでなければならない。そのゴールとは、顧客及びその他の利害関係者の満足を通しての組織の成功であろう。ただし、組織運営にはそれに付属するリスクが存在する。このリスクは組織活動のあらゆる側面、戦略策定及びゴールの設定から製品の実現プロセスに至るすべての領域で存在している。 組織がゴールを達成し成功を収めるには、これらのリスクに対し十分な対策を講じる必要があり、品質マネジメントは、ゴールマネジメントかあるいはリスクマネジメントかの二項対比で捉えるべきではない。成功を収めている組織では、ゴールマネジメントとリスクマネジメントが一対をなして取り扱われているはずである。 そもそも、計画するということは、目標を実現するために必要な事柄を整理し、その実施の時期や方法をあらかじめ決めることであり、この作業の中には、何かを実施したときの結果の予測と同時に、実施に際しての阻害要因や上手くいかなかった場合の対応が考慮されておかなければならない。 構築した品質マネジメントシステムが実質的にはよりゴールマネジメントに重点を置いたものになるかは、組織の置かれた状況に依存している。持続的な成功を追及する組織にあっては、組織の信用にかかわる致命的な失敗は絶対に避けるべきであり、その基礎固めとして品質マネジメントシステムの初期の段階では、リスクマネジメントに重点を置いて考えるのが良作と思われる。
と応ずるといったものです。
このようなページが続くので、その度、本をいったん閉じて電車に揺られながら考えて、また続きを読むの繰り返しで、まぁ、ほとんど頭には残っちゃいないわけなのですが(^_^;)、訓練にはなったかもという感じです。
［17］増井雄一郎, 天野龍司, 大河原哲, miko：『PukiWiki入門』，翔泳社，2006年．
Pukiwikiはヘルプや解説Webページが充実しています。しかし、ヘルプは知っている機能のシンタックスを探すには良いのですが、全体を知るには時間がかかります。これまではどうしていたかというと、他の人が作られたページを[編集]ボタンを押して中身をテキストエディタにコピペして修正なんてことをしていたのですが、それだと使われていない機能については使えないといった限界がありました。
たとえば、太字にするには、どうしたらいいんだろう？とかね。いや、Googleで"pukiwiki 太字"とすれば一発でわかるのだけれど、「太字」そのものの機能があるかないかはこういった入門書を読む方が時間の節約なので。
と、言い訳っぽい話が続きましたが、結論から言うと読んでよかったです。リンクのところ、特にWiki名に「/」が入ったときの階層化の仕組みなどが分かったのがすっきりしました。
ということで、買って損はないと思いますが、読んだらできることが増えるかと言うとほとんどそんなことはなく、逆に言うとどんどん書き込んで慣れることが大切かと思います（←ありきたりな結論に）。
［18］近藤良夫 ：『QC百話』，日本規格協会，1998年．
本書の副題は「野外工学のすすめ」なのですが、筆者の近藤良夫（1924年2月17日生）は、現在でも、2009年2月18日～3月10日の「品質管理研修コース」の主任講師を勤めるようで最前線に立って活動していらっしゃいます。「品質管理研修コース」は、（財）海外技術者研修協会による開発途上国の製造業に従事する管理者の品質管理能力向上を図ることを目的としたもののようで、非常に意義深いものだと思います。
本書には、様々な知恵が読みやすいエッセイの形で提示されています。それら一つ一つを仲間と議論するととても良い職場に変わるんじゃないかなと思いました。
［19］富士ゼロックスKDI (著), 野村恭彦 (著), 仙石太郎 (著), 荒井恭一 (著), 紺野登 (著), 荻野進介 (著), 野中郁次郎 (著) ：『サラサラの組織』，ダイヤモンド社，2008年．
本書の著者の一人である、仙石太郎は、『ソフトウェアテストHAYST法入門』の「第12章 HAYST法の組織的展開」を執筆した人で、本書では、「第2章 ドロドロの組織」を担当されました（サラサラとかドロドロは、血と知をかけているんですね）。
本書の内容を一言で言うと、
組織を変革する「変革リーダ」は特別な人じゃなくて"あなた"です。
といったものです。
まず、「第1章 サラサラの知恵」では、KDIのリサーチャーの野村恭彦が、実在の人物をモデルとした「物語」を通してサクセスストーリーを読者と共有し「7つの知恵」を授けます。
作家が書いた小説ではないので、ちょっとコテコテのところ（たとえば、主人公の名前が麻丘沙羅……アサオカサラだったり）もあるのですが、たとえば、沙羅が、役員に噛み付く次の部分などいいなと思いました。
役員：「コミュニティをいろいろ立ち上げるのはいいが、そのアウトプットは何か？ 誰がコミットするのか？ また、アウトプットの出ないコミュニティはどう閉じるのか？ こういったことをしっかりと計画しておかないとだめだよ」
沙羅：「コミュニティの本質をご理解いただけてなく、残念です。コミュニティの価値はアウトプットではなく、インプットです。最先端の知識、新たな知識を必要とする社員が、その知識にアクセスするための媒介となるのがコミュニティです。たとえば経験入社の社員がいたとして、最初の1ヵ月でどれだけこの会社の仕事のやり方を理解することができるでしょうか。各分野のキーパーソンが誰で、どんな部門がどんな知識を持っているかなど。もしコミュニティが無ければ、こういった知識から完全に切り離されてしまい、経験入社社員は、他社で培った能力を十分に発揮する前に、1年かけて少しずつ会社のことを理解しなければならないでしょう。つまり、コミュニティはアウトプットを出すから必要なのではなく、コミュニティは存在することに意義があるのです。コミュニティにアウトプットを求めて、その立ち上げに失敗した企業は数知れません。アウトプットが欲しいなら、プロジェクトを立ち上げるべきです」
「第2章 ドロドロの組織」では、本音ベースで現状の問題点（ドロドロの組織で各年代の社員が何を思っているか）が取り上げられ、KDIの紹介がされます。89ページからまとめられている「なぜなぜ分析」はなかなかよいです。
「第3章 サラサラの組織」は、実際にKDIが手がけた9つの会社の事例紹介です。人と人をつなぐことの重要性がわかります。
「第4章 これからの企業経営」は、KDIを作った木川田一榮（現在は大阪大学の教授）によるKDI創立秘話と、野中郁次郎×小林陽太郎の対談です。木川田一榮の、
人はコスト（経費）ではない、キャピタル（資本）だ
という観点が重要と思いました。
膠着した組織を何とかしようと考えている方、コミュニティ作りで悩んでいる方は一読の価値ありと思います。
［20］佐藤 竜一 ：『エンジニアのためのWord再入門講座』，翔泳社，2008年．
Wordに対する見方、そしてWordを使った文章の作り方が変わります。
Wordで10ページ以上のドキュメントを書いている人は絶対に買って損はないと思います。Wordの仕組み（スタイル機能など）が分かるとこんなにドキュメント作成がいらいらしなく楽しくなるのかという感じです。
それから、文書作成のルールも勉強になりました。たとえば、「段落区切りの表現方法」。段落区切りには、欧文ドキュメントに良く見られる段落ごとに空行を挟むタイプ。つまり、
あああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ
いいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいい
と、和文ドキュメントの基本である、段落先頭を字下げするタイプ。つまり、
あああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ
いいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいいい
があって、これらを混在させることはしてはいけないのだそうです。これまで意識していませんでしたのできっと恥ずかしい文章形式だったんだろうなぁ
［21］結城 浩：『数学ガール/フェルマーの最終定理』，ソフトバンククリエイティブ，2008年．
ツンデレのミルカさん、ドジッ娘のテトラちゃんに、今回新たに登場した妹キャラの（主人公の従姉妹の）ユーリら数学ガールたちと主人公である僕が織りなす物語です。
全体的によいのですが、なかでも「砕ける素数」の話が一番おもしろかったです。要するに、2, 3, 5, 6, 11, 13, 17,...は整数の世界では素数だけれど、複素数（ガウスの整数）を持ち込むと、
2 = (1+i)(1-i)
3 = 3
5 = (1+2i)(1-2i)
7 = 7
11 = 11
13 = (2+3i)(2-3i)
17 = (4+i)(4-i)
と言ったように、積で表せるもの(2, 5, 13, 17, ...)といった「砕ける素数」がある、そして、どういう素数は砕けるのかについて数学ガールたちとその規則を発見しそのルールを証明するといった話です。
本書では、群・環・体の話も出てくるのですが、折角アーベル群の話がでたのですから、対称性の話など数学の概念が、物理的な世界観を拡大しているといったつながりも書いて欲しかったなぁと思うのは、物理科出身のせいか。
そうそう。直交表と関係深い有限体の話もでてきます（拡大体まではでてこないけどねー）。難しい整数論の本を読む前のウォーミングアップにもいいですね。
ということで、前作同様素晴らしい完成度なので数学好きな方はもちろん、そうでない人もおもしろいと思います。
［22］廣松 渉：『哲学入門一歩前』，中央経済社，2008年．
本書の副題は、「モノからコトへ」でして、「モノからコトを見つける上手い方法」がないかと探索中の一冊なのでした（……という目的にはそれほど参考になりませんでしたが……）。
本書を一言で言えば、Wikipediaの廣松 渉の解説にある、
実体があって関係があると考える物的世界観に対し、関係があってこそ実体があると考える事的世界観を提起した。
という哲学の入門書です。
まえおきに、
本書は、著者がこれまで出した本のうちで最も判り易いかたちにかけていると信じています。
と書いてあるように、予備知識なしで読むことができます。でも、独特の言い回しや漢字の使い方があるのですらすら気軽に読むというわけにはいきませんでした。
さて、内容に入りますが、廣松 渉が否定する「実体があって関係があると考える物的世界観」とは何のことかというと、根底にモノが存在してそのモノとモノとの関係から世界が成り立っているという考え方だそうです。
廣松は、量子論を出して物理的なモノ自体の基盤のもろさを指摘したり、相対性理論を持ち出して、主観－客観という認識関係が成り立たないことを示します。
その後、モノの認識の話に移るのですが、ここで、
「抽象」という手続きによる「概念」形成ということは論理的にみて成立しえない。
という話が載っているのですが、それがおもしろかったので、引用し紹介します。
今、人が概念を抽象によって形成しようと努めているものとする。そこでの作業手続きはどのようになっているであろうか？
それは二段階の手続から成るものと考えられている。第一段において、比較校合する素材的与件たる一群の個物が弁別収集され、第二段において、それら与件群の普遍本質的な規定性がピック・アップされる、云々。──これが「機能的抽象」の手続だというわけである。
はい。科学的方法として、サンプルを集めてきて、それを分別・分類・分析することで本質的な何かを発見するのと私も思っていました。
ところが、、、
だがしかし、謂うところの「第一段」（これは現物を実地に寄せ集めるというより、実際問題としては、当座の概念形成に必要な与件群が記憶その他をも動員して意識野に引出される過程なのであるが）、そこにおいてすでに重大な先決問題がある。
人は、＜犬＞という概念を形成しようと試みるさい、自家の飼犬ポチ、隣家の飼犬ジョン、……等々の個体群を“集め”ることであろう。が、ミケ、タマ、等々の個体は初めから除外してかかる。ましてや、＜犬＞という概念を抽象しようという今の場合、机とか石とか、木とか草とか、……こういった多数のものどもは与件群に入れられない。
おぉ。確かに！！
では、一体なぜ、ポチやジョン……を比較校合の素材的与件として集めるのか？ まさに、それらは犬であるから。また、ミケやタマや、机や石や草や木……などを排除するのは、まさに、それらは犬でないから、であろう。
言われてみれば……。
ということは、人は＜犬＞という概念を今から抽象・形成しようと企てているのであるにもかかわらず、何は犬であり何は犬でないかを与件収集の場面ですでに知っているということを意味する。ポチ、ジョン……を集め、ミケ、タマ、机、石……等を除外するさいの、判別基準は何か？ まさに＜犬＞という概念、つまり、今から形成すべき概念を事前に知っているということにならないか？ もし、そうなら、なにもいまさら、＜犬＞という概念を抽象などという手続で形成する必要もあるまいではないか！
この後、もう少し精緻にこの問題の考察が続き、外延と内包の話にまとまり結論としては、
論者たちは、概念形成は抽象という論理的手続によっておこなわれると称し、第一段の作業工程として、外延群の集拾をを云々する。が、実態においてはサンプルの集拾しかおこなわれないのであって、しかもそのさい、選別・集拾の基準として“概念態”を事前に所持している。そして、自覚的概念形成と称される手続はたかだかこの既知の“概念態”の陶冶（みがきあげ）にすぎないのだが、当の“概念態”たるや、今から形成されるという触れ込みの「概念」と、不明瞭ではあれ実質的には既にほぼ同じものである。“概念態”が直感的に既知とされるとき、今から抽出するという触れ込みの概念が実質上は既知という論件先取の事態となってしまっている！
議論は、さらに「内包抽出」の行程に進み、そこもとてもおもしろいのですが、読むほうも疲れていると思うので結論だけ引用すると、
普遍的本質なるものは、帰納的抽象といった順次的手続によってではなく、直覚的に観取される。
なのですね。
最後の章では、これらの考察を受けて、「対象→内容→作用」というつまりは、モノがあってコトが生ずるという認識ではなく、「所与→所識」によって、つまりは、事的世界観を展開するのですが、本書ではその詳細までは至れずでした（廣松渉は1994年にお亡くなりになってしまったので完成させることはできなかったようです）。
［23］高橋 昌一郎：『理性の限界』，講談社，2008年．
副題は、「不可能性・不確定性・不完全性」となっていて、それぞれ、「アロウの不可能性定理」、「ハイゼンベルクの不確定性原理」、「ゲーテルの不完全性定理」に対応しています。
ものすごーく、頭がいい人（もしくは神様でもいいけど）がいたら、何に対しても必ず答えがあると思いがちだけど、実はそんなことは無いんだぞ、と、足元を掬われる本です。
パネルディスカッション形式で話が進むので分かり易いし、すっごくおもしろいです。
［24］エドワード・デ ボーノ (著), Edward de Bono (原著), 川本 英明 (翻訳) ：『会議が変わる6つの帽子』，翔泳社，2003年．
昨年、『ソフトウェアテストの基礎』を翻訳した際に、原著が引用していた本です。それは、
もし、たまたま見た白鳥がみな白ければ、「すべての白鳥は白い」という、大胆な発言ができるのだろうか？
といった部分で、私が、「すべての白鳥は白い」といった部分の訳を変えた方がよいのでは？と言ったら、湯本さんが、「『会議が変わる6つの帽子』の翻訳でもそうなっているのでこのままで行きましょう」と教えてくださって、助かったのでした。
本の要約は、簡単で、要するに「会議の時には、情報(白)、感情(赤)、消極(黒)、積極(黄)、創造(緑)、戦略(青)の帽子を全員が同時に同じ色をかぶり変えながら進めること、つまり、議論する視点を揃えて会議のテーマを掘り下げることが大切」と、それだけです。
実は、湯本さんに「どこがいい本なの？」と豆蔵の会議室で訪ねたときに「6色の帽子をかぶって、白なら事実を提示しあうといった感じに会議を進めていく方法なんだけど、全員が同時に同じ帽子をかぶるってところがミソで、まぁ、読んでみてください」って言われたのですが、本当にそれだけのことなんですが、たぶん、すごいメソッドです。また、仮にこのメソッドが、全員が本を読んでいないと上手く使えないとしても、この本に載っている解説を読むだけでも本当にためになります。たとえば、
建設的な意見より批判的な意見を述べる方がずっと簡単である。椅子をデザインするのは難しいが、あれこれ批判することは、それよりずっとやさしい。例えば、簡素な椅子であれば、時代遅れであるとか、すぐに飽きてしまうなどと批判できる。逆に椅子が凝った造りであれば、趣味が悪いだの仰々しいだのと文句をつけられるかもしれない。つまり、目の前にある物とは異なる概念を故意に導き出せば、批判は簡単にできるわけだ。ただし、あなたがその気になればの話だが。
といった金言は（他の人から別の言葉で聞いたことがあるだろうけれど）忘れがちなのでためになります。
さて、それでは、ここで、JaSST'08Sapporoの出荷判定ライブをデ・ボーノ博士の6つの帽子を使うとどんな感じになるかやってみましょう（遠い記憶を基に書いているので内容は若干異なります）。
★
1. 「青い帽子」（空、冷静、超越：プロセス全体を構成する視点）で会議で決めるべきことを明確にする。
司会： それでは、来年の「さっぽろ雪まつり」をターゲットにしたメトリホテル札幌の旅館予約システム出荷判定に向けた「担当者レベルでの事前打ち合わせ」をはじめます。1年前に要求分析を始め、今回は、ベトナムへのオフショアも行いました。まずは、それぞれの立場から自由に状況を説明していただき、その後、メトリクスの確認、出荷判定会議までにすべきことの明確化を実施したいと思います。この進め方でよろしいでしょうか？
全員： 了解です。
2. 「赤い帽子」（怒り、情熱、感情：思ったままの感情的な視点）で自由な意見を出し合う。
開発部長： 東です。洞爺湖サミットに向けたシステムということでスタートしましたが、間に合わず、悔しい思いをしました。しかし、メトリホテル予約システムに軌道修正し、初めてのオフショアも実現し、多少の問題は残っているようですが、なんとかここまで漕ぎ付けました。お客様も待っていることですし出荷判定合格と行きたいものですね。
品質保証部長： 三浦です。いやいや。セキュリティに問題が残っていると小耳に挟みましたよ。大問題につながりかねないキズを残したままの出荷は認められませんな。慎重にいきましょう。
開発内テスト担当： 平本です。あとで詳しく説明しますが、大詰めに来ています。必死になって頑張っているところです。ベトナムのホーさん、状況はどうですか？
オフショア先： ホーです。テストのやり直しが発生して現場はちょっとうんざりしています。でも、初めての試みなので、精鋭メンバーを集めて頑張ってますよ！
3. 「白い帽子」（中立、客観的：事実と数値(データ)への視点）でテーマに関するあらゆる情報を出し合う。
司会： それでは、みなさん、白い帽子をかぶって客観的に状況の説明をお願いします。まずはテスト担当の平本さん、状況はいかがでしょうか？
開発内テスト担当： はい。こちらは、信頼度成長曲線です。ゴンペルツに当てはめると収束率は98.5%まで来ています。現在は、予定していたテストの99%を終え、先日発生した問題に対する回帰テストをオフショア先で実施していただいているところです。
司会： オフショア先の状況はいかがですか？
オフショア先： 実は一昨日、回帰テストの連絡が来て、昨日スケジューリングが終わったばかりです。計画としてはあと4日あれば回帰テスト完了の予定です。
司会： セキュリティの問題とは？
開発部長： 実は、顧客リストを必要最小限の開示に留めるといった機能に問題があり、現状はシステムを操作できる人であれば顧客リストを画面上に表示できるようになっています。もちろん、印刷はできませんし、システムは奥の部屋にあるので顧客がそれを目にすることはありません。
4. 「黄色い帽子」（明るい、積極的：肯定的な側面(プラス面)への視点）で計画や提案を引き出す。
司会： なるほど。100%問題無しと言ったわけではなさそうですね。それでは、みなさん、黄色い帽子をかぶってプラスな側面に目を向けて前向きな提案をお願いします。
開発部長： セキュリティの問題については、運用でカバーするという方法が取れると思います。
品質保証部長： 顧客との了解がとれればの前提ですが、運用は一つの案としてＯＫでしょう。
開発内テスト担当： それでは、私の方は、出荷判定会議までにテストをやりきる方策を考えます。
オフショア先： 時間が短いのですが、もう一セットのシステムとオペレータを追加すればなんとかなるでしょう。
5. 「緑の帽子」（草木、植物などの“成長”：創造性と新しい考え方への視点）で新しいコンセプトを考える。
司会： 運用でカバーという案が出てきましたが、それで当初のメトリホテルに対するコンセプトは守れるのでしょうか？ もし、守れないなら新しいコンセプトを緑の帽子をかぶって考えてください。
品質保証部長： セキュリティを守るため、従業員ごとにアカウントを作り、ログイン記録を残すというのはどうでしょうか？
開発部長： それなら、簡単に実現できるし、そうだ、ログインした直後にログイン名と共にセキュリティへの注意を促すメッセージを出すくらいならすぐできるぞ。
オフショア先： その位のテストなら1日あればできますよ。
開発内テスト担当： あと、背後に人が周れないところにシステムを設置してしまうと言うのも手かもしれませんね。ローテクですが。(^^;)
6. 「黒い帽子」（生真面目、思慮深い：警戒と注意を促す、弱点(マイナス面)への視点）で使い物にならない提案などを吟味する。
司会： 今度は、黒い帽子をかぶって注意深く提案の問題点を指摘してください。
品質保証部長： リリース直前の今となっての仕様変更をお客様はどう思うだろうか？
開発部長： 確かに、これまでオペレータへの説明会も開きましたし。そこは心配ですね。
7. 「青い帽子」（空、冷静、超越：プロセス全体を構成する視点）で全体的な地図の完成予想図を描き、「どのルートを選択するか」戦略を練る。
司会： それでは、本番の出荷判定会議までにやらなければいけないことをまとめましょう。青い帽子をかぶって全体を俯瞰しながら意見を述べてください。
品質保証部長： 営業部長とコンタクトを取って、まずは、お客様と提案について話し合ってくるよ。開発のほうは、案どおり進めておいてもらえるだろうか？
開発部長： 了解した。
8. 「赤い帽子」（怒り、情熱、感情：思ったままの感情的な視点）で情緒的な問題が無いか確認する。
司会： 現場である、オフショア先のホーさん、それで構いませんか？ 赤い帽子をかぶって自由に述べてください。
オフショア先： ひょっとしたら無駄な作業になるかもしれないと言う思いはありますが、お客様の意思確認と並行作業をしないと間に合わないと言うことも理解しています。なんとか、現場を説得できると思います。
司会： みなさん、それでは出荷判定までの進め方はこれでＯＫですね？
全員： 頑張りましょー。
# 今回書いた帽子の使い方（会議の進め方）はあくまでも例です。全ての帽子を使わなくてもいいし、その辺は工夫次第というところです。
★
まぁ、こんな上手く進むことは難しいと思いますが、それぞれがバラバラな視点で意見を述べ合うより、ずっと、上手くいきそうな気がします。
［25］エリヤフ・ゴールドラット (著), 岸良 裕司 (監修), 三本木 亮 (翻訳) ：『ザ・チョイス』，ダイヤモンド社，2008年．
日米同時発売と言うことで、『ザ・ゴール』のときとはエライ違いです。
経営者向けの啓蒙書という感じで、他著のような目から鱗の話はでてきません。
父娘の対話で進むこの話は、
何事においても、
・人はもともと善良である
・すべての対立は解消できる
・ものごとは、そもそもシンプルである
・どんな状況でも飛躍的に改善できる
・すべての人は充実した人生を過ごすことができる
以上の信念を持って、因果関係を見つけて対処すればよい
ということを教えてくれるのですが、それは、誰もが使いこなせるレベルの方法論ではなく（少なくとも私にはそう思え）、むしろ、TQMの方が現場の問題解決には役立つのではないかと思いました（といった意味で経営者向けの啓蒙書と書きました）。
ちょっとおもしろいと思ったのは、コンフォートゾーンの定義の話。日本語で一般には「居心地がいいと感じる場所や状況のこと」。ただし、そこにつかまっていると大成功を収めることはできないことから、"ぬるま湯"という意味に近い言葉ですが、エリヤフ・ゴールドラットによる再定義は、
人が、原因と結果に関して十分な知識を有している領域、また、ある行動に対してどのような結果が予測されるか十分な知識を有している領域
＊ こうした知識は、状況に対して効果的に影響力を及ぼすことができる能力にもつながる。ゆえに、コンフォートゾーンが支配力、影響力に関連づけられることがあっても、それは当然のことと考えられる。
といったもので、さらに、
この定義に従うと、人をコンフォートゾーンの外に追いやるシナリオは以下のとおりとなる。
①ある望ましい結果に達するために、特定の行動を起こすことが促される（あるいは強制される）。②促された当人は、関連する原因と結果に関する自らの知識に基づいて、促された行動では、望まれる結果を達成することはできない、あるいは達成する可能性が極めて低いと確信する。
話はさらに、経験から確信している場合とそうでない場合に分かれ、それぞれの対応方法が説明されているのですが、色々な場面で適用できそうな話なので、意識して使ってみようと思いました。
本の紹介は、「本棚２」へ続きます。