2019年に読んで好きになった本

　「今年の漢字」を個人的に選ぶとしたら、わたしはまっさきに「A」を選びます。そう、「インフルエンザA型」のAですね。
　保育園恒例のクリスマスプレゼントとして次男がまずもらい、それでも治る頃にはギリギリ帰省の予定には間に合うという日程感と思っていたところで長男がそれを引き継ぎ、帰省はあきらめたけれどせめてゆっくり自宅で年末年始を迎えようと思っていた矢先にわたしの頭が痛くなり普段感じない足のけだるさを覚えながらも病院は開いていないのでインフルかどうかは確定していません。

　年の瀬なので、2019年に読んでとても好きになった本のうち、Evernoteにまともにメモが残っているものを紹介します。
　わたしは貧乏性のためあまり本を買わず、一般本は市の図書館で、技術本は会社の図書室で、マンガはゲオで借りることが多いのですが、以下の本は「これは買って手元に置いておこう」と思った本ばかりです。なお、新刊ばかりではありません。

IT技術関連

リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

　今年は朝活の一環として、PyQでPythonを勉強し始めました。「未経験からのPython文法」というコースでまだ少し残っているのですが、やはり書いて動かして直して・・・というループで勉強するのはいいなと感じています。

　『リーダブルコード』は、各プログラミング言語固有の文法を解説するのではなく、言語に（あまり）依存しない、より一般的な「良いコード」の書き方について教えてくれます。変数の使い方、名前の付け方といった基本的な話題から始まるので、仕事としてプログラミングをする機会に乏しいわたしが読んでも、たくさんの学びのある内容でした。何度も読み直すと思います。

Web API: The Good Parts

Web API: The Good Parts

　仕事でAPIに関わる機会が増えてきたので、入門書として手に取ったものです。
　ソフトウェアには、機能性に加えて、性能や信頼性といった品質特性が求められますが、Web APIの場合、「他の多くの開発者に使ってもらうための利便性、理解容易性」といった、ちょっと特有の特性も求められます。
　本書では、Web APIの基本を概説したうえで、これらの品質特性を高めるためにはどのように設計すればいいのかということを丁寧に説明してくれます。設計に絶対の正解はないことから、世の中の巨大Webサービスの事例を挙げつつ、著者自身の見解も交えてくれるので、とても分かりやすい内容になっています。

現場で役立つシステム設計の原則

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

　「システム設計」はなかなかコンテキスト依存な言葉にも思えますが、SIer的な言葉でいえばこれは「内部設計」、つまりソフトウェアを使用する分にはあまり意識しないけれど、性能・保守性・拡張性・可読性などにガンガン響いてくる、「プログラム全体をどう組み立てるのか」の部分を指してい（ると思い）ます。
　初めはリファクタリングの話が出てきたので、きれいなソースコードの書き方の話なのかと思いましたが、テーマはもっと広範。「オブジェクト指向で拡張性の高いソフトウェアを作るには、全体と部分をどう設計すればいいのか」ということが、著者の熱い思いとともに述べられています*1。これも読み込むほどに発見の多い本のようなので、読み返すことが多そうです。

ノンフィクション

FACTFULNESS

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

　いやもうこれは今年ナンバーワンでした。売れるだけあります。FACTFULNESS自体を疑えという姿勢も好き。
　ブログの記事を書きました。

www.kzsuzuki.com

AIと憲法

AIと憲法

　この本は実はまだじっくり読めていないので感想文を書く資格がないのですが・・・、
　AI、機械学習、深層学習を技術的な側面で解説してくれる本はたくさん出版されていますが、憲法・法律、人間の権利・ロボットの権利、保険、社会規範、といった社会学的な側面から解説してくれるのがこの本です。

　たとえば、AIによるプロファイリングの精度が上がり、効率的な運用のために人間の関与がなくなっていくことが予想されます。この場合、AIに何らかのバイアスや誤りが含まれていたとき、継続的に不利な扱いを受ける人が出てくる可能性があります。
　これに先立ってGDPRでは、

データ主体は、当該データ主体に関する法的効果をもたらすか又は当該データ主体に同様の重大な影響をもたらすプロファイリングなどの自動化された取扱いのみに基づいた決定に服しない権利を持つ

