CIOを目指しつつの8makiのアレ

(8 free Data Visualization frameworks not only for charts [en])

相変わらずData Visualization関係で調査・開発を行っているのですが、その中でJavascriptのライブラリ・フレームワークを探す時間も多いです。

» 20 Fresh JavaScript Data Visualization Libraries

上記記事のようにまとめ記事が結構あって助かるのですが、ほとんどがCharts（グラフ）のライブラリなんですよね。Chartsも線グラフか、棒グラフか、円グラフか、、、みたいにライブラリ化される主要なグラフは8種類くらいしかなく、面白くない。
適切なデータに対して適切なVisualを関連付けるわけですから、もっと多くのVisualが考えられてもいいはず！

そこでChartsに限らない、もっと根本的にData Visualizationを扱っている有名どころのフレームワークをリストアップしてみました。

SIMILE Widgets Exhibit

MITのメディアラボがリリースしているFaceted Search用フレームワークです。HTMLを拡張したテンプレート言語を用いて、簡単にFaceted Searchと、検索結果のリッチなVisualizeを可能にしています。現在、リスト、テーブル、地図、Timeline、TimeplotといったVisualに対応しています。タブなどでVisualを切り替えられるので、ユーザーの目的にマッチした検索機能を提供することができます。

SIMILE Widgetsでは、他にもTimelineや、Timeplot、Runway(Coverflow)などのVisualもAPIとして個別に提供しています。

» SIMILE Widgets Exhibit – US President Search DEMO

ProtoVis

ProtoVisはStanfordのVisualizationフレームワークです。これは巷のライブラリと違い、グラフや地図、といった単位を1つの単位として扱わず、線や面、点といったもっと細かい部品単位でVisualを作成しています。どちらかというとProcessing.jsに近いかも。たくさんのDEMOが載っているので、それらを参考にかなり自由度の高いVisualを作成することができます。

» ProtoVis DEMO

Prefuse Flare (Flash)

Prefuse FlareもData Visualizationのフレームワークとして有名です。Prefuseは、Javaのフレームワークでしたが、今回Flashに対応しました。こちらも豊富なVisualを用意しており、SIMILE同様データ構造をしっかり設計しているので柔軟性が高く、Visualの切り替えや様々なVisualを拡張することができるようになっています。

また、Flashならでわの気持ちのいいインタラクションも高評価です。

» Flare DEMO

Style Chart

こちらは、javascriptでVisualのリクエストを投げるとサーバー側で画像を生成し、それを表示するというフレームワークです。Galleryを見る限りかなり豊富なVisualを扱えるようです。画像だからってアニメーションやアクションが行えないわけではなく、そこにもちゃんと対応しています。扱っているライブラリが少ない、レーダーチャート（スパイダーチャート）も用意している点がいいです。

» Style Chart Editor(DEMO)
» Style Chart Gallery

CanViz

有名なVisualizationフレームワークであるGraphvizのJavascript版です。主にグラフ構造のデータを描画するのに適しています。ただ、DEMOを見る限り、アニメーションやイベントの設定ができないようで、本当にVisualizeのためだけのフレームワークのようです。

» CanViz DEMO

Axiis (Flex)

こちらはAdobe FlexのVisualizationフレームワークです。インタラクティブなアクションがかなりリッチに作りこまれています。下記のBrowser Statisticsは一部で話題になりましたね。かなり自由度の高いフレームワークのようです。

» Axiis – Browser Statistics DEMO

Infovis

こちらもグラフ構造のデータ描画ライブラリとして有名です。フレームワークではないので個別のVisualを利用する形になります。グラフ構造しか扱えないのですが、この手のライブラリとしては珍しく、Weighted Graph（ノード間のパスに重みが付いている）/Directed Graph（パスに方向がある）、の描画にも対応しています。現時点で5種類のグラフ系、ツリー系のVisualがありますが、どれもよくできています。

» Infovis DEMO

RGraph

番外ですが、HTML5用のグラフ生成ライブラリも登場しています。HTML5なのでまだまだ本格導入は難しいかもしれませんが、相当クオリティ高く仕上がっており、今後が楽しみなライブラリです。

» RGraph DEMO

8maki IT, proposal, survey, テクノロジー, デザイン Data Visualization, Flash, Information Presentation, Javascript

前回、モノをある切り口で捉え、それを適切な表現方法にあてはめて考えるアイディア出しスタイルと、モノの関連データにVisualizationをあてはめるというData Visualizationのスタイルは、脳の構造・プロセスが同じで、分かりやすいのではないか、という記事を書きました。

