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

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

インシデントの「発生頻度」という言葉について

 この記事は、欠陥のトリアージについてのメモ書きポエムです*1

 ソフトウェアのテストや本番環境で検出されたインシデントには、さまざまな情報が付加されていきます。
 インシデント管理システムなどへの最初の登録の際には、発生したソフトウェアのバージョン、事象、再現させるための条件などがあるでしょう。また調査や原因特定の過程で、事象の原因(ソフトウェア自体の欠陥なのか否かも含めて)、対策案といった情報も追加されていきます。

 こういった情報の一つとして、「重要度」や「発生頻度」を管理することも一般的です。
 重要度は、「重大度」「Severity」「Impact」などと呼ばれることもあります。「開発しているソフトウェアにとってどれほど致命的か」という情報です。

 発生頻度は、「Frequecy」と呼ばれることもあります。「そのインシデントがどのくらいの頻度で起こり得るか」という情報です。
 この「発生頻度」について、複数の意味があるなーと常々思っていたので、整理しておきます*2

「発生頻度」の三つのパターン

 「発生頻度が低いインシデント」というとき、少なくとも以下の三つがあります。
 なおMECE性にまったく配慮していません。

  1. ロジック的に発生頻度が低い
  2. ユースケース的に発生頻度が低い
  3. 利用環境的に発生頻度が低い

パターン1: ロジック的に発生頻度が低い

 内部状態の特別な組み合わせや、レアなタイミングでのみ起きるインシデントです。たとえば、「通信のシーケンス番号がある値をとったタイミングで特定の処理を実行した場合」みたいなものです。

 「発生頻度が低い」というとき、一番イメージしやすいのがこのケースかもしれません。ユーザが意識的に制御できないのが特徴です。メモリリークもこのパターンに含まれそうです*3

パターン2: ユースケース的に発生頻度が低い

 発生させるための手順などが非常にまれ、普通はやらないようなものなので、通常は起こりえないと考えられるインシデントです。たとえば、「画面の”進む”と”戻る”を1,024回繰り返した場合」みたいなものです。

 ユーザが意識する手順・使い方が発生条件なので、その条件をわざと満たせばサクッと出てしまうのですが、その条件をユーザに回避してもらうことで普通に使えるケースが多いです。使い方に制限を課すことになるので不便を強いることもある一方、ワークアラウンドが提示しやすい。

パターン3: 利用環境的に発生頻度が低い

 ソフトウェア自体ではなく、それを利用する環境が特別な組み合わせの場合に起こるインシデントです。たとえば、「OSが〇〇でブラウザが△△でウィルス対策ソフトが◇◇の場合」みたいなものです。

 この手のインシデントは再現条件に環境が含まれるので原因が特定しづらく、本番系で起こると調査が難航して泣きが入りやすいやつですね。

三つのパターンの違い

 どれも「発生頻度が低い」と呼ばれうるものですが、注意すべき違いがあります。

 まずパターン1と2は、「どのユーザにとっても発生しづらい」インシデントです。パターン1はユーザの意志で避けることが難しいかわりに、滅多には起きない。パターン2は、レアな使い方をしなければ発生しません。一方パターン3は、「起きるのはわずかなユーザに過ぎないが、そのユーザでは確実に起きてしまう」場合があるのが問題です。

 雑な絵ですが、イメージを以下に示します。オレンジ色の部分が「インシデントが発生してしまう条件」です。