とすでに規定しているうえに、必要とされる人間の関与が「やってるフリ」だけにならないように、実質的なものであることを保証しなければならないとまで念押ししているとのこと。
　これからAIが当たり前になっていく社会で、このような法規制が技術の進化の足止めになるのではというよくある批判をものともせず、論ずるべきことを正しく論じていくという論者のみなさんの姿勢が強く表れている本です。 　

国旗で読む世界史

国旗で読む世界史(祥伝社新書) (祥伝社新書 515)

　大学生の時から「国旗」に関わり続けてきた著者による、国旗にまつわるエピソード集。国旗が新しく作られる時、掲げられる時、変わる時、そこにはたくさんの重いドラマがあるのだなと感じさせられます。
　著者は多くの国際行事に関わっており、この世界では重鎮といえる存在なのでしょうが、そのキャリアをことさらアピールするわけでもなく、丁寧で中立的な視点で書かれています。それぞれのエピソードはせいぜい4ページほどに丁寧にまとめられており、飽きがこない。読み物としても面白く、また勉強になる良著です。

　たとえば、「月面のあの米国旗は、まだあるのか？」というトピックがあります。NASAの調査によると、6本中1本を除いてすべて存在しているとのこと。ただ・・・、
　この先は、ぜひ読んでください。

小説・マンガ

恋は雨上がりのように

恋は雨上がりのように（１） (ビッグコミックス)

　これはおじさんが絶対に読んではならない本だし、間違って読んでしまったら最後まで読まざるを得ないし、なんならAmazon Primeでアニメ版まで観てしまうやつ（実写版は観ない方がよさそう）だし、「これは買って手元に置いて」おいたら家族に誤解されてしまうので買えないやつなんですけれど、これはおじさんは読んだ方がいいですよ。

　あらすじとして、「45歳のファミレス店長さえないバツイチ男に17歳女子高生が恋をする」という、おっさん向けのあざといやつかと思ったら・・・とてもよかった。今のはよかったぞーーー！
　さらにいうと、エンディングテーマのAimerの『Ref:rain』の曲もいいしPVも至高すぎるんですよね・・・。このPVから一本映画起こしてもらえませんかね？

www.youtube.com

かぐや様は告らせたい

かぐや様は告らせたい～天才たちの恋愛頭脳戦～ 1 (ヤングジャンプコミックスDIGITAL)

　これまだ6巻までしか読んでないから絶対先の話ネタ晴らししてほしくないんですけれど、今年のナンバーワンノンフィクションが『FACTFULNESS』なら、ナンバーワンマンガは絶対に『かぐや様は告らせたい』なんですよ。もう何ていうかぶっちぎりに面白いです。

　ラブコメです。で、「コメ」成分が強めのラブコメなんですけど、急に「ラブ」成分の濃度を急上昇させてくる。
　よくTwitterに上げられたマンガを読んで「尊い」とか「語彙力を失う」とかいう本当にハイレベルなレスを付ける人たちがいますが、いやほんとこれは語彙力を根こそぎ奪ってくほどの破壊力なんです。「コメ」単体でもものすごく面白いのに、「ラブ」の落差で大ダメージを与えてくる、これは恐ろしい才能ですよ。
　全然マンガのあらすじに触れていませんけれど、とにかく読むべきです、特に5巻はラブがコメり過ぎてて語彙力が語彙り過ぎてしまいました。煩悩にまみれすぎて同じシーンを108回くらい読み返してしまいました。

デビルズライン

デビルズライン（１） (モーニングコミックス)

　すみません、これもまだ途中までしか読んでいないのですが、本当によい作品です。
　どんな話かというと・・・、まずAmazonから。

都会の喧騒の裏で連続発生する吸血殺人。ある日、恋愛に疎い大学院生・平つかさは、自分にじっと向けられた男の視線に気づく――。愛と欲望、暴力と献身が交錯するダークファンタジー第1集！

　メチャクチャ面白くなさそうじゃないですか！？
　Wikipediaの方がまだマシです。

吸血欲をもった「鬼」と呼ばれる存在が静かに息づく現代日本。人と鬼のハーフであり、警視庁公安五課で鬼の犯罪を取り締まっている安斎結貴は、捜査の最中、大学院生の平つかさと出会う。惹かれあう2人は、やがて鬼の抹殺を企てる組織「CCC」や、それを裏で操る黒幕の陰謀に飲み込まれていく。

