差はカンマの有無だけですが、意味がまったく違ってきます。この「few」について、限定用法の(1)が指しているのは「重傷じゃない乗客」、叙述用法の(2)が指しているのは「乗客」ですよね。
　重要なポイントとして(1)は、「重傷じゃない乗客」という限定が、逆に「重傷である乗客」の存在を暗示していることです。
　この違いを踏まえたうえで・・・。

　この関係代名詞のような表現が、（自然な）日本語にはないので、ややこしいことが起きます。

　(1)は、一覧表示される条件が　延滞中 ∧ 新着図書 であることが、まあわかる。なぜなら、「延滞中か否か」と「新着図書か否か」とは、直交する条件であると自然に推測できるからです。

　(2)はどうか。「購入から2週間以内か否か」と「新着図書か否か」とは、直交するという確信がもてないと思いませんか。どちらも、「購入からの経過時間」に関係していそうだからです。

　よって、2つの意味に解釈することができます。
　叙述用法的な意味なら、「新着図書・・・ああ、これは購入から2週間以内の図書を指すんだけどね。それを一覧表示したいんだ」というアメリカ文学みたいな仕様。
　限定用法的な意味なら、「新着図書のうち、購入から2週間以内のものを、一覧表示する」という仕様。

　「以内の」の「の」のせいで言いたいことが言えない。そんな「の」はまさに poison のような危険さをもっています。

　この曖昧さを回避するための表現方法として、

などが考えられます。
　とにかく「の」は危ない。意味が多すぎるんだ。

　この「反町仕様書」の派生版が「マーブル仕様書」です。
　例を挙げてみます。

　この仕様には嫌な点が2つあります。
　一つ目は、カッコ内を体言止めにしていること。カッコ内の体言止めは、反町の「の」と同じ、曖昧さをもたらす poison です。
　次の二つの文では、カッコ内の言葉が果たす役割が違います。前者では叙述用法、後者では限定用法ですね。

　もう一つは、外部仕様の話を、内部的なパラメタで補う、あるいは限定していること。
　次の工程への優しさなのかも知れませんが、たとえば外部仕様書をレビューするお客様にとっては意味のない記述でしょうし、上述のような曖昧さをはらんでいるだけに、あまりよい方法とは思えません。

　それでは、外部仕様と内部仕様の「言葉」をどう繋げばいいのか。
　これはまた別の話になりますので、別のエントリーで。

だそうです。
　その第38回は、日本IBMの細川宣啓さんによる「ソフトウェア品質検査技術と静的解析～インスペクション技術を中心に」というテーマ。ソフトウェア品質技術者たまねぎ戦士のわたしとしては外せないイベントです。

　このエントリーでは、その内容を一部、お伝えしたいと思います。
　なお発表のスライドは（まだ）公開されていませんが、内容の一部は細川さんの別の講演でも紹介されているので、そのスライドをご参照ください。たとえば、コチラ（PDF)です。わたしの記事には文章しかないので、わかりづらいと思います。

　大きなテーマがいくつかありましたが、わたしが特に気になったのは2つ。ドキュメントのレビューとコードインスペクション、それぞれの対象の選び方です。
　レビュー自体の能力ももちろん重要ですが、その能力を最大限生かすためには、対象を効率よくサンプリングする能力が必要なのですね。

　V字モデルで開発している組織は多いと思いますが、その実態は、設計のある段階からテストのある段階までを外注する、つまりV字の下の部分を自分たちでは行わない「洗面器モデル」。
　その洗面器に入れる「発注時のドキュメント」と、洗面器から出てくる「納品時のプログラム」の品質の見極めが大事であり、そのためにはそれぞれを適切にサンプリングする方法が必要だというお話です。

　まずはドキュメント。膨大なドキュメントからどう、品質的なリスクの高いものをサンプリングするか。

　設計工程で得られるデータといえば、見積もり規模、ドキュメントの枚数、レビュー工数、レビュー指摘件数などでしょうか。
　これらを組み合わせて、何がしかのメトリクスを作ることはできます。伝統的な指標については、たとえば『定量的品質予測のススメ』にたくさん載っています。

　ですが細川さんの提示された散布図は、これらをなぎ倒すものです。
　この散布図、ドキュメントの最終更新日時の「日付」横軸に、「時刻」を縦軸に持っています。そこにはどんなパターンが現れるでしょう。

　たとえば、縦に現れる強い筋。縦ということは同じ日に多くのドキュメントを更新しまくっているということで、つまりは納品直前だったりします。
　さらにその納品日直後に、台形を左に倒したような形（右に長い辺、左に短い辺）。これは、「納品日は早上がりして、酒を飲みにいく。翌日以降は一時的に、出勤時刻が遅く、退勤時刻が早くなるが、納品後のお客様指摘への対応のために徐々に労働時間が長く・・・」ということを意味するとのこと（笑）。

　「最終更新日時」なんていう普段は気にもしない属性が、プロジェクトの様子を如実に表していますね。
　このように、グラフが示すパターンから事実を読み取ることを「グラフマイニング」と呼んでいました。特徴的な欠陥パターンの例として、以下のものがあるそうです。

