尾上洋介／ビジュアライゼーションとモダンWeb開発

Wed, 29 Dec 2021 00:00:00 +0000

Data Visualization Japan Meetup 2021（2021年12月29・30日開催）における、尾上洋介さん（日本大学文理学部情報科学科准教授）の講演です。行政事業データベース JUDGIT! の開発経験をもとに、可視化アプリケーションを支える Web 技術の現在地を紹介します。

「ビジュアライゼーションとモダンWeb開発」ということで、普段やっていることを振り返って喋ってみようと思います。

自己紹介

日本大学文理学部情報科学科で准教授として教育・研究をしています。実データを触る関係で企業からも声をかけていただくことが多く、現在は株式会社帝国データバンクの客員研究員として、可視化のデザインやシステムのデザインを行っています。

可視化と Web が好きです。私が可視化を始めたのは2013年ごろ、D3.js が流行りだしたタイミングでした。もともとオペレーションズ・リサーチ（最適化） の研究をやっていて、いろいろあってドクターから可視化の分野に踏み込むことになったのですが、教授の下にいる若い先生に「これからは可視化も Web だよ」と唆されて、可視化と Web はその時期からセットで取り組んできました。

アカデミックな研究とエンジニアリングの両立を目指していて——新しいアルゴリズムや視覚的表現を作る基礎研究、可視化技術を各分野に適用する応用研究、可視化というキーワードで分野横断的な問題解決に取り組む研究、といったことをしています。

私は、**可視化とは「人とデータが向き合う場のデザイン」**だと考えています。アプリを作るのか、デバイスを用意するのか——どういう環境を整えたら、データに向き合っている人がそれを行動に結びつけられるのかを考えて取り組んでいます。

**デザイン方面は全然明るくなく、完全にエンジニアの方面から可視化に取り組んでいます。**ソフトウェア開発、データベース、システム設計を勉強したり、学生時代に Web 開発のアルバイトをして実務的なシステムの作り方を学んできました。

NHKスペシャル「検証コロナ予算 77兆円」

昨日放送された番組に協力させていただきました。データを分析して提供したり、一緒に議論したり、専門家として意見を出すということをやりました。

番組は NHK プラスで見逃し配信されています。また番組と併設してコロナ予算をいろんな角度から見る Web サイトも公開されていて、こちらは矢崎さんがかなり気合いを入れて関わっているのでぜひご覧ください。

JUDGIT! ― 行政事業のデータベース化

なぜコロナ予算の分析に携わることになったかというと、2018年末ごろから行政事業をデータベース化して可視化することに取り組んでいたからです。

現在、中央省庁は小さい委員会なども含めると21いくつかありますが、そこで行われる事業は年間約5000件あります。

**省庁の縦割りで、別の組織が何をやっているのか見えない。**予算的な観点で全体を管轄する財務省ですら、担当外はあまり詳しくなかったりする。行政事業の全体像の把握は非常に困難でした。もはや年間約5000件の事業の全体像を把握できている人間はいなかったのではないかと思います。

行政事業レビューシート

情報自体は「行政事業レビューシート」という、各事業の自己点検のための書類として毎年出されていました。Excel で書かれていて、担当の人が埋めていくという形です。

これをコンピュータで扱いやすいように、記述が曖昧な部分を整理してデータベース化し、閲覧できる Web サイト JUDGIT! を公開しました。

レビューシートは実に多種多様な情報を含んでいます。

数値情報：予算額、どれだけのお金がついてどれだけ使ったか
定量評価：どういうアウトカム・アウトプットを設定してどれだけ実現できたか
定性的なテキスト：事業の概要、有識者からのコメント
関連情報：他の事業との関連、どういう会社や民間団体に仕事を依頼していくら出しているか

データベース化したことで、もともと一つの事業の自己点検に使われていたものを、全事業横断で調べられるようになりました。

予算宇宙 ― 事業の関連ネットワーク

番組で「予算宇宙」という形で取り上げていただいたもののベースになっているのが、このネットワーク図です。

事業の文章をニューラルネットワークで処理して文章同士の近さを計算し、近いものをつなぐとネットワークが出てきます。

そうすると——経済産業省、厚生労働省といったそれぞれの省庁が事業を展開しているわけですが、文章の書きぶりから、結構似たことを違う省庁でやっているものがあったりします。

それはある意味「重複した無駄」かもしれないし、あるいはそれらを連携することでより効果的な事業を展開できるのではないかという示唆にもつながります。