　でもね、これすごくいいんですよ。主人公含め、ほとんど鬼は、「病気みたいな」自分の性質に苦しんでいる。人間たちに疎まれ、恐れられ、危険視される自分たちの存在にもがいている。
　この作品を底をずっと流れているのは、「悲しみ」です。鬼の姿に変異し、血を求めてしまう自分への怒りと悲しみ。話が重くなり過ぎないように注意深く軽いテンポも交えていますが、鬼たち、人間たちがそれぞれ抱える過去、葛藤、やり切れなさが、作品全体を覆っています。

　そこにサスペンス。鬼を狩ろうとするもの、鬼を守ろうとするもの、誰が味方で、誰が敵なのか。登場人物はそれほど多くない、にも関わらず張り巡らさせる複雑な関係性。ラブとサスペンスと、「鬼」というギミック、この組み合わせに「悲しみ」というスパイスを効かせた『デビルズライン』、もう完結しているようなので、この正月に一気に読むぞ！

おわりに

　最後の方ちょっと語彙が乱れてしまいましたが、今年もたくさんの良い本に巡り合えました。良い本はちゃんとお金を出して買って、著者の方にまた良い本を書いていただきたいと思います！

*1:Amazonのネガティブレビューは、この部分を批判しているものもあると思う・・・

テストケースの期待結果と事後条件の違いについて考えてみる

　Peing*1でのにしさんへの質問で一瞬、テスト関連用語について議論が起きたので、自分の考えを整理しておきます。

　質問の内容は、「期待結果」と「事後条件」の違いについてでした。 peing.net

　これを見てのわたしのツイートは以下です。

　一方、須原さんは以下のようなご意見でした。にしさんのコメントもぶら下がっています。

ISTQBの当初の意図は知らないけど、期待結果と事後条件はoutputかstateかで分けてるんだと思うんだよね。たとえば、赤色のLEDがつくこと、だったらoutputでもあるし、stateでもあるので両方に属する。stateは観測可能でない、が前提で。事後条件がテスト実装に使える、は結果論なのかなと。

— Hidetoshi SUHARA (@suhahide) 2019年12月9日

　正直言って、須原さんのご意見のような観点では考えたこともなかったので、定義から読み直した次第です。

I/JSTQBの定義

　まず基本に立ち戻って、ISTQBの定義の確認からしてみました。

期待結果（expected result）
The predicted observable behavior of a component or system executing under specified conditions, based on its specification or another source.
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの観測可能な振る舞い。
　
事後条件（postcondition）
The expected state of a test item and its environment at the end of test case execution.
テストケースの実行終了時に、テストアイテムやその環境が満たすべき状態。

　いくつかキーワードがあるので、順に検討してみます。

観測可能

　期待結果の定義にある「観測可能な振る舞い」という言葉は、大きなポイントになりそうです。
　しかし、「観測可能でない」としたら、その事後条件が満たされていることをどのように確認すればいいのでしょうか。二つの考え方があると思います。

考え方1: 事後条件は確認すべき対象でない

　確認すべきなのは期待結果であり、事後条件はそもそも確認しなくてもよい。あくまでもテストケースに対する付加的な情報である。という考え方です。
　では何のためにそんな情報を明示するのか。それは「テストケースの接続」のためです。これについては後述。

考え方2: 事後条件は、当該テストレベルでは観測可能でない

　原理的には観測可能だけれど、そのテストケースの位置づけ的には観測ができないという考え方です。
　意味不明なので具体例で考えましょう。

　こちらのサイトに、期待結果と事後条件の違いについての質問が載っています。
　銀行の顧客が、ATMで口座からお金をおろすユースケースです。

pm.stackexchange.com

　BillThorさんの回答は以下のようになっています（意訳）。

• 事前条件: 顧客の口座には、おろす金額に対して十分な残高があること。
• 期待結果: 現金が引き出されること。
• 事後条件: 取引が記録され、顧客の残高はおろした分だけ減っていること。

　テストでは、取引の記録も残高変化も「観測可能」でしょう。
　ですが、システムテストレベルでユースケーステストを行う場合、視点はユーザであり、ユーザがデータベース上のレコードやログを「観測」することはない。「ログが出力されていること」はもっと前のテストレベルで確認済みのはずです。

