search

cocoa-mhlw / cocoa

Mozilla Public License 2.0
990 stars 113 forks source link

接触通知の発生状況に関する利用者調査で、利用者の属性を接触通知の発生情報と紐付けて取得するか・その属性はなにとするか #1143

Closed daisuke-nogami closed 1 year ago

daisuke-nogami commented 1 year ago

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

前提（ https://github.com/cocoa-mhlw/cocoa/issues/1138 ）

このデータ提供の依頼をするときの仕様の論点に関するIssueである。

解決策についてお書きください / Describe the solution you'd like

データを提出いただくときに、データと紐付ける形で提出者に関する属性があることが望ましい。 ない場合には、提出されたデータの偏りがあるかが判断できないこと、それを踏まえた分析も限定されてしまう。

ただし、プライバシー保護・回答率の向上の観点から、必要最低限（最大で3問程度）に止める必要がある。

起票者としては以下の3項目（優先順位順）を提案したい。

通勤通学の有無を優先しているのは、職場・学校に行くことや、公共交通機関を利用することが、陽性登録者との接触頻度に大きく影響するため、この要素を明らかにする必要があるからである

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

提出者の属性は取得しない。

その他 / Additional context

接触情報の発生状況に関するデータ取得以外の「アンケート」については #1140 において議論する。 これは、COCOAの振り返りで、利用者に対する調査を用いて調査すべき事項と、適切な手段は以下のように整理しているため。

- Process Output Outcome
意味 政策の進め方/過程 直接生み出される結果 社会に対する成果/効果
指標/測定内容 アプリ品質（ご意見・改善案、利用を止めた理由）、開発プロセス（Github活用も含む） ダウンロード数、陽性登録件数、稼働台数（推計）、 通知発生回数 など 注意喚起効果（通知カバー率、行動変容率、喚起した行動の内容）、利用者のメリット
測定手法 アプリ利用者向けアンケートorヒアリング、関係者によるKPT 実績値の集計、 exposure_data.jsonの収集 調査パネルによるアンケート調査、報道内容・件数整理、SNS発言内容分析
メディア メール and/or Webフォーム、行政内総括 システム運用業務、 機能停止版アプリ 外部調査会社パネル
keiji commented 1 year ago

いろいろ考えているのですが、ぼくは2つの視点から、2つの情報を紐付けることはしない方が良いと言う方に傾いています。

1つ目は、情報を紐付けることでどのような情報が得られるのか。をぼく自身が明確にできていないことです。

Issueの説明では、提出されたデータの（属性上の）偏りがあるかを判断できると言う趣旨なのですが、そもそも運用終了が発表されたCOCOAをアンインストールせずに、機能停止版にアップデートをして機能停止処理に進んで、アンケートにも答えて、接触データの送信にも合意してくれる人って、その時点で相当偏りがあるのではないかと思います。ロイヤリティ ロイヤルティなのか無関心層なのかは分かりませんが、それはおそらくアンケートで聞く属性では導けない要素です。そのバイアスがかかった状態の情報を接触データの偏りとして取り扱うことは厳しいのではないかと思います。

「属性と接触情報を紐付けられれば、データを分析したときに得られるものがあるのでは」と、ぼくが考えているのは事実です。 一方「とりあえず情報を取っておけば何かに使えるかも」というのはけっこう危ない考え方だと自覚していて、プロジェクトとしては、もう少し前の段階「情報を紐付けることでどのような情報を得たいのか」を慎重に検討する必要がある。「偏りを判断するため」はちょっと弱い。と、考えているのが今の段階です。

2つ目は、もう少し利用者寄りの視点になって「この2つを関連付けますよ」と言ったときと「関連付けませんよ」と言ったときの協力してもらえる確率がどうなるだろうかと言う視点です。 一般的に「関連付けませんよ」と言ったときに、そこに不安を感じる人は少ないと思います。その上で、「関連付けますよ」と言われたときはどうでしょうか。ぼくが利用者の立場であれば、不安が少しでもあれば協力しないと思います。

