Ringo's weblog / コミュニティーエンジン代表ブログ

CEDEC 2009セッションの結果報告

去る9月1日、CEDEC 2009にてMMOゲームサーバのバックエンドアクセス実装法というセッションを行いました。

セッションの講演資料はこちら

セッションでは、303席がほとんど満席になるほどの参加をいただきました。 大変ありがとうございました!

今年からCEDECは規模が大きくなり、基調講演、セッション、 参加者数すべてが拡大したそうです。 会場でも日本におけるCEDECの影響力が大きくなっていることを実感しました。

このほどCEDECの事務局から聴講者アンケートの結果が送られてきましたので、 結果の報告と、アンケートにあった質問に可能な範囲でお答えしたいと思います。

まず結果については:

役に立った=80 どちらともいえない=30 役に立たない=6

ということでした。いまのプロジェクトに取り入れてみたいという意見もあり、 多くの方に情報を活用していただけたようで、ほっとしています。

その一方で、いくつか指摘や質問などもいただきましたので、ご紹介したいと思います。

▼ 最初に資料を公開有無を教えてほしかった。時間が短かった...。 

「説明がはやすぎる。メモによけいな時間を取った。」という指摘もありました。 これについては配慮が足りず、申し訳ありませんでした。 今後はぜひそうしたいと思います。

▼ 国内と海外のDB(←DB以外にもサーバ構成そのものを)の使い方を比較してほしい。

これはぜひ今後、やってみたいと思います。 アマゾンに売っているようなMMOG開発本では、 ほぼ概論の解説にとどまっていて、違いがよくわからないので、 今回のセッションのように開発者にインタビューをしてみたいところです。

興味が沸いたので、 GDC2009のプログラミングセッションリストを見てみると、 database, db, といったキーワードは一切登場せず、 しかも serverも1個だけ・・・と取り上げられること自体が少ないようです。 CEDECのセッションを準備するときに、MMOGの実装に関する 技術セッションを調査したのですが、海外も含めてかなり少ないようでした。

個人的には、それぞれのタイトルでの違いとしては、

  • サーバ構成にあまり違いは無いんじゃないか
  • ゲームサーバでは、DBアクセスをする際に、スレッドを使うとか違いがありそう
  • JavaやLLなど使っている言語の違いもありそう

このあたりがあるのではと思います。

今後、ぜひ取材をしてみたいです。 海外のMMOG開発者に知り合いがいるという方はTwitter等で 教えていただければ嬉しいです。取材に駆けつけます。

▼ パケットの通信には〈XML〉→XMLパーサ→バイナリ→暗号化のような中間部分があるのか?etcにもきょうみが出ました。

これはMMOGに特有というよりは、ネットワークゲームに特有の部分かもしれません。 web上にも、まさにこれだ、という資料は見つけられませんでした。 弊社で提供しているツールで支援している部分も関連性はあるのですが、 現状ではツールの利用方法の説明にとどまっている感じなので、 ぜひ折をみて概論も含めて解説をしてみたいと思います。 もしも情報源を知っている方がいたら教えていただければ嬉しいです。

以上、CEDEC 2009 の報告でした。

Special thanks to:真・女神転生IMAGINEの巽さん、田中さん、パンドラサーガの中さん、情報提供ありがとうございました!

Posted by ringo | コメント(1) | トラックバック(0)

CEDEC2009でMMOG開発のレクチャーをします。

タイトルは「MMO ゲームサーバのバックエンドアクセス実装法 」で、かなりMMOGの開発者向けの内容になっています。

ネットワークゲームの開発経験が全くない方にはちょっとなじみのない話かもしれませんが、実際の2つのタイトル「真・女神転生IMAGINE」と「パンドラサーガ」に取材する中で共通点や相違点を見つけることができました。これまでにない内容になっているかと思います。自分もとても勉強になりました。

各タイトルの開発者の方々にも教壇に立っていただくことになっているので、鋭い質問をぶつけに来てください!

Posted by ringo | コメント(0) | トラックバック(0)

【お知らせ】GTMF 2009にてセミナーを開催します

来たる6月8日(大阪)と6月15日(東京)に、
ゲーム向けの開発ツールを集めた展示会である、
"Game Tools and Middleware Forum 2009"が開催されます。

