新型コロナ on Data Visualization Japan

小副川健／東京都新型コロナウイルス感染症対策サイトの開発に携わった話

Mon, 28 Dec 2020 00:00:00 +0000

Data Visualization Japan Meetup 2020（2020年12月28・29日開催）における、小副川健さん（株式会社ユーザベース／Code for Japan）の講演です。「東京都新型コロナウイルス感染症対策サイト」の初期開発に携わった立場から、技術選定と開発コミュニティの運営を振り返ります。

株式会社ユーザベース、および Code for Japan の小副川が発表させていただきます。よろしくお願いいたします。

タイトルは「東京都新型コロナウイルス感染症対策サイトの開発に携わった話」です。今回のミートアップのテーマでもある「話題になった可視化コンテンツ」ということでキャスティングいただいたのかなと思いますが、私は特に初期にかなり深く携わっていたので、その頃に何を考えながらサイトを作っていたか、というお話ができるといいなと思っております。

**先にネタバラシしてしまうと、可視化のコンテンツとしては全然特別なものではありません。**可視化の研究レベルの話や技術的に高度な話を期待されると「すみません」という感じになってしまうのですが、可視化をして人に情報を伝えるという、可視化のベーシックな機能の部分については果たせていた面もあるのかなと思い、その軸でまとめてみました。

ただ、組み立ててみるとあまり可視化だけの話にはならず、どちらかというとシビックテック——データや ICT を使って地域課題を解決していく活動——の色が強い話になります。

自己紹介

普段はユーザベースという、「経済情報で、世界を変える」というミッションを持った会社にいます。BtoB SaaS の事業で、企業の公開情報を分かりやすく整理してお客様にお届けする——そういうサービスの仕事で、データサイエンティストをしております。普段は自然言語処理で機械学習を使ったようなことをやっています。

それとは全く別に、Code for Japan のエンジニアとして、本業が終わった後や土日にシビックテックと呼ばれる活動をしています。

ユーザベースではフェローエンジニアという立場でもあります。CTO のように経営面へのコミットを強く求められる立場以外で、エンジニアとしてキャリアパスを作るためのものです。日々ひたすらコードを書いていますし、Code for Japan でもひたすらコードを書いています。

シビックテックとは

ざっくり言うと、ICT を使って地域の課題を解決する、世界的なムーブメントのことです。

Code for America が一番の本場のようなところですが、最近は台湾でオードリー・タンデジタル担当大臣が大活躍されていて、g0v（ガブゼロ） という台湾のシビックテックコミュニティもかなり有名になってきました。

台湾の g0v の例のように、マスクの在庫を可視化してオープンデータとして提供することで、在庫量をチェックできるアプリケーションが市民の手によって生まれる——そういった活動がシビックテックなのかなと思っています。

日本でも Code for Japan という団体があり、Code for All という世界的なシビックテックのネットワークに加盟して、他国の団体と交流したり、国内のブリゲードと呼ばれる特定地域に根ざした団体を支援したりしています。

ビジョンとして「共に考え、共につくる」を掲げ、日本の地域課題を解決することを目指すコミュニティです。

なお私自身は一般社団法人の構成員というわけではなく、たまにプロジェクトに業務委託のエンジニアとして入る、といった関係です。ちゃんとした所属として名乗ると誤解を招くかもしれないのですが、事務局長の了解はもらっていて、Code for Japan でエンジニアをやっているということで。

中の人はエンジニアが多いとはいえそれでも20%くらいで、それ以外は公務員や普通の会社員でエンジニアリングではない仕事をされている方、学生の方も参加されています。

Slack でコミュニケーションを取っているのですが、**このコロナサイトの影響で、それまで500人くらいだったコミュニティが一気に4500人くらいまで成長しました。**ただ、一気に増えた後もずっと継続的に活動している人はそんなに多くはないので、実質の活動人数が増えた感じはあまりしていないのですが。

私とシビックテック ― 7年

シビックテックに参加して7年くらいになります。

**一番最初にシビックテックを知ったのは、2011年の sinsai.info でした。**当時、私は都内の某大学で博士研究員をしていて、データとはあまり関係ない研究をしていました。東日本大震災も大学の研究室にいるときに被災したのですが、私自身も困った経験をする中で、「IT を使ってボランタリーな活動で世に貢献していく、そういう道があるんだ」とすごく感動したのを覚えています。

そこからすぐ参加したわけではなく、少し時間を置いて、2012年ごろに富士通に就職してデータサイエンティストとして駆け出しました。そして2013年末、「Where Does My Money Go?」——私の税金は何に使われているのかを可視化するサービス——のイベントに参加したのが最初でした。

これもオープンソースで、データを自治体ごとに差し替えるとその自治体版ができるという仕組みになっていて、その対応自治体を増やすイベントでした。

当時の私は思いっきり駆け出しで、データの加工もろくにできないような状態でした。自治体ごとに費目が表記揺れしていて、そのままソフトウェアにかけられない——そういう体験を通じて、データの標準化や、正しくデータを出すことの重要さを実感できたかなと思っています。

そういう体験もあって「シビックテックは重要だし面白いな」と参加し続けているうちに、本業では得られないフロントエンド系の技術や、政府系のオープンデータ・データ標準化に詳しくなり、それがまた本業にも生きてくる——そういうサイクルを体験できた7年でした。

東京都のコロナ対策サイト

一番最初のリリースは3月3日の深夜——正確には日をまたぐくらいでした。その段階では4枚くらいのパネルしかなかったと思います。本当に基本的な数字だけを表示している、そんなサイトでした。

やっていることは、東京都が公式で発表したデータを可視化したものです。可視化として凝ったものではなく、ただの棒グラフだったり、移動平均線が付いていたり、テーブルの形で検査陽性者の状況が出ていたり——本当にシンプルなものが並んでいるだけです。

特徴① ソースコードが OSS として公開されていた

この活動が面白いと言っていただけた背景の一つに、サイトのソースコード自体が MIT ライセンスの OSS として公開されていたことがあるかなと思います。

裏側は JavaScript でできているのですが、そのソースコードが全部 GitHub で公開されている。誰でもアクセスでき、コピーして自分のパソコンで立ち上げることも、別のところにホスティングすることもできる——そういう配布の仕方をしています。

技術としては Vue.js と、それを助けるフレームワークである Nuxt.js を使っています。このあたりの選定も、自治体のサイトとしてはだいぶ尖っていると言っていただいたところです。

特徴② データもオープンデータで公開していた

棒グラフの下あたりに「オープンデータで入手」というリンクがあり、クリックすると JSON の形でデータがダウンロードできるようになっています。

受賞

いろいろと賞もいただきました。もちろん受賞している主体は東京都です。グッドデザイン賞では大賞の候補まで残り、惜しくも大賞は逃したのですが、金賞をいただいております。

その受賞理由のコメントが非常に象徴的だったのでご紹介すると——

正確な情報を迅速に届けるため、様々な指標の情報やデータをグラフや表で分かりやすく掲載し更新していること。グラフや表などに活用しているデータをオープンデータとして公開していること。ソースコードも公開して、他自治体においても活用が可能な形にしていること。

今まで前例はなかったけれど、やってみると非常に合理的だと思えることを達成できたかなと。そこをグッドデザイン賞でも認めていただいたのは、それなりに良いことが達成できたのかなと思っています。

あと個人的な話ですが、開発者として嬉しかったのが GitHub Trending です。世界で総合1位——1日だけだったと思いますが——を取れたのは、個人的にも嬉しかったです。

62サイトへの横展開

受賞理由にもあった「他自治体への展開」ですが、実績としては 62サイトに展開されました。47都道府県すべてで一度は作られた状態になりましたし、サンフランシスコや台湾など海外でも使われています。

そのうちいくつかは実際に自治体の公式サイトとして採用していただき、運用が続いていると聞いています。

それ以外は個人ベースやボランティア団体がやっているところもあって、データの更新に課題があって廃止されてしまったサイトもあると聞いています。今までのシビックテックではそこまで到達できなかったので、あまり気にならなかった課題なのですが、今回そういう課題も顕在化してきたので、次はそういうことがないように頑張りたいね、という反省が生まれたりしました。

左が神奈川県版、右が北海道版です。ほぼそのまま採用いただいているのですが、自治体ごとに工夫も入っていて、たとえば北海道版には日付のレンジを変えるつまみが入っています。全部オープンソースなので、自治体の都合や表示したいデータに合わせて改造が入るわけです。

なぜ横展開に意味があるのか

このコロナサイトが達成したことは「情報の伝達」です。そして情報の伝達という課題は全国共通です。

それ以外の地域課題も、だいたい全国共通のものが多い。今までのシビックテックでも、「保育園がどこ空いているか分からない」とか、「ゴミナシ」というアプリのように「ゴミはいつ出せるのか」「このゴミは何ゴミなのか」といった課題を、その地域用のアプリを作って解決する、というものがありました。

全国共通の課題が多いので、アプリの横展開は開発するときにだいたい考えることになります。

一番の理想は——

オープンデータが全国の自治体で完全に標準化されてどこにでもある
ある地域課題を解くオープンソースのソフトウェアを一つ作る
あとはオープンデータを自治体ごとに入れ替えるだけで、その自治体用のアプリが完成する

これがシビックテックの一つの理想かなと思っています。

**ただ、実際にやろうとするとデータ側に課題が多い。**今回のコロナサイトでも、県が出しているデータが PDF だったという話も聞きました。データを出してはくれているけれど——

フィールド名が違う
集計しているものが違う
形式が JSON だったり CSV だったりバラバラ
そもそもデータとして公開していない
電子的に保存しておらず紙でしかない

そういうデータも結構たくさんあるわけです。

自治体側もそういうオペレーションを組むメリットが今まで取れなかったので、されてこなかったことかなと思います。しかし今回、**東京都は全面的にバックアップして、「サイトを表示するためにどういうデータが必要か」というところから都内でオペレーションを組んでくださった。**そこまでできるという実例ができたので、こういう活動もしやすくなっているかなと思います。

技術選定の話

ここから開発の話に入ります。

非常にざっくりした仕様からのスタートでした。最初は本当に何もなく、どんなサイトになるかも分かりませんでした。決まっていたのは——

静的なサイトである
データごとに拡張する
1日1回データが更新される
表示したいデータは後で増える
いくつかページがある

この断片的な情報から逆に設定していきました。

静的サイト → スタティックサイトジェネレーターでいいよね
1日1回更新 → GitHub Actions を組むか
データが増える → レイアウトは後でコンポーネントを追加しやすいよう細かいコンポーネントで作る
ページが複数 → ルーティングができるフレームワークがいい

……ということで、Nuxt.js でいきましょうと決まりました。

Nuxt.js とは

