D3.js on Data Visualization Japan

LT：田島将太／はじめての Data Viz が Twitter で100万回見られた話 ― Observable のススメ

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

Data Visualization Japan Meetup 2020（2020年12月28・29日開催）における、田島将太さんのLTです。

なお本記事は自動字幕をもとに整文していますが、この動画の字幕は認識精度が低く、固有名詞や専門用語の誤認識が多く含まれていました。文脈から復元していますが、細部は動画でご確認ください。

本日は「はじめてのデータビジュアライゼーションが Twitter で100万回見られた話」をします。

特に、編集部とデータジャーナリストが同じ方向を向いて作業するための言語化、それから試行錯誤しながらチャートを作って発信できるツールである Observable について紹介したいと思っています。

自己紹介

昨年まで前職のスマートニュースで事業開発とデータ分析をしていまして、今年はメディアコンサルタントとして、文藝春秋さんやフジテレビさんなど5社ほどのお手伝いをしていました。

完成した記事

こちらが完成した記事です。ハフポストさんの記事の中にチャートが3つ埋め込まれています。

日本のジェンダーギャップを、国際比較の観点や議会の女性割合といった切り口で可視化するもので、テキストとグラフが相互に情報を補いながら理解を促すコンテンツになっています。

真ん中のものはアニメーションになっていて、**これが Twitter で100万回再生されました。**1945年から2020年まで、各国の議会における議員の女性比率の推移が分かるコンテンツです。

企画の発端

普段メディアコンサルティングをしている市場調査から、Web メディアの戦略として取るべき柱の一つがデータジャーナリズムにあると考えていました。

ただ国内の事例を見ると、日経ビジュアルデータさんなどかなり本格的で気合の入ったコンテンツが多く、お話しする編集部の方が「自分たちにはできないんじゃないか」と感じてしまうものが多いように感じていました。

そこで今回は——

特設ページを作らない
CMS の改修をせずに大きなインパクトを出す
編集者と協力して一緒に作り上げる

ということを目指して取り組みました。

始める前に言語化したこと

そのために、まず始める前に3点を言語化して共有することから企画を動かしていきました。

読者に価値を提供できるか
チームの理解を得られるか
作成コストを抑えられるか

なぜハフポストにデータ可視化が必要なのか

ハフポストが感じていた課題として、扱う社会問題は社会的な合意形成が十分に取れていないものが多く、簡単に主張のぶつけ合いや誹謗中傷に陥りやすいというものがありました。

そこでデータによって、政治的イデオロギーに左右されないアジェンダ設定をすることで、会話の出発点とすることを目指しました。

インパクトの言語化

データビジュアライゼーションによって得られるインパクトを、社会へのインパクトとビジネス上のインパクトに分けて言語化しました。

この段階で実は編集部の理解を得られていたので、ビジネス上のインパクトを KPI に落とし込むところは実際にはやっていないのですが、こういったことを言語化してきました。

読者に提供する価値

データ可視化が読者に提供する価値を、3層で想定しました。

機能的価値：テキストを読まなくても興味を持てる／テキストを理解する助けになる
感情的価値：社会問題という「正解の分からないトピック」について、客観性の高い理解ができて安心するのではないか
社会的価値：データを見ることで他人からどう思われたいか——データに基づいて議論ができる、論理的でスマートな人物だと思われたいという価値を提供できるのではないか

グラフを作る上での指針

グラフを作る上で、まず指針を決定しました。これはまだ私の中では仮の指針で、今回のイベントを通して考えを深めたいと思っています。

インクルーシブであること ——グラフのタイトルで主張を固定するのではなく、グラフを見た人がいろんな解釈をできるようにする
再利用できること ——インパクトを最大限に出すために、1回で終わりではなく何度も使えるように
わかりやすいこと
公共性を持つこと ——ソースや取得先のデータに透明性を持たせる、色覚特性のある方に配慮する、など

ここまでが Why と What の話です。ここからは How のお話をします。

ツール ― Observable

今回データビジュアライゼーションに使ったのが Observable というツールです。

これは何かというと、Jupyter Notebook と GitHub と Excel を混ぜたような、JavaScript で動作するデータジャーナリストのためのツールです。

Jupyter Notebook のように、ノートブックという形で動き、一つ一つのセルに JavaScript や HTML を定義して対話的にコンテンツを作成できる
GitHub のように、ノートブックのインポートやフォーク——他人のものを簡単にコピーすること——ができるので、コミュニティの資産の上に立つのが非常に簡単
Excel のように、リアクティブなデータフローでセルが依存関係の順に実行される。そのため微調整や依存関係の把握が非常に簡単

こういった特徴は、今回のような——初挑戦で要件が変わりやすく、D3.js を学びながらサイトを作成し、CMS の改修をせずにアニメーションを記事に埋め込む——という条件に非常にぴったりでした。

実際に見てみるとこんな感じです。それぞれのセルで関数が定義されていて、右上に依存関係が出てきます。このチャート自体も、コミュニティのサンプルをフォークして自分でカスタマイズして作ったものです。

読者の反応

今回のアニメーションに対する読者の反応です。

「日本の女性参画の進みがいかに遅いかが分かりやすかった」
「北欧はともかく、メキシコや南アフリカがすごいのが意外だった」
「女性が少ないことに何が問題なのか」
「候補者に女性が少ないだけなのではないか」

批判的な意見もありましたが、**日本の議会の女性比率が低いという「事実」そのものを疑う発言は、観測範囲では見当たりませんでした。**これは議論の形成に貢献できたのかなと思っています。

そして、こうした反応は次のコンテンツにつながります。

「女性が少ないことは何が問題なのか」→ 「（女性が少ないことで）犠牲にしてきた何か」というテーマで新しい記事を書くことで会話を生み出せるかもしれない
「候補者に女性が少ないだけなのでは」→ 候補者男女均等法についてハフポストが次に出すことで、議論が進みやすくなるのではないか

学び

今回のアニメーションを通した学びとして——

メディアの皆様へ

**データのありかを知っているのは編集部です。**協業なくしてコンテンツは生まれません
ぜひデータ好きをクリエイターとして仲間にしてください
遠慮しないで What と Why を伝えてほしい

データジャーナリストの皆様へ

Observable が非常に使いやすいぞ、ということをお伝えしたいと思います

以上です。

大野圭一朗／今あえてコードから可視化を作る場合のツール

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

Data Visualization Japan Meetup 2020（2020年12月28・29日開催）における、大野圭一朗さん（カリフォルニア大学サンディエゴ校医学部）の講演です。生物学研究のためのツール開発という立場から、現代のコードベース可視化の実践を紹介します。

カリフォルニア大学サンディエゴ校の医学部で勤務しています、大野と申します。

大学に勤務していると言っても研究者ではなく、あくまでソフトウェア開発者という立場です。大学はある種の非営利団体なので、その中に他の団体と共同でいろんなプロジェクトが立ち上がり、そちらの組織にも名前が入っていたりするのですが、基本的にはサンディエゴをベースに大学の中でソフトウェアを開発しています。

この会はオーディエンスの方がいろんな分野から来られているので、テクニカルなことばかりに集中してもなかなか面白くない可能性があるので、今回は長めのイントロとして私がやっているようなことをお話ししながら、最終的に技術的な部分を紹介する、という形で進めたいと思います。

生物学と可視化

研究室のタイトル的なものは、以前は「ネットワークバイオロジー」を掲げていましたが、今はもっと広く「ゲノミクス」というカテゴリーで考えていただければいいと思います。

ゲノミクスという性質上、生物すべてに共通するものなので、扱う生物種は本当にいろいろです。もともとは技術的な制約から酵母などから始まって、今は人間の疾患や哺乳類の研究をしている研究者もたくさんいます。

2020年という特殊な年

2020年の主役はこれですよね——コロナウイルスの実際の遺伝配列（シーケンス） です。

そういうこともあって、今年は一般のメディアも含めて生物学に関係する用語が飛び交った年だったと思います。PCR（ポリメラーゼ連鎖反応） という言葉を聞かない人はいないでしょうし、それに使うプライマー、ゲノムを解析してウイルスの系統樹を作る技術、そしてワクチンの話題で mRNA という言葉が毎日登場する。

私たちは特定の生物種を研究しているというより、汎用的に使える手法——いわゆるバイオインフォマティクス——でいろんな生物種を研究しているので、COVID-19 に関する共同研究者の仕事を紹介しながら、可視化との関わりをお話しします。

生物学のデータはほぼすべて公開されている

生物学分野のデータは、特殊なものを除いてほぼすべて公開データとして誰でもアクセスできるようになっています。

リンクの先へ行くと、実際にリファレンスのゲノム——このコロナウイルスのゲノムデータにアクセスできます。ウイルスというのは非常に効率がいいと言ったら変ですが、情報量としては本当に3万文字くらいで表せるゲノム情報で、今の世界をぐちゃぐちゃにしているという感じです。

データとしては本当に単純で、FASTA という名前のフォーマットで、情報量もそれほど大きくありません。

ただ、元のファイルには ATGC という文字列が並んでいるだけで、**これを見て何か分かる人間は基本的にいません。**なのでコンピュータの力を借りて、今わかっている情報をその上に乗せたり、ゲノムブラウザというインタラクティブなツールを使ったりしながら、研究者は日々研究しているわけです。

タンパク質相互作用ネットワーク

ウイルスが人間に対して何か悪さをして、最終的に疾患として現れる——それがなぜ起こるかというと、ウイルスのタンパク質と、ホストである人間側のタンパク質が何らかの相互作用を行うからです。

そういうものを解析するとき、相互作用はグラフ＝ネットワークとして表せるので、シンプルなネットワーク図で全体のインタラクションを把握できるようにするわけです。

この論文では、網羅的に解析した結果をネットワーク図として表しています。

薬というのは「この病気が出てきたからすぐ作ろう」というのは無理だというのは、今年の状況を見てこられた方は皆わかると思います。開発に非常に時間がかかるのに対して、ウイルスは待ってくれない。

そこで研究者や医師が最初に考えるのは——すでに臨床試験が終わって他の病気に使われている薬があって、それが同じような作用機構で同じようなタンパク質をターゲットにするなら、この病気にも使えるんじゃないかということ。この ドラッグリパーパシングの研究でこういったネットワーク可視化が実際に使われています。

余談ですが、この論文は被引用数が970。せいぜい半年ほどでこんな引用数が出るのは普通ではないので、いかに今、世界中の研究者がこの部分に寄ってたかって研究しているかが端的に分かる数字だと思います。

生物学で使われる可視化の種類

ネットワークは生物学で使われる可視化のごく一部です。

アライメントビュー ——塩基配列やアミノ酸配列を比較するとき。昔は目でやっていた時代もあったようですが、基本は機械で並べて、どこが変異しているのかを目で見られるようにする
ゲノムブラウザ
タンパク質の構造ビューア ——タンパク質は3次元構造の状態によって働きが決まるので、その3次元の状態を見られるようにする
ネットワーク図 ——相互作用
系統樹

Nextstrain に行くと、系統樹と世界中への伝播をダッシュボード的に作り上げたソフトウェアがあります。研究ツールと報道ツールの中間くらいという印象を私は受けました。生物学で使うツールは、複数の異なった形のデータを統合してダッシュボード的にし、そこで探索的な可視化を行うということが割と頻繁に起こります。

データ型と可視化手法の対応

COVID-19 関連研究で使われる情報を、コンピュータの用語に置き換えると——

生物学のデータ	計算機的には
遺伝子配列	文字列
3次元構造	座標＋文字（アミノ酸）
薬剤との相互作用	グラフ構造
感染経路	グラフ構造
系統樹	ツリー

つまり——ウイルスの研究に限らず、計算機はある種、生物を研究するためのインフラ的な立場になっている。だから私のような立場の人間が存在するわけで、本業は生物学者のためのツールやインフラを整えることです。

余談 ― 犬の年齢

私の職場から出た論文の一つに面白いものがあって、ニューヨーク・タイムズでも記事になりました。

昔から「人間と犬の年齢を比べるときは7を掛ければいい」という説がありました。俗説なのかサイエンスのデータに基づいたものなのか私は知らないのですが、実際に調べてみるともう少し違うカーブを描くんじゃないか、というのを私の職場の大学院生が論文にして出したんです。犬という身近な動物を使った研究だったこともあって、日本語でもニュースになっているのを見つけました。

ゲノミクスは生物に共通する基盤を研究しているので、生物種としては本当にいろんなものを扱っています。とはいえ研究予算が集中するのは難易度の高い疾患なので、どうしてもがんなどを研究する場合が多いです。

私たちの仕事

遺伝子から、最終的に生物上に現れるフェノタイプ（表現型）を予測したり、その関連性を調べたり——そういったことを計算機を使って研究している職場です。

中でも私たちはネットワークやパスウェイ——化学物質と人間のタンパク質、あるいはタンパク質同士が集合したコンプレックス、そういったもの同士の反応経路や作用の仕組みを中心に研究しています。がんの研究、DNA のダメージを修復する機構、老化とは何か——そういうものを分子生物学的に研究しているのを、計算機側からサポートしています。

実際に何をやっているかというと——

解析の部分：研究者が書いたプロトタイプ的なコードやアルゴリズムを、一般の生物学者が使えるようなツールにまとめる
可視化の部分（私が主にいるチーム）：新しい可視化手法そのものを開発・研究するのではなく、可視化研究者が作ってある程度評価の定まった手法を組み合わせて、より複雑な探索的可視化ができるアプリケーションを作る。あるいは論文に合わせてカスタムのツールを作って最終的な図を作成する

バイオインフォマティクスという言葉は分かりにくいのですが、やっていることは意外と地味で、普通のソフトウェアエンジニアがやっているようなことです。

インフラ整備とお金

インフラ整備には必ずお金の問題が出てきます。**こういうソフトウェアは基本的にそれ自身がお金を生みません。**使う人が多くても、その人からお金を取るというよりは、どこかからお金をもらってきて開発するという形になります。

毎年いろんなグラント（助成金）に応募するのですが、面白いファンディングソースとして Chan Zuckerberg Initiative があります。Facebook のザッカーバーグさんと奥さんがやっている慈善団体で、そこが「Essential Open Source Software for Science」という枠を作って、科学研究の分野で広くインフラ的に使われているソフトウェアに対してお金を出しましょうという基金を運営しています。

私たちも応募して通ったのですが、サイトを見ると pandas、Bokeh、NumPy、Jupyter、Binder など、聞いたことがあるプロジェクトがいくつもあります。これだけ広く使われているソフトウェアでも、持続的に開発していくのは難しいという現状があるので、非常にありがたい基金です。日本も含めて、起業家の方なども含めてこういったサポートができるといいなと思ったりしました。

作っているもの

NDEx ——生物学方面で使うネットワークやパスウェイの共有サイトのようなものです。Pfizer や Roche といった製薬会社も資金を出してくれています。パブリックにできないデータについては、彼らが自前のサーバーにデプロイして機密性のあるデータをそちらで使う。それとは別に私たちがパブリックのサーバーも運営していて、キュレーターが、たとえば今年なら COVID-19 関連の信頼性のあるネットワークデータをコレクションとしてまとめる、といったことをしています。

Cytoscape ——汎用のネットワーク可視化ソフトです。比較的大規模なものから、人間が手で描くようなパスウェイ図まで可視化できます。もともとは私のボスが2003年ごろに開発し始めたもので、2020年現在も続いている。この「継続させる」というのが非常に難しいのがこの分野のソフトウェアの特徴ですが、なんとか生き残っています。

カスタムツールを作る

私たちに関して言うと探索的な可視化ツールを作るのですが、データの特殊性もあってニーズが複雑で、研究者が見たいものも研究内容によってだいぶ変わるので、カスタムのツールを作る必要性はずっとあります。

最近作っているのが HiView です。巨大なネットワークに対して階層的なクラスタリングを行い、その階層を circle packing で表現して、どんどん展開して中に入っていけるブラウザと、それに対応する各種データを表示するダッシュボードです。

ただ、技術的な要素を見ていくと特殊なことは何もやっていません。

階層構造の部分：D3 の circle packing をベースに、インタラクションを後から追加
ネットワーク（node-link diagram）：Cytoscape.js（これも私たちのチームが作っている JavaScript ライブラリ）
バーチャートなど：1から作る必要もないので react-vis（Uber が最初に作ったライブラリ）
UI：Material-UI（大元のデザインは Google、オープンソースの実装として React で使える）

使っている技術の要素は本当にシンプルです。つまり——基本的なパターンはだいたい有り物のツールでカバーできる。

**データの種類と量が決まれば、自ずと使える手法が決まり、最近は実装まで手に入る。**このあたりは昔に比べるとずいぶん楽になったと思います。

手法についても、**何を見せたいかがあって、データの種類と量が決まれば、「これは散布図」「これはヒストグラム」とかなり自動的に決まってくる。**チートシートのようなサイトもいくつかあるので、必要なものが実装も含めて手に入るかをまず調べるのが、最近は大事になってきています。

それでも自分でコードを書く必要があるケース

大きく3つだと思います。

大量のデータがある
比較的複雑なインタラクションが必要
可視化手法自体を作らなければならない

3つ目はどちらかというと可視化自体を研究している研究者の領域なので、私はあまり踏み込みません。今日は1と2について実例を交えてお話しします。

問題の複雑さ

一番簡単なのは単一種類のデータを可視化したいというケース。これは Excel でもライブラリでも比較的簡単に作れます。

データ型が増えれば、それに対応する違う種類のチャートを作らなければならない。逆にデータは単一でもものすごい量があると、既存の手法にただ読み込ませるだけで大丈夫か、というケースが出てくる。

そして大量の、いろんな種類のデータをそれぞれ相互につなげて、アクションに基づいて見え方が変わる——そうなるとかなり複雑になっていきます。

私が主に作業しているのはこのあたりで、構成要素自体は1から作らなくても、量的な問題や特殊なインタラクションに時間を割いています。

① 複雑なインタラクション ― Plotly Dash

**Tableau のようなコマーシャルツールでもある程度双方向性のあるダッシュボードは作れます。**もちろん限界があって、描きたいコンポーネントがなかったり、必要なインタラクションがなかったりする場合はどうしても自分で書かざるを得ない。

ただ、ほとんどの人——特に分析自体をやって最終的な可視化まで作っている人——にとって、JavaScript で1から書くのはハードルが高い。

いま、データ分析者にとって Python は非常に大きな存在です。「Python で1から書けてしまえば楽だろうな」と思っている人は多いと思います。

そこで Plotly Dash です。JavaScript を書かなくてもインタラクティブな Web アプリケーション／ダッシュボードが作れてしまうツールキットです。

Plotly（カナダの会社だと思います）のビジネスモデルはエンタープライズエディションの方で、可視化部分はオープンソースなので、Dash も基本機能は全部フリーで使えます。

実例を見るのが一番早いと思いますが、基本的な部品が全部揃っているので、それを組み合わせて割と複雑なダッシュボードを Python のみで構築できる。

今は「1か0か」ではなく、こういう中間的なツールキットもあるので、データ分析側にいる人はこのあたりも考慮するといいと思います。

ちょっとびっくりしたのですが、**英語の書籍も出ていないような気がするのに、日本語で書籍が出ていました。**興味がある方は見てもらうと実際どういうものか分かると思います。

また、Plotly から私たちのカナダのコラボレーター——Cytoscape.js を作っている同僚——にアプローチがあって、Cytoscape.js を Dash で使えるコンポーネント「Dash Cytoscape」 が用意されています。その解説もこの日本語書籍にはかなりページを割いて書いてあります。

もちろん限界はあって、描画部分までいじりたくなると、最終的にはモダンフロントエンドと呼ばれるジャングルに入るしかない。ただそこまで行く前に、今公開されているコンポーネントで目的のアプリケーションが作れるかどうかをちゃんと試した方がいい。

私の同僚もこれで作り始めたのはいいけれど、データ量的に対応できなくて最終的に私に仕事が回ってきたこともあるので、そのあたりの見積もりも大事です。

② 大量のデータ ― deck.gl

可視化のアプリケーションを書く＝ほぼ Web ブラウザで見るという流れになってきています。

私はネットワーク描画をかなり長く扱っているのですが、100万や200万といったノード・エッジをシンプルな node-link diagram で表す——そんなものをブラウザで実行するのは、昔はあまり考えられませんでした。今は技術的に可能になってきている。

ユースケース

エッジ数の多い密なネットワークを、シンプルに node-link で表示したい。でも数がめちゃくちゃ多い。そして全体の傾向を見たい——クラスタリングを施した後、クラスター同士が密に固まった状態をざっと表示して、同時に Google マップのようにズームイン・ズームアウトもできるといいよねという、無茶なお願いをしてくる人がいるわけです。

有り物で自由にそういうことができるものはないので、作るとしたらどのくらいの手間かを考え始めました。

私たちは最終的なアプリケーションを作る人間で、解きたい課題があってそれに技術を持ってくる形なので、CG の専門家もいないし GPU に詳しい人間もいない。できるだけハイレベルな API を持つライブラリがあればな、と探していたところ——都合のいいものがありました。

deck.gl

もともと Uber が作っていたライブラリです。

彼らのサイトを見ると**地理空間データの例が非常に多い。**日本だと食べ物の配達のイメージが強いと思いますが、彼らがメインで最初に始めたのは配車サービスなので、そちらのデータを可視化したい欲求があったのだと思います。

**ただ実際は汎用的なツールです。**もともと Uber で作られましたが、今後は比較的オープンな体制で作っていくことも決定しているようなので、ロックインもあまり心配しなくて大丈夫だと思います。

deck.gl を使った例として kepler.gl があります。地理空間データを手間少なく地図に重ねて表示できるツールで、下で走っているのが deck.gl です。

**よく間違われるのですが、例が地理空間可視化ばかりなだけで、実際は汎用のツールキットなのでいろんなことができます。**Uber は自動運転の研究もやっていたので、その結果を可視化するようなものも全部これで作っていると、開発者のワークショップで聞きました。

なぜ自分たちで作ろうと思ったか

100万を超えるエッジやノードを持ったデータの概要（オーバービュー）を見たいというのが主なモチベーションです。

クラスター同士がそれぞれ近い場所に集まって、カラーコーディングされて、必要に応じてさらにデータレイヤーを上に乗せられる——そういう巨大な白地図のようなものが作れればいいなというので始まりました。

deck.gl の考え方 ― レイヤーの集合

deck.gl はレイヤーの集合で作ります。基本的な考えは「可視化したいものを、いくつかのレイヤーに分割して表現できないか」。散布図用のレイヤー、直線を引くだけのシンプルなレイヤー——そういうプリセットを重ね合わせて作ります。

グラフを描画したい場合は、ノードを表示し、ラベルを付け、ノード同士を線で繋ぎ、必要に応じて背景を描く。つまりノードレイヤーとエッジレイヤーを別々に既存のもので作ればいい。

技術スタックは下から——

WebGL（ブラウザ技術）
luma.gl（Uber が作った、WebGL に対するもう少し高レベルな API のラッパー）
deck.gl

レイヤー自体の描き方は割と簡単に切り替えられるので、2次元から3次元に切り替えて、複数のレイヤーが重なった3次元空間の表現——2.5次元と呼んだりします——もやろうと思えばできます。

実例

40万ノードくらいのものです。あらかじめ Python でクラスタリングを施し、レイアウトしたものを描画しています。さすがに分析やレイアウトをオンザフライでやるのは現実的ではないので、そこは別でやっています。

ただズームやパンといった基本的な部分については、このくらい何も考えずにやっても普通に描けるパフォーマンスが、今の機械・ライブラリ・ブラウザのおかげで出るようになっている。

50万ノードくらい入れると、ここまで行くともう単なるメッシュにしか見えないのですが、何も考えずとも比較的こういうものを deck.gl で作れるということが確認できました。

D3.js とどう違うのか

ちゃんとライブラリに合った役割を割り当てるのが大事です。

D3.js：カラーパレットの生成や circle packing の計算といった、数学的なライブラリとして使うのは今でも非常に便利。それが今後のメインの使い方として正しくなってくると思います
deck.gl：ひたすら力技で大量のデータを描くユースケースに異常に向いている

ただし巨大なデータを一気に描画する場合、その場で解析やレイアウトを行うのは現実的ではないので、その部分は大きな計算機であらかじめ計算しておいて、どこかに蓄積する。こういう役割分担が今後は大事になってくると思います。

まとめ

D3.js でチャートを作る作業自体は面白いんですけれども、最近はいろんなものがすでにあるので、既存のものを利用する。「自前で作らないと気が済まない」という欲求と戦うのが、今後は結構大事だと思います。

今の段階では単純にメモリに流し込んだものを無理やり描いているだけなので、実用的なアプリケーションにするには、1000万といったオブジェクトがあってもダイナミックにロードすれば、ブラウザでも十分扱えるはずで、そういう仕組みができないかを今やっている最中です。

生物学的な話からスタートしましたが、まとめとしては——

比較的複雑なアプリケーションを作る場合でも、必要なツールキットは非常によく整備されている。まずそれを使えないかよく考える
足りない場合は、中間的な Dash を使う
それでもできない場合は、deck.gl で自前のレンダリングを書く

作る側としてはどんどん便利な世界になってきているので、ぜひこのあたりも試してみてください。以上です。

Cameron Beccario／地球を作り上げる：世界天気のアニメーション地図

Tue, 26 Dec 2017 00:00:00 +0000

Data Visualization meetup 2017（2017年12月26日・Indeed Tokyo 目黒オフィス開催）における、Cameron Beccario さんの講演です。世界の気象データをリアルタイムに可視化する earth の作者が、その動機・構築・反響・そこから得た教訓を語ります。

本セッションは英語で行われました。以下は日本語に翻訳・整文したものです。なお**末尾の質疑応答は、質問者が日本語で話しているにもかかわらず自動字幕が英語として認識してしまっているため、質問文を復元できませんでした。**回答から推測できる範囲で構成しています。

こんにちは。Cameron Beccario と申します。お招きいただきありがとうございます。

最初にお断りしておくと、今日は Indeed の社員としてではなく、Indeed に入る前に個人で作ったプロジェクトについてお話しします。それから、英語で失礼します。Twitter は @cambecc です。

earth というのが私のプロジェクトの名前です。Web の技術を学ぶために作った風の地図（wind map） です。今夜は4つのトピックについてお話しします——動機・構築・反響・教訓です。

自己紹介

私はもともとアメリカ中西部、アイオワ州シーダーラピッズの出身です。何もありません。トウモロコシと豚だけです。

アイオワ州立大学でコンピュータ工学の学位を取り、その後シアトルに移ってマイクロソフトで5年間働きました。少し飽きてきたので、日本に来て日本語を勉強することにしました——**いまこうして英語で話しているわけですが。**その後いくつかの会社を経て、最終的に Indeed でソフトウェアエンジニアとして働いています。

動機 ― 無職の夏

2013年の夏、私は無職でした。

**切手を集めていました。**エンジニアが切手を集めている——あまり良い兆候ではありません。

何か新しいスキルを学ぶためのプロジェクトが必要でした。HTML5 と JavaScript をやりたいと思っていた。**JavaScript は知りませんでした。**そしてデータ可視化。でも何を作るか。

インスピレーション

そこで素敵なインスピレーションを見つけました。2012年に見つけた hint.fm/wind というサイトです。Google の（当時はまだ別の場所にいた）二人の研究者が作ったものです。

これを見たとき、私は思いました。「これは本当にクールだ。ブラウザでこんなことができるのか。すごい。」しかも基本的にリアルタイムです。最終更新の時刻が出ている。

「これを参考にして、自分でも何か作れるんじゃないか」と思いました。それに——**私は天気が好きなんです。**大きな嵐、澄み切った空、雪。恐ろしくて、同時に美しい。

「よし、風の地図を作ろう。良いプロジェクトになりそうだ」と。

道具とデータ

何を使うか調べ始めて、D3 を見つけました。今日も先ほど話に出ていましたね。D3 で綺麗な地図を作る方法を説明した良いチュートリアルがありました。長いチュートリアルでしたが。地図は問題なし。

ではデータはどこから取るのか。そもそもそんなデータは存在するのか。どうやって見つけるのか。

調べると、アメリカ国立気象局（US National Weather Service） が GFS という気象モデルを持っていることが分かりました。スーパーコンピュータ上で3時間ごとに走るシミュレーションで、**そのデータが無料で公開されている。**FTP サイトがあって、ファイルをすぐにダウンロードできる。非常に奇妙なフォーマットですが、とにかく無料でダウンロードできる。

構築 ― 4つの段階

どこから始めるか。

最初の勝利は、ブラウザに世界地図を表示できたことでした。D3 を使って。「これはすごい。地図さえ出せるなら、このプロジェクトはやれる」と思いました。

次のステップは、それを球体にすること。これも D3 がサポートしています。とても良くできている。

そして気象データを使って、緯度経度グリッドの個々の点に色を付ける。色を塗り始めると、それらしく見えてきます。さらにデータ点と点の間をバイリニア補間で埋めると、滑らかな球体になります。

しかしこれは色だけです。私が欲しかったのは動くアニメーションでした。そしてそれが難しかった。本当に難しかった。

どうやればいいのか理解するために、たくさんのことを試しました。そして最終的に分かった。デモをお見せします。

デモ

これがサイトです。3時間ごとに更新される、ほぼライブのデータです。地球を回転させたり、ズームインしたりできます。いま通り過ぎた気象システムが見えますね。

メニューから他の種類のデータも見られます。

ジェット気流 ——南極上空のジェット気流が見えます。なかなか面白い
波（ocean waves） ——先ほどの嵐のシステムが大きな波を作っているのが分かります
海流（ocean currents） ——これも綺麗ですね

時間を前後に動かせるので、過去に遡ってどう変化したかも見られます。D3 なので投影法も変えられます。こんな変わったものにもできる。ちょっと楽しい。

そして PM2.5。……ええ、**中国、ありがとう。**ひどいですね。

ただ PM2.5 は汚染物質だけではありません。砂や埃、海からの塩分も PM2.5 に分類されます。ですから汚染源がどこなのかを理解することが重要です。

4つのレイヤー

地球は4つのレイヤーでできています。

SVG の地球
HTML5 canvas ——アニメーションが起きる場所
WebGL ——色。最初は canvas でしたが、性能のために WebGL に切り替えました
もう一枚の SVG ——縁を綺麗に整えるため

アニメーションの仕組み

気象データをダウンロードすると、ベクトル場が得られます。この場の上に粒子を描きたい。

やり方はこうです。

一度に短いセグメントを1本だけ描く
毎フレーム、そのベクトルが指す方向を見て、その方向に描く
前のフレームで描いたセグメントをフェードさせる
速度を上げる
粒子を増やす。もっと増やす。もっと増やす

それであの効果になります。

球体の歪みという難題

先ほど「球体の歪みが難題だった」と言いました。なぜ難しいか。

気象データは風を「北向き」「東向き」で示します。しかし画面上の「北」は、場所によって上だったり、右だったり、下だったりする。「東」も同じです。

ですからすべての点について、ベクトルをどう変換するかという歪みを求めなければならない。

東だけを見てみましょう。同じことをします——場を描いて、粒子を1ステップずつ動かして、速度を上げる。……そう、これがこのプロジェクトで一番大変な部分でした。

GPU の arcsine が壊れている

色は最初 canvas で実装しましたが、WebGL に切り替えました。

**最初の実装はこうでした。地球を回転させると、色が消えてしまう。**良くないですね。

そこでフラグメントシェーダを書きます。フラグメントシェーダとは、要するにピクセルの色を作る小さなプログラムで、GPU 上で走ります。GLSL で書きます。すべてのブラウザがサポートしています。

これが最も単純なフラグメントシェーダです。「このピクセルの RGB はこれ」を返すだけ。

風の地図では、すべてのピクセルについて、それがどの緯度経度に当たるかを求め、その緯度経度の風速を調べ、色にマッピングする。

そして、この「XY から緯度経度へ」の部分が難しいのです。

正射図法（orthographic projection） ——地球を眺めるような投影法の洒落た名前です——を使っていて、これには X と Y から緯度経度を計算する公式があります。それを GLSL で、フラグメントシェーダで書ける。素晴らしい。動く。しかも猛烈に速い。

バグ報告

しかし**バグがありました。**あるユーザーがこの画像をメールで送ってきました。

どこがおかしいか分かりますか？

すべてが南にずれているのです。しかも奇妙なことに、**画面上で下にずれているのではなく、「南に」ずれている。**経度は問題なさそうで、ちゃんと合っている。南にずれているのに、**イタリアは大丈夫そう、アフリカも大丈夫そう。**本当に奇妙でした。

そこでフラグメントシェーダを見始めました。この緯度の値に何か問題がある。

項を見ていきます。**問題はここではありえない。経度は正しいし、経度も同じ項を使っている。**同じ、同じ、基本的に全部同じ項です。では、なぜ緯度だけがおかしいのか。

**緯度は arcsine を使っている。**これはユーザーのマシンの GPU のハードウェアに組み込まれた関数です。

「arcsine が間違っているなんてありえるのか」と思いました。そこで小さなプログラムを作って、そのユーザーに走らせてもらいました。

これが、そのユーザーのコンピュータでの arcsine の出力です。CPU で動く JavaScript と、GPU で動く WebGL。一致しません。arcsine が間違っている。

対処

どうするか。**arcsine を近似すればいい。**簡単です。誰かがすでに書いてくれています。掛け算と足し算だけで arcsine を近似する式があります。

それを追加して、自前の arcsine を作りました。

そのユーザーは「ありがとう、これでサイトが使えるようになった。私は地球温暖化を信じていないけどね」と。

……地球温暖化を信じていない人のために、あれだけの作業をしたとは。

教訓

**GPU はゲームのために設計されていて、計算のために設計されているわけではありません。**高価な GPU なら別ですが。そのユーザーの arcsine のハードウェア実装には、ゲームの世界では問題ないが計算では問題になる最適化が入っていたのです。7年落ちの GPU でした。

ただ、**サイトに小さなテストを仕込んで、arcsine が壊れているユーザーがどれくらいいるか調べてみました。約3％です。**訪問者の3％。理由は分かりません。とても奇妙です。

アーキテクチャ ― 月50ドル

サイトの構成についても少しお話しします。

すべて静的です。Amazon S3 に置いて、その前に CloudFlare。CloudFlare は無料の CDN、S3 は安い。サイトの運用コストは月50ドルほどです。

気象データは国立気象局から自前のサーバーが取ってきて、JSON ファイルに変換して S3 にアップロードするだけ。**S3 は狂ったようにスケールするし、維持すべきサーバーが無い。**これが本当に素晴らしい。

反響 ― 4,800万人

スケールする。ではローンチだ。誰か見に来てくれるだろうか。

Twitter と Facebook で、友人に向けて公開しました。これが Google Analytics です。

ローンチ当日：64訪問。そして何も起きない。

「あれだけ作業して、これか」と思いました。

翌日：3万訪問。

そして次の週、その次の週と、バイラルに広がっていきました。

2013年から2017年まで、累計4,800万ユーザー、1億3,800万セッション。

グラフのピークは台風、嵐、熱波です。地球上で何も起きていないときは、トラフィックはごくわずか。ほとんどゼロ。でも何かが起きると、人が来る。

最も忙しかったのは、イギリスを直撃したハリケーンのとき。1日で200万セッションでした。

NASA、アル・ゴア、Forbes などが Twitter で言及してくれました。**テレビでもかなり使われています。**BBC、それから NHK も時々使っています。The Weather Channel も。

学術誌でもアートワークとして使われました。Nature Climate Change など。

**誰かがビールを作りました。**私には教えてくれませんでしたが。そのビールが本当に欲しかった。

そして、とても興味深いアートワークを作った人もいます。これは布です。カナダのアーティストが作った刺繍作品で、彼女は20点を制作して、あの投影法をもとにした個展を開きました。

教訓

① ユーザビリティ ― 誰もメニューの場所を知らない

誰もメニューがどこにあるか分かりません。

自分では気が利いていると思ったのです。綺麗で良いデザインだと。でも**一度いじったことがある人以外、誰もメニューに気づかない。**これは直さないといけません。

② この可視化は、厳密には正しくない

この可視化は間違っています。「間違い」は言い過ぎかもしれません。**誤解を招く、正確でない。**理由を説明します。

これはある時点のスナップショットをアニメーションさせたものです。時計は動いていません。

では、あの動きは何なのか。あれは時間の中の動きではありません。ベクトル場の中の動きです。

粒子を1つ取って軌跡を描くと、流線（streamline） が得られます。流線とは、ある瞬間における線です。

**しかし天気はそう動きません。ベクトル場は時間とともに変化する。**この嵐は右に移動していきます。時計が動いている状態で同じ粒子を描くと、まったく違う軌跡になります。こちらの方が現実に近い。

しかし私の風の地図で見えているのは、最初の方——流線です。

ですから、**これは誤解を招くし、厳密には正しくない。**ただ、人々はそれをあまり気にしません。

でも、**私たちがデータ可視化を作るときには、正直でなければなりません。**ユーザーに対して正直であり、その可視化が何を意味しているのかを正確に説明しなければならない。

私はまだ、これをサイトの訪問者にうまく説明する方法を見つけられていません。

なお、このサイトのローンチ以降、**粒子アニメーションはあちこちで使われるようになりました。**気象局、CNN、The Weather Channel、NHK。よく似たものが出てきています。

③ データが無料であることの意味

地理データは無料。フレームワークは無料。帯域も（実質）無料。Twitter で受けた助けもすべて無料。そして気象データが無料。

無料のデータは、私のような人間——職がなくて、ただ何かを作りたいだけの人間——に、途方もない可能性を開きます。

**これは何十億ドルもの代物です。ロケット、衛星、スーパーコンピュータ。それを私が無料で使える。私たち全員が無料で使える。**これは非常に大きな教訓です。

ただし——**ヨーロッパ気象局、そして日本の気象庁のデータは無料ではありません。**月に数万円かかります。日本の気象庁のデータをぜひ使いたいのですが、手に入れられません。

以上です。ありがとうございました。

質疑応答

以下は、日本語での質問に対する Cameron さんの回答です。**自動字幕が日本語の質問を英語として誤認識しているため、質問文そのものは復元できませんでした。**回答の内容から質問を推測して見出しを付けています。

——このプロジェクトは一人で作ったのですか。制作期間はどのくらいですか。

はい、一人です。7月に始めて、12月に公開しました。

最初に東京だけのプロトタイプを作りました。これがそのプロトタイプですが、ほとんど何もできません。これを見た人たちが「埼玉に住んでいるんだけど」「沖縄に住んでいるんだけど、自分の場所の天気はどう見るの」と言ってきた。それで地球全体を作ることにしたのです。5か月かかりました。

職がないと、時間はいくらでも使えます。

——サイトを作っていて発見した、面白い場所はありますか。

たくさんあります。

南極周辺の風です。気づきにくいのですが、**この海には風を遮る陸地がまったくない。**だから風はひたすら加速していく。「吠える40度（roaring 40s）」と呼ばれていて、常に非常に荒れています。風を減速させる陸地が無いからです。

そして——**南極を見せてくれる天気サイトが、他にどれだけありますか。**たいていは決まった窓しか見せてくれない。でもこれはおもちゃなので、探索して発見できるのです。

もう一つ面白いのが極渦（polar vortex） です。これは成層圏で、いまは北半球の冬なので北極上空に非常に強い渦があります。夏になるとこれが南極側に移ります。探索して面白い場所は、本当にたくさんあります。

——データフォーマットについて教えてください。

差分符号化をするフォーマットです。**PNG に少し似ていて、3点から平面を予測して、その差分（デルタ）を符号化する。**これが非常によくできています。

アーキテクチャ全体にもたくさんの工夫があります。S3 と CloudFlare でサーバー無し、すべて静的。ロジックはすべてブラウザにある。つまり私のではなく訪問者の CPU を使っている。

最後にもう一つ。S3 が非常に安いので、私はデータを消していません。2013年から3時間ごとのデータがすべて残っていて、いま数年分あります。

ありがとうございました。

D3.js on Data Visualization Japan

LT：田島 将太／はじめての Data Viz が Twitter で100万回見られた話 ― Observable のススメ

自己紹介

完成した記事

企画の発端

始める前に言語化したこと

なぜハフポストにデータ可視化が必要なのか

インパクトの言語化

読者に提供する価値

グラフを作る上での指針

ツール ― Observable

読者の反応

学び

大野 圭一朗／今あえてコードから可視化を作る場合のツール

生物学と可視化

2020年という特殊な年

生物学のデータはほぼすべて公開されている

タンパク質相互作用ネットワーク

生物学で使われる可視化の種類

データ型と可視化手法の対応

余談 ― 犬の年齢

私たちの仕事

インフラ整備とお金

作っているもの

カスタムツールを作る

それでも自分でコードを書く必要があるケース

問題の複雑さ

① 複雑なインタラクション ― Plotly Dash

② 大量のデータ ― deck.gl

ユースケース

deck.gl

なぜ自分たちで作ろうと思ったか

deck.gl の考え方 ― レイヤーの集合

実例

D3.js とどう違うのか

まとめ

Cameron Beccario／地球を作り上げる：世界天気のアニメーション地図

自己紹介

動機 ― 無職の夏

インスピレーション

道具とデータ

構築 ― 4つの段階

デモ

4つのレイヤー

アニメーションの仕組み

球体の歪みという難題

GPU の arcsine が壊れている

バグ報告

対処

教訓

アーキテクチャ ― 月50ドル

反響 ― 4,800万人

教訓

① ユーザビリティ ― 誰もメニューの場所を知らない

② この可視化は、厳密には正しくない

③ データが無料であることの意味

質疑応答

LT：田島将太／はじめての Data Viz が Twitter で100万回見られた話 ― Observable のススメ

大野圭一朗／今あえてコードから可視化を作る場合のツール