先日、マイクロソフトのクラウド事業・Azureのセミナーに参加したところ、最新の「第４世代コンテナ型データセンター」をトラック付きでプレゼントされました。

ずっと放置してきたのですが、最近やっと時間ができたので組み立ててみました。

スライドショー （クリックで次の写真に進みます。）

[[Show as slideshow]]

↑ コンテナ型データーセンターの組み立て作業。

参考： FRT Vol.4 クラウド 規模の経済の裏側

これは日経コンピュータの中田記者による講演動画です。Microsoft,Google,Yahoo,Amazonといった巨大クラウド事業者の裏側であるデータセンターの「規模の経済」が解説されており、大変勉強になります。

Windows Azureアプリケーション開発入門 (MSDNプログラミングシリーズ) 酒井 達明

okachimachiorz氏

• MapReduce（Hadoop）はWeb系ビジネスから出てきた技術だが、物流・会計などの基幹系ビジネスのおよそ9割に、素直に適用できる。適用範囲は意外に広い。産業構造に大きな変化を与える程の、巨大なインパクトを持っている可能性がある。
• このように大きな可能性を持っているMapReduceだが、課題は多い。例えばクラス図やシーケンス図といった既存のモデリング手法が使えないなど。新たな設計手法が必要とされている。

shot6氏

• Hadoop適用の前に、設計・開発・テスト・運用・障害対策・品質保証と考えなければならない様々な問題がある。扱うべきテラバイト級のデータはそもそも何処に在るのか？、HDFSにデータをどのように入れ・どのように取り出すか、「JobTrakerが死んだときは再起動する」という運用でホントに良いのか？、拡張運転の話はよくあるが縮退運転は可能か？、バグの見つけ方・テスト手法は？、生のMapReduce（Javaクラス）とPig・Hiveとの使い分け方、などなど。
• 主催している「Hadoopソースコードリーディング」の人気が凄い。ただのインフレか？「Hadoop大国日本」か？

asami224氏

• 既存のシステムは、S（アクター）・V（イベント）・O（エンティティ）の連鎖でモデリングすることが可能。これをクラウド上でのモデリングに応用しようと試行錯誤している。
• プログラマーは図を描くよりも、テキストの方が書きやすい。DSLを使ってモデリングとプログラミングを同時に行なう「モデグラミング」を開発している。
• 「静的構造モデル」と「状態遷移モデル」はDSLから自動生成。「振る舞いモデル」は工夫が必要。今までどおり「手続き」として書いてしまうとクラウド上ではロックだらけに。メッセージフローモデルを導入した「g3フレームワーク」を開発中。

masayh氏

• Hadoopは物理モデル。論理モデルの導入が必要。論理モデルとしてDryadとPregelなどの「グラフデータモデル」が有効。
• DryadはHadoopに比べて論理モデルを持っている。自動生成やデプロイ、さらにデプロイ後の自動最適化など。
• データの入力と出力の依存関係のマトリクスからグラフを作り、MapとReduceをどの粒度でやるかを考える。
• DryadLINQが操作モデル。操作モデルを使うには、データの構造定義を先にする必要がある。（データの構造定義＝Directed acyclic graph？ ※著者注）
• クラウド上のデータは、（Cassandraで扱うようなデータ構造ではなく）最終的に人間の知識構造に近づくと思われる。（セマンティック・ウェブ？）

座談会