そもそもは Vue.js というフレームワークがあって、Vue 製のアプリケーションをサーバーサイドレンダリングするフレームワーク、というのが定義です。

Vue.js は JavaScript で Web UI を開発するフレームワークの一種で、先ほど大野さんの話に出てきた React とちょうど同じ立ち位置です。React で開発するか、Vue で開発するか、Angular か、と。

Vue も React と同様にコンポーネントごとに作って組み合わせていく。コンポーネントは小さい単位で自己完結的に作られ、再利用可能な形にします。今回で言うと、グラフを表示しているカード1枚1枚、そしてその中の細かい部品も全部 Vue のコンポーネントで作りました。

サーバーサイドレンダリングとは、多くのアプリケーションのように JavaScript を配信してブラウザでレンダリングするのではなく、あらかじめサーバーでレンダリングした HTML だけを配信するものです。ただ今回その機能は使っておらず、スタティックサイトジェネレーターの部分だけを使っています。

Nuxt を選んだ本当の理由

もう一つの大きな特徴として、Vue アプリケーション開発のベストプラクティスを「制限」としてフレームワークに組み込んでいることがあります。

Vue 自体は非常に薄く、規定の少ないフレームワークです。ファイルをどこに置くか、どういう名前にするか、どういう役割を持たせるかは開発チームが決めることになる。ノウハウが共有されることもあまりないので、バラバラのまま作ってしまったり、開発チームが変わるとどこに何があるか分からなくなったりする。

Nuxt.js の場合は、**開発ニーズの8割以上を満たす設計ができるベストプラクティスを、あらかじめルールとして設けてしまっている。**それ以外をやろうとすると大変なのですが、そこを守ってさえいれば簡単に開発ができる。

たとえば HTML のページを1つ作りたければ、pages ディレクトリの下に Vue ファイルを1つ置く。そのファイル名が URL のパスになる。

制限が強いのでできないこともあるのですが、今回はデータを表示するだけのサイトなので、Nuxt.js を使っても後で詰まることはないだろうと考えて選定しました。

さらに、ビルド関係の設定も内包しているという特徴があります。サーバーサイドレンダリング、スタティックサイトジェネレーター、SPA——**人力でやると非常に大変な切り替えが、1つの設定値やコマンドだけでできる。**ディレクトリ構造もはっきりしているので、**新しく来たコントリビューターが迷うことなく開発を始められる。**本質的な開発に集中するためにメリットのあるフレームワークです。

……と、こう話すと合理的な選択に見えると思うのですが、もちろん「React でもいいじゃないか」という話も当然出てきます。

なぜ Nuxt だったのか。実は文脈がありました。

Code for Japan の活動で、避難所などの情報を地図にプロットして、それを紙に印刷して被災地に配る——そういうことを支援するアプリを作っていた時期がありました。Web マップはネット回線や電源がないと使えないので、本当の被災地では役に立たないんですよね。

作ったのは2018年7月、西日本豪雨の水害のときで、そのときは jQuery と Leaflet.js で開発していました。「2018年にそのチョイスはなかなかない」と言われるかもしれません。ただシビックテックのコミュニティは年齢層の高いエンジニアが多く、集まった人たちも「jQuery だったら書ける」という方が多かった。若い方ももちろんいましたが。それで機能したので「jQuery で良かったね」と言いながら作っていました。

ただ、jQuery で作ると一つのファイルに巨大なコンポーネントを書かなければならなくなる。4〜5名で開発していてもコンフリクトが多発したので、「もっと汎用的な作りにするときに何か導入しよう」ということで Nuxt.js をそのときに選びました。そのときになぜ Nuxt だったのかの経緯は、私が選んだわけではないので分からないのですが、そのチョイスがあったのでコミュニティの知識として Nuxt を使える人が結構多く、いけるんじゃないかということで選定した、という背景があります。

ホスティング ― Netlify

サイトは Netlify でホストしています。

一番最初は GitHub Pages を検討していて、GitHub Actions で CI を組んでデプロイしようとしていました。ただ東京都の公式サイトということで証明書に制限があり、「この証明書でないといけない」という指定のものを GitHub Pages では使えなかった——そういう理由で、Netlify ならできるのでやってみようかとなりました。当時から普通にホスト先として有名だったので、チョイス自体は普通だったと思います。

リリースして数週間した3月22日、Netlify がコロナウイルス関係のサイトへのサポートを発表して、有料プランを無償で提供することになりました。今でも東京都のサイトの派生サイトはそちらでホストされているものが多いんじゃないかと思います。

UI コンポーネント ― Vuetify

もう一つ、Vuetify を使っています。Vue で使う、マテリアルデザインのスタイルをあらかじめ適用したコンポーネント群です。

対策サイトの部品は今でも結構これで作られていて、サイト全体は v-app、メインコンテンツは v-container、タブも v-tabs、カード1枚1枚も v-card でできています。

これは後で話しますが、Vuetify は当時アクセシビリティ的にあまり良くなかったらしく、「Vuetify を使いましょう」と言ったのが私だったので、「Vuetify をなんで選んじゃったんですか」と後で怒られたというのが発生して、ちょっと思い出深かったりします。今 Vuetify のサイトを見るとアクセシビリティ対応のチュートリアルがあったりするので、その辺は改善されているのかなと思います。

ようやく可視化の話

**一瞬で終わってしまうのですが、可視化はほとんど棒グラフです。**データの粒度は1日1本。

その1日1本のデータを都庁内で取りまとめるオペレーションが組まれていて、SharePoint に入力されているものを GitHub Actions などの CI で API 経由で取ってきて、data.json に整形して、サイト側で読み込む——そういう構造になっていました。

取りまとめる際に複数部局に分かれているのでデータの反映タイミングがバラバラだったりして、初期はゴタゴタしたのですが、だんだんスムーズになっていった印象があります。

なぜ Chart.js を選んだか

チャートの部分は Chart.js を使いました。

私自身は D3.js が好きなので、一瞬 D3.js でいこうかと思ったのですが——D3.js はご存知の通り学習コストが非常に高い。「生身のチェーンソーをそのまま振り回すようなものだ」と言われるくらい扱いが難しく、間違ったグラフを作ってしまいやすい面もある。

どれくらいのスキルの人たちが今後開発に参加してくれるか分からない状況では、間違ったグラフが作られにくい Chart.js を使いましょうと、そこで理性を取り戻しました。

ただ、データの事情に合わせて特殊な対応が必要になったこともありました。

途中で算出基準が変わったデータがあったんですね。たとえば入院患者数は5月11日から基準が変わったのですが、そのとき「こういうふうに改変してくれ」という依頼が来る。Chart.js だと、この境界を示す枠線を出すだけで大変だったりします。D3.js なら1〜2行でできるような処理なのに。

これは、今は学生インターンとして Code for Japan で大活躍している開発者が「線グラフとしてここに書けばいいんじゃないか」と発想して、実際に線グラフとして矩形を表現して回避しているらしいです。

コンポーネント設計 ― スロット

カード1枚1枚を DataView というコンポーネント（名前は適当だったのですが）にして、中身を後で入れ替えられるようにし、それを並べる、という基本構造を最初に作りました。

Vue には slot というものがあります。HTML は入れ子にできますが、その入れ子の中身を slot の場所にレンダリングするという対応関係になる。それを利用して、中身だけ差し替えて、外側は同じという状況を作りたかったわけです。

**実際に作ってみると、最初に想定していなかった場所に、想定していなかった注意書きなどを出したい、ということが結構ありました。**今だと6か所くらいに slot が刺さっている状態になっているのですが、あらかじめそういう構造にしておいて良かったなと思っています。

slot は1個だけだと困るので複数作ることができて、たとえば description という名前で差し込むとそこに入る。拡張性と、見た目の統一の両方ができるように工夫して実装していました。

実装中の「祈りのような心の動き」

実装している間に祈りのような心の動きが発生したのが印象的だったので、共有させていただきます。

今から考えると呑気すぎる話なのですが、当時はどれくらい続くか、どれくらいの規模になるか全く分かりませんでした。リリースした日も感染者4人だったんですよ。「長期化しないといいな、願わくば数ヶ月で収束してくれるといいな」——それくらいの感覚でいました。

ただ、エンジニアリング的にものを作るときは「大量のデータに対応できるように」と当然考えるので、そういう実装をしなければならない。

感染者数の表示に3桁区切りのカンマを入れるという対応をしてくれた方がいて、それをマージするときに「でも、これ要らないといいですよね」と言いながらマージした
棒グラフの横幅も、最初は固定幅でリリースしました。今はスクロールバーで3月まで遡れますが、当時はどれくらい続くか分からないし、実装が必要なだけ長くなりそうだということでスクロールなしでリリースした
そして最近まで残っていたのですが、データの部分に「2020年」という年号が入っていなかったので、サイトが実は年を越せない仕様になっていました。もうあと数日で1月1日を迎えますが、プログラムは「2020年1月1日のデータ」と誤読する状態のまま、しばらく放置されていたという話があったりします

リリース直後 ― リポジトリが特定される

3月3日の深夜にリリースされたのですが、その日のうちに Twitter で GitHub のリポジトリが特定されて拡散されました。

未だになぜ拡散したのか謎なのですが、サイトのソースの変数名あたりからかな、と憶測を立てています。とにかく「東京都のサイトのソースコードがこんなところにある」と拡散された。リポジトリの中で立てていた issue に Figma の URL もあったので、デザインも公開しているということで、それも結構拡散されました。

それ自体は喜ばしいのですが、Figma にアクセスが集中しすぎると人数制限で入れなくなってしまうので、当時コアで開発していたメンバーも入れなくなってしまったということがありました。

そして「こういうことがあるなら自分の技術を活かしたい」と思っていただいて、既に立っていた issue にコミットしてくださる方も大勢いらっしゃいました。

ただ当時は受け入れ体制が全くできておらず、レビューの手順も決まっていない、誰がやるのかも決まっていない。取り込みが全然できず、皆さんの貢献したい気持ちにブレーキをかけてしまった——これが当時、結構ストレスになっていたかなと思います。

さらに、取り込むのに東京都の OK が必要なケースもあるので、善意で立てられた issue でも取り込めるかどうか分からないケースがある。きわどいものに対して、そういう事情を分かっていない方がコミットするような動きも見えたので、結構ヒヤヒヤしていました。

コミュニティの受け入れ体制を作る

そういうときに、開発コミュニティとして今まで蓄積してきた知見も含めていろいろ対策を打ち、1週間後くらいにはレビューして取り込んでいける体制ができました。

具体的には大きく3つです。

① 行動規範とコントリビューションガイドの整備

**これは実はリリースの瞬間には既にやっていました。**こういう行動規範は Code for Japan のイベントで普段から設けているもので、元々あったものを適用した形です。

