ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

積読をしがちなエンジニアに届けるケチケチ勉強法

新しいことについて学びたいんだけれど、まだ単語レベルの知識しかない。
書店に行ってみるとたくさん本があって、どれを選んで読んでいいかわからない。
仕方なくAmazonのレーティングとレビューを見て買ってみたものの、何か合わない

そんな経験をしたことはないでしょうか。
わたしは超あります。でもそれなりのお金を払って買った本だから処分することもできず、積読。。。

本が「合わない」理由

買ってみた本が「合わない」理由はいくつかあります。

レベルが合わない

たとえば技術書にはそれぞれ、想定する読者がいます。気の利いた本なら、本の最初の部分に、その「想定する読者」や「前提知識」まで書いてくれています。これに合う本を読むことが大切です。

目的が合わない

技術の全体を俯瞰したい人と、その中の特定のことについて深掘りしたい人では、必要な本は違ってくるでしょう。
その人の目的と、本の意図が合っていないと、不幸なことになります。

デザインやノリが合わない

ぶっちゃけわたしは、表紙のジャケ買い、フォントの大きさと行間の広さ、「せっかくだからシリーズで揃えたい」みたいな、まったく本質的でない理由で技術書を選んで、1と2の理由で自分に合わず、失敗することが多いです。 でもそれくらい、見た目とか論調って大事なんですよ・・・それが合わないと買う気がしない。

以上のような理由で本を積んでしまうと、自分だけでなく、積まれてしまった本にとっても不幸です。

図書館貯蔵本濫読メソッド

そんな時にわたしが採用しているケチケチ勉強法・「図書館貯蔵本濫読メソッド」を紹介します。
やり方は単純。名前を付けるまでもない。

  1. そのテーマの本をかたっぱしから図書館で借りる。
  2. 難易度と、できればもう1軸くらいを見つけて、それぞれの本をマッピングしてみる。
  3. 自分の目的とレベルに沿って、勉強に使う本を決める。
  4. 選んだ本を買って勉強する。

これで、勉強を始めるコストが限りなく低くなります。

1. 図書館で借りまくる

図書館のWebサイトの検索は充実しているし、最寄りの図書館になくても市内であれば取り寄せしてくれたりもします。
「ソフトウェアテスト」なんて比較的マイナーな分野でも、意外に蔵書があったりします。わたしの地元だと6冊もありました。

当然ですが、図書館で扱う技術書のカバー率は高くなく、できるだけ「広く読まれる」本が多くなる傾向があります。
でも、右も左もわからないモノを学ぶのですから、その手の本で最初は十分なのです。

たとえばAWS(Amazon Web Services)について、すぐに借りられる本を4冊読んでみました。
なおこの時点での「読む」の目的は、深い理解ではなく、本の傾向をつかむことです。合わなければ読むのをやめて返せばいいです。

  1. Amazon Web Services入門 ― 企業システムへの導入障壁を徹底解消
  2. Amazon Web Services 徹底活用ガイド (日経BPムック)
  3. AWSクラウドの基本と仕組み
  4. Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂3版
  5. Amazon Web Servicesインフラサービス活用大全 システム構築/自動化、データストア、高信頼化 (impress top gear) *1
2. 本をマッピングする

複数の本を読んでいくと、同じテーマを扱っていても、それぞれ立ち位置が微妙に異なることに気づきます。
AWSの本の場合だと、分類の軸として、「難易度」に加え、「ビジネス寄りか、技術寄りか」という軸があると感じました。

難易度というのは絶対的な尺度ではなく、自分が読んでみて平易と感じたか難解と感じたかという主観です。人によってもっている知識が違うので、他の人にとっては相対値ですね。

ビジネス⇔技術 という表現は妥当かわかりませんが、たとえば「オンプレの自社システムをパブリッククラウドの移行したいのだけれど、AWSのビジネス・課金・契約はどういうものなのかを知りたい人」*2と、「AWSにアカウントを作ってとりあえず触ってみたい人」*3では、必要とする本がまったく違います。

上の5冊をわたしの主観でマッピングすると、以下のようになりました。

f:id:kz_suzuki:20210815164831p:plain
AWSの本をマッピングしたマトリクス

図書館の本なので、「易しい」寄りの本が多いことがわかりますね。
当然ですが、このマトリクスのここにあるからいい本だ・悪い本だ、ということを意味していません。

3. 本を決める

わたしのレベルと目的を踏まえると、まずCを読んで全体を理解し、Dで手を動かしてみる、というのがよさそうに思えます。勉強の進め方は以下のようになります。