• 業務フローをDAG（Directed acyclic graph）で書いてみるとかなりできる。DAGは計算/最適化可能。つまり、このDAG自体をMapReduceで計算できる。 （okachimachiorz氏）
• Dryadではそのような計算をして、グラフを動的に変更している。ただし、ネットワークトポロジを考えないといけない。Dryadがプライベートクラウド向けということは、ネットワーク分断が問題になるから。（masayh氏）
• ノードの重みとか、流量とか考えれば最適化できるけど、問題が複雑化しすぎる。抽象化レベルをどの程度にするかが問題。 （masayh氏）
• アカデミックでは1980年代辺りから、データフローの検討は多いので、発掘される技術があるかも。データの依存関係の局所化できる粒度を見つけたり。 （？）
• 大量のデータがどこにある？という問題提起は、そう思わない。諦めて捨てているデータは多い。期間限定で保存して捨てたり。現状、小売りの販売データは大抵１３カ月で捨てられる。これではたいした分析が出来ない。米でウォールマートがあれだけ強いのは、商品ごとに利益率データを分析しているから。日本でこれが出来ている小売はない。 （okachimachiorz氏）
• アメリカ政府では、気象データなどの公共性の高いデータのマーケットプレイスを構想している。これを基礎データとして、ビジネスを発展させるという展望を持っている（Data.gov？）。いずれ日本でもそうなる時期に備えて、大量データの扱い方のノウハウを準備しておく必要がある。 （masayh氏）

上記すべての記述は、そのままの発言ではなく、私の解釈が入ったものです。 勉強不足でグラフ関係の話が（重要にも関わらず！）スッキリ頭に入ってきませんでした。

主催者によると「今後もやっていきたい」とのことなので、期待できそうです。

参考：Togetter – まとめ「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会」

Hadoop Tom White

上流工程UMLモデリング 業務・要求分析からプログラミングへのモデル化技法 浅海 智晴

マインドマップではじめるモデリング講座 (DB Magazine SELECTION) 浅海 智晴

アーキテクトの審美眼 (DBMagazine SELECTION) 萩原 正義

既存のオンライン・ショッピングだけでなく、新しい「クラウド」事業でも存在感の増しているアマゾンがエンジニアの募集をしています。

私は、今年２月に行われた「第0回 AWS User Group勉強会」でこの話を知って興味を持ち、３月に英文履歴書を提出して、４月初めに面接に呼ばれました。応募したポジションは、「デベロッパーサポートエンジニア（AWS）」と「ITサポートテクニシャン」の２つのポジションです。

この２つのポジションでそれぞれ面接が行われ、計５人のアマゾン社員の方のインタビューを受ける機会がありました。結果的には、「デベロッパーサポートエンジニア（AWS）」の方は１次面接で、「ITサポートテクニシャン」の方は２時面接の後に不採用の連絡をいただくことになったのですが、この応募プロセスを通して色々と気づくことがあり、たいへん勉強になりました。これから、その「気づき」とそう考えるに至った面接中の出来事に関してレポートしたいと思います。

周りにラブホテルと倉庫しか見えない殺風景な市川塩浜駅を降りて少し歩くと、巨大なアマゾン市川配送センターが現れる。ここで面接は行われた。

さて、具体的に何があったのかですが、以下のようなことがありました。

• 面接のために指定されたアポイント時間にアマゾンを訪れると、インタビュアーが忙しいとのことで、面接は一方的にキャンセルされた。
• 複数のインタビュアーからほぼ同じ内容の使い回しの質問を何度も受けた。特に何度もDNSとDHCPに関する同じ質問を受けた。どうやらインタビュー用の質問マニュアルを使いまわしているようだった。
• 面接の前に、NDA（秘密保持契約）らしきものにサインを求められるも、その契約文章がまったく日本語として読めず意味を成さないヒドイものだった。米国本社で使っている英文を機械翻訳にかけただけのものを、事前に読まずにそのまま応募者に配布していた。（渡した担当者に意味を聞いてみても、担当者自身が読めなかった。）

要するに応募者に対する扱いが非常にザツだった訳です。

もしかするとこれを読んで、不採用の腹いせに悪口を書いていると感じらる方がいるかもしれません。しかし、私の本意はそうではありません。私が言いたいのは例え些細なことであっても、上記３つの出来事すべてにアマゾンの強さの本質が現れているということです。

アマゾンの強さの本質は、徹底的なコスト削減の意志が企業文化（カルチャー）として深く根付いていることです。それは採用活動の細部にまでです。つまりインタビュアーが応募者に合わせて仕事を止めるのはムダだし、個別に質問を考えるのも勿論ムダ、NDAの内容を事前に弁護士のレビューに掛けることもムダだと彼らは考えているのです。

