新型コロナウイルスの検査とソフトウェア開発管理で感じた共通点
新型コロナウイルスの検査結果が必ずしも正確ではないという話をニュースで見るようになりました。私は医療の専門家ではないのでどういう理由で正確にならないのか詳細はわからないのですが、私の研究分野でも予測（検査）の偽陽性、偽陰性を確かめることがあるのでなじみがある話です。私は、日経メディカルの記事を参考にして、共通点があるなぁと感じました。
偽陽性、偽陰性は身近な天気予報でも同様のことが起こるくらいで、検査、予報、予測にはつきまとう話です。ただ、検査と聞くと100%正確という印象を持つのが普通の感覚かもしれません。たとえば、テレビの天気予報の結果から外出には傘を持っていったほうがよいという提案があったとします。この提案に絶対に間違いはないと考える人は少ないはずで、「傘を持っていけと言われていたけど、自分の行く場所は少し距離があるところだから大丈夫だろう」「特に傘を持っていけと言っていないけど、雲行きやこれまでの予報からすると降る可能性もあるので持って行こう」という判断をすることがあると思います。天気予報が確実に当たるというわけではないことを理解できているからだと思います。
もう少し細かく見ていくと、以下のように場合分けできると思います。
- 傘を持っていくように提案があったとき
- 雨が降って傘が必要になった(A)。
- 雨が降らず傘が必要にならなかった(B)。
- 傘を持っていく提案はなかったとき
- 雨が降って傘が必要になった(C)。
- 雨が降らず傘が必要にならなかった(D)。
助かるのは、(A)の傘を持っていく提案があったときに雨が降って傘が必要になることです。傘を持っていると手荷物になれば、(D)の傘を持っていく提案がなかったときに、雨が降らず傘が必要にならないのも助かります。
傘を持っていくように提案があったけど傘は必要なかったとき(B)や傘を持っていく提案はなかったけど傘が必要になったとき(C)が困る場合です。偽陽性と偽陰性はこれらを指しています。
ここで、ウイルスに感染しているという検査結果を天気予報の傘を持っていく提案と考えます。乱暴な置き換えですが、わかりやすさのためと考えてください。
- ウイルスに感染しているという検査結果のとき
- 実際にウイルスに感染していた（真陽性）。
- 実際にはウイルスに感染していなかった（偽陽性）。
- ウイルスに感染していないという検査結果のとき
- 実際にはウイルスに感染していた（偽陰性）。
- 実際にウイルスに感染していなかった（真陰性）。
感染していることを「陽性」、感染していないことを「陰性」として、検査の結果が正しいとき「真」を、正しくないとき「偽」を先頭につけると、カッコ内のように分類できます。つまり、検査と実際の感染を比べると4つの分類があるということになります。このうち、真陽性と真陰性のみと考えると検査結果の解釈を誤ります。偽陰性の場合には、検査結果が問題ないのだから接触しても大丈夫ということになりますが実際には感染しています。偽陽性の場合には、実際には感染していないのに隔離される可能性があります。
検査という言葉から受けるイメージとして、結果のほとんどは真陽性と真陰性と考えてしまうと思います。なので、検査をたくさん実施したほうがよいということになると思います。偽陽性や偽陰性が多いと上のような実際とは異なる状況になるので、デメリットが多くなる場合がありそうです。
私の専門は医療ではないので本当のところはわからないのですが、新型コロナウイルスの検査のニュース記事で、いったん陽性ではないと判断されても再検査すると陽性になるというものがありました。これは、1回目が真陰性で2回目が真陽性であったという可能性もあるのですが、1回目が真陰性で2回目が偽陽性であったり、1回目が偽陰性で2回目が真陽性であったりという可能性もあります。もちろん1回目偽陰性、2回目偽陽性の組合わせをはじめ他の組合わせの可能性もあります。
この検査の話でソフトウェア開発においても共通している点があると感じたことがあり、このブログエントリを書きました。前置きが長くなりましたが、ここからがソフトウェア開発の話です。1つは、プログラムを書いて納品先から静的解析ツールの実行結果とその対応と解釈を要求されるような立場の方にはなじみがあるのではないでしょうか。
コンパイラや静的解析ツールの実行結果として「警告(warning)」があります。たとえば、あるメソッドや関数内で変数を宣言しているのにそれを一度も代入、参照していない場合、「問題になる可能性がある」というものです。これを上のウイルスに感染しているというところに当てはめると、真陽性(警告通り問題があること)もあるけれど偽陽性(警告が想定しているような問題は起こらないこと)も多いということになります。
静的解析を依頼する側や発注者側で、そうした警告に偽陽性や偽陰性があることを理解していないと新型コロナウイルスの検査と同じことが起きます。ツールを開発している立場からすると「警告は出るけど外れる場合もあります」というのは積極的には書きにくい内容です。依頼側や発注者側で開発側や受託側でツールのほうが信頼できると考えてしまう場合には「警告が出るんだから見ておくべきだし、その対応はきちんと報告すべき」と依頼側、発注者が思うのは、ある程度わかります。ただ、偽陽性や偽陰性があってどのくらいの割合かということは、理解しておかないと双方苦しむことになってしまうと思います。
もう1つは、よく使われていた(使われている)欠陥密度のようなメトリクスにも同様の傾向があります。欠陥密度は、単位時間や単位規模あたりの欠陥の数で、プロダクトの品質を推測しようとするものです。一般には、下限と上限を設定して、それらを超えるような場合に、問題がないかどうかを確認するという使い方をします。
しかし、作る側になれば、このメトリクスと管理手法にも偽陰性や偽陽性の可能性が多いことがわかるのですが、「管理手法」というのが上の「検査」と同じように真陽性と真陰性がほとんどという思い込みを作ってしまう場合があります。作る側の方のなかには、こうした管理手法に過剰反応してしまう方もいると思います。ただ、うまく付き合えば、何もないときよりも手がかりは増えるはずです。あるべき姿は、偽陰性や偽陽性の可能性を理解した上で、こうした情報の収集コストを下げようという考えのもと、よりよい方法をさがすことです。
私が偽陰性や偽陽性が気になったのは、自分の研究分野に詳しくなる前で(高校生くらいだったような...)、そのきっかけはパペポTVというバラエティ番組です。そこでコメディアンの上岡龍太郎氏が言っていた「飲み屋で阪神の試合見てるおっさんが「オレは(阪神の投手が)打たれると思ってたんや」と予想が当たったかのように言うけど、あれ毎日言うてて、たまたま今日当たっただけやからね」です。