JUDGIT on Data Visualization Japan

尾上洋介／ビジュアライゼーションとモダン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年間、完全にオンラインでやっていたのですが、オンラインのツールをすごく活用してくれていて、ユーザーストーリーマッピングをやってみるなど、議論を重ねてくれました。いろんな観点から音楽トレンドの情報が可視化できるコンテンツになっています。

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

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

矢崎裕一／JUDGIT!、そして、コロナ予算の探索的可視化

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

Data Visualization Japan Meetup 2021（2021年12月29・30日開催）における、矢崎裕一の講演です。行政事業データベース「JUDGIT!」と、NHKスペシャル「検証コロナ予算」に連動する Web コンテンツの制作過程についてお話しします。

イベントページの方に最後まで「カミングスーン」というか「何を話すんだ」という状態になっていたかと思いますが、タイトルとしてはこういう形にさせていただきました。「JUDGIT!、そして、コロナ予算の探索的可視化」です。

一つ前の尾上先生のところで JUDGIT! の話があったかと思いますが、私も少し後のタイミングからこのプロジェクトに参加させていただいています。そこから、昨日 NHK スペシャルでコロナ予算の使い道の調査報道の番組がありましたが、その Web コンテンツの方でお手伝いをさせていただいております。

今日はそこに関わった時の話をします。NHK さんのことを私が話すのはおかしいので、あくまで私自身のエピソードとしてお話しさせていただきます。

JUDGIT! とは

名前がいいですよね。どこかで聞いたことがあるような、でも造語みたいで、SEO に強そうで、覚えやすいんだけれどちょっと独特、という。

関わっているメンバーとしては、この Visualizing.JP というのが私のロゴでして、すでに皆さんで進められている中で一番最後に混ぜていただいたという感じです。

構成メンバーとしては——

構想日本 ——地方で行政事業レビューをやられていて、民主党政権の時に日本の政府にやり方を提案された。その後、自民党政権になってもずっとその仕組みが続いています
Tansa（少し前の組織名で言うとワセダクロニクル）——新聞社ご出身のジャーナリストの方たちが立ち上げた NPO の調査報道団体
尾上先生のラボ

何ができるか

いろんな切り口で行政事業の検索が行えるようになっています。

下世話な使い方としては、世間を騒がせるニュースがあった時に、関係する名前を打ち込んでみるという興味本位的な使い方もあります。

ここに載っているのは、国の中央省庁を通じて何かのプロジェクトをやる際に、どんなプロジェクトでいくら支払われていて、その先のアウトプットはどうだったかというデータベースです。

ですので実は**民間企業の方にも役立ちます。**大企業にお勤めの方が「自分の会社でこんなプロジェクトをやっていたんだ」と発見したり、競合が国の委託事業としてこんな事業をやっているんだと見つけられたりする。どういうプロジェクトにいくらの予算がつき、何年かけてやったのかが分かるので、今後の入札に役立てることもできる。

グラフで検索

私がお手伝いしているのが「グラフで検索」という機能です。まずざっくりとデータの姿を眺めるところから始めませんかということで、棒グラフを使って複数の切り口を同時に表示しています。

府省庁という単位で絞り込んで、厚生労働省の「子ども・若者育成支援」ならどんなプロジェクトがあるのか、と一覧を出す。あるいは主要施策の切り口から「科学技術イノベーション」をテーマにした事業を見てみると、文部科学省だけでなく、経済産業省や防衛省もこのテーマで予算をつけて事業をやっていることが分かります。

一般的な Web サービス——たとえば食べログのようなレストラン探し——は、割とベストエフォートというか、「その時空いている」「食べたいものに近い」という形で、ずばりを見つける感じでもないと思うんです。

**このサイトの場合は「そのものズバリ」を見つけたい。**そのアプローチとして、データがどういう姿をしているかを確認しながら、少しずつ自分の興味関心をもとにデータを切り刻んでいく——そういう見方ができるサービスになっています。

記者会見とグローバルカンファレンス