左の方に大きな島があって、このあたりは経産省・農水省・国交省などの事業がつながっています。いわゆる社会課題系のものは多面的で、いろんな見方から問題解決に取り組まないといけないので、他省庁でも同じような課題への対策が行われている。それを見て「もっとどうやったらよくできるのか」を考える材料にできます。

個人的に面白かったのはICT 関係の島が孤立してあったこと。**ICT は本来、社会課題解決の根幹に来なければならないものだと思うのですが、大きな島から離れて出てきてしまっているのは、正直なところ「日本らしいな」と。**ある意味、日本の ICT が抱える課題でもあるのかなと感じました。

きっかけはプロトタイプだった

最初からこういうものを作ろうと思っていたわけではありません。

共同運営している団体から「東京オリンピック予算の検証がしたい」と持ちかけられたのが2018年ごろでした。「レビューシートという Excel のシートがあるんだけど、これから何とかできないか」と。

行政の事業データや政策には明るくなかったので、**まずは自分がデータの理解を深めるためのビューアを作り始めた。**いくつか検索や簡単な可視化ができるようにしたら、それがプロジェクトメンバーに思いのほか受けが良く、「東京オリンピック予算の検証は抜きにしても、これ自体を世に出そう」ということになって本格的に仕上げて公開しました。

これをやって感じたのが、プロトタイピングをして、ドメインの専門家と相互理解をして、それを世に出すことの重要性です。

**私が可視化の専門家として、行政事業というドメインの知識を獲得する。同時に、データを使って何かをしたいドメインの専門家が、可視化やデータ分析の技術に触れる。**プロトタイプを作って開発していくのは非常に良い体験でした。

こだわったこと

軽快に、簡単に——Web サイト自体の質を高めようと工夫しました。

最近は国も力を入れて行政系からもいいウェブサイトが出るようになっていますが、古いイメージだと行政系のサイトは重くて硬い雰囲気がある。それを払拭して行政事業を身近にしたいという気持ちがありました。

もう一点、データが Excel や PDF で公開されていたため、普通の人が調べ物をした時にそういう情報に行き当たりにくいという課題がありました。まず行政事業という情報自体を、検索エンジンのクローラーがしっかり拾ってくれるようにしたい。

検索エンジンフレンドリーにコンテンツを作ることで、身近なところから行政情報につながることを意識しました。

Google Analytics のアクセス状況を見ると、4分の3がオーガニックサーチ——ほとんど検索流入です。「JUDGIT! というサイトを知っていたわけではないけれど、どこからともなくたどり着く」方がほとんどです。

ユーザーを見てみると、**もともと行政に強い関心がある人というより、平日昼間のアクセスが多い。**仕事で調べ物をしていて、たまたま行政の情報にたどり着く、という方が多いことが分かりました。

公開してよかったこと

**「こういうものがあるんだ」と、行政の情報に気軽に触れられるようになった。**その結果として、今回のコロナ予算の NHK スペシャルのように「もっとこういうことできませんか」という問い合わせをいただくようになりました。

**元の Excel ファイルの束だと、そこから何か分析をしようという気は起こらなかったと思う。**それがデータベース化されていることで、もっと次のアイデアが生まれてくる。実際にユーザーにデータに触れてもらうことで、さらに次の良いアイデアに進むことができる——これが作って公開してよかったことです。

可視化とは何か

改めて考えてみます。

「可視化とは」と言った時、普通のビジネスパーソンが思い浮かべるのは「棒グラフとか円グラフとか、いろんな表現があるよね」ということだったり、「Tableau で可視化できるよ」「matplotlib で可視化できるよ」というツールの話だったりします。可視化を専門としないデータサイエンティストもよく言います。

でも、これらを使いこなすことが可視化なのかというと、多分そうではない。

視覚変数とデータの対応づけ

表現可能な視覚変数は一通りあります。位置、大きさ、色、模様、形——特にコンピュータの上で使える視覚変数は、そんなに大した量がない。

コンピュータグラフィックスは結果的に複雑な図形を描けますが、基本は多角形を描く、線分を引く、点を打つ、それくらい。

逆に言うと、可視化はそういった基本的な要素をデータと結びつけることで成り立っています。

折れ線グラフで線の高さが何を表しているのか——「人口」というデータの空間から、「座標」という視覚変数の空間へのマッピング。これが可視化を成り立たせることの根幹にあるわけです。

データを視覚的に表現する限界

実際のデータは行数も列数も無数にあり、大規模化・複雑化しています。