　このように、テストレベルやテストタイプに応じて、テスターの確認目的に合致するものが期待結果で、それより「内部」あるいは粒度の小さいものが事後条件と捉えることもできると思いました。

ふるまいと状態

　ふるまいと状態は確かに別のものではありますが、「期待結果か事後条件か」を判断する際に有効な情報とは思えませんでした。
　須原さんはブログ記事で、以下のように書いています。

note.com

やっぱりstateかそうでないかがカギですよね。期待結果として見られるものはなんらかのふるまいであり、もし状態が期待結果となるのであればそれは状態が結果としてふるまいになっているだけであると考えると区別はできそうです。

　ふるまいの結果が状態になっているとしたら、そこに区別の必要性があるのか・・・がまだ咀嚼できていません。

テストケースの接続

　テストケースが多数あると、それを効率的に実行していくために、テスト開始前とテスト終了後の状態を意識する必要があります。

　これにも二つの考え方があるでしょう。
　一つ目は、自動テストでよくいう setup / teardown です。テスト開始前と終了後の状態がいつも同じになるようにしておけば、テストの順番の重要性は薄れます。

　もう一つは、「テストをつなげる」ことです。テストAの終わった状態と、テストBの始まる状態が一致していれば、テストAとBは続けて実行することができるわけです。たとえば、ログアウトのテストの後にログインのテストをするより、ログインしてからログアウトする方が自然でしょってことですね。

　事後条件の定義に「環境」という言葉があるのもポイントです。
　たとえば、「有線ネットワークが物理的に切断された場合のエラー処理」を確認したいテストケースがあるとします。この場合、テスト後には「ネットワークが物理的に切断されている」ことになりますが、これはテストで確認したいこととは関係がないので、期待結果ではなく事後条件に入るでしょう。
　そしてこのテストケースの後に別のテストケースを接続したければ、「ネットワークが物理的に切断されている」ことを事前条件にもつテストケースを探してくるか、あるいはもっと単純に「ネットワークを物理的に接続する」作業が必要になります。

　テスト対象のソフトウェアやテスト環境を含めたこれらの「状態」を形式的に記述できれば、最適なテスト実行プランを自動的に導くこともできるでしょう。*2

秋山さんの捉え方

　秋山さんは、また違うことを教えてくださいました。

JSTQB的に言えば、テストで検証したいこと（＝テスト条件）に対する検証エビデンスが期待結果です。
事後条件はカズさんのいう使い方もありますが、事前条件からの変化を書きます。

— あきやま🧌 (@akiyama924) 2019年12月9日

　考えてみると、わたしはそもそも「事前」と「事後」を明確に対応させて記述していたかも怪しいです・・・。

まとめ

　定義からいろいろ考えてはみたものの、特に正解を提示できるわけではないです。自分の意見をまとめておきたいだけ・・・。
　ということでわたしの暫定的な理解を要約すると、以下。

1. 期待結果と事後条件は、当該テストケースのテストレベルにおいて観測可能かどうかで区別する。
2. 期待結果は、当該テストケースを pass にするための必要条件である。
3. 事後条件は、当該テストケースを pass にするための十分条件であるが、pass / fail に関係のない情報も含まれる。
4. 事前条件と事後条件を組み合わせることでテストケースを接続し、効率のよいテスト手順を提案することができる。

*1:「ペイング」と発音することを今知った

*2:まるでもう自分がやっているように描いていますが、やっていません。

判定器の「よしあし」に関するメトリクスを確認しておく － その2

　機械学習の分類性能の指標として、「AUROC」「AUR-ROC」という言葉もよく出てくるので、Excelでいじってみました。
　AUROCとは、「受信者操作特性曲線の下の面積」という直訳になりますが、意味不明ですね。

　では前回に続いて、陽性か陰性かを分類するプログラムを考えてみます。

www.kzsuzuki.com

判定の閾値と性能メトリクスの変化

　この分類がゼロイチではなく、「75%の確率で陽性」といった「確信度」で表現される場合、これを陽性に倒すか陰性に倒すか、閾値を設けることになります。
　閾値を「50%以上」と設定すれば、75%の分類は「陽性」判定。閾値を「80%以上」と設定すれば、「陰性」判定になります。閾値が100%であれば、確信度100%の分類以外はすべての分類を陰性と扱う。

