オープンソースにおける開発方法

職業としてのシステム開発

「伽藍とバザール」の論文中では、「伽藍方式 vs バザール方式」とは別に、（オープンソース開発ではない）職業としてのシステム開発（＝伝統的開発方式）について、プロジェクト管理のあり方に対する疑問を投げかけています。その中で、バザール方式と比較した際の、伝統的開発方式のメリット（と考えられる点）として、以下を挙げています。

・仕様書通りの機能をもったシステムを、計画通りのコスト、スケジュールで開発できる。
→確かにメリットかもしれないが、成功するプロジェクトの方が少ないではないか。

・開発が頓挫した場合の責任分解点が明確になっている。
→開発を頼んだ側は、頓挫した場合に損害賠償をできるかもしれない。でもそれって、不毛な争いではないのか？

これらメリット（という程メリットではないと指摘していますが）を享受するために、伝統的開発方式が行っているプロジェクト管理は、コストが高すぎるのではないか、という論を展開しています（図2）。この内容は、オープンソース開発と職業としてのシステム開発との違いを如実に表しています。

・プロジェクトへの参加者

オープンソース開発では、プロジェクトに興味のある開発者のみが集まってきます。しかも、興味がなくなれば、容赦なく去っていきいます。しかし、職業としてのシステム開発は違います。プロジェクトには、開発者は業務命令で集まります。もちろん、興味がなくなっても去ることはできません。

・開発者のスキルレベル

オープンソース開発では、皆が同じような機能を実装しているとしても、より有能な開発者のソースが選択されます。ほかの開発者のソースは無駄になってしまいますが、有能な開発者とそうでない開発者の生産性の違いは10倍とも100倍とも言われますので、大きな問題にはなりません。しかも、有能な開発者は、前触れなくプロジェクトに参画してくるかもしれないのです（いなくなるかもしれませんが）。しかし、職業としてのシステム開発は違います。開発者は、事前にアサインされた人のみであり、スキルレベルもバラバラです。予算の制約上や社員育成の観点から、有能ではない開発者も開発を行います。

・プロジェクトの方向性

オープンソース開発では、プロジェクトに関与している有能な開発者が決める（正しいであろう）方向性に対して、開発者の好きなやり方で進んでいきます。しかし、職業としてのシステム開発では、正しいかどうかではなく、顧客が方向性を決めます。また、進め方については、プロジェクト管理の範ちゅうです。これらの方向性や進め方次第では、開発者のモチベーションを著しく下げる要因となります。

バザール方式が意味すること

なぜ、バザール方式では、ボランティア開発者の集まりにもこだわらず、高品質なソフトウエアを生産することが可能なのでしょうか。一言で言えば「好きでやっているから」でしょう。例えば、アーティストと同じと考えてください。絵が好きな人は絵を描き、歌が好きな人は歌を歌う。そして、開発が好きな人はオープンソースソフトウエアを開発する。さらに言うと「自己実現」の場であるとも言えますので、モチベーションが高く、それにより生産されるソフトウエアの品質も上がるというものです。

これに対して、職業としてのシステム開発を行う開発者は、金銭面がインセンティブになっている人が多いのではないでしょうか。もちろん、ソフトウエアが好きでこの業界に入り、開発を行っているという人も大勢いるとは思います。しかし、仕事となると、純粋に自分の好きなことをできるケースはほとんどないのではないでしょうか。ですので、開発プロセスの仕組みとして、バザール方式の考え方を全面的に取り入れることは難しいと思います。先に述べた職業としてのシステム開発であるが故の制約もあります。ですが、バザール方式の考え方は、それ自体はオープンソース開発に特化した極論かもしれませんが、織り込まれているエッセンスは、開発プロセスの仕組みとして取り入れるに十分なノウハウが含まれていると考えることができます。