行数（レコード数）の限界は非常に分かりやすい。8Kディスプレイ——実際に使われている最大の解像度でも、約3200万ピクセルです。

仮に一要素を1ピクセルで表せるとしても（そんな可視化をしたら怒られるとは思いますが）、そのピクセル数分の要素しか表現できない。

**3200万要素は、ビッグデータの時代からすると非常に些細な量です。**何億レコードとなると桁がいくつも足りない。せいぜい一要素100ピクセルは使いたいと思うと、表現できる情報の桁はさらに減ります。

列（データのフィールド） で考えても、視覚的表現に割り当てられる変数はごく少数です。一つの円に対して割り当てられるのは、座標、半径、色——たかだかそれくらい。でも何十列とかになってくると、当然すべてを見渡せなくなります。

だから「選ぶ」必要がある

複雑で大規模なデータには——

可視化する対象を行なり列なりで選ぶ
統計的に集計して統計情報を出す
列方向でまとめる次元削減
行をまばらに取り出すサンプリング
データ全体の傾向を失わないように粗く表す粗視化

といったアプローチが必要になります。

それでもなお「見せるものを選ばないといけない」のが課題です。見せられないものを補いたかったら、もうインタラクションくらいしかない。

検索・絞り込みのインターフェースをつける
メインのビューだけでは捉えられない情報をサブのリンクトビューで表す
点をクリックすると詳細が見えるドリルダウン

ただ、そういうインタラクションを実装していくと開発コストが高くなり、開発自体が複雑化していく。それとどう向き合うのかを考えなければなりません。

なぜ Web で作るのか

可視化システムをユーザーにどう提供するか。デスクトップアプリと Web アプリの比較です。

Tableau のようにパッケージをダウンロードしてインストールするものに比べて、Web アプリはインストール不要で、ブラウザさえ動けば利用可能。

**ただし性能面では Web アプリはデスクトップアプリにかないません。**実装言語の性能上の問題も、ハードウェア機能の利用が限られる制約もある。パフォーマンスとデリバリーのしやすさにトレードオフがあるわけです。

Web の利点

第一に、ユーザーに届けることが簡単になる。

私は他の大学や研究所と共同研究することが多いのですが、忙しい研究者に「こういうのを作ったから遊んでみてください」と言う時に、「このソフトをインストールしてこの手順でセットアップしてください」と言うと、なかなかやってくれない。

**Web で提供していれば「このページにアクセスしてください」で済む。**向こうもハードルが低くてすぐ利用してもらえる。すぐ利用してもらえるとフィードバックがもらえて、次の機能改善につながる。

**もう一つは、今のアプリはリッチだということ。**日常的に触れるアプリケーションはそこそこリッチで、そういうリッチな UI を個人や数人のチームで片手間に開発するのは大変。Web の技術に乗っかることで、ユーザーにも馴染みのある UI を、そんなにコストをかけずに提供できます。

補足 ― オフラインで動く Web アプリ

スライドに入れられなかったので補足すると、実はインターネット接続がなくても使用できる Web サイトがあります。

さすがに最初の1回は訪れておく必要がありますが、Service Worker という技術を使えばオフラインで動く Web アプリケーションを作ることができます。

私も一時期そういうものを作っていました。共同研究先がインターネットもないような場所にフィールドワークに行くので、「可視化アプリをネットに繋がらなくても使えるようにならないか」というニーズがあったんです。興味のある方はぜひ調べてみてください。

トレンド① 宣言的UI

2010年前後から HTML5 が言われ出し、HTML を単純にコンテンツを表示させる土台から、アプリケーションのプラットフォームとして成熟させていこうという動きがありました。2010年代はなかなかカオスでしたが、その中で発展してきたのが Web フロントエンドのフレームワークです。

**Web の表現力が高まった一方で、それは開発コストを高めることでもある。**従来 PHP や Ruby on Rails でバックエンドでやってきた処理を、リッチな Web 体験のために前（ブラウザ側）に持っていく動きがあったので、フロントエンドの開発コストが大きくなりました。

10年ほど前は jQuery が流行っていて「プラグインを入れると簡単におしゃれな機能を加えられます」という感じでしたが、それでは到底太刀打ちできない規模のアプリケーションがブラウザ上で動かされるようになってきた。

そこで React、Vue、Angular、Svelte といったフレームワークが使われるようになります。

今回紹介するのは React ですが、そこが取り入れているトレンドが「宣言的UI」です。

UI = f(state) と表されます。UI があってユーザーが操作すると、アプリケーション内部が持っている「状態（state）」が変化し、その結果 UI が更新されてユーザーが見る——UI 構築と状態管理を分離してアプリケーションを構築していく流れです。

