データ可視化の実践者が共有すべき知識

はじめに

私は可視化の研究者ではありませんが、先日、実際に可視化を作成する必要に迫られて試行錯誤しながら学んだ知識の一部を以下の記事にまとめました：

• プログラマーが効果的な可視化を作成する

改めて読み返してみると、本来は本でカバーすべきようなトピックを無理やりまとめたため、かなり急ぎ足で流した部分が多く感じます。そこで本稿では、その中の一部を補足する記事を書いてみました。

データ可視化と言う実際の作業

先の記事にも書きましたが、データ可視化をするということは、そこに伝えたいストーリーが存在するということです。ストーリーと言う言葉は多分に主観的な意味を含みますが、一方でそれを形作るデータは（原則論としては）客観的なものです。結果として、可視化を作成するという作業は、伝えたい自分のストーリーを形作るという主観的な部分と、データを一定のルールに従って視覚変数にマッピングしていくという客観的な作業のせめぎあいとも言えます。ここで、ストーリーを伝えるという部分を忘れてしまったり、主観的な美意識（？）が極端に出てしまえば、それはひとりよがりな、よく分からない図になってしまいます。

参考：　「悪い」可視化、恣意的な可視化の事例集

例えばこのエントリの最初の図は、私達が作っているソフトウェアの機能デモとして、挿絵的な用途を前提に作ったものですからその範囲においては有効かもしれませんが、実際の論文に使う場合は、ラベルの読みにくさなどが問題になってくるでしょう。このように、実際に作業する場合には、用途やオーディエンスを考えて様々な手法を使い分ける必要があります。

「悪い可視化」を避けるための知識の共有

現在、可視化の「悪い例」、そして「良い例」は、インターネットでちょっと検索すればいくらでも見られますし、可視化のイロハを説いた教科書も（英語ですが）たくさん出回っています。これらは素晴らしい学習のためのリソースなのですが、一つ問題もあります。多くの場合、良い例・悪い例と言う結果を見ることは容易なのですが、そのプロセスを追体験することは現在でもなかなか難しいのが実情です。ソフトウェア開発の世界ではベストプラクティスと言う言葉をよく使いますが、データ可視化の世界でも、教科書的な基礎から一歩先の実践者向けのベストプラクティスを蓄積することは、関係者の時間を節約し、出来の悪い可視化を減らしていくと言う意味で非常に重要だと思います。

サイエンスとジャーナリズム

サイエンスの世界では、大学院で科学の作法のトレーニングを受けた人々が、再現性の確保等といった基本的な仕組みに則り研究を行います。結果は査読システムと言うフィルタを経て論文という形で公開され、公平性や一定の正しさを担保しています。しかし一方でショッキングなニュースもあります。多くの「ランドマーク的成果」、すなわち多くの研究論文の引用元になっているようなインパクトの大きい研究でさえも、再現性が乏しい物があると言う事実がわかってきたのです（参考文献）。実験の管理と言うレベルでの瑕疵がある場合はわかるのですが、そのデータを解析する過程にも再現性の問題は潜んでいます。科学が高度化すればするほど、生のデータ生成から最終的な可視化を含む論文に至るまでには非常に複雑なプロセスを経ており、そこには無数の「バグ」が混入する余地があります。

大規模な実験では、実験そのものの再現が非常に高コストであるために不可能な場合も多いのですが、現在では、特に生物学分野において、各種公共のデータベースに登録されたデータを統合・解析して科学的な知見を得ようとする「ドライ」な研究（実際の生き物を使った「ウェット」な実験に対する言葉として使われます）も盛んに行われています。問題は、本来ならば正しく解析の手法をなぞれば同じ結果が出るはずのこういった研究でも、再現することが困難であったり、異なった結果が出たりということがあることです。これは米国における巨大なfunding agencyの一つであるNIHのディレクター達も問題視しており、多面的にこの問題に取り組んでいます（参考）。

さて、科学と言う分野ではこういった問題は広く認識され、皆がその解決に向かって取り組みを始めています。では他の分野ではどうでしょうか？最近はジャーナリズムの分野でも、大量にある公開データを統合・再検討して可視化し、記事にすると言うdata-driven journalismと呼ばれるような手法が流行りつつあります(参考文献)。これは従来の調査報道の文脈で語ることが出来る動きだとは思うのですが、ネットの普及以前と大きく異なるのは、そこへの参入障壁自体が非常に低くなっているという点です。公開データへのアクセスの容易さと、個人で利用できる計算機のリソースが増大したことにより、知識さえあれば一人のジャーナリストができることは以前とは比べ物にならないほど大きくなっています。もちろん、実際の情報ソースにあたって取材をする記者の方々の重要性は変わりませんが、それを補完する役割としての公開データセットからの知識抽出を行える人々も含めたチームが、今後のジャーナリズムでは車の両輪となるはずです（余談ですが、この関係性は生物学におけるbench biologistとcomputational biologistの役割に非常に似ていると思います）。このような流れになれば、データの出自の管理、解析に使ったツール、実際に可視化を行った時に使った手法やコードなどといったものの管理が新たな問題としてジャーナリズムの世界にも訪れるのは容易に想像できます。