発表した時、参議院議員会館で記者会見をしました。隣にいるのが尾上先生、後ろが Tansa の皆さんと構想日本の皆さんです。記者の皆さんも隠し撮りしてみたということで、こんな感じで詰めかけていらっしゃって、記者会見の舞台裏を体験することができました。

Yahoo! ニュース個人という枠組みがあり、専門家をオーサーとして指名し、事前チェックなくそのままパブリッシュできる仕組みがあります。そこで JUDGIT! の話も書かせていただきました。覚えたてのパラグラフ・ライティングで書いてみたという感じになっています。

また調査報道系のグローバルカンファレンスがあり、ワセダクロニクルさんが定期的に行ってコネクションをガンガン作っていくという活動をされています。そこで JUDGIT! も発表したいということで、私も一緒についていって、Tansa の方と2人で英語で発表してきました。漫才じゃないですけど、目の前に机も何もない状態で、怖いなという体験をしてきました。

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

昨日放送されたもので、3回あった補正予算の中でコロナ予算と呼べそうなものについて、報道のアプローチとして中身を調べ、現地でインタビューもする番組でした。

この中で、番組とほぼ同じタイミングで公開された Web コンテンツ——アートディレクション的なところと、データを探索的に操作できる Web コンテンツ——を作らせていただいています。

難しさ

「新型コロナ禍」というテーマのコンテンツをマスに向けて作ると考えた時、いろんな難しさが想起されます。

**まだ完全に終わったと言えないし、亡くなられた方もいらっしゃるし、今も苦しんでいらっしゃる方もいる。**一方で「お金」という独特なテーマを扱う。これを Web のコンテンツとしてどう表現し、取りまとめたらいいのか。

コンセプト

これは私が考えたことですが、NHK の皆さんも同様のことを考えていらして、すごく話が合ったところです。

コロナ予算と呼ばれているものの全体像を俯瞰したい
せっかく Web で提供するので、ユーザー・視聴者が自分の興味関心に応じてデータを探索できるといい
一人の市民として、コロナ予算との関わり方を見つけ出せると、より自分ごとに引き寄せて考えられるのではないか

番組の演出では、冒頭でお札がうわーっと積み重なってものすごく高くなる CG がありました。あの表現は私もすごく好きで、初めて見た時はゾッとするようなところがありました。

一方で Web でそれをどう表現するか。「77兆円」というのはすごくマクロじゃないですか。日本全体の話でもあるし、これ以上ないくらい集計した値でもある。そこだけ見せられても実感が湧かないし、距離が遠すぎる。

トーン&マナーを言語化する

デザインの「トーン&マナー」——具体的な文字や写真だけでなく、見た目から受ける印象です。「印象」と言うとふわっと聞こえるかもしれませんが、すごく大事な要素で、これをどうするかをまず言語化しようと思いました。

一口に「綺麗」と言っても——

洗練されている／シンプル → 今回のプロジェクトに合っている
透明感／ピュアさ → 遠くにあって合わない。むしろ感じさせない方がいい

「信頼感がある」と言った時も——

整然ときちんと並んでいることから感じる信頼感 → これはいい
大人の風格 → そうでもない。学生さんも含め年齢問わず見ていただきたいので、年齢的な属性はあまり関係ない

「楽しい」で言うと——

遊び心がある → これが「楽しい」に通じるといい
子供向け／ポップ／元気な感じ → 必要ない

こういう啓蒙的なコンテンツだとレゴっぽい色使いがされることもありますが、今回それがふさわしいかというと、そうでもない。

**では、この遊び心を今回のプロジェクトに合った形でどう取り入れるか。**これが一つのテーマでした。

ユーモアの「温度感」

そこでイラストを活用しようと。何らかのユーモアを感じさせることができれば、それが遊び心につながるのではないか。

ただし、ユーモアにも温度感があるわけです。お風呂の湯温と同じで、**熱いのがいい人もいれば、ぬるめで長く入りたい人もいる。**一口に「ユーモア」と言っても、どんな温度感のユーモアなのかが問われます。

人を選ぶユーモアの例

私が好きなのは amadana という家電メーカーです。東芝にいた方が外に出て、インディペンデントなデザイン家電を作られていました。