» アイディアの発想法とData Visualizationは同じ構造なのではないか？

そこで今回は、上記事で言及している”モノとその関連データ”とは何なのか、深く掘り下げてみたいと思います。

関連データとはプロパティである

「データから自動でVisualizationを行う」という取り組みの中で、どのようにデータを扱えばよいかという問いにぶちあたり、最近RDFおよびRDF Schema、Dublin Coreあたりを調べています。

RDF とは、主語・述語(プロパティ)・目的語(値)という3要素を用いてデータの関係性を表現するWeb上の枠組みのことです。例えば、「New Yorkの略語はNYである。」という例文は下記のようなXMLで表現されます。

<rdf:RDF
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:dcterms="http://purl.org/dc/terms/alternative">
  <rdf:Description rdf:about="urn:states:New%20York">
    <dcterms:alternative>NY</dcterms:alternative>
  </rdf:Description>
</rdf:RDF>

この例で、主語・述語・目的語はこのような意味になります。↓
主語： New York というモノが存在し、
目的語： NY という関連データがあり、
述語： 略語 という主語と関連データの関連性を意味している。

これだけだとちょっと分かりにくいかもしれませんが、表は、基本的に主語・述語・目的語の構造に落とすことができます。下記は宇多田ヒカルのWikipedia Infoboxの例です。「宇多田ヒカルの出生名は宇多田光である」ということを表しています。

この構造は、前回の記事で示した、モノ⇔関連データ⇔Visualizationの構造に合致しています。

ここの述語、要はプロパティの部分とVisualizationをうまくひもづけるルールを定義できたら、「扱うデータからVisualizationを発想する」ことができるのではないでしょうか。さらに言えば、ルールさえしっかりしていれば、データとプロパティさえ定義すると自動でユーザーが求めるVisualizationを生成することができるようになります。

規格化されたプロパティの定義

ただ、適切なプロパティと適切なVisualizationをひもづけるには、プロパティの規格化が必要です。色々な人が、バラバラのプロパティ名を用いたり、統一化されていないカテゴリをプロパティとして付与したりすると、自動化が非常に困難になります。

そこでRDFでは、Dublin Coreというメタデータ記述語彙集を用いることが推奨されています。Dublin Coreには、TitleやCreatorといった15の基本要素と呼ばれるプロパティ候補があり、これらを用いることで、情報に共通化されたメタデータ、プロパティを付与することができるようになります。

さらにこれを細分化したDCMI Metadata Termsというものも存在します。DCMI Metadata Termsでは、50個以上のプロパティが定義されています。 先程の「略語」という述語（プロパティ）は、DCMI Metadata Termsのdcterms:alternativeというプロパティに置き換えることができます。

考察

このようにWeb上でデータを構造化する動きは、Semantic Webという流れの一つです。Semantic Webとは、コンピュータが理解できるように、Web上の情報に意味を付与しよう、というプロジェクトです。Data Visualizationで扱うデータをSemantic Webに合わせて構造化する方法は、現状は、割と有効だと思われます。

ただ、Semantic Webは分かりにくい上に考え方が古いので、中々浸透していません。Data Visualizationを主軸に考える場合、もっと別なデータの構造化・規格化手法を考える余地は大いにあるとは思います。

参考

こちらに、Semantic Webの概念図が載っています。コンテンツにメタデータの付与→メタデータの語彙規格化→語彙の意味把握(Ontology)→論理式を用いて結論を導く(Rules,Logic Framework)→結論の証明(Proof) という流れはいい線いっている気がしますが、先は長そうですね。

8maki IT, proposal, survey, テクノロジー, デザイン Data Visualization, Dublin Core, RDF, Semantic Web

(Data Visualization is the same as how to organize ideas [en])

先日、元サイボウズでアメリカでLUNARRを立ち上げられた高須賀さんにお会いしました。そこで、最近研究している Data Visualization について発想が沸いたので書き残します。各データの種類（スキーマ）から自動で適切な Visualization 方法を選択して表現する、という研究です。

高須賀さんのお話

「アイディアをひねり出すとき、いきなりすごいアイディアを考えるよりも、切り口を見つけてそこから発展させた方がいい。アイディアと切り口のバランスが取れた位置が一番エネルギーがある。」ものすごく簡単にまとめるとこういうお話でした。

つまり、ものごとを構造化してとらえ、ツールを使って着想を得た方がアイディアを出しやすい、ということ。

