新しいフリーソフトウェアプロジェクトをスタートさせる方法――各論：オープンソースソフトウェアの育て方（4/5 ページ）

[Karl Fogel， ]

開発者向けのガイドライン

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

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

• ほかの開発者とのやり取りのためのフォーラムの場所
• バグ報告やパッチの投稿の方法
• 開発の基本方針――「慈悲深い独裁者」式でいくのか「民主主義」式でいくのか、あるいはそれ以外の手法を取るのか

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

　開発者向けガイドラインの実例はHacker's Guide to Subversionをご覧ください。また、OpenOffice.org Guidelinesには、より一般的なガイドラインがあります。こちらは、技術的な話題よりもプロジェクトの管理体制やプロジェクトへの参加方法に重点を置いています。

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

ドキュメント

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

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

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

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

• 読者に対して、ソフトウェアを使用するために必要となる技術的な前提知識を明確に示す
• そのソフトウェアのセットアップ手順を、明確かつ完全に説明する。そしてドキュメントの最初の方で簡単な動作テストの方法や基本的なコマンドを説明し、セットアップが正常に完了したのかを確認できるようにする。導入に関するドキュメントは、ある意味実際の使用法のドキュメントよりも重要です。ソフトウェアをインストールして起動するためにより多くの努力を注ぎ込んでいればいるほど、そのユーザーはより粘り強く、ドキュメントが不十分な高度な機能を理解しようとするのです。ユーザーがあきらめるとしたら、それは初期であることが多くなります。つまり、最も初期の段階であるインストール時にこそ最大のサポートが必要となるわけです
• チュートリアル形式の例を用いて、一般的な作業の方法を示すこと、もちろんさまざまな作業に対するたくさんの例があるにこしたことはありませんが、時間が限られている場合は、どれか1つに絞ってそれを完ぺきにするようにしましょう。そのソフトウェアが何か1つの場面で使えることが分かれば、後は自分自身でほかの使い方を見つけてくれるようになります。また、もしかしたら「残りのドキュメントを書いてあげようか？」なんていう幸運なことになるかもしれません。これについては次のポイントで取り上げます
• ドキュメントがまだでき上がっていない部分は、それを示しておくこと。読者に対し、足りていない部分があることを認識していますよ、ということを示すことで、あなたは読者の視線に合わせることになります。読者に共感を示すことで、読者に対し、重要なことをプロジェクトに納得してもらうための苦闘に直面することはない、ということを再保証することになるのです。別に「いつまでにこのドキュメントを仕上げる」と表明する必要はありません。ボランティアの助けを広く求めるものとして取り扱うのも同程度に正当なことです

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

FAQの管理

　FAQ（“Frequently Asked Questions”、つまり“よくある質問集”）は、教育という観点において投資効果の最も高いものの1つです。FAQは、ユーザーや開発者が実際に質問する内容――彼らが質問することをあなたが期待した内容ではありません――にチューニングされています。その結果、よくメンテナンスされているFAQを探した人はたいてい、まさに欲しかった回答が見つけられるようになります。ユーザーは、何か問題に出くわすとまずFAQを調べます。公式マニュアルよりもFAQの方を先に見ることも多いでしょう。そして、ほかのサイトから最も多くリンクされることになるのもFAQとなるでしょう。

　残念なことに、プロジェクトが始まったばかりのころはFAQを用意することはできません。FAQは誰かが書くものではなく、徐々に成長していくものだからです。FAQは、その名前からして反応的なドキュメントであり、多くの人が日々ソフトウェアを使っていくに従って成長するものです。これから受けることになるであろう質問を正確に予測することなど不可能なので、有用なFAQを腰を据えてゼロから書き上げることなどできないのです。

　従って、FAQを書こうとして時間を浪費することは避けましょう。しかし、ほとんど空っぽのFAQのテンプレートを用意しておくことはよい考えかもしれません。そうすることで、プロジェクトが動き始めた後にユーザーが質問と回答を投稿してくれるかもしれません。この段階で大事なのは、完全性ではなく利便性です。FAQが追加しやすいようになっていれば、皆がそこに追加してくれるでしょう（FAQを適切に管理するという作業は決して簡単なものではなく、興味をそそる問題です。これについては、章8.ボランティアの管理のFAQマネージャ項でより詳しく説明します）。

ドキュメントの公開方法

　ドキュメントは2通りの方法で公開しなければなりません。オンライン（Webサイト上で直接公開するもの）、そしてソフトウェアの配布物としてダウンロード可能なもの（章7.パッケージの作成、リリース、日々の開発のパッケージング項を参照してください）の2通りです。オンラインで公開しなければならない理由は、人は普通そのソフトウェアをダウンロードする前にドキュメントを読むことが多いからです。ダウンロードに値するかどうかを、ドキュメントの内容で判断するわけです。しかし、それだけでなくソフトウェアにも同梱しておく必要があります。これは、ダウンロードすることでそのパッケージを使用するために必要なものがすべて手に入る（すなわち、ローカルにアクセス可能になる）ようにすべきである、という原則に従ったものです。

　ドキュメントをオンラインで提供する際には、ドキュメント全体を単一のHTMLページにまとめたものへのリンクを用意しましょう（このページへのリンクには、“完全版”や“すべてをひとまとめにしたもの”、あるいは“単一の大きなページ”といった説明をつけておきます。これによって、そのページの読み込みに時間が掛かることを示します）。これは、ドキュメント全体から特定の単語やフレーズを検索したいといった用途で便利です。一般に、そのような場合は何を探したいのかが既に分かっています。単に、それが第何章にあるのかが思い出せないだけです。そんな人たちにとっては、あるページには目次だけ、次のページには導入だけ、その次のページにはインストール方法だけ、……といったドキュメントほどストレスが溜まるものはありません。こんな形式のページ構成だと、ブラウザの検索機能が無意味になります。個別に分割した形式が便利なのは、必要な内容が第何章にあるのかが事前に分かっている場合です。あるいは、ドキュメント全体を頭から最後まで順に読んでいきたい人にとっても便利でしょう。しかし、ドキュメントにアクセスする人の多くは、このパターンには当てはまりません。よくあるパターンは、そのソフトウェアの基本的な内容をある程度理解している人が、特定の単語やフレーズを検索するといった使い方です。そんな人たちに対して単一の検索可能なドキュメントを提供しなければ、彼らにとっては非常に生きにくい世界になってしまいます。