旧THE BBL とは？
ある時、とある掲示板サイトで「みんなでオリジナルOSをつくってみないか？」という話題が起こりました。多くの
人がこれに興味を持ち、それ専用のスレッドが作られました。のちにそのスレッドにて「THE BBL OS」という名前
が決まり、また沢山の人が参加を表明。「THE BBL プロジェクト」という形ができあがりました。
意欲的な成り立ちでしたが、この体制はみるみる崩壊してゆきました。
さまざまな要因がありましたが、その中で特に、これからこういったプロジェクトを作ろうと思っている人に
参考にしてほしいものがあります。
（いまでも時々、とてもよく似た形でプロジェクトを立ち上げようとする人がいらっしゃるので）
旧THE BBLにはどんな問題があったのか
旧THE BBLプロジェクトには、合議制とメンバー制という柱がありました。
- 合議制
- 文字通り、合議によって意思決定を行い進めてゆこうというもの
- メンバー制
- 参加なり退会なりを明確にし、メンバーという地位を設定しました。メンバーには会議に参加する なり勉強をするなりの義務あるいは推奨が課せられるような方向だったようです。（よくわからん）
これらがどういった目的で設置されたものなのかは、今となっては正確にはわかりません。
（私が知った時には既にこの体制が明記されていたので）
憶測ですが、「極端な民主主義」を実現しようとしていたようです。小さい子に民主主義の理念を
教えると、妙な勘違いをすることがありますね。あれに近かったのではと感じています。
もちろんそこに、悪意があったとは思えませんが。
結果、どんな問題が起こったか？
みんなでと平等にという理想と誤解
- 「鼻の咬み方」すら決定できない
-
合議制。すなわち、みんなで話し合ってという理想が先行していました。当初は参加者もそう多くなく、
また出てきた意見をそう真剣に捕らえていなかったのでしょう。掲示板に書かれたことが、なんとな〜く決まって
ゆきました。しかし人が増えればかならず別の意見や提案が起こります。ある地点を境に、
「このままではよくない。 ちゃんと決めよう」
という意見が増えてきました。しかしここで実にくだらない問題が起こりました。
「会議で決める」だけは決まっていましたが、その「会議の方法をどうやって決まるか」という。 （卵が先か鶏が先か・・・）
「複数の人間が会議なり話し合いを行い、物事を決める」ということそのものは、決して悪いことではありません。 （こういうプロジェウトの場合、極端に不向きでデメリットが多いということはちょっと置いておいて）
しかし、複数の、そして生まれも環境も年齢も違う人間達の意見が満場一致するなどということはありえません。 かならず多数決なり投票なり、リーダーへの一任なりが必要です。この最終決定のプロセスを置き去りにして ものを進めてしまったようです。
結果はご想像通りでした。掲示板のスレッドでは何度も「xxxを決めよう」という提案がされましたが、その たびにろくに対案が示されないまま「意見」だけが投稿され、議論は堂々巡り。文字通り「鼻の咬み方すら決定できない」 まま、いたずらに時間とスレッドだけが消費されてゆきました。
これに危機感をもち、なんとかしようとした人もいましたが、「危機感がなく、なんとかもしたくない」人もまた 存在しました。「どんなに頑張って意見しても結局はなにも進まない」という状況に、どんどん絶望感が広がって いったのではと感じています。
- 「チームで行う」の期待と勘違い
-
Linuxを考えてみましょう。Linuxは世界中の、そして沢山のハッカーによって開発・メンテナンス・デバッグが
行われていますね。さらに各部門でも、ドライバを専門に行う人、ドキュメントを書く人、広報を行う人等等、
沢山のチームに別れて作業が行われています。
旧BBLは、どうもこんな感じを目論んでいたようです。
（実際にLinuxの体制を直接参考にしたかどうかは定かではありませんが）
カーネル班・ブートローダー班・シェル班等と分割し、チーム単位で別々にプログラムを行うという提案が あちこちありました。
しかし、この構想もご想像通り、あっというま・・・どころか、一度も日の目をみないまま崩壊しました。
チームで別れ、得意分野で別々にプログラムする。一見とてもよい構想に見えます。たま、例に出したLinux などはまさにこれですね。いったいなぜ？？？？
チーム構想は悪いものではありません。しかし、実はこれは一人きりで作業を行うことに比べ、はるかに 難しく、スキルが必要なことなのです。チームとチームをつなぐパイプに相当する部分。実際にはそれは、 「API仕様の決定と実装」「全体の構造の把握と評価」「しっかりした指揮系統」「高い求心力」等が 必要になります。旧BBLは、こんな高度な部分を誰に任せるつもりだったのでしょう？ もしくは、そんなことが自分達にできるとでも思っていたのでしょうか?。
・・・実は、これはちょっと違います。旧BBLは、そんなに深く考えていませんでした。むしろ、
「チームで分かれてプログラムすれば量も少なくなるし、知識や勉強も一部ですむ。楽なはずだ」
という、とんでもない勘違いをしていたのです。
「分けたほうが楽なはずだ」という勘違いはその後ずっと尾を引きます。 後半になると、「マイクロカーネルにすればカーネルをみんなで作れるしデバッグもしやすい」などと いうことを平気で書いていますので。
みんなでというのは、自分が楽をしたり苦手なことをしたくないための方便ではありません。
そして役割分担は自ら名乗り出て行うものであり、嫌いなことを人にやらせるためのテクニックでも ないのです。
Linuxのリーナス氏は最初、プログラム・アーカイブ・ドキュメント・広報等、全て自分でやっていました。
OSASKの川合氏やMonaのひげぽん氏も同じです。あの堀江元社長ですら、最初は自分でCGIを書き、帳簿をつけ、 銀行にお金を借りにゆき、お風呂の掃除をしていました。 - その人は、「いざとなれば俺がやる！」と考えているのか
- 俺は、「いざとなれば俺がやる！」と考えているのか
まとめ
誤解してほしくないのは、「チームで」なり「合議で」なりが悪いのではありません。（もちろん良いとは
思えないのですが）
非常に優れたリーダーやカリスマを持った中心メンバーがいれば、もしかしたら画期的な成果を挙げることが
できたかもしれないという可能性も、ゼロではないでしょう。
しかし、自分がそれほどすごい人間なのか。
自分が所属するプロジェクトにそんなすごい能力を持った人間がホイホイいるのか。
これを考えれば答えはおのずと出てきます。アニメじゃないのですから。
みんなでという、心地よいフレーズに魅かれた時、今一度考えてみてください。
いまでも時折、旧THE BBLのような話がふっと沸いてくるのを見かけます。
そんな時、旧THE BBLがなぜ崩壊したのか。なにがいけなかったのか。こういったことを是非、
貴重な失敗の資料として頂けたらと思い、まとめてみました。