2005/3/18配信号／新居雅行

　メールクライアントをオープンソースで開発している「オープンメール環境（OME）」は、普通にメールのやり取りができることを目指したソフトウエアである。オープンソースであればすべての情報が伝わるという訳ではなく、やはりどうしても、ドキュメントが必要になる。プログラムを作りながら、さらにはドキュメント、具体的にはWebサイトを用意して、テキストや図で説明が必要になるが、正直言ってそこまで手が回らないというのも事実である。オープンソースプロジェクトとドキュメントの関係をOMEの枠組みで考えてみよう。

　オープンソースにもマニュアルは必要だ。公開されたソースにばかり目がいくが、ユーザがプログラムの解析をできないのは当然としても、プログラムを読んだり作り込もうという側にとっても何かしらのドキュメントがないと、取りかかりがとてつもなく大変になる。しかしながら、ドキュメントがしっかりしたプロジェクトとなると、そうざらにはない。多くの人が関わるようなものだと確かにしっかりとしたドキュメントがある。ApacheのWebサーバはその典型だろうが、おそらく多くのプロジェクトではそこまでの人的リソースはないというのが実情だと思われる。

　もちろん、作成物に応じて必要なドキュメントは違ってくる。Apacheのようなサーバソフトだと、やはり設定ファイルの書き方といった情報がまずは充実してほしいところだ。また、チュートリアル的な「クイックスタートマニュアル」あたりが便利に思うところである。一方で、ライブラリ系のものとなると、APIのドキュメントやサンプルプログラムが欲しいものである。いずれにしても、オープンソースものとなると、ソースを公開することでのある種のコミュニケーションを期待していることもあって、どちらかといえば通常のアプリケーションのような「使い方マニュアル」はあまり見られないのが一般的だろう。もちろん、その種のアプリケーションにオープンソースものが少ないということもある。

　オープンソースということでプログラムそのものばかりが評価されるが、オープンソースプロジェクトでの「ドキュメント」も、ソースと同様な成果として評価されるということが必要ではないかと思う。昔だとドキュメントは文書そのものだったが、今時はWebサイトという形のアウトプットがとりあえずコストはかからないし、後からの修正も楽だ。読み手に届くまでの手はずを整えるのもプロジェクトとしては必要な仕事である。

　OMEはメールクライアントと言った性質上、どうしても、「使い方マニュアル」が必要になる。しかしながら、単一のアプリケーションではないので、通常のソフトのような、ダイアログボックスのオプションの設定などを説明するようなのが「使い方」には相当しないなど、どうも同じようには行かないのである。一番最初のMac OS 9版では、「ひととおりの使い方」のページを、インストール直後に表示するといったことを考えた。最低限の操作方法や設定ファイルの作り方を示したものである。

　しかし、そうなると、やっぱりソースを見ないことには何も分からないという状態になってしまう。また、OMEは当時から、AppleScript、Java、CでのAPI、REALbasicといろいろな手段を使っているため、全貌を見渡せないプロジェクトとなってしまった。そういうわけで、設定ファイルのリファレンスなどを作るようになったが、正直なところ、いい感じで作れていないのが現状だと言えるだろう。マニュアルの多くの部分を私が書いているのであるが、私がたとえば仕事の合間にOMEにかかわる時間が取れたとして、まず何をやるかと考えると「バグを直す」ということだ。つまり、開発者として関わると、やはりまずは開発に時間を割く、そして直したところをマニュアルに追加する…と言いたいところだが、これはけこう忘れてしまっていて、苦労して組み込んだ機能もみんなが知るのは宴会でそういう話がポロっと出たときといった始末になる。これは大きな反省点ながら、最適な解決方法は見いだせない状態だ。

　いちいちWebを作る手間がかかっているだけということなら、それはそれで何とかなるのかもしれないが、なんだかそうでもなさそうだ。ちなみに、現在はApacheプロジェクトの成果の1つであるCocoonを使ってOMEのサイトは運用しているが、この話はまた別の機会にしよう。

　いちおうライターとして今までは仕事をしてきたので、それなりのドキュメントを作れると自負はしているのであるが、自分で作ったソフトのマニュアルはなんだか大きく勝手が違う。ドキュメントを作るときの基本は、読み手の立場に立った文章を書くことに尽きるが、OME自体の開発を行う自分が解説するOMEはどうもディテールにこだわりすぎたりしている気がする。いや、言い換えれば、自分で作ったプログラムのレポートでしかなく、情報を必要としている人に向けた文書になっていないと、書く尻から思ってしまうのだ。

　ただ、この話をOMEのメンバーで集まったときに話したら、みんな一様に、気にすることはないと言うのである。逆に、開発した人間が、どんな形でもいいので、テキストを吐き出すということがまずは必要というのが皆の意見なのだ。なるほど、なら、気にしないで、書けるときに書けるだけ書くということでいいのかもしれない。

　何か機能を組み込んだ場合、とにかく、メーリングリストに思いついたことを投げる。そして、ある程度とたまったところでサイトにするという流れでずっと作業をしてきたが、最近ではWikiで文書をためてWebサイトにまとまったものを反映させるという流れの作業もやるようになってきた。しっかりした内容であることがもちろん必要だが、ないよりある方が遥かにましであるという割り切りでとにかくしのいでる。

　文章を書く以外の手段も試したことがある。どんなコンセプトでソースを作ったのかという説明を、テキストではなく音声で行うということも行った。OMEのソースを読む前に、おおまかな知識をつけてもらおうという意図である。いくつかのサウンドオンリーのムービーファイルがサイトに上がっているが、資料を見ながら音声を聞いてもらうというラジオ講座的なコンテンツである。これはこれでいいとは思うけど、特に評価されなかったので、ある程度でやめてしまった。ただ、思うに、この方法は意外に手間がかからない。文章だと作文してレイアウトして…ってことだが、音声は資料を作って話せばいいので、段取りよく慣れればあまり手間にはならない。間違えや訂正は、資料に後から追加できるので、自分ではけっこう効率のいい方法だと思っている。

　願望としては、やはりドキュメントやWebサイト、あるいはそうしたアクション、つまりはプロモーティブな活動といったところにも、参加者をしてもらいたいということがある。オープンソースプロジェクトは、ある程度の広がりが出てきたところで、開発者の働き以外のものが必要になってくる。もちろん、プログラミングがある程度分かっている人は参加しやすいのだが、そうではない人もOMEの場合は歓迎だ。逆に言えば、プログラミングという枠組みで動くプログラマの見えないところをそういう方々はきっと発見してフォローしてくれるのではないかと期待したい。

　オープンソースとは言いながら、運営形態はオープンとは言いがたいコミュニティもあるようだし、全体的にはプログラマ至上主義である点は否定できないだろう。もっとも、最近はオープンソースで有名になりたい人も多いようで、あまりに有象無象するのもどうかとは思うが、プログラマ以外の関わり方という点でも、オープンソースプロジェクトとしての道筋や流れを持ちたいと思うところでもある。

　【にい・まさゆき】msyk@msyk.net

　トレーナー、コンサルタント、デベロッパー、そしてライターと、あれこれこなすフリーランス。Mac miniを買い、19インチのディスプレイを買った。DVIとVGAの2端子なので、Windowsマシンもそちらで使う。卓上がすっきりし、広い画面なので、自分のデスクではPowerBookよりもMac miniを使う方が多くなってしまった。