第2章 さあ始めましょう

どこかの誰かがあなたのプロジェクトのことを聞きつけたとしましょう。 おそらく、何かの問題を解決するためのソフトウェアを検索しているときに見つけたのでしょう。 彼らが真っ先に目にするのは、そのプロジェクトの名前です。

すばらしい名前をつけたからといって、 そのプロジェクトの成功が約束されるわけではありません。 また、変な名前をつけたからといって それだけの理由でプロジェクトが失敗するというわけでもありません —もちろん、あまりにも マズい名前をつけてしまったら悪影響があるかもしれません。 しかし、わざわざプロジェクトを失敗に持っていくようなことはしないだろう という前提の下で話を進めます。 ただ、変な名前をつけてしまうと、 真剣に受け止めてもらえなかったり覚えてもらいにくかったりして、 そのプロジェクトの利用が低下してしまうかもしれません。

よい名前とは、次のような条件を満たすものです。

プロジェクトのウェブサイトを訪れた人たちが次に見るものは、 そのプロジェクトについての簡単な説明や目標などのメッセージです。 それらを見て (たいていは 30 秒程度で)、人は そこから先に進むか引き返すかを決断します。 このメッセージは、トップページの目立つ場所に配置しなければなりません。 プロジェクト名のすぐ下に置くといいでしょう。

この声明は、具体的で内容を絞り込み、そしてなによりも簡潔でなければなりません。 たとえば、以下に引用した http://www.openoffice.org/ の記述などがよい例です。

たったこれだけの文章ですが、主に訪問者の予備知識を利用することにより、 重要なところはすべてヒットしています。 "コミュニティーとして (as a community)" と明記することにより、 どこか１つの企業が開発を支配するものではないことを表しています。また "国際的な (international)" という言葉によって、 このソフトウェアが複数の言語や地域で動作することを示しています。 そして "すべての主要なプラットフォーム (all major platforms)" とあることから、おそらく Unix、Macintosh そして Windows で動作するであろうことが読み取れます。 その他の箇所からは、インターフェイスが公開されていることや ファイルのフォーマットが一般的なものであることなどがわかるでしょう。 彼らが Microsoft Office の代わりとなるフリーソフトウェアを作ろうとしているとはどこにも書かれていません。 しかし、たいていの人は行間からその気持ちを読み取ることができるでしょう。 この声明は一見したところ大雑把なようですが、 実際にはきわめて絞り込まれたものです。 また "オフィススイート (office suite)" という言葉を使用することで、その手のソフトウェアになじみがある人たちにとって かなり具体的な印象を与えることができます。 ここでも声明を簡潔なものとするため、 訪問者が持っているであろうと思われる前提知識 (この場合は MS Office に関するもの) を利用しているのです。

この声明の本質は、それが対象としているソフトウェアだけではなく 「だれがそれを書いたか」にも依存します。 たとえば、OpenOffice.org があえて "コミュニティーとして (as a community)" と書いているのがいい例です。 このプロジェクトはもともと Sun Microsystems が始めたものであり、 現在も同社が主なスポンサーとなっているからです。 あえてこの文言を含めることで Sun は「開発プロセスを 支配するようなつもりはない」ということを示しているわけです。 このように「問題が起こる可能性を認識している」 ということを示すだけでも、問題の発生を回避するのに大いに効果があるのです。 一方、特定の企業の支援を受けているわけではないプロジェクトについては このような文言は不要でしょう。結局のところ、 普通はコミュニティーベースの開発になるわけですから、 それをわざわざ示す必要はないわけです。

プロジェクトの目標についての説明 (ミッションステートメント) を読んで興味が残っているひとたちは、もっと詳細な情報を知りたくなることでしょう。 たとえばユーザー向けドキュメントや開発者向けドキュメントなど。 そして、何かをダウンロードしたくなるでしょうね。 でもその前に、まずはそれがオープンソースなのかどうかを知る必要があります。