サイエンスもジャーナリズムも、どちらも公共性の高い透明性が求められる分野としての共通点があるうえに、上記のような潮流があるため、今後は技術的な部分でも問題やその解決方法を共有できる可能性があります。すなわち、最終的な可視化に辿り着くまでの過程の透明性と再現性を確保するためのノウハウ、もしくはベストプラクティスと言う部分です。

コードとしての可視化の二面性

上記の問題を更に複雑化している原因の一つに、最近の計算機を利用した複雑なデータ可視化があります。データ可視化と行っても様々なレベルがありますが、典型的なヒストグラム、ラインチャートなどといったものならば、それほど大きな問題にはなりません。チャートジャンクの問題はありますが、基本的には機械的な変換作業が多くを占めます。一方で、D3.js等を利用した高度にカスタムされた可視化はどうでしょうか。その場合には、可視化の技法そのものの実験的要素まで入り込みますし、表現の自由度はExcelなどを利用したプリセット可視化とは比べ物になりません。しかし表現に自由度が生まれるということは、そこに主観の入り込む余地も大きくなるということです。「数字そのものを捏造せずに統計でウソをつくことが出来る」と言う事実は、少しでも統計学をかじった人ならばよくご存知だと思います。同じように、見るものを惑わすようにデザインした複雑な可視化というのもまた可能であり、コンピュータベースの複雑な可視化ならば更にその危険性は高くなります。こういった可視化は、コンピュータのコードが生成するものですから、ソースコードとデータさえあれば誰がやっても同じ結果が出せるという点では透明度は高いのですが、コードとデータ両方がオープンになっていない限り、プロセスの再現性と透明度という点ではやや危なくなります。

結果の共有からプロセスの共有へ

これらの問題点を解決するには、多分野に渡るノウハウや技術の共有が必要になります。オープンソースという考え方はソフトウェアの世界では広く浸透しましたが、ジャーナリズムの世界でこれが浸透するには未だ少し時間がかかる気がしています。手法を完全に明らかにして公開データからコードを使って可視化を作成し、それに基づいて記事を執筆するということは、ウソがあればいずれ発覚するいうことを意味しており、いい加減なことをすれば自分の評価へと跳ね返ってくるからです。現在は、表やグラフを報道に使うことはあっても、その過程の詳細を公開するなどということは未だ一般的ではなく、この「なんでもとりあえずオープンにしてしまう」と言う文化に慣れるには一定のモラトリアムが必要でしょう。

ソフトウェアの世界でも、全てをオープンにすることに抵抗のある人もいますし、そういう部分がある事自体は問題無いと考えています。しかし、報道や科学といった公共性の高い分野においては、出来る限りのオープン性を求めていくことが全体の利益となるはずです。プロセスの何処かにブラックボックスを挿入するということは、そこから先のプロセスの妥当性を検証することが困難になるということで、これは科学や報道の世界には馴染まないと思われます。

この理念を実現する上で重要なのは、既存の技術によるプロセスの透明化と共有です。これは10年前なら（技術的には可能でもコスト的に）不可能でした。しかし今は極めて低コストでこれらを実現する仕組みが整いつつあります。これらが可能なのも先に触れたオープンソースの潮流のお陰です。サイエンスの世界は、多大な恩恵をオープンソースソフトウェア(OSS)から受けています。報道の世界にも同じ流れが見え始めています。

Provenance

このプロセスの共有という問題を考える時のキーワードはProvenanceだと考えます。Provenanceとは、英語としては固い表現ですが、データを扱う人々の間では頻繁に使われる単語です。何も難しい話ではなく、データなどの出自や履歴のことです。データからコード、実行環境までを履歴として管理するのは技術的には大変困難でしたが、現在の計算機を使った可視化ならば、それがOSSのおかげで可能になりつつあります。

データ

データと一言に言っても、形式やサイズにたいへん幅があります。Git等のSCMは基本的にソースコードのような比較的小さなサイズのデータの履歴を完全に保存し、グラフとして辿れることに主眼をおいて作られたシステムなので、大規模なデータの管理には向きません。逆に大規模なデータというのは、一度生成されてしまえばそれを頻繁に改定して多人数でエディットするということは考えにくいため、多くの場合直線的な履歴になると思われますので、一般的に利用できる各種データベースの機能で間に合う場合も多いでしょう。

一方、小規模なもので頻繁にある特定のフォーマットに加工されたり、データに対するアノテーションを加えたりする場合には、履歴のグラフが複雑になりがちなので、特に履歴の管理が重要になります。こういった二次加工が施されたデータは小さく切り分けられている場合も多いので、ソースコードのようにGitで管理してしまうということも可能です。

