地味な天秤系パズルが実はけっこう面白いと気づかされた。

"Balance scale" by Sepehr Ehsani is licensed under CC BY-NC-ND 2.0

こんな有名な問題がありますね。

8個のボールがある。7個は同じ重さで、残りの1個だけ他の7個よりわずかに重い。
天秤を2回だけ使って、重い1個を特定するにはどうすればいいか。

このような「天秤系」のパズル、どうも根気系・しらみつぶし系に思えてあまり魅力を感じず、すぐに答えを見てしまうわたしです。
そんな天秤系パズルについて、「やっぱ面白いかも！」と思える話を2つ見つけたので、紹介します。

1g刻みで重さを測る方法

元ネタはこの本です。

とてつもない数学

問題はこんな感じ。

1gから40gまでの重さを、1gきざみで量るためには、最低何個の分銅が必要か。

たとえば3gと5gの分銅があれば、3g、5g、（2つ使って）8gの重さを測ることができます。一方、1gを測ることはできませんね。

この問題を見て反射的に、IT関連の人は

両手の指10本を使って表現できる数は何種類？

という話を連想するかもしれません。元の問題は、「1から40までの数字を表現するには、指が何本必要？」と読み替えることができますよね。
たとえば18gを測りたければ、(13)₁₀=(001101)₂ なので、2⁰=1gと、2²=4gと、2³=8gの、計3つの分銅があれば済むわけです。
40gまでを1gきざみで測りたければ、2の累乗となる1g、2g、4g、8g、16g、32gの6つがあれば済みます。

ということで、「簡単な問題だな～」といい気になっていたのですが、実は6つさえいらず、4つだと。

その4つとは、3の累乗となる1g、3g、9g、27g。
いや、それだとたとえば7gなんて表現できないし、そもそも4つだと最大でも2⁴しか表現できないのでは・・・と思いません？

では、この4つで7gを測るにはどうすればいいか。
測る側に、1gと9gを載せる。測られる側に、測られるもの（7g）と3gを載せる。こうすれば釣り合う、というんですね・・・！

上の例だと

13 = 1*1 + 2*0 + 4*1 + 8*1

にように、各分銅はプラスかゼロかだったのですが、こちらの例だと

7 = 1*1 + 3*(-1) + 9*\1

のように、分銅を「マイナス」として使えるようになるというのがミソなんですね。これによって、最大40（すべての分銅を足した重さ）まで測ることができるようになるというわけです*1。

といった数学関連の興味深い話が満載の本書、高校数学くらいの知識がある方にお勧めです。

情報量から考える天秤の使い方

問題はこんな内容です。

12枚のコインのうち1枚だけ、本物と少しだけ重さの違う偽コインが含まれている。 天秤を3回だけ使って偽コインと特定するにはどうすればいいか。

このパズルとその解はよく見かけるのですが、『情報数学のはなし』ではこれを情報エントロピーの観点から説明しているのが面白いです。

情報数学のはなし【改訂版】

その説明を要約してみます。

(1)測定のパターンを洗い出す

左右で枚数が違うと意味がない*2ので、枚数は合わせます。1枚対1枚、2枚対2枚、・・・6枚対6枚、という6パターンがあります。

(2)各パターンで起きる事象と確率を整理する

たとえば2枚対2枚の時に発生する事象とその確率は、以下の通りです。

1. 左が下がる。確率は2/12*3。
2. 右が下がる。確率は2/12。
3. 傾かない。確率は8/12。

(3)各パターンで得られるエントロピーを計算する

n個の事象を対象にしたエントロピーは

H = p₁*log(1/p₁) + p₂*log(1/p₂) + ... + p_n*log(1/p_n)

なので、2枚対2枚のエントロピーは

H = (2/12)*log(12/2) + (2/12)*log(12/2) + 8/12*log(12/8)
= 0.43083 + 0.43083 + 0.38998
= 1.25163

このように整理していくと、エントロピー、つまり得られる情報が一番大きいのは、4枚対4枚を比べた場合で、1.584ビットであることがわかります。次点は3枚対3枚の1.500です。

(4)1枚を特定するためのエントロピーを計算する