プロジェクトのトップページで、 それがオープンソースであることを明記しておかなければなりません。 当然のことだとお考えかもしれません。しかし、 世の中にはそれができていないオープンソースプロジェクトが山ほどあります。 私がかつて見たとあるフリーソフトウェアプロジェクトのウェブサイトのトップページでは、 そのソフトウェアの配布時にどのライセンスを適用するかが示されておらず、 さらにそのソフトウェアがフリーなのかどうかさえ書かれていませんでした。 また、このような重要な情報が ダウンロードページや開発者向けページなどにしか存在しないというページもよくあります。 このような場合は、重要な情報を得るためにさらにマウスクリックが必要となってしまいます。 最もひどかった例では、ウェブサイト上のどこにもライセンスが示されていなかったものもありました。 ソフトウェアをダウンロードしてその中身を見ない限り、ライセンスの内容がわからなかったのです。

同じようなミスはしないでください。 そんなことをすると、せっかくの開発者候補やユーザー候補の多くを失うことになります。 トップページのミッションステートメント部の次に、そのプロジェクトが 「フリーソフトウェア」あるいは「オープンソース」であることを示し、 さらに具体的なライセンスについても記しておきましょう。 どのライセンスを適用すればいいかについては 「ライセンスの選択と適用」で説明します。 また、ライセンスに関するさまざまな問題については 10章ライセンス、著作権、特許 で詳しく説明します。

ここまでの情報を見るのに、訪問者が要する時間は１分かそれ以下でしょう。 これらの内容をもとに、彼/彼女 らがさらに次を読み進めるかどうかを決断するわけです。 次のセクションでは、最初の５分間で訪問者が見るであろう内容について扱います。

そのソフトウェアのちょっとした機能一覧 (まだ完成していない機能を一覧に含めてもかまいません。しかしその場合は "予定" とか "開発中" などとはっきり示して置くようにしましょう)、 そしてそれを動かすために必要な要件についての説明が必要です。 機能一覧/要件一覧は、そのプロジェクトについて誰かに聞かれたときに 答えるためにまとめたものと考えるといいでしょう。 これは、単にミッションステートメントの内容をより深く掘り下げたものと考えてもかまいません。 たとえば、ミッションステートメントで次のように説明したとすると、

機能一覧、要件一覧でその詳細を説明することによって ミッションステートメントの範囲を明確にします。

これらの情報によって、訪問者はそのソフトウェアが自分の希望を満たすものかどうかを判断します。 また場合によっては開発者としてプロジェクトに参加することを検討してくれるかもしれません。

そのプロジェクトがいったい何をやっているのか、訪問者たちはきっと気になることでしょう。 特に新しいプロジェクトの場合は、 そのプロジェクトが掲げている目標のうち 現在どれくらいが達成されているのかが気になるところです。 十分に成熟したプロジェクトの場合に気になるのは、 「そのプロジェクトが現在活発に保守されているのか」 「どれくらいの頻度で新しいバージョンがリリースされているのか」 「バグレポートに対する反応の速さはどれくらいか」 などとなります。

これらの質問に答えるために、開発状況を示すページを作らなければなりません。 ここには、直近の目標とそれを達成するために必要なもの (たとえば「ある特定の分野に強い開発者を募集しています」など) を表示します。また、過去のリリース履歴や機能一覧などもここに掲載するといいでしょう。 そうすることで、そのプロジェクトが「進捗」というものをどのように定義し、 その定義にしたがってどのくらい速く前進しているのか、 ということが訪問者にわかるようにしておきます。