issue のテンプレートも置きました。.github の下にテンプレートの Markdown を置いておくと、誰かが issue を投稿しようとしたときに「こういう項目を書いてください」という雛形が表示される。箇条書きの部分を埋めるだけで issue が投稿できるし、読む側もフォーマットが統一されているので何をやりたいのかが分かりやすい。こういうものでコミュニケーションコストを下げていました。

② Lint を CI にかける

開発環境を特に指定していなかったので、皆さんいろいろな環境で開発されていました。そうすると、行頭のスペースをいくつにするかといったコード規約を自動で整える処理がかからない開発環境もある。

そこは非常にしつこく、何回も CI にかけて、そういう差分のせいで本来コミットしたかった開発が漏れてしまわないように注意していました。

③ Netlify のデプロイプレビュー

Netlify を使ってデプロイしていると、プルリクエストが来たときに「取り込んだ後のプレビュー環境」を自動で生成してくれる機能があります。独自の URL が発行されて、そこで**取り込んだ後の挙動をチェックできる。**これは生産性を大きく向上させました。

その道のプロが集まってきた

参加者が増えていくと、その道のプロが集まってきてくださいました。2つだけ紹介します。

アクセシビリティ

アクセシビリティのプロの方々が来て、このサイトのアクセシビリティを向上させてくれるということがありました。

3月3日のリリース後、3月6日にオンラインでアクセシビリティのもくもく会が開催され、このサイトのアクセシビリティの問題点を探し出そうという催しが行われました。

「公開処刑されるんじゃないか」と戦々恐々としていたのですが、実際はすごくポジティブなマインドの方々が集まっていて、その後も継続的に改善に取り組んでいただきました。

……ただ「なんで Vuetify を採用したんだ」という怒られはこのときに発生したので、私にとってはちょっとトラウマ、というほどではないですが。

このあたりの話は Code for Japan Summit で詳しくしていただいているので、ご興味ある方はそちらの講演を見ていただくと面白いと思います。

多言語対応

これもその道のプロが集まってくださって、最終的には5か国語に対応することができました。

Nuxt の中で t で始まる文字列を書いておくと、対応を書いた JSON ファイルで自動的に置き換えられ、言語設定を変えるだけで、ソースコードに触れずに多言語化できる——そういう状況を初期の段階で整えることができました。

あとは翻訳の文言を、いろいろな方がやってくださいました。これはオードリー・タンさんにも手を入れていただいたことがあって、結構話題になりました。

これを「普通」にしていきたい

こんな感じで開発が進んでいきました。特に最初の1ヶ月は私もかなりコミットしていたのですが、その時点で既に**各分野の詳しい方が入ってきてくださっていて、「私なんかが出る幕じゃないな」**と。

学生の活躍もかなり素晴らしく、先ほどの国際化（i18n）も音頭を取ってくれたのは学生だったりしました。

私が思ったのは、今回の活動を、今後は「普通」にしていきたいということです。

今回の東京都の対応は結構素晴らしかったと思いますが、実際にやってみると、オープンソースでオープンデータでこういうことをやるのは、すごく合理的なんですよね。こういう合理的な事例があったということ自体をベースにして、次の活動ではそれをどんどん超えていくようなことをやっていきたいと思います。

まとめ

エンジニア視点であのサイトの開発をまとめると、シビックテックのベストプラクティスと呼べるものが浮かび上がってきたかなと思いました。

個人としては、今後の事例の足掛かりとして、次のプロジェクトではもっとより良いものを目指していきたいと思っています。

長くなりましたが、以上で終わります。ありがとうございました。

山辺真幸／新型コロナの最前線研究を伝える可視化と、テレビ番組のデータジャーナリズム

Mon, 28 Dec 2020 00:00:00 +0000

Data Visualization Japan Meetup 2020（2020年12月28・29日開催）における、山辺真幸さん（慶應義塾大学）の講演です。NHKと制作した4K/8K放送向けの新型コロナ可視化について、その狙いと制作プロセスを共有します。

慶應大学の山辺と申します。「新型コロナの最前線研究を伝える可視化と、テレビ番組のデータジャーナリズム」という少し長めのタイトルですが、発表させていただきます。

先ほどの大野さんの発表がかなりゲノムの話だったので、その後でまたゲノムの話を私がするのですが、特にゲノムに精通しているわけではないので、間違いがあればどんどん突っ込んでいただければと思います。

自己紹介

工学部を卒業して、最終的には半導体および物理あたりの論文を書いて卒業しました。その後 IAMAS（情報科学芸術大学院大学／当時はまだ大学院大学になっていなかったのでアカデミーと言っていました）を出て、デザイナーとして勤務し、10年ちょっとで独立して制作・デザインをしておりました。

その間、かなり長い間、主に美術系の大学で非常勤をさせていただき、プログラミングやメディア、データビジュアライズの作り方を教えてきました。少し前は多摩美術大学の情報デザイン学科で指導していたりもしました。

2014年から今の慶應大学の方で、社会人博士という形で、働きながら情報可視化の研究をしています。

研究室のテーマ ― Nature Interpretation

脇田玲先生の研究室におります。主要なテーマが「Nature Interpretation」——世界を解釈するためのコーディング、そして目の前にありながら知覚することができない自然界の情報を可視化・物質化する、そういう新しいメディアを作っていこう、というものです。

脇田先生は今 SFC の学部長になられていて、完全にアーティストとして活動されていることもあるので、研究室自体もアート寄りのプロジェクトをする人が増えています。私は完全にアートの方には行かず、可視化というデザインの範囲の中でできる可能性を探求しています。

最近自分では「可視化のクオリア」と呼んでいるのですが——現実はめちゃくちゃ複雑で、ビッグデータ時代になるとその複雑さをかなりカバーできるような多様で複雑なデータがますます増えていく。そういうものを分かりやすく切り取るのではなく、複雑なものを複雑なままに、感性的に伝えるための可視化のデザインはあり得るだろうか、という研究をしています。

今回お話しする NHK のプロジェクトは共同研究ではないのですが、普段やっている研究の内容をプラクティカルに実践している形——平たく言うと受託で作っている形になります。

研究室の過去の可視化プロジェクト

ダイキンさんとの「空気の可視化」 ——エアコンが排出している気流・温度・湿度・匂いといった密度の変化をリアルタイムに可視化する野心的なプロジェクト。アート的に表現してそこに没入していく。空調は単なるものではなく、住環境をいかに人間の感覚的に心地よい状態に保つかを体感する作品
日本科学未来館のコンテンツ ——JAMSTEC、ライゾマティクス・リサーチと共同で制作。地球シミュレータが計算した全地球面の高解像度海流データを使い、日本近海から世界の海域まで、海流の動きを美しく見せる

プロジェクトの狙い

4K放送・8K放送が始まっている状況の中で、この高解像度でコロナ禍をどう映し出していくかというのが趣旨のプロジェクトです。

2つ作っておりまして、「ゲノムの3次元系統樹」と「感染リスクの時空間3Dマップ」です。

なぜこのプロジェクトが立ち上がったか

新型コロナに関するビッグデータ——膨大な量のデータを高精細に可視化して、「どうぞ見てください」ではなく、専門家と一緒にそれを読み解こう、というのが狙いです。

**コロナに関しては、確定的に分かっていることの方が少ない。**専門家もまだまだ仮説を立て、どんどん変わっていく状況を読み取り、そこから新たな仮説を作っていくような段階です。そういう最新の研究をされている方がいろいろなジャンルにいらっしゃるので、その研究から出てきているデータを高精細に可視化していこうと。最先端の研究と、我々普通の視聴者との距離をいかに縮められるかという狙いがあります。

もう一つは技術的な話で、8K放送をどうしていくべきかという NHK さん内部の課題です。8K の受像機が家庭にあるわけでもない中で、風光明媚な映像やお相撲、過去の名作のリマスターといったコンテンツが多い。その中で「データを見る」という番組は新しいんじゃないか、と。感染爆発の実像を描いて、新たな気づきやインパクトをダイレクトに届けたいという思いもありました。

※ 私は NHK の中の人ではないので、この辺りは NHK さんの資料から私が読み解いた部分でもあり、正確なメッセージとは若干異なるかもしれません。

放送実績

9月26日 4K放送
10月 8K放送
12月頭 NHK サイエンススタジアム（8Kディスプレイを持ち込んでの展示）
12月13日 NHKスペシャル「新型コロナ第3波」（生放送）

制作環境 ― NMAPS と Processing

NHK では NMAPS（高度情報利用報道システム） というシステムがすでに運用されていて、取材や番組制作におけるデータ分析・可視化に使われています。カチッとしたシステムというより、日々アップデートして改良を重ねている状況です。

ここで CG のカメラワーク、4K/8K のレンダリング、番組の収録自体を行うことが可能になっています。

私が担当したのは、NMAPS 上で再現する 3D モデルや可視化のアルゴリズム——つまりデータから視覚要素への変換というビジュアルデザインの部分です。

この部分は主に Processing で開発しています。

Processing で開発したアプリをアップデートしながら、プロデューサー、取材担当者、研究者、エンジニアに一斉に配信して見ていただき、そこから上がってくる議論をまた開発にフィードバックさせながら最終形を作っていく、というアプローチを取りました。

先ほどの大野さんの話とは対極にあるような話ですが、可視化ライブラリはほとんど使用せず、ほぼスクラッチで開発しています。

① ゲノムの3次元系統樹

時間が手前から奥に進行していき、その時間軸上を地図がスライドしていく形になっています。手前から1本の線がたくさん分岐していく——これが系統樹です。

系統樹はどう作られるか

COVID-19 の RNA は約3万塩基が連なって遺伝情報が書かれています。これが増殖するときにコピーミス＝変異が発生します。増殖のたびに確率的にコピーミスが起こるので、ウイルスの変異の共通部分を見ていくことで系統が分析できるという仕組みです。

**四角い点一つ一つが変異を表しています。**それがどこで発生して、どういう形で分岐してきたのかが見られるようになっています。

データの出どころ

GISAID ——医療機関や研究機関で感染者から採取された遺伝子をゲノム分析し、新しいものであれば変異株として登録されていく国際的な取り組みです。もともとは COVID-19 のために作られたのではなく、季節性インフルエンザなどウイルス全般の情報を扱う取り組みだったそうですが、今はコロナウイルスの収集で中心的な役割を果たしています。

そしてゲノムデータの可視化や分析リソースを提供しているオープンソースプロジェクトとして Nextstrain があります。

Nextstrain の2次元の樹形図はオンラインで誰でも見られます。色分けはアジアやヨーロッパといったリージョンで分けられているのですが、これだと素人目にはどこで発生したのかが直感的に分かりにくい。