例： 新しいレーザーを考える。レーザーは点であり直進する。点の反対は面で、直進の反対は曲がる。これらを2次元グラフにプロットし、各象限に何が当てはまるか頭をひねる。面・曲がるという象限、つまりどこにおいても光を反射させ、面に映し出すという切り口から、スクリーンの前に置かなくてもよいプロジェクターというアイディアが生まれた。

このとき、切り口からアイディアをひねるために用いたツールが、高須賀さん曰く2×2というもの。要は2軸ある2次元グラフで昔私もマトリックスとも呼んでいました。構造化してアイディアを得る・まとめる方法は以下の高須賀さんの記事が分かりやすいです。

» 事業を考える切り口 – Toru Takasuka の起業・経営ブログ

» 新しい concept のはじまり – Toru Takasuka の起業・経営ブログ

松岡正剛の編集学校で教える編集術

こういった発想の訓練、実は以前にも受けたことがありました。松岡正剛の編集学校で体験授業です。

割と戦略コンサルのケーススタディ訓練に似ているのですが、MECEに限らず、もっと自由に発想する、ということが目的で楽しかったのを覚えています。そこでいただいたパンフレットに、6個のツールが載っていました。

1. Combination (一種合成型)
2つのものを合成して新しいアイディアを生み出す。

2. Triple Jump (三間連結型)
ホップ・ステップ・ジャンプ型で発想を展開。大・中・小や過去・現在・未来などの切り口もあり。

3. Branching (二点分岐型)
一つのものを2つに展開。この例ではブランドを切り口に展開した。

4. Trinity (三位一体型)
三位一体型、3点セットで考える発想パターン。3Cなどが代表例かも。

5.1 All Around (二軸四方型1)
Branching型の枝が2つ増えて、四方へと分岐する発想法。

5.2 2×2 (二軸四方型2)
2軸を決めてそれぞれのマスに何が入るか考える。マトリックス型。

※英語は勝手に私が変換したものです。

Data Visualizationとの関係

さて、本題ですが、切り口をツールにあてはめアイディアを得るという発想法と、Data Visualization は、頭の中では同じ構造で処理しているのではないか？というのが今回のパラダイム・シフトでした。

どちらも「分かりやすく考える」「分かりやすく表現する」ということで、頭の使い方が非常によく似ているような気がします。Data Visualization というと Computer Science チックですが、何か考えを図にまとめるときのことを考えると分かりやすくて、まず扱う対象があって、それを一つの側面で切ったデータ群があり、それをどう Visualize するか？というのは、高須賀さんのおっしゃる構造的な思考と同じプロセスを踏むのではないでしょうか。

普通 Data Visualization を調べる場合、どういった Visualization があるのか、どうプログラミングで表現するのか、といったことに目が行きがちになります。オライリー本の”Visualizing Data“もアルゴリズム中心の本でした。

そこを、扱うデータから Visualization を発想するというパラダイムに変換することで、おもしろい表現ができるだけでなく、説得力のある Data Visualization 手法を考案できる気がしました。

参考までに、こちらの図↓は様々なチャートを目的別に一覧表示しています。チートシートとして使うと便利かも。

» Chart Suggestions – A Thought Starter

p.s.

オフィスにお邪魔した際、VentureBEATの勝屋さんもいらっしゃいました。Blogに写真を載せてさらにリンクまで張っていただきました。ありがとうございました！最強のコネクターと言われるだけのことあって、超人懐っこいでしたｗ

» 人のつながりは無限（∞）につながる – 勝屋久の日々是々

Ben Fry, 増井 俊之 (監訳), 加藤 慶彦 定価 : ￥ 3,780 発売日 : 2008/12/01 出版社/メーカー : オライリージャパン おすすめ度 : (6 reviews) 可視化の一つの手段としてProcessingの概要を知りたい人に 情報の可視化入門 目からウロコが。。。 日本人の本より読みやすい 既存のマッシュアップAPIを使うのとは違ったWeb情報の楽しみ方

8maki IT, proposal, エンジニア Data Visualization, 松岡正剛, 編集学校, 高須賀宣

会社のスクリプト言語がPythonに統一されて、今月からPythonをメインに使っているのですが、MySQLに接続する際なぜかものすごくメモリを食う時がありました。その備忘録。

最近技術ネタが続いていますがf^^;

結論から先に書くと、MySQLdbのfetchallの部分を下記のように書きなおすとメモリリークが起きなくなりました。

sql = "SQL文"
con= MySQLdb.connect(db = db, host = host, user = user, passwd = passwd)
cur = con.cursor()
cur.execute(sql, params)
result = cur.fetchall()