その万能リモコンの取扱説明書に、注意書きとしてこんなことが書いてあるんです。「自分のガールフレンドはこれでコントロールできません」とか。ちょっとエスプリというか、クスッとくるものがある。

私自身も amadana が好きだったので、防災トートバッグのデザインをさせていただく機会があり、イラストも自分で描きました。自然災害が起きた時にこのトートバッグが役に立つ、と。物が入るのは当たり前なので、**それ以外の使い方をイラストで提案する。**その中に「かぶると一人になれますよ」というのも書いています。

これもユーモアではあるのですが、人を選ぶユーモアだなと。私自身は好きなんですけれど。

たとえば「マスクを口だけでなく鼻にも3つつけたら完全装備です」とか、「マスクが足りなかったのでアベノマスクが助かりました」とか——**これはやはり人を選ぶ。**人によっては不快に思ったり、違う文脈を見出して気持ちがザワザワするかもしれない。今回は合わないだろうというところです。

人を選ばないユーモアを探す

では人を選ばないユーモアとはどんなものか。

なんとなくイメージはあったので、イラストレーターの方をアサインして、その人が持っている世界観を引っ張り出そうと考えました。イラストレーターのカタログサイトで、自分が考える「人を選ばないユーモア」を体現してくれそうな人を探したんです。

面識はなかったのですが連絡が取れて、スケジュール的にはタイトでしたが「問題なくやってくれます」ということでお願いすることにしました。朝日新聞社内でデザイナーとして働かれていて、ちょうどその年の8月に独立、独立3ヶ月目という方でした。私はそのキャリアは全然知らず、単純に作品を見てお願いしました。

たとえば——

「弁当パジャマパーティー」 ——二段重ねのお弁当箱を二段ベッドに見立てる
クリームソーダのアイスを、北極・南極の浮いている氷に見立てる
ナルキッソス（ナルシストの語源になった人物）が水面を覗き込む様を、スマホで再現

スケール感をずらすんですね。普通ならお弁当の中で寝られないじゃないですか。でもスケールが違うと入れる。現実に存在している行為・ものなんだけれど、少し異化効果が出る。これは誰も傷つけないし、ちょっとしたおかしさを感じることができる。

何を描くか

誰もがこの2年として記憶しているシチュエーションの情景がいいのではないか、ということで——オンラインのビデオチャット（Zoom や Teams）で飲み会をやった、テレワークをした、みんなマスクをつけていた——そういうところをモチーフに選びました。

実際に描いてもらうと、意味は保ったままスケール感を非現実的にすることで、広い間口のユーモア、目を引くキャッチーな分かりやすさ・楽しさを込めることができたのではないかと思います。

もう一つは、正反対の指向性を持つものが同居していることの面白さです。

屈強でマッチョな男性が、注射をめちゃめちゃ怖がっている
上半身はきちんとジャケットを着込んで、顔の周りに星が出るくらい明るく丁寧に話しているのに、下は寝巻きでゴミが置いてある
自動で消毒液が出るハンドサニタイザーに、たまたま歩いてきた猫がかかってしまう——意図しないおかしさ

ちなみに「Zoom 足湯」——足だけ入るお風呂に見立てたもの——を作ってほしかったのですが、**これは採用してくれませんでした。**イラストレーターの方が「もっといいアイデアがある」ということで、別のものを考えてくださいました。

前提として、ジェンダーを感じさせない、男らしさ・女らしさをイラストのトーンから感じさせない中性的なものがいいだろう、というのはもともとありました。

お札にマスクを描く

一方で、もう一つ課題がありました。「整然とレイアウトされていることによる信頼感」も表現しつつ、イラストを通じて「人を選ばないユーモア」も伝えたい。この2つをどう同居させるか。

数日、頭の片隅に置いて考えました。手書きでいくつか描いてみたけれど、しっくりこない。

そこでこんなアイデアが浮かびました。

**お札に人物が描かれていますよね。その人物も、実はこの2年、マスクをしているんじゃないか。**そこでマスクをさせてみた。テーマが「新型コロナとお金」なので、うまくフィットするのではないか。