2つのデータを関連付けることで得られる情報の用途を明確して、その情報を取るメリットが非常に大きい場合に限って関連付ける。そうでないなら利用者に協力してもらえることを第一とするのがよい。と言うのが今のぼくの考えです。

daisuke-nogami commented 1 year ago

私は、提出されたデータが分析に値すると認めてもらうためには、 最低限の属性（通勤通学の有無・COCOAインストール日）では分ける必要があり、 一切のデータが属性を持たない状態の方が、回答者に対して望ましくない 結果になると考えています。

まず、COCOAインストール日については、「通知が起こらなかった日」を正しく把握するために 必要な情報になります。 インストール日がないと、通知（ないし信号の受信）が最初に行われた日から提出日までしか 「通知が起こらなかった日」が判別できません。 そうすると、回答者が協力できた、と思っている期間のうち幾ばくかが無駄になってしまいます。 （極論すると、データが空の方が提出しても無駄、ということになります）

ついでサンプルの偏りについてですが、私は「全ての偏りを把握し補正する」とは述べていません。 提出者の接触情報のうち、通勤通学の有無・公共交通機関利用有無については、 偏りを把握し、区分して統計値を算出する必要があると考えています。

なぜなら、算出された接触通知発生回数に対して、これが少ないと思うひとは「自宅を出ない人だけのデータで実態を示していない」、これが多いと思う人は「公共交通機関を利用したり、通勤通学をしているひとだらけのデータで実態を示していない」という、一見説得力のある反論がでることは容易に予想できます。 これに対して、属性別の割合を把握すれば、通勤通学の有無と交通手段は国勢調査で調査されているので偏りを明確に把握できます。

また、COCOAのような接触通知を行うアプリが（COCOAの動作に疑念を持っていない方向けではあるが）どのような生活状況の方に対して、どのような頻度で通知を出して行動を促しているのか、それは感染リスクから見ても妥当であったか、ということは必ず振り返る事項になるはずで、そのときに「通勤・通学といった他者と定期的に接する場がある」「公共交通機関という、必ずしも感染リスクとリンクしないが他者と定期的に接する場がある」ことは、区別すべきシチュエーションとなると考えています。

一方、年代については、そこまで明確な用途（反論への対応など）を持って加えたものではないため、 同じように用途を吟味する必要があるのは、おっしゃる通りだと思います。

あと、「そもそもCOCOAのデータ提出に協力する人はロイヤリティ高すぎで代表値ではない」という点については、そのデータの偏りの前提が分かれば数値を判断するのに十分足りるので問題ではないと思います。 なお、自身の過去の経験から相当割合で無関心層も回答いただけると考えており、ロイヤリティが低い（というよりCOCOAに対して不信感を持つ）層が含まれないという前提がおけるだろうとは思いますが… （ただ、どちらの前提であろうと、通知回数の状況を踏まえた今後への示唆は、比較的近いものになると思います）

そして回答者の観点ですが、上記の使い方を踏まえた適切な説明をすること、一定の無回答を許容することで、 これは「ご協力をお願いしたいとお願いする」というものだと考えていますし、 説明を受けても回答を躊躇うほどの不安を持つ方の提出が得られないことは受容せざるをえない、 と考えています。

keiji commented 1 year ago

（上のコメントでぼく、ロイヤルティをロイヤリティって書いてましたね。すみません……）

私は、提出されたデータが分析に値すると認めてもらうためには、

「認めてもらう」ということは、データを分析に値すると認める具体的な誰かを想定していますか？ もし特定の誰かがいるのなら、（名前を書いてくれと言うのではなく）事前にその人に聞いてみたい気もします。

特定の誰かはいないけれど、感染症の専門家（研究者）に分析して欲しい。と言うことであれば、やはり想定している層に一度聞いてみても良いかなと思いました。実際やるかどうかは時間の都合などもありますけど。

データの分析を誰にしてもらうか（認めてもらうか）に関連するとは思うのですが、ぼくはリンクしなくても「COCOAをどんな人たちが使っていたか」「ある期間に、どの程度接触が記録されていたか」の2つのデータを出すことはできると考えています。

