HAYST法

 

「人間の側面からみたソフトウェアテスト」についての本です。

ワインバーグはこの本で繰り返し、「テストは情報を得るために実施するものである」と書いています。例えば、

　キーを打つかどうかにかかわらず、何らかのアクションに影響を及ぼす情報を求めるものでなければ、テストとは呼べない。

といったようにです。

そして、その情報の質については、例えば、第10章の「テストはキーを打つだけではない」の「よくある間違い」に書いてある、

4. カバレッジテストが何かをテストした証明になると思っている

コードのすべての部分を何らかのテストでふれたことを証明できたからといって、その部分が完全にテストされたとはいえない。また、コードをすべてカバーしたからといって、すべての機能を完全にテストしたとはいえない。そういえるためには、テストの関係性と包括性を分析する必要がある。別の言葉でいえば、考え方を分析する必要がある。

や、第16章の「コンピュータを使わないテスト」の「テスト担当者は貴重なレビューアになる」に書いてある、

1. 開発者にありがちな思考パターンの欠点を観察することで、より良いテストを作成できるようになる。
2. 早い段階から仕様書をレビューすることで、テスト計画のスコープを早く決められる。
3. 設計を熟知することで、より迅速にバグを発見し、その絞込みに協力できるようになる。
4. レビューに参加することで、自分たちのテストケース、テスト計画、テストドライバ、ツールの良いレビューアーになる方法を学ぶ。さらに、関係者からテストするものを渡されるのをじっと待っているだけのテスト担当者にくらべ、はるかに早くプロジェクトのスピードに着いていけるようになる。

の1のように、「思考パターンの欠点を観察すること」の重要性を主張しています。

にしさんの「不具合モード」、智美塾、今回のSSでのＷモデルの議論の方向性が間違っていないことを本書で確信しました。

よし、いまやってる活動を自信を持って進めよう！と思える一冊でした。

 

 

本書の副題は、「知識変換のSECIモデルとQFD」となっています。

野中郁次郎教授の暗黙知と形式知の変換モデルであるSECIモデルと、赤尾洋二先生発案のQFDの関係が明らかになります。

実は、HAYST法のFV表は、QFDの要求品質展開を参考に作りました。

QFDというと「品質の家」とか、「品質展開」という完成形を思い浮かべる人が多いんじゃないかなと思うのですが、原始データから要求品質への変換（シーン展開）から始まる「要求品質展開」というアクティビティがありまして、そこからFV表の原型が生まれました。

# 完成形から学び始めると本質を見落とす罠がありますよっ。

本書では、「要求品質展開」がSECIの「共同化」に当たるといった整理がされているので非常に分かりやすいし、個人的にはFV表の位置づけもそういうこと(共同化から表出化の逆変換)であったかと理解が進みました。

ということで、とてもおもしろい本です。
後半、事例集が載っているのでそこも参考になります。

 

記号論理とは、命題論理（￢∧∨⇒）とか述語論理（命題論理＋∀∃）のことで形式言語を理解するために避けて通れないものです。

本書では、記号理論を「日本語の一番やさしい、分かりやすい部分を記号化したもの」といいます。だから日本語が普通に話せる私たちなら理解できるはずであると。

さて、この本を読み終えてどうだったか？というと、これまでわかっていた部分はすらすらと読め、分からない（モヤモヤしている）部分は相変わらずわからないなぁと言う感じです（先生に怒られそうです）。

丁寧に書いてあるから書いてあることは理解はできるんですよ。でも、この本のように考えられるかどうかというと……残念ながらそんなことはなく（泣）。

★★★

実は、齋藤先生には、大学の時に線形代数を教わりました。

単位行列とか逆行列とか、それらを用いた方程式の解き方とかの授業を受けた記憶があります。

今から思えば、もっとちゃんと勉強しておけばよかったなぁと思います。＞行列

 

 

1982年以来NECが長年培ってきたソフトウェア品質管理の体系やノウハウを公開した本です。

本書に書かれている方法は、わかりやすく、どこの会社においても明日にでも採用できる容易な方法です。

「えっ！？そんないい加減でいいの？」「もっと複雑な理論式を使った方が合うんじゃないの？？」と思われる読者の人も多いんじゃないかと思うくらいです。