　午前3時にプロットがある。おつかれさま・・・。でも、そんな時間帯に一人で更新すると、すり合わせ不足による矛盾・不統一の欠陥が多いかも知れない。

　外部設計書と内部設計書、それぞれの納品日直前の黒い筋。この間隔に全然プロットがないということは、内部設計書を書き始めてから、外部設計書をほとんど更新していないということ。仕様追跡性の欠如が疑われる。

　身につまされるお話。。。
　IBMでは、成果物の品質のリスクになるパターンを10数個に整理しているそうです。それらのパターンをもったあたりを狙い撃ちすることで、危ないところから潰していけるということですね。

　まず、細川さん謹製の「欠陥の魚群探知機」という散布図。
　上から下が、基底クラスから派生クラス。左から右が、重い欠陥から軽いバグとしてプロットしています。
　たとえば横に強い筋があれば、広くたくさん誤っているということで、人を次ぎ込む必要がある。縦に強い筋が現れていれば、標準化をミスっているため、みんなで間違っているのかも知れない。こんなことが読み取れると言います。

　さらに、すべてのソースファイルをスキャンして、「診断」に必要なパラメタを抽出します。行数、コメント率、IFの数、try~catchの数・・・。
　これらのパラメタを組み合わせてメトリクスにして、「2万行のクラス」「コメント率が100%」「ifが数100個なのにelseがほとんどない」といったリスクの高い箇所を絞り込み、サンプリングの対象とします。

　そのうえで、さあいよいよコードのロジックを・・・見ない。まず、ファイルを開いてコードをソートする。！ ？
　ソートにより、デッドコピーが1か所に集まってきたり、深すぎるネストの多さが可視化されたりするのです。これだけでも、ざっくり傾向がつかめるというのです。ダイナミック過ぎてすごい。

　さらに今度は、書かれた言葉を検索する。「TODO」「TBD」「調整」など・・・。中国の開発においては、「XXX」という隠語が使われることもあるとのこと。
　これらのコメントは、仕様がギリギリまで固まっていないとか、とりあえずの実装をしているといったリスクをはらむ。最悪のコメントして、「// 苦肉の策」なんてものまで紹介されました。

　もちろんこれは、下準備。この後に本来のインスペクションがあるわけですが、その前段階としてできることがある、ということです。

　なお、この言葉拾いは、わたし自身もドキュメントチェックの際にやっています。当初は、「以上/以下」「こともある」みたいな、間違えにつながりやすい言葉を拾っていましたが、そのうちより人間行動に着目しｗ、そっち系のキーワードを集めました。
　わたしの場合「XX」と「**」をチェックしていますが、細川さんの観点とはちょっと違って、「XXX参照」「＊＊＊に記載」のようにとりあえず書いたまま参照先のネタを作り忘れるということがあるためです。

　欠陥マスターDBについての話がありました。これは細川さんが以前から進めていた研究の一つで、欠陥の現象や原因を一般化し、その定義、発生の兆候、検出方法、除去方法、副作用などを整理したものです。
　これらの特性を数値化し、それを「Shape of Defects」として可視化したり、欠陥同士の関連性を見つけたりという欠陥エンジニアリングの研究を進めているそうです。

　このようなトピックは、来週開催されるJaSST'12 Tokyoでもお話されるとのこと。JaSST参加予定の方は、ぜひ聞いてみることをオススメいたします。

　細川さんはプレゼンの最後に、「日本のソフトウェア開発でもっとも不足しているのは、品質エンジニアだ！」と力説されていました。
　品質とは本当に難しい分野だと思いますが、わたしもその一端を担えるようがんばりたいです。という、小学生の日記のような終わり方ですいません。

　「Verpixelungsrecht」というドイツ語があるそうです。googleストリートビューで撮影された自宅やオフィスの画像に対して、モザイク化を求める権利のこと。言葉を簡単に合成してしまうことで有名なドイツ語ならではですね。

　この合成語を作り出す傾向が、ソフトウェア開発の設計ドキュメントで顕著に感じられるのはわたしだけでしょうか。

　たとえば以下。

　中華一番！
　「検索結果を表示した状態で、複数の項目を選択している場合は・・・」と書けばいいと思うのですが・・・。この短縮により何かメリットがあるのでしょうか。

　さて、勝手熟語が作られるプロセスは2つあり、それぞれ別の問題をもっています。

　「残業をする」は、名詞+助詞+(サ変)動詞 という構造をもっていますが、「残業する」はそれ自体が1つの動詞です。「サ変動詞を省く」とは、「する」を省略して名詞に戻す行為を指します。

　何が問題なのか。
　「する」は動詞であり、動詞は活用を持つ。つまり「する」「される」「した」「された」といった、時制や態を持つのに、その情報をあえて捨てて、時制も態もない名詞に戻していることが問題です。

　たとえば「複数項目選択時」という勝手熟語を考えてみましょう。