↓

sql = "SQL文"
con = MySQLdb.connect(db = db, host = host, user = user, passwd = passwd)
con.query(sql)
r = con.store_result() # use_result()も可
result = []
while(True):
　　row = r.fetch_row()
　　if not row: break
　　result.insert(0, row[0]) # 初めにデータを挿入してリストの再構成を防ぎ高速化！
con.close()

» ueBLOG | PythonをつかってMySQLの巨大な結果を返すselect文を処理する
主にこちらのブログを参考にしたのですが、cursorを使わず直接connectからクエリを投げるようにしています。
大きな違いは、一度にデータを取得するのではなく、1行ずつ取得するようにしている、ということだと思います。6～9行目で取得する行を一つ一つリストに格納しています。

なお、4行目でstore_result()を使っていますが、use_result()も可能で、use_result()を使うとデータをサーバに保持しそこから一行ずつ取得するようになるので、よりメモリの消費が抑えられる、気がしますf^^;
確認していないので何とも言えないのですが。

SQLAlchemyだとメモリリークしない、と聞いて試してみたのですが、ORマッピングで導入が面倒くさそうなうえに、生SQLを叩く際は結局MySQLdbを使うようで問題は解決しませんでした。
大量のデータをMySQLに保存しそこから全文検索（エンジンはSenna）でデータを引っ張る処理を行っていて、ある特定のSQLを書く必要があったので。

参考：
» MySQLdbのメモリー・リーク – スコトプリゴニエフスク通信
» [Python] MySQLdbのメモリリーク (それなりブログ)

8maki IT, proposal, エンジニア memory, MySQL, MySQLdb, python

昨今、新しいインターフェースを採用したアプリケーションが多く出てきている印象があります。先日Blogでも紹介したGAPMINDERですが、こういった統計データをグラフ化して公開するサービスは、最近になって注目を集めている気がします。

データが溢れてしまって、次はそれを「いかにわかりやすくまとめて表示するか」に焦点が向うのは自然かもしれませんね。そこで今回は、どういったアプローチがあって、具体的にどんなアプリケーションとして実装されているのか、調べてみました。

【目次】

• ２D（プロバイダーがデータを提供）
  • 莫大なDBからデータを提供するアプリケーション
  • 関係性の視覚化
• ２D（ユーザーが自分のデータを表示）
  • Web上の描画支援
  • 脳内の視覚化
• 3D

■2D（2次元）

大きく分けて２Dと３Dの方向性があって、２Dはいかに2次元ブラウザ上でうまくデータを表示するか、というアプローチになるでしょう。２Dはさらに、コンテンツプロバイダー側のデータをグラフ化して提供するアプリケーションと、ユーザーのデータをWeb上でわかりやすく表現するアプリケーションの二つに分類できます。

■２D（プロバイダーがデータを提供）

○莫大なDBからデータを提供するアプリケーション

Wolfram Alpha（画像↓1枚目）と最近開発が発表されたGoogle Squared（to Techcrunch）は（画像↓2枚目）有名ですよね。前者は１０TBもの統計データを、検索キーワード（SQLのようなクエリ？）に応じて図を示してくれるアプリケーションで、5月にリリース予定です。あの数学アプリケーションMathematicaの作者Wolframのプロダクトとしても有名です。

一方、Google Squaredの方ですが、下記の画像を見るとわかるように、Web上の検索結果をグリッド上に表示して、それぞれの結果を比較できる、というインターフェースになっています。莫大なWebデータを保有するGoogleならではのサービスですね。Google Analyticsがアクセス解析の会社を一掃したのように、巷のバーティカルサーチエンジンを恐怖に陥れるのでしょうか。

また、先日紹介したGAPMINDERも統計データの表示なので、こちらのアプローチに入ります。

→検索エンジン系
扱うデータが膨大なため、検索エンジンの様相を呈していくのではないでしょうか？となると、データの表示は主に今までなされてきたようなグラフ化に落ち着きそうです。それよりも、検索クエリの構文とか、検索方法といったユーザーインターフェースに改善の余地が出てきそうです。

○関係性の視覚化

また、検索エンジン系のアプリケーションでは対象としていない、データ同士の関係性を示そうとする試みもあります。一番わかりやすいのはmixigraphではないでしょうか？ノードとノードがあってその間をつなぐ線があるという図は、実生活ではよく目にしますが、なかなかWeb上では目にしません。

ただ、関係性の抽出という意味では、一つ有名な領域があります。