しかし、「そこが落とし穴なんだよ」と教えてくれているように思うのです。

★★★

たとえば「バグ収束モデル」について筆者は、様々なモデルを当てはめた結果、最もフィッティングする曲線を採用するのは、「単に説明に都合の良いソフトウェア信頼性モデルを選択することになってしまい（……略……）責任者の直観に頼ることと同じである」と喝破しています。

では、NECではどうしているかというと、式で予測精度をあげるのではなく、テスト終盤において「バグ傾向分析」をしっかりと行って全員の知恵を結集するとともに「バグ分析と1+n施策」によって残存する課題に対して考えられる限りの品質向上施策を実施して課題を取りきるというのです。

「品質会計におけるバグゼロ」とは、組織として蓄積したすべての経験と知識にもとづいて考えられる限りの確認をした結果、バグが検出できなくなったことを意味する。

といいます。ソフトウェアの品質管理の王道ってこういうことなんだと改めて感心しました。

スパイラルアップを続ける組織におけるリーダの考え方を学ぶことができる貴重な一冊でした。

 

 

文章讀本のような本が好きです。ウェブで読めるものとしては、Kazuさんの『正確な文章の書き方』や、結城浩さんの『文章を書く心がけ』が好きです。本書もそういった本のひとつです。

★★★

本書の目標は「達意の文章」です。はじめにに、

　達意の文章を書くための基本方針は「外国語を初めて学んだときの姿勢で日本語を見直そう」ということだ。「初心忘るべからず」である。だから普段なにげなくやり過ごしている基本的なことにも目配りした。文の長さ、読点の打ち方、語順、「は」と「が」の使い分け、段落の立て方などをしっかりと押さえた。特に、論証（説得力）との関連で段落の問題をていねいに説明した。

とあります。

したがって、とても実用性の高い本です。実用性を重んじるので、「起承転結」ではなく「結起承展」を勧めています。「展」はタイプミスではありません。

　起承転結はいかにしたら読者に「感動」を与えることができるかを意図している。エッセーには向いているかもしれないが、実用文では絶対に真似をしてはいけない。実用文には脱線は禁物である。大切なのは「転」ではなく「展」である。話をさらに展開しなければならない。話をさらに掘り下げなければならない。転じるなんて飛んでもない。

という意味です。

この他にも、「文が曖昧になるよりは、うるさくても遠慮なく接続詞と指示語を使うことをおすすめする」といったアドバイスは、他の文章讀本にはあまり見られないのではないでしょうか。

★★★

本書のもう一つの特徴は、日本語とヨーロッパ語を対比して、日本語の性質を理解したうえでその弱点を補う作文をすべきとしている点です。

　日本語は基本的には主観的判断（と思う）か事実の記述（雨が降る）しかできない。

　　（１）あなたは悲しい。（You are sad.）
　　（２）彼は悲しい。（He is sad.）

　（１）と（２）は英語なら問題ないが、普通の日本語では不自然である（たとえば（２）は小説の中なら可能だろう）。自然な日本語なら次のようになるはずだ。

　　（１）’あなたは悲しそうだ／悲しそうに見える。
　　（２）’彼は悲しそうだ／悲しそうに見える。

翻訳をしていると、英語には必ず主語があり、それをそのまま日本語に直すととってもうざい文書になることがわかります。また、逆に日本語を翻訳ソフトにかけるといかに主語がない文章が多いか唖然とします。
（上の文章も主語が書かれていませんね）

本書では「無生物主語」を立てることで、論理的な文章になるとしています。そして、「名詞中心文を動詞中心文へ書き換える」ことによって、日本語らしい文章になること、また、逆をすることによって論理が明確になることを示しています。つまり、「名詞中心文を動詞中心文へ書き換える」のであれば、

　[1]名詞は動詞に換える
　[2]形容詞は副詞に換える
　[3]無生物主語は原因・理由、手段・条件、あるいは場所・時間の表現に換える

のステップを踏みなさいと具体的に方法を示しています。

★★★