まだできあがっていないことを恐れる必要はありません。 できあがってもいないことを変にごまかすこともやめましょう。 ソフトウェアの開発にはいくつかの段階があることを、みんな知っています。 "このソフトウェアはアルファ版です。既知のバグが存在します。 とりあえずは動作するでしょう。しかし、自己責任のもとで使用するようにしてください" と言ったところで、何も恥ずかしいことはありません。 そのような段階でプロジェクトが必要としている開発者は、 「アルファ版」という説明なんかではおびえたりしません。対エンドユーザーという面では、 まだできあがってもいないソフトウェアにユーザーが群がってしまうほどまずいことはありません。 いったん「不安定」だとか「バグだらけだ」だとかいう評判が出てしまうと、 それを払拭するのは大変な話になります。 結局のところ、多少保守的なほうがうまくいきます。 そのソフトウェアが「ユーザーが期待しているよりも安定していた」 ほうが、期待はずれだった場合よりもずっといいでしょう。 そしてそのほうが、口コミによる広がりが期待できます。

標準的な形式で、ソフトウェアのソースコードをダウンロードできるようにする必要があります。 プロジェクトを立ち上げた最初のうちは、バイナリ (実行可能) パッケージはなくてもかまわないでしょう。 ただし、ビルド手順が面倒だったり依存性が複雑だったりして、 ただ動かせるようにするだけでも多くの人にとって骨が折れるような場合は、 バイナリ版も必要です (でも、 そんなプロジェクトは開発者にとってはあまり魅力的ではありません)。

配布形態は、できるだけ便利で標準的かつ余計な負担の少ないものを選びましょう。 あなたがある病気の撲滅を狙っているなら、 薬を配る際に独自の注射器が必要となるような面倒な手段はとらないでしょう。 同様に、ソフトウェアについても標準的な手順で ビルド・インストールできるようにしておきましょう。 標準から外れれば外れるほど、 ユーザー候補や開発者候補は狼狽してそのプロジェクトから離れてしまいます。

当然のことだと思われるかもしれません。 しかし、多くのプロジェクトは本当に切羽詰るまで インストール手順を標準化しようとはしないものです。 "ま、リリースに近づいたら そのときにやろうよ。そんなことはいつでもできるんだから。" といった言い訳をしてしまいがちです。 彼らはわかっていないのですが、そういった作業を後回しにしてしまうと、 結果的にリリースに近づくまで余計に時間がかかってしまうのです。 なぜならば、さもなくばコードを貢献してくれたかもしれない開発者たちの意欲を削いでしまうからです。 もっとも悪いことに、彼らはそのような開発者を失いつつあることに気づきません。 なぜならば、この過程は 「誰かがウェブサイトを訪れた→ソフトウェアをダウンロードした →ビルドしようとした→失敗した→あきらめた」 という、イベントが発生しなかったことの積み重ねだからです。 あきらめた本人以外には、そんなことがあったということはわかりません。 もともとあなたのプロジェクトに興味を持っていてくれたはずの人が黙って立ち去ってしまった、 そしてそれをプロジェクトのメンバーは誰も気づかないのです。

面倒だが見返りの大きい作業は、できるだけ早めに済ませてしまいましょう。 パッケージをきちんと作成すると、 プロジェクトへの参加障壁を劇的におろすことができ、 結果として大きな見返りを得ることになります。

ダウンロード用のパッケージをリリースするときは、それに対して 一意なバージョン番号を与えることが大切です。 それによって人は、２つのリリースのうちどちらが新しいのかを知ることになるのです。 バージョン番号のつけかたについては 7章パッケージの作成、リリース、日々の開発 の 「リリースに番号を付ける」 で、 そしてビルド手順やインストール手順の標準化については同じ章の 「パッケージング」 でそれぞれ詳しく説明します。