　閾値を変化させていくことで、精度・適合率・再現度・特異度がどのように変化していくかを見てみましょう。
　下のグラフは、50個のサンプルのうち5個が陽性という集団に対し、それなりに分類性能が高い場合の例です。

性能メトリクスの変化

　まず青い線の精度を見てください。グラフの右に行く＝閾値を高める＝陰性判定しやすくなる、ということで、陰性比率が低い集団では精度が上がっていきます*1 。

　オレンジ色の線の適合率は、「陽性と判断したもののうち、本当に陽性だったもの」でした。閾値を高めていくと、陽性扱いすること自体が減るので、分母が小さくなっていきます。また「誤って陽性判断する」（偽陽性）ことも減るので、精度と同様数値が上がっていく傾向にあります。
　今回のサンプルでは、「100%の確信で陽性」というものがあったため、閾値100%でも「正しく」陽性扱い、つまり真陽性となり、適合率も100%となります。

　黄色の線の特異度は、「現実に陰性であるもののうち、正しく陰性であると扱えたもの」です。今回のサンプルには陰性が多いので、精度と同様、閾値を高くして陰性判定してれば、どんどん上がっていくことが見て取れます。

　一方、再現度はどうでしょう。再現度は「現実に陽性であるもののうち、正しく陽性であると扱えたもの」です。閾値を上げるととにかく陽性扱いがどんどん減っていくので、再現度はどんどん下がっていくことがわかります。先ほどと同様、「100%の確率で陽性」というデータがあったので、何とか再現度ゼロになるのを踏みとどまっています。

真陽性率と偽陽性率

　別名の多い分類性能メトリクスですが、上述の再現度は、「真陽性率」と呼ばれることもあります。繰り返しますが、「現実に陽性であるもののうち、正しく陽性であると扱えたもの」でしたね。
　一方この逆に、「偽陽性率」は、「現実に陰性であるもののうち、誤って陽性であると扱ったもの」と定義できます。閾値を上げれば上げるほど偽陽性は減っていきますので、最終的にはゼロになります。これは 1 - 特異度 でもあるため、特異度とは逆に、閾値を下げるとともに下がっていきます。

　バランスの取れた判定性能を実現するためには、真陽性率を高く保ちつつ、偽陽性率は低く保ちたい。これを可視化するために、2つのメトリクスをパラメタとして、散布図を描いてみます。

ROC曲線

　この右肩上がりの散布図が、ROCです。Wikipediaによると

信号処理の概念で、観測された信号からあるものの存在を判定する際の基準となる特性である。

ということで、レーダー技術から開発され（そのため「受信」といった言葉が出てくる）、臨床の現場で用いられ、判定器の性能評価に用いられているわけですね。

　3つのケースをプロットしてみました。
　まずは緑の線。このデータは、「強い確信度で正しく判定できている」ケースです。50個のうち2つのケースでだけ、「陰性に対して80%の確信で陽性判断」、「陽性に対して50%の確信で陽性判断」という「ミス」を混ぜています。 　このケースでは、いきなり垂直に立ち上がって、ほぼそのまま上限に達しています。グラフを解釈すると「閾値を下げることで偽陽性率を上げなくても、真陽性率を十分に高く維持できる」ということで、優秀なモデルということができます。

　オレンジ色の線は「それなり」のケース。「真陽性率を上げるためには、閾値を下げて、偽陽性率の上昇を受け入れる必要がある」ということです。
　グレーの線は、ランダムに判定したもの。真陽性率を80%にするには偽陽性率が62%になってしまう。言い換えると、「現実の5個の陽性のうち4個を正しく陽性判定できる代わりに、「陽性と判定した5個のデータのうち、3個が現実には陰性」という「うっかりものの誤り」を受け入れることになります。

　つまりモデルの良しあしは、このROCがいかに早く立ち上がるかで決まる。言い換えると、曲線の下にある面積の大きさ、積分ともいえます。これがAUC、Area Under the Curve というわけです。

　各性能メトリクスを個別にみるのではなく、真陽性と偽陽性のバランスを視覚的に表現してモデルの良しあしを直観的に認識することができ、かつ閾値をどこに置くのが適切かという議論の土台にもなるツールなんですね。

　勉強が進むのが、とっても遅いです。