さっき気が付いたのですが、文章讀本って、単に「この文章は悪文だ」と書いているのではなく、「これこれこういう理由で、ほら実用文としては名文と言われたこの文章もいまいちでしょう」と悪文の原因を分析して悪文を書かない方法を伝えているじゃないですか。

これって、ソフトウェアテストが目指しているものととても近いと思うのです。本書でも、句読点の打ち方で文の作り方を解説し、そのあと接続詞と指示語を使うことで文と文との接続の仕方を教え、段落の切り方で意味のまとまりについて説明しています。

私のソフトウェアテストのとらえ方も同じで、今度、SQiPシンポジウムで、「体験！ テスト技法：点 、線、面、立体、四次元の観点で」というタイトルで併設チュートリアルをするのですが、まったく同じ視点でやろうとしています。

ということで、そういう類の（分析とか）が好きなんでしょうね。＞自分

 

 

「角の三等分」という有名な問題があります。ギリシアの三大作図問題の一つで、

どのような角が与えられても定規、コンパスを規定通り有限回用いて、その角の3等分線を見出せる方法はあるか？

というものです。

この問題は、「不可能」であることがわかっているのですが、数学でわかっているとは、証明済みであるということになります。
そして、証明するためには、コンパスと定規の定義から始まり、この問題であれば「コンパスと定規のみで作図できる」ということはどういうことだろうか？　ということを見出さないとなりません。

ある図が作図可能である必要十分条件は、作図に必要な長さを、与えられた長さから四則演算と開平算の繰り返しでつくることができることである。

ここまで来て、問題は幾何学から代数に変換され、解くことができるようになります。

★★★

本書では、ユークリッドの『原論』からゲーデルの不完全性定理まで、不可能をどのようにして証明してきたかが書かれています。

「数学を鑑賞するツボ」の指南書といってよいでしょう。

もちろん、おもしろい問題ばかりで、

「この文章の中には数字1が〇個ある」
この〇の中に0から9までの数字のどれかを入れて「　」内を正しい文章にせよ。

とか、思わず、にやりとしてしまいます。

もちろん、この問題も何故不可能なのかについて解説されています。

★★★

省みると、自分も「その問題がなぜ解けないのか」についていい加減にしたまま議論を進めていることがあるなあと思います。
まず、問題を正確に定義して理解することと、解けない理由を証明しないといけないなぁと思いました。

たとえば、「バグをゼロにすることは不可能」についてなら、「バグ」の定義が必要でしょう。
「バグがゼロ」とはどういった状態を指しているのか？　また、「枯れてきてバグが出ないソフトウエア」とどう違うのか等々について考察しなければなりません。

そして、自分は何がしたいのか……。

 

 

7月2日に翻訳者の柴田 芳樹さんから献本いただきました。どうもありがとうございます。

さて、一見、舌を噛みそうなタイトルですが、実際に口に出してみると意外と大丈夫なので安心して声に出して読んでみましょう。せーの、、、という話は、置いておいて、「アプレンティスシップ」ってご存知でしょうか？　私は知りませんでした。

で、サブタイトルに目をやると、「徒弟制度に学ぶ熟練技術者の技と心得」という、、、おい、この日本語はどこで切れるんだい？　というものです。

[徒弟制度に学ぶ]　[熟練技術者の技と心得]
[徒弟制度に学ぶ熟練技術者の]　[技と心得]
[徒弟制度に学ぶ熟練技術者の技]　[と心得]

うーん。読み終わった今、考えてみるとどれも違う気がします。
いただいておいてなんですが、タイトルとサブタイトルで損してないですか？？

自分なら、
タイトル：徒弟制度に学ぶ！ソフトウェア開発者を極めるための行動パターン
サブタイトル：志あるソフトウェア職人への手引き

とかにするなぁ。うーん。うーん。
タイトルは出版社マターなので、柴田さんには選択の余地がなかったのかもしれませんが……。

★★★

さて、本書は、成長中の意欲を持ったソフトウェア職人が、指導者または業界の全体とコミュニケーションをとる役割になるまでに直面する様々な難題に対して、どのような「行動パターン」を取ればその壁を乗り越えることができるかについて書かれています。