コインが12枚、重さは本物より重いか軽いかの2つ、つまり12*2 = 24ケースから1つを特定する必要があるため、エントロピーは log₂24 ≒ 4.582ビット。 これを3で割ると1.527ビットで、これだけの情報量を稼げるのは4枚対4枚の測り方のみ*4。

以上から、4枚対4枚の測定を3回行うことで、このパズルを解くことができるということになるわけです*5。「解ける」ことがわかっただけで、具体的な解法を示してくれるわけではないのが、また面白いところです。

まとめ

パズルは、直観で解けるものと論理で解けるものがあり、論理一辺倒のものはあまり好きではないのですが、情報数学で捉えるとまた違った様相を呈して面白いですね！
大村平さんの「はなし」シリーズは、どれも説明が平易かつ展開も独自で、楽しんで数学を学ぶことができる好著が多いです。ぜひ。

*1:かといって表現力が単純に3⁴になるわけではない。1つも載せない場合は重さがゼロになって意味がなかったり、重複するケースがあるため。

*2:必ず傾くことがわかっているので情報量がゼロ。もちろん重さの差は、コイン1枚の重さより小さいことが前提ですね。

*3:偽コインが重く、かつ左に含まれる確率 = 1/2 * 2/12 = 1/12。 偽コインが軽く、かつ右に含まれる確率 = 1/2 * 2/12 = 1/12。 合わせて2/12。

*4:4枚対4枚を2回、3枚対3枚を1回でも4.670ビット稼げるので、この解もありうる・・・？

*5:この最後の部分が実は理解できていません。2回目の測定が1回目と独立でないと、1.584ビットを稼ぐことができないはずだけれど、独立した測定が3回できるかをどう確かめるのかがわからない。

JaSST Online Cloverで、情報発信についてお話しました。#JaSSTOnline

昨日7/31(土)に、JaSST Online CloverというイベントでLightning Talksに参加しました。

jasst.jp

第3回であるCloverのイベントテーマは「技術の発信」ということで、ブログを細々と続けているわたしにも声をかけていただいた次第です。
LTゲストは、『ソフトウェアテスト技法ドリル』の秋山さんと、『テスターちゃん』の松谷さん。 すごいお二人と一緒にお話できたことは光栄です。

ブログを続けているモチベーションは何か？などと考えたことはなかったのですが、せっかくの機会なので整理してみた資料が、コチラです。

200731 JaSST ブログにまつわる因果ループ from Kazuhiro Suzuki

発表者として加わってみると、参加者の立場では知りえなかった運営チームの準備の大変さと丁寧さが見えてきます。いや、発表者から見えるのもごく一部で、運営チームの苦労と努力は相当だと感じられました。頭が下がります。
ZoomとDiscordとCommentScreenとJamBoard（とTwitter）という各種サービスを併用しての仕組みは、オーバーテクノロジー過ぎてわたしには理解しきれず、「すげえな」しかありませんでした。

事前に、音声・映像・画面共有ができることを何度か確認させていただき、その際「音が聞き取りづらい」というご指摘を受けたため、「いやいや、これは仕方ない、買わざるを得ない」と超正当化してマイクまで買ったのですが、

HyperX SoloCast USBスタンドアロンマイク テレワーク/ストリーマー/コンテンツクリエーター/ゲーマー向け/PC,PS4,PS5使用可能 2年保証 HMIS1X-XX-BK/G

当日は、機器不調、ネットワーク遅延、資料先祖返り、妻子の闖入など様々なトラブルに見舞われ（全部自分以外のせいにしている）、運営チーム、参加者のみなさんに大変ご迷惑・ご心配をおかけしました・・・。結局マイクも活躍せず。。。

ともあれ、OSTも含めてとても楽しいイベントでした。みなさま、ありがとうございました。

JaSSTは、無印、Review、OnlineそしてNanoと、展開が続いています。オンラインならではの参加しやすさを活かして、どんどん参加しましょう！

『THE CULTURE MAP』が教えてくれる、国民性の8つの軸

　「日本人ははっきりとNoを言わず、米国人は何でも包み隠さずに直言する」。
　こういった「国民性のイメージ」は誰しも、多かれ少なかれ持っているでしょう。
　さすがにそこまで単純ではないにせよ、考え方や習慣は、国や地域ごとに無視できない傾向があるようです。