→レコメンドエンジン系
レコメンドエンジンです。主なレコメンドエンジンは、商品同士の関連を計算して、類似商品を表示します。サイジニアのデクワス（画像↓）というレコメンドエンジンでは、ユーザーの指向から類似コミュニティを見つけて、そのコミュニティを利用して関連商品を出しているようです

。

結局mixigraphも、共通の知人や関連性の高い友人を見つるのに使うのが主な目的だと思うので、ある種レコメンドエンジンと言えますね。多くのレコメンドエンジンもmixigraphのような、ビジュアル的アプローチができる気がします。

■２D（ユーザーが自分のデータを表示）

○Web上の描画支援

Google Visualization APIは、ユーザーのデータをWeb上に表示する際に便利なAPIです。仕組みは簡単で、データを投げるとグラフの画像が返ってきます。また、Google Analyticsやなかのひと、といったアクセス解析ソフトも、ユーザーのデータをわかりやすく表示するアプリケーションと言えばこちらの分類ですね。

→API系
今後も自分のデータを簡単に、かつ分かりやすく示したいというニーズは増えてきそうですし、こういった描画支援系のサービスはAPIやASP/Saasといった方向で出てくるのではないでしょうか。

○脳内の視覚化

Mindmapに代表されるような、脳を整理するアプリケーション群です。これはこれで別エントリでまとめたいほど多くのアプリケーションがありますが、基本はツリー構造のアプリケーションですよね。個人的にはFrieve Editor（画像↓）というのがオススメです。普通のMindmapではツリー構造しか表現できませんが、こちらは多対多の関係を表現できます。

→認知系
Webに限らず、多くの形が考えられそうな領域です。スライドをインタラクティブに作れるツールとか、ワークフローに特化したアプリケーションとか、それこそ無限に考えられます。けれども、人間の脳をいかに効率的に表現するか、という領域に収まる気がするので、認知系とまとめてみました。

■3D（3次元）

上記のグラフ化と一線を画すのが、３Dの方向です。２Dの、「人間が紙の上にまとめる」という考え方が、３Dでは「人間がその中で行動する」という考え方になり、よりインタラクティブなアプリケーションが出ています。

iFree3D（to Techcrunch）（画像↑）は立方体空間の中で、Webブラウジングするアプリケーションで、サイトや画像といったアイテムを、より直観的にいじれるように３Dを活用しています。ま

た、FoxTab（画像↓）というFirefox Addonも、今開いているサイトを、３Dで表示してくれます。

→ブラウザ系
これらのアプリケーションに共通しているのが、ブラウザあるいはブラウザ支援ツールということです。より実世界に近い形でWebを動き回れたらいいんじゃないか、というのは自然なアプローチはな気がします。AR（拡張現実）も注目を集めていますし、IE vs Firefox vs その他Webブラウザ、という構図が大きく変わりそうな気配がします。

————– まとめ —————

こうみると、本当に分野横断的に色々なアプローチ、アプリケーションがありますね。とはいえ、今回まとめたものだけでも、一通りのトレンドを網羅しているように思えます。つまり、新しいイノベーティブなアプリケーションには、イノベーティブなインターフェースも必須になりつつある、ということなのではないでしょうか。

【参考】
こちらのブログ↓では、扱うデータによってでData Vizualizationの視覚化アプローチを7個にまとめています。

» Data Visualization: Modern Approaches | Graphics | Smashing Magazine

• Mindmaps
• Displaying News
• Displaying Data
• Displaying connections
• Displaying Web-sites
• Articles &  Resources
• Tools and Services

8maki IT, Web, proposal, survey, テクノロジー, デザイン 3D, Data Visualization, Google Squared, mixigraph, Wolfram Alpha, 視覚化

最近、Data Visualization（情報の視覚化）というテーマで調べ物をすることが増えました。
ようは「データをいかに人がわかりやすく、接しやすいインターフェースで表示するか？」という意味で私は捉えていますが、非常に曖昧な言葉だと思います。Infographicsも「情報の視覚化」という意味で同義な気がします。

Data Visualizationのアプローチで、最もポピュラーなのがデータのグラフ化。Googleが検索結果にグラフを表示（via Techcrunch）するようになったのも記憶に新しいですが、データ描画検索エンジンとも言える、Wolfram Alpha（via Techcrunch）も注目を集めています。

そんな中、2次元グラフの推移を動画のように再生できるようにして、時間推移をわかりやすく表現するサイトがありました。 

» GAPMINDER

