(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情報の楽しみ方

会社のスクリプト言語が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のメモリリーク (それなりブログ)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・職探しはコネもコネ。

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

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

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

・面白いのはモバイル

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

○声がイイと言われた

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

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

○写真写りが微妙ｗ

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

以上、つらつらと。

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

» パネル限界論

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上初パネルの顧み。

お久しぶりです。

今日は秋間氏に誘われてMozilla 24のスタッフをしています。
今もなおリアルタイムにｗ

Mozilla 24ということで24時間のイベントです。ITイベントで深夜突入は初めて。

でもこのイベント。24時間っていうことで以外にも色々と面白い企画がちりばめられています。

まずShibuya.js。

言わずもがなの人気イベントのため、開始数分でいっぱいになるという。。。
当日も盛況で250人近く参加していた模様。かなり高度な話題が多かった。

でもCUIでphotoshopをイヂる、というのは圧巻でしたｗ

次にドキッ! 丸ごとウェブ!! ブラウザだらけの討論大会 ～Chatでユーザのポロリもあるよ～。

ブラウザベンダーやユーザさん同士のパネルなのですが、リアルタイムに動画を配信し、IRC（チャット）でイベントに参加できる。
ustreamの存在で一気に動画配信が身近になった感じですね。
てか会場でPC使ってあえてWEBから参加する人の多さｗ

双方向性を実現するイベントとしてはかなり質の高いイベントだったと思います。

そして今がLiveCoding。

LiveCodingっていうのはリアルタイムに簡単なプログラムを作成するシーンをスクリーンに映して、実際にコーディングを見せる、というもの。
これは23:30～3:30っていう激しいスケジュール。

たった今、はてなの神原さんがニモTVなるサイトを開発されていますｗ
最近は就活生として、コーディングから離れた生活をしていたのですが、こういう雰囲気の中にいるとなんかうずきますよね～

さあ、後はサバイバル。いつまで耐えていられるかっていう新しい感覚も味わえるイベントでしたｗ

もうIT系のベンチャーでエンジニアとして働いてきて3年目となりました。
その中で思ったことをまとめてみたいと思います。

• ソースコード管理システムは必須かと
• 逆にバグ管理システム等は使わない
• ノリが良い&&事業化に向けたフローが整っている
• エンジニアにやらされている感じをさせない
• ただマーケティング担当者が口うるさいのもプラスかも
• 社内の情報共有がしっかり生きている
• 自分がどう評価されているかを明確に”適宜”伝える
• タスクの〆切が明確
• 居眠りは推奨すべき
• 究極的に言えば少人数がベスト

■ソースコード管理システムは必須かと

そこそこ分かるエンジニアに取っては当たり前のことですが、3人以上の人がいじるとなるとこのシステムは必要不可欠。間違えて他人のコードを上書きしてしまったときの悲しさといったら･･･最近ではSVNが主流のようですね。
ただ人数が2人以下とかだったら地道な手作業UPの方が速いかもしれません。

※ソースコード管理システムとは・・・
説明が難しいのですが、ようはメーリングリストのソースコード版と例えればいいでしょうか。メーリスではメールを投げると皆に届きますが、SVNでは自分のいじったソースコードを投げると、ある場所で他の人のものと比較・合併して皆で共有するというものです・・・という感じ？

■逆にバグ管理システム等は使わない

細かいバグに追われてしまう気がしました。売り上げに直結するタスクは何なのか、優先順位をつけるという意志が薄くなってしまいがちです。ただ、大きめなシステムとなるとこういった類のツールは不可欠となります。そのような場合では、キューのように常に個人のタスクに順番をつけてやるといいと思います。

■ノリが良い&&事業化に向けたフローが整っている

ITベンチャーではノリのよさが一番だと思います。「それいいね！とりあえず、やっちゃうか」。でもそれを具現化するプロセスを持っていないと頓挫してしまう可能性が高いので、早期に新規事業のフレームワーク作りをしておくと成長後に楽かと。基本的にベンチャー社長は事業を興すために起業したわけで、そういったことは得意のはず。他の人にも共有した方が良いと思います。

■エンジニアにやらされている感じをさせない

自分から進んでバグを直すような風土が一番ですが、中々そうはいきません。その対策例の一つとして、googleでは見つかったバグを一番に直した人がamazonギフト券をもらえるという仕組みを導入しています。
また、上司や非エンジニアの人は頭ごなしにタスクを押し付けるのではなく、ちゃんとそのタスクが会社の何に貢献するか説明すると良いと思います。何事も説得＆納得が重要。会社への貢献感は大事ですが、具体的にどのように貢献しているか把握できると仕事もやりやすいはずです。

■ただマーケティング担当者が口うるさいのもプラスかも

正直、エンジニアはプロモーション等への意識が希薄だと思います。やはりマーケティングを専門にやっている人からのプレッシャーはある程度あったほうがいい。そうしないとダラダラと売り上げに直結しないようなタスクをしていまいがちに。
つまり、ある程度の「縛り」は、自由な環境の中でも必要だと考えます。

■社内の情報共有がしっかり生きている

基本ですが、進捗報告、他人のやっていること・考えているこが分かるというのは非常にプラスです。それは上司と部下の間だけでコミュニケーションが取れればいいわけではなく、他部署の人でも閲覧できると良いと思います。その人がどのくらいできる人なのか一目瞭然で、自然な競争を生むからです。

■自分がどう評価されているかを明確に”適宜”伝える

これはモチベーションの維持という点で非常に効果的だと思います。自分の行ったものに対する評価というものは気になるもので、「実装が速い」「仕事が丁寧」等の言葉をもらえたりすると自分の武器を認識し、さらにその武器を高めようと努力します。逆に怒られても、自分の欠点が分かり努力すべき部分が把握できます。（ここで努力しようとしないのはベンチャー向きでない？ｗ）

■タスクの〆切が明確

いつまでにやるべきことなのか、ダラダラを防止します。

■居眠りは推奨すべき

私は仕事中でも短時間の仮眠は非常に効果的だと考えています。ダラダラと眠い中仕事をするよりかは、30分だけ寝て次からまた頑張った方が確実にいい仕事ができる。ただ、眠る場所や時間帯は工夫すべきかもしれませんね。

★究極的には少人数がベスト

やはり小さいベンチャーはスピードが速い。何せ自分がやらないと何も進まないのでf^^;
人数が多かったらどうするか。そこはいかに少人数なチームでこなせるか工夫したいところです。例えばいじる箇所を完全に分ける等。

　　
特に個人的には、”目的意識”、”売り上げへの意識”、”少人数”がポイントだと思います。効率的な社内システムというものには昔から興味があり、生涯の課題としたいと考えています。そのため、外資コンサル・VC業界に興味があるというわけなのですが・・・

とはいえ、まだ学生の身ですし、経営をしたことがあるわけではないので、あくまで末端のキャラから見た提案だとお考えください。まだまだ至らないものもあると思いますが、書くことに意義がある！ｗ

何か「これは違う」「たしかにそうかも」等、フィードバックを頂けたら幸いです。

【関連】
東大経営の現実

【参考】
Joel on Software – ジョエル・テスト
ソフトウェア開発に必要な12に項目を挙げています。参考までに。