参考

techblog.gmo-ap.jp www.randpy.tokyo

*1:この例では、閾値を100%にした時点で「95%の確率で陽性」とした判定まで「陰性」に倒しているため、再度に精度が下がっていますね。

GAFAの席巻に関する、語り口の全く違う2冊の本

　『GAFA×BATH - 米中メガテックの競争戦略』と、『the four - GAFA 四騎士が創り変えた世界』という本を読みました。
　タイトルの通りテーマはともにGAFAなのですが、切り口と味わいがまったく違ってとても面白いので、読書感想文を書いておきます。

GAFA×BATH 米中メガテックの競争戦略

GAFA×BATH 米中メガテックの競争戦略

　こちらは読み始め冒頭から「コンサル」「フレームワーク」というキーワードが脳裏に浮かび、さらには「そのままパワポにできそう」という印象さえ受けるほどのスマートさ。本来は複雑極まりないであろうGAFA、BATH、そしてその関係が、驚くほどきれいに仕分けされ、陳列されています。

　まず各社については、孫子の兵法に基づくという著者独自の分析メソッド「5ファクター分析」に基づいて分析しています。5ファクターとは、以下の通り。

• 道（戦略目標）: ミッション、ビジョン、バリューなど。
• 天（天の時）: タイミング、変化、時間など。SWOT分析やPEST分析が対応。
• 地（地の利）: 市場、業界構造、競争優位。3C分析や5 foces分析が対応。
• 将（リーダーシップ）: 社会的リーダーシップ、組織的リーダーシップ。
• 法（マネジメント）: ビジネスモデル、収益構造。

　第1章で扱われるAmazonでいえば、「道」は「地球上で最も顧客第一主義の会社」というミッション。「天」は、カスタマーエクスペリエンスを向上させるテクノロジーの進化。「地」はeコマースからリアル店舗への展開。「将」は創業経営者であるジェフ・ベゾス氏のリーダーシップ。「法」は小売りでは最低限の営業利益率を維持しつつ、AWSで効率よく稼いで事業拡大につなげる構造。というように整理されています。

　そして、米国のGoogle・Apple・Facebook・Amazonに、それぞれ中国のバイドゥ・ファーウェイ・テンセント・アリババを対応させ、類似点を説明することで、相違点もクリアにしていくという構成になっています。

　たとえばAmazonの「道」で「顧客第一主義」が謳われる一方、「顧客」に該当しない競合（場合によっては競合でさえない存在）は、「Death by Amazon」「アマゾン・エフェクト」ともいわれるような苛烈な淘汰を受けることになります。
　一方中国のアリババは「社会的問題をインフラ構築で解決する」ことを「道」としています。地方のシニアにとって買い物の生命線である「パパママショップ」（家族経営の零細小売店）を潰しにかかるのではなく、デジタルコンビニエンス化することで、消費データを獲得しながら地方のインフラを壊さないという戦略をとっていると対比されています。

　4社同士を比較していくと、バイドゥだけはやや見劣りするものの、米国の巨大プラットフォーマーも盤石ではないのだということを感じされられます。

the four - GAFA 四騎士が創り変えた世界

the four GAFA 四騎士が創り変えた世界

　the four、「四騎士」とは、

ヨハネの黙示録の四騎士。地上の4分の1を支配し、剣、飢饉、悪疫、獣によって「地上の人間を殺す権利」を与えられている。

からの言葉で、GAFAという4企業はネガティブな筆致で描かれていきます。
　『競争戦略』が洗練された枠組みの中で「報告書」のようにきれいに整理されていたのに対し、『the four』は著者自身がGAFAビジネスの周辺で力を発揮していた起業家であるからこそ書ける「物語」のごとし。ビジネス的な側面だけでなく、経営にかかわる人々のエピソードや、歴史・宗教的な側面から見た分析が連綿とつながって、かつまったく飽きさせない語り口は、お見事としかいいようがありません。

　『競争戦略』でもApple製品は「プレミアムブランド」という位置づけで語られていますが、『the four』ではこの点がより深堀されていきます。Appleがなぜこのような地位を獲得するに至ったのかについて、「ブランド品がなぜブランド品として売れるのか」という観点で語られます。