f:id:kz_suzuki:20200102060418p:plain
発生頻度「低」のパターン

 パターン1と2では、すべてのユーザ(縦軸)が同じ「頻度」でインシデントのリスクを受け持つのに対して、パターン3では一部の「特別な」(少なくとも開発側が「特別」だと信じている)ユーザが全部のリスクを引き受ける形になってしまいます。言い換えると、このユーザにとっては、発生頻度「高」なのです。

 パターン3であっても、「ディスプレイの改造がものすごく低く、かつWindowsのハイコントラストモードで使用している場合」といった条件なら、まだ回避が可能そうにも思えます。しかし、ウィルス対策ソフトの動作との兼ね合いで起きてしまうようなインシデントに対し、「ウィルス対策ソフトを止めてください、ウチのソフトウェアと干渉するので」とは言えないわけで、回避不可能になりかねません。

 パワポでお絵かきしてまでこんな話を長々としているのは、「発生頻度」がインシデント対応の優先度付けに使われることが多いためです。
 発生頻度が低いと、それだけで対処の優先度もそのまま下げられてしまいがちです。そんなとき、「ここでいう発生頻度とは何を指しているのか。一部のユーザを犠牲にする判断になっていないか」という観点に立ち戻ることが必要だと思います。

 正月早々のポエムでした。

unsplash-logoRiho Kroll

*1:「ポエム」と言っておえば記事のクオリティが低くてもいいという免罪符になっていたが、最近の自称ポエムはクオリティも高く逆効果になりつつある。

*2:Webサービスのように「手元で」の修正・バージョンアップをできるソフトウェアではなく、メディアやダウンロードによってユーザに配布され、ユーザがそれぞれの環境にインストールして利用するソフトウェアを想定しているため、コンテキスト依存の部分があるかもしれません。

*3:ただしメモリリークにによるインシデントはそんなに時間がかからず発生しまうこともあるので、発生頻度が低いとは限らない。

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

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

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

IT技術関連

リーダブルコード

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

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

  • 作者:Dustin Boswell,Trevor Foucher
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/06/23
  • メディア: 単行本(ソフトカバー)

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

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

Web API: The Good Parts

Web API: The Good Parts

Web API: The Good Parts

  • 作者:水野 貴明
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2014/11/21
  • メディア: 大型本

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

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

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

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

  • 作者:増田 亨
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/07/05
  • メディア: Kindle版

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

ノンフィクション

FACTFULNESS

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

www.kzsuzuki.com

AIと憲法

AIと憲法

AIと憲法

  • 作者:
  • 出版社/メーカー: 日本経済新聞出版社
  • 発売日: 2018/08/25
  • メディア: 単行本

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

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

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

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

国旗で読む世界史

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

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

  • 作者:吹浦 忠正
  • 出版社/メーカー: 祥伝社
  • 発売日: 2017/09/02
  • メディア: 新書

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

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

小説・マンガ

恋は雨上がりのように

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

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

  • 作者:眉月じゅん
  • 出版社/メーカー: 小学館
  • 発売日: 2015/04/03
  • メディア: Kindle版

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

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

www.youtube.com

かぐや様は告らせたい

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

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

  • 作者:赤坂アカ
  • 出版社/メーカー: 集英社
  • 発売日: 2016/04/19
  • メディア: Kindle版

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

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

デビルズライン

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

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

  • 作者:花田陵
  • 出版社/メーカー: 講談社
  • 発売日: 2013/09/20
  • メディア: Kindle版

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

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

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

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

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

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

おわりに

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

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

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

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

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

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

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

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

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

秋山さんの捉え方

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

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

まとめ

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

  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個が陽性という集団に対し、それなりに分類性能が高い場合の例です。

f:id:kz_suzuki:20191227170330p:plain
性能メトリクスの変化

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

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

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

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

真陽性率と偽陽性率

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

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

f:id:kz_suzuki:20191227170906p:plain
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 米中メガテックの競争戦略

  • 作者:田中 道昭
  • 出版社/メーカー: 日本経済新聞出版社
  • 発売日: 2019/04/10
  • メディア: 単行本(ソフトカバー)

 こちらは読み始め冒頭から「コンサル」「フレームワーク」というキーワードが脳裏に浮かび、さらには「そのままパワポにできそう」という印象さえ受けるほどのスマートさ。本来は複雑極まりないであろう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 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』では「この状況で、あなたはどうするべきか」が、それぞれ終章で語られています。世界の趨勢も、日本の立場も、個人が求められる能力も、どんどん厳しくなっている。その中で、日本が、わたしたちがどう生きていくべきか・・見つめ直さざるを得ない、口に苦い良書でした。