もちろん、このような考え方は普通の企業ではしません。でも、それでイイのです。仕事に対して普通の企業とは違う考え方を持ち、違うやり方を実践しているからこそ、結果が違ってきている訳ですから。

そして当然、このようなコスト削減への意志は、私の些細な採用活動に関するミクロな話にとどまりません。クリス・アンダーソン「ロングテール」は、アマゾンが以下の段階を踏んで成功していったと記述しています。

• 第一段階： 大規模な倉庫で在庫の集中管理をしてコストを削減した。
• 第二段階： マーケットプレイスで外部のサプライヤーに在庫の保管コストを負担させ、さらなるコストの削減に成功した。
• 第三段階： 電子書籍で在庫そのものを無くして、さらにコストを削減した。

ロングテール(アップデート版)―「売れない商品」を宝の山に変える新戦略 (ハヤカワ新書juice) クリス アンダーソン

コスト削減に成功するごとに、アマゾンは飛躍していきました。

もちろんこのような大規模なコスト削減は、アマゾンCEOであるジェフ・ベゾスの卓越した戦略のおかげです。しかし、戦略だけで組織が上手くまわる訳ではありません。戦略があっても、それを全従業員まで浸透する企業文化（カルチャー）にまで落していかないと上手くまわらないのです。カルチャーこそ大事です。

アマゾンはリクルートのページで「Frugality 倹約」をアマゾンのコア・バリューとして掲げています。

今回の個人的な経験によって、上記の企業文化の深い浸透度合いをよく確認できました。

アマゾン・ドット・コムの光と影 横田増生

私にとって特に興味深かったのは江渡さんによる「合議の知を求めて」という本の紹介でした。この本に書かれている実験によると、複数のグループに対して答えのある問いを出した場合、仲間内でコミュニケーションを通して統一した答えを導き出す方法よりも、グループ内のコミュニケーションを遮断して個々に答え出した上で（グループ内で）ひとりでも正解者がいればＯＫという方法の方が、正しい答えに到達する可能性が高かったそうです。

もしかして私たちは今まで「コミュニケーション」の効用を過大評価していたのかもしれません。

根回しによる合意形成、「話せばわかる」的説得、妥協と譲り合いによる一致よりも、個々人による意思決定を重視する、つまり意思決定の数を多くして、結果的に成功した判断を事後的に採用する、という方法の方が上手くいきそうです。

昨年のウェブ学会の時に、集合知的に個人の意思を集約する「民主主義2.0」の話を知って、その際は「人と人とがコミュニケーションを通して合意形成する議会の機能を無視して上手くいく訳ないじゃん！」と受け流していたのですが、やり方しだいでは上手く行くかもしれないと思いなおしています。

合議の知を求めて―グループの意思決定 (認知科学モノグラフ) 亀田 達也

この本のみならず、社会的な意思決定に関しては、学術的な成果が既にいろいろあるようです。興味が出てきたので、時間を作って学べればと思っています。

１、OpenSocial ケータイ Game 戦国時代 山下英孝（mixi）,山口徹（DeNA）

mixi・モバゲー各担当者による、話題のソーシャルアプリのセッションです。どちらのプラットフォームもOpenSocialを採用し、システム構成は似ているものの、各APIへの対応ぐあいや認証の仕組みなど、細かいところで様々な違いがあることが分かりました。

面白かったのがユーザー層の違い。大まかな傾向として、mixiがリアルでの知り合いがつながっているのに対して、モバゲーはゲームを通して知り合った、必ずしも顔見知りでない友達が多いのだとか。アプリ作りにもいくらか影響があるかもしれません。

２、本当に問題ないですか？～大規模RIA案件50社をこなしてきたプロが語るエンタープライズにおけるCloud＆RIAアーキテクチャ 島村伸之（住商情報システム）

顧客にクラウドを利用したシステムを提案したところ、「データが国内で管理されないのは不安だ」と言われたとか。これから多発しそうな話です。

３、三周遅れのXP -僕とドワンゴのXP- 庄司嘉織（ドワンゴ）