デフォルトで、横軸に「一人当たりGDP」、縦軸に「寿命」がプロットされていますが、さらに横軸の下を見ると、時間軸があるのが分かります。以下で5つほど、推移をお見せします。中くらいの大きさの赤い丸が日本なので、注目して見るとおもしろいです。

↓ほとんどの国が同じような位置に。

↓欧米（オレンジ・黄色の丸）の国々が右上のほうにシフトしています。

↓日本を始めとするアジア諸国が追随しています。

↓終戦付近で、日本の寿命がものすごい勢いで落ちています。

↓高度経済成長で、日本は世界一の長寿国に。左下のアフリカ諸国の格差が目立ちます。

。実際に再生して連続で見てみるととてもわかりやすいので是ご覧ください→GAPMINDER

Data Visualization: Modern Approachesにもある通り、様々なグラフ化のアプローチが試されていますが、2次元グラフに時間軸を取り入れて時間推移もわかる3次元グラフにする、というアプローチは非常に有効なのではないでしょうか。意外に使われていないアプローチなので、取り上げてみました。

このサイト自体も、様々なデータを扱っているので、うまく使えば教育等の分野に使えそうですね。

8maki IT, proposal, デザイン Data Visualization, GAPMINDER, Infographics, グラフ

　先ほどAmazon Web Servicesから新しいサービスがBetaリリースされていましたね。

　その名も「Amazon Elastic MapReduce」
 

MapReduceというのは、Googleの検索技術を支える分散処理アーキテクチャで、ようは「処理を細かいタスクに分けて、めちゃくちゃたくさんのPCに独立して処理させることで、スパコン並の能力を発揮させられる構造」という感じでしょう。
Amazon Elastic MapReduceのDemoはこちらから見れます。 
（Demoでは、ある文章の単語出現数を計算しています。） 

MapReduceを実装しているフレームワークで一番有名なのが、オープンソースのHadoopです。
商用化など、Tech界隈で話題のフレームワークなのですが、そもそも大規模分散処理用のインフラ技術なので人目につきにくく、ビジネス界隈では見慣れない名前ですよね。

言ってしまえば、「大規模分散処理が身近に！」ということなのですが、ビジネス的にどれくらい身近になるのか未知。
そこで、ちょっと計算してみました。（ものすごい大雑把な計算ですf^^;）

———— 計算 ———–

仮に、セットアップ・維持が３人日、処理が１台のサーバーで7日かかるシステムがあったとします。

するとそれにかかるコストは、だいたいこんな感じでしょうか。