React は Facebook 社が開発するライブラリで、JavaScript の拡張構文 JSX を利用します。JavaScript の関数の中にタグが出てくるので、慣れないうちはちょっと気持ち悪い気がするかもしれません。

Facebook には意外と関数型言語や凝ったプログラミング言語が好きな人が昔からいて、関数型言語を利用した開発効率の向上に研究的に取り組んできた流れがあります。

大雑把に言うと——データがあって、それを UI のどこに埋め込むかを宣言的に書くことで、データと UI の関係を分かりやすくする、というのが一つのアプローチです。

React と可視化

可視化は結局、元のデータと、それに対するユーザーの興味関心が操作に反映されて出てくるものです。React はそのまま SVG のタグを書くこともできます。

上の方にデータがあって、それを SVG のタグの中にどうやって埋め込むかを考えればいい。

可視化ライブラリは古くは D3.js、最近は関数を一つ呼び出せば綺麗なチャートを描いてくれるものもたくさんあります。でも「有り物のチャートでは満足できない」という人は、D3.js のような低レイヤーの API を使って可視化を組み立てていく。そういう時にこのアプローチが有効になります。

**私は D3.js で UI を構築するということはもうやっていません。**D3.js 自体はしょっちゅう使いますが、UI の構築・可視化の構築には React を使うというアプローチをずっと取ってきました。

D3.js を「可視化のオールインワンのパッケージ」として使うのではなく、「データ変換のためのツール」として使うアプローチです。

先ほどの「データと視覚要素をどう結びつけるか」でやっていたのは、実は線形変換です。d3.scaleLinear はよく使われるのではないでしょうか。そういうものでデータと視覚変数の対応関係を作り、必要なコンポーネントに渡してマッピングをする。

**新しく始める際のポイントは d3.select を使わずにやってみること。**おそらく d3.select から勉強された方が多いと思いますが、宣言的UIで可視化コンテンツを作ろうと思ったら、まず d3.select を使わないという縛りプレイから始めるといいかもしれません。

もちろん完成された D3 のコンポーネントを持っていたり既存ライブラリを使いたい場合は直接使った方が効率的ですし、必要になれば React の中に d3.select を組み込むこともできるので、そんなに怖がらずに。「まだ d3.select で UI 構築しているよ」という人は、結構違った世界が見えるかもしれません。

トレンド② パフォーマンスと Next.js

本当は昨日のリリースに間に合わせたかったのですが、パフォーマンスを意識した新しい技術スタックで作るアプリケーションにチャレンジしていました。

新型コロナウイルス感染症対応地方創生臨時交付金——内閣府が地方自治体に向けてコロナ対策の補助金を出すので提案を出してください、というものです。全国約1800の自治体から集められた6万件ほどの事業情報が Excel で公開されていたので、データベース化しました。

自治体の数が多いので事業数が多く、地域性も見たいということで、地図を含むいろんな観点から検索できるダッシュボードを開発しました。

「緊急経済対策との関係」が19個ほどのカテゴリーから選択されていたり、「地域未来構想20」との関係が書かれていたりします。医療関係、中小企業対策、環境、地域経済の活性化——カテゴリーごとにいくら使われているかを表示し、絞り込むと「どの自治体がどれくらいの金額の事業を行っているか」の地図表示もリアルタイムに連動するようにしました。

パフォーマンスの原則

データ容量が大きくなると Web サイトの中身がなかなか表示されず、ユーザーは見るのを諦めて離脱すると言われています（これは可視化に限らず Web 一般の話です）。

パフォーマンス、結局「時間」というのは「距離 ÷ 速さ」なんですよね。

地球上は光ファイバーで通信されていますが、残念ながら「速さ」の方の光は速くならない。なので「距離」をいかに縮めるかが、どんなレベルのパフォーマンスでも問題になる。

CPU の高速化でも、**レジスタからメモリまでの距離が遠いので近くにキャッシュメモリを置く。**Web でも、海外だけにサーバーを置くのではなく日本にもサーバーを置いてコンテンツを早く届ける。

メインのアプリケーションサーバーとデータベースがあって、そこまでの距離が遠いのが問題なので、ユーザーのより近くにエッジのサーバーを置く必要がある。

でも、可視化のデザイナーがここまでフルスタックにエンジニアリングして可視化アプリを作るのはなかなか大変じゃないですか。