プレゼンが面白かったです。時々「？」と思わせる違和感のある言葉が出てくるのだけれど、その言葉がフックになって次々と内容に引き込まれて行きました。

最終的にはドワンゴにおける正統なアジャイル開発の実践事例の紹介でした。アジャイルがいま再注目されている理由がよくわかりました。

講演資料：三周遅れのXP

４、クラウド開発に役立つ OSS あれこれ 水野正隆,奥垣内喬（オージス総研）

クラウドサービスと既存のオンプレミスアプリケーションとの統合等の為に使えそうなOSSの紹介でした。はやり実務ではクラウドだけで完結するケースは少ないようですね。

rforce, fabulatr, Puppet, Wakame, Atomosphere, muleESB, Eucalyptus などが紹介されていました。

講演資料：クラウド開発に役立つ OSS あれこれ

５、パネルディスカッション 出張！ DDD難民救済キャンプ ～ドメイン駆動設計をあきらめない～ 和田卓人,角田直行,和智右桂,佐藤匡剛,渡邉健太郎

正直、DDD（ドメイン駆動設計）は、言葉を知っているという程度だったのですが、このパネルディスカッションのおかげで大変興味を持つことになりました。

Zenスタイルで「ユビキタス言語」「ブレイクスルー」といった魅惑的な言葉が説明され、圧倒されました。

講演資料：出張！DDD難民救済キャンプ

Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans

６、Programming Amazon Web Services/EC2,SQS,S3,SimpleDB Jeff Barr（Amazon Web Services）

AmazonのエバンジェリストJeff Barr氏によるセッションです。クラウドの概説から入って、CloudFusionを使ってPHPからAWSの主要サービスを利用するチュートリアルが説明されました。

クラウドの概説で「Utility Pricing」という言葉が使われていたのが印象に残っています。クラウドは電気やガスのように使える「ユーティリティーコンピューティング」であるという説明に、今まで少しばかり引っかかっていましたが、課金面のアナロジーから入っていくとスッキリ理解できました。

７、次世代Web標準 HTML5 最新動向 矢倉眞隆,小松健作,羽田野太巳,白石俊平,上山智士,竹迫良範

最初にHTML5の概説があり、その後、HTML5を使った様々なアプリ紹介がなされました。

概説で、それまで断片的だった知識が整理されたのは助かりました。また事例の中では「Web Workers」によるクライアント・コンピューティングの姿には未来を感じさせられ、クラウドによるサーバ・コンピューティングとの関係がどのように整理されていくのかも含めて、興味く感じました。

講演資料：
HTML5 & Web Platform
Web SQL Databaseを用いたサーバーレスパーソナライズドサービス

HTML5&API入門 白石 俊平

徹底解説HTML5マークアップガイドブック 羽田野太巳

以上、２日間に渡って見学したデブサミ2010の感想でした。私が行った他にも興味深いセッションは沢山ありました。いま私は、行けなかった分の講演資料を確認しているところです。不況の影響で今年は開催が危ぶまれたそうですが、来年も開催されることを切に願いたいと思います。

以下、1日目に行ったセッションすべての感想です。（敬称略）

１、クラウドがもたらすパラダイムシフトとデベロッパーへのインパクト 栗原潔

「所有から利用へ」「サーバ中心コンピューティング」「データセンタ集約」「選択と集中」のメガトレンドは以前より着々と進行しており、「クラウド」という言葉もメガトレンドの表れ。たとえ「クラウド」という言葉が廃れても、メガトレンド自体は変わらないとのこと。このメガトレンドの中で、既存のSI会社は厳しくなり、「ノマド」ワーカーが創意工夫で活躍する時代になるらしいです。

途中、世界各国の年齢別人口比グラフが紹介されたのですが、少子化である日本の若年層が減っているのに対して、インドではすごい勢いで若年層が増加しており衝撃的でした。これから厳しくなる日本の環境の中で生き残っていくには、個人としての「選択と集中」が重要になってくるという締めでした。

講演資料：クラウドがもたらすパラダイムシフト

参考書籍：

ライフサイクル イノベーション 成熟市場+コモディティ化に効く 14のイノベーション ジェフリー・ムーア