単にそのソフトをインストールして使いたいだけという人にとっては、 ソースパッケージで十分でしょう。しかし、デバッグをしたり 機能追加をしたりしたい人たちにとってはそれだけでは不十分です。 毎晩最新ソースのスナップショットを作成するという手もありますが、 開発が活発に行われているコミュニティーではまだこれでも完璧だとはいえません。 常にその時点の最新のソースにアクセスしたいという人たちにその手段を提供するのが、 バージョン管理システムです。 バージョン管理システム上のソースに匿名でアクセスできるようにしておくと、 「このプロジェクトは、新しいメンバーの参加を歓迎しています」 というメッセージをユーザーと開発者の両方に送ることになります。 もし今すぐにバージョン管理システムを用意できない場合は、 近々公開予定であるというメッセージを書いておくようにしましょう。 バージョン管理システムについては 3章技術的な問題 の 「バージョン管理」 で詳しく説明します。

バグ追跡システムについても同じです。 バグ追跡システムの意義は、開発者に対する有用性だけでなく、 それがプロジェクトの観察者に対して発している暗黙のメッセージにも存在します。 多くの人は、バグデータベースが公開されていると 「熱心に開発が進められているようだ」と感じます。 さらに、バグデータベースにたくさんのバグが登録されていればいるほど、 そのプロジェクトの見栄えはよくなります。 ちょっと直感に反しているように思われるかもしれません。でも考えてもみてください。 バグデータベースに登録されたバグの数が実際何に依存しているかというと、 それは次の３つです。まず、そのソフトウェアに存在するバグの絶対数。 次に、そのソフトウェアを使用しているユーザー数。 そして最後に、ユーザーが新規のバグを登録できるための利便性です。 このうち最初の１つよりも後ろの２つの方が重要な要素になります。 ある程度の規模と複雑さを持つソフトウェアには、 基本的にバグが含まれているものです。本当の問題は、 それらのバグをいかにして見つけ、どのように優先順位を設定するかというところにあります。 したがって、よく整備された (バグに対する対応がすばやく、 重複したバグ報告はきちんと統一されているなど) 大規模なバグデータベースがあると、 バグデータベースがなかったりほとんど機能していなかったりするプロジェクトより ずっと印象がよくなります。

もちろん、そのプロジェクトが本当に始まったばかりなのなら バグデータベースに登録される内容はほんのちょっとだけになるでしょう。 それについてはどうにもしようがありません。 しかし、プロジェクトが始まったばかりであることがどこかにきちんと書いてあり、 かつデータベースに登録されているのが最近登録されたバグばかりであったとすると、 プロジェクトのバグ登録が健全な比率を保っている、 ということを読み取ることができます。 彼らはバグ登録の絶対数が小さいことを不当に警戒することはないでしょう。

バグ追跡システムに登録されるのはソフトウェアのバグだけではありません。 機能追加の要望やドキュメントの変更、 とりあえず保留になっている作業などが登録されることも多々あります。 バグ追跡システムの運用方法については 3章技術的な問題 の 「バグ追跡システム」 で詳しく説明するので、 ここでは深く立ち入りません。プロジェクトの見栄えという観点から見て大切なのは、 まずバグ追跡システムが 存在する ということ。 そしてそれがプロジェクトのトップページからたどれる場所にあるということです。

プロジェクトの関係者の連絡先を知りたいという人もあらわれることでしょう。 関係者と連絡を取れるように、メーリングリストのアドレスや チャットルーム、IRC チャンネル、掲示板などの場所を示しておきましょう。 あなた、あるいはその他のプロジェクト関係者がこのメーリングリストに参加していることも明記しておきましょう。 そうすることで、「そこに行けば開発者と話すことができる」ということが伝わります。 あなたがメーリングリストに参加しているからといって、 すべての質問に答えなければならないとか すべての要望に答えなければならないとかいった義務が発生するわけではありません。 長い目で見れば、ユーザーのほとんどはこのようなメーリングリストや掲示板には参加しません。 とはいえ、必要ならいつでも参加できるということを示すだけで、 安心感を与えることができます。

