もともとの「伽藍とバザール」はいまのビジョンで終わっていた —— ネットワーク化されたシヤワセな集団プログラマー／アナキストたちが、 伝統的な閉鎖ソフトの階級社会を競争でうち負かして圧倒するという。

　かなりの懐疑論者は、納得しなかった。そしてかれらの挙げる質問は、 まともに相手をするだけの価値がある。バザール議論へのほとんどの反論は、 バザール支持者たちは従来のマネジメントが持っている生産性倍増効果を 過小評価している、という話にいきつく。

　伝統的な考え方のソフト開発マネージャは、オープンソース世界では いともあっさりプロジェクトグループが生まれ、姿を変えては消え去っていくので、 オープンソース・コミュニティーがどのクローズドソースの開発者集団と比べても、 数の上で圧倒的な優位性を持っているというメリットの大部分は消えてしまう、 と反論することが多い。かれらの主張では、ソフト開発で重要なのは長期にわたり 開発努力が継続することで、顧客が大事な製品に投資を続けてくれると 期待できるようにすることなのだ、何人が鍋に骨を投げ込んでそのまま 煮立てておこうと、そんなのは関係ない、ということになる。

　この議論には、確かに一理ある。実はぼくも、 『魔法のおなべ』で、ソフト生産の鍵となるのは 期待将来サービス価値だという考えを展開している。

　でもこの議論にはまた、大きな問題が隠されている。それが暗黙に 仮定しているのは、オープンソース開発はそういう継続的な努力を提供できない ということだ。ところが実は、従来型のマネジメントが不可欠だと考えるような、 インセンティブ構造や組織的なコントロールなんかまったくなしに、 きちんと方向性を保って有能な管理者コミュニティをずいぶん長期にわたって 維持してきたオープンソースプロジェクトはたくさんある。GNU Emacs エディタの開発は、その極端で示唆的な例だろう。15 年にわたり何百もの 貢献者たちの努力を吸収して、統合されたアーキテクチャの方向性を 維持してきている。開発者の入れ替わりは激しくて、しかもその間ずっと活動を 続けてきたのは、たった一人（開発者）だけだ。 クローズドソースのエディタのどれ一つとして、 これほどの長寿記録にかなうものはない。

　ここから出てくるのは、伽藍 VS バザール方式の議論とは独立した、 従来型のソフト開発マネジメントのメリットに対する疑問だ。もし GNU Emacs が一貫したアーキテクチャのビジョンを 15 年も維持できたり、Linux みたいな OS が同じように 8 年も、ハードやプラットホームの技術が変わり続ける中で 維持できたのなら —— そしてもし、ほかにもきちんとしたアーキテクチャを持った オープンソースのプロジェクトが、5 年以上も続いている例があるなら —— だったらわれわれとしては、そもそも従来型のマネジメント方式の開発というのは、 あれだけすさまじいオーバーヘッドをかけて、いったい何を買っているんだろう、 というのを当然聞いてみたくなるわけだ。

　それはまちがいなく、締め切りを信頼できる形で守るということではないし、 予算内にきちんとおさめるということでもないし、仕様書をすべて反映させる ということでもない。こういう目標の一つでも達成できたら、それは珍しくきちんと 「マネジメント」されたプロジェクトだと言っていい。また、 プロジェクトの寿命の中で、技術的・経済的な環境変化にも すばやく適応できているとは思えない。この点では、 オープンソース・コミュニティのほうがはるかに高い能力を 見せてきた（これはたとえば、インターネットの 30 年にわたり歴史と、 独占ネットワーク技術の短い半減期とを比べてみればすぐに確認できる —— あるいはマイクロソフト・ウィンドウズの 16 ビットから 32 ビットへの移行が えらく高コストだったのにくらべて、同じ頃に同じことをやった Linux ではほとんど何の苦労もなかったことを考えてみるといい。しかも Linux はインテル専用ではなくて、64 ビットの Alpha チップも含む一ダースもの ハードウェア・プラットホームでそれを実現したんだぜ）。

　伝統的な開発様式で買えるもんだと多くの人が考えているものとしては、 プロジェクトがおかしくなったときに、法的に縛って責任をおわせ、 可能性としては損害賠償金も得る相手ができる、ということだ。 でもこんなのは幻想でしかない。ほとんどのソフトライセンスは、 このソフトが商品として売り物になることすら保証しないような免責条項が 書かれているし、まして性能のことなんかまるっきり保証しない —— そしてソフトが期待性能に達しない場合に、損害賠償を勝ち取れたケースがあるか？ まったくないといっていいくらい、ほとんどない。 そしてそれがそんなに珍しいことでなかったとしても、 訴える相手がいるから安心なんていうのは、そもそもがピントはずれだ。 きみは訴訟がしたかったのか？　ちゃんと動くソフトがほしかったんだろうに。

　じゃあ、マネジメントのオーバーヘッドをあんなにかけて、 いったい何が手に入るんだろう。

