このとき、コミュニティーエンジンには女性のプログラマが数名いる
という話をした。いまはプログラマ30名弱に対して3名だ。
これはかなり多いほうらしい。師が率いるチームでも、
20名に1名しか居ないが、それが普通のようだ。
プログラマや料理人は男性が多いのは何故か？
私は、「10年ぐらい1つのことに没頭してる女性は、とても少ないと思う。」
「とくに日本の働き盛りの世代では、「女のくせに」と言われて育った人も多いはず」
と話していたが、関連する話が紹介されていた：
自分の場合は、高校時代までは1日2時間で10年ぐらい、
大学に入ってから起業するまでは1日3〜4時間で10年ぐらい、
起業してからも同様で5年ぐらい、プログラミングに没頭する時間があった。
これまでの合計では2万時間とちょっとぐらいだろうか。
自分の知識がプロとして通用するかもしれないと感じはじめたのは、
起業する2〜3年前ぐらいだから、やっぱり1万時間が必要だったと言って良い。
以前から、私は、
知識の量が創造性を決めると考えている。
「どれぐらいの量が必要なのか？」と問われたら、
「1万時間同じことに没頭する程度」といって、
だいたい間違いないのかもしれない。
1万時間というのは、「知の高速道路」ができたら、短くなるのだろうか？
私はそうは思わない。必要なのは、知識の絶対量ではなくて、相対量だからだ。
いまある社会では、同じことに興味をもった人のうち、
1万時間没頭できる人が、仮に100人に1人しかいないとしよう。
プロの仕事が成立するというのは、いままで利用可能な知識の取引システム
（ようするに企業に就職するとか起業してサービスするなどの社会システム）
の中では、100人に1人程度の際だった希少性をもっていないと、
取引可能にならない、つまりプロにならない、という意味でしかない。
だから、Webが発達して、知識の取引システムが進化し、
10人に1人とか3人に1人程度の稀少さでも取引が可能になったら、
1000時間の没頭でもプロ（知識を売ってる）になれるし、
ごく短時間の没頭で極められるようなごくごく小さな領域に特化した
知識でも取引可能になっていく。
だからWebの影響があるとしたら知の高速道路ではなく、
取引システムの改善のほうだ。
googleのknolなどはこの取引市場を見ているのだろう。
さてここからが本題。前置きがとても長かった！
「社員にとって有益であるような会社であってほしい」
という当たり前だが重要な願いがある。
日本の大企業につとめる友人がよく言うのは
「自分の会社はプログラマを大事にしてない。」という事だ。
どうしてこうなるのか？ 彼らはかなりよい待遇を得ている。
どの会社に行ってもよい待遇が得られる人がこれを言う場合には、
待遇のことを言ってるのではないことは明らかだ。
残る部分は、仕事の内容、プロフェッショナルの中身そのものだ。
彼らの多くは、会社に入る前に1万時間を経過し終わっている。
会社に入ってからは、配置換えや昇進などによって、
同じことに集中する時間を与えられていないために、
自分のプロフェッショナルの内容をさらに高めたり、
これまでとは違う分野で1万時間をすごしたり、といったチャンスが無いのだ。
「長期間同じことに没頭できる環境」を用意することが、
プログラマ（というよりプロフェッショナル）の益につながると考えられる。
そもそも、何事かに没頭しているときは、脳の報酬系が強く働き、
ドーパミンが放出され、幸福な状態になっている。
この時間が長いことは、益そのものであると言って良い。
これを実現するためには、
* 経済的に長期間安定した基盤を持つこと
* 会社の人数に比して多角化し過ぎないこと
* 配置換えや昇進について基準を持つこと
などが必要だろう。
どれも、具体的な企業努力で、実行していけるものばかりである。
技術を売ることを中心とした会社を運営していくのならば、
これらについて考え方を持っておく必要があるが、
1万時間という量から考えていけば、
具体化の仕方も逆算できるというものだ。
ちなみに冒頭のエントリの最後に「没頭しやすい性格はDNAかも」とあった。
企業努力として、没頭するのが得意な人だけ採用する、
ということも追加可能で、そのときには「これまでに1000時間以上
没頭したことがある対象は何？」というような質問ができるのかもしれない。
彼の答えに新しい部分は無かったのだが、ひとつの発言が印象に残った：
「EC2の上にGoogleを載せることができる」という発言だ。
これは計算してみるしかない。
EC2の価格リストはここにある：
早速計算開始。 当然だが、私はGoogleの当事者ではなく野次馬だ。
なので内容は当然正確ではない、あしからず。飲み屋のネタにしてください。
さて、adsenseなども入れるとGoogleは1000億クエリ/month (100G q/month)
をこなしている。
1クエリの処理に0.3sec, マージンを適当に入れて0.5secかかるとしよう。
またoutgoing trafficは、1queryで5KB送信するとしよう。
incoming trafficは無視できるので、outgoingは1queryあたりHTMLのサイズを
計測してみたが、5KBとして良いだろう。
1ヶ月は2.5M秒あるので、Googleは1秒あたり
100G/2.5M = 40K query/sec
処理してることになる。多いなあ。
合計では、出力に必要な帯域は、40K * 5KB = 200Mbytes/sec。
CPU時間は1秒あたり 20Ksec必要なので、1秒に2万秒必要。
utility rateを高くしたとしても、インスタンスが5~10万個必要。10万とする。
クローラ用に1000インスタンス、インデクサ用にさらに
1000インスタンスだがこれは誤差として無視する。
インスタンスコストは、instance/hour high-cpu medium $0.2
なので1時間に2万ドル、１ヶ月に1500万ドル必要となる。
次は、サーバに入っていく帯域を見てみる。単価は：
$0.100 per GB - all data transfer in
クローラは帯域を消費する。100億ページを毎月10回づつ取るとすると、
1000億get, ほとんどheadリクエストだが大きいページもあるので15KBとすれば、
100G * 15KB = 1.5PBytes なので、1.5M * $0.1 = 0.15M$ 毎月15万ドル。
インスタンスにくらべて安い。
次はサーバから出て行く帯域。 単価は：
$0.170 per GB - first 10 TB / month data transfer out
$0.130 per GB - next 40 TB / month data transfer out
$0.110 per GB - next 100 TB / month data transfer out
$0.100 per GB - data transfer out / month over 150 TB
月間1000億クエリ * 5KBだ。
100G * 5K = 500TBなので、 $0.1 per GB が適用される。
500K * $0.1 = 50K 1ヶ月に5万ドル。安い。
ストレージも必要だ。
$0.15 per GB-Month of storage used
100億ページを10倍に圧縮して保存している。
平均して10バージョンづつ置いていれば、ページサイズを15KBとすれば
10G * 0.1 * 10 * 15KB = 150TB
150TBのログと格闘するには最低5倍の容量が必要なので、 1PB
とすれば、 1M * $0.15 = $150K 毎月15万ドル。
インスタンスに比べると誤差に近い。
一説によるとストレージに関してはGmailが飛び抜けて大きいという。
1億ユーザが平均して100MB保存しているとすれば(大きすぎだろうが)、
100M * 100M=10PB となり、毎月150万ドル追加。165万ドル。
次はストレージへのアクセス量だ。単価は：
Data Transfer
$0.100 per GB - all data transfer in
$0.170 per GB - first 10 TB / month data transfer out
$0.130 per GB - next 40 TB / month data transfer out
$0.110 per GB - next 100 TB / month data transfer out
$0.100 per GB - data transfer out / month over 150 TB
Requests
$0.01 per 1,000 PUT, POST, or LIST requests
$0.01 per 10,000 GET and all other requests*
毎月、100億ページを10回DBに保存し、同量読むとする。
圧縮率は10%実際にはこんなにひどくはないはずだが。。
だとすると、DBからの出力は、10G * 10 * 1.5K = 150TB
150K * $0.1 = $15K 1.5万ドル/月
DBへの入力も同様。合計3万ドル/月
PUTが100G回。よって、100G / 1000 * 0.01 = $1M毎月
GETも100G回。よって、100G / 10000 * 0.01 = $100K毎月
合計すると、
インスタンス=毎月1500万ドル
in帯域=15万
out帯域=5万
ストレージ量=165万
ストレージアクセス=1.5万+1.5万
ストレージクエリ数=100万+10万
合計=1850万ドル/月
毎月1850万ドル(年間200億円程度）あればGoogleの大部分をAmazon EC2の上にのせることができる。
もちろんそれを実現するためのソフトウェアがあればの話だが。
Googleの決算資料を見てみる。
Operating Expenses - Operating expenses, other than cost of revenues, were $1.25 billion in the third quarter of 2007, or 30% of revenues, compared to $1.21 billion in the second quarter of 2007, or 31% of revenues. The operating expenses in the third quarter of 2007 included $659 million in payroll-related and facilities expenses, compared to $625 million in the second quarter of 2007.
Googleは四半期に3600億円売り上げて、人件費や設備のために600億円使う。
このうち設備費用がいくらかは明らかになっていない。
全部のサービスを実現するために、毎年200億円をAmazonに支払い続けるよりは、
自前で自社サービスに特化した設備を維持するという判断を現状はしているのだろう。
あるいは、最もコストがかかるインスタンス部分のコストを圧縮するために、
検索専用チップを作って出し抜こうと考えているか。
今後、amazonが数千万というインスタンスを販売することになって、
そのコストダウン効果がGoogleが自社でできる範囲を超え始めたら、
また状況が変わるのかもしれない。
今度Googleの人に会ったら、これを計算してみたことはあるか？
と聞いてみよう。
昨日、私が私塾の師としている人と飲むことがあったのだが、
そのときに「経営者タイプ」と「プロデューサータイプ」
という傾向の名前がでた。
彼はこう言う。
「中嶋君はプログラマからプランナーになったところだね。
プランナーの次はプロデューサーか、経営者か、
どっちを目指すのがいいんだろうね。」
プログラマというのはプログラムを書く人だ。
プランナーというのはどんなプログラムを書く必要があるか知った上で、
ゴールへの到達方法を考える人だ。プランナーのゴールの単位は「製品」だ。
だから「製品プランナー」と言ってもいい。
コミュニティーエンジンでは、エンジニアにはこの両方の仕事を期待している。
多くの小さなソフトウェア企業では基本的にそうだろう。
私自身もそのような仕事をしてきたと考えている。
師に、プロデューサーと経営者の違いは何かについてたずねた。
するとこういう意味であるという。
世の中をこうよくしたいとう最終結果Xがあるとする。
Xにはたとえば貧困をなくすとか、病気を無くすとか。
私自身ならば人間の創造性を拡張したいという願いがある。
Xを実現するためには、何らかの手段Yが必要だ。
XのためならYはなんでも良いとする人が経営者、
かなり狭いYを決めてそれでXがいかにして可能かを考える人が
プロデューサーであるという。プロデューサーにとってはXは自由だ。
まとめると、最終結果を固定して手段を柔軟にするのが経営者。
手段を固定して最終結果を柔軟にするのがプロデューサーだ。
彼から見れば、たとえばGoogleでは創業者2人がプロデューサー、
シュミット氏が経営者で、シュミット氏は自分が持っている最終結果に
2人が持っている手段が現時点では合致すると
分かったから参画したのだろうという。
任天堂の岩田社長や久多良木氏はプロデューサー、
スクエニの和田社長は経営者であるという。
アップルのSteve Jobsも、「箱に入ったコンピュータ」
という手段を片手にいかにして最終結果を実現するか、
最終結果を固定せずに考えているように見える。
どちらがいいというのではない。どちらの立場でも、
素晴らしい最終結果を出すことはできるのだ。
この2種の人々は相互に補い合うシステムを作って活動し、
最終結果を実現することができるからだ。
成功している組織では双方のタイプの人が活躍しているのだ。
最終結果をとことん考え続けるのと、手段をとことん考え続けるのと、
両方が必要であることは明らかだ。
どちらか一方だけを選ぶ必要があるというのではない。
スタート地点では補完関係が弱いから、両方を自分でやる必要もあるだろう。
時間と経験が経過するなかで、より自分に合ったほう、好きな方を
選択していくだけだ。
ひとつ言えそうなことは、手段と目的の両方を同時に固定すると、
固定している部分が多すぎて、可能な仕事の範囲が狭まりすぎ、
結果として何も実現できない確率が上がるかもしれない事だ。
たとえば、計算機とネットワークという手段と、
創造性を拡大するという最終結果の両方を固定してしまうのは、
狭くしすぎな可能性がある。
どちらかを自由にしておいたほうがいいかもしれない。
これについても今後考えたいが、まずいまは置いておく。
さて、自分にとってどちらが向いているのかを考える。
私は幼少時代から、計算機とネットワークという手段に魅せられ、
これまでの20数年間、没頭をしてきた。
これについて何の後悔もしていないし、
たぶん今後も没頭を続けるのだろう。この手段が気に入っているのだ。
ある手段に関して、膨大な時間的投資をしたのだから、
そのぶん、自然と、ほかの事には習熟していないのだろう。
「人間の創造性を拡大する」という最終結果に対して、
経営者であれば、学校や教育法を作るとか、知育おもちゃを作るとか、
未踏ソフトウェアのような投資活動をするとか、結果を最大化するための
さまざまな手段について考えをめぐらす事になる。
プロデューサーであれば、計算機とネットワークという手段を活用し、
高めながら、いかにして創造性を拡大するか、
あるいはほかの最終結果を出すことが可能かも含めて考えていく。
師は「中嶋君は経営者よりプロデューサーを目指すのがいいかもしれないね。
エンターテインメントやものづくりの業界は、
プロデューサータイプの人が大きな結果を出しやすいフィールドだと思うよ。」
と言っていた。
人生の金言とは、こういう言葉のことを言うのだ。
すぐに結論を出す必要は当然ないが、
やっぱり今日も、計算機とネットワークについて、
とめどなく探求している自分に気づくのであった。
ひとと話をしていて、創造性がある！と感じるのはこんなときだ：
A 多数の事の裏にある、誰も気づかない共通点に気づいてしまう。
B あるひとつの事のはるか先にある、誰も気づかない帰結に気づいてしまう。
どっちも根っこは同じだ。
少なくとも私のまわりの創造性豊かな人たちは同じ根を持っている。
以下、その仕組みを解説する。
まず人間は、多段階の関係を記憶することができる。
エンジニアならこんなことを最初に習うかもしれない。
C言語→中間言語→アセンブリ→中間言語→x86バイナリ
この関係に関する知識を抽象的に表現すればこうだ。
A→B→C→D→E
しかし知識があればC言語を生成する前段階の軽量言語を知っているかもしれない。
またx86バイナリコードの次にくるマイクロコードのフォーマットを知っているかもしれない。
あるいはさらにプロセッサコアのブール代数処理系の構造を知っているかもしれない。
多くの人が知っているように知識というのは途方もない奥行きがある。
→A→B→C→D→E→
左端と右端は通常は閉じていないのだ。
だから自分が知っている関係の鎖は、とても長い鎖の、ごく一部でしかない。
一方、人間は関係を多数記憶することができる。
文献によってその数は100億とも何十兆とも言う。
まあとりあえず多くて数えにくいのだろう。
ほとんどの人が A→B→C D→E→F という知識を持っているようなときに、
X→A と X→D という関係性についての知識を持っている人がいる。
その人はAとDの共通の根っこを簡単に見つけ出すことができる。
あるいは、F→G→H という知識を持っていたら、
簡単にD→・・・→H を想像できてしまう。
ひとはこういったことを見ると「創造的である」と言うのだ。
知識の量がある水準を超えると、急激に創造的になったように見えるのだ。
これとパーコレーションの現象は無関係ではない。
「常識のない若者にしかできない創造があるではないか」これは反論にならない。
常識のない若者にしかできない創造は、もちろんある。
しかしこれは、若者が物事を知らないことによるものではなく、
バランスの悪さに起因するもののみである。
つまり、バランスよく問題解決にあたる技術を体得してしまったひとが
絶対にそうしないようなやりかたで、世界のごくごく狭い範囲の問題について、
徹底的かつ執拗かつ異常に、長時間、膨大なエネルギーをかけて
知識を吸収してしまうことができるからなのである。
しかしその分、世界のほかのほとんどの部分に関する知識は著しく欠ける。
私がこれまで見てきた創造的な若者はすべてこの場合に含まれる。
単純な無知は創造につながらないのだ。
現時点では、私は無知による創造性を信じない。
]]>以下、2008年更新分をコピーしておく。
------------
私は、2007年の目標を以下のように置いていた。
「私に関わっているすべての人の潜在能力が100%発揮されるために、必要なことをすべて実行すること。」
これは、普通に考えると1年で終わるような事ではないし、実際に終わっていない。
「終わっていない」とはどういう事だろうか？
まず去年は、「人の潜在能力が100%発揮されている」とは何なのかを、特に考えていなかったようだ。
だから、終わったのかどうか、どの程度実現ができたのか、いま、ふりかえって評価することができない。
2008年は、これを評価可能な状態にして取り組みたいと思う。
「人の潜在能力が100%発揮されている」こと自体が良いかどうかについては問わず、
まず評価基準を考えてみる。この目標に何らかの意味があったかどうかは、
評価結果が出ればより深く考えることができる。
「人の潜在能力が100%発揮されていない状態」をできるだけシンプルに定義するならどうなるか。
まず何もしない状態と、何かをしている状態があるだろう。
何もしないとは、何かをただ待ってぼーっとしている状態だ。
これはかなり正確に能力を発揮してないと言えそうだ。
次に何かをしている状態はどうか。必要なことをしてる時と、そうでない時がある。
必要ないことをしてる状態でも、これは後になって考えたらやっぱり必要だった、と言えるかもしれない。
ムダや失敗からうまれる発明も多いはずである。
また必要なことでも、それを限界速度よりも遅くやってる状態は、能力を発揮してないと言えるだろう。
ただし、これは実は待ってる状態の派生に近いのではないか。
このように考えると、自分のまわりの人が、自分や他人を待ってる時間を最小にすればよい、
という評価基準で、評価することが可能なのではないか。
まずは、これでいってみたい。
これはどこかで聞いたことがある・・トヨタ生産方式の要素である。
トヨタの待ち時間最短理論は、自動車ならではの平準化された販売が
基本システムとして必要なので、同じ考えはそのままでは通用しないだろう。
というわけで今年は、自分たちの業態に合った待ち時間の評価方法を考えて、
それを最小化することをやってみたい。
ビルドの待ち。欲しいドキュメントが見つからない待ち。
バグによるblocking。要望に対応する時間の長さとか、会議のやり方とか、
営業における提案活動のやり方とか、仕事の中に、待ち時間は山ほどある。
改善できることは山ほどありそうだ。
その本に基づいて考えたエントリなので、
できれば読んでからもういちど見ていただきたい。
本書の後半に、「心の理論」の再帰レベルについて切り込んでいる部分がある。
これは本書の核心部分である。
>レベル 0 「高野は計算機の中に心が作れると信じている」
>レベル 1 後藤は「高野は計算機の中に心が作れると信じている」ことを知っている
>レベル 2 小島は「後藤は「高野は計算機の中に心が作れると信じている」
> ことを知っている」かどうか疑っている
>レベル 3 佐藤は「小島は「後藤は「高野は計算機の中に心が作れると信じている」
> ことを知っている」かどうか疑っている」ことをばかにしている
>レベル 4 松田は「佐藤は「小島は「後藤は「高野は計算機の中に心が作れると信じている」
> ことを知っている」かどうか疑っている」ことをばかにしている」
> ことを気にしている
・・・
チンパンジーはレベル2まで、人間でも普通はレベル4までしか理解できないという。
人間は文字やツールなどの道具を使えるので、
時間さえかければ無尽蔵なレベルを扱うことができるはずだが、
脳の機能を問う場合には、外部のツールを使わずに処理できる限界が問題となる。
「空気を読めない人」という日本語があるが、この言葉は、
「レベル３や４がすぐには理解できない人」なのかもしれない。
これは容易にテストできる。実際、多人数に対して理解度のテストをして、
人間はおよそレベル4だ、という結果が出ている。
人間の能力はおそらくつりがね状の分布をしているのだろう。
有田氏は、このレベルが高ければ高いほど「良い」のか？
どのレベルが最適なのか？ について疑問を抱く。
まず心の理論を計算機の中でシミュレートするには、仮想空間にロボットを入れる。
ロボットは狭い空間の中をできるだけぶつからずに目的地に到達しなければならない。
> レベル0のロボットは、目的地までまっすぐに行こうとする。
> レベル1のロボットは、他のロボットがレベル0であると予想して、他のロボットを避ける
> レベル2のロボットは、他のロボットがレベル1であると予想して・・
というように物理的な挙動にモデル化してしまう。
この結果が面白すぎるのだが全部を書くと本を買う意味がなくなるので
その結果だけを述べると「ロボットの視界の広さ」がすべてなのである。
どの「心の理論」のレベルが最適なのかは、視界の広さによる。
考えてみれば当たりまえのことだが・・いざ言葉になると、おどろいてしまう。
さらに、視界の広さが極端に狭かったり広かったりすると、レベル2が最適、
とかある値に落ち着くが、視界の広さがちょうど良いと、
レベルが高ければ高いほど良くなる。
人間の視界の広さだと、レベルが高ければ高いほど良い、
という結論になる可能性が高いという。
実際、このレベルは、これまでの人類の歴史を通して、じわじわと進化してきているという。
引用が長くなった。
さて、この理論の結果をwebシステムに応用することを相変わらず考える。
gumonji MMO版の運営でわかったこととして、
1. 十分に土地が余っているときは、みんな好き放題遊ぶことができるが、
ほぼ個人的な営みや、ランダムな営みに終わる。
2. 余剰の土地が無くなってきたら、みんな遠慮しはじめ、行動が減ってしまう。
3. ちょうどよい状況のときは、良いコラボレーションが生まれる。
以前MMO版を運営したときは、1から3を経由して2に至ってしまった。
2に至る原因は、人数の増加と、各プレイヤーの行動の蓄積だ。
ロボットによるシミュレーションは、以下のような結論になるという。
a. 視野が大きいと、あまり避けないレベル0やレベル2が多くなる。（最適）
b. 視野が小さいと、大きく避けるレベル1や3（奇数レベル）が多くなる。（最適）
c. 視野がちょうど良いと、無限に進化し続ける。
a. のあまり避けないというのは「好き放題でランダム」に対応し、
b.の大きく避けるのは「遠慮して行動が減る」に対応すると思う。
人間の認知能力に限界があるならば、
人数（人口密度）の増加は視野の縮小を推進するかもしれない。
仮想空間の中でちょうどよいコミュニケーションが産まれるようにするために、
プレイヤーの人口密度を保つだけでなく、
ゲームシステムやゲーム内のコミュニケーションツールの仕組みを
あるプレイヤーが見える範囲という観点から整理してデザインし直せるかもしれない。
多分ひとつ言えるのは、プレイヤーの視野の広さを1個に決めるのではなく、
あとで調整できるような設計にしておくことが肝心である、ということかもしれない。
それを実現するには、基本的には、プレイヤーの行動に関する情報を
可能な限り記録して検索可能な状態にしておくが、
その量は圧倒的に人間の処理能力を越えているようにする
（1プレイヤーあたり数GB以上など）。
そのうえで、必要な情報を探し出すフィルタを用意して、
その時点で適切な視野を与える。このフィルタがデータベースの層と
綺麗にわかれていて、あとで修正しやすいpluggableなものになっていて、
状況にあわせて動的に調整可能であるなら、
初期にデザインを確定させるという危険を冒さなくて済むかもしれない。
このソフトウェアは、テキスト入力における
「情報のプロクロニズム」を実現するための1歩として開発された。
TypeTraceがどのようなものなのかを知るには、
体験するしかないので、ここでは説明しないが、
TypeTraceによるテキスト年賀状がここにある：
HappyNewYear
TypeTrace開発メンバーであるドミニク氏から頂いたものだ。
私は、TypeTraceがリリースされる前から、アルファ版を使い、
1万文字を越える雑誌記事の執筆のために使っていた。
私は、その作業を通して、いくつかフィードバックをするなど、開発に協力をした。
TypeTraceを使うことによって、いままで計算機を使って入力された
テキストが失っていた情報が、完全ではないにせよ、保存されていることがわかった。
そして何よりも大きな収穫は、「情報のプロクロニズム」の考え方が、
テキスト入力以外の様々な領域に広げて使うことができることがわかったことだ。
TypeTraceを使って書いた、情報のプロクロニズムに関する記事が、
近々、雑誌において公開されるので、それが公開されたらまたお知らせをしたい。
TypeTraceは現在はMacOS用だが、web版など今後は広がりを見せるに違いない。
今後が楽しみなプロジェクトだ。
まず、ロールモデル思考法は結局のところ、
「巨人の肩の上に立つ」ということだ。
技術や文化に関する知識だけではなく、人間の行動パターンにおいても、
巨人の肩の上に立つことが可能であり、価値がある、と梅田氏は言っている。
技術や文化に関しては積極的に本を読んだり美術館に行ったりして
積極的に取り入れる（マネをする）するような人たちでも、
何故か、人間の行動パターンについてはマネをすることを嫌がるときがある。
これは「人間の自由意志」という妄想を信じすぎているからかもしれない。
行動パターンにおいても巨人の肩の上に立つべき、という事については、
私も梅田氏と同意見である。自分の周囲の人にもそれをすすめてゆきたい。
実際に肩の上に乗るには何が必要か？
まず最初にすべきこととして、「他の人の行動をみて、
「良い」と肯定的な言葉を発する」ことが必要だ。
これは、やると決めて練習すればできる。
この次に、以下の要素をチェックして、自分の現状を観察することができる。
＊自分より若い人の行動パターンをマネしたことがあるか？
＊自分よりキャリアの短い、経験の浅い、実績のない人の行動をマネしたことがあるか？
＊異業種の人の行動パターンをマネしたことがあるか？
＊同業でも、職種が異なる人の行動パターンをマネしたことがあるか？
＊外国人の行動パターンをマネしたことがあるか？
＊部下のマネをしたことがあるか？
このように具体的なチェックリストを作って、
自分がどの程度他の人の行動パターンを日常的に
取り入れることができているかを測定することができる。
このリストは、必ずしもその通りにすべき、というリストではない。
現状を把握して自分を観察し、自分にあった変え方を見つけるためバロメータだ。
Bittorrent日本法人の方々に加えて、
テレビ向けコンテンツを作っている人、
大手電機メーカーでP2Pやデータベースの研究をしている人、
携帯電話向けP2Pミドルウェアを作っている人、
VoIPの研究をしている人、ベンチャー投資家の人、
オンラインゲームメーカーの人、
超有名ブロガーなど
合計15名ほどの参加だった。
今回はツアー第一回だったが、次回以降は、
アリエルネットワークス社やヨシダカマガサコ社など、
国内のP2P企業へ訪問する予定だという。
私たちコミュニティーエンジンも数ヶ月先には
P2P企業になる予定なのでいずれ訪問を受けたいと思う。
訪問先の企業だけでなく、参加者同士の会話が非常に面白いので、
興味ある方はぜひ参加されたら良いと思う。
昨日は、申し訳ないことにBittorrent自体についての話はあまり多くなかった。
印象的だったのは、動画配信やソフトウェアアップデート以外の用途を
いかに探すか？ というのが主な課題意識だったことだ。
Torrentの特徴を活かした用途として、この次にThin Clientを実現するために
OSイメージ自体を動的に配信したら良いのではないか？
といったようなアイデアが出ていたのが面白かった。
これは直近の用途として有望かもしれない。
ちょっと先の用途としては分散検索エンジンの研究を進めている人もいた。
どのようにレスポンスを確保していくのか興味津々である。
私自身は主催者のTomo氏から様々な事を教えてもらった。
Network Codingの概念やVivaldiアルゴリズムなど、
自分たちの仕事に直接役立つことが多かった。本当に有り難い。
昨日はほとんど教えてもらってばかりだったのだが、
将来はいまやっているP2Pライブラリ開発の仕事を通して学んだことを
教えたりもできるようになりたいと思う。
次回もぜひ参加したいと思う。
]]>私は、Extreme Meeting（XM）の概念が生まれたころから、
XMの概念を人間の行動に焼き付けるためのグループウェア
"Galapagos"の開発に関わってきた。
最近は開発からは離れ、日々の仕事の中でXMを実践している。
Galapagosのコンセプトは「XM養成ギブス」であった。
開発においては、
「人間は、日々使うソフトウェアに身体的にも精神的にも影響を受け、
ソフトウェアの設計が人間の行動に強い影響を与える」
という仮定を置いて、このソフトを使うと否応なしにXMが身についてしまう、
というレベルのwebアプリケーションを目指した。
未踏ソフトウェアではその成果に一定の評価をいただくことができた。
Galapagosの成果を土台として、現在、鈴木氏は、書物の執筆だけではなく、
実際のサービスを完成させ、運営している。
ユーザーも順調に増えているそうだ。
鈴木氏は、このサービスの運営を通して、XMにさらに磨きをかけている。
今後、XMの影響がどこまで広がるのか、非常に楽しみである。
投票の結果を記録しておく。
第一位 6票獲得 チーム０「ふぁみりーこむ」
第二位 4票獲得 チーム１「ニコニコピル」
第三位・四位タイ 1票獲得 チーム２「ロストワールド」・チーム３「モバイルトモダチ」
この競争のもとになった問題文はここ。
以下に各アイデアの概要を説明する。
一位「ふぁみりーこむ」
図
まず各家庭にロボット(AIBOのようなものでよい)を導入する。
そのロボットは、映像以外のより抽象度の高い方法で、
家庭環境の雰囲気をセンスし、「ケンカしてる」「テレビみてる」
「だんらん中」「暴力をふるわれた」「かわいがられた」「会話がない」
「怖い表情をしている人がいる」「見知らぬ人がいる」「叩かれた」
など、ポストペットのペットみたいに観察をする。
ポイントはその観察結果の使い方である。
何とこれはセキュリティ会社の新しいサービスなのだ。
観察結果は、その会社のサーバにリアルタイムに送られ、
家庭が危険な状態になると、問題解決のために人が駆けつけてくれるのだ。
あるいは犬ロボットがワンワン騒ぎ立てて警告するといったこともできる。
家庭がうまくいってないと犬が警報を出してくれるのだ。
提案書では、さらにセコムの裏側に、Mechanical Turkの考えに基づき、
多くの人々が動いていて、コミュニケーション・ツールとしても機能する
という段階まで発展していた。家庭環境を集合知を使って改善できるというわけだ。
愛くるしい家庭用犬（でなくてもいいけど）ロボットの新しい用途として、
具体的な提案の一つになりえるのではないだろうか？
きわめて大きなビジネスチャンスが眠っているようにおもわれる。
二位「ニコニコピル」
図
問題文では2015年だったのだが、これは2030〜2040年を見越したネタだ。
そのため、今回は得票率が低かった。原案を出した人は、
ナノテクやバイオテクノロジー等についてかなり知識が豊富だったようだ。
ニコニコピルは、製薬会社によって発売される製品で、
人間の身体に吸収される薬剤である。
薬剤の成分は、（おそらくナノテクによって実現される）特殊なデバイスであり、
血流に乗って脳に到達することができる。
そのうえで、あるデバイスを身体に装着すると、人間の脳に、
非常に単純な信号（怖いとか楽しいとか驚きとか）を送ることができる。
つまりミクロな情報出力装置を大量に身体にばらまくタイプの
あたらしいゲーム機だ、ということである。
未来のゲームは1回100円で飲み薬を飲んで新しい体験を提供する、のだ。
これについてあり得ない、と即断してしまった方は、
このあたりの本を読んでみると、ちょっと考えが変わるかも・・
ポスト・ヒューマン
ナノ・フューチャー
三位「ロストワールド」
図
これはサーバ上にかなりリアルな3次元の都市データを作っておいて、
それを携帯電話のGPSや加速度計など座標取得技術を使って
いつでも・誰でもエディットできるようにしようというもの。
パズルゲームやコミュニケーションツールの実現という案が出ていた。
四位「モバイルトモダチ」
図
これは携帯電話で「Knowledge Navigator」の原始的なものを動作させるというもの。
オリジナリティという点で、あまり高得点には至らなかったようだ。
1時間20分というのは相当短かった。が、ブレインストーミングというものは、
あっという間に時間がたつものだ。1時間20分で、しかも10人以上のブレストの
アウトプットであると考えると、かなり濃度が高いと言えるのではないだろうか。
朝10時40分で、しかも超人気セミナーの裏なのだが、
今後登場してくる、あたらしいタイプのゲームはどのようなものが面白いのか？
について多人数でブレインストーミングをおこなう。
http://cedec.cesa.or.jp/contents/t11.html
このブレストには、ウノウの代表取締役社長・山田進太郎氏、
芸者東京エンターテインメントの代表取締役・田中氏にも
コメンテーターとして参加していただくことになっている。
二人の切れ味の鋭い突っ込みには期待したい。
このブレインストーミングでは、投票により「勝者」を決定するのだが、
勝者にはなんと iPod Touchをプレゼントする。
アイデア出し勝負に勝ってiPod Touchを手に入れたい、
という方はぜひ参加していただきたい！
ちなみに、コミュニティーエンジンでは、CEDECにてWorld Synthesizerの
プレイアブルデモを展示中。
こちらもごらんあれ。
この考え方が広まるのが速くなればうれしい。
gumonjiプロジェクトでは、特にMMO版を考える場合には、
おおきくわけると以下のような仕事がある。
1. シミュレータの動きやユーザーインターフェイスなどの技術的な部分
2. 荒しを防ぎつつ大人数を受け入れられるようにする社会的な部分
ソーシャルグラフのデータを外から持ってこれるならば、
2についての仕事を大幅に減らし、限られた経営資源を1に集中することができる可能性が高い。
「ユーザーデータベースを囲い込むことによる競争優位」に立脚せず、
1の部分の純粋な価値で勝負するほうが、長い目で見たときの社会全体にとっての
価値が大きくなる可能性が高いということである。
ずっと、gumonji MMO版の荒しを防ぐために使える概念が必要だったのだが、
一歩進んだ、と思う。
gumonjiだけでなく、コミュニティーエンジンがかかわるほとんどすべてのプロジェクトに
深く関係のある話だ。
次にすべきことはなにか？
ひきつづき考える。
> http://www.watch.impress.co.jp/game/docs/20070913/ceint.htm
> > 同じ内容でP2P(分散型)とMMO(集中型)の両方を試した例というのはなかなか
> > ないと思うんですが(笑)、その両方をやって初めて見えてきた結論として、
> > 次にやるとしたら基本となるネットワーク方式はMMOしかないと思っています。
> > ですから、P2Pはチートされてもいいようなデータだけに使います。
> という意見がとても気になっていますが。
> 結局、ハードとソフトとネット帯域の性能向上によって、P2Pの管理の難しさに
> 比べてMMOの負荷集中のデメリットの方が小さくなるかもしれませんね。
この「MMO/P2Pのコストパフォーマンス境界」は、通信のトポロジや量よりも、
むしろゲーム内容によって大きく変化すると思う。
まず、多くのユーザーがネットワーク経由で集まり、同時ログインして、
同じデータベース（データの塊）に対して何かをアップロードしたり
編集したりするゲームの場合は、データのクオリティを一定に揃えたいので、
MMO型にするメリットが大きい。
また、何度か登場している「生きている度合い」が大きいほど、
MMO型にするメリットが大きい。これは、少しでもほころびがあると、
それがシミュレータによって増幅され、データの品質が予期せぬ方法で落ちる
場合が多いからである。「生きている」から「病気」になったりしやすい
ということである。病原体が少しでも入ると全体がダメになって死に至ることもある。
オンラインゲームにおけるデータのセキュリティは根本的なものだ。
今後「生きているデータベース」がエンターテインメントの中心になっていくと思うので、
World Synthesizerにおいては、MMO型をデフォルトとしている。
http://www.watch.impress.co.jp/game/docs/20070913/ceint.htm
World Synthesizerの製品について情報を外に出すのはこれが最初となる。
現在のバージョンは、CEDEC 2005で発表していたものに至る道の第1歩目である。
今はまだ、プロが仕事の使う用のソフトウェアなので、
TGSではビジネスデイでの展示のみとなる。
今後はもっと利用範囲をひろげてゆく。
記事中で「生きている度合い」について説明不足が感じられたので、
ここで補足をしておきたい。
生きている度合いというのは簡単で、
シミュレータの単純な動作規則から、
いかに複雑な別のものが自動的に産み出されたかが、その尺度となる。
したがって、非常に単純に説明をしてしまえば、
規則の単純さをＸ、できたものの複雑さがＹとすると
（Ｙ／Ｘ）の値が大きいほど、生きてる度合いが高い、となる。
人間ほどの複雑な生物が、DNAの単純なルールから産み出されてしまうから面白いのだ。
計算機の中で同じようなことが起きるかどうかは、まだわからないが。