お札に描かれているのは、過去に功績を遂げた著名な方です。**その中に、私たち一人ひとりが入っていく。**イラストで描いてもらった、コロナ禍で誰もが経験した情景や行為が、お札として刷り込まれている。

お札が整然と並んでいることによる信頼感・シンプルさと、イラスト表現によるユーモア——この2つをうまく混ぜて、一つの表現として統合できないかと考えました。

公開したコンテンツ

① 主要施策が複数省庁にまたがる様子を俯瞰する

あまり複雑にしすぎないで見られるものがいいということで、横軸に中央省庁、縦軸に色分けで主要施策を配置しました。

主要施策は20個ほどあります。色で区別するとして、凡例をつけるか。

正直に20個のカラーバーを並べて「どの色がどの施策です」と示しても、**積み上げ棒グラフとの対応を目で行ったり来たりしながら追うことになる。**それは疲れるし、大変な割に分かったような分からないような感じになりそうでした。

そこで凡例をつけるのではなく、クリック（タップ）していただく。すると該当する施策のみが残った状態になります。

たとえば「地方創生」なら——いまクリックしたのは内閣府ですが、それ以外にもいろんな省庁が同じ「地方創生」でプロジェクトをやっているという偏りが見て取れます。

「沖縄振興」なら、本当に内閣府が一手にやっていて、他はほとんど扱っていない。農林水産省がちょっと扱っているくらい——そういう発見があります。

ここに JUDGIT! へのリンクがついていて、クリックすると**絞り込んだ条件のまま JUDGIT! に飛ぶ。**省庁は内閣府、主要施策は男女共同参画、2021年度に公開された補正予算のレビューシート——というように。7つに絞り込まれているので、一つ一つ見ていけばより理解が深まります。

凡例をつけないのは、もしかしたら約束破りかもしれないのですが、クリック・タップする中から発見してほしいという思いがあります。

② 予算規模に応じた成果は

左右2つの塊に分かれています。

左：1つのプロジェクトにかかっている予算額の合計を、多い順に並べたもの
右：その事業を通じてどういうアウトプットが出たか、多い順に並べたもの

**問題は、アウトプットの単位がめちゃめちゃたくさんあること。110種類あります。**人数だったり金額だったり——網羅的に一つの単位にできそうなものも当然あるのですが、行政事業レビューシートを記入する官僚の皆さんがそれぞれ別々に書くので、違う単位が使われている。

そうすると施策を横串で通した評価がしづらい。

本来であれば、インプット（お金・リソース）とアウトプット（人数・件数）の比が事業の成果であり、定量的に効果を計測して、2年3年と回すことでパフォーマンスが良くなったか悪くなったか、複数プロジェクトを比較できるはずなんです。

現状は単位が148種類ほどあるので、**クレンジングのしようもなくそのまま入れています。**上のプルダウンで省庁と単位を選ぶと、合致するプロジェクトが下に出てきます。

そして同じプロジェクトを線でつなぐ。これはスロープグラフと呼ばれる手法です。

赤く塗られている線が「予算額は少なめなのに、活動としては大きい数値を出している」もの——右上に線が伸びているものです。金額が少ない割にアウトプットが多い、逆に金額が多い割にアウトプットが少ないというのを俯瞰して見える仕組みにしています。

少し乱暴かもしれませんが、探索する目安にしていただければと。プロジェクト名にマウスポインターを載せると「JUDGIT! で確認する」が出て、クリックするとそのものズバリの行政事業レビューシートが見られます。

制作中のもの ― サンキーダイアグラム

まだ公開していない部分ですが、どこからどこにお金が支払われたかをネットワークとして捉えることができます。

支払先は8,243件ほど。ただしこれも、固有名詞を一つ一つ確かめないと、そもそも8,243なのかどうかも分からない。

たとえば「株式会社」が全角カッコで書かれていたり、漢字一文字で表現されていたり。クレンジングをやっている方からすると「クレンジングしたくてたまらない」感じになると思うのですが、名寄せ特有の難しさがあります。

法人番号が国税庁から API やデータセットで公開されているので、それと突合させれば正式名称は分かる。ただ、そこからさらにどうグルーピングするかという問題もあります。

