第3章 技術的な問題

目次

プロジェクトに必要なもの
メーリングリスト
スパム対策
投稿のフィルタリング
アーカイブでのメールアドレスの処理
識別しやすいヘッダ
Reply-to はどうすべきか
私のふたつの夢
アーカイブ
ソフトウェア
バージョン管理
バージョン管理に関する用語集
バージョン管理システムの選択
バージョン管理システムの使用法
すべてをバージョン管理する
ウェブで閲覧できるようにする
コミットメール
ブランチの活用
情報の一元管理
承認
バグ追跡システム
議論の場としてメーリングリストを使う
バグ追跡システムをあらかじめフィルタする
IRC / リアルタイムに行なわれるチャットシステム
ボット
IRCの会話を保存する
RSS フィード
Wiki
ウェブサイト
ツールが一通り揃ったホスティングサイト
ホスティングサイトを選ぶ
匿名性とプロジェクト参加
Social Networking Services

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

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

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

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

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

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

プロジェクトに必要なもの

ほとんどのオープンソースプロジェクトは、 情報管理用のツールとして少なくとも以下のようなものを用意しています。

ウェブサイト

プロジェクトについての情報を、 管理者側から一般に向けて公開する場所です。 また、プロジェクトで使用するその他のツールについての 管理用インターフェイスもここで提供します。

メーリングリスト

通常は、そのプロジェクトにおける最も活発な議論の場となります。 また、議論の「記録媒体」としての意味合いもあります。

バージョン管理システム

開発者が、コードの変更点を追いかけやすくするものです。 変更内容を元に戻したり、他に移植したりすることもできます。 これを見ると、コードに何が起こっているのかを誰もが知ることができます。

バグ追跡システム

開発者が自分の作業内容を確認したり、 他の開発者と作業を調整したり、リリース時期の予定をたてたりするために用います。 特定のバグの状況や関連情報 (再現手順など) について、誰もが調べられるようになります。 バグだけに限らず、やるべき作業やリリース時期、 新機能の追加などについてもここで扱うことがあります。

リアルタイムチャット

ちょっとした議論や質問のやり取りのための場です。 議論の内容がアーカイブされないこともあります。

ここであげたツールはどれも異なるニーズを満たすものではありますが、 その機能には相関性があります。また、 各種ツール群は協調して動作させなければなりません。これ以降では、 その方法について考えます。また、より重要なこととして、 メンバーにそれを使ってもらうためにはどうすればいいのかも説明します。 ウェブサイトについての議論は後回しにします。というのもウェブサイトは、 独立したツールというよりは 他のツールを組み合わせるための接着剤のようなものだからです。

どんなツールを選択しようかといった問題に悩まされたくないという場合は、 出来合いの ホスティング サイトを使用するといいでしょう。 たいていはパッケージ化されたウェブサイトのテンプレートが用意されており、 フリーソフトウェアプロジェクトの運営に必要なツールもひととおりそろっているはずです。 本章の後半「ツールが一通り揃ったホスティングサイト」 で、 ホスティングサイトの利点と欠点を取り上げます。



[15] 1975 年に出版された彼の著書 The Mythical Man Month (邦題:「人月の神話」) に登場した法則。 http://en.wikipedia.org/wiki/The_Mythical_Man-Month および http://en.wikipedia.org/wiki/Brooks_Law ( 日本語) を参照してください。