　「●●の国の人は約束の時間にルーズ」「▲▲の国の人は結論から話さない」、こういった国民性（のイメージ、場合によっては偏見）の断片を、もっとシステマティックに把握・理解することはできないものでしょうか。そして異文化のメンバーをチームを組む際に、効率的に信頼関係を築くことはできないでしょうか。

　これに答えてくれるのが、Erin Meyer・著、『THE CULTURE MAP』です。

The Culture Map: Decoding How People Think, Lead, and Get Things Done Across Cultures

　Erinさんは、ビジネスシーンで重要な要素を8つの軸で表現し、その軸上に各国をマッピングしています。

　たとえば第1章で扱われる Communicating Scale。
　この軸では、左に Low-context、右に High-context を配しています。
　もっとも Low に位置するのが米国人で、もっとも High に位置するのが、わたしたち日本人。

　ハイコンテキスト・ローコンテキストという言葉は、最近でもよく使われるようになってきましたね。
　日本や中国のように、歴史が長く、人間関係が世代間を通じて継承されていくような国の人間は、「空気を読み」、相手の暗黙的なメッセージを拾い上げることに長けていると説明されます。
　一方米国のように国としての歴史が短く、また多くの異文化が移民とともに入ってきたような国では、メッセージを明白に、できるだけ曖昧さを排除して表現することが重要とされています。

　と、第1章のこの話はそんなに珍しい話ではありません。
　ではそんなわたしたちは、部下に対するネガティブなフィードバックをどのように伝えるか。これが第2章のテーマです。

　第2章で扱う Evaluating Scale は、部下を評価する際の伝え方を表したもので、左に Direct negative feedback、右に Indirect negative feedback を配した軸です。あからさまに伝えるか、オブラートに包むか、ということですね。
　この2つの軸の4象限に国をマッピングしたのが、こちらです。

Communicating と Evaluating の2軸（『THE CULTURE MAP』より引用

　日本人は意外性なく、またもや一番右。直接的にネガティブなことを言わない強い傾向があります。
　一方米国人。Communicating Scale では最も左にいた米国人が、Evaluating Scale では真ん中あたりに位置しています。
　米国における評価では、「ネガティブなことを伝える前に3つポジティブなことを伝える。そして a few small suggestions といった前置きで、ネガティブなメッセージを極力やわらげて伝える」というのです。米国人は常にはっきりと物事を伝えるという単純なステレオタイプだけで米国人に接すると、大変な軋轢をもたらしかねないということですね。

　第4章で議論される Leading Scale は、コミュニケーションの仕方に地位や役職がどの程度効いてくるかを表現したもの。左が Egalitarian（平等主義）、右が Hierarchical（階層主義）。日本がここでもまた Hierachical に全振りしているのに対し、米国は左寄り。階層間の壁が相対的に薄いとうことで、ここには意外性ないですよね。

　一方第5章で扱う Deciding Scale、決定の手続きの傾向においては、米国は Consensual（コンセンサス型）ではなく、Top-down（トップダウン型）に寄っているんですね。ふだんのコミュニケーションにおいては比較的フラットな文化を持ちながら、決定においては地位の高いものの意見が強く優先される。これもまた「米国は人間関係がフラットだし、民主主義の国だから・・」などと思い込んでいると、誤ってしまいそうです。
　さらに、そもそも「決定」の意味・重みが国によって異なるという要素もあり、話はさらに面白くなっていきます。

　本書ではこのような軸8本を、それぞれ豊富な事例とともに紹介しています。
　もちろんこの8本をもってなお、国民性を表現するには十分ではなく、依然としてステレオタイプの部分もあるのかもしれません。特に日本人を引き合いに出している部分を読むとやはり「そんなに単純じゃないよ」なんて思ってしまいます*1。また同じ国の人間でも、個々人の特性もそれぞれ異なるでしょう。

