[OpenVis Conf 2014] Mike Bostockによるキーノート講演


OpenVis Conference 2014

Part 1: Keynote

はじめに

私は最近、自分が働く分野(生物学関連のデータの解析と可視化)に間接的に関わる分野で起こっている様々な先端を覗いてみよう、と言うテーマの元に全米各地のカンファレンスやワークショップに参加しています。私は研究者ではなく、彼らが必要とする計算機環境を提供するのが仕事であるため、重要なのは実践的であることです。従って参加するのは主に実践者(practitioner)向けのテック系カンファレンスと言うことになります。

今回はアメリカ東海岸マサチューセッツ州ボストンのケンブリッジ(MITやハーバードのあるエリアです)で行われた、OpenVis Confと言うカンファレンスに参加してきました。これは可視化ソフトウェアの開発者やデザイナー、データ分析を行う人々等、データ可視化分野の実務畑で働く人々のための会議です。従って、全く新しい可視化の論理やアルゴリズムを提示すると言うよりは、実際に手を動かしてアプリケーションやダイアグラムを作成する時に直面する諸課題について、経験やテクニックを共有するのが主なテーマとなっています。

どんなカンファレンスか?

openvis2014-01

カンファレンスの基本的な構成は、キーノートスピーカーを最初にオーガナイザーが決定し、他の登壇者は公募と言う形で作られます。今回の場合はMike Bostock氏のキーノートが最初に決定し、その後公募されたトークをオーガナイザーが選定しました。登壇者の専門分野はかなり多岐に渡り、企業でデザインに関わっている人から、NASAで働く人、大学教授、ソフトウェア開発者とかなりバラエティに富んでいました。従って講演の内容も多岐に渡り、可視化に関するテクニックの話からツールの紹介、プレゼンターの関わっている具体的な可視化プロジェクトの紹介など、実践的な内容が多かったです。具体的なトピックとしては、以下のようなものがありました:

  • 具体的なツールの紹介
    • IPythonの新機能の紹介
    • Rを使った解析とWebアプリ化
    • 新しい可視化ツールキットのデモ
  • 可視化の実践的なテクニック
    • 効果的な色使い
    • 大量のデータポイントの同時レンダリング
  • 可視化周辺の一般的な話
    • デザインの難しさとその克服
    • ジャーナリズムにおける可視化の歴史と実践

キーノート

ここからは具体的なトークの内容について振り返りたいと思います。内容が多岐に渡るので、内容を私が咀嚼してレポートとしてまとめるのに時間がかかっているため、まずはキーノートの内容をまとめてみたいと思います。

1. Mike Bostock

初日のキーノートは、高度にカスタム可能な可視化ツールキットとして事実上の標準の地位を獲得しつつあるD3.jsの開発者として有名なMike Bostock氏でした。彼は大学院生としてスタンフォード大学の可視化グループ(Jeffrey Heerのグループ。このラボは、2000年代半ばにもprefuseと言うJavaの可視化ツールキットを作成したことでも知られています。我々のプロジェクトでも、彼らのレイアウトアルゴリズムの実装を一部利用しています)でD3.jsを開発した後、今はNew York Times紙のデータ可視化部門で働いています。NYT社のサイトをご覧になっている方は分かると思いますが、彼らのサイトでは非常に凝ったデータ可視化アプリケーションを公開しています。その多くは彼を含む可視化チームの手によるものです。NYTは、いわゆるデータ駆動型ジャーナリズム(Data-driven journalism)の最前線を走っているメディアの一つなので、可視化や新しい形でのジャーナリズムに興味のある方は定期的に記事をチェックする事をお勧めします。余談ですが、日本の大手新聞社は体力的にNYTを遥かにしのぎます。しかし、彼らがこのようなデータ解析・可視化セクションを内部に持っていない事は残念な点です。彼らが統計やコンピュータに精通した人々を雇用し、純粋にデータに基づいたデータ駆動型の報道を大胆に取り入れれば、新聞にはまだまだ可能性があると思うのですが。

以下、彼のキーノートの骨子です。彼はコンピュータサイエンスの素養があるので、そういった人なら知っている各種サーチ、最短経路問題や、プリムのアルゴリズム、焼きなまし法といったアルゴリズムをメタファーとして多用しつつ説明していましたので、その辺りの知識があるとより深く彼の主張が理解できると思います。

検索問題としてのデザイン

  • デザインについて話すのは難しい。それはなぜか?結局はデザインそのものが難しいからだ。
  • 良いデザインをする事とは、すなわち失敗を避けるためのプロセス。
  • 「デザインとは検索問題である」(Design is a search problem)

    • つまり決められた時間内(締め切りまで)に最適解(=ベストなデザイン)を探すプロセス
    • ソートアルゴリズムの可視化を例として
    • 大量の経路が存在する
  • このように明確な経路を示すのは難しいので一般化は困難だが、いくつかの基本原則は定義できる

デザイン/UX設計の基本原則例

ディーター・ラムズの良いデザインの十か条 (Wikipediaより)
  1. 良いデザインは革新的である。
  2. 良いデザインは製品を便利にする。
  3. 良いデザインは美しい。
  4. 良いデザインは製品を分かりやすくする。
  5. 良いデザインは慎み深い。
  6. 良いデザインは正直だ。
  7. 良いデザインは恒久的だ。
  8. 良いデザインは首尾一貫している。
  9. 良いデザインは環境に配慮する。
  10. 良いデザインは可能な限りデザインをしない。
    • Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials. Back to purity, back to simplicity.
  • データ可視化において大切なのは、不要な「デザインのためのデザイン」を避ける事が大切。