　これを理解するには、ソフトウェアの開発マネージャたちが 何をしているつもりなのかを理解しなくてはならない。ぼくの知り合いで、 この仕事がとても上手らしき女性に言わせると、 ソフトウェアプロジェクトのマネジメントというのは五つの機能がある。

1. 目標を決めて、みんなを同じ方向に向かせておく。
2. しっかり見張って、大事な細部が見落とされないよう確かめる。
3. みんなのやる気を出させて、つまらないけれど必要などた作業をやらせる。
4. メンバーの配置を組織化して、最大の生産性をあげるようにする。
5. プロジェクトの維持に必要なリソースをひっぱってくる。

　一見どれも立派な目標だ。一つ残らず。でもオープンソースモデルと、 それをとりまく環境の中では、どれも不思議なくらいどうでもよく思えてくる。 ケツのほうから撃退していこうか。

　この友人の報告では、リソース調達のかなりの部分は、 実は手持ちの防衛なんだという。自分のスタッフとマシンとオフィスを確保したら、 同じリソースを求めて競合している同僚のマネージャたちや、 限られたプールの最有効利用を目指して配置を考えている上司たちから、 それを守らなくてはならない。

　でもオープンソース開発者たちはボランティアだし、 自分のかかわるプロジェクトについて、興味と能力で自薦により 貢献することなったわけだ（そしてこれは、オープンソースのハッキングで 給料をもらうようになったときにもおおむねあてはまる）。ボランティアの精神は、 リソース調達の「攻撃」側の面倒をみてくれる。みんな自主的に自分のリソースを 提供してくれるんだ。そして、伝統的な意味でマネージャが「防御」する必要性は、 ほとんど、いやまったくない。

　どのみち、安い PC や高速インターネット接続の世界では、限られている唯一の リソースというのは、才能ある人々の関心だけだ。オープンソースプロジェクトは、 つぶれるときにも、別にマシンやリンクやオフィスが足りないから つぶれるんじゃない。開発者自身が関心を失ったからという、それだけだ。

　そういうことなら、オープンソースのハッカーたちが、自薦によって 最大の生産性をあげるべく自ら組織化するというのは、 二重の意味でだいじになる —— そしてハッカー界の社会理念によって、 有能な者だけが容赦なく選ばれる。ぼくの友だちは、オープンソース界と 巨大閉鎖プロジェクトとの両方を知っていて、オープンソースが成功した 理由の一部は、その文化がプログラミング人口のトップ 5% しか受け入れないからだ、 と信じている。彼女は、残り 95% の動員を組織するのに時間を費やしている。 そして、最高のプログラマと、単に有能なだけのプログラマとの 100 倍もの生産性のちがいというのを、直接見せつけられているのだ。

　この生産性の差は、居心地の悪い質問をずっと投げかけ続けてきた。 ということはだよ、ソフトの個別プロジェクトや、ソフト産業全体として見ても、 使えない下半分を切り捨てたほうがずっとよくなるんじゃないだろうか。 もし伝統的なソフト管理の唯一の機能が、一番使えないやつらを、 せめて損害は出さずにトントンに持っていくくらいだとしたら、 そんな仕事は何の価値もないんじゃないかということを、 有能なマネージャたちは昔から理解していた。

　オープンソース・コミュニティの成功は、この質問をもっともっと尖鋭化する。 インターネットで自薦のボランティアをつのったほうが、 ほかのことをしていたい人たちをビルいっぱい集めて管理するよりも 安くて効率がいいことが多いという、動かしがたい証拠をつきつけているからだ。

　というところで、話は都合よく動機づけのほうにやってきた。 友人の論点と同じことを別の言い方で言っているのをよく聞く。 伝統的な開発マネジメントは、そのままではいい仕事をしてくれない、 やる気のないプログラマたちを補うためのものなんだ、と。

　この答はまた、オープンソースは「セクシー」で技術的に魅力ある仕事でしか あてにならない、という議論とセットになっていることが多い。それ以外のことは、 放っておかれるままだ（あるいはいい加減にしか処理されない）。 それをやるには、札束でひっぱたかれて、区画に閉じこめられた日雇いプログラマが、 頭上でマネージャのふりまわす鞭の響きをききつつ必死で書くしかない、 というわけだ。ぼくは、こういう主張がまゆつばだと思う理由について 『ノウアスフィアの開墾』で述べた。 でもこの文の趣旨からして、これを本当として受け入れたらどういうことになるかを 指摘するほうが、もっとおもしろいだろう。

　もし従来型のクローズドソースでマネジメント過大のソフト開発スタイルが、 退屈からくる問題でつくったマジノ線によってしか弁護できないのならば、 その議論が成立するのは、それぞれのアプリケーション領域で、 だれもその問題を本気で面白いとは思わないし、 さらに他にだれもその問題の抜け道を見つけない場合に限られる。 「退屈」なソフトにオープンソースの競合がでてきた瞬間に、顧客たちは、 その問題自体が面白いから解決してやろうという人物が、 それに取り組んでいるんだな、 というのがわかるわけだ —— そしておもしろさというのは、 ソフトに限らずあらゆるクリエイティブな仕事に言えることだけれど、 ただのお金なんかよりもずっとずっと優れたニンジンなんだ。