f:id:kz_suzuki:20210815165223p:plain
マトリクスから検討した勉強の針路

せっかくなので、CとDがどんな本か、紹介してみましょう。

↑この本は、AWSの主要サービスについて、技術的な解説も含めて概観的に網羅しています。全体を知りたい、忘れたときにぱっと概要を思い出したいという目的に合いそうです。
主要なサービス、VPC・S3・EC2・Lambdaなどについては、やや詳しく「このように使える」といったところまで説明されています。詳しい仕様や設定方法は対象外です。

↑こちらは、AWSを実際に使ってWordPressのサービスを立ち上げるところまでを案内しています。そのために必要なAWSサービスに解説を絞っている代わりに、スクリーンショットレベルで手順を詳説するものです。
また、AWS以前に必要な知識、たとえばネットワークなら、IPアドレス・DNS・ルーティングといった技術の基本的な解説もカバーしているため、「AWS以前の勉強から必要だった・・・」とならないですむようになっています。スクショ&基本技術解説となると分厚くなりそうなものなのですが、200ページちょっとで収めているのがすごい。

4. 勉強する!

するだけです。簡単ですね?*4

図書館で借りられる本の特徴と注意点

特徴
  • 書店では手に入りづらいムック(日経BPがよく出してる)を入手しやすい。
  • 資格関連の本はあまりないかも。たとえばAWSだと、認定関連の本が少なかったです。
  • 古い本も混じってきます。たとえばAWSについて調べるのに、5年前の本だときっと古い情報も多いでしょう。
注意点
  • いっぺんに借りると、同じテーマを勉強したい人に迷惑なので、避けましょう。
  • 技術書に限らず、人気のある本、良い本は貸出中の可能性も高いので、「そうでない本」が手元に集まりやすいという欠点があります。
  • 「イイ!」と思った本は、著者の方に感謝し、お金を出して買いましょう
  • いや、公式ドキュメント読めよ!というのはその通りなので、次のステップではそうしましょう・・・。

レビューコメント

Amazonのレビューは参考になりますが、レビュアがその「想定する読者」に合っていたのかどうかまではわかりません。
たとえば「初歩的なことしか書いておらず、実務ではまったく使えない」というレビュー。レベル5の人向けに書いた本をレベル10の人が読めば、そうなるでしょう。でもレベル5の人には必要十分かもしれません。

このようなレビューコメントを見てしまうと、買うのにちょっと躊躇してしまいますよね。
なのでAmazonの評価はあまり気にしない方がいいですが、「事実誤認が多い」とか「内容が古い」、この辺は多少気にした方がよさそうです。

まとめ

図書館を利用して合う本を見つけ、合う本には金を払い、合う本で勉強しましょう。

YDS Library"YDS Library" by Chris and Amy Stroup is licensed under CC BY-NC 2.0

*1:この本は図書館ではなく、買った本。

*2:こういう方向けには導入として、上のAの本が合うと思います。

*3:こういう方向けには、上のBの本もいいでしょう。

*4:と書くととても勉強している風ですが、自分を追い込むだけのプレッシャーにすぎません。

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

Balance scale"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)10=(001101)2 なので、20=1gと、22=4gと、23=8gの、計3つの分銅があれば済むわけです。
40gまでを1gきざみで測りたければ、2の累乗となる1g、2g、4g、8g、16g、32gの6つがあれば済みます。

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

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

では、この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 = p1*log(1/p1) + p2*log(1/p2) + ... + pn*log(1/pn)

なので、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つを特定する必要があるため、エントロピーは log224 ≒ 4.582ビット。 これを3で割ると1.527ビットで、これだけの情報量を稼げるのは4枚対4枚の測り方のみ*4

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

まとめ

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

*1:かといって表現力が単純に34になるわけではない。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ゲストは、『ソフトウェアテスト技法ドリル』の秋山さんと、『テスターちゃん』の松谷さん。 すごいお二人と一緒にお話できたことは光栄です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

f:id:kz_suzuki:20210711194656p:plain
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のサイトからの引用です。

f:id:kz_suzuki:20210711195919p:plain
マネジメントスタイル

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

www.audible.co.jp

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

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

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

Naked tree"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つのプラットフォームで扱えるのはとても便利で、クラシフィケーションツリーの普及にも一役買いそうです。

f:id:kz_suzuki:20210711111418p:plain
クラシフィケーションツリーの例

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

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

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

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

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

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

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

.

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

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


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

www.kzsuzuki.com www.kzsuzuki.com

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

www.slideshare.net