ここで、成長中の意欲を持ったソフトウェア職人のことを“アンプレテイス”(apprentice)と呼び、指導者のことを“ジャーニーマン”(journeyman)と呼んでいます。
見習い奉公中の職人が“アンプレテイス”で、徒弟奉公を済ませた一人前の職人が“ジャーニーマン”なのですね。

“ジャーニーマン”の上に位置する“熟練職人”(master)というのもあります。

スターウォーズのジェダイ・パダワン（Jedi Padawan）、ジェダイ・ナイト（Jedi Knight）、ジェダイ・マスター（Jedi Master）のようなものです。

★★★

本書では、各パターンごとに「パターン名」「状況」「問題」「解決方法」「行動」「関連項目」でその問題に対してどういう行動をとればよいかが示されます。

多くのパターンは「やっぱりそうであったか」と自分の経験から納得できるものでした。
したがって、アンプレテイス達は道に迷った時に本書を読み返すことで明かりがみえると思います。

ちょっと読みにくい（例えば日本語としては「あなた」という単語を消した方が読みやすいところが多いように思いました）のですが、参考になる（考えさせられる）ところの多い本でした。

 

 

以前、『エンジニアのためのWord再入門講座』を読みましたが、そちらは、「スタイル」の使い方を中心にWordを理解しようという本でした。

この『Wordのストレス解消読本』は「書式」を完全に理解することでWordの奇妙な動きの原因を知りストレスを解消しようという本でした。

この本には、いくつか名言があります。

例によって言語明瞭意味不明なオプション名

とか、笑ってしまいます。この名言は[リンクされたスタイルを使用不可にする]というオプション名を皮肉ったものですが、たしかにこの名前から「このオプションをオンにすると、リンクスタイルは常に段落スタイルとして働き、文字スタイルとしての機能は使えなくなる」という意味はわかりませんんよね。

★★★

図が、あっちへ行ったりこっちへ来たりという問題について、本書では図のアンカーを「見出し段落に固定する」、つまり、アンカーを表示して、それを（ページ移動しない）見出し段落にドラッグして、[レイアウトの詳細設定]ダイアログボックスの[アンカーを段落に固定する]オプションをオンにするという方法を勧めていました。

確かに良いかもしれません。

 

 

JUASで講演をしたときに玉置先生にお会いし、面白いパワフルな先生がいるのだなぁと興味を持って何か著作をと思い、買った本です。

共著者のなかで久保 宏志先生（もと帝京大学教授）の名前を聞いたことがあるなぁと思ったら『富士通におけるソフトウェア品質保証の実際』の監修者でした。なるほど。
久保先生が、

　シグマ計画は、まさにソフトウェア産業界にインフラを与えようとするもので、日本のソフトウェア業界と官僚が手を組んで発案したヒットといえよう。

というのには、時代を感じました（私の記憶では、1989年にはすでに破たんしてたけどなぁ）。

★★★

玉置先生はこの本では、産業面（つまり利用者の側面）からソフトウェアの今後を論じていて興味深いです。コンピュータを誰が何の目的で使うのかということをしつこく書いています。
この当時は日興証券の日興システムセンター取締役だったのですね。

★★★

この本に書かれているソフトウェアを作る側の問題点は今もほとんど変わらずというのがちょっと悲しかったですね。

ソフトウェア工学のページは、白井豊氏が書かれているのですが、

　まず、一人のプログラマーが自分で見渡せる作業範囲には当然のことながら限界がある。だいたい二〇〇〇行ぐらいだとされている。ところが通常のソフトウエアは、これをはるかに上まわる。
　　　　（略）
　ところが、厄介なのは複雑にからみ合ったプログラムの実行順序やプログラムの記述要素（ステートメント）間の誤りである。
　　　　（略）
　自分自身の誤りには奥深い、いろいろな原因がある。その一つは、ソフトウェアの機能そのものに関わることである。プログラマーがソフトウエア開発の依頼者の意図を取り違えていることがある。あるいは依頼者自身が意図を十分に伝えていないこともある。
　　　　（略）
　二つ目に、複数人で開発されることにともなう問題である。数十人で一斉に設計を始めるわけだから、担当者間の連携をはかる必要がある。
　　　　（略）
三つ目は、ソフトウェアの複雑さに伴う人間の側の設計ミスである。

と、今のままです。