　この句点の後の行動・動作のタイミングはそれぞれ、いつなんでしょう。
　(1)は「選択する前」で、(2)は「選択した後」。同じ言葉なのに、タイミングが異なりますよね。
　文脈に応じて時制や態を読み手が解釈しないといけない。つまり、曖昧です。動作の説明をするドキュメントで、その動作が起こるタイミングが曖昧なのは悲しい。

　たとえば(1)「利用者閲覧済み記事」という合成語。この言葉を、(2)「利用者が閲覧した記事」と比べたとき、印象にどのような違いがありますか。

　(2)だと、「閲覧」という操作がシステムとしてどういう意味を持つかまでは言及していないのに対し、(1)では、たとえば「閲覧済みフラグが立っている」など、「システムとして明確に特定できる言葉」であるような印象を受けます（よね？）。

　合成語はもともと自然界に存在する言葉ではなく、そのシステムでいきなり生み落としているものなのだから、当然そのシステムにおいてクリアに定義された意味を持つべきということになります。そうでないなら助詞を省かず、自然な自然言語を使うのがいいと思います。

　結論というか、主張は以下です。

　さて、この「明確に定義」に関する問題に、「マーブル模様の仕様書」というものがあります。多分次回は、これについて。

　2011年は「ソフトウェアテスト技法ドリル勉強会」のおかげで、テスト技法に関する勉強を進めることができました。
　2012年はこれに加えて、「レビューどうやろうか」ってことをじっくり考えていきたいと思っています。昨年末のレビュー祭りでアジャイル・インスペクション、「ガイドを用いたサンプリングレビュー」の話を聞いたことが大きいですね。

　レビューは静的テストに分類されるのですが、プログラムのテストと大きく違う点があります。
　テストケースがないことです。
　何をもってよしとするかもよくわからないし、「レビューってどうやるの？」という疑問にも答えがたい。自分自身、システマティックにチェックやレビュー作業をしているとはとても言えない。

　細谷泰夫さんによる、SPI Japan 2011の発表資料・『産学連携によるデザインレビュー改善事例』を絶賛精読中なわけですが、このスライドp.8のような、レビューのロードマップを、自分なりに持っておきたいですね。

　さて、スライドp.8の図を参考に、レビュー形態を次の2つの軸でマッピングしてみました。理解が誤っていたらスミマセン。

　「技術」はそのまま、技術的に妥当な設計かということを検討するもの。「ドキュメンテーション」（もっと適切な表現がありそう）は、用語の統一、ヘッダー・フッターといったエディトリアルな正しさや、記述の十分性、明確さなどを検討するもの。

　ドキュメントの一部を対象とするのか、全部を見るのか。

　(A)(D)(E)がスライドにあるもの。(B)はレビュー祭りで習ったもの。(C)は今、自分で考えているものです。1つずつ見てみます。

　まず、(A)アジャイル・インスペクションです。先の発表スライドにあるように、文書様式、言葉の定義、記述の粒度や深さという部分を見ます。技術的な妥当性は埒外。
　使える道具として、エディトリアルな観点についてはプロジェクトや組織規定のチェックリストがあったり、曖昧さにつながる表現の検出については一部、ツールで機械的にチェックできますよね。

　(B)「ガイドを用いたサンプリングレビュー」の守備範囲はアジャイル・インスペクションと重複するものの、真にエディトリアルなところは見ないので、若干上側に。ここで使用する道具は、ガイド。

　(C)チェックリストに基づくレビューってのを考えています。チェックリスト嫌いな人、かたじけない。
　ここでいうチェックリストは、コーディング規約を羅列したようなものとか、過去の失敗事例に基づいて作成したような技術的・各論的なものではありません。開発対象のプログラムの性質にあまり依存しない、汎用的な項目です。

　(D)インスペクション。(C)との合わせ技で、技術的な妥当性と、それに伴う記述の十分性・正確性を担保する！というところでしょうか。言うだけなら簡単ですね。
　レビュー担当者の成長パスとして、最初は(C)のチェックリストをたよりにレビューに貢献しつつ、次第に(D)にシフトしていく作戦。

　(E)ウォークスルーです。
　(D)と(E)については、先のスライドにそれぞれ「自信のない部分を局所的に」「全体を通して」とあることから、この位置にしています。

　で、今年よく考えていきたいと思っているのは、太い楕円のもの。(B)の「ガイド」と、(C)のチェック観点の手持ちを増やしたい。
　(B)のガイドについては、レビュー祭りで習った入出力のガイドと、前回書いたキーワードマトリックスで、とりあえず2つ(笑)。
　(C)のチェック観点として考えているものを、今後書けたらと思います。

　もしかすると、車輪の劣化再発明を一生懸命やっているのかも知れません。参考になる本や記事などあれば、教えてくださいませ。

　(C)のチェックリストは、技術的な事例の集まりじゃないよと書きましたが、「やりがちな失敗」「設計誤りの経験」みたいなものを、ノウハウとして蓄積していくのは正しいと思っています。
　でもそれをチェックリストの体裁にして、設計後にそれに基づくチェックをする/させるというのは、アンチパターンかなと。挿話証拠「そんなチェックリストあるなら先に言ってよ」。
　そういうノウハウは、ドキュメントを書く前に見て、理解しておくべきなんですよね。