それにあわせて、コミュニティーエンジンでも、
ブラウザベースのMMOGを開発するTips講座を行うことになりました。

大阪の講演は、当社きってのフラッシャーであるプログラマのひとりが、
東京の講演は、私自身が担当します。

セミナー概要はこちら:


6月8日(大阪)開催概要


6月15日(東京)開催概要

セミナーでは、ブラウザ上で動作するMMOGの実装について、
詳細な解説を行います。同時に、ツールの展示も行います。
実際にプレイできるMMOアクションゲームのソースコードを見ながら解説します。
講演時間が短いので・・残念ながら?ライブコーディングはありません。

今回初公開するデモゲームは、セミナーにあわせて、
ミドルウェアの開発スタッフが一人で超短期で作ったものですが、
昨日、皆でテストプレイしてみたところ、けっこう楽しく遊ぶことができました。
ゲームバランスが荒削りですが、会議中であることを忘れて遊びこんでしまうほどでした。
セミナー終了後はwebサイトにて公開などしたいところです。
2009年度はブラウザベースのオンラインゲーム元年になりますが、
コミュニティーエンジンでは、この流れにしっかりとついていくつもりです。

GTMF 2009でのセミナーは、おかげさまでほぼ満席に近いようです。
ご要望があれば、GTMFとは別にセミナーを開催することも考えていますので、
情報が欲しいという方は、メールで、 info アット ce-lab.net
までご連絡ください。

Posted by ringo | コメント(0) | トラックバック(0)

「ゲーム」の価値とモンテッソリ教育

フィードを読んでいたら、久々に、ゲームの面白さについての長い文章を見た。

ゲームの面白さ

「ゲーム」と「面白さ」について定義せずに、
役立つ何かを見つけるのはむずかしいかもしれない。
CEDECのゲームデザインのセッションなど、たまに、定義を気にしている論考もあるが、
定義をせずに話しをするのが半分ぐらいあるし、
同語反復的でない、使える定義を用いている事は非常にまれだ。
Raph koster氏のゲームデザイン本は、
脳や神経、心理に関する学問の結果をできる限り使って、
同語反復にならないように最大限努力しているが、
このような本は日本だけでなく世界的にもかなりまれだ。

しかし、私が仕事をするなかで出会う、最前線でゲームを作っている開発者たちは、
みな自分なりのゲームの定義を持っていて、知識の蓄積を続けている。
私は一緒に作業をしたことはないが、たとえば、最近、遠藤雅伸氏が
インタビューでゲームの本質について語っている。
いわく、「インタラクティブな要素があって満足感が得られるもの」
この定義はかなり広めだ。恋愛や仕事まで含まれてしまう。
商売の都合上「前記かつ、半自動的に売上をあげられるシステム」
などといった暗黙の定義の上で仕事をしているのだろうけれども。
彼は、長年にわたり、極めて多くの挑戦をし続け、
多数の成功も重ねてきた人なので、ものすごく広い定義でも、違和感を感じない。
世の中全体を面白くしてしまう勢いで、今後も仕事をされていくに違いない。

さて私も、ゲームと呼ばれているものの開発に関わる身だ。
これまで、自分が作り出したいと思っているものを、
遊んでいるうちに賢くなってしまうようなソフトウェアだとか
人間の創造性を引き出すシステムだと表現してきた。
これらの要素が、遠藤氏を含め、みんなが「ゲームだ」と思っている何かと
共通している部分があるので、私は、ゲーム開発に関わっていると言って差し支えない。
(「ゲームを作りたい」と言ってしまうと、ひどくずれてしまうのだが。)


自分はまだ、遠藤氏ほど大量の試行をやりとげたわけではないので、
このレベルの表現よりも、あともう1段階具体化しないと、
仕事のステップを踏みにくいなあ、と感じていたのだ。

最近、その方法を発見できた。前置きが長かったが、それが今日の話である。

私は、4歳〜5歳のころ、モンテッソリ教育法を実践する幼稚園に通っていた。
モンテッソリ教育理論とは、モンテッソリ博士が戦前に、
発達障害の子供を観察していて発見した理論で、極端に簡単にいえば、
「ある条件を満たした単純作業に没頭すればするほど、
子供の知能が飛躍的に早く発達する」というものだ。
のちの研究で発達障害のないこどもにも発達加速の効果が大きいことが判明した。