　それでもなお、相対的な傾向と注意点を知っておくことには価値があると思います。
　いきなり人を殴りつけることは万国共通で無礼だとしても、ある国で当たり前、むしろ適切であるとされることが、他の国では失礼・マナー違反・プロフェッショナルでない、と受け取られることが、思った以上に多いのだということを思い知らされるのです。
　特に日本人は多くの軸において極端な位置にマッピングされており、変な民族なんだな～ということをあらためて感じさせられました。以下は、Harvard Business Reviewのサイトからの引用です。

マネジメントスタイル

　なお本書は、比較的な平易な英語で書かれており、英語を読む練習をしたい人にはぴったりだと思います。Audibleで、オーディオブックも提供されています*2。
　わたしは修業のため、オーディオブック＋本書でシャドーイングしながら意識高く読みました。英語の勉強にも良いコンテンツです！

www.audible.co.jp

*1:日本人との親睦を深めるには飲みにケーションが一番！といい切られてしまうと、うーん・・・となってしまう。いや、飲みにケーション好きですが。

*2:Audibleは毎月1枚コインが付与され、このコイン1枚でオーディオブックを1冊聴くことができます。要は、無料で聴けます。

Veriserveのテスト設計サポートサービス、GIHOZを触ってみる - その3

"Naked tree" by Ivan Naurholm. thanks, for more than 500.000 views is licensed under CC BY-NC-ND 2.0

　GIHOZでクラシフィケーションツリー*1がサポートされたということで、練習も兼ねて触ってみました。

gihoz.hatenablog.com

　お題は、@halspringさんのこちらの記事の例です。

halspring.hatenablog.com

　結果として、大きく戸惑ったりすることなく、さわやかに作ることができました。
　各種モデリング技法が1つのプラットフォームで扱えるのはとても便利で、クラシフィケーションツリーの普及にも一役買いそうです。

クラシフィケーションツリーの例

　気になった点は以下です。

• ツリーが大きくなると画面内に収まらなくなり、一覧性が失われてしまう。
  →不要にパラメタを組み合わせ過ぎているかも、木を剪定するタイミングか？と考える契機になるかもしれない(笑)。

• 初期状態で、第2階層のクラシフィケーションにすでにクラスが生えているため、隣にクラシフィケーションを生やすことはできない。
  これ自体はクラシフィケーションツリーの仕様（のはず）だけれど、ぱっと見、「ルート以外にはクラシフィケーションを生やせない」と思ってしまいそう。
  →初期状態の第2階層は、クラシフィケーションからクラスが生えているノードと、クラシフィケーションからクラシフィケーションが生えているノードにしておくとわかりやすそう。

• クラスからクラシフィケーションを生やすことはできなさそう。
  →なので、井芹さんの資料P.17のような絵は描けなかった。

　あと、これは他の技法でも同じことを書いたのですが、テスト設計のモデリングにおいては「意図」がとても大事なので、それを残せればなーと思います。

　先の@halspringさんの記事には、このように書かれています。

クラシフィケーションツリー法では人の意思を介入させることができます。

.

テスト対象の特徴や要件に合わせて網羅基準や水準の選定基準を考えます。

　「こういう根拠で、このように設計した」という意図を残しておくことは、その後でテストケース不足による欠陥流出が起きたときに「どこで」間違ったかをトレースできるようにしておくということです。
　記法に沿ってモデルが簡単に描け、そこからまた簡単にテストケースを導出できる。これはGIHOZのようなツールにお任せして、ヒトはその「意図」「根拠」をよく考え、確実に残しておくことが重要だと考えます。

---

　GIHOZを触ってみた過去記事は、以下です。

www.kzsuzuki.com www.kzsuzuki.com

*1:　クラシフィケーションツリーの概要については、安定の井芹さんのスライドがわかりやすいです。

クラシフィケーション・ツリー法入門 from H Iseri

www.slideshare.net

テストオラクルとは何か

"File:Chinese oracle bone (16th-10th C BC) - BL Or. 7694.jpg" is licensed under CC0 1.0

　ソフトウェアテストの有識者の方々と、「テストオラクル」について話す機会があったので、自分なりの理解を整理しておきます。

　まずはおなじみ、I/JSTQBの用語集から。

テストオラクル（test oracle）
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。

　要するに、期待結果を作るための元ネタでふね。

　ここで2つ、気がつくことがあります。