そこで3次元化して、位置情報を使いながら時間を変化させることで、ウイルスの時間的な拡散と空間的な広がりを同時に見るという表現を作ることができました。

日本に入ってきたものだけをフィルタする、中国はどうだったのか、アメリカ・イギリス・ドイツはどうか——国ごとに経路を見ることもできます。

色の違い ― D614G

もともとの武漢株ではなく変異した欧州株が出てきたことが報道でも取り上げられました。この D614G という広まった遺伝子を持つものを青、もともとのものを赤で視覚化しています。

D614G の変異は、スパイク——コロナウイルスの突起で、人間の細胞に引っかかる構造を持つ部分——が変化したことで感染性が強まったという報告が出ています。D614G に注目して着色することで、いかに感染力が強まったのかを視覚化できるのではないかと考えました。

放送されたものでは——2019年12月24日に中国のところに赤い点が出て、そこから出発して中国国内で広がりつつ、最初の D614G が発生。それがすぐヨーロッパに拡散してドイツ、イタリアで確認されたものがヨーロッパに拡大。その後アメリカ大陸に渡り、そこから全世界へ。

**日本にも最初は武漢株が入ってきていたのが欧州株に切り替わり、それ以降、武漢株はほとんど見られなくなった。**ある意味、淘汰というか進化をしながらコロナウイルスが広まっているということを、放送を通じてお伝えしました。

横から見ると、政策の影響が見える

真横から見てみると、見えてくることがあります。

左が古い時間、右に向かって新しくなっているのですが、広がり方が人の行動とリンクしているところがある。各国で行動の制限がかかると、それより右の時間では縦に走る線が少なくなり、横に走る線が増える。しかも同じエリアの中でしか束が広がらなくなることが視覚的に分かる。

つまり各国の政策がウイルスの広がり方に影響したことが分かるわけです。色をつけてみるとなおさらよく分かって、入国制限・移動制限をした後は、同じ色の束の中でしかあまり広がっていない。

課題

**正確に「そこで起きた」とプロットできない。**位置情報はリージョン、国、県といったレベルで持っていますが、詳細なロケーションは欠損が多い
そもそも変異がどこで起こったかは特定できず、採取された位置から推定している
**検査数によって報告数に差が出る。**変異を示す四角い点が少ないところは変異が少ないように見えるが、検査数が多ければ多いほどたくさん採取されるので、見た目と現実がリンクしていない面がある

② 感染リスクの時空間3Dマップ

青・黄・赤という3つの空間が入れ子になっているのが分かるかと思います。これは時空間カーネル密度推定による可視化で、東北大学の中谷先生のご研究をもとにしています。

JX通信社と東北大学の共同研究として「新型コロナ実効感染リスクマップ」がアプリや Web で公開されていますが、基本的には同じものを使っています。

どういうことかというと——**JX通信社から取得した感染の発生地点情報をマップし、高さ方向に時間を取る。**地表に近いところが2月で、一番高いところが8月。

こうして空間的にプロットしていくと、発生したポイントが時間的にも空間的にも近い＝連続して発生しているところがリスクが高いとみなせる。その密度分布を出し、リスクが同じ等値面を可視化すると、こういう形が出てくる——というのが中谷先生のご研究の成果です。

「雲」に見立てる

**NHK のプロジェクトでは、時間を上下反対にしています。**上の方が古い時間、下の方が新しい時間です。

なぜひっくり返したかというと、これを「雲」に見立てるためです。下からどんどんせり上がってくると、雲がせり上がってくるような感じになる。そうすると上の方が過去だね、ということでこうした表現になっています。

見ていただくと分かる通り、**第1波と言われる3月にかなりリスクが高まり、6月ごろ——緊急事態宣言も解除され感染が下火になったところ——ではこのエリアがほぼ見えなくなる。**そして9月に入って第2波、現在第3波ということで、ここは完全に連続してしまっていることが分かります。

リスクの色分けは——

青：4km四方で4日に1件以上
黄：毎日1件以上
赤：毎日5件以上

CT スキャンのように切って俯瞰する

各期間で切って俯瞰したものがこちらです。

**第1波の頃は本当に東京の都心部だけに集中して高リスクのエリアがあった。しかし現在の第3波は、中心が高いというより、各地に黄色い部分が飛び火している。**中心だけが非常に高いのではなく、各地に危険なエリアがあることが視覚的によく分かります。

人の流動と重ねる

さらに、国立情報学研究所の水野先生のご研究で、NTTドコモのデータから人がよく流動している地域を可視化すると——東京23区の東側、埼玉の東側、千葉の北西部、そして横浜・横須賀あたりが非常に人の流動が多く、この外にはあまり出入りがなく、この中でぐるぐる回っている。

これも Processing で実装したのですが、先ほどの図と重ねてみると、エリア内を人が動いていることで、主要駅や繁華街のあるところでリスクが高まっていることが分かりました。

全国の主要都市——東京、名古屋、関西、北九州、東北、北海道——で計算してみると、**どの都市にも赤いエリア＝感染の核となる部分が存在している。**真横から見ると、第1波と第2波の間はどの地域もほぼ落ち着いていたことが分かります。

専門家と一緒に読み解く

東海大学の中川先生、そして中谷先生と水野先生に実際に8Kをご覧いただきながら、「ここがこうですよ」と解説していただきました。

**特に中谷先生と水野先生には同じ場所に来ていただいて、お二方それぞれの研究を合わせた。**そうすると、人の動きと、第3波が地域に拡散しているという違いがよく分かった。

違うジャンルの研究をされている方同士を、8Kの上で視覚化して合わせる——ここが今回得られた大きな成果かなと思っております。

12月5・6日には展示も行いました。子供向けのイベントでもあるので、丁寧に設計し、解説員が説明をしながらテレビ放送と同じ内容をお伝えする形になりました。

制作の舞台裏

時系列で言うと、7月初旬に企画会議。そして10月の8K放送までは、7月の段階でほぼ決まっていた。なので9月には収録しなければならない——実質7月・8月のほぼ2ヶ月で仕上げる必要がありました。経験上かなりの短納期で、最初は懸念がありました。

8K のポテンシャルを引き出せる研究がどこにあるかは NHK さんが事前に広く取材されていて、いろいろなデータが候補に上がっていました。その中で、8K は細部と全体が両方一度に見えるという特性があるので、それが貢献するテーマということで先ほどの2つが選ばれました。

初期・中期・最終の3段階

【初期】探索的な可視化

専門家と取材陣の間で「どういうストーリーが伝えられそうか」を検討する段階。科学的にある程度の正しさがあるものでないと当然扱えないので、そのストーリーがどこにあるかを検証したりディスカッションしたりするサポートとしての可視化を行いました。企画書やコンテ作りにも、アプリのスクリーンショットを活用していただきました。

【中期】分かりやすさと厳密さの両立

いろんな機能をまずつけて、触っていく中でどこが面白いかを見極めた上で、では何を残して何を捨てるのか、というアプローチです。最終的に何を残すかは、収録にかなり近づいた段階で確定しました。

【最終】エンジニアとの連携

NMAPS を担当するエンジニアに再現用のデータを渡すためのフォーマット、そして放送の数日前に最新データへ更新することもあり得るということで、パイプラインをどうしておけばいいかの連携を図りました。

スケッチから最終形へ

これが最初のスケッチです。3次元で系統樹を見せようと言ったとき、なんとなく直感で「できるだろう」と思ったんです。こんな絵を描いたのですが、当然この絵では伝わらなくて、いろいろ可視化を進めていくうちに「これは面白いかも」と思っていただけた様子でした。

初期の可視化はいわゆる「ヘアボール」の状態で、何も見えない。そこから時間のグリッドを足したり、エッジの描き方を変えたり、いろいろトライしました。地図の重ね方も、完全に透過させて並べるのがいいのかどうか、と。

エッジをどう繋ぐかは非常に難しく、かなり知恵を絞ったところです。最終的に、感染の位置情報・繋がり・時間を変えずにエッジを束ねる方法が見つかったので、それを実装しました。左が束ねる前、右が束ねた後。かなり美しく、分かりやすくなったかなということで、こちらが採用されました。

もう一つの3次元可視化は、ArcGIS Pro を使って JX のデータを3次元に計算しています。中谷先生が ArcGIS 用のツールボックスを配布されているので、これを使って計算しました。

計算した上で「関西と関東で時間的にどう違ったのか」「第1波と第2波はどうだったのか」を取材チームに共有してきました。最終的に各都市のものを Processing 上で統合し、そこに感染の公表地点も3次元的にプロットして検証しています。

水野先生のご研究も、市区町村をグルーピングしたデータを CSV でいただき、Processing で GeoJSON からカラーリングしたシェイプに変換して合成する流れでやりました。

台本にもスクリーンショットを使って番組の流れを検討していただく、という使い方をしていただきました。

振り返り ― Ben Fry のモデル通りだった

矢崎さんの発表にもありました、Processing 開発者 Ben Fry のデータビジュアライズのプロセス——データの収集から最後の Refine / Interact まで、**一方向に進むのではなく、常に前の段階に戻ってやっていく必要がある。**そのループを繰り返すことで質が高まっていく。

まさにこのモデルの通りの進め方だったなと思いました。

これらの段階は、コンピュータサイエンスやフィルタリング・マイニングのところでどうしても先生方の力を借りるので、非常にいろいろな方が関わってくる。そういう中で一つ一つバラバラのツールでやっていると時間も食うし、特に手戻りが発生するとかなりストレスになる。

タイトなスケジュールの中、日々変わるデータがあるところを一つのプラットフォームで回していくことで、かなりスピーディーにできたのかなと思っております。

それから最後に、放送素材としてのクオリティアップをどうしてもかけなければいけない。ここはやはり Processing の強いところかなと思いました。「ちょっとここの色味が」「もう少し透明度があった方が」といった要望に、他のツールだとなかなか難しいところをかなりタイムリーに対応できたかなと思います。

評価

日本科学未来館で展示した際にアンケートを取らせていただきました。ゲノムと3Dマップの両方について「分かりやすいか」「美しいか」「興味が湧いたか」などを聞いたところ——

分かりやすい、興味が湧いたが高い
ゲノムの方は「美しい」という声がかなり多かった
「知らなかったことが分かった」も高い数値

ただ**展示形式が口頭説明中心だったので「説明員がうまかったんじゃないの」という可能性も否定できない。**そこで「どこが印象に残っていますか」と聞いたところ、可視化のところが高かったという結果が得られております。

内部的な評価としては、担当いただいたプロデューサーの方によると——**最初「系統樹を3次元化する」と言ったときは現場もあまりピンと来ていなかったけれど、一緒に可視化を進めていく中で非常に可能性があると気づいていけた。**結果として4K/8Kでやる予定だったものが、局内での評価も良く、NHKスペシャルや展示の話につながっていったということで、制作チームの中でも評価が良かったかなと思っております。