「ある条件」とは、

・触感、音、色など、五感が刺激される作業であること。
・子供が持ちやすい、操作しやすいこと。
・どんな操作をするかは自分で完全に選択できること。
・1回、操作をするごとに進捗が把握できること。
・終わりがある(わかりやすい)こと。あるいは、小さな終わりの単位があること。
・失敗が起きること。
・失敗を自分で直せること。(やり直しができること)
・いろんな方法で試せること。
・意図は一つに絞ること。
・何百回、何千回と試せること。
・何十分も没頭できること。
・他にもあったはず

これらを実現するための道具を、モンテッソリ理論では「教具」と言う。
教具のデザイン目標は、子供が長時間集中し、
没頭できる繰り返し作業を可能にすることだ。
上記は私がこれまで調査して収集したそのための条件だ。

モンテッソリ理論を実践する幼稚園では、園児が登園した後、
これらの教具を使って、園児が作業に没頭する時間が、
午前と午後に2時間づつぐらい、用意されている。
この時間は「お仕事」の時間と呼ばれる。
普通の幼稚園であれば、みんな、「お遊戯」をするのだが、
モンテッソリ幼稚園では、みんなは「お仕事」をするのだ。
お仕事は、一人で、黙々と、やる。普通の幼稚園であれば、
みんなで輪になって遊ぶとかだが、教具を使うお仕事は、
一人で、1時間以上、ひたすら作業に没頭する。一つの作業が
自分の中で完璧に近づいたら、ほかのお仕事をする。
競争などのコミュニケーションはほとんどしない。
幼稚園の棚には、何十、おそらく100以上の教具があるので、お仕事のネタは尽きない。

みんなの「お仕事」のための教具は、具体的にはこんなのだ:
家庭で簡単にできるモンテッソーリ(1)
モンテッソーリ教師による教具紹介

上の条件が巧みに満たされていることがわかるだろうか。
教具には、子供を単純作業に没頭させるために細部まで工夫がこらされている。
五感を刺激する単純作業において、作業の最適化を、自分が満足するまで没頭してする。

これまでに1000以上の教具が発明され、日々、新しい教具が作られ続けている。
教具の作り方や、教具が使われた結果の観察には、極めて細かな、
多数の洞察が含まれているのだ。モンテッソーリ関連の書籍には、
それらが書かれているのだが、webで検索してもテキストは見つからなかった。
ただ、先の教具の紹介からでもその片鱗を見ることができる。
「円柱が穴にピッタリはまる感じ」とか、重要な感覚の部分が言語化されているのだ。

モンテッソリ教育には、教具を使うだけでなく、自然を体験したり、
お話をしたり、プールで運動したり、といった要素ももちろんあるが、
私自身が記憶している限りでは、単純作業に没頭している時間の記憶が
今でも極めて鮮烈である。今でも紙をめくる感触が思い出されるほどだ。
私の場合は、紙に1づつインクリメントしながら数字を書いて、
20進むごとに紙をノリでつないで丸めていくという「連続数字」
というお仕事を非常に気に入っていた。10万の桁までやったら、
先生が「幼稚園の新記録!」と言っていたのを覚えている。
私は、早く10万まで到達したいので、幼稚園の他の園児にも協力を依頼して、
流れ作業のラインを作って4人ぐらいで「ノリをつける人」「数字を書く人」
「紙を切る人」といった具合に分業体制を作って作業を加速した。
そのときは4人とも、作業に没頭して興奮していた。

こどもが何時間も作業効率の最適化のために没頭し続ける。
これによって脳におけるドーパミン報酬系が作動し、
新しいシナプスが急速に増え、こどもの知能が急速に発達する。
ここまでが実験や教育の結果でわかっている。