２、“クラウド”をビジネスにしませんか？ 〜 Force.comのテクノロジーとビジネスモデル 〜 岡本充洋（Salesforce）

Salesforceのセッション。「Salesforceを使えば開発の生産性が５倍上がる」という調査会社のレポートが紹介されました。WebでDBが即座に設定できるなどのデモを交えながら、コーディング過程のみではなく、開発のライフサイクル全体で生産性が５倍上がるとの説明でした。

またユーザーと開発者が同じ方法でログインするなど、Salesforce独自のアーキテクチャが強調されていて興味深かったです。試用できるようなので、早めに時間をとって評価してみたいと感じました。

講演資料：“クラウド”をビジネスにしませんか？

３、Google的分散コンピューティング Gregor Hohpe（Google）

最初は、GFS、BigTable、MapReduce、Sawzallの概説から始まりました。ここらへんの話は「Googleを支える技術」を読んで既に知っている話だなと聞いていたのですが、概説が終わったあとは、Google的な設計原則に関する興味深い話に入っていきました。

特に面白かったのは、ステートレスな処理とステートフルな処理を分離して設計するという原則。ステートレスな処理は分散が容易だが、ステートフルな処理の分散は難しい。ステートレスな処理だけでシステムの目的が達成できれば良いのだが、大抵そう上手くは行かない。どうしてもステートフルな処理も必要になってくる。そうした場合には、ステートレスな処理を行う場所とステートフルな処理を行う場所を混在させるのではなく、２種類の処理を分離してまとめる設計にしよう、という話でした。

４、ドッグフーディングとアジャイル開発 大澤俊介（Atlassian）

自社内でのベータ版の試用のことを「ドッグフーディング」と言うらしいです。初めて知りました。アトラシアン社内でのイテレーションのまわし方などが紹介されていました。

講演資料：Dogfooding and Agile Development