そこで CDN（コンテンツデリバリーネットワーク）の利用で Web サイトの体験を良くすることが、より身近に手が届くようになっています。

React ベースの Next.js は、**Web サイトのローディングパフォーマンスを向上させる仕組みにかなり力を入れています。**これを作っている Vercel という会社がホスティングサービスを提供していて、そこに Next.js のアプリを載せるだけで勝手にこうした恩恵が受けられる。

もう一点のメリットとして——可視化コンテンツを表示するために毎回データベースを叩いて集計するとコストが小さくない。一方で見られるデータは毎回同じなはず。Next.js や Vercel はキャッシュの仕組みを持っていて、データベースへのアクセス回数を落とせます。

可視化アプリケーションでも、こういう技術トレンドが取り入れられていくのではないかと思います。

トレンド③ WebGPU と WebAssembly

キーワードだけになりますが——

WebGPU

先ほど説明されていた deck.gl は WebGL ベースのライブラリですが、もう一歩先のグラフィックスAPIの策定が進んでいて、それが WebGPU です。

OpenGL はコマンドを発行するコストが大きいという問題があり、それを取り払うために Vulkan や Apple の Metal といった低レベルなグラフィックスAPIが策定され使われるようになりました。Web もそれに準じた API を提供しようと進んでいます。

大きな違いの一つが GPGPU が可能になること——GPU で計算できるようになる。

ブラウザ上で大きなデータと向き合う時、描画だけでなくある程度クライアント側で処理しなければならない。そこそこの量となると複雑な計算をクライアント側で高速にやる必要が出てくるので、有力な選択肢の一つとして上がってくるのではないかと思います。

WebAssembly

Web は文化が独特なので、Web の上で使える可視化ツールが他に持って行っても使いにくいという問題があります。

そこで WebAssembly ——ブラウザ上で動作するバイナリフォーマットです。これを使えば **C++ や Rust など他の言語からコンパイルしてブラウザ上で動くプログラムを生成できる。**すでに多くのブラウザで動作する実用的な技術です。

私もこれを利用していて、グラフのレイアウトを計算するライブラリを、論文を書くためにも作らなければいけないし、アプリを開発するためにも作らなければいけない。それを両立させるために Rust で実装して、研究用のベンチマークと Web アプリ開発の両方に使ったりしています。

可視化は総合格闘技

技術的にもいろんなことを考えなければいけないし、ドメインエキスパートと協業するのも大変です。

可視化という自分の主軸を置きながら、他の技術・他のドメインにチャレンジすることがどうしても必要になる。データを収集して加工して可視化してシステムを構築する——本当にいろんなレベルのスキルが必要です。

でも、これに恐れずチャレンジしてほしい。私は可視化は総合格闘技だと思っていて、情報科学プラスアルファの周辺分野の幅広い知見を学んで実践していく、チャレンジングな分野だと思っています。

ドメインの専門家と協業するという意味では、本当に「壊すことを恐れない」——たくさん作ってたくさん壊していいと思います。

これは企業と一緒に作っていたものの事例ですが、結構何回も作り直しています。「もっと違うものが見たい」「作ってみたけれど見たいものは違った」——作っては見せて意見をもらってまた直す。

**そういうプロトタイピングを通じてドメイン専門家との相互理解が生まれる。**可視化の専門家としてはドメイン知識とユーザーニーズが得られるし、同時にドメインの専門家も「可視化によって何ができるのか」「分析によって何ができるのか」の理解が深まります。

学生の取り組み

うちのゼミでは、ガチガチの理系の学生でもプログラミングや情報科学だけでなく、「デザインをどう考えるか」のワークショップを一緒に勉強したり、データを頑張って取ってきて整形してデータベースにしてシステムを作ることに取り組んでもらっています。

一例として、今の4年生が開発している「世界の音楽トレンドの可視化」。Spotify で各国で再生された曲のランキングと詳細情報を使って、SPA として可視化コンテンツを作ってもらっています。

この1年間、完全にオンラインでやっていたのですが、オンラインのツールをすごく活用してくれていて、ユーザーストーリーマッピングをやってみるなど、議論を重ねてくれました。いろんな観点から音楽トレンドの情報が可視化できるコンテンツになっています。

取り留めのない話でしたが、可視化をちゃんとやっていこうと思うと、どうしても可視化だけにとどまることはできないのが現状だと思うので、技術的にも領域的にも広く考えて取り組んでいけたらと思っています。

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

WebGPU on Data Visualization Japan

尾上 洋介／ビジュアライゼーションとモダンWeb開発