第3章 技術的な問題

フリーソフトウェアプロジェクトを運営していくには、 さまざまな情報を取捨選択する技術が必要です。 これらの技術を使いこなせばこなすほど、また周りの人に使わせれば使わせるほど、 プロジェクトがうまくいく可能性が高くなります。 プロジェクトの規模が大きくなればなるほど、この傾向は強まります。 うまく情報を管理しないと、オープンソースプロジェクトは ブルックスの法則 ^[15] (プロジェクトの終盤になってから人を増やしたところで、 かえってプロジェクトの完成が遅れてしまう) の罠に陥ってしまいます。 Fred Brooks は、プロジェクトの複雑度はそれにかかわる関係者の数の ２乗に比例するとしています。 メンバーの数がほんの数人の時は、簡単にお互いの意思疎通ができます。 しかしメンバーが数百人規模に膨れ上がると、 もはや他のメンバーが何をしているのかをすべて把握することは不可能です。 フリーソフトウェアプロジェクトを管理する秘訣は、 お互いがまるでひとつの部屋に集まってともに働いているかのように感じさせることだといいます。 では、もし混雑した部屋に詰め込まれたメンバーがみんないっせいに話し始めたら、 どんなことになるでしょう?

これは、特に目新しい問題ではありません。 たとえ話ではない実際の混雑した部屋では、このような場合の解決法は 議会制、つまり大人数の集団で議論を行う際の手順を決めることです。 重要な異議が「異議なし!」の大合唱にかき消されてしまわないようにしたり、 いくつかの小委員会を構成したり、議決方法を定義したりといったことです。 この制度で重要なのは、その集団が情報管理システムをどのように利用するかというところです。 "正式に記録される" 情報もあれば、そうでないものもあります。 記録自体は方向性を決めるためのものです。 「何が起こったのか」を単に書き記したものではなく、 その集団で何を 合意 しようとしているのかを表すものと考えます。 記録は、目的によってさまざまな形式で行います。 個別の打ち合わせの議事録、すべての打ち合わせの議事録をまとめたもの、 その概要、議題、コメント、委員会の報告書、 その場にいない通信員からの報告、宿題の一覧などが記録に含まれます。

インターネットは実際の部屋とは異なるので、 「誰かが発言しているときは他のメンバーは静かにそれを聴く」 というようなしきたりにこだわる必要はありません。情報管理技術を駆使すると、 オープンソースプロジェクトにおける議論の手順はより効率的になります。 オープンソースプロジェクトでは、ほぼすべてのやりとりは文字によって行われます。 そこで、情報を振り分けたり適切なラベル付けをしたりするためのシステムが発達してきました。 繰り返しを最小限に抑えて間違った方向に進みにくいようにしたり、 データを保存して検索しやすくしたり、 間違った情報や古びた情報を訂正したり、 あちこちに散らばった情報をまとめてそれらのつながりを見出したりといった作業のためのシステムです。 オープンソースプロジェクトに積極的にかかわっている人たちは、 これらのテクニックを自然に身に着けており、 情報が正しくいきわたるように複雑な手作業を行っていることもあります。 しかし、プロジェクト全体で考えると、これらの作業にはソフトウェアのサポートが必要です。 可能な限り、通信に使用するメディア自身が 振り分けやラベル付け、内容の保存といった作業を行うべきです。 そして、その情報は、人間が見やすい形式で利用可能にしておかなければなりません。 もちろん、現実的にはまだそこまで全自動化されているわけではなく、 途中で何らかの人手が必要となるでしょう。 しかし一般論として、人間側で振り分けやラベル付けのための情報を一度提供したら、 あとはソフトウェア側でそのめたデータを最大限に活用できるようにすべきです。

本章でのアドバイスは、実用的なものばかりです。 どれも特定のソフトウェアやその使用例にもとづいたものです。 とはいえ、単に特定のテクニックを教えるだけというつもりはありません。 ちょっとした例をたくさんご覧いただくことで、 あなたのプロジェクトにおける情報管理をよりよくするための 一般的な方法を身につけていただくつもりです。 これには、技術的なスキルだけでなく社会的なスキルも含まれます。 技術的なスキルは必要不可欠です。というのも、 情報管理用のソフトウェアは常に何らかの設定が必要となるからです。 また、運用中にもある程度の保守作業が必要です (たとえば、大きく成長したプロジェクトをどのように扱うかについて、 本章の後半 の 「バグ追跡システムをあらかじめフィルタする」 で取り上げています)。 また、社会的なスキルも必須です。なぜなら、 人間の集まりについても維持する必要があるからです。 さまざまなツールを使用して利益を受ける方法は、 すぐに明らかになるとは限りません。場合によってはその使用法をめぐって争いが起こるかもしれません (例として、メーリングリストから配送されるメールの Reply-to ヘッダの設定についての議論を 「メーリングリスト」 で取り上げています)。 プロジェクトに参加している人たちはみな、 そのプロジェクトの情報をうまく管理するための方法を必要としています。 プロジェクトに深くかかわればかかわるほど、 学ばねばならないテクニックは複雑で専門的なものになります。

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

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