　このようなガイド、他にどういうものがあるのでしょう。
　『Engineer Mind』の連載『エンジニアよ、国語力に目を向けよう』（開米瑞浩氏）で紹介されている「キーワードマトリックス」が、まさにガイドとして使えると感じたので、紹介します。

　記事では、Microsoft Windows XP Professional リソースキットの文章を引用しています。以下の引用はその孫引きです。

　何といいますか、清潔に書かれていますが、シーケンシャルに流れていって、頭にはなかなか入ってこない、そんな文章です。
　開米さんはこの文章を、ステートメント（1つの意味だけを明確に表現した短い文）に解体し、グルーピングせよと教えています。するとこの文章は、(1)ユーザプロファイルの話 と (2)移動用のユーザプロファイルの話 に分けられることがわかります。

　キーワードマトリックスは、この再構築が終わった後に使います。
　キーワードとは、上の文章でいう「ユーザプロファイル」「ログオン」など、説明の要となる言葉。さらにこのキーワードたちの、文章における属性を抽出して、マトリックスを作ります。そのマトリックスに、再構築したステートメントの内容を埋めていく。すると・・・

　このように、「埋まっていない部分」が明確になるというわけです。
　特に(B)は、仕様として明確にしておくべき場所でしょうが、元の文章から、「Bが抜けている」と見ぬくのは難しいですよね。
　また「用途」列でわかるように、「移動用」に対して、「デフォルト」的なモノは、名前が省略されがちと指摘されていました。「ラッパ飲み」という言葉はありますが、「容器から飲み物をコップに注いでから飲む」という動作に名前がないのと同じですね。この名前の省略は、あとあと仕様の曖昧につながっていきます。

　入出力ガイドに比べて、自分で属性を抽出しなくてはならない分難しくはなりますが、有効な方法だと思います。色々な要素が長文でダラダラ書かれているような箇所に適用するのがよさそうです。

　ところで、開米瑞浩さんにはどんな著作があるのかな？と調べてみたところ、WACATE2011冬の予習本であり、ぼくも購入している『エンジニアのための図解思考 再入門講座』がまさに、それでした。2012年も、毎度毎度の出遅れ感・・・。

　分量の割に内容は薄く、要点は以下の2点です。

　ソフトウェアの欠陥の数を予測する話・・・などと口走った瞬間に警戒されますよね。特に「欠陥密度」を嫌う人は少なくないようです。
　なぜ、嫌われるのか。考えてみると、以下のような三つのドグマが、その理由になっているように思います。

　・・・まあ極端に書いてますし、これを絶対的に盲信している人はあまりいないでしょう。
　一方で、「テストの終わり」の基準として何らかの数字が欲しいのも人情。そのため、これほど極端ではなくとも、どうにもしっくりこない「目標」が独り歩きしてしまうことがありそうです。

　欠陥数を予測する技法として、もう少しこのドグマから逃れられるものはないでしょうか。

　『SQuBOKガイド』の知識エリア3.6「品質分析・評価の技法」に、「探針」（Quality Probe）という項があります。
　このエントリを書こうと思い立って改めてネットを調べたところ、すでに秋山浩一さんが、この探針について必要十分な記事を書かれていて、目の前が真っ暗になりました。詳細はこちらをご覧いただくとして。

　探針とは、ハードウェア製品でいう抜き取り検査のアナロジーです。製品全体から一部を抜き取って、その不良の割合から全体の品質を予測する。
　ソフトウェアでは、「製品」を「テストケース」に読み替えます。
　検査部門が、用意したテストケースから一定の割合の項目を無作為に選び取り、消化する。その結果から、テストケース全体で出るであろう欠陥の数の範囲を予測するのです。

　この予測には、区間推定の考え方を使います。「開票が始まったばかりなのに当確が出る」「ほんの一部の世帯しか調べていないのに視聴率が出る」というのと、本質的なところは変わりません。

　主な変数は2つだけ。消化したテストケースの数と、摘出した欠陥の数。たとえば、全テストケース5,000件の中から30%選んで消化した結果、欠陥が50件だったとすると、全テストケースでは121～212件の欠陥が出ると予測されます。

　探針による予測は、テスト工程のどこかの一時点で行うものとされています。でもためしに、テスト工程の進捗の各段階で予測をしたらどんな姿になるか、見てみましょう。

　日付を横軸にして、欠陥の摘出がまんま Gompertz 曲線に乗るような、40日間のテスト工程で試してみます（土日もテストやってる！とか気にしないでください。欠陥数も適当）。

　わー！最初の2週間くらいでもう、最終的な欠陥数の範囲にほぼ収束してる！すごい！
　開始直後はテストケースのサンプル数が少ないので、上下限の幅はとても広いのですが、急速に狭まり、予測が安定していますね！

