この一連の論文は、フリーソフトの作者や協力者たちには、協力する大きなメリットがあることをはっきり指摘した。それは、自分の使うソフトが改善されるということだ。バグがあるソフトはトラブルが多発して時間が無駄になる。でもぼくがそのソフトのバグを見つけてなおせば、その後はリナックスを使うときのエラーが減る。そしてそれを報告して取り入れてもらえば、将来はそうしたトラブルに悩まされずにすむ。自分の使いたい機能を作って取り入れてもらえば、そのソフトは自分のニーズにあったものとなる。
そして、多くの人の行う協力がほんのわずかだということが、このシステムの成立にはかえって役立つ。多くの改良はあまりに小さなもので、それだけを切り出して売り出せるわけではない。だったら、そんなところで小銭を稼ごうとするよりは、みんなに公開してソフトそのものの利用価値を高めるほうがいい。他にも多くの人が同じ発想で細かい改良を持ち寄れば、自分のちょっとした貢献をはるかに上回る勢いでソフトが改良される――それがさらにそのソフトの利用者を増やし、貢献者を集めることになる。
通常のソフト開発であれば、人が増えるにつれてだんだんその管理がむずかしくなる。仕様設計、作業の調整、協調、エラーのチェック、工程管理等々、ついでにそれに伴う人事や福利厚生。そして、それが増えればさきほど紹介したコースの天井にいずれはぶちあたってしまう。でも、フリーソフトのやり方であれば、こうしたものがない。「こうしたほうがいい」と思えば、それを思いついた人がソフトを書けばいい。出てきたものを見て、それがこのソフトの機能として必要なものか判断すればいい。ソフト開発の中心チームによる方針設定と各種の貢献の仕分けさえできれば――そしてその方針が納得のいくものだとみんなが思えば――あとは自然に動く。実際のプロジェクトはこんな甘い物ではないけれど、これがフリーソフトの基本的な理屈だ。
そしてここに1つの示唆がある。集合知というのは、「みなさん参加してください」といえば人が勝手に集まってくれるようなムシのいい話ではない。参加するメリット――それは金銭的なものではないかもしれないが、でも何かしらのメリット――は絶対に必要だ。そしてそれ自体としてはつまらない（売れない）ものをみんなから集めることで、全体としては大きなメリットを提供しなくてはならない。たとえばグーグルの検索はまさにその例だ。みんなが検索を行い、その結果を使うことで、さらに検索の精度は高まる。それにより、もっとその検索を使う人が増える――集合知の利用にはこうした条件が必要となる。
【連載バックナンバー】
第1回 みんなの力で英語のヒアリング？日常の中の集合知