1. （少なくとも明示的には）仕様書はオラクルと見なされていない。
   　→ オラクルにはどんな種類があるのか
2. オラクルは、期待結果そのものではない
   　→ オラクルが期待結果そのものではないとは、どういうことか

　本記事では、この2点について考えてみたいと思います。

オラクルにはどんな種類があるのか

　「期待結果のソース」というオラクルの定義を考えれば、明記こそされていないものの、仕様書自体もオラクルに含めてもかまわないでしょう。
　これを含めれば、オラクルは以下の3つに分類できます。

そのソフトウェアをふるまいを記述したドキュメント

　仕様書、ユーザマニュアルなどがこれに当たります。

比較対象にできるソフトウェア

　まず、用語集で「ベンチマーク」と表現されているものがあります。Cem Kaner氏は、Microsoft Officeの競合品としてOpenOfficeを開発しているとすると、OpenOfficeの動作が「正しいか」は、Microsoftの「Word」が教えてくれるとしています*1。

http://www.testingeducation.org/k04/examples/obas05s.htmlwww.testingeducation.org

　またJRの運賃計算では、膨大なテストケースの期待結果を、1つ1つ人間が考えるのではなく、Nバージョンプログラミング、つまり同じ出力を持つシステムを複数作って突き合わせるということをしています。

www.publickey1.jp

テスト対象となる実機用の運賃ソフトウェアと、検証用の運賃ソフトウェアは別のチーム、別のアルゴリズム、別のプログラミング言語で作ります。実機用はC++ですが、検証用はJavaで言語特有のバグをなくそうとしています。でも検証用のソフトウェアにはそんなに予算が掛けられず少人数で作っているので、実機用はどうやって作ったのか聞きたくなるのですが、そこを我慢して作る。

過去の履歴

　「そのソフトウェアの前バージョンと同じ動きであれば問題ない」というオラクルもあります。リグレッションテストは、「過去の想定した期待結果の通りに動作する」ことを確認するので、テストオラクルの一覧ということができるでしょう。

人間の知識

　用語集では「専門家の知識」とあります。
　ですが、たとえば文字判別のソフトウェアにおいては、一般の人が「妥当」と考える常識的な判断がオラクルになりうるでしょう。

その他

　メタモルフィックテスティングはちょっと異色で、「正しいことがすでに分かっている期待結果」を派生させていくものです。

www.kzsuzuki.com

　このように、「期待結果のソース」は様々な種類があることがわかります。

オラクルが期待結果そのものではないとは、どういうことか

　oracleとは、神託のことですね*2。
　世界観がぐちゃぐちゃですが、こういう絵になります。

神と神託

　神からのお告げを巫女さんが受け取ります。お告げは神秘と暗示に満ちていますから、解釈が必要です。専門職たる巫女さんがこれを解釈し、人々に伝えます。
　このアナロジーから言えることが、これまた2つあります。

• 間違いが入り込む
• 細かいことを教えてくれるとは限らない

間違いが入り込む

　まず、巫女さんが間違えます。
　たとえば「18歳以下は無料」という仕様を、「18歳であれば有料」と解釈してしまうと、誤った期待結果を得ることになります。

　次に、神が間違えます。
　神の無謬性を信じたいところではありますが、ソフトウェア開発において神託を告げるのは神ならぬ人。「仕様通りの動作である」ことがテストで確認できても、「間違った仕様通りの動作」なら意味がありませんね。

細かいことを教えてくれるとは限らない

　たとえば神たるお客様が「性能要件は、“旧システムと同様“ね～」と重々しく宣われたとしましょう。このオラクルは、システムのあらゆる性能要件を余すところなく記述したものと言えますが、「旧システムの性能を一つ一つ確認する」という「解釈」なしには、何も言っていないのと同じです。
　つまり、オラクルがあったとしても、テスト設計においてはそれを解きほぐす必要があるかもしれない、ということです。

まとめ

　まとめると、「適切なオラクルを適切に解釈しないと、適切な期待結果は得られない」という、ごくごく当たり前の結論になります・・・！

*1:まったく同じ話を過去記事でも書いていました・・・ www.kzsuzuki.com

*2:甲骨のことは、oracle bone というらしいです。