接触通知の発生状況に関する利用者調査で、利用者の属性を接触通知の発生情報と紐付けて取得するか・その属性はなにとするか #1143
Comments
|
いろいろ考えているのですが、ぼくは2つの視点から、2つの情報を紐付けることはしない方が良いと言う方に傾いています。 1つ目は、情報を紐付けることでどのような情報が得られるのか。をぼく自身が明確にできていないことです。 Issueの説明では、提出されたデータの（属性上の）偏りがあるかを判断できると言う趣旨なのですが、そもそも運用終了が発表されたCOCOAをアンインストールせずに、機能停止版にアップデートをして機能停止処理に進んで、アンケートにも答えて、接触データの送信にも合意してくれる人って、その時点で相当偏りがあるのではないかと思います。 「属性と接触情報を紐付けられれば、データを分析したときに得られるものがあるのでは」と、ぼくが考えているのは事実です。 2つ目は、もう少し利用者寄りの視点になって「この2つを関連付けますよ」と言ったときと「関連付けませんよ」と言ったときの協力してもらえる確率がどうなるだろうかと言う視点です。 2つのデータを関連付けることで得られる情報の用途を明確して、その情報を取るメリットが非常に大きい場合に限って関連付ける。そうでないなら利用者に協力してもらえることを第一とするのがよい。と言うのが今のぼくの考えです。 |
|
私は、提出されたデータが分析に値すると認めてもらうためには、 まず、COCOAインストール日については、「通知が起こらなかった日」を正しく把握するために ついでサンプルの偏りについてですが、私は「全ての偏りを把握し補正する」とは述べていません。 なぜなら、算出された接触通知発生回数に対して、これが少ないと思うひとは「自宅を出ない人だけのデータで実態を示していない」、これが多いと思う人は「公共交通機関を利用したり、通勤通学をしているひとだらけのデータで実態を示していない」という、一見説得力のある反論がでることは容易に予想できます。 また、COCOAのような接触通知を行うアプリが（COCOAの動作に疑念を持っていない方向けではあるが）どのような生活状況の方に対して、どのような頻度で通知を出して行動を促しているのか、それは感染リスクから見ても妥当であったか、ということは必ず振り返る事項になるはずで、そのときに「通勤・通学といった他者と定期的に接する場がある」「公共交通機関という、必ずしも感染リスクとリンクしないが他者と定期的に接する場がある」ことは、区別すべきシチュエーションとなると考えています。 一方、年代については、そこまで明確な用途（反論への対応など）を持って加えたものではないため、 あと、「そもそもCOCOAのデータ提出に協力する人はロイヤリティ高すぎで代表値ではない」という点については、そのデータの偏りの前提が分かれば数値を判断するのに十分足りるので問題ではないと思います。 そして回答者の観点ですが、上記の使い方を踏まえた適切な説明をすること、一定の無回答を許容することで、 |
|
（上のコメントでぼく、ロイヤルティをロイヤリティって書いてましたね。すみません……）
「認めてもらう」ということは、データを分析に値すると認める具体的な誰かを想定していますか？ 特定の誰かはいないけれど、感染症の専門家（研究者）に分析して欲しい。と言うことであれば、やはり想定している層に一度聞いてみても良いかなと思いました。実際やるかどうかは時間の都合などもありますけど。 データの分析を誰にしてもらうか（認めてもらうか）に関連するとは思うのですが、ぼくはリンクしなくても「COCOAをどんな人たちが使っていたか」「ある期間に、どの程度接触が記録されていたか」の2つのデータを出すことはできると考えています。 属性と接触データをリンクして、通勤通学の有無（公共交通機関利用状況）などの視点で分析する。と言うことは総括に必要なのでしょうか。 |
|
利用者の何らかの属性を紐付けて取得する、という方針となった場合、「主たる活動地域の都道府県名」を取得するかどうか、ご検討いただけたら嬉しいです。 #1141 (comment) これらの数値を、都道府県別にお示しするイメージです。 |
基本的には「一般の方で、COCOAに対してやや懐疑的～ニュートラル」な方への説得力をだすこと、 COCOAに対して先入観なく見る方であっても、世の中で大きな声である「通知なんて出ていない、通勤しているのに出ないなんて動いていない」、次に大きな声である「独居で家に籠もっているのに通知がでる」、この2つは、分かりやすくシンプルであるが故に、N数に関係なく説得力をもつ主張になっていると思います。 もし、単純に全体としての通知の件数が出たときに、そのような声の流れとして「これだけ通知回数が多いのは通勤しているひとばかりデータを提供したためだ／独居で家に籠もっていても反応しすぎて回数がふえているのだ」といった声がでると、ニュートラルに見てくださる方にも色がついてしまう懸念があると思います。このような、ある種の「揚げ足取り」に近いような指摘に応えるには、母集団の性質が見えるだけでは不足すると考えたのです。 逆に、COCOAが適切に機能していなかったとして、そのことを適切に確認して、PoCが成立しなかったのだ、ということを確認するためにも、それくらいの情報までないといけないだろうと思います。 いずれにせよ、COVID-19に限らず、感染症の拡大のハブとして、職場・学校が影響を与えているのは良く知られているので「公共交通機関を利用して通勤通学をしているユーザで、通知がでたユーザの割合は◯割で、公共交通機関を利用しない人は△割、通勤通学をしていないと◇割である」という数字があることが、議論には最低限必要になると考えました。 一方、このデータで公衆衛生に寄与できるかというと、出来たら儲けものですけれど、これだけで何かを指し示すエビデンスにするのは難しいとは思っています。せいぜい、これまでの積極的疫学調査で気づかなかったものがあるかも、という可能性を指し示す（証拠は別に取らないといけないが、仮説がだせる）可能性があるやなしや、ぐらいです。 前述の例だと、疫学的な常識に則るなら、◯≒△＞◇となるはずですが、もしこの大小関係が違ったとしたら、職場・学校を止めることよりも、違う接触の場を押さえることが大事かもしれない、というヒントになるかもしれません（が、ENのパラメータが悪かった、という可能性もあるので証拠としては弱い） |
こちらは、機能停止後の振り返りとしては、あまり優先度は高くないと考えています。 日本の新型インフルエンザ等対策特別措置法の枠組みでは、都道府県知事の権限が非常に強く、都道府県単位で施策が行われるため、例えばCOCOA運用中に随時提示する場合には、それぞれの都道府県の政策判断に活かすために分解するのは必要性が高かったと思います（英国NHSアプリも通知数は自治体単位の分解をしていましたし）。 一方、事後から振り返るには、「その通知の件数から何らかの示唆が得られる」前提を置かないといけないですが、先のコメントにあるとおり、通知の件数が望ましいか自体もPoCの検証対象だと考えています。その場合、PoCを確認できる属性を優先すべき、というのが私の考えです。 |
|
まず、このIssueの課題として最初に挙げられているのが『「どの程度の利用者に接触通知という形で注意喚起を出来たのか」を測定する』ことです。 提出者全体に対して、たとえば公共交通機関を使って通勤する人が多ければ、通知回数が大きくなることが予想されます。 解析の前段階でそれらの条件の偏りを低減したサンプリングをするために、exposure_data.jsonと属性を結びつけたい。と言うことでいいでしょうか。 その上で、通知数を知りたいのであればexposure_data.jsonをそのまま送るのではなく、アプリ側で通知が発生したと判定できる接触の数を計算したものを送信する。と、言う方法もあり得るかと思います。 一方、データを変換して送ると言うことはデータを変換するロジックをアプリ側で書く必要があります。そうなると今の体制では工数・時間的にも厳しくなることが予想されます。オープンソース側からぼくがコントリビュートしたとしても、開発チームの取り込み（レビュー）対応とテストの工数を考えると、そこはやらないと判断する理由になり得ると考えています（けど、検討はしたい）。 |
はい、ここまでに表現していただいたとおりの考えです。 その点では、優先度の高い情報は回数ですので、アプリ内で加工してから送るという手法も当然検討対象だと思います（し、工数・時間面での課題があることも認識しています）。 細かい点で、回数への加工をするか否かにかかわらず、日付情報については、例えばバラしておくってしまう（同じ端末から送られた、◯月◯日の通知と、◯月△日の通知が紐づけできないようにする）、という対応などもできるとは思います。 |
|
memo: 「定期的な通勤通学の有無」を聞くときの聞き方について 国勢調査の調査票の表現と極力平仄を取る必要があるので、最新の国勢調査である令和2年国勢調査 調査票の記入のしかたを参考にする。…が、けっこう気にすると大変だな…
|
daisuke-nogami
changed the title
|
いったん、ここまでの議論を踏まえて、どういう案が俎上に残っているかの整理をさせてください。
|
|
現状を親Issueに貼りました。 |
|
調査が終了して、総括報告書で発生回数推計も公開することができましたが、もう少し詳細な集計を公開できるよう調整いただいているので、その集計が公開できたらCloseします。 |
|
発生回数に関する細かめの集計を含んだExcelの公開が出来たのでCloseします。 |
その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?
前提（ #1138 ）
このデータ提供の依頼をするときの仕様の論点に関するIssueである。
解決策についてお書きください / Describe the solution you'd like
データを提出いただくときに、データと紐付ける形で提出者に関する属性があることが望ましい。
ない場合には、提出されたデータの偏りがあるかが判断できないこと、それを踏まえた分析も限定されてしまう。
ただし、プライバシー保護・回答率の向上の観点から、必要最低限（最大で3問程度）に止める必要がある。
起票者としては以下の3項目（優先順位順）を提案したい。
通勤通学の有無を優先しているのは、職場・学校に行くことや、公共交通機関を利用することが、陽性登録者との接触頻度に大きく影響するため、この要素を明らかにする必要があるからである
あなたが考える代替案についてご説明ください / Describe alternatives you've considered
提出者の属性は取得しない。
その他 / Additional context
接触情報の発生状況に関するデータ取得以外の「アンケート」については #1140 において議論する。
これは、COCOAの振り返りで、利用者に対する調査を用いて調査すべき事項と、適切な手段は以下のように整理しているため。
The text was updated successfully, but these errors were encountered: