オープンソース on Data Visualization Japan

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

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 で自前のレンダリングを書く

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

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

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）も音頭を取ってくれたのは学生だったりしました。

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

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

まとめ

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

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

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