　　（セットアップおよび維持中）の人件費＋10日分のサーバー費用(AmazonEC2.small：1台とS3：1台）
　　＝3人日×4万円（人月80万円）＋（月8000円÷30×11日＋1000円）
　　≒12.7万円 

それが、このAmazon Elastic MapReduceを使うと、だいたいセットアップ・維持に1人日、サーバーを４台使って２日くらいになると思います。すると、

　　１人日×４万円＋８０００円÷30×2日×4台+1000円+MapReduce使用料：1000円くらい？
　　≒4.５万円

コストがおよそ1/3くらいになりますね。
もちろん前者の例ではAmazon EC2を使って、サーバー代をかなり浮かせているため、実質は２０万円以上かかると思います。

———— 計算 ———–

小規模な処理だとコスト削減はこれくらいですが、サーバーを数百代、数千台使う処理だと雲泥の差に なるでしょう。

かつ、これだけ簡単に使えるようになると、多くの業者がこのサービスを使ったソリューションを提供することが考えられます。
昔なら１００万円以上したECサイトの開設が、今や１０万円以下で作れるようになり、販売のビジネスチャンスが大きく広がった、くらいのインパクトにはなりえそうですね。

もちろん重要なのは、この高性能演算システムを安価に使えて何をするか、なのですが。
今は下記くらいしか用法が思いつきません。。。

• 大規模なクローリングとインデックス化が必要な検索エンジン
• 機械学習によるレコメンドエンジン
• データマイニング
• ログファイルの解析
• 科学的なシミュレーション
• 生物学的な実験

まだまだ検索・レコメンドエンジンやアカデミックな領域を出ない分野ではありますが、逆にいえばものすごいチャンスでもあるので、何か面白いプロダクト・サービスを作る会社が出てくるのに期待ですね。

もちろん弊社でもバリバリ狙っていきますがｗ

なお、MapReduceの技術的説明は、id:nayoyaさんのブログが詳しいです。

※追記　Techcrunchでも紹介されていました。

8maki IT, proposal, survey, テクノロジー, ビジネス Hadoop, MapReduce, 分散

本日は昼から研究室の先輩（Mozzillaでインターンされててこっちに来ている）と合流し、IntelやApple等のメジャー企業を周りました。

■Adobeの女性エンジニアの方とお茶

その後、ウノウの山田さんにご紹介いただいて、Adobeの方とお会いしました。
そして、Adobe San Joseオフィスの中を案内していただきました。

やはりAdobeでも個室が一人一人に与えられるのですが、それが広かった！およそ2.5m四方くらいでした。

オフィス内もさすがデザインツールの会社、細部まで凝られていておしゃれでした。様々なフォントが額縁に飾ってあるのは秀逸でした。

社内レイアウトもZ型に通路が出来てるなど、おもしろい仕組みが満載でした。Googleは郊外の大きなキャンパスというイメージでしたが、Adobeは都会のおしゃれビルって感じでした。

その後、カフェテリアで軽くお茶しました。

・家族を持つとやはり大企業がいいかも。

これは米国でも同じですね。
ただ日本は独身中心のキャリア感ですが、こっちは家族単位で物事が進むそう。男の産休とかザラ。

・こっちで留学考えるんだったらTOEFLやらないと。

奨学金を得るにもTOEFLが高いと有利とのこと。ただスピーキングもあるため、日本にいても留学生とかとつるんで常に英語力を鍛えないといけないですね。
その点うちの研究室は1/3が留学生になるので有利ですｗ

・就職するなら景気を読め。

これは就職の本質だと思いますが、やはり不景気のときより景気の良いときの方が就職のうまみが大きいということです。
これから少なくとも2,3年は米国も日本も危ういので、留学して時間稼ぎもありだよねーっていう話をｗ

・こっちで起業するにしろ就職するにしろビザが問題

ここでも出ましたビザ問題。
こちらに進出する場合、圧倒的な日本企業のスポンサーが必要のようで、そういう意味では大企業に入りこちらに派遣というやり方が一番手っ取り早いかもしれません。
他にも、未踏のスーパークリエイターの方は経産省がバックについてくれるという話も聞いた事があり、色々な手法がありそうではありますが。

雑感：
こちらの日本人女性は個性的というか、芯が強くActiveです。
もちろん日本でも仕事をされている女性は多いですが、こっちは家族単位、つまり働きながら、色々な活動をしながら子育てがしやすい環境なのだなぁと改めて実感。

実際、生活も訪れたことのある他のどの国よりもしやすいです。

8maki IT, proposal, エンジニア, シリコンバレー, 海外 Adobe, シリコンバレー

この日は午前中、残してしまった仕事をして、午後はGoogleのエンジニアの方に訪問しました。
ちょうど毎週金曜のSocialization Eventだったらしく、Familyやら色々な方がいらっしゃいました。

■Googleのエンジニアの方とmtg

・職探しはコネもコネ。

転職ありきのこっちではreference・人との付き合いは大事。
referenceとはレジュメに書く、他人からの自分の紹介。
前職のボス等に、自分はどういう人間か、どんな功績を残したかを書いてもらうケースが多いみたいです。
逆に敵を作ってしまうとその会社に入れなくなるということもシバシバ。

・4年もいると長いねと言われる。

こちらの方は3,4年周期で転職を考えられているようです。
もちろん大企業を見れば10年戦士もざらにいらっしゃるようですが。

・面白いのはモバイル

日本にもiPhoneが上陸しましたが、こっちでのiPhone熱は異常ｗ
異常というか、iPhoneにより米国のモバイル事情が一気に変わるという見方が濃厚のようです。
未だにモバイルよりPCの普及率のほうが高い米国で、これからコンテンツとしてのモバイルが面白いし、変化をもたらすべき領域だと感じました。

・やっぱりGoogleはエンジニアにとっていい会社だよ

直前に、グーグル、豪華な福利厚生の大半を廃止へ――同社を去る従業員が増加 という記事を読んで、どんなもんかと思っていたのですが、相変わらず好きなことができて、優秀な人が多いこの会社はエンジニアにはとても良い会社だと思いました。
（この記事についてはお聞きしませんでしたが。。。）
この方に限らず、こちらの人のGoogleの評価は未だに非常に高く、「そろそろ落ち目なんじゃね？」という見方も昨今見られますが、そんなマクロ的な分析とは関係ないみたいですね。

※chromeのリリースによるWEB包囲網戦略は、Googleの成長を見る上で重要なポイントですね。

その後Googleキャンパスをうろうろしたのですが、とにかく広い！
数十の建物が散在していて、全て車で回るのも一苦労でした。
朝とかはGoogleに行く車の列で渋滞するそうなｗ

8maki IT, proposal, エンジニア, シリコンバレー, 海外 Google, シリコンバレー

ということで以前告知したイベントの詳細がCNetに上がっていました。

» IT業界でキャリアアップするとはどういうことか–業界人が議論

初めてのパネルだったのでちょっとばかし感想＆反省を。

○全く準備が無かったのでテンパった

運営者の方を批判するわけではないですが、何も考えずに臨んでしまいました。
結果、ろくな発言をしておりませんf^^;（記事を見ていただけるとわかりますが）

面接だと自己PR、志望動機、長所短所など準備していけるので対応が可能なのですが、いきなりの質問に対して即答するのは至難の業でした。

ですが、他のパネラーの方はこれぞという発言をされていることもしばしば。
やはり人生哲学（今回の場合エンジニア哲学）を確立しているとすぐにアウトプットが出せるようです。

私も今まで考えることに関しては自信があったのですが、圧倒的な経験不足を思い知らされました。

○学生だからと尻込んでしまった

これは今回で一番の反省です。
上記の状況から、途中ろくな発言ができていないことに気づき尻込んでしまいました。

どうせ学生の言うことなんて浅く参考にもならない、だろうと。

○学生だからという地位を活かせなかった

つまり、これは学生という地位をうまく活かせなかった、とういことです。

学生なので企業のしがらみは全くありません。
ですのでかなり好戦的な発言をしようと思ってはいたのですが、やはり「キャリア」の話になると全くキャリアなんぞ歩んだことの無い私はツッコみどころをその場で探すことができませんでした。無念。

※後半からは逆に開き直って思ったことを素直に言うようにしましたが。

○声がイイと言われた

うれしかったので載せますｗ

そもそも面接やプレゼンなどで緩急をつけることで、人をひきつける話方というのを意識しているので役に立ったのか、な？

○写真写りが微妙ｗ

微妙！慣れてない感が･･･

以上、つらつらと。

またタイムリーにも田口さんがパネルについてのエントリーを書かれているので参考にしたいです。

» パネル限界論

———————————————————
ついでなのでCNetに上がっている自分のコメントを取り上げます。

「コーディングできなくても会社は成り立つけど、社長がコードを書ける会社は元気な印象があります」

ウノウとかはてなとかですよね。エンジニアが生き生きしている会社って。
やっぱり技術系の会社を見ると社長が(元)エンジニアであることが多いと思います。

それはエンジニアの気持ちっていうのはエンジニアをやってみないとわからん、ていうのが僕の自論です。

でもそれは竹岡さんによると「生き生きしていると思わされているだけ」と。

これは一見相反する意見ですが、本質は一緒で僕のはある程度の待遇があった上での”生き生き”です。
もちろん給料は無いけどカリスマエンジニア社長についていきます！系は生き生きとは呼べないと言う点で同意。

「考え方として、お客様に対する仕事はすべてサービス業だと思います」

これはそもそもサービス業だの製造業だの分類は議論として無意味だと思ったのであっさりスルーしただけの発言ですねf^^;

「やりたいことをやりたいですが、収入の最低ラインは維持していたいですね。ITや環境を変えていけたらいいなと思います」

これは今のIT業界は賃金の最低ラインさえ維持されていない、と学生に思われている、という僕の発言からのものです。
給料が低いと言うか、労働分の給料に見合ってない、と”思われている”と。

ただこれは実際のところどうなのでしょうか？
僕が学生代表と名乗りにはあまりにもIT業界を知りすぎている気がします（うぬぼれ）

「まだ学生の私が言うのもなんですが、私は『穴掘り』を極めたんです（笑）。子供の頃ですが、庭に穴を掘って自分の背丈まで掘れたら成功という。極めたことで、どこを掘ればいいのかという場所選びや、最後までやり抜くことなどを学びました。たぶん、これはすべてのことに共通すると思うんですよね」

ウケ狙いのためスルー。でもこれで場を持っていくことができたｗ

「よく人の多いところは『渋滞する道』に例えられますが、人と同じことをせずに別のルートを探る、開拓していくことも重要です」

まあうん。そんな感じ。もっといいたとえをしたつもりだったんだけどなーｗ

以上初パネルの顧み。

8maki IT, proposal, survey, イベント, エンジニア, 八巻 パネルディスカッション, ミリオンタイムズスクウェア