まとめ

1月にまたアップデートしたバージョンを放送で使う予定です（番組名はまだ公表できません）。

最終的なまとめとしては——

専門家に読み解いてもらったものを、いかに普通の視聴者に届けるか、そして高画質なものを鮮度よく届けるか
Processing を使ったことで、Ben Fry のモデルを援用したプロセスをほぼその通りに構築できた
結果としてこれまでにない可視化を、かつ報道で利用できた
アンケートの結果から、オーディエンスの関心と理解を引き出すことができたと考えています

非常に駆け足になりましたが、これで私の発表を終わらせていただきます。どうもありがとうございました。

荻原和樹／新型コロナの特設サイトから見る報道とデータ可視化

Mon, 28 Dec 2020 00:00:00 +0000

Data Visualization Japan Meetup 2020（2020年12月28・29日開催）における、荻原和樹さん（東洋経済新報社）の講演です。「東洋経済オンライン新型コロナウイルス国内感染の状況」の制作・運営を通じて見えてきた、報道とデータ可視化の関係を語ります。

ご紹介にあずかりました、東洋経済新報社の荻原と申します。ちょうど昨年もここに招いていただいて、その時はリアルでお話ししたんですけど、今回はオンラインということで。よろしくお願いします。

新型コロナのいろんなデータを公開する特設サイトを作っていまして、制作もやって、開発もコードも書いて、デザインもして、必要だったら記事も書いて、毎日のデータ更新もやってくれる人がいないから毎日自分でやっている、という状況です。その制作から運営までを通じて見えた、報道とデータの関係、そして報道がこれからどう変わっていくのか——そんなことをお話ししたいと思います。

自己紹介

肩書きをどう名乗るかはいつも悩みの種なんですけど、だいたいデータジャーナリストとかデータ可視化デザイナーと名乗っています。

東洋経済オンラインというメディアで、報道コンテンツとしてデータビジュアライゼーションを使っています。地図だったり、3D だったり、アニメーションだったり、あるいは静止画1枚のインフォグラフィックを作ったり。他にも社内向けのデータ分析ダッシュボードを作ったりもしています。

だいたいいつも自分で企画を立てて、デザインして、データを収集して、必要なら Python なども使ってデータベースにして加工して、JavaScript でビジュアライズして、そのページと一緒に記事も書いて公開する——そんな仕事です。あまり似た仕事をしている人はいないんじゃないかと思います。

略歴としては、新卒で今の会社に入って、最初はデータベースや Web の開発をしていました。それからデザインを勉強したいと思ってイギリスの大学院に留学し、デジタルデザイン、3D アニメーション——みんながゲームデザインをやるような専攻でした——を学んで、戻ってきて編集部で今のような仕事をしています。

昨年は E2D3 というオープンソースのコミュニティの方々と協力して本を出させていただき、その中でインフォグラフィックのあたりを担当して書いています。

これまでの作品

甲子園の投手はどれだけ過剰な投球をしているか

昨年の夏に公開した、1枚の画像で表すインフォグラフィックです。

甲子園の投手は非常に過密な日程で、しかもその高校に投手が一人しかいなかったりするので、すごい数の球を投げなければならない。本来なら休養日や1日あたりの投球数の制限が必要なところ、甲子園には基本的にそういう制限がない（少なくとも2019年まではほぼ無かった）。

野球雑誌やスポーツ新聞では「早稲田実業の斎藤佑樹が948球投げた」「金足農業の吉田輝星投手が889球投げた」といった単独の数字は出ていました。でも、それが本当にどのくらい重いものなのかは、あまり注目されていなかったんです。

そこで比較対象として、アメリカの投球ガイドライン Pitch Smart を使いました。青少年の肩と健康を守るために、1日あたりの投球数制限や「何球投げたら何日休まなければならない」という休養日制限が定められています。これを日本の高校野球の選手に当てはめたらどうなるかをカウントしたのがこのインフォグラフィックです。

白：一応ガイドラインの制限内
黄色：1日あたりの投球数制限を超えている
赤：休養日制限を超えている

見ると、赤と黄色の合計が軒並み半分から3分の2くらいを占めている。つまり Pitch Smart を適用したら、彼らは本当は半分から3分の1くらいしか投げてはいけないということになります。

そして赤が多い。つまり休養日制限が特に深刻だと分かります。甲子園は参加チーム数が減る後半になるにつれて日程が過密になっていく。最初は47都道府県ありますから1試合したら何日か空けられますが、**準決勝・決勝になると、試合をして次の日また試合、ということになる。**そうすると休養日制限を全く無視した投球をせざるを得なくなるわけです。

世界のパスポート

パスポートの情報を解析して、どの国からどの国にビザなしで行けるかを表したものです。

日本の場合、ビザなしで入れる国が122カ国。ビザ・オン・アライバル（到着時にビザを発行）の国が42カ国、ビザが必要な国が34カ国。日本から伸びている線がビザフリーで行ける国で、赤がビザフリー、青がアライバルです。

日本だと結構いろんな国に行けるんだなと分かります。アメリカもそう、イギリスもそう。それに比べてインドだとビザフリーの国は25カ国だけで、ビザが必要な国のほうが多い。北朝鮮だと11カ国だけだったりします。

今年は1本だけ ― 新型コロナ特設サイト

……と、ここまでお見せしたスライドは、実は2019年に作ったものと全く変わっていません。今年は1個しか出していないんです。「新型コロナウイルス国内感染の状況」というビジュアルページです。

2月27日ごろにオープンして、ここまで注目されるとは思わなかったんですけど、ほぼずっと毎日データ更新をして、改修やメンテナンス、問い合わせ対応といろんな作業をしている1年でした。

ありがたいことに、「新型コロナウイルス」という単語を含む Web コンテンツの中で報道コンテンツとしてはシェア1位になりました。Facebook で12.5万回、Twitter は「9万9999回」でカウントが止まってしまうようなので、実際はもう少しシェアされていると思います。グッドデザイン賞や SmartNews のベストパートナーアワードなどもいただきました。

コンセプト ― 冷静に現状を把握する

このサイトのコンセプトは「冷静に現状を把握する」でした。

皆さんが目にするニュースは、速報のストレートニュースが多いと思います。「今日の感染者数は何千人でした」「今日時点の東京都の感染者数は何人」「PCR 検査数は何件」といった情報です。

このサイトで心がけたのは、まず冷静に、現状がどうなっているのかをワンストップで把握できるようにすること。そのために速報ではなく時系列のグラフをメインにしました。今では当たり前と言われるかもしれませんが、当時はこういうグラフ自体があまり手に入らなかったんです。

HUD デザイン

配色についても、HUD（Heads-Up Display） を参考にしました。SF 映画などでよく見る、暗い画面に蛍光色の要素が浮かび上がるようなデザインです。「HUD」で英語検索するとたくさん作例が出てきます。

これをもとに、配色とデザインをすごく落ち着いた感じにしようと心がけました。暗いトーンで、色は基本的に蛍光色の青緑——少し緑がかった青がメインです。赤やきつい黄色といった危険色をできるだけ使わない。

なぜか。私がこれを作っていた2月中旬というのは、ダイヤモンド・プリンセス号の話が大きく報じられ、中国が武漢の街を封鎖し、そのウイルスがいよいよ日本に入り始めている——という状況でした。社会的な不安としてはかなりピークに近かったのではないかと思います。

不安を煽るような情報が非常に多く出ていて、「コロナ疲れ」「報道疲れ」、あるいは「インフォデミック」という言葉に代表されるように、毎日の暗いニュースを見るのに疲れてしまった人が Twitter を見ていても多かった。それを受けて、落ち着いてデータを見られる、冷静に状況を把握できるサイトを作ろうというのが出発点でした。

解釈はしない、解説は厚く

このページでは、基本的に解釈はしません。「これはこういう意味なんですよ」「今あぶないですよ」といった解釈はしない。

その代わり、いろいろなデータをただ見せられるだけだと混乱してしまうでしょうから、「よくあるご質問」のようなコーナーを設けて、解説はたくさん入れようと。皆さんが疑問に思うであろうことを結構たくさん入れて、状況に応じて差し替えたり修正したりしています。

あくまでマスに届ける

もう一つ。このサイトはあくまでマスに届けるものです。専門家のためのものでも、高度な分析をするものでもなく、とにかく基礎データを把握するためのもの。

私がマスメディアの人間としてやるべきことは、まず基礎的なデータをいろんな人が見られるようにすること。自分の両親でも、母方の祖母でも、どこの地方にいても見られるようにする。それがこのサイトの目的でした。

そのために新規と累計の切り替え、後方7日移動平均（最新の日から数えて直前1週間の平均値）といった仕掛けを作りました。5月ごろには実効再生産数——1人の感染者が平均して何人に感染させるかを表す指標——を、当時北海道大学にいらした西浦教授（いわゆる「8割おじさん」）の監修を受けて追加したりもしました。

毎日やっていること

実際にどんな作業をしているかをお見せします。

厚生労働省のウェブサイトに「新型コロナウイルス感染症の現在の状況と厚生労働省の対応について」という、とても長い名前のページが毎日更新されます。長い上にリンクがたくさんあって、少し分かりにくい。これを毎日読んでいます。

システム力の高い優れたエンジニアなら完全自動化できるんじゃないかと思うんですが、この辺の中身が日によって変動したり、ある日突然重要な注意書きが付いたりするので、私は毎日確認するようにしています。

クイズ ― 「感染者数」はどの数字か

せっかくなので、クイズを。

厚労省のサマリーの表が出ています。我々が今「検査陽性者数」とか「今日の感染者数」と呼んでいる数字は、どこでしょうか。

……「ここだ」と思った人が多いんじゃないでしょうか。**縦の、陽性者数の合計の数。**いろいろあるけど合計の数だろう、と思いきや、実はこちら——「国内事例」なんです。合計ではありません。

正確に言うと、ここの数は厚労省のオープンデータとも微妙に違っています。本来は同じでなければいけないのですが、厚労省のオープンデータは、過去分の訂正の際に日付が分からないものを計上に入れていないからです。オープンデータは「何月何日に何人」という形式なので、日付が分からない場合は計上に入れられない。それで微妙にずれるんです。

とにかく定義としては**「国内事例」であって、空港検疫やチャーター便で帰国した事例は入れていない**。

なぜか。報道は加熱しているのにデータが把握できない状況だった。そのとき読者が知りたいことは、おそらく国内の感染状況——「自分や自分の家族が感染する可能性はどのくらいなんだろう」ということだろう、と考えてこの形式にしています。

Do one thing well（スティーブ・ジョブズが言ったんでしたっけ）。「国内感染の状況」というタイトルからも分かる通り、何でもかんでも手を広げず、一つのことに注力するプロダクトを心がけていました。