属性と接触データをリンクして、通勤通学の有無（公共交通機関利用状況）などの視点で分析する。と言うことは総括に必要なのでしょうか。 それとも、総括の向こう側、公衆衛生に資することを目指しているのでしょうか。このあたり、いまいちイメージを掴み切れておらず、これは純粋な質問として聞きたいです。

kvaluation commented 1 year ago

利用者の何らかの属性を紐付けて取得する、という方針となった場合、「主たる活動地域の都道府県名」を取得するかどうか、ご検討いただけたら嬉しいです。

https://github.com/cocoa-mhlw/cocoa/issues/1141#issuecomment-1250048354 「濃厚接触の可能性通知」が出た台数（日次） データを送信いただけて集計対象となった台数（日次） 通知には至らなかったが陽性登録者の信号を受信した台数（日次）

これらの数値を、都道府県別にお示しするイメージです。

daisuke-nogami commented 1 year ago

「認めてもらう」ということは、データを分析に値すると認める具体的な誰かを想定していますか？

基本的には「一般の方で、COCOAに対してやや懐疑的～ニュートラル」な方への説得力をだすこと、 デジタル・コンタクト・トレーシングをBluetoothだけで行うことのPoCに必要となること、の2点を考えています。 公衆衛生の専門家、疫学の方であれば、データにある程度偏りがあろうと、機序とデータの前提が分かれば、 そこから分かることは絞り出してくれる（分からない事は分からないという）方々なので…

COCOAに対して先入観なく見る方であっても、世の中で大きな声である「通知なんて出ていない、通勤しているのに出ないなんて動いていない」、次に大きな声である「独居で家に籠もっているのに通知がでる」、この2つは、分かりやすくシンプルであるが故に、N数に関係なく説得力をもつ主張になっていると思います。

もし、単純に全体としての通知の件数が出たときに、そのような声の流れとして「これだけ通知回数が多いのは通勤しているひとばかりデータを提供したためだ／独居で家に籠もっていても反応しすぎて回数がふえているのだ」といった声がでると、ニュートラルに見てくださる方にも色がついてしまう懸念があると思います。このような、ある種の「揚げ足取り」に近いような指摘に応えるには、母集団の性質が見えるだけでは不足すると考えたのです。

逆に、COCOAが適切に機能していなかったとして、そのことを適切に確認して、PoCが成立しなかったのだ、ということを確認するためにも、それくらいの情報までないといけないだろうと思います。

いずれにせよ、COVID-19に限らず、感染症の拡大のハブとして、職場・学校が影響を与えているのは良く知られているので「公共交通機関を利用して通勤通学をしているユーザで、通知がでたユーザの割合は◯割で、公共交通機関を利用しない人は△割、通勤通学をしていないと◇割である」という数字があることが、議論には最低限必要になると考えました。

一方、このデータで公衆衛生に寄与できるかというと、出来たら儲けものですけれど、これだけで何かを指し示すエビデンスにするのは難しいとは思っています。せいぜい、これまでの積極的疫学調査で気づかなかったものがあるかも、という可能性を指し示す（証拠は別に取らないといけないが、仮説がだせる）可能性があるやなしや、ぐらいです。

前述の例だと、疫学的な常識に則るなら、◯≒△＞◇となるはずですが、もしこの大小関係が違ったとしたら、職場・学校を止めることよりも、違う接触の場を押さえることが大事かもしれない、というヒントになるかもしれません（が、ENのパラメータが悪かった、という可能性もあるので証拠としては弱い）

daisuke-nogami commented 1 year ago

「主たる活動地域の都道府県名」を取得するかどうか、

こちらは、機能停止後の振り返りとしては、あまり優先度は高くないと考えています。

日本の新型インフルエンザ等対策特別措置法の枠組みでは、都道府県知事の権限が非常に強く、都道府県単位で施策が行われるため、例えばCOCOA運用中に随時提示する場合には、それぞれの都道府県の政策判断に活かすために分解するのは必要性が高かったと思います（英国NHSアプリも通知数は自治体単位の分解をしていましたし）。