私は、モンテッソリ教育理論の教具の設計指針には、
「遊んでいるうちに賢くなってしまうようなソフトウェア」や
「人間の創造性を引き出すシステム」を定義し、
実現していくための大きなヒントがあると思う。
それがたとえ成人用でもだ。私には、子供を没頭させるしくみは、
ほとんどの成人にも適用できるように思える。
もし、成人でも、作業に没頭することで知能が発達するのならば、
それは「遊んでいるうちに賢くなってしまう」という価値そのものだ。
没頭させるビデオゲームに何の価値があるのか、という事にも答えられるようになる。
教具の設計を参考にして、いまあるソフトウェアの価値を増やせるようになる。
たとえばgumonjiであれば、「進捗が毎回確実にわかる」とか
「意図は一つに絞ること」「終わりがわかりやすい、あるいは単位がある」
などがとても弱かった。このあたりを強化すれば改善ができそうだ。

でも、教具は物理的なものを使って作られている。
計算機を使ってでも実現ができるのだろうか。

教具を使う作業では、紙や糸、針、糊、はさみ、鉛筆、砂、粘土、
金属の輪など、さまざまな、豊かな身体感覚をともなう道具を使う。

計算機が相手の場合でも、手の感覚と、視覚、聴覚を使うことができる。
もちろん、視覚は立体感覚がとぼしいし、聴覚も、限定的かもしれない。
しかし、モンテッソリの理論でも、「ある条件」に
特定の入出力デバイスを要求していないし、
実際にデバイスは何でもいい可能性が高いと思う。

と思ってちょっと調べたら、結構ポジティブな研究があった。

Computer-Based Learning and Montessorian Manipulatives

"computer based montessori manipulatives"で深掘りするとわんさか出てくる。
ACMでちょっと見てみたら山ほど出てきた。tangible computingや
smalltalkやmindstormsの論文なども次々にひっかかってくる。
モンテッソリはじめ、巨人達の仕事をうまく消化して、
次の挑戦に活かしていきたいところだ。

Posted by ringo | コメント(1) | トラックバック(0)

2009年

明けましておめでとうございます。

ということでまたポジションペーパーを更新しました。

短く言うと、未来語りはもうおなかいっぱいかな、という感じがしていて、
今年は、描いた未来に向けてあたりまえの事を完璧にやり続けられる
体制をつくって、淡々と、静かにかつ早く夢に近づいていきたい。

という感じです。

本年もどうぞよろしくお願いいたします。


Posted by ringo | コメント(0) | トラックバック(0)

10000時間

先日、また別の、私塾の師とするゲーム業界の先輩と飲む機会があった。
いつも登場する私塾の師だが、ぱっと出てくるのは5人だ。

このとき、コミュニティーエンジンには女性のプログラマが数名いる
という話をした。いまはプログラマ30名弱に対して3名だ。
これはかなり多いほうらしい。師が率いるチームでも、
20名に1名しか居ないが、それが普通のようだ。

プログラマや料理人は男性が多いのは何故か?

私は、「10年ぐらい1つのことに没頭してる女性は、とても少ないと思う。」
「とくに日本の働き盛りの世代では、「女のくせに」と言われて育った人も多いはず」
と話していたが、関連する話が紹介されていた:


プロフェッショナルにおける1万時間とDNAの違い

自分の場合は、高校時代までは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時間以上
没頭したことがある対象は何?」というような質問ができるのかもしれない。

Posted by ringo | コメント(0) | トラックバック(0)

google on ec2

先日、Amazon EC2のTechnology Evangelistの人に対して
Googleとどう競争するのか、と質問する機会があった。

彼の答えに新しい部分は無かったのだが、ひとつの発言が印象に残った:
「EC2の上にGoogleを載せることができる」という発言だ。
これは計算してみるしかない。

EC2の価格リストはここにある:

link

早速計算開始。 当然だが、私は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万ドル、1ヶ月に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の人に会ったら、これを計算してみたことはあるか?
と聞いてみよう。

Posted by ringo | コメント(0) | トラックバック(0)

手段と結果の自由度について

人をタイプわけするのはあまり好きではない。
しかし、人の行動パターンには傾向があることも確実である。
その行動パターンに名前をつけることもできる。

昨日、私が私塾の師としている人と飲むことがあったのだが、
そのときに「経営者タイプ」と「プロデューサータイプ」
という傾向の名前がでた。

彼はこう言う。

