見出し画像

接触確認アプリの背景を調査し リリース後の課題について考えてみた | UI Design Weekly vol.03

コロナ感染拡大防止の取り組みとしてリリースされる、「接触確認アプリ」をめぐって様々なニュースや意見を目にしてきました。
今朝のニュースによると、明日にでもアプリの運用が開始されるようですが、
オープンソースで開発されているこのアプリはGithub上でデータが公開されていたり、
実は少し前まで複数アプリが並行して開発されていたり...など、興味深い内容が多かったので、
個人的に気になった3つのことをまとめてみました。


「接触確認アプリ」の概要

■ 接触確認アプリとは?
新型コロナウイルス感染症の陽性者と接触した可能性について、通知を受け取ることができるアプリ。
 どんな仕組み?
Bluetoothを利用して、アプリをダウンロードした人同士が約1m以内の至近距離に15分以上いると、互いのスマホに接触記録が14日間残る。
■ 今、どういう状況?
まだリリースされていない。厚生労働省からアプリが近日リリースされる(2020/6/18時点)


1. デザインデータの変遷...?

接触確認アプリは、有志で集まったエンジニア集団が立ち上げた「COVID-19 Radar」と言うプロジェクトがベースになっているようです。
オープンソースで、GitHub上で全て公開されていて、デザインデータも見ることができました。

画像3

画像は6/17時点、Github上のXDデータから参照したものです。

なかなかこの規模のアプリのデザインデータが公開されていることは少ないので、数日ウォッチしてたのですが、
6/16時点でダウンロードしたXDのデザインデータとガラっと変わっていました。

画像4

ファイル名に0521と入っていたので、最新版は前者ということになります。
使ってすらいない状態で画面デザインだけを見てああだこうだ言うのは好ましくないのでやめますが、
少なくとも、デザイナー含む開発者が意図しない変更もいろいろあったのだろうな...と、この変遷を見て感じました。

変更に関して一つ憶測ですが、大幅な色使いの変更に関してはコントラスト比が関係ありそうです。
最新版のデザインデータは全ての色の組み合わせにおいてコントラスト比はクリアしているものの、以前のデザインに使われている水色はクリアしていません。

📝 コントラスト比
ここで述べている「コントラスト比」とは、イイ感じの色の組み合わせ...とかいう話ではなく、
JIS規格に基づいて4.5:1以上じゃないといけないというWebコンテンツにおいての達成基準があるのです。
この規格はWCAG(Web Content Accessibility Guidelines)2.0というガイドラインに基づいていて...という話は今勉強中なのでまた別の機会に。

アプリが実際にリリースされたら、変更前のデザインデータや、後述する「まもりあいJapan」が公開したデザインや、他国のアプリなどと比較して考察してみたいと思います。


2. リリースが中止になったもう一つのアプリの存在

そんな中、先日、接触確認アプリのデザインデータを公開しますというnoteが公開されました。
「え、接触確認アプリって複数リリースされる?いろいろやばない?」と勝手に一人で騒いでいたのですが、
こちらは前述した「COVID-19 Radar」とは別の、Code for Japanを中心とした「まもりあいJapan」という団体がリリースする予定だったアプリでした。

📝 Code for Japan
IT技術を活用した地域課題の解決をめざす非営利団体。東京都公式の新型コロナウイルス感染症対策サイトの開発なども手掛けていた。

なぜリリースが中止になったのか、こちらの記事を読んで納得しました。

実は接触確認アプリは、有志でバラバラに開発が進められていましたが、
AppleとGoogleが採用した、「分散型(decentralized)」と呼ばれる方式を使うにあたって、アプリの一元化が必須だった、とのことでした。
分散型では、端末IDなどユーザーの個人情報が、政府が管理する中央サーバーではなく、スマホなど端末側に分散して記録される方式で、プライバシーを重視するEU域内などでは特に支持を集めているようです。
そしてこの仕組みを使う条件として、

・各国の保険衛生に関わる機関が直接アプリを提供すること
・1国1アプリとすること

という条件があったため、「COVID-19 Radar」をベースとしたアプリのみがリリースされることになった、という経緯があったそうです。

記事にも書かれている通り、アプリの性質上、非常にセンシティブな問題を扱うため、複数アプリが並行していると混乱を招いたり、そのうち詐欺目的の偽物のアプリが出てきて...という可能性も考えられるので、確かにこの一元化の方針は必須ではあったのかなと感じました。
正直このフレームワークを使うために一元化する...というよりもっと最初の段階で、「複数アプリが並行していると混乱を招く」ということは予測できる問題であったとは思うので、なぜそのまま開発が各々で進められていたのかは気になりますが...。

しかし、前述のnoteや、どのようなUIとUXの考え方であったかを解説していたオンラインイベントなどを通して、
かなり詳細な内容まで開発の経緯が公開されていて、非常に興味深く勉強になる内容ばかりでした。

そしてリリースには至らなかったものの、これからは仕様策定などの協力によって1つのアプリを全体で作り上げていく...という姿勢はまさに、
Code for Japanの掲げる「課題を解決するための共創」を表しているなと感じ、
ものづくりに関わる一人として、その考え方を常に持ち続けたいと思いました。

3. 普及率6割の壁と、政府への信頼

アプリの仕組み上、本当に役立たせるためには少なくとも6割の国民がダウンロードする必要があると言われています。
6割...というと、LINEレベルの普及率が求められ、明日以降政府がどのようにダウンロード促進を行っていくのかが非常に重要になります。

既にSNSでコメントを見ているだけでも「絶対ダウンロードしない」のような意見も既に多く出ていたりします。
こう断言する理由としては、アプリをダウンロードすることによって自分に大きなメリットがない、という意見もあると思いますが、プライバシーの懸念や、なんとなくアプリに対する不信感がある、などの理由も多く見受けられました。

この傾向は日本だけではなく、先日同じ接触確認アプリがリリースされたドイツでも、リリース前にすでに「ダウンロードしない」と回答している人が5割弱いたという記事もありました。

やはり行き着く先は政府への信頼が足りているか、という点が鍵になるのではないかと感じています。
作り手がどれだけ透明性の高い開発を行ったり、Apple/Googleのプライバシーに考慮した仕組みを使ったりしても、
なんとなく不安」という懸念を払拭しアプリをダウンロードしてもらうことが、このアプリに関わる全体のUXを通して一番難しいことなのではないでしょうか。
感染者の特定はしない、とどれだけ政府が訴えても、でももしアプリを入れることで、非難されてる感染者のような扱いを受けることになったら...と感じてしまう人が少なからず存在することも、この非常にセンシティブな状況においては理解できます。

「ダウンロードしましょう!」だけではこの6割の壁は越えられないと思うので、アプリの内容以上に
明日以降政府が、どのように国民の不安を払拭できるかが大きな課題となりそうです。


おわりに

調べ始めるとなかなか根深い問題も多かったり、まだまだ気になる点や学んだこともたくさんあった今回のトピックでした。
アプリの見た目を批判することは誰にでもできますが、UI/UXという分野に関わるデザイナーとして、もっと大きな問題も考えていかなければ、と改めて思うきっかけになりました。

もちろんダウンロードすると感染しない、なんていう魔法のようなアプリではないですが、
多くの人が利用することで、これからの感染拡大防止や、自分や身の回りの人の健康を守る手助けとして、大事な役割を果たすことができると思います。
明日のリリース以降どうなっていくのか、引き続きウォッチしていきたいと思います。

この記事が気に入ったらサポートをしてみませんか?