これは他社との競合の際にも役立ちます。何でもやるプロダクトを作ると、最終的には資本力・技術力の戦い、速報の戦いになってしまって、我々のような小さいメディアには勝ち目がないんです。

私はこれを「データ編集」と呼んでいます。世の中にいろんなデータが公開されている中で、何を選んで何を出さないか。コンセプトを決めて何をやるかを決める。グラフを作り始める前、コードを書き始める前、デザインをする前の作業がすごく大事だと思っています。

信頼できないデータと戦う

もう一つは「信頼できないデータと戦う」ということ。

COVID-19 の特徴として——

感染→発症→検査→報告に2週間ほどのタイムラグがある
無症状感染者がいて、感染している数の正確な状況が出せない
集計基準の変更。自治体や厚労省側の事情で、集計基準が変わったり、最新の値だけがこっそり更新されたりする

つまり完璧なデータが揃わない、でもビジュアライズしなければならないという状況です。

もちろんデータが完璧に速報で揃えばそれでいいのですが、往々にして世の中はそうではない。厚労省も普段は月次や年次の統計を作っている組織ですから、日次で、しかも現在進行形の事象をデータ化するとなると、どうしても基準の変更などは起こってしまう。

そういうときにどういう注釈をつけるか、グラフの視覚的な表現をどう変えるかを考えるのも、データ編集のうちだと思っています。

データを見る力は汎用的ではない

「データを見る力」が汎用的かというと、ちょっと違うのかなと実は思っています。

Twitter を見ていると、おそらくデータを見慣れているはずの分野の方——ぼかしますが理系の研究者、しかも結構な大御所の方——が、割と盛大にデータを読み違えていたりする。

そこで思ったのは、そういう方々は普段カチッとしたデータ——訂正や、統計に現れない数といったものがあまり無いデータ——を扱っているから、それと同じ感覚で COVID の状況を扱ってしまって、違う解釈をしてしまうのではないか、ということです。

**一口にデータと言っても、その文脈や、公的統計の事情によって読み解き方は全然違う。**そういうものに配慮する、考えるということが重要なのかなと思います。

データ可視化は、サイエンスよりアートに近い

データサイエンスが一方にあるとして、データのビジュアライゼーション自体はサイエンスというよりアートに近いのかなと思っています。

客観的なデータ可視化、完璧なデータ可視化は、おそらく存在しません。

先ほどの例で言えば、空港検疫やチャーター便、ダイヤモンド・プリンセス号を私は含めませんでしたが、もちろん含めても全然正解だと思います。厚労省から合計の数字もちゃんと出ているわけですから。正解がどちらにあるかではなく、どちらを選ぶか、どちらがより重要だと判断するかの問題です。

用語の表記も同じです。「感染者数」と表記するか「検査陽性者数」と表記するか。**私は後者を使っています。**無症状感染者の存在があるので「感染者」と「検査陽性者」はイコールではないだろうと思うからです。ただ「今わかっている感染者数」と言い換えるのであれば、感染者数でも間違いではない。

配色、デザイン、地図表現についても同じことが言えます。

**サイエンスであれば、同じ材料・同じデータから同じ分析手法を適用すれば、みんな同じ結果になるはずです。**再現性がなければサイエンスとは呼びにくい。でも今メディア各社から出ているデータビジュアライゼーションのページを見ると、各社いろんな工夫が凝らされている。

私がよく使う表現は「データの翻訳」です。文章表現に近い。**データという、我々にはよく分からない外国語を、視覚表現という我々がよく知っているものに翻訳する。**基礎的な部分はみんな同じ——「今、感染者数が減っていますよ」とビジュアライズする人はいないでしょう——けれど、細かいところでは各人のこだわりやバックグラウンドがあって、翻訳が分かれてくる。

「データだから受ける」という時代は来ない

作る側の視点から言うと、「データだからこれは受けるだろう」「データだから必要とされる」という状況は、もう来ないんじゃないかと思っています。

これだけ多くの会社が、個人が、データビジュアライゼーションを公開したり分析をしたりしている中で、データを出せばそれで受ける、ということはもう無い。

**データだから、ではなく、そのデータを通じて何を表現するか。**文章と同じです。「文章表現だからきっと受けるだろう」ではなく、その文章でどういうふうに記事を書くかが問われるのと同様に、データをどう扱い、どうビジュアライズし、どう要素を配置するかが重要なのだと思います。

オープン化 ― 透明性の確保

今回、GitHub でデータとソースコードを公開しました。日本の報道機関では初めてなんじゃないかと思います。

なぜやったか。まずは透明性の確保です。

ビジュアライズには、恣意的なもの、偏った解釈になってしまう可能性が常にあります。客観的なビジュアライゼーションができないのであれば、どうするか。「我々はこういうデータを、こういうふうに料理して、こういうふうにビジュアライズしましたよ」という一連の流れを全部オープンにして、いつでも検証できるようにすることにしました。

従来の一般的な記事だと、出典は「厚生労働省より東洋経済作成」といった書き方になってしまう。それだと読者が流れを追えなかったり、「なんでこうしているの」という疑問が生じたりするのではないかと思うので、こういう形にしています。

Twitter の反応を見ていると「東洋経済が信頼できるかは分からないけど、厚労省のデータをオープンにしているから信頼できるだろう」という人もいました。いきなり「全部ブラックボックスにするけど東洋経済を信用してくれ」というのはさすがに難しいでしょうから、まずはそういうところから出発できたらいいのかなと思っています。

ただし双方向性は慎重に

オープン化には2つの側面があります。我々が何を考えてやったかをオープンにすることと、プルリクエストや issue でいろんな人の意見を受け入れることです。

後者については、慎重になったほうがいいのかなと思っています。

たとえば、毎日のデータ更新をボランティアの方にお願いする——これは慎重になったほうがいい。データに不備があったら誰の責任かという問題がありますし、メディアの責任として一次情報にちゃんと当たるというのが報道の責任だからです。厚労省のページなり会議なり取材なりを通じて、うちがちゃんとオープンにするのが適切だろうと。他社がまとめたものを使ったりも、今のところしていません。

改修についても、読者が言ったからやる、ではなく、決定自体は編集部・我々が主導で決めるべきなのかなと思っています。その上で、「こんなふうにやりましたよ」「いつ変えましたよ」を透明にするのがいいのかなと。

可視化は「届ける範囲」で3種類に分かれる

データ可視化は、誰に届けるかによって重視することが違ってくると思っています。以前ブログにも書いたことですが——

自分のためのデータ可視化：自分のメモ用。正直、何でもいい。自分が分かればそれで OK
組織のためのデータ可視化：社内向けのレポートやダッシュボード。シンプルさ・分かりやすさ。メールや社内文書と同じで、簡潔で明晰なものが求められる
社会のためのデータ可視化：我々報道がやるもの

3つ目については、「分かりやすい」「見やすい」だけでは、たぶん見てもらえないのではないかと思っています。

データを見るという行為は、おそらく多くの人にとって苦しいものです。私はデータを見るのが好きだから数字が並んでいてもずっと見ていられますが、一般の方はそうではない。ですからデータを見るという行為の負担を少しでも和らげるための工夫が必要になる。今回の新型コロナのダッシュボードで言えば、HUD デザインで少し暗い、かっこいい感じにするというのがその工夫の一つだったりします。

なぜ日本でデータジャーナリズムが根付かないのか

最近考えていることです。

報道関係の人と話していると、「データジャーナリズムやデータビジュアライゼーションは欧米の先進的な機関がやっているもの」というイメージを持っている人がたまにいます。でもいろんなアワードを見ていると、アジアやアフリカからもガンガン出品がある。むしろマーケットの大きさを考えると、日本だけが例外的に進んでいないんじゃないかという気がしています。

何が考えられるか。

**編集部にほぼ記者しかいない。**私は今編集部所属ですが、周りは全員記者で、コードを書いているのは私だけ。エンジニア・デザイナーと編集者・記者の物理的な距離感が大事なのかなと
テキストがメインという前提がある
プラットフォームへの配信優先

3つ目について。ロイター研究所の「デジタルニュースレポート」で、日本とアメリカで人がどのメディアを見ているかを比べたグラフがあります。アメリカと違って、日本では1位の Yahoo! ニュースがダントツであることが分かります。Yahoo! ニュースがドーンと来て、その次に NHK、日テレ、テレ朝、朝日新聞、フジテレビと続く。アメリカでは CNN があって Yahoo があって New York Times があって、とコンテンツプロバイダーとプラットフォーマーが拮抗しているのに対し、日本ではプラットフォーマーが優先です。

それがデータジャーナリズムと何の関係があるのか。プラットフォーマーに送る記事は、ほぼテキストや画像といった固定されたフォーマットしか認められないんです。セキュリティ的には当たり前なんですけど。そういう事情があって、自社サイトでしか公開できないデータジャーナリズム、特にインタラクティブなものは難しいのかなという気もしています。

あとは、記者が担当業界・企業・地域で手一杯だったり、速報や独自情報が評価される世界というカルチャーもあるのかなと思います。

日本のデータ報道でてっぺんを取ろう

最後に言いたいことは、ぜひ皆さん、日本のデータ報道でてっぺんを取ろうということです。

日本のデータジャーナリズムはまだまだ遅れている、とよく言われます。でも逆に言えば、いろんな分野・いろんな試みで「日本初」「日本一」になれるということなんじゃないかと思うんです。

先ほど「GitHub での公開はたぶん日本で初めて」と言いましたが、**エンジニアの方であればほぼ常識に近いような「GitHub でソースコードを公開する」というだけで日本初になれてしまう。**今回も、厚労省のデータをチャートにするという、ある意味それだけのページが一番シェアされてしまったりしている。

**いろんな試みで、まだまだ日本初・日本一になれる可能性がある。**今の日本だと結構珍しいことなんじゃないかと思うんです。

ぜひ2021年が「データジャーナリズム元年」みたいになれば——すみません、10年くらい前に誰かがもう言っていたら申し訳ないんですけど——今回のコロナによってデータビジュアライゼーションの力が社会的に認知されてきた気がするので、そういうものがもっと発展していけたらいいなと思っています。

ProPublica の8つのコツ

ではどうすればいいか。アメリカでデータジャーナリズムが非常に得意な報道機関 ProPublica が、コツをまとめた記事を出しています。

ジェネラリストを雇う ——ジャーナリズム／コード／デザインという3つの大きなスキルのうち、2つ以上を持つ人を採用する
ニュースアプリの開発者を「書き手」として扱う ——エンジニアやデザイナーを、記者と同等の立場で扱う。発注を受ける立場ではなく
Don’t cross the streams ——ニュースアプリ／ニュースコンテンツの開発者に、コーポレートサイト制作のような別の仕事をさせない