　というのはもちろん欺瞞。このグラフでは、「消化したテストケース数に比例して欠陥が出る」というシミュレーションをしています。
　探針でのサンプリングは、（層別で）無作為が原則です。欠陥のありそうなところから優先度をつけて叩いていく、という戦略のもとでテストを進めている場合は、無作為ではないですね。
　一方、そういう戦略ナシで、各チームが並行に、担当分のテストケースを作った順に消化していくような場合は、ある程度の無作為性があるようにも思います。逆説的ですが、テスト戦略なく進めている方が、うまく理論に乗る、なんてことがありそうです。
　いずれにせよ、技法なりメトリクスなりを適用するには、前提を押さえておくことが肝要ですね。

　さて、欠陥密度と同様、探針による予測も素朴なものです。ですが実は、最初に述べた(1)と(2)のドグマからは解き放たれています。

　(1)について、ソフトウェアの「大きさ」の概念が出てきません。
　(2)についてはどうでしょう。「テストケース数」と「摘出された欠陥数」という、2つの変数について考えてみます。

　当然ながら、ソフトウェアの品質が低ければ欠陥が多く出るでしょうし、テストケースがいまいちなら、出るべき欠陥が出せません。
　つまり「欠陥」は、プロジェクトやソフトウェアの性質、設計・実装チームのスキルといった要素が織り込まれたもの。「テストケース」は、テストチームのテスト戦略、テスティングスキルが織り込まれたもの。
　ものすごい単純化かも知れませんが、探針による予測には、その開発独自の要素が織り込まれており、プロジェクト固有の指標になっているのです！・・・いるのかもしれないのです（言い直した）。

　では、予測した上限・下限をどう使うべきなのでしょう。

　探針本来の目的として、『SQuBOKガイド』には、「品質の早期把握と品質向上施策の指針を得る」とあります。保田勝通氏・奈良隆正氏の『ソフトウェア品質保証入門』でも同様です。短絡的に、「この範囲を目標として欠陥を出すのだ！」とは言っていません。(3)のドグマからも自由になれそうです。

　ここでちょっと目先を変えて、この区間を、「リスクの幅」と考えることはできないでしょうか。品質的なリスクではなく、テスト工程に要する工数の不確定要素ということです。
　欠陥が多ければ、それだけ改修の人と時間を要する。テスト工程の途中段階で、欠陥数の最良と最悪がざっくりとでも把握できていれば、何やら嬉しさがあります。

　また、この区間推定はけっこう、傾向の変化に敏感のようです。ためしに、上のグラフの欠陥数のうち4/16だけ5件増やすと、こうなります。

　2011年4月16日(土)休日出勤中のテストエンジニアの苛立った顔が目に浮かぶようですね。
　このように、テスト工数のリスクと、傾向監視に使うことができそう。とも思います。

　以上、一般にあまり知られた技法ではない「探針」の紹介と、勝手な実験をしてみました。

　テスト工程の状況から欠陥数を予測するといえば、まずソフトウェア信頼度成長モデルがあり、『SQuBOKガイド』でもちょうど、探針の直前に来ています。この Advent Calender でも太田さんが、Gompertz 曲線はアジャイル開発で使えるかというエントリーを書かれていました。

　こんな風に、古式ゆかしい技法を、現代の開発の現場でうまく使えないものかと考えてみるのも、面白いのではないでしょうか。
　机上の空論に終わらない、そして現場の助けになれるような技法やメトリクス。そんなものを見つけていけたらいいなと思い、こんなエントリーを書いてみました。

　最後まで読んでいただき、ありがとうございます。
　明日12/15(木)は、Shuji Watanabeさんの予定です。

　今回の講師は著者ご本人、秋山浩一さんです・・・。何という勉強会。秋山さんは「時間を網羅する」章の執筆で時間との戦いを余儀なくされ、書きたいことを網羅しきれなかったとのこと・・・。

　状態遷移の話に入る前に、「4つの視点」と称するテストの分類が紹介されました。

　テスト技法の分類としては、秋山さんのWebサイトで紹介されている「テスト技法ポジショニングマップ」がありますね。
　ポジショニングマップは、ブラックボックス/ホワイトボックス という軸と、網羅的/ピンポイント という軸で作った平面に、各種テスト技法をマッピングしたものです。
　一方「4つの視点」とは、テストの対象や技法を、「構造」「機能」「振る舞い」「並行・並列」の4つに分類したもの。テストの視点が、順にズームアウトしていくイメージでしょうか。

　まず、「構造」に対応するテスト技法の代表が、コードカバレッジです。単体テストに対応しますね。
　次に「機能」。「構造」で確認したものを統合してできた、機能の論理を検証します。デシジョンテーブルや原因結果グラフ、HAYST法などが、技法として対応します。
　その機能によって遷移していく状態を確認するのが「振る舞い」。今回の対象である状態遷移表が、その確認のための技法となります。
　さらにその遷移が複数動いているときの挙動を検証するのが「並行・並列」。ハレル図、ペトリネットといった、わたしにとって未知の技法がここにあります。

　この勉強会の中で秋山さんが、Boris Beizer 氏の「グラフを見たら、網羅せよ」という言葉を紹介されていました。『Black-box Testing』にある「テストの一般原則」という章にある言葉みたいですね。