一方、事後から振り返るには、「その通知の件数から何らかの示唆が得られる」前提を置かないといけないですが、先のコメントにあるとおり、通知の件数が望ましいか自体もPoCの検証対象だと考えています。その場合、PoCを確認できる属性を優先すべき、というのが私の考えです。

keiji commented 1 year ago

まず、このIssueの課題として最初に挙げられているのが『「どの程度の利用者に接触通知という形で注意喚起を出来たのか」を測定する』ことです。 次に、exposure_data.jsonを収集して分析すれば、提出利用者全体で何回接触通知が出たのか。と言うことが分かります。

提出者全体に対して、たとえば公共交通機関を使って通勤する人が多ければ、通知回数が大きくなることが予想されます。 逆に、通勤通学をしていない人が多ければ、通知回数が少なくなることが予想されます。 また、4月からCOCOAをインストールしていた場合と、9月からの場合では検出している接触や通知の数に差が出ることもあり得る。

解析の前段階でそれらの条件の偏りを低減したサンプリングをするために、exposure_data.jsonと属性を結びつけたい。と言うことでいいでしょうか。 そうであれば、属性と接触データを結びつける必要性について、ぼくは理解できたと思います。

その上で、通知数を知りたいのであればexposure_data.jsonをそのまま送るのではなく、アプリ側で通知が発生したと判定できる接触の数を計算したものを送信する。と、言う方法もあり得るかと思います。 通知の数だけでなく、たとえばもう少し加工して、日付情報を落とすとか（ぼくも日付情報は欲しいですが、仮の話です）特定の用途を限定した形に変換して送ると、影響度は若干なりとも小さくなると考えます。

一方、データを変換して送ると言うことはデータを変換するロジックをアプリ側で書く必要があります。そうなると今の体制では工数・時間的にも厳しくなることが予想されます。オープンソース側からぼくがコントリビュートしたとしても、開発チームの取り込み（レビュー）対応とテストの工数を考えると、そこはやらないと判断する理由になり得ると考えています（けど、検討はしたい）。

daisuke-nogami commented 1 year ago

解析の前段階でそれらの条件の偏りを低減したサンプリングをするために、exposure_data.jsonと属性を結びつけたい。と言うことでいいでしょうか。

はい、ここまでに表現していただいたとおりの考えです。

その点では、優先度の高い情報は回数ですので、アプリ内で加工してから送るという手法も当然検討対象だと思います（し、工数・時間面での課題があることも認識しています）。

細かい点で、回数への加工をするか否かにかかわらず、日付情報については、例えばバラしておくってしまう（同じ端末から送られた、◯月◯日の通知と、◯月△日の通知が紐づけできないようにする）、という対応などもできるとは思います。

daisuke-nogami commented 1 year ago

memo: 「定期的な通勤通学の有無」を聞くときの聞き方について （聞くとしたときに備えて調べたことのメモで、聞くことを決めたものではありません）

国勢調査の調査票の表現と極力平仄を取る必要があるので、最新の国勢調査である令和2年国勢調査 調査票の記入のしかたを参考にする。…が、けっこう気にすると大変だな…

daisuke-nogami commented 1 year ago

いったん、ここまでの議論を踏まえて、どういう案が俎上に残っているかの整理をさせてください。 特に問題提起・代替案が出ていないところは案を分けていないですが、一方、並行しているIssueも踏まえて案が幾つかあるところは、本Issueのコメントになかった部分も追記しています。

daisuke-nogami commented 1 year ago

現状を親Issueに貼りました。

https://github.com/cocoa-mhlw/cocoa/issues/1138#issuecomment-1296416738

daisuke-nogami commented 1 year ago

調査が終了して、総括報告書で発生回数推計も公開することができましたが、もう少し詳細な集計を公開できるよう調整いただいているので、その集計が公開できたらCloseします。

daisuke-nogami commented 1 year ago

発生回数に関する細かめの集計を含んだExcelの公開が出来たのでCloseします。 https://www.digital.go.jp/policies/cocoa/