「中嶋君はプログラマからプランナーになったところだね。
プランナーの次はプロデューサーか、経営者か、
どっちを目指すのがいいんだろうね。」

プログラマというのはプログラムを書く人だ。
プランナーというのはどんなプログラムを書く必要があるか知った上で、
ゴールへの到達方法を考える人だ。プランナーのゴールの単位は「製品」だ。
だから「製品プランナー」と言ってもいい。
コミュニティーエンジンでは、エンジニアにはこの両方の仕事を期待している。
多くの小さなソフトウェア企業では基本的にそうだろう。
私自身もそのような仕事をしてきたと考えている。

師に、プロデューサーと経営者の違いは何かについてたずねた。
するとこういう意味であるという。

世の中をこうよくしたいとう最終結果Xがあるとする。
Xにはたとえば貧困をなくすとか、病気を無くすとか。
私自身ならば人間の創造性を拡張したいという願いがある。

Xを実現するためには、何らかの手段Yが必要だ。

XのためならYはなんでも良いとする人が経営者、
かなり狭いYを決めてそれでXがいかにして可能かを考える人が
プロデューサーであるという。プロデューサーにとってはXは自由だ。

まとめると、最終結果を固定して手段を柔軟にするのが経営者。
手段を固定して最終結果を柔軟にするのがプロデューサーだ。

彼から見れば、たとえばGoogleでは創業者2人がプロデューサー、
シュミット氏が経営者で、シュミット氏は自分が持っている最終結果に
2人が持っている手段が現時点では合致すると
分かったから参画したのだろうという。

任天堂の岩田社長や久多良木氏はプロデューサー、
スクエニの和田社長は経営者であるという。
アップルのSteve Jobsも、「箱に入ったコンピュータ」
という手段を片手にいかにして最終結果を実現するか、
最終結果を固定せずに考えているように見える。

どちらがいいというのではない。どちらの立場でも、
素晴らしい最終結果を出すことはできるのだ。
この2種の人々は相互に補い合うシステムを作って活動し、
最終結果を実現することができるからだ。
成功している組織では双方のタイプの人が活躍しているのだ。
最終結果をとことん考え続けるのと、手段をとことん考え続けるのと、
両方が必要であることは明らかだ。

どちらか一方だけを選ぶ必要があるというのではない。
スタート地点では補完関係が弱いから、両方を自分でやる必要もあるだろう。
時間と経験が経過するなかで、より自分に合ったほう、好きな方を
選択していくだけだ。
ひとつ言えそうなことは、手段と目的の両方を同時に固定すると、
固定している部分が多すぎて、可能な仕事の範囲が狭まりすぎ、
結果として何も実現できない確率が上がるかもしれない事だ。
たとえば、計算機とネットワークという手段と、
創造性を拡大するという最終結果の両方を固定してしまうのは、
狭くしすぎな可能性がある。
どちらかを自由にしておいたほうがいいかもしれない。
これについても今後考えたいが、まずいまは置いておく。


さて、自分にとってどちらが向いているのかを考える。
私は幼少時代から、計算機とネットワークという手段に魅せられ、
これまでの20数年間、没頭をしてきた。
これについて何の後悔もしていないし、
たぶん今後も没頭を続けるのだろう。この手段が気に入っているのだ。
ある手段に関して、膨大な時間的投資をしたのだから、
そのぶん、自然と、ほかの事には習熟していないのだろう。


「人間の創造性を拡大する」という最終結果に対して、
経営者であれば、学校や教育法を作るとか、知育おもちゃを作るとか、
未踏ソフトウェアのような投資活動をするとか、結果を最大化するための
さまざまな手段について考えをめぐらす事になる。
プロデューサーであれば、計算機とネットワークという手段を活用し、
高めながら、いかにして創造性を拡大するか、
あるいはほかの最終結果を出すことが可能かも含めて考えていく。

師は「中嶋君は経営者よりプロデューサーを目指すのがいいかもしれないね。
エンターテインメントやものづくりの業界は、
プロデューサータイプの人が大きな結果を出しやすいフィールドだと思うよ。」
と言っていた。

人生の金言とは、こういう言葉のことを言うのだ。

すぐに結論を出す必要は当然ないが、
やっぱり今日も、計算機とネットワークについて、
とめどなく探求している自分に気づくのであった。