　ポジショニングマップも4つの視点にしても、グラフではありませんが、「こう切ってみたが、当てはまる技法は何だろう」とか、逆に「技法があるが、当てはまる象限がない。なぜだろう」みたいに発想が膨らむんですよね。なので、「集まったら、分類せよ」というのも大事だと思います。

　さて、今回の宿題は、「シンガマジック！」という人形の状態遷移図を描くというもの。なお、以下の図表はastah*を使って描いております。

　リンク先に飛ぶとわかりますが、どのモードでも、おなかを押していると音がなって、離すと止まるという動きのようです。
　「3つのモード」という文言を見て、「じゃあ状態はまず3つだね」と脊髄反射的に作ったのが以下の状態遷移図です。

　いや、初期はもっとひどい、かつ表記ルールも守っていなかったので、思い出を美化しています。
　「バイバイ」というのは上の説明にはありませんが、あるモードで放置すると、「バイバーイ」といって黙りこむという動作をするので、その状態も追加しています。

　この状態遷移図のダメな点はなんでしょう。・・・ダメな点は複数ありそうなので、「特にダメな点」としておきましょうか。
　モード「ハーモニー」に注目してください。開始直後、シンガマジックの声は出ていません。次に、腹部を圧迫すると、声が出ます。その「声が出ている」状態は何かというと、ぐるっと回ってやっぱり「ハーモニー」としているのが、上の状態遷移図なんですね。
　「声が出ている」と「声が出ていない」とは、別の状態として定義しないといけません。イベントとしては、「押す」に対して「離す」を入れてやるといいですね。で、描いたのがコレ。

　3つのモードからもそれぞれ、電池切れで終了状態に落ちいるようにしました。

　この「開始状態」「終了状態」というちょっと難しい。正しくはこれを「開始擬似状態」「終了擬似状態」と呼ぶそうです。秋山さんにコチラの記事を紹介していただきました。

　状態遷移図の遷移図の「状態」は、オブジェクトが取りうるもの。オブジェクトは時間軸のある時点で生成され、別の時点で消滅します。
　では、生成の前のオブジェクトはどのような状態なのでしょう。答えは、「状態はない」ということになりますね。存在してないのだから、「バイバイ」ですらありません。とはいえ、最初の状態へは、どこからか遷移してこなくてはならない。よって、実際にはオブジェクトがとりえない「開始擬似状態」を定義して、何らかのイベントをトリガーにして最初の状態を取る、ということなんですね。

　さて、astah*を使うと、描いた状態遷移図から、状態遷移表が自動的に生成されます。これは嬉しいよなあ。
　最初はこんな感じで現れます。空白のセルが多いですね。

　状態遷移表のメリットは、このように、考慮されていない状態×イベントが可視化できる点ですね。
　たとえば、「バイバイ」で「腹を押す」とどうなるかが、遷移図にないことがわかりますね。実際には、このアクションでも「モード1」に遷移するとのことです。また、「腹を離す」を定義したのに、「手を離す」って不要なの？とも思い当たります。

　たとえ「ありえない」遷移であっても、空白で残すのではなく「N/A」と明示的に判断しておくことが必要になります。
　なお、astah*では「N/A」にあたるものとして、「cannot happen」と「ignore」の2つから選べるようです。「cannot happen」は原理的に起こりえない、たとえば「押した状態で、押す」といったもの。「ignore」は、起こりうるけど、考慮しない。というものと捉えています（未確認）。「ignore」を選ぶのは勇気がいるな。

　「開始状態」は、表にいらない気がするんだけどなあ・・・。

　状態遷移の網羅の考え方として、n-switchカバレッジがあります。n-switchとは、遷移後n回スイッチすることを意味しています。上の状態遷移図でいうと、「モード1→モード2→モード3」は、1-switchの遷移ということになりますね。

　遷移する回数nを決めると、状態から状態へn回のスイッチで到達するためのルートは、行列計算で求めることができます。手順的には難しくありませんが、面倒です。
　今回の勉強会では、遷移をツリー状に展開することでスイッチパターンを洗い出す方法を教えていただきました。Togetterには、参加者の方の結果の画像もアップされているので、ご覧ください。

　さて、この後、直交表を使った状態遷移テストの考え方と、さらにはシーケンスカバリングアレイという、テストパターン削減のための技法についてお話いただいたのですが、全然咀嚼できておらず・・・。
　とりあえず書けるのはこんなところです。シーケンスカバリングアレイは、某MLのやりとりを一度じっくり読んだので、もしかすると、いつか・・・いつか・・・書けるかもしれない。
　ともあれ、いつも充実した内容の本勉強会、主催者・講師のみなさまには感謝でございます・・。

　では、x と y の相関の程度を表す相関係数を求めてみましょう。
　直接コマンドを叩くのが速いです。相関係数（coefficient of correlation）を求めるための関数は、cor。

　行列形式で表示されるので、3変数以上あるときに、すべての変数の組み合わせで、相関係数を見られますね。
　x と y の相関係数は、約0.82とわかりました。