この本から、20年経って、確かにソフトウェア（アプリケーション）は進化していると思うけれど、ソフトウェアを作る側の問題点はそれほど解決していないなぁと思いました。
（まぁ、高々20年ですからね。これからに期待です）

 

川喜田二郎は、言わずと知れたKJ法の生みの親ですが、昨年お亡くなりになっています。本書は、『創造と伝統』（1993年）という本の「I 創造性のサイエンス」部分を信書化したものだそうです。

★★★

本書のテーマは「文明の立て直し」です。

　この本は、今や「没我」つまり「われを忘れて」という文明が必然になる、　-- snip -- 他方では、巨大な生き物である「世界」を、その内面からの共感で悩もうではないかと訴えているのである。

と述べています。

それは、本書でいうところと創造性の三カ条、すなわち「自発性」「モデルのなさ」「切実性」につながります。

　この三カ条をできるだけ高度に持っている「ひと仕事」ほど、それは創造的な行為であるという結論になった。

というのです。

★★★

　つまり、自分がやりたいからやるんだという底の浅いものではなく、全体状況が自分にこういうことをやれと迫ってくるから、やむなくやっているという絶対感があるもので、それは絶対的受け身ということでもある。

と言います。
私の好きな「他力」につながる発想だなぁと思いました。そういった感覚で動いているときほど振り返るとよい仕事ができているものです。

★★★

KJ法についてこの本ではほとんど書かれていないのですが、企業の教育担当者から、

じつは先生、KJ法なんかを使っても、何も価値のあるアウトプットは出ないですよ。だけど、われわれが重要視するのは、あれを使うと社員がやる気を出して盛り上がるからですよ

と言われたという話が載っていて興味深かったです。

川喜多先生に面と向かって言ったとなっているのでそれもびっくりです。

まぁ、そういった心得違いはどこにでも転がっているのかもしれません。ゴールと、結果の状態を錯誤しているのですね。

★★★

最後に、創造的な小グループ（スモール・グループ）の話がでて、日本でいえば、松下村塾のような強力なチームがなぜできるのか、そこにも、創造性というのが深くかかわっているという話が書かれています。

 

 

SQiPシンポジウムの特別講演を聴いて読んでみたくなりました。

「組織」は、どんなときに「組織」として見えるのか。筆者はこう書いています。

近代組織論の創始者バーナード（Chester I. Barnard）は、二人またはそれ以上の人々の諸活動または諸力が意識的に調整されているときに、「組織」－－これをバーナードは協働システムと呼んでいる－－として見えるのではないかと考えた。

……略

実は、バーナードの非凡なところは、先ほどの公式組織の成立条件として、次の三つを提示した点にあった。

　① コミュニケーション
　② 貢献意欲
　③ 共通目的

言い換えれば、この3条件が満たされたとき、われわれはそこに「組織」を見るというのである。

この組織の定義にはすごく納得しました。

某ML（GA）を横目で見ていて確かに危険水域ではあるけど、大丈夫と思ったのも、コミュニケーションはなんとかとれているし、メンバー全員が貢献しようと頑張っているし、目的はなにより明確だから組織として成り立ってると思ったからなんだなと自分の勘を論理的に理解することができました。

逆に、一見どんなに波風が立っていなくても、会うことも少なく、貢献することもなく、目的もよくわからないと、組織名はあって名前も連ねていても成り立っていないというか、、、いやいや、あれは、組織が必要なわけじゃないからそれでよいのですが……。

★★★

筆者の最後のまとめが気に入ったので引用します。

　私たちは、努力している若者が好きだ。人には見えていないような陰の部分でも手を抜かず、一生懸命にやっている若者が大好きだ。もう少し要領よくできないものかと、いつもハラハラしているが、たとえ、すぐに結果は出せなくても、私たちは、君たちのする事をずっと見守っている。だから、いつか、君たちの力を本当に必要とする日がきたとき、私たちは迷わず君たちを選ぶだろう。そして、君たちと仕事をともに出来ることを心から誇りに思うはずだ。これは偉そうに、上から目線で言っているわけじゃない。君たちのファンとして言っているんだ。

ソフトウェアテスト業界もいい若者が育ってきていますよね。