コミュニケーションを促進する技術的な仕組み：オープンソースソフトウェアの育て方（1/2 ページ）

フリーソフトウェアプロジェクトを運営していくには、さまざまな情報を取捨選択する技術が必要です。本稿では、ソフトウェアを用いていかにプロジェクト内のコミュニケーションを円滑にするかを考えます。

[Karl Fogel， ]

　フリーソフトウェアプロジェクトを運営していくには、さまざまな情報を取捨選択する技術が必要です。これらの技術を使いこなせばこなすほど、また周りの人に使わせれば使わせるほど、プロジェクトがうまくいく可能性が高くなります。プロジェクトの規模が大きくなればなるほど、この傾向は強まります。うまく情報を管理しないと、オープンソースプロジェクトはブルックスの法則*1（プロジェクトの終盤になってから人を増やしたところで、かえってプロジェクトの完成が遅れてしまう） のわなに陥ってしまいます。

　フレッド・ブルックスは、プロジェクトの複雑度はそれにかかわる関係者の数の2乗に比例するとしています。メンバーの数がほんの数人の時は、簡単にお互いの意思疎通ができます。しかしメンバーが数百人規模に膨れ上がると、もはやほかのメンバーが何をしているのかをすべて把握することは不可能です。フリーソフトウェアプロジェクトを管理する秘訣（ひけつ）は、お互いがまるで1つの部屋に集まってともに働いているかのように感じさせることだといいます。では、もし混雑した部屋に詰め込まれたメンバーがみんな一斉に話し始めたら、どんなことになるでしょう？

　これは、特に目新しい問題ではありません。たとえ話ではない実際の混雑した部屋では、このような場合の解決法は議会制、つまり大人数の集団で議論を行う際の手順を決めることです。重要な異議が「異議なし！」の大合唱にかき消されないようにしたり、幾つかの小委員会を構成したり、議決方法を定義したりといったことです。

　この制度で重要なのは、その集団が情報管理システムをどのように利用するかです。“正式に記録される”情報もあれば、そうでないものもあります。記録自体は方向性を決めるためのものです。「何が起こったのか」を単に書き記したものではなく、その集団で何を合意しようとしているのかを表すものと考えます。記録は、目的によってさまざまな形式で行います。個別の打ち合わせの議事録、すべての打ち合わせの議事録をまとめたもの、その概要、議題、コメント、委員会の報告書、その場にいない通信員からの報告、宿題の一覧などが記録に含まれます。

　インターネットは実際の部屋とは異なるので、「誰かが発言しているときはほかのメンバーは静かにそれを聴く」といったしきたりにこだわる必要はありません。情報管理技術を駆使すると、オープンソースプロジェクトにおける議論の手順はより効率的になります。オープンソースプロジェクトでは、ほぼすべてのやり取りは文字で行われます。そこで、情報を振り分けたり適切なラベル付けをしたりするシステムが発達してきました。繰り返しを最小限に抑えて間違った方向に進みにくいようにしたり、データを保存して検索しやすくしたり、間違った情報や古びた情報を訂正したり、あちこちに散らばった情報をまとめてそれらのつながりを見出したりといった作業のためのシステムです。

　オープンソースプロジェクトに積極的にかかわっている人たちは、これらのテクニックを自然に身に着けており、情報が正しくいきわたるように複雑な手作業を行っていることもあります。しかし、プロジェクト全体で考えると、これらの作業にはソフトウェアのサポートが必要です。可能な限り、通信に使用するメディア自身が振り分けやラベル付け、内容の保存といった作業を行うべきです。そして、その情報は、人間が見やすい形式で利用可能にしておかなければなりません。もちろん、現実的にはまだそこまで全自動化されておらず、途中で何らかの人手が必要となるでしょう。しかし一般論として、人間側で振り分けやラベル付けのための情報を一度提供したら、後はソフトウェア側でそのメタデータを最大限に活用できるようにすべきです。

　本章でのアドバイスは、実用的なものばかりです。どれも特定のソフトウェアやその使用例に基づいたものです。とはいえ、単に特定のテクニックを教えるだけというつもりはありません。ちょっとした例をたくさんご覧いただくことで、あなたのプロジェクトにおける情報管理をよりよくするための一般的な方法を身につけていただくつもりです。これには、技術的なスキルだけでなく社会的なスキルも含まれます。

　技術的なスキルは必要不可欠です。というのも、情報管理用のソフトウェアは常に何らかの設定が必要となるからです。また、運用中にもある程度の保守作業が必要です（例えば、大きく成長したプロジェクトをどのように扱うかについて、本章の後半のバグ追跡システムをあらかじめフィルタする項で取り上げています）。

　また、社会的なスキルも必須です。なぜなら、人間の集まりについても維持する必要があるからです。さまざまなツールを使用して利益を受ける方法は、すぐに明らかになるとは限りません。場合によってはその使用法をめぐって争いが起こるかもしれません（例として、メーリングリストから配送されるメールのReply-toヘッダの設定についての議論をメーリングリスト項で取り上げています）。プロジェクトに参加している人たちは皆、そのプロジェクトの情報をうまく管理するための方法を必要としています。プロジェクトに深くかかわればかかわるほど、学ばねばならないテクニックは複雑で専門的なものになります。

　情報管理には、月並みな解決策はありません。考慮すべき点があまりに多すぎるのです。最終的に望みどおりの手段が見つかるかもしれません。コミュニティーの参加者のほとんどもその方法を利用してくれるかもしれません。しかし、プロジェクトがさらに成長したときに、その方法がそのまま使えるとは限りません。あるいは、プロジェクトの成長が安定し、開発者とユーザーの両方が現在の情報管理技術に慣れてきたときに、だれかがまったく新しい情報管理サービスを発明するかもしれません。新しくプロジェクトに参加したメンバーはきっとこう言うでしょう。「何であの便利なツールを使わないの？」。Wikiが登場しだしたころ、当時のプロジェクトの多くでまさにこれと同じことが起こりました。どのような手段を使用するかを決めるには、さまざまな判断材料があります。例えば、情報を提供する側と情報を利用する側のどちらの利便性を優先させるかも判断材料の1つとなるでしょう。あるいは、情報管理ソフトウェアの設定の難易度と、それがプロジェクトにもたらす利益とのトレードオフについても考える必要があります。

　何でもかんでも自動化しすぎないようにしましょう。実際、人手がかかわるべきところまで自動化してはいけません。技術的な仕組みは重要ですが、フリーソフトウェアプロジェクトをうまく運営するために重要なのは、結局のところ人への気配り――決しておしつけがましくない気配りなのです。技術的な仕組みは、この気配りをうまく行うための手段に過ぎません。

[1] 1975年に出版された彼の著書「The Mythical Man Month」（邦題:「人月の神話」） に登場した法則。The Mythical Man-Monthおよび（日本語）を参照してください。