　なお、メニューからは、[統計量] - [要約] - [相関の検定] を選択すると、次のようになります。最後の行に、相関係数が。

　相関係数の書かれた最後の行以外は、検定に関する記述なので、ここでは立ち入[りれ]ませんが、「相関がない（相関係数がゼロである）という帰無仮説を棄却し、相関はある、という対立仮説が採択された」ということになるようです。「偶然のバラツキとは思えないほど相関があるように見える」ってことですね。

　その1 で、4つに層別した散布図を見ました。それぞれ特徴のある分布でしたが、これら4つの相関係数はどうなっているでしょう。

　そう、これだけ多様な散らばりなのに、相関係数はほとんど同じ。最小二乗直線を見ても、

　わかりづらいですが、右肩上がりの直線でみんな重なっています。相関係数も最小二乗直線も、線形的な関係がどのくらいあるかということを表現しているので、緑△のような二次曲線っぽさは無視されてしまうし、水色×のように一見垂直のように見えても、右上のはずれ値に思い切り引きづられてしまうんですね。

　最小二乗直線を求めるには、[統計量] - [モデルへの適合] - [線形回帰] 。こんなダイアログが出ます。

　ここで注意。このダイアログでは、目的変数が左、説明変数が右に配置されています。通常グラフで縦軸になる方が、目的変数。散布図を描くダイアログと逆です。

　「といっても、y = a*x + b への当てはめなんだから、x と y を逆したところで、x = (1/a)*y - b/a に変換すればいいだけでは？」と思ったら負けです。最小二乗直線を求める算出式では、目的変数と説明変数は対照ではないのです。

　最初の散布図の、水色×の散布図で、それを確認してみます。下図の左側が、y を目的変数、x を説明変数としたグラフで、右側がその逆のグラフを回転・反転させたものです。傾きが全然違っていますね。

　次の第3回は、12/18の予定。第9話・確率と、第10話・確率変数 が対象となりますが、わたしはWACATE2011冬に参加予定のため、残念ながら出席できません。どなたかのつぶやき&togetterに期待！

　ヤマハの小池さん主催の「（ソフトウェア品質技術者のための）R勉強会」の第2回が行われましたので、復習をかねてエントリを書きます。なお、当日のつぶやきまとめはコチラにあります。

　今回のテーマは、『例題で学ぶ統計的方法』の第7話「散布図と相関係数」、第8話「回帰曲線」。「ソフトウェア品質技術者」がもっとも使う道具がこの2つと言えるかも知れません。ともに、基本は知ったつもりでいながら、学んだところが大きかったです。

　何はともあれ、演習で使ったデータセット（Anscombe のデータ）をで、散布図を書いてみましょう。データセットの44点をプロットしたのが、下のグラフ。

　「ぼんやり、右肩あがり」程度しか、傾向は見いだせませんね。

　実は上のグラフは4種類のデータをいっしょくたにしたものなので、描き分けてみます。グラフ描画のダイアログで「層別」を選択し、平滑線も入れて出力した結果が、以下。

　分けると、傾向が見えました。赤○と青+は、右肩上がり。緑△は2次曲線。水色×は、Y軸に垂直な傾向がありますね。

　では、この青+のみのプロットをしてみましょう。データを絞ってグラフを描く方法は（少なくとも）2つあります。

　絞ったデータ自体を何度も使いたいなら、①がいいでしょうね。手順は、メニューの [データ] - [アクティブデータセット] - [アクティブデータセットの部分集合の抽出] から。
　ダイアログは、入力した値を覚えておいてくれないので、一度実行したら、コマンドを直接叩く方が早いでしょう。下のコマンドは、初めに使っていたデータセット Ans01 から、変数 layer の値が 「c」であるものを選び、さらに変数 layer 自体は省いたデータセット Ans02 を定義しています。

　この Ans02 で散布図、および最小二乗直線を描くと、

　不自然なほどきれいな直線に乗っている。が、どうも右上の点は、傾向から外れているように見える・・・。

　さて、全体の傾向から外れているからといって、それが「間違っている」「意味がない」ということにはなりませんが、全体の傾向をより精度よく調べるために、これを外したい。
　ただ、「外す」には何らかの指標がほしいものです。恣意的に外すべきではない。ではどんな方法があるでしょうか。

　簡単なのは、トリム平均というものです。最大と最小の付近の値を取り除いてから平均値をとる。Excel だと TRIMMEAN という関数があって、上下何パーセントを除くかを指定することができます。

　野中先生に教えていただいた1つの目安は、「箱ひげ図を見て、四分位範囲の1.5倍を超えたらはずれ値の候補とする」というものです。

　上の図のように、箱ひげ図は散布図のオプションとして出力できるので、まずはざっくりとはつかめますね。y軸でいうと、箱の上辺が第3四分位、下辺が第1四分位でその幅が四分位範囲です。この幅の1.5倍以上、上辺より上にある、または下辺より下にある場合、はずれ値とみなせるかも、と。

　四分位範囲の正確な値は、メニューから、[統計量] - [要約] - [アクティブデータセット]。これで数値データセットの基本統計量を出力するコマンドです。