ぜいたく品は合理性という意味ではまったく意味がない。私たちはただ神聖なる完璧さに近づきたいという欲望、あるいは生殖の欲望から逃れられないというだけだ。

　Appleは自分たちの製品をぜいたく品、ブランド品と位置づけている。Apple製品を持つことは、神の美しさに近づくことであり、スティーブ・ジョブズは神格化されたアイコンであり、（当初完全に的外れとされた）アップルストアは神殿であると。

　Appleとその製品を、美をつかさどるギリシャ神話の神のように扱う一方で、Googleのことは、一神教の神のように描写しています。人々の告白に耳を傾け、すべてを受け入れ、答えを返してくれる存在というわけです。ただし・・・

神との違いは、グーグルが人々の望み、夢、不安を盗み聞ぎしてカネを稼ぐということだ。グーグルは、それらへの答えを提示したいという者すべて（商品を販売したい企業すべて）から、料金を取りたてている。

　「使いやすくて便利なもの」の延長ではなく、神性さえを獲得したサービスとして解き明かしていく展開はとってもエキサイティングです。

二冊を読んで

　『the our』のAmazonの章では、意外な事実が語られます。
　Amazonの席巻により、リアルな大型店舗をもつ企業は軒並み没落・・・という印象を受けがちですが、それは雑な捉え方のようなのです。アメリカ最大のモールを所有するグループは、富裕層が住む地域に資産を集中させることで安定した運営を継続。高級モールを所有する別のグループも、面積あたりの売上げを伸ばしていると。

　Appleの章でも同様のことが語られます。

実店舗の苦境は、デジタル化による秩序破壊のせいだとされている。 しかしネット販売は、いまだ小売り全体の10～12パーセントを占めるにすぎない。消滅しかかっているのは店舗ではなく中産階級であり、彼らに商品を売っていた店舗である。・・・
かつて中産階級はアメリカの61パーセントを占めていた。しかしいまやその層はマイノリティであり、人口の半分に届かない。他は収入がそれより下か上の層だ。

　どうもGAFAによって世界は、良い方向には向かっていない。
　さらに『競争戦略』では「この状況で、日本はどうするべきか」、『the four』では「この状況で、あなたはどうするべきか」が、それぞれ終章で語られています。世界の趨勢も、日本の立場も、個人が求められる能力も、どんどん厳しくなっている。その中で、日本が、わたしたちがどう生きていくべきか・・見つめ直さざるを得ない、口に苦い良書でした。

テスト管理ツール「PractiTest」を触りながら勝手にテスト管理を語る - その7

　「その6」の続き、最終回です。

www.kzsuzuki.com

　標準ダッシュボードとカスタマイズについて言及できればと考えていたのですが、「それっぽいダッシュボード」の作りこみに時間がかかりそうなので、やめておきます！
　最終回は、偶然見つけたPractiTestのバグと、テスト管理ツールに対する考えをまとめておきます。後半、もはやPractiTest関係ない。

PractiTestの不思議なバグ

　端的に言うと、「テストケースをインポートすると、謎の文字列が付加される」というものです。漢字を含むテストケースであれば再現性は高いので、PractiTest社側でも既知の事象とは思います。
　インポートするテストケースはこんな感じ。ユースケース(笑)としては、これまでExcelで作っていたテストケースから、PractiTestにインポートしてみるというものです。つまりExcelファイルを自分で作っている（PractiTestからエクスポートしたものの再インポートではない）。

テストケース#2以降は適当

　まず、インポート自体はあっさり成功。インポート機能ってぶっちゃけ、「2～3回は特定困難なエラーが出て、原因追及しながらようやく成功する」というイメージなので、さくっと成功するのは本当に安心感があります。
　ですが、インポートした結果はこんな感じになります。

末尾に付加される謎の文字列

　カギツカカギア？？？ 何語だ？

　・・・よくよく見てみると、文字列の最後に漢字のフリガナが付加されているんですねえ。「鍵」「使」「鍵」「開」で「カギツカカギア」です。
　Excelファイルに記録されたフリガナの情報だと思いますので、インポートしたExcelを調べてみましょう。PHONETIC関数で、文字列からフリガナを抽出すると、こんな感じ。

PHONETIC関数でフリガナを取り出す

　漢字の上についたフリガナが、余計に付加されてしまっているようですね。試していませんが、ほかのインポートでも同じことが起こるのではないでしょうか。