フィッツの法則 (Fitts’s law)
  • HCI分野で用いられる法則。適切にUIデザインを行うときの指標となる数字。
  • T = a+blog2(1+D/W)
    • ここでTはユーザーが操作を完了するまでの時間。具体的には、マウスポインタを目的のポイントまで移動するための時間など。つまりその時間は、距離と対象ウィジェット(ポイント)の大きさの関数として記述できるということ。
  • 例: 小さすぎるポイントが大量にある図(3px程度。非常にクリックしづらい)
  • これはボロノイ図に変更することによって選択可能エリアが増えてUXが向上する。

デザインの難しさの理由

  • 根本的には人間そのものが複雑な存在だからだ (Humans are complicated.)
  • ゴール(つまりそのデータセットに対するベストなデザイン)はあるが、そこに到達するパスは無数にある。
  • このゴールへ至るプロセスを迷路のメタファーを使って説明。
    • いくつかのよく知られたアルゴリズムをアニメーションとして可視化
    • プリムのアルゴリズム (迷路を作成する手法として)
    • Best-first search (迷路を解く手法として)
    • デザインとは、要するにbest-first searchのようなもの。
    • 全部の可能性を試すのは無理なので、その時点で最良と思う手法を試しながら「デザインの迷路」を解く。

Design in Practice

ここからは具体例を使って説明。この「迷路のようなデザインプロセスを検索しながらベストなデザインを目ざす」と言う事を実践する手法としてのPreviewと呼ばれるNYTのチームが使っているWebアプリケーションの紹介。

Preview by New York Times Visualization Team
  • NYTでは、紙面/ウェブサイトで公開する図やインタラクティブな可視化を作成する場合、チーム全員がGitHubを経由してデータやコードをシェアする。彼らが報道に使うデータは、基本的に巨大なものではなく、公的機関から配布されているせいぜいMBのオーダーなCSV等が多い。
  • 具体的にGitレポジトリで管理するのは:
    • Makefile
    • JSON/CSVなどの形式で保存されたデータ
    • node.jsで使われるpackage.jsファイル
    • JS/CSS等も含んだindex.html
  • Gitレポジトリへのコミットは、最初のコミットを起点としたツリー構造を構築する。すなわちこのコミット履歴を可視化することは、チーム全体の作業過程を時系列データとして可視化することに他ならない。
  • NYTでのデータ可視化は、多くの場合一画面で完結するので、最新版のコードとデータをローカルにcloneして、ローカル環境のブラウザでそれを表示した場合、その画面がその時点での最新版の可視化と言うことになる。
  • GitHubデフォルトの可視化システムでは、コミット履歴を見ることはできるが、ハッシュ値、コミッターの名前、コメントくらいしかわからない。しかし、可視化の試行錯誤の過程を俯瞰するには、あるコミットの時点では、どのようなレンダリング結果が得られるのかを見えるようにする必要がある。
    これを実現しようとしたのがこのシステム。
  • Previewを使うことにより、コミット時点での可視化をブラウザで閲覧できる。時系列に沿って、「進む」「戻る」という見方ができる。

  • 実際の使用例紹介。Previewを使って、ある一つの記事を作成するのに作った可視化の遍歴を30秒の動画に。

    • 具体例で見せていたものは、グラフ(ネットワーク)図からスタートして、最終的にはアメリカの地図を使ったものに。
    • 最終的には最初のプロトタイプとは全く違った結果になっている
    • それぞれのコミット時点でスクリーンショットをタイル化することも可能。
    • 通常は、一つのブランチを一つの可視化の可能性(手法)に対応させる。
  • 外部の新たな視点を常に招き入れ、批判を受け入れよ (Get fresh eyes frequently, invite criticism.)

  • 更に2つの使用例

    • Across U.S. Companies, Tax Rates Vary Greatly
    • これの作成プロセスも、初期のものは最終的とはかなり異なる
    • 散布図から始まり、ボックスプロット等も使い、最終的にはリンク先のようなものに
    • Tracing the History of N.C.A.A. Conferences
    • サンキーダイアグラムのようなものから始まって、試行錯誤(ブランチング)しつつ最終的には上のようになった

まとめ

  • プロトタイプは早く作れることを重視して、細部にはこだわらない (Prototypes should emphasize speed over polish.)
    • プロトタイプ作成時にあまり細かいところにこだわると、そこが(サーチにおける)local minimumだった場合に時間のロスが大きい。
  • 必要ならば大胆にコードを削除せよ (Delete code as you go. Be ruthless.)
  • 全体のプロセスを再現可能なものにせよ (Make your precess reproducible.)
  • あえて悪いアイデアも試してみよ (Try bad ideas deliberately.)
  • 失敗を恐れるな

その他質疑応答でのコメントなど

  • 利用しているツールについて
    • Text editor, node.js, & D3.js
  • 「基本的にNYTで扱っているデータは、いわゆる『ビッグデータ』ではない」
  • 各種公的機関からの公開データをテーブルとしてダウンロードしたり、そうなっていないものはスクレイピングする
  • どちらかと言うと公開データのフォーマット変換やクレンジングが面倒くさい

コメント