また別のアプローチとしては、生のデータは極力そのままでデータベースなどに流し込み、それ自体にエディットは施さず、必要に応じて下に述べるコードとして書かれたワークフローを実行し、中間生成物をその都度得るということも可能でしょう。

解析・可視化の過程

実験を含む科学論文には、必ずプロトコル（手順）を記述するセクションがあり、基本的にはそれに従えば同じ結果を得られます。結局それはソフトウェアのREADMEを読みながら環境をセットアップし、実行して…と言う一連のプロセスを手動で行うことに似ています。幸い、コンピュータベースの可視化では、データの加工から実際の可視化部分まで、全てをコードとして記述することが出来ます。これを書くのはもちろん普通のスクリプトファイルでもいいのですが、更に便利なツールが普及しつつあります。

可視化のための作業では、クレンジング→解析ライブラリ用に加工→解析→可視化ソフトウェア向けに加工→可視化と言う流れが一般的です。これらを人が読める形で保存しておけば、プロセスそのものの再現性の確保に役立つばかりでなく、第三者による再現が容易になります。

IPython Notebook / Jupyter

科学実験では、作業を実験ノートに記録しますが、同じように解析と可視化の作業記録をインタラクティブに行える技術が普及し始めています。この「電子的な実験ノート」と言う文脈で一番ポピュラーなのがIPython Notebookです。使っていただければわかると思うのですが、「コードの入力/評価/結果の表示」と言うサイクルを、ブラウザの中で分かりやすい形で行えます。もともとはPythonに特化したものだったのですが、他言語を同一のインターフェースで使えるようにするJupyterと言うプロジェクトも始まっています。

• IPython Notebook
• Project Jupyter

こういったノートやスクリプトは、実体はJSONファイルや小さなテキストファイルであったりするので、履歴管理は従来通りGitなどを利用すれば容易に行えます。広く普及した標準的技術のみで履歴管理が完全に行えるというのがこれらのツールの便利な部分です。

実行環境

最後に解析と可視化を実行する実際の環境です。以前は、長いREADMEドキュメントを読みながら、指定されたバージョンのライブラリをインストールし、設定ファイルをいじり、エラーを出しながら更に依存関係を修正し…と言う部分が非常に面倒だったのですが、そういった問題を技術的に解決する方法がいくつかあります。これらは主に大規模なアプリケーションをデプロイし、適切に管理する必要に迫られた人々によって作られたものですが、「ビッグ」でないデータを加工して可視化する作業でも非常に便利です。

Docker

プログラマの方はバズワードとして聞かない日はないであろうコンテナ化技術のDockerですが、何もこれは大規模なアプリケーションをデプロイする軽量コンテナとしての役割だけではなく、小規模なデータ解析と可視化でも威力を発揮します。データの加工のプロセスでは、多くの場合、サードパーティ製のライブラリを使うことになると思います。PythonであればPandasは標準ですし、生物系の研究者であればRとBioconductorの組み合わせは必須でしょう。これらが依存するライブラリのバージョンも含めてきちんと記録して環境を整えておくというのは非常に面倒です。場合によっては、言語のバージョン自体を変更する必要性もあったり(2から3への移行が遅れているPythonだとこれは顕著です)、データを扱う人には頭の痛い問題の一つです。データ解析と可視化を行う人にとっては、これを技術的に解決するもののひとつがDockerです。

Dockerの優れているところは、Docker Hubというコンテナイメージのレポジトリがあり、ここに多数の典型的な設定が登録されており、それを継承・拡張できる点です。例えば、IPython Notebookをデータ解析に使う典型的な設定とともにコンテナ化したものはここにあります。継承と言う概念は、OOPの世界では当たり前に行えたことですが、これを誰でも環境に対して行えるというのは非常に賢いやり方だと思います。セキュリティモデルなどに色々と議論が沸き起こっている昨今ですが、解析環境の再現性の確保という視点から見れば、とりあえず今直ぐに使える技術として利用する価値は非常に大きいです。特に共同作業でありがちな、「自分のマシンでは動いたのに、相手のだと変なエラーが出て動かない」という非常に面倒な問題をかなりの部分解決してくれます。

おわりに

生物学は、ここ数十年でかつての博物学的なものから、data-drivenな科学へと変貌しました。近年、実験手法に多数のイノベーションが起こり、配列情報などが凄まじい勢いで増えています。このような急激な変化を体験しているのは何も生物学分野だけではなく、ジャーナリストの方々も公開された大量のデータから社会の状況を読み解くという新たな手法の出現で、様々な問題に直面しているのではないでしょうか。

Data Visualization Japan Meetup#2

宣伝になって申し訳ないですが、この話題に関連して今月の25日都内のSony Creative Loungeにて勉強会を開催します。今回の記事は、その時のトークの導入として書きましたので、更に議論を深めたい方はぜひお越しください。

• Data Visualization Japan (FBのグループです）