　PractiTest社の方が読んでくれることを期待して、つたない英語で事象を残しておきます。

After importing tests from an xlsx file including Japanese "kanji" characters, unexpected strings are added after each text in imported tests.
These strings seem to be phonetic of the kanji characters.

　これがバグなのか、何か意図しての作りで回避できるものなのかはわかりません。まあバグだとしても、元の文字列は残っているの で、インポートしたものを使いながら直せばいいでしょう。悪用の可能性は・・・うーん、あるかなあ？ Excelの読み仮名は修正できるので、そこに長大な文字列を埋め込んでおくとか？

　ちょっと面白かったので、ご紹介でした。

テスト管理ツールにまだ足りなさそうなもの

　個人的には、テスト管理ツールがテストについて万能である必要はない、と考えています。
　たとえばイシューの作成はテストに関係する活動ですが、それを得意としているチケット管理ツールがすでに安定して運用されているのであれば、テスト管理ツールでがんばる必要はありません。両ツールで双方向の連携ができれば十分です。
　自動テストも同様で、テスト管理ツールが自動テストを駆動する必要は必ずしもなく、自動テストシステムから情報を抜いてこられればいいと思います。

　ソフトウェア開発ツール群において、わたしがテスト管理ツールに求める立ち位置は

1. テストに関するアクティビティのうち、他のツールでカバーできないものを機能としてサポートする。
2. 同、他のツールでカバーできるものは、APIなどを通じて情報を集めてこられる。
3. 他のツールから情報をとるためのインタフェースをもつ。

といったところです。

　b.は上で述べた通り。c.は、自分が他ツールからデータを集めるだけでなく、自分が他ツールに渡すこともできるべきということです。もちろんPractiTestは、両者をよく満たしていると思います。

　ではa.はどうでしょう。
　PractiTestに限らずテスト管理ツールがメインでサポートしているのは、「テスト実装」と「テスト実行」（イシュー管理を含む）です。逆に、JSTQBでいうところの「テスト分析」と「テスト設計」はカバーしているとは言いづらいでしょう。
　「要求」を管理することはできますが、それはあくまでテストケースの導出元として関連付けを行い、テストのカバレッジを測定することが目的です。要求間の構造があるわけではなく、あくまでもテストケースとの親子関係のみ。
　テスト観点の十分性や関連については別の何かで行うことが暗黙の前提であり、テスト管理ツールを適用する段階では、要求と観点がすでに十分に抽出・整理されていることを意図しているように思えます。

　テスト設計も同様です。
　「要求」と「テストケース」は関連づいていますが、その間をつなぐ「どのようにこのテストケースを導いたのか」「どのような網羅性があるのか」という情報をカバーできていないように思います。そこには、表だったり図だったりが入ってきがちなので、テキストだけだと心もとない部分ですよね*1。

　ということで、テスト分析やテスト設計を統一的に扱えるツール*2がテスト管理ツールはに統合されたら、最強だと思います。

おわりに

　以上、PractiTestという素晴らしいテスト管理ツールをネタに、テスト管理について自分の言いたいことを言うシリーズでした。無計画に始めたので構成も何もぐちゃぐちゃですが、直す気は特にありません。

　最後に突然のフォローのようですが・・・、
　PractiTestは、テスト管理ツールが標準的に備えている機能はもちろんのこと、現場で直面する課題を解決するための機能も含めて手堅く押さえた、充実したツールだと感じました。そもそも使い方に迷うことが少ない作りに仕上がっているのですが、公式Web、動画、オンラインヘルプデスクを整備して、「使うのを諦める」ことがないように工夫されています。おかげでこのシリーズも、だいぶ楽しむことができました。
　すでにメジャーなツールなのでわたしが言うのもおこがましいですが、テスト管理ツール導入の際は有力な選択肢の一つになることは間違いないです！

　 PractiTest社のみなさま、トライアルさせていただきありがとうございました。

*1:そもそテスト管理ツールが意図している管理対象は、パラメタの網羅性を気にするような単機能のテストではなく、UATのようなシナリオっぽいテストなのかもしれない。それより前のテストレベルのテストは自動化が前提で、手順や期待値を人間向けに書き下すような必要はないと。

*2:そもそもこれが存在するのか？という疑問はさておく。