プロジェクトを立ち上げたばかりのころは、 エンドユーザー向けと開発者向けにフォーラムを分ける必要はありません。 それよりも、プロジェクトにかかわる人たちが１つの「部屋」 に集まってわいわいがやがや話をするほうがずっといいでしょう。 アーリーアダプター層においては、開発者とユーザーの区別はあいまいです。 あえて分類するとしても、プロジェクトの初期には開発者の比率がかなり高くなります。 アーリーアダプターのすべてがそのソフトウェアをハックしたいと思っているとは限りません。 しかし、少なくともそのプロジェクトの今後の方向性に関する議論には 興味を持っていることでしょう。

本章では「プロジェクトをどのように立ち上げるか」についてのみを扱っています。 この段階では「とりあえずコミュニケーション用の場所が必要だ」というくらいで十分でしょう。 後で、6章コミュニケーション の 「巨大化への対応」 においてさらに詳しく説明します。 ここでは、掲示板の設置や管理の方法について扱います。 また、いつかユーザー向け会議室と開発者向け会議室を分割することになったときに、 両者の間に溝を生じさせないための方法も説明します。

開発者としてプロジェクトに参加しようと考えた人は、 まず開発者向けのガイドラインを探すことになるでしょう。 このガイドラインは、技術的なものというよりもむしろ社会的なものとなります。 たとえば開発者同士のやりとりの方法、ユーザーとのやりとりの方法、 プロジェクトをうまく進めるためにどのようにしていくかなどです。

このトピックについては 4章プロジェクトの政治構造と社会構造 の 「全てを記録しておく」 で詳しく説明します。 ここでは、そこに含める基本的な内容だけをまとめておきます。

ところで、「独裁者」という言い方には、特にそれを批判する意図はありません。 特定の開発者だけがすべての変更に対する拒否権を行使できる というような専制政治を行ってもまったく問題はありません。 実際、多くのプロジェクトはこの方式で成功しています。 大事なのは、そのプロジェクトがそういう方針で運営されているとはっきり示しておくことです。 実際には独裁型なのに無理に民主主義っぽく見せようとすると、 人は離れていってしまいます。きちんと独裁型であることを宣言しておけば、 少なくともその独裁者が有能で信頼できる人である限りはうまく進みます。

開発者向けガイドラインの実例は http://subversion.apache.org/docs/community-guide/ をご覧ください。また、http://www.openoffice.org/dev_docs/guidelines.html には、より一般的なガイドラインがあります。こちらは、 技術的な話題よりもプロジェクトの管理体制やプロジェクトへの参加方法に重点を置いています。

プログラマー向けにソフトウェアについての説明を行うことについては、 本章の後半の 「開発者向けドキュメント」 で取り上げます。

ドキュメントは必要不可欠です。 何か読んでもらうものが必要です。 たとえそれがごく簡単な未完成のものであってもかまいません。 この作業はまさに、先ほど言及した「骨折り仕事」の範疇に属するものです。 新しいオープンソースプロジェクトがしばしば最初につまづくのがこの分野です。 ミッションステートメントや機能一覧を作成するとか、 ライセンスを選択するとか、開発状況をまとめるとかいったことはどれも比較的小規模な作業です。 しかも「ここまでできたら完了」という点がはっきりしており、 通常は一度作成すればそれ以降は手を加える必要のないものです。 ドキュメント作成はこれらとは異なり、 決して終わることのない作業です。 みんながドキュメント作成を嫌がるひとつの理由がここにあります。

ドキュメント作成において最も注意すべき点は、 ドキュメントの書き手にとって有用な内容と読み手にとって有用な内容とは まったく正反対であるということです。 はじめて使用するユーザーにとって必要なドキュメントは、 基本をまとめたものです。ソフトウェアを手っ取り早くセットアップする方法や 動作の概要、そして一般的な作業をするための手引きなどが必要でしょう。 しかし、これらの内容はまさに、ドキュメントの書き手 があまりにもよく知りすぎていることです。 そのためかえって、物事を読者の視点から眺めたり、また、 (ドキュメントの書き手にとっては) 言及に値しないほど明白な手順を、 骨を折って詳細に説明するのが困難になる可能性があります。