こういうところを見てみるといいと思います。

来年もまたいろんなデータに挑戦していければと思っています。引き続きよろしくお願いします。ありがとうございました。

西田勘一郎／データサイエンス革命の駆動力 ― データリテラシーとデータの可視化

Mon, 28 Dec 2020 00:00:00 +0000

Data Visualization Japan Meetup 2020（2020年12月28・29日開催）における、西田勘一郎さん（Exploratory, Inc. CEO）の講演です。科学哲学の視点からデータサイエンスを捉え直し、コロナ禍のデータを実際に可視化しながら、市民のデータリテラシーの重要性を論じます。

皆さん、こんにちは。矢崎さんに招待していただきました。

今日は「データサイエンス革命」と私たちが呼んでいるものについて、その中心となるのはデータリテラシーとデータの可視化ではないかというお話をします。

今年はコロナで、ほぼインパクトを受けない人が世界中にいなかったくらいの大きな出来事でした。いろいろ考えさせられる年だったと思います。その中で、データに関わる人間として、データの力に対する大きな失望と、同時に期待を感じるような1年でした。

自己紹介

Exploratory という会社で CEO をやっています。2016年の春にシリコンバレーで、データサイエンスを民主化するために立ち上げました。

Exploratory というアプリケーションを作っていて、データサイエンスをもっと簡単に、誰もがアクセスできるようにしています。ただツールを作るだけではデータサイエンスの民主化はできないので、皆さんの知識やスキルを向上させるべく、データサイエンス・ブートキャンプなどのトレーニングを通じて普及と教育も日々行っています。

私たちのビジョンは「誰もがデータをもとに、より良い意思決定をしていける世の中になる」こと。ミッションは「データサイエンスを民主化して、この言葉がなくなるくらい当たり前に使いこなせる時代にする」ことです。

Exploratory というツールは——データを取ってきて、加工して、可視化する。そして「アナリティクス」と呼んでいる機械学習や統計のアルゴリズムを取り入れて、可視化だけでは捉えきれないパターンやトレンドを発見する。さらにレポートやダッシュボード、スライドとしてより多くの人にコミュニケートしていく。それを一つのシームレスな体験として提供できないか、というツールです。

データサイエンスとは何か

「データサイエンスとは何か」という話はよくあります。100人に聞いたら100通りの答えが返ってくるようなもので、私自身はその定義自体にあまり興味はありません。酒のつまみにはなると思いますが。

言ってみれば、**社会的なゴールがあって、それを達成するためにデータをもとにより良い意思決定ができるようになるべきではないか。**私たちが考えるデータサイエンスは、いつも人間が中心にいて、人間がより良い意思決定をするためにデータを使えないかということです。

そこでデータを使うだけでなく、サイエンスの手法を使う。

「そもそもサイエンスの世界にはデータはいつもあるのだから、データサイエンスなんて言わずにサイエンスでいいじゃないか」という言い方もあると思います。ただ今**一般的に使われているデータサイエンスには、「ビジネスにサイエンスの手法を持ってくる」という文脈がある。**データをしっかり使って意思決定することでビジネスをよりよく回していく、という側面です。

ここで強調したいのは——データサイエンスはアルゴリズムや AI といった特別なテクノロジーの話をしているというよりも、ゴールがあって、そこに行くための手段。データサイエンスそのものがゴールではないということです。

サイエンスとは何か ― カール・ポパー

では、そのサイエンスとは何なのか。ヒントとして、カール・ポパーという哲学者の言っていたことが非常に参考になります。

すべての法則や理論は、もはや疑いないと思われるときでさえ、暫定的・推測的・仮説的でしかない。それは誤りや無知として摘発される可能性を、原理的に持っているのである。

これがすごく重要だと思うんですね。

アメリカでもこの1年、「サイエンスをもとに」という言葉をみんな簡単に言っていましたが、誰もサイエンスの本当の意味を理解せずに、サイエンスを宗教として扱って「サイエンス＝正しいもの」という形にしてしまっていた。

そもそも私たちが思っていることは仮説でしかない。ここを忘れるべきではない。今持っている理論だと思っているものでさえ間違っている可能性があり、「まだ棄却されていない仮説」を、私たちはたまたま持っているだけなのです。

疑似サイエンス ― フロイトの例

ポパーがよく使っていた例がフロイトに代表される心理学です。何も証明することができないし、それを使って予測することもできない。

フロイトは「子どもの頃の経験は、大人になってからの行動や精神状態に大きく影響する」と言います。私もニューヨークにいた頃、結婚してからもセラピストに会っていたことがありますが、だいたい**「子どもの頃どうだったか」という話になる。**

いま人間関係で問題があるとすると、過去に遡って「この時の経験によって今の問題が作られているのではないか」という話になっていく。**「母親の愛情を十分受けていなかったから、今、自信がなくて人間関係もうまくいかない」**と。

でも、もし実は愛情をしっかり受けていたとしたら? そのときは「逆に愛情を受けすぎていた。そのせいで母親がいないと自信がない人間になってしまった」と言うことができてしまう。

つまり——**過去に起きたことによって現在を予測しているように見えるが、それは予測ではなく「解釈」**ではないか。過去にあった都合のいいことを、現在を説明するために引っ張ってきて、うまく解釈をつけているだけではないか。それが疑似サイエンスだ、とポパーは言うわけです。

サイエンス ― アインシュタインの例

では、サイエンスとはどういうことか。

アインシュタインのような科学者がやっているのは、過去のデータから現在を解釈することではなく、過去のデータから将来を予測するための理論を作ること。そしてその理論によって将来を予測する。予測することで「間違っている」と証明されるリスクを引き受けている。

アインシュタインは1915年に一般相対性理論で、重力は局所的に観察される現象であること、光より速いものはないこと、太陽の光は地球に届くまで8分ほどかかることを説明しました。

それまで——ニュートンの時代の重力の考え方は「質量を持った物体間の引き合う力」で、しかも無限大の速さで伝わるとされていた。ところがアインシュタインは時空（スペースタイム） という概念を持ち込んで、その歪みこそが重力であり、光より速いわけはないと言ったわけです。

重力が時空の歪みであるなら、光の軌道も重力によって曲がる。

そして何年か後に日食がありました。そのとき、本来であれば太陽の影になっているはずの星が、なぜか太陽の横にあるように見えた。

なぜか——**星から地球に届く光が、太陽の周りにできた時空の歪みによって曲がる。**すると地球から見ると、**あたかもその星が別の場所にあるように見える。**実際の場所は違うところだった、と。これがアインシュタインの理論で、後になって証明されたわけです。

アインシュタインの理論についてはこういうニュースがたくさんありました。ブラックホールなどもそうです。

当たり前のことのように聞こえますが、こういう科学者は「予測することで、観測されたときに間違っていたと言われるリスクを負っている」。それこそがサイエンスだというのがポパーの主張です。

まとめると

今持っている理論は、間違っている可能性がある
間違いが証明されるまで、たまたま正しいと思っているだけ
仮説からいかに間違いを排除していくかがサイエンス
ということは、その仮説が正しいか間違っているかを判断できるような仮説にしておかなくてはいけない

良い仮説の条件は——

計測できる（データに関わる人には当たり前でしょう）
検証できる（正しいかどうかテストできる）
反証できる（間違っていると言える基準があるかどうか）

3つ目が最も重要です。

コロナでもそうですが、「マスクに効用がある／ない」「インフルエンザと比べて恐れる必要がある／ない」「都市封鎖をすべき／すべきでない」——そういうとき、「もし自分たちの仮説が間違っているとしたら、何をもって間違っていたとするのか」が明らかになっていないと、終わりのない議論になっていく。

サイエンスのプロセス

問題を定義する → 解決するための仮説を作る → 実験してデータを取る → データを分析する → 仮説が間違っているかどうかを判断する → 「今日までは間違っていると言われていない理論」を作る

その理論があれば将来を予測できるし、間違っているならそう判断されるべきです。

良い質問と、探索的データ分析

では仮説をどう作るか。やはり質問が重要になってきます。

正しい質問に対するおおよその答えの方が、間違った質問に対する正確な答えよりも、よっぽど良い。 ——ジョン・テューキー

テューキーは探索的データ分析（EDA） を70年代ごろに提唱した人です。

探索的データ分析とは、簡単にまとめると——予測、また将来をコントロールするために、データに対してたくさんの質問を投げかけて答えを探していく。それをもってより良い仮説を構築していくための分析。

**「データサイエンスとは、そもそも探索的データ分析だよね」と言う人もいます。**サイエンスがいかにより良い仮説を作り上げていくかということであれば、データを使ってより良い仮説を構築していくことこそがサイエンスの醍醐味ではないか。

可視化するだけで、かなりのことが分かる

ここが今回のテーマです。

データサイエンスというと、機械学習や AI、難しそうな統計を考えがちですが、データを使って可視化をするだけで、かなりのことが分かってくるのではないか。

今回のコロナでも、**データはたくさんありました。**日本政府も PCR 検査数、感染者数、死亡者数、入院患者数を出していたし、東京都や地方自治体も、世界中の組織や大学も。オックスフォードは各国の都市封鎖の強さを数値化して公表していました。

リアルタイムで、世界中の誰もが、無料で、許可を取ることもなくダウンロードして使えるようになっていた。

ところが——データはあったけれど、おかげで世界中の人・政府・組織がより良い意思決定をできていたのかというと、すごく疑問が残ります。

ビッグデータの世界でよく言われることですが、データはどんどん増えているのに、そこから得られる知識は増えていない。

なぜか。そもそもみんな、そのデータをダウンロードすらしていない。ダウンロードしていないので、可視化すらしていない。

**みんな難しく考えすぎているんです。実は可視化するだけでかなりのことが分かる。**メディアから垂れ流される情報だけでは分からない情報が見えてくる。専門的な知識を要することもなく、ただ単に現状を把握するだけでも、かなりのことが分かると思うんですね。

例① 検査数と陽性者数

これは厚生労働省からダウンロードしてきた PCR 検査数です。3月ごろに最初の大きな波があって、夏、そして最近と波があり、今どんどん増えている。

オレンジが検査数、青が陽性者数です。（可視化のカンファレンスで、凡例もタイトルもない酷い見せ方を一つしてしまっていて申し訳ないのですが。）

検査数は上がっているけれど、陽性者数自体はあまり上がっていないように見える。

数の桁が圧倒的に違うので、スケールを変えて第2軸を使ってみると——**この2つは相関しているように見える。**同じ時に上がって、同じ時に下がる。

「最近すごく陽性者数が増えている、大変なことになっている」と考えることもできますが、「ただし検査数も増えている」という情報を文脈として捉えておくのは、すごく重要だと思うんですね。