左に中央省庁が縦に並び、右に地方自治体、労働局、国立系の機関、独立行政法人などが並ぶ。**このグルーピングを作ってデータ化して教えてあげないと、正しく表現できません。**D3.js で作っているのですが、D3 側が「これは地方自治体だよね」と丸めてくれることはない。なのでどうまとめるかというデータも必要になってきます。

これはサンキーダイアグラムと呼ばれるチャートです。有り物のライブラリを使っているので、独自の表現にするために手を入れながら自分の表現に引き寄せていきたいと思っています。

どこの省庁からかで支払先がガラッと変わるので、これだけでも結構面白いという感じがしています。

技術的な共有

Cloud Dataprep

データのクレンジングについて。Cloud Dataprep という Google Cloud のサービスがあります。

今回のコロナのデータはそこまで大きくないのですが、ファイルサイズが大きいデータをクレンジング・名寄せする時にすごく便利なツールです。一番安いプランで月額1万3〜4千円ほどするので高いといえば高いのですが、かなり大きめのデータでもクレンジングや名寄せができます。

システムを組む必要は特になく、Google Cloud Storage や BigQuery に GUI でファイルをアップロードすれば Dataprep で読み込めて、GUI でクレンジング・名寄せ処理が行えます。

Python で同じことをやろうとすると、どんな複雑なコードを書かなければいけないんだろうと戦々恐々とするので、**時間がない時は「使っちゃえ」**ということで、ご紹介させていただきました。

レスポンシブ対応

D3.js などで1から可視化コンテンツを作る時、レスポンシブレイアウトに合わせるのは悩ましいですよね。

可視化コンテンツが表示される Web 標準の画像フォーマット SVG で、まずサイズを指定します。そして preserveAspectRatio ——ブラウザが大きくなったり小さくなったりする時に SVG の拡縮の基準点をどこにするか——を、縦も横も中央にする設定にしておきます。

横幅は追従させるとして、では縦はどうするか。これは横幅に対する比率でやるとうまくいきます。

ただし——大きいディスプレイで見る場合は横幅がかなり長くなる。4:3 で作ると縦がすごく長くなってしまうので、**大きめのディスプレイに対しては縦を短めにして、結果的に横長にする。**1280〜1920px くらいならもう少し縦幅をしっかり取る。スマホのポートレートモードならまた全然違う。

今回は3パターンで出し分けて、最大公約数的なところはいけたかなという感じです。ユーザーが気まぐれにウィンドウサイズを変えることもあるので、それを検知したらサイズを取得し直して SVG に伝えると、いい感じにフィットします。

チャートの状態へのパーマリンク

インタラクティブに操作できるチャートを人にシェアしたい時、毎回トップページ的な「何も操作していない状態」をシェアすると、受け取った側はもう一度自分で最初から見ていかなければならない。

たとえば「男女共同参画のこの状態を人に伝えたい」と思った時、リンクを送るだけでなく「どう操作してみて」と伝えなければならない。

それよりは、URL の中にチャートの状態が組み込まれていて、そのままシェアできるとすごくいい。

いわゆる GET メソッドです。URL の中にクエスチョンマークがあって長々と文字が付いているアレですね。?変数名=値&変数名=値 という書式で、送りたい設定項目が全部書いてある URL です。

この書式に、ユーザーが操作するたびにチャートの状態を常に書き換えています。そうすると常にチャートの状態が URL として保存されているので、見ているユーザーは何も考えずに URL 欄からコピーして人にシェアすればいい。

なお、他の人が勝手に書き換えても大丈夫なように、一応内部でチェックしています。正しい値かどうかを確認し、合致しなかったら初期値を入れるという感じにすれば、悪意やいたずら心を持って書き換えられても問題ないかなと。

まとめ

今日は、まず JUDGIT! というプロジェクトの話を共有させていただいて、そのデータも活用する形での NHK の番組と連動した Web コンテンツについて——デザインプロセスで考えたことと、チャートとして実装する時に気を使った部分をお話しさせていただきました。

以上です。どうもありがとうございます。