この問題を解決するためのマル秘手段は存在しません。 誰かが腰を落ち着けてそれを書かなければならないのです。 そして、初心者にそれを見せて内容をチェックしてもらわなければなりません。 ドキュメントの書式は、 たとえば HTML やプレーンテキスト、Texinfo あるいは各種 XML といったような、 シンプルで編集しやすいものにしましょう。 すなわち、ふと思ったときお手軽かつ迅速に更新するのに適した書式です。 これらを使用すると、ドキュメントの作成者があとからそれを更新する際の手間も少なくなります。 また、後からプロジェクトに合流した人にとっても、作業に参加しやすくなるでしょう。

基本ドキュメントをきちんと整備できるようにするためのひとつの方法としては、 ドキュメントで網羅する範囲を事前に限定してしまうというものがあります。 このようにしてしまうと、少なくともドキュメントの作成が 果てしない作業に思えてしまうことはなくなるでしょう。 実際的な目安としては、以下に挙げる最低限の基準は満たすようにすべきです。

この最後に述べた点は、実のところ、より広範囲の重要性があり、 単にドキュメントだけに限らずプロジェクト全体にあてはまることです。 既知の足りていない部分を正確に会計することは、 オープンソースの世界においては当たり前のことだということです。 そのプロジェクトの欠点を必要以上に誇張する必要はありません。 単に、事情がそれを要求する場合 (ドキュメントやバグ追跡データベース、あるいはメーリングリストにおける議論など) に、それを厳正かつ私情を交えずに明らかにするだけのことです。 それを負け犬根性だという人はいないでしょうし、 明示的に示さない限りは「いつまでにこれを解決する」という公約だと受け取る人もいないでしょう。 ソフトウェアを使用していると、だれでもそのソフトウェアの欠陥を発見してしまうものです。 彼らが心の準備をできるようにしておいてあげましょう。 すると、そのプロジェクトは自分たちのことがよくわかっているとみなされるようになります。

そのプロジェクトがグラフィカルなユーザーインターフェイスを持っていたり、 グラフィカルあるいはそうでない特徴的な出力を行ったりする場合は、 そのサンプルをプロジェクトのウェブサイトに公開しておきましょう。 インターフェイスの場合は、スクリーンショットがこれにあたります。 出力の場合は、同じくスクリーンショットか、 あるいは実際の出力ファイルとなります。 これはどちらも、即座の満足感に対するユーザーの欲求を満たすものです。 長々とした説明やメーリングリストでのやりとりよりも、 ほんの一枚のスクリーンショットのほうが説得力を持つこともあります。 なぜなら、スクリーンショットはまさにそのソフトウェアが 動作した結果であることに疑いの余地がないからです。 バグだらけかもしれません。インストールが難しいかもしれません。 ドキュメントが足りないかもしれません。 でも、スクリーンショットさえあれば、 何とかがんばれば動かすことができるんだということの証明になります。

オープンソースプロジェクトのために、 ウェブサイト用の領域やバージョン管理機能、バグ追跡システム、ダウンロードエリア、 掲示板、バックアップなどの機能を無料で提供するサイトがいくつかあります。 詳細はサイトによって異なりますが、基本的な機能はどこでも同じようなものです。 これらのサイトのいずれかを使用すると、無料で多くのものを手に入れることができます。 ただ、ユーザーへの見せ方をきめ細かく調整するといったことはあきらめなければなりません。 そのサイトでどんなソフトウェアを用いるのかを決めるのはホスティング業者であり、 プロジェクトのウェブページの見た目はその業者に多少なりとも左右されることになります。

あらかじめ用意されているホスティングサイトを使うことの利点と欠点、 ホスティングサイトの一覧などについての詳細は、 3章技術的な問題 の 「ツールが一通り揃ったホスティングサイト」 をご覧ください。