５、MVP & .NET Community Member`s Lightning Talks 猪股健太郎、小野修司、福岡寿和、亀川和史、瀬尾佳隆、冨田順、こだかかおる

マイクロソフト系コミュニティのライトニングトークス。どの話も面白かったです。アプリ内にSQLを書いてDBにから直接データを取得するのでは無く、間にWebサービスを設けてみると良いという話と、Visual Studioでテストデータが簡単に作れるという話が、私にとっては実践的で印象に残っています。

講演資料：
MVP & .NET Community Members Lightning Talks
WCF RIA Servicesって
Visual Studioでテストデータを作ろう
Windows Azureで Webサーバーを再発明してみる
Windows 7のトラブルに立ち向かう～Troubleshooting Packご紹介

６、RDB入門～アプリケーション開発者が陥りやすいDB開発の落とし穴～ 磯辺信雄（iAnywhere）

実際に起こった問題をもとにRDBの技術を解説していくというスタイルで、非常に実践的な内容でした。「トランザクション分離レベル」「効率の良いSQLの書き方」「Viewの使い方」「ボトルネックになりやすいディスクI/O」などが解説されました。

講演資料：RDB入門 ～アプリケーション開発者が陥りやすいDB開発の落とし穴～

７、パネルディスカッション 『徹底入門』の著者による仮想化エンジニアの未来 平初（Red Hat）、各務茂雄（VMware）

担当編集者の司会のもと、Xen、WMwareと、２つの仮想化技術入門書の著者によるパネルディスカッションでした。平氏がQEMUの仮想ハードウェア構成からXEN、KVMと順次解説されて、「もっとハードウェアのことを知ろう！」と言われたことが印象に残っています。議論の終盤は、個別の技術から離れて未来のエンジニア像の話になり、「（グローバル化で）日本人というだけで付加価値があった時代は終わりつある」「英語、そしてなによりも日本語での表現能力がますます重要になってくる」と大変刺激を受ける内容でした。

セッション終了後には、直前にニフティがWMwareを使ってクラウドサービスを開始のニュースを読んでいたので、気になって質問しに行きました。記事の中で、「VMwareのコストは支配的ではありません。むしろ苦しいのは、ストレージのコストですね。」とあります。これはディスク容量が苦しいのではなくて、ディスクI/Oがボトルネックになっているとのこと。IOPS（Input/Output Operations Per Second）が問題となっているので複数台を接続する必要がありコストが掛かる、という理屈がスッキリ理解できました。

参考書籍：

Xen徹底入門 第2版 (CD-ROM付) 宮本 久仁男 平 初 長谷川 猛 津村 彰

VMware徹底入門 (DVD付) ヴイエムウェア株式会社

２日目の感想に続きます。

クラウドとは何か

「クラウド」とは、複数のコンピューターを１つの大きなコンピューターにまとめた上で、計算能力をネットワーク経由で貸し出すユーティリティー事業です。「クラウド化する世界」には「クラウド」という言葉はほとんど出てきません。代わりに「ユーティリティー事業者」という言葉が数多く出てきます。

クライアント・サーバーシステムの非効率性

なぜ、コンピューティングのユーティリティー事業者が必要とされているのか？それは、現在主流の企業内C/S（クライアント・サーバー）システムが、複雑で非効率なシステムだからです。

メインフレーム時代はコンピューターは企業に１台だけなので、話は単純でした。しかし、現在は個人がパソコンを持ち、企業内の各種サーバーにつながっています。クライアントのパソコンが多数であるのは勿論のこと、サーバーも沢山の数があり、その間の相互接続は複雑です。

また、各サーバー間の利用率（負荷率）はバラバラで、一部のサーバーの負荷が能力の限界値ぎりぎりで運用される一方、ほとんどのサーバーは負荷率が低いまま運用されています。つまり、非常に効率が悪いのです。

この非効率性は企業内のサーバー間のみならず、企業間にも見られます。各企業で情報システムの利用度合いが異なるにも関わらず、今まで個別企業が自前で似たような情報システム構築し運用してきました。

クラウドによる規模の経済の実現

クラウドはこの非効率を解消します。企業は情報システムを自前で所有せず、ユーティリティー事業者から必要に応じて借りて利用することになります。ユーティリティー事業者は、保有する膨大な数のコンピュータを内部ネットワークを通してシームレスに接続し、最適に負荷が分散される「１つの大きなコンピューター」として動くように設計します。この設計のおかげで、事業者は保有する各コンピューターの利用率を高くたもち、「規模の利益」の経済性を実現します。

経済性がイノベーションを規定する

要するに「クラウド」とは、コンピューティングにおける経済性の追求にほかなりません。「クラウド化する世界」ではコンピューティングを、２０世紀初期の「電気」にたとえます。送電ネットワークの発達と共に、各企業が所有していた発電機を廃棄して、大規模な発電所で生み出された安価な電気を利用するようになった経緯を描写することで、テクノロジーが経済性から逃れられないことを説明します。

クラウド化する世界 ニコラス・G・カー Nicholas Carr

ここまでが、上記の本の前半部分。

残りの後半は、ユーティリティーコンピューティングが実現した社会でのネガティブな話を、これでもかと提示します。格差の拡大やプライバシー問題、国家の関わりに、コンピューターが人間のために働くのではなく、コンピューターの為に人間が働く可能性。これらの話はたいへん興味深けど、複雑な問題で語りにくいですね。

グローバル化

90年代初頭に冷戦が終結し、旧共産圏が自由貿易圏に加わることで、経済のグローバル化が一気に進んだ。イデオロギー対立の時代は終わり、途上国と呼ばれていた国も含めて、世界各国が経済成長という単一の目標に向けて邁進することになった。

IT化

グローバル化と時期を同じくやってきたのがIT化だ。95年に発売された「Windows 95」の登場で、インターネットが家庭まで普及した。現在は新興国にて、ITの低価格化と普及が急速に進んでいる。

知識の拡散

次に起こったのが、知識の拡散（Decentralization:民主化・周辺化・分散化）になる。

かつて知識は、少数の大学か研究所に存在するものだった。しかし、まず第一に、大学が多数設立され、高等教育を受けた人物が大幅に増えた。大卒人材が供給過多に陥り、国内では、高学歴貧困層が社会問題化している。企業や研究機関ではない在野に、知識を持った優秀な人材があふれている状態だ。

そして、グローバル化とIT化が、知識の拡散を地球レベルで一挙に加速させている。つまり、日本の大卒人材を、質と量で圧倒するほどの人材が、新興国にあふれてきているのだ。

ネットブックを見て考えるべきことは、「世界中でこれで初めてパソコンに手が届く人がどれくらいいるのだろう」ということだ。5万円のネットブックが4万5千円になった時、インドや中国などのBRICs諸国では、その5千円の違いでやっとギリギリこれに手が出るようになる人が数億人はいると思う。そういう人はみんなホワイトカラーの予備軍だ。そういう人の中で、勤勉で頭が良い人は凄いスピードでネットや経済やITについて学び、立派なホワイトカラーになる。

数億人単位のホワイトカラーの供給増加=労働の単価の低下=相対的な資源価格の高騰だ。これがこれから加速度的に進んでいくことは間違いない。…

その数億人の1%でも、ネットで勉強しまくる人がいたら、日本が今のままで食っていけるなんて思えるはずがない。

原油高と同じくらい深刻な「ホワイトカラーの仕事破壊」

オープン・イノベーション

ついに、企業もこうした現象（外部に拡散した知識）を無視できなくなってきた。旧来の企業は、自らの「中央研究所」に、高等教育機関を卒業して知識を持った人材を終身雇用で囲い込んで、自前の知識で製品開発していた。しかし、現在はそうではない。

自社の事業ドメインに適合する製品知識を、自社からだけでなく、外部から積極的に導入する「オープン・イノベーション」を行うことで、製品化のスピードを速めて、急速に変化する市場環境に対応しようとしている。

また、資本と知識の蓄積がほとんどないような、ベンチャー企業であっても、ベンチャーキャピタルに資金提供を受けながら、外部の豊富な知識を利用・導入することで、大企業に対して製品化スピードで競争できるようになってきている。

モジュール型アーキテクチャ

ただし、いくら外部の知識を活用するといっても、すべてをアウトソーシングしてしまっては、製品を市場に合わせてコントロールする力を失い、いずれ競合他社に取って替わられてしまう。顧客に対して継続的に価値を提供するには、モジュール型アーキテクチャを採用し、知識を「統合」する部分をコントロールし続ける必要がある。

プラットフォームを制御し、各モジュール（=コンポーネント）の依存関係を解決することで、各モジュールは容易に取り換え可能になる。このようなアーキテクチャを採用し、市場や外部環境の変化に合わせて、各モジュールを素早く適切に取捨選択することで、競争優位を獲得できるようになる。

で、次は何か？

問題はこの流れを踏まえた上で、さらに将来注目すべきものは何か？いま私は、必死で考えているところです。

OPEN INNOVATION―ハーバード流イノベーション戦略のすべて ヘンリー チェスブロウ

もともとWebの価値の大部分はリンク（ハイパーリンク）にある、と昔読んだ本に書いてあったことを思い出す。人間が頭を使って、コンテキストを判断しながらつなげた情報をブラウズするのに対して、非公開で不可解なアルゴリズムの判断に身をゆだねながら情報をブラウズするのは「きもちわるい」し、現に非効率だ。

もちろん「検索」が必要なくなる訳ではないが、表舞台から退場し、あまり使われないコンポーネントの１つになり下がる可能性は大いにありそうだ。

Google社のミッションは「世界中の情報を整理し、世界中の人々がアクセスできて使えるようにすること」らしいので、別に検索だけが事業ドメインではないようだ。彼らが賢いのは自明なので、「検索」だけではジリ貧になると分かっているから（waveなど）いろいろと仕掛けてきていのだろう。

（対してYahooは昔から、検索はコンポーネントの１つで、コンテンツが主体だ。これは正しい！）

Google社でも安穏としていられないほど、今のWebの世界の競争は激しくて、ほんと面白い時代だなあ、と感じます。

参考記事：リアルタイム検索の向こう側：アンビエント・ストリームの夜明け

視聴後、講演者の方々にも興味を持ち、twitter上で、その後の議論も追っていたのですが、どうやら単に「集合知」といってもさまざまな考え方があり、代表的なものには「集団的知性（Collective Intelligence）」と「群衆の知恵（Wisdom of Crowds）」の二つのモデルがあるようです。

ということで、私もさっそく上記ページを読んでみたところ、とても明快に「集団的知性」と「群衆の知恵」の違いが説明されていました。

Surowiecki and Levy start from very different premises which would lead to very different choices in the game design process. Surowiecki’s model seeks to aggregate anonymously produced data, seeing the wisdom emerging when a large number of people each enter their own calculations without influencing each other’s findings. Levy’s model focuses on the kinds of deliberative process that occurs in online communities as participants share information, correct and evaluate each other’s findings, and arrive at a consensus understanding.
Confessions of an Aca/Fan: Archives: Collective Intelligence vs. The Wisdom of Crowds

要約： 「群衆の知恵」と「集団的知性」は、まったく違った前提からスタートしている。「群衆の知恵」モデルでは、多くの人々がお互いの知識に影響されることなく、個別に自らのデータを生み出す。そして、その個別データを匿名で集計することで、知恵が得られると考える。対して、「集団的知性」モデルは、コミュニティの中で、参加者が情報を共有しお互いの知識を評価・修正しあいながら一定のコンセンサスに至るような、討議的なプロセスにフォーカスしている。

「群衆の知恵」モデルは、多様性をもった参加者が、個々に自律していて、まわりの人々の考えに影響を受けないことが前提となっている。参加者がお互いに影響を与え、同質なグループができあがってしまうと、結果がゆがめられてしまうからだ。しかし、現実には、参加者はお互いに影響を与えあうため、「群集の知恵」モデルは問題をかかえている。

加えて、「群集の知恵」モデルは、技術的に、個別のアウトプットを数値として平均化できる質量推測/市場予測/オッズのような、客観データにしか適用できない。政治的オピニオンのような主観的なものに「群集の知恵」モデルを使うのは間違いだし、Wikipediaをこれで説明しようとするのも適切ではない。

Wikipediaを説明するのに適しているのは（「群集の知恵」モデルよりも古典的な）「集団的知性」のモデルである。これは、すべての知識を持っているメンバーはおらず、個々人が断片的な知識しか持ち合わせていない状態で、メンバーによってもたらされた知識に、他のメンバーが自由にアクセスしながら、多様なメンバーが協力して世界の理解を洗練させてゆくモデルだ。

The Wisdom of Crowds model focuses on isolated inputs: the Collective Intelligence model focuses on the process of knowledge production. The gradual refinement of the Wikipedia would be an example of collective intelligence at work.

「群集の知恵」モデルは独立した入力にフォーカスし、「集団的知性」モデルは知識生成のプロセスにフォーカスしている。「集団的知性」モデルの働きは、Wikipediaの漸進的な進化に見ることができる。（要約終了）

（追記：邦訳「Collective Intelligence vs. The Wisdom of Crowds」で全文の翻訳が公開されています。）

…ということらしい。この議論のあとは、ゲームに「群集の知恵」モデルを適用した場合と、「集団的知性」モデルを適応した場合とで、ゲームデザインがいかに大きく異なるかが述べられています。

「群集の知恵」モデルの適用範囲がとても狭いというのは意外でした。ウェブのみならず、技術、芸術、ビジネス、政治のさまざまな分野で「集合知」が話題になり、ブームになっています。「集合知」の議論はとても魅力的です。でも、具体的モデルが不明確なままだと、そのうち現実とのギャップに遭遇し、失望を生むかもしれない。地に足のついた議論が必要だと、自戒を込めて思いました。

「みんなの意見」は案外正しい (角川文庫) ジェームズ・スロウィッキー

こちらが「群衆の知恵」モデルについて書かれた本で、（読まなきゃ！）

Collective Intelligence Pierre Levy

こっちが「集団的知性」モデルについて書かれた本らしい。（翻訳はないのか、、）