　伝統的なマネジメント構造を、みんなの尻を叩くためだけに持っておくというのは、 戦術的には優れていても、戦略的にはダメだ。短期的には成功しても、 長期的にはまちがいなく負ける。

　いまのところ、伝統的な開発マネジメントは 2 つの点（リソースの調達と、組織） で、オープンソースに対して勝ち目がなさそうに見える。 そして三番目の点（動機づけ）でも、先は短そうだ。 さらにあわれな包囲された伝統的マネージャは、監督面でも 点をあげられない。オープンソースコミュニティを支持する最強の議論が、 分散化された同業者レビューシステムが、細部の見落としがないようにするための 従来型のあらゆる方式など足下にも及ばないほど優秀だ、ということなんだから。

　じゃあ、伝統的なソフトプロジェクト管理のオーバーヘッドを正当化するのに、 目標設定というのくらいは救ってやれるかな？ かもね。 でも、そのためには、マネジメント委員会だの企業のロードマップだのが、 オープンソース界で似たような役割を果たすプロジェクトごとの「優しき独裁者」 や部族の長老に比べて、価値あるみんなに共有される目標を定義するのが上手だ、 と信ずべきまともな理由が必要になる。

　こいつを正面きって主張するのは、なかなかにむずかしいことだ。 そしてそれがむずかしいのは、オープンソース側がどうのというわけではない （Emacs の長寿ぶりとか、リーヌス・トーヴァルズが「世界征服」を語って 開発者の群を蜂起させられるとか）。むしろ、ソフトプロジェクトの 目標設定にあたって、伝統的な仕組みがそのタコぶりを遺憾なく 証明してきてしまったという点が問題なんだ。

　ソフト工学の、口伝理論でいちばん有名なものとして、 伝統的なソフトプロジェクトの 60% から 75% は、結局完成せずに終わるか、 あるいはその予定顧客に拒絶される、というものがある。 もしこの数字が多少なりとも真実に近いなら（そして多少なりとも 経験あるマネージャで、これを否定する人にはお目にかかったことがない）、 たぶん半分以上のプロジェクトは、現実的に達成不可能か、 あるいは単純にひたすらまちがっている目標を目指して すすんでいるということになる。

　これは、他のどんな問題にも増して、いまのソフト工学界で 「マネジメント委員会」ということばがそれを聞いた者の背中に 寒気を走らせる理由なのだ。それを聞いた人が、たとえマネージャであったとしても （いや、マネージャであればこそ、かな）。このパターンについてグチっていたのが プログラマだけだった時代は、とうの昔に過ぎ去っている。 「ディルバート」のマンガが、いまでは重役のデスクにだって 置かれているのだ。

　すると、伝統的なソフト開発マネージャへのわれわれの答は簡単だ —— もしオープンソース・コミュニティが伝統的なマネジメントの価値を 過小評価しているというんなら、なぜあなたたちのそんなに多くが、 自分自身のプロセスに対して恐怖や恐れや侮蔑を 表明しているのでしょうか？

　またもや、オープンソース・コミュニティの存在がこの質問を かなり尖鋭にしてしまう —— ぼくたちは、楽しんでやっているんだもの。 ぼくたちの創造的な遊びは、技術面でも、市場シェア面でも、精神的なシェアでも、 すさまじい勢いで成功を重ねてきている。ぼくたちは、もっといいソフトが つくれることを示しただけじゃない。よろこびが資産であることを 証明してもいるんだ。

　この論文の最初の論文から二年半たって、ぼくが最後に提供できる いちばんラジカルなアイデアというのは、オープンソースが圧勝した世界のビジョン ではない。だってそんなものは、いまではスーツ姿のしらふ人間たちにだって、 ずいぶん納得のいくものになっているようじゃないか。

　むしろぼくは、ソフトウェア（そしてあらゆる創造的またはプロフェッショナルな 仕事）についての、もっと広い教訓をここで提示してみたい。人間は仕事をするとき、 それが最適な挑戦ゾーンになっていると、いちばん嬉しい。 簡単すぎて退屈でもいけないし、達成不可能なほどむずかしくてもダメだ。 シヤワセなプログラマは、使いこなされていないこともなく、 どうしようもない目標や、ストレスだらけのプロセスの摩擦でげんなりしていない。 楽しみが能率をあげる。

　自分の仕事のプロセスにびくびくゲロゲロ状態で関わり合う （それがつきはなした皮肉なやりかただったとしても）というのは、それ自体が、 そのプロセスの失敗を告げるものととらえるべきだ。楽しさ、ユーモア、遊び心は、 まさに財産だ。ぼくがさっき、「シヤワセな集団」という表現を使ったのは、 別に「シ」の頭韻のためだけじゃないし、Linuxのマスコット がぬくぬくした幼形成熟（ネオテニー）っぽいペンギンなのも ただの冗談じゃあない。

　オープンソースの成功のいちばんだいじな影響の一つというのは、 いちばん頭のいい仕事の仕方は遊ぶことだということを 教えてくれることかもしれない。