　なお、四分位点を求めるには、以下。

　今回、y の上の方の外れ値を外すことを考えるので、データセット Ans02 に対する四分位範囲（InterQuartile Range）を求めてみましょう。この表現にたどり着くまでに、試行錯誤で2時間以上かかりました。本当に疲れた。

　「第3四分位点から見て、四分位範囲の1.5倍より大きい値」は、

　この表現を使って、散布図と最小二乗直線を描いてみます。
　この式を、グラフ作成時のデータ絞り込み条件に使ってもいいし、別の変数に代入して、その変数を絞込み条件に使うこともできます。下のコマンドでは、直接絞り込んでいます。

　外れ値を除いた曲線を描くことができました。確かに、「直線に乗ってるっぽい」ですね。

　ところで、はずれ値を除去しても、y軸の箱ひげ図の幅があまり変わっていないことは、大事なポイントです。この「データを多少抜いても、あまり変わらない」箱ひげ図の性質を、ロバスト性というと習いました。
　何故、ロバストか。箱ひげ図はデータの順番を見ているので、データが多ければ、はずれ値を外したところで全体への影響は少ない。一方平均なんかは、値そのものが計算に効いてくるので、外れ値の影響を思い切り受けるわけです。なるほど・・・。

　極端なデータセット(96, 1, 1, 1, 1) を考えてみましょう。
　平均値は20、中央値は1。
　一方、はずれ値「96」を外すと、平均値は1に大きく変化しますが、中央値は依然として1（=(1+1)/2）なのです。
　外れ値の目安を聞いたときに、「外れ値を外すと1.5倍の範囲も変わって、やってもやっても新しいはずれ値が出るのでは？」と思ったのですが、この性質によって、この「タマネギの皮むき」をある程度回避できるのですね。

　その2では、求めた最小二乗曲線が「どのくらい妥当なのか」という話と、最小二乗曲線の注意点について、学んだことを書きます。

　ド・モルガンの法則とは、以下の2つですね。

　腑に落とすために、次の例文を考えてみましょう。

　命題Pを「オービーである」、命題Qを「バービーである」とすると、「オービーでもバービーでもない」という言明は「オービーでない、かつ、バービーでない」、つまり「￢P ∧ ￢Q」ということになります。
　これをド・モルガンの法則第1式で置換すると、「（オービーである、または、バービーである）ということはない」、ということになります。

　さて、何故こんなことを言い出したかというと、AND、OR、NOT が日常語に現れたとき、最も紛らわしいのはNOT だと思っているからです。で、ド・モルガンの法則を使えばその紛れを軽減することができるかも知れません。

　たとえば、次のようなちょっとわかりづらい文章を書き換えていきましょう。

　この前半部分を論理式に変換しやすいように書くと、

　ド・モルガンの法則を適用して、

　ここで、日常語ならではの変換をほどこします。

　で、最終的に得られた命題は、

　最初の命題より、ちょっとだけ人間が理解しやすくなりました。

　つまり、命題を結合した論理式全体にかかっていた否定語を、ド・モルガンの法則によって個々の命題に直接くっつけたうえで、日常語の変換をすることで、否定語を消すことができるかも知れないというお話です。特に大小関係は、「以上でない」が「未満」に変換できたりと、簡単です。

　ただし、注意点が2つあります。

　否定語を消して、￢A という表現を B に変換する場合に、B は A の補集合でなければなりません。AとBが、MECE であるといってもいい。
　上の例でいうと、「休日以外」＝「平日」である、つまり、「すべての日は、休日か平日のいずれかである」ことが保証されていないと、ダメです。
　たとえば、これも秋山浩一さんのソフトウェアテスト技法ドリルで学んだことですが、ISO 5218 では、「人の性別の表示のためのコード」として、4つのコードを定義しています。「男性以外」を、そのまま「女性」と変換していいかは、考慮が必要ということですね。

　そもそも、大小関係に関する日常語、たとえば「以上」「以下」「より大きい」「より小さい（未満）」という言葉自体が紛らわしい、避けろという話もあります。たしかに、不等号で表現する方が、紛れはないですね。

　英語の事例を見てみましょう。
　下の絵は、『HUNTER×HUNTER』というマンガのヒトコマです。

　この右の吹き出しのセリフ、「右手を左足を使っていない」という表現は、英語でどう訳されていると思いますか？

　「右手も左足も使っていない」と言うことを表すのに or を使うのは、ちょっと違和感がないでしょうか。
　でも、ド・モルガンの法則を使って、こう理解することができます。

　つまり、右手を使っていない、かつ　左足を使っていない、と。
　ここで and を使うとどうなるか。

　つまり、右手を使っていない、または、左足を使っていない。これだと、「どっちも使っていない」という意味にならないですね。

　命題AとBについて、次のような対応があります。

　普通の論理和にぴったり一致する表現は見当たりませんね。Google Scholar で OR を用いると、排他的論理和XORで検索されるそうです。　
　はい、あまり英語のことを書くとボロが出るので控えめにします。