さらに死亡者数も重ねてみると、陽性者数は上がっているけれど、死亡者数は上がってはいるものの、ものすごく上がっているわけではないことが見えると思います。

例② スウェーデンは本当に「大変なこと」になっていたか

日本はいわゆる欧米で言うロックダウンをほぼしていません。一方、欧米は思い切ったロックダウンをしました。

このロックダウンが必要だったのかという話でよく出てくるのがスウェーデンです。（『ファクトフルネス』を書いたハンス・ロスリングの出身国でもありますね。）

この国は基本的にロックダウンをしなかった国で、「スウェーデンはロックダウンしなかったから大変なことになっている」という話をメディアでよく目にします。特にアメリカにいると。

しかしデータにして、ただ時間軸で人口あたりの死亡者数を見るだけで、全然違う姿——というより、より現実にある姿が見えてきます。

このチャートで、**一番大きな青いのがスウェーデンなら「ロックダウンしないとある程度の被害は起きるのかな」と見えそうですが、これはベルギーなんです。**その次に多いのはスペインやイタリア。

**では、スウェーデンはどれくらいか。この辺です。**別に少ないわけではないけれど、多いわけでもない。

こういう質問はすごく重要だと思うんですね。「ロックダウンをしなかったから大変なことになっているのか」というとき、「他の国、施策をしていない国と比べて明らかな差があるのかないのか」。見たところ、そんなに差がない。

これだけで「ロックダウンは意味がなかった」という結論に持っていくわけではありません。それぞれの国の事情は違うので。ただ、こういうデータの見方は文脈を捉える上で重要なのではないか。

これこそが私の言おうとしている可視化の力です。この上にさらに統計の難しい話をしていきがちですが、「これ以上のことが本当に分かるのか」。可視化しただけでかなり十分な文脈が分かる。ですが、なぜかここまでもみんなやらない。これこそが今の問題なんじゃないかと思っています。

例③ 日本はどうなのか

「感染者数が大変だ」と言っているこの日本を見てみると——**赤いところです。**スウェーデンよりももちろん低いですが、**ここにあるどの国と比べても圧倒的に低い。**人口あたりの死者数で比べると。

私はアメリカにいますが、アメリカやイギリス、ヨーロッパの人たちが「コロナが大変だ」と言っているその大変さとは、全然違うはずなんですね。

こういった文脈を、データにして可視化することによって捉えておくのはすごく重要だと思います。

**私が言いたいのは「日本は全然心配する必要ない」といった大げさなことではありません。**ただ、こうやって比べることで、どれくらいのインパクトがあるのか、どれくらいの影響が起きているのかを知ることが重要だということです。

これから皆さんの毎日の行動が変わるかもしれない。ビジネスが、仕事が、学校が変わるかもしれない。そういうときに、これくらいの文脈は誰もが捉えておくべきだと思うんですね。

そしてなぜかメディアは見せない情報なので、一人ひとりの市民がこういう情報を自分で掴んで、さらに発信していくことが求められている時代なのではないかと思います。

例④ オックスフォードのロックダウン指数

各国の都市封鎖、マスク、学校閉鎖、職場閉鎖、ソーシャルディスタンスといったものを重み付けして指数にしたものです。赤が日本。

これを見ると、日本は1年を通じてずっと比較的緩い。「緩いから最近の感染者数が増えているんじゃないか」という考え方もできますが、逆に、日本よりずっと厳しい国がたくさんある。

こんなに厳しい国があるにもかかわらず、なぜこういう差が出ているのか。この質問はすごく重要な質問だと思うんですね。私も今でも自分に、そしていろんな人に問い続けています。

**「日本が欧米並みの都市封鎖をすることで、本当にそれが役に立つ」ということが、こういったデータから捉えきれるのだろうか。**それはどこかの理論なのかもしれないけれど、**それはフロイト的な理論ではないのか。**本当にデータからそういった傾向が掴めるのかどうか、見て比べていく必要があるのではないかと思います。

データサイエンス革命 ― 宗教改革との相似

今回のコロナの経験から、私たちは何を学ぶべきなのか。

宗教改革が16世紀に起こります。その前の15世紀にグーテンベルクが印刷機を発明し、その後に宗教改革があり、さらにその後に科学革命がある——15・16・17世紀という流れがあります。

もともと昔は、**教会がすべての情報を管理していました。**ほとんどの人は教会に行って、司祭の言う情報を得た。**なぜかというと、聖書がそこにしかなかったから。**聖書を作るのは大変で、みんな手書きで書いていたわけです。

**それが印刷機の発明によって、聖書が一気に増えた。そうすると教会が聖書を独占できなくなり、多くの人が聖書に直接アクセスできる時代になった。**ここでプロテスタントの改革が起きるわけです。

このときに一気にリテラシー（読み書き）が上がって、多くの人が実際に聖書を読める時代になっていく。

グラフの上の方——オランダ、イギリス、スウェーデンといったプロテスタントに流れた国のリテラシーが**1600年ごろから一気に上がっている。**カトリックの国に比べて特徴的です。

今、同じことが起きている

インターネット革命によってデータが一気に増えました。

**それまでデータは、科学者やメディアに独占されてきた。**それが今、データの数があまりに増えて、一般の市民が誰でも同じデータをダウンロードできる時代になった。

市民が直接データにアクセスして、そこから——真実と言うと大げさですが——現時点で起きている事実を掴み出すことができるようになった。一部の科学者、一部のメディアを通さずに。

これによってデータリテラシーがどんどん上がってくる時代になると思います。より多くの人がデータにアクセスして、データに質問を投げかけ、そこからいろんな議論をしていく時代になっていくべきなんじゃないかと。

これが私たちが言っているデータサイエンス革命です。

分からないなら、怖がるのではなく学ぶこと

もし分からないのであれば、するべきことは怖がることではなく、学ぶことだ。 ——アイン・ランド

コロナのように恐れやパニックが起きるときこそ、それが何なのかをしっかり学ぶべきだと思うんです。もちろんウイルスを学ぶこともありますが、現実に起きていることがどうなっているのかを学べるのが、実はデータだと思うんですね。

**そこで効果的な手段がデータの可視化。**答えは見つからないかもしれないけれど、目の前にあるデータに問いかけていくことによって、パニックになるよりは、少なくとも心の平静は取れる。

これこそが、今の時代のデータリテラシーの重要性です。

最後に

最後は告知っぽくなりますが、データサイエンス・ブートキャンプというトレーニングを提供しています。データの基礎、可視化の基礎、統計の基礎から始まってモデリングまで話しますが、**3日間を通して学んでほしいのは「どうやって仮説を作っていくか」、そして「どうやってその仮説を検証していくか」。**その手段としていろんな手法がある、ということです。

今回のオーディエンスの方たちはデータの可視化を共通項にされていると思いますが、可視化ができるということは、すでにデータサイエンスのコックピットにいると思うんですね。

**今わかっていると思っていることは仮説かもしれない。メディアやニュースから見たことも仮説かもしれない。**そこに対していろんな質問をして、いろんな角度から可視化することによって、データと対話していきましょう。

そしてデータリテラシーをもっと上げていくことで、より良い世の中が見えてくる。

いろんな意見を持った市民が多くなればなるほど、異なった意見でも健康的な議論をしていくことで、社会として、市民の集団として、より真実に迫っていくことができるんじゃないか。

これこそが、私が今年気づいたこと、再認識したことであり、今こそデータサイエンスとデータリテラシーがものすごく重要だと思っていることです。

すごく駆け足になってしまいましたが、以上で終わりたいと思います。どうもご清聴ありがとうございました。

新型コロナ on Data Visualization Japan

小副川 健／東京都新型コロナウイルス感染症対策サイトの開発に携わった話

自己紹介

シビックテックとは

私とシビックテック ― 7年

東京都のコロナ対策サイト

特徴① ソースコードが OSS として公開されていた

特徴② データもオープンデータで公開していた

受賞

62サイトへの横展開

なぜ横展開に意味があるのか

技術選定の話

Nuxt.js とは

Nuxt を選んだ本当の理由

ホスティング ― Netlify

UI コンポーネント ― Vuetify

ようやく可視化の話

なぜ Chart.js を選んだか

コンポーネント設計 ― スロット

実装中の「祈りのような心の動き」

リリース直後 ― リポジトリが特定される

コミュニティの受け入れ体制を作る

① 行動規範とコントリビューションガイドの整備

② Lint を CI にかける

③ Netlify のデプロイプレビュー

その道のプロが集まってきた

アクセシビリティ

多言語対応

これを「普通」にしていきたい

まとめ

山辺 真幸／新型コロナの最前線研究を伝える可視化と、テレビ番組のデータジャーナリズム

自己紹介

研究室のテーマ ― Nature Interpretation

研究室の過去の可視化プロジェクト

プロジェクトの狙い

なぜこのプロジェクトが立ち上がったか

放送実績

制作環境 ― NMAPS と Processing

① ゲノムの3次元系統樹

系統樹はどう作られるか

データの出どころ

色の違い ― D614G

横から見ると、政策の影響が見える

課題

② 感染リスクの時空間3Dマップ

「雲」に見立てる

CT スキャンのように切って俯瞰する

人の流動と重ねる

専門家と一緒に読み解く

制作の舞台裏

初期・中期・最終の3段階

スケッチから最終形へ

振り返り ― Ben Fry のモデル通りだった

評価

まとめ

荻原 和樹／新型コロナの特設サイトから見る報道とデータ可視化

自己紹介

これまでの作品

甲子園の投手はどれだけ過剰な投球をしているか

世界のパスポート

今年は1本だけ ― 新型コロナ特設サイト

コンセプト ― 冷静に現状を把握する

HUD デザイン

解釈はしない、解説は厚く

あくまでマスに届ける

毎日やっていること

クイズ ― 「感染者数」はどの数字か

信頼できないデータと戦う

データを見る力は汎用的ではない

データ可視化は、サイエンスよりアートに近い

「データだから受ける」という時代は来ない

オープン化 ― 透明性の確保

ただし双方向性は慎重に

可視化は「届ける範囲」で3種類に分かれる

なぜ日本でデータジャーナリズムが根付かないのか

日本のデータ報道でてっぺんを取ろう

ProPublica の8つのコツ

西田 勘一郎／データサイエンス革命の駆動力 ― データリテラシーとデータの可視化

自己紹介

データサイエンスとは何か

小副川健／東京都新型コロナウイルス感染症対策サイトの開発に携わった話

山辺真幸／新型コロナの最前線研究を伝える可視化と、テレビ番組のデータジャーナリズム

荻原和樹／新型コロナの特設サイトから見る報道とデータ可視化

西田勘一郎／データサイエンス革命の駆動力 ― データリテラシーとデータの可視化