Posted by ringo | コメント(2) | トラックバック(0)

知識の量が質に変化する瞬間

創造性は、知識の量から成る、と思う。本当にそうか?

ひとと話をしていて、創造性がある!と感じるのはこんなときだ:

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 を想像できてしまう。
ひとはこういったことを見ると「創造的である」と言うのだ。
知識の量がある水準を超えると、急激に創造的になったように見えるのだ。
これとパーコレーションの現象は無関係ではない。

「常識のない若者にしかできない創造があるではないか」これは反論にならない。
常識のない若者にしかできない創造は、もちろんある。
しかしこれは、若者が物事を知らないことによるものではなく、
バランスの悪さに起因するもののみである。

つまり、バランスよく問題解決にあたる技術を体得してしまったひとが
絶対にそうしないようなやりかたで、世界のごくごく狭い範囲の問題について、
徹底的かつ執拗かつ異常に、長時間、膨大なエネルギーをかけて
知識を吸収してしまうことができるからなのである。
しかしその分、世界のほかのほとんどの部分に関する知識は著しく欠ける。
私がこれまで見てきた創造的な若者はすべてこの場合に含まれる。
単純な無知は創造につながらないのだ。

現時点では、私は無知による創造性を信じない。

Posted by ringo | コメント(0) | トラックバック(0)

ポジション・ペーパー2008年版

2004年あたりからポジション・ペーパーを年1回更新している。
過去のものを掲載し続けるのは、はっきりいって恥ずかしいのだが、
成長の記録ということで公開しておく。
絶対値ではなく変化量に注目していただきたい。
(しかし派遣会社とかのスキルシートでスキルの絶対値ではなくて、
変化速度に着目して評価している会社は見たことがないな。。)

以下、2008年更新分をコピーしておく。

------------


私は、2007年の目標を以下のように置いていた。
「私に関わっているすべての人の潜在能力が100%発揮されるために、必要なことをすべて実行すること。」
これは、普通に考えると1年で終わるような事ではないし、実際に終わっていない。

「終わっていない」とはどういう事だろうか?

まず去年は、「人の潜在能力が100%発揮されている」とは何なのかを、特に考えていなかったようだ。
だから、終わったのかどうか、どの程度実現ができたのか、いま、ふりかえって評価することができない。
2008年は、これを評価可能な状態にして取り組みたいと思う。

「人の潜在能力が100%発揮されている」こと自体が良いかどうかについては問わず、
まず評価基準を考えてみる。この目標に何らかの意味があったかどうかは、
評価結果が出ればより深く考えることができる。

「人の潜在能力が100%発揮されていない状態」をできるだけシンプルに定義するならどうなるか。
まず何もしない状態と、何かをしている状態があるだろう。
何もしないとは、何かをただ待ってぼーっとしている状態だ。
これはかなり正確に能力を発揮してないと言えそうだ。

次に何かをしている状態はどうか。必要なことをしてる時と、そうでない時がある。
必要ないことをしてる状態でも、これは後になって考えたらやっぱり必要だった、と言えるかもしれない。
ムダや失敗からうまれる発明も多いはずである。
また必要なことでも、それを限界速度よりも遅くやってる状態は、能力を発揮してないと言えるだろう。
ただし、これは実は待ってる状態の派生に近いのではないか。

このように考えると、自分のまわりの人が、自分や他人を待ってる時間を最小にすればよい、
という評価基準で、評価することが可能なのではないか。
まずは、これでいってみたい。

これはどこかで聞いたことがある・・トヨタ生産方式の要素である。

トヨタの待ち時間最短理論は、自動車ならではの平準化された販売が
基本システムとして必要なので、同じ考えはそのままでは通用しないだろう。
というわけで今年は、自分たちの業態に合った待ち時間の評価方法を考えて、
それを最小化することをやってみたい。
ビルドの待ち。欲しいドキュメントが見つからない待ち。
バグによるblocking。要望に対応する時間の長さとか、会議のやり方とか、
営業における提案活動のやり方とか、仕事の中に、待ち時間は山ほどある。
改善できることは山ほどありそうだ。

Posted by ringo | コメント(0) | トラックバック(0)