まえがき
この記事は、社内共有するための記事を一部書き換えて転載したものである。弊社ではリモートワークでの協業の問題や、チームの分権化・自律化を目指すいくつかの実践が実施されていて、他の多くのIT企業も似たような状況だと思う。
実は、Linuxを始めとするオープンソース開発では、地理的に分散し、分権化したチームを運営し、プロダクトの求心力を保ってきた歴史がある。その歴史を紐解くことで、現在の我々に必要なヒントが得られるのではないかと考え、『オープンソースの成功―政治学者が分析するコミュニティの可能性』を底本にまとめてみた。ソフトウェアエンジニアにとっては当たり前のことも多いが、改めて考え直して整理しなおすことや、他職種が見てまた新たな視点が得られることを期待している。
まず、オープンソースについて知らない人のために、RedHatのWEBサイトから説明を引用する。
オープンソースとは、元々はオープンソース・ソフトウェア (OSS) を指す言葉でした。オープンソース・ソフトウェアは、誰でもアクセスできるように設計されたコードで、誰もが好きなように表示、変更、配布することができます。分散型の共同作業で開発され、ピアレビューとコミュニティでのプロダクションが大きな役割を果たしています。また、単一の作成者や企業ではなく、コミュニティによって開発されているため、多くの場合、プロプライエタリーなソフトウェアよりも安価で柔軟性に富み、長期にわたって利用できます。
オープンソースは 1 つの運動となり、その影響力はソフトウェア生産以外の活動にも及びました。オープンソース運動は、オープンソース・ソフトウェアの価値と分散型の生産モデルを使用して、コミュニティや業界が抱える問題を解決する新たな方法を見出すものです。
この記事では、代表的なオープンソースプロジェクトのLinux（リナックス）に注目し、そこから学べるかもしれないプラクティスを抽出する。Linuxはリーナス・トーバルズ（引用元によってはリーヌス）が開発を始めたオペレーションシステム（OS）で、タイトルのバザール方式という聞き慣れない言葉は、そのLinuxの開発プロセスを評した『伽藍とバザール』という本によって提案された。この本は『オープンソースの成功』でも度々引用されており、従来の中央集権的な方法を「伽藍（大聖堂）」の建築づくりに、非中央集権的なオープンソース開発を「バザール」に喩えて説明している。
また、私自身はオープンソース開発の経験がほとんどない（ライブラリのインストールエラーがあってプルリクを送った程度）し、Linuxの開発当初の状況もリアルタイムでは知らないので、何か間違いや補足があったら教えてほしい。
オープンソースプロジェクトはなぜ注目されたのか？
まず、比較のために、ソフトウェアプロジェクト管理の名著『人月の神話』の時代を見ていこう。
この本は1975年に著者のIBMでのオペレーションシステム（OS）の開発の経験を基に書かれたものである。たとえこの本を読んだことがなくても、IT業界にいるなら「遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである」というブルックスの法則は耳にしたことがあると思う。『オープンソースの成功』から要約の一部を引用する。
まず、アーキテクチャと実装との間に、できる限りきれいな線引きをする。システムを設計し、マスタープランを作り、意図する結果の想像上のモデルを握るのは、このアーキテクチャだ。システムを可能な限り独立した状態で実装できるサブシステムに分割する責任はアーキテクトが担う。次が、ミルズの言うところの外科チーム的な構造実装チームの出番だ。それぞれのチームにはサブアーキテクトがいて、実装チームを指揮する（手術室で指示を出す執刀医のようなものだ）。このプロセスは、チーフアーキテクトが構築しようとするプロジェクトの複雑さに応じて再帰的に繰り返され、重層的な分業体制になる。
ブルックスのアプローチの中核部分は、フォード式産業組織をわずかに修正したものだ。これは批判ではない。フォード式分業体制は、ある種の商品の組み合わせについては、すさまじい成功を収めた。
『人月の神話』では、プロダクト開発について次のような議論が展開されていく。
- 一つのプロジェクトに関わるプログラマーの人数が増えても、仕事の量は人数nに比例するだけだが、バグへの脆弱性はnの2乗に比例する。それはチームメンバーのコミュニケーションパスが増えたり、分担可能性の低い作業を分割したりことによって、元々無かった仕事が増えるからだ（そしてこれらがブルックスの法則の理由である）。
- だから「コンセプトの完全性」を目指すなら少数精鋭チームがいいが、その方法は大規模なシステム開発では実現しない。
- そのため、作業の分割と機能の専門家を行い、組織を階層構造にしよう。そうすればコミュニケーションパスが増えることもない。
「コンセプトの完全性が重要で、一人またはごく少数の頭脳から考え出されなければならない」とされている。これはトップのアーキテクトが中央集権的に意思決定していることを示唆している。プロジェクトの進め方に目を向けると、現在「アーキテクトが良い設計して、開発者に回す」という形になっている。いわゆるウォーターフォール・モデルに近いと言えそうだ。
アジャイル開発の時代になっても、「最初から完璧なコンセプトを作るのは無理なので、スプリントに分けて修正しながら作ろう」「現場からの知見をバックログに吸い上げよう」という方針になったものの、組織構造の「組織に階層性を持たせてコミュニケーションパスを減らし、各層のトップが判断する」という根本の発想には議論が入っていないと思う。
ところが、1990年代にLinux（リナックス）が登場し、同じく大規模なOSであるにも関わらず、それまでの常識と違う非中央集権的なアプローチで実用的なシステムを実現したことで注目を集めた。Linuxは最も成功したOSだと言ってよく、一般用のPCで使われることは少ないものの、例えばLIFULLのWEBサービスもほとんどがLinux上で動いていて、AndroidのスマートフォンもLinuxベースのOSで作られている。
『伽藍とバザール（原文の発表は1998年）』では、そのときの様子を次のように熱っぽく語っている。
リナックスは、ぼくがわかっていたつもりでいたものを、根底から覆してくれた。それまでだって、小さなツールや高速プロトタイプ作成、進化的プログラミングといったユニックスの福音は説き続けてはいた。でも、もっと上にレベルではなにかどうしようもない複雑な部分ができてて、もっと中央集権的で、アプリオリなアプローチが必要になってくるものだとも思っていた。（中略）
だからリーヌス・トーバルズの開発スタイルー早めにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンするには全く驚かされた。静かで荘厳な伽藍づくりなんかないーリナックスコミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった（これをまさに象徴しているのがリナックスのアーカイブサイトで、ここはどこのだれからでもソフトを受け付けてしまう）。そして、そこから一貫した安定的なシステムが出てくるなんて、奇跡がいくつも続かなければ不可能に思えた。
このバザール方式がどういうわけかまともに機能するらしく、しかもみごとな結果を生むなんて、衝撃以外の何物でもなかった。（後略）
余談だが、引用にあるUNIX（ユニックス）は後にLinuxなどの祖先になった先駆的なオープンソースOSだったが、1980年代の中盤からライセンスを有料化し、コミュニティが反発して派生OSが多数生まれ、派生OS間で揉めて標準化が妨げられ…というようなひどい状態だったらしく、その失敗体験のせいで特に「ある程度の規模のプロダクトは（企業が）中央集権的に管理しないと成立しない」と考えられていたんじゃないかと思う。
これらの問題もあって、当時はオープンソース文化（※というより、古き良き時代のコンピュータはユーザーがプログラマーに限られており、ユーザー間のソースコードの共有やサポートはある意味当たり前だった）自体の存続が悲観視されていたらしく、80年代半ばに発表された『ハッカーズ』ではGNUプロジェクトを創始したリチャード・ストールマンが最後のハッカー（※ハッカー文化を参照）として描かれている。
オープンソースプロジェクトはどのように開発されているのか？
それでは、オープンソースプロジェクトにおいて、分散チームがどのような工夫によって成り立っているかを整理しよう。開発者は次のような流れで参加することが多く、これらの各項目に沿って説明していく。
- 開発者自身が貢献するプロジェクトを決める
- 開発者が文書でのコミュニケーションを通じて、開発に必要な情報を手に入れる
- 開発者が修正したコードを提案する
- そのソフトウェアの運営者がその修正を取り込むか判断する
①開発者自身が貢献するプロジェクトを決める
まず、（定義上ある意味当たり前だが）開発者自身が取り組む課題を決めるということが特徴的である。
ここで「開発者は何をモチベーションに開発に参加するのか」という疑問がでると思うが、少なくとも一部の開発者では、この「自分で選べる」ということがモチベーションの源泉となっている。
もちろん、この種の動機は、独占ソフトウェア企業でも基本的なレベルでも機能している。だが、こうしたプログラマーは普通は、解決すべき問題を指定する上司がいる。そして、解決方法は最終的には見えなくなっている。オープンソース開発者は、自発的に取り組む問題を選び、その結果は誰でも万人に公開する。それは個人的な意味で、非常に掛け金の高いゲームだ。というのも、自由な選択のおかげで、その努力はただの趣味や仕事よりも自意識的に高いものになっているからだ。
「自分の作品の質を示す実証行動として」参加するモチベーションもあるといい、評判経済と関連づける人も多い。ただ『オープンソースの成功』は「もしそうなら、戦略的に分派させ、プロジェクトリーダーとしての評判を奪うことを画策する人がもっと現れるはずだ」という疑問を提示している。
また、「プログラマーの能力は成績や年齢、人種ではなくプログラミングの能力で判断せよ」「コンピュータは芸術を作り出せる」というようなハッカー文化が影響していて、また一部はその信念がモチベーションになっていることもあるらしい。どんなものか知りたい人は『伽藍とバザール』のエリック・レイモンドが書いた別のWEB文書『ハッカーになろう（How To Become A Hacker）』を読もう。
もちろん、単に「仕事で使っているライブラリでバグを見つけたので修正した」というような開発者も多いと思う。
また、『オープンソースの成功』では、オープンソースソフトウェアではフリーライダーが迷惑にならず、むしろその一部がメリットを提供する「反競合財（※著者の造語）」であるという興味深い議論がある。
要するに、オープンソースソフトウェアは、貢献者にとっての財の集積を減らさずにフリーライダーを容認できるという意味での非競合財にとどまらないということだ。それは、システム全体がフリーライダーによって正の便益を受けるという意味で、実は反競合財になっている。こうしたフリーライダーの（ごくわずかな）一部は共同の産物に何か価値のあるものを提供する――それが単に、バグに怒ってそれを報告したり、新しい機能を求めたり、もっと上手に実装できるはずの機能について文句を言ったりするだけであっても。それどころか、ここで「フリーライダー」という用語を使うべきかどうかも迷うところだ。とはいえ、それはさておき――この環境では、「フリーライダー」が多ければ多いほどありがたい。
つまり、インターネットで多数の利用者を集められ、その中に開発者（プロジェクトに貢献できる人）の割合が高いことが、バザール方式が成立する条件であるかもしれない。もしこれが正しければ、過去のUNIX派生OSと違ってLinuxが発展したのは、ちょうどその間にインターネットが発達し、より数多くのユーザー兼開発者にリーチできたことも一因であるとも言えそうだ。
②文書でのコミュニケーションを通じて情報を手に入れる
また、「バザール方式」という名前から想像するイメージとは裏腹に、決して無秩序に開発が進められているわけではない。
そのコミュニケーションは文書で行われ、開発にあたっては、他の開発者やプロジェクトの方針に沿った課題をまとめている場所（GitHubでいうとIssue）をチェックし、必要に応じて質問しながらドキュメントやソースコードを参照して修正方法を考える必要がある。つまりソフトウェアエンジニアリングのスキルに加え、ある程度の文章力と読解力が求められる。
文章力の問題については『賢い質問のしかた（How To Ask Questions The Smart Way）』という有名な文章があり、これもなんとエリック・レイモンドが書いている。
また、プロダクトの方針についての議論も、メーリングリストなどで活発に行われていることが多い。
（私はLinuxをそこまで追ってないので別の例で恐縮だが）オープンソースなプログラミング言語であるPythonでは、PEPというドキュメントに新機能が議論・提案され、それが採択されるまでの議論（もしくは不採択の理由）が残っている。これは単なる利用者にとっても「この機能ってどういうケースを想定して作られたものなんだっけ？」ということが分かる有意義な情報源である。
つまり、オープンソース開発ではコミュニケーションパスを制限せず、代わりに「パブリックで文書に残る形で議論を行って、そのログを必要なときに誰でも参照（検索）できる」という形でマネジメントしているようだ。
実際のところ、トーヴァルズのリーダーシップで最も特筆すべきところは、意見の分かれる問題に決定を下す際の正当化、説明、文書化に労をいとわないこと。そして間違いを犯した場合や考えを変えた場合にそれを認めることだ。トーヴァルズは直観的にこれを理解しているらしい。Linuxプロジェクトの創始者としてのリーダーシップのあやうさを考えれば、信奉者たちを失望させる方法はただ一つ――彼らに応えないことだ。そうすることで意見の違いがなくなるわけではない。むしろ、管理の下でとはいえ、意見の相違をうながしている。結局、トーヴァルズは慈悲深い独裁者なのだが、風変わりな独裁者――配下の開発者たちが進んでその権力を受け入れ続ける人物なのだ。
ちなみに、慈悲深い独裁者は「コミュニティ内で論議、論争が発生した際に最終的な仲裁を行う権利を持つプロジェクト創設者」という意味の用語である。また、『オープンソースの成功』では、リーナスのリーダーシップが「カリスマ的だが控えめ」と評されており、Linux初期の時代に次のように発言しているらしい。
「『コントロールを保つ』ことについてのぼくの立場を一言で言うと、保たない。Linuxに関して現在もきちんとコントロールできていることはただ一つ、誰よりもLinuxをわかっていることだ。」
コンセプトの完全性も放棄し、後から変更することもあるし、なんならコンセプト自体を完全にはコントロールしようとしない、ただ意思決定の説明はしっかり行うというスタンスのようだ。
ただ、リーダーシップのとり方はコミュニティによってけっこう異なるようで、リチャード・ストールマンの場合は強力なフリーソフトウェアの思想が推進力になっているらしい。
ただし、全ての情報が無制限に公開されているわけではなく、例えばセキュリティの懸念がある場合などは、運営者側でクローズドな形で議論され、後から変更内容が発表されるようなこともある。たしか2018年のSpectreとMeltdown（CPUのセキュリティ問題）の対応がその一例だったと思う。
③修正したコードを提案する
開発者は問題を報告し、もし可能であれば修正したコードを提案し、運営者が取り込むかレビューするのを待つ。
これらはGitHubを使っていた場合では、Issueとプルリクエストの機能にあたる。また、実験的な変更は、安定版とは別の開発版として公開され、意欲的なユーザーからのフィードバックやバグの報告を受け付けていることがある。
これまた余談だが、数々のUNIXの派生OSと違ってLinuxが求心力を失わなかったのは、リーナスのリーダーシップに加えて、これらの方法が実現できる優れたバージョン管理システム（Git）があったことも一因じゃないかと思う。実はGitもLinuxのソースコード管理のためにリーナスの作ったオープンソースプロダクトであり、現在では「プログラマーが普通に生活してたらこれ使ってるよね」くらいの当たり前の存在になっている。
『伽藍とバザール』では、こうした方法を「早めのリリース、ひんぱんなリリース、そして顧客の話を聞くこと」として、次のように解説されている
リーヌスは、デバッグと開発に投入される人・時間を最大化することをずばり狙っていたわけだ。コードの安定性が犠牲になったり、なにか深刻なバグがどうしようもなくなったら、ユーザ基盤に見放されるかもしれないという危険をおかしてまでそれをやっていた。
ただし、これは後述する事件によってバージョン管理システムの導入される前の話のはずで、おそらく「コードの安定性を犠牲にせずに頻繁なリリースとテストができるようになった」というほうが現状に近いだろうと思う。
④ソフトウェアの運営者が取り込む
開発者から寄せられたバグの報告や修正、ときには機能の提案は、ソフトウェアの運営者によって精査される。必要であればその修正の不備や意図について、レビューや議論をする必要がある。
ただし、薄々感じる通り、これはやはり運営者の負担がかなり大きいらしい。実際に、1998年にリーナスが開発者に反応できなくなり、一部の開発者に不満を持たれ、Linuxがフォーク（分派）されそうになったことがある。この時期にリーナスは第二子が生まれ、フィードバックやメディアからの取材も増えていて、デイヴ・ミラーら開発者との間でメーリングリスト上で感情的なやり取りが続いたそうだ。
このとき、エリック・レイモンドの仲裁でなんとか取り持ち、話し合いの場が持たれたらしい。そして解決策として、バージョン管理システム（当時はBitKeeperで後にGitになった）の導入と、階層型組織のようなものを設けることが決定された。
こうして一九九八年九月末に、トーヴァルズとミラーを含めた中心人物がシリコンバレーに集まり、珍しく顔を合わせて夕食を共にした。トーヴァルズの受けているプレッシャーをいくらか和らげる方法について、技術を共通の基盤に議論が交わされた。トーヴァルズはメディアの露出を減らし、エリック・レイモンドに「宣伝大臣」の役目を任せることになった。それよりも重要なこととして、パッチとソフトウェアの投稿を扱うにあたり、さらに公式なピラミッド型階層のようなものを設けることが、この席で同意されたのであった。
現在の他のオープンソースプロジェクトでも、コアメンバーによる小さな階層的な組織を持っていることが多い。このことから、私は結局、意思決定の問題をスケールさせるためには、ある種の階層組織や官僚制は必要なんじゃないかと思う。ただ、その規模や必要性はそれ以前にあったチームよりも小さくなっているはずだ。
重要なことだが、Linuxの意志決定階層はそれでも非公式なものだ。プログラマーたちはたいてい内輪の重要性を認識しているが、誰がどの時点でどの立場にあるかを特定する文書や組織図は存在しない。（中略）この図式から、コックスはLinuxの副総裁とでもいうべき立場におかれているのだ。だが、トーヴァルズがコックスを選んだわけでもなければ、この役割を公式に任命したわけでもない。コミュニティ内でひとりでに確立した専門家的な立場をコックスがただ受け入れただけのことだ。
また、アジャイル開発ではプロダクトオーナーが最終的な意思決定権を握ってコントロールする（以下にスクラムガイドの該当箇所を引用）ことが多く、リーナスのやり方は「リーダーが決定権を他人に任せている部分がある」「開発者自身が取り組むべき課題を選んでいて、リーダー（たち）が受け入れるか判断する」という点で異なっている。
プロダクトオーナーは 1 人の人間であり、委員会ではない。プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合がある。ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する。
また、現在では企業が運営者となっている場合も多く、例えばAWSのAPIクライアントライブラリや、最近では機械学習のライブラリ（FacebookのPyTorchなど）などがある。この各企業のビジネスモデルやモチベーション（自社サービスへの誘導、ブランディングなど）の話も面白いが、また長くなってしまうので『オープンソースの成功』を読んでみてほしい。
現代のテック企業文化との類似
余談だが、『ユニコーン企業のひみつ』によって話題になったSpotifyの企業文化も、オープンソースコミュニティと類似しているところが多いと感じている。どちらもチームへの分権化や自律性を重視した結果、似た形になったのかもしれない。そのため、過去のオープンソース文化の発想を学ぶことは企業チームにとって有意義だと考えている。
例えば以下のような要素だ。
- カンパニーベットという「会社が取り組みたい重要事項を、終わらせたい順に並べたリスト」が利用されている。GithubのIssueの概念を企業運営にも拡張したものに見える。
- 情報をオープンに公開する。
- リリーストレインやフィーチャーフラグというプラクティスを使って頻繁なリリースを実現している。アジャイル開発の一般的な方法では「数週間のスプリントで区切り、その最後のスプリントレビューでOKが出たならリリース」という形であり、それらのやり方よりリーナスのやり方に近づいていると思う。
- 開発者が所属先を選ぶ。これはオープンなコミュニティじゃないと成立しないと思っていたので驚いた。ただ、実験的にやってみたような書き方で、どれくらいいつもこの方法を取っているのかは分からない。
- 社内でオープンソースモデルを使っていて、他チームからのバグ修正も可能にしている
ただし、彼らがオープンソース開発を直接意識したわけではなさそうで、この比較は都合のいい引用であることは留意してほしい。
まとめ
我々が普段企業内で行っているアジャイル開発と比べると、次の点が興味深かった。また、これらの点の多くは『ユニコーン企業のひみつ』で紹介されたSpitifyのやり方とも重なっており、興味深い。
- 開発者自身に取り組む課題を判断させる
- オープンなドキュメントで情報をやり取りする
- パブリックな場でプロダクトの方針を議論し、議論のログも残す
- プロダクトオーナー1人で意思決定する必要はない
- スプリントやタイムボックスではなく開発者のペースで実装してよい
ただし、企業のチームでは、教育や採用、評価といった問題も考えなければならない。これらの点についてオープンソースは「有名になるほど開発者を集めやすく、その中の一部が貢献できればいい」「貢献の内容が有意義なら他の開発者に評価される」くらいのことしか言っていない。これらは別の機会に考えようと思う。
もっと考えたい人のための文献リスト
- TEAM OF TEAMS: アメリカ軍が分権化された組織（アルカイダ）に苦戦し、複雑性・不確実性に対処するために適応型組織を目指した内容。文脈が異なるが、似た議論が多くて面白い。ビジネスサイドの人はこれ読んでほしい。
- オープンソースの成功―政治学者が分析するコミュニティの可能性: この記事のパクリ元。面白いが難しいので要約に苦戦した。
- 伽藍とバザール: この記事のパクリ元2で、Linuxの開発コミュニティを解説したもの。ただちょっとむやみに褒めすぎ感はある。
- 人月の神話: ITの開発に関わっている人はとりあえず読んでほしい。