大規模なコラボレーション活動を成功に導く5つの原則――パート2:Magi's View(2/2 ページ)
大規模なコラボレーション活動を成功に導く5つの原則。今回は、結合について解説する。多様ではあっても分断されているコミュニティーは創造的にはなり得ない。
多様なスキルを持つ人々が出会い協力する場とみた場合、市場は決して最適な仕組みではない。問題を抱えた人物がその解決策を保有する人物を見つけ出す手段にはなるだろう。例えば、蛇口が水漏れするから水道工事業者を探すというような場合だ。あるいは、これをモデルとしたInnocentive。これは製薬企業Eli Lillyから生まれた科学的問題解決コミュニティーで、10万人を超える科学者が登録している。科学的問題を抱えた企業は、その問題をInnocentiveのWebサイトに公開することで、その問題がすでに解決しているか否かを知ることができる。
しかし、この種の市場には本質的な限界がある。すなわち、特定の問題についてそれを解決できる人物を探すという場合には機能するが、持続的な創造性とイノベーションがなければ解決できないような困難で複雑な問題に取り組む際の基盤とはなりえないのである。そうした問題は丁々発止のコラボレーションからしか解決できない。前回触れたワームプロジェクトは研究者たちがブレナー博士の研究所にある喫茶室に集まることから始まった。それと同じように、We-Thinkプロジェクトには多くの人々が集う場所、アイデアが自由に流れるように配慮された創造的な対話のための中立的な空間が必要である。自由な討論の場とwiki、掲示板とコミュニティー協議会、Lean's Engine Reporter(蒸気機関に関する新技術・工夫を扱っていた業界紙)やWorm Breeder's Gazette(Caenorhabditis Genetics Centerが発行する線虫に関するニューズレター)といった簡易な情報誌。We-Thinkに類するどのプロジェクトもこうした場を持っているのは決して偶然ではなく本質なのだ。そうした場があるからこそ、1+1が12になるような形で人々が集うことができたのである。
We-Thinkプロジェクトではアイデアは容易に結びつく。プロダクトは通常レゴブロックのように結合可能、つまり相互接続可能な多くのモジュールから構成されているからである。このモジュラリティという概念は決して新しいものではなく、遅くとも1960年代からコンピュータ開発の特徴の1つになっていた。
当時、IBMはSystem/360というコンピュータを開発中だったが、その責任者だったフレッド・ブルックスはすべての担当者が担当外を含むすべての作業について同レベルで理解していることを求めた。そのため、プログラムの変更にかんする作業日報をすべての担当者間で共有し、毎日始業前に目を通すこととした。しかし、作業日報はほどなく厚さ5センチほどにもなり、コミュニケーションと調整のコストは急増して制御不能となり、連絡ミスと誤解が増大した。増員しても問題は解決せず、かえって事態を悪化させた。処理量は増えたが誤解も増え、それがさらにバグを増やしたのである。作業日報の厚さが150センチとなるに至って、ブルックスはSystem/360を独立した作業が可能なモジュールに分割することを決断し、コアチームを設置して必要なモジュールと相互接続を指定するデザインルールを定めさせた。つまり、モジュールの担当者は自分の作業に集中し、コアチームはシステム全体のアーキテクチャを考えるという体制を作ったのである。この体制では、改良したモジュールはそのままシステムに接続でき、モジュールを改良するたびにシステムを作り直す必要はない。
しかし、モジュラリティがその威力を本当に発揮するのはオープンな作業方式と組み合わせた場合、つまり多くの試みを並行して実施でき、さまざまなチームが同じモジュールを対象に異なるソリューションを提案できる場合である。これはオープンソースのありかたそのものであり、これこそがオープンソースが「聖杯」を獲得しえた理由、すなわち相互に接続可能でありながら中心を持たない多数のイノベーションを実現しえた理由なのである。レゴブロックには途方に暮れるほど多くの色と形と大きさがあるにもかかわらず、その接続の仕組みは同じである。これと同じように、We-Thinkプロジェクトにも接続のための規則(通常コアチームが定める)があり、これにより独立してはいても相互接続可能なイノベーションが可能となる。マスコンピュータゲームも、コラボレーティブブログも、オープンソースプログラムも、ヒトゲノムプロジェクトも、多くのモジュールが相互にピタリと結合するというこの特徴を持っているのである。
しかし、レゴのブロック構造だけでは、We-Thinkプロジェクトが機能するには不十分だ。グループでは意思決定も必要だからである。多様な貢献者が集まりアイデアを結合するには同意可能な方法でコラボレートされている必要がある。共有の場は効果的に自己規制できなければ必ず荒廃する。しかし、そうした自己規制は、言葉で言うのはたやすいが、実現ははるかに困難である。
最終回は残り2つの法則を論じ、結論を述べる。
関連記事
- 大規模なコラボレーション活動を成功に導く5つの原則――パート1
創造的活動を行うコミュニティーが成功するには、幾つかの原則を見て取ることができる。ここでは、そうした原則を紹介していこう。 - 大規模なコラボレーション活動を成功に導く5つの原則――パート3
2回にわたってコラボレーション活動を成功に導く5つの原則を紹介してきた。最終回となる本稿では、参加者相互の協力と集団による創造的な活動について考察してみよう。 - ソーシャルネットワーキングで鼻つまみ者にされる11種類の行為
今日のビジネス環境におけるソーシャルネットワーキングの重要性は、ここで言及するまでもないだろう。ここでは各分野で共通してみられる11種類の失敗を再確認する。 - ITプロジェクトを失敗させないための7つのガイドライン
組織のリソースを無駄にすることなく、ITプロジェクトによって組織の価値を高める責任は、ITマネジャーに課されている。本稿では、これから新たに進めるプロジェクトを破局に導かせないためのヒントを幾つか紹介することにしよう。 - Web2.0で起業を志す者に捧げる9つの心得
1年前に投稿されたこの記事。「来年の今ごろになれば、Web2.0などは過去の出来事の1つに成り果てている可能性すらある」と述べられているが、現状と併せて読み進めてみると、幾分の真実が含まれている。 - プロセスはITプロジェクトにとって最善の策とは限らない
ITプロジェクトの成功には、優良で、繰り返し行うのに適していて、確固とした「プロセス」が必要不可欠だ。しかし一方で、プロセス自体がむしろ思わぬ落とし穴となっている場合もある。以下では、プロセスを敵ではなく味方につけるための定番で実用的なアイデアを紹介する。
Copyright © 2010 OSDN Corporation, All Rights Reserved.