ここまで取り上げてきたのは、プロジェクトの立ち上げ時に一度だけ必要となる作業でした。 ライセンスの選択や最初のウェブサイトの作成などです。 しかし、プロジェクト開始時に最も大切なのは、それ以外の動的な作業です。 メーリングリストのアドレスを決めるなんていうのは簡単なことです。 でも、そのメーリングリストでのやり取りを有益で前向きなものに保つのは それとはまったく別の話となります。 これまで何年にもわたって社内の閉じた環境で開発が進められてきたものをオープンにすると、 その開発プロセスはこれまでとはかわります。これまでの開発者たちに対して、 その変更に対応できるように準備をさせなければなりません。
最も困難なのが、はじめの一歩です。なぜなら、今後の方向性に関する先例もなければ 今後どのようになっていくのかもまだはっきりわからないからです。 プロジェクトの安定性は、形式張った方針からくるものではなく、 開発者の間で徐々にできあがっていく集合知によってもたらされるものです。 そして、これはしっかりとらえにくいものです。 明文化された規則があることもありますが、それはたいてい、 プロジェクトを本当に動かしているこれらの無形の合意をまとめあげたものにすぎません。 明文化された方針によってプロジェクトの文化を定義することはできませんし、 それに近づくことさえできません。
このようになるには、いくつかの理由があります。 成長と変化の速さは、人が考えるほどには文化の蓄積に影響を与えません。 変化の速度があまりにも高速にならない限り、新入りさんがそれを学ぶ時間はあります。 そして学び終えた後は、自分自身でそのやりかたを補強してくれるでしょう。 童謡が、いったいどのようにして何百年も歌い継がれるようになったのかを考えてみましょう。 現在の子どもたちが歌っている童謡は、基本的には数百年前の子どもたちの歌っているものと同じです。 もちろん、昔の子どもたちが童謡を歌っていた頃には現在の子どもたちはまだ産まれていません。 子どもたちはその歌を年長者から聞いて覚えます。そして子どもたちが成長すると、 年少者の前でそれを歌って聞かせるわけです。もちろん、 子どもたちは意識的にそうするよう指示されているわけではありません。 しかし、何百年も同じ歌が歌い継がれているという事実は、 このような伝承が常に繰り返し行われていることを示しています。 フリーソフトウェアプロジェクトの歴史が今後何百年も続くかどうかはわかりません (どうなるかはまだわかりません) が、この仕組みは似たり寄ったりでしょう。 しかし、その回転率はより高速になるので、 より活発かつ慎重に伝承を行うようにしなければなりません。
この動きは、人が基本的に社会規範を求めているという性質があるので成功しやすくなります。 それこそが人が存在する理由なのですから。 一般的な方法でまとめあげられた集団なら、そこに参加しようとする人々は 本能的にその集団の一員として振る舞うためのやりかたを見つけようとするものです。 より早い時期に先例を確立するには、そのプロジェクトに役立つ 「グループとしての」振る舞いを作ることです。いったんできあがってしまえば、 あとは勝手にそれが広まっていきます。
以下に示すいくつかの例は、 よりよい先例を作るためにできる具体的なことをまとめたものです。 これだけを行えば完全だというものではありません。単に、 「早いうちに協力的なムードを作り上げておくとプロジェクトを運営しやすくなりますよ」 ということを説明するためだけのものです。 物理的には、個々の開発者がそれぞれ別の場所で作業をしているのかもしれません。 しかし、まるで同じ部屋で一緒に開発しているかのように 感じさせる ために、いろいろなことができます。 彼らがこのように感じてくれればくれるほど、プロジェクトに対してより時間をさきたいと思うようになるでしょう。 以下の例は、Subversion プロジェクト (http://subversion.tigris.org/) から選びました。私は、開始当時からこのプロジェクトに参加しています。 しかし、これらの例は決して Subversion 独特のものではありません。 同様の状況は大半のオープンソースプロジェクトで起こりえるでしょう。 また、プロジェクトに片足を突っ込む際には意識しておく必要があることばかりです。
プロジェクトを一般に向けて公開した後でも、難しい問題についての話し合いは 内輪の関係者たちだけで行いたいと考えることもあるでしょう。 これは、プロジェクトが始まったばかりのときにはあり得ることです。 話し合うべきことは山ほどありますし、通常は その話し合いに参加する資格のある外部の協力者はほとんどいないからです。 公開されている場所で議論することによるさまざまな損失があなたの頭の中に浮かぶことでしょう。 メールでのやりとりに特有ののんびりした速度、 合意を形成するのにかかる時間、本当は何もわかっていないのに 「自分はすべてわかっている」と勘違いしているボランティアへの対応 (どんなプロジェクトでもこの手の人がいます。彼らのうち何人かは将来すばらしい貢献をしてくれることになるでしょうが、 中にはずっと勘違いしたままの人だっています)、ある問題 X がより大きい問題 Y の一部であるときに、 なぜ問題 Y ではなく問題 X だけを解決したいのかを理解してくれない人たち、 などなど。こんなときに、密室の話し合いで決めた内容を "既成事実 (faits accomplis)"、 あるいは少なくとも有力な選択肢として提示できればどんなに楽なことでしょう。
でも、そんなことをしてはいけません。
たとえ公開の場での議論の進行が遅くて厄介だとしても、 長い目で見ればそれが一番望ましい方法です。 重要な決定を内輪でこっそり行うのは、まるでそのプロジェクトに 「貢献者よけスプレー」を振りまくようなものです。 秘密の協議会がすべての重要な決定を行うというような環境では、 やる気のあるボランティアは決してついてこないでしょう。 さらに、公開の場での議論にはよい副作用もあります。
その議論が、新しく参加する開発者の訓練や教育に役立ちます。 その議論をいったいどれだけの人が注目しているかは決してわかりません。 大半の人たちは単なる傍観者として見ているだけで、 黙ってそのソフトウェアについての情報を追いかけているのです。
その議論は、あなた自身 の訓練にもなります。 技術的な問題を、そのソフトウェアにあまり詳しくない人たちにもわかるように説明するという技術を磨くことができます。 これは実際に必要となる技術であり、 すでにそのソフトウェアについて熟知している人たちと話しているだけでは身につけることができません。
議論の内容とその結論が公開されたアーカイブに残るようになります。 後に同じような問題が発生したときに、同じ議論を繰り返す必要がなくなります。 詳細は 6章コミュニケーション の 「アーカイブを目に付きやすくする方法」 を参照してください。
最後に、メーリングリスト上の誰かがそのやり取りに対して真の貢献をしてくれるかもしれません。 つまり、あなたが思いもしなかった新たな考え方を示してくれるということです。 これがどのくらいの頻度で起こるのかは断言できません。 そのコードの複雑さがどれくらいか、そしてどの程度の専門知識を要するかによっても異なります。 ただ、私のこれまでの経験上、その頻度はみなさんが思っているよりもかなり高くなります。 Subversion プロジェクトで、私たち (プロジェクトを開始した当時のメンバー) は深く複雑なさまざまな問題に直面していました。私たちは何ヶ月も悩み続けました。 そして、率直に言って、当時できたてのメーリングリストにいるメンバーがこの手の議論に貢献してくれるとは期待していませんでした。 そこで私たちは安易な方法をとることにしました。技術的なアイデアについての議論を個人的なメールのやりとりで行うようにしだしたのです。 その様子を嗅ぎ付けた人 [13] から「議論は公開されたメーリングリストでしてくれ」 と言われるまで、その状態が続きました。私たちはそれを受け入れ、その話題をメーリングリストに移動しました。 そのとたん、数々の洞察に満ちた意見や提案が寄せられるようになり、私たちは驚きました。 寄せられた意見の多くは、これまで私たちが考えもしなかったものでした。 メーリングリスト上には、非常に 優秀な人間がいたのです。 彼らはただ、メーリングリスト上にネタが投下されるのを待ちわびていたのです。 確かに、すべて密室の議論ですませるのに比べれば時間はかかりました。 しかし、時間をかけたのに十分見合うだけの成果が得られました。
"三人寄れば文殊の知恵" だとか "個人よりも集団のほうが常によい判断ができる" とかいうように一般化して逃げてしまうのではなく、 集団のほうがよい結果がでる活動としてはどんなものがあるのかを知っておきましょう。 大規模なピア-レビューなどがその例のひとつです。 あるいは、とにかくたくさんの案を手早く出していくといった作業もそれにあたります。 もちろんアイデアの質はそれを考えた人たちの質に依存しますが、 困難な問題を皆にぶつけてみるまで、誰がどのような案を持っているかはわからないものです。
当然、内容によっては個人的に議論しなければならないものもあります。 本書の中でもそのような例がいくつか登場します。 しかし、基本方針として、隠す必要がないものは、すべて公開すべきである ということは常に心においておきましょう。
そのためには何らかのアクションが必要です。 あなた自身が常に公開のメーリングリストに投稿しようと心がけるだけでは不十分です。 隠す必要がない内容のメールを他の人から受け取ったら、 それをメーリングリストにも流すようにしなければなりません。 誰かが個人的に議論を始めようとしているとき、もしそれが個人的にする必要のないものなら、 それを個人的に行うのか公開で行うのかに関する議論をすぐに始める責任があります。 首尾よくその議論を公開の場に持ち出すか、 あるいは個人的に話し合うのが適切であることがわかるまで、 元の話題にはコメントしないでください。 常にこのようにすることを心がければ、 人はやがてデフォルトで公開の場を使用することになるでしょう。
プロジェクトを一般に公開したら、 フォーラムにおける失礼な振る舞いや侮辱的な発言にはゼロトレランスで (情け容赦なく) 対処しなければなりません。「ゼロトレランスで」とは、 何か技術的に特別なことをしなければならないという意味ではありません。 別の参加者を罵倒した参加者をメーリングリストから強制退会させる必要はありませんし、 人を傷つけるようなコメントをしたからといってその人のコミット権を剥奪する必要もありません (理屈上は、結局のところそういった措置をとらざるを得ないことになるかもしれません。 しかし、それはさまざまな対策がすべて失敗したときの最後の手段とすべきです。 つまり、プロジェクトの開始当初にはそのようなことは起こりません)。 ここで言うゼロトレランスとは、そんな振る舞いを決して見過ごさないということです。 たとえば、技術的なコメントといっしょに プロジェクトの他の開発者に対する個人攻撃 (ad hominem) を含むコメントが投稿されたとしましょう。そんな場合は、まず その個人攻撃に対する指摘をしたうえで、技術的な内容についてはそれとは分けて返答するようにしましょう。
残念ながら、これは易しいことではありません。 そして、たいていは建設的な議論が不毛な罵倒合戦に陥ってしまいます。 人は、面と向かっては決して言えないことでもメールでは平気で言ってしまうものです。 また、議論の内容もこの傾向に拍車をかけます。 技術的な問題に関して、多くの人は「ほとんどの質問には正解がひとつしかない」 と考えがちです。そしてその答えに同意しない人のことを無知で愚かな人だと思ってしまうのです。 誰かの技術的な提案を否定すると、その人自身の人格を否定したように受け取られることもあります。 実際、技術的な議論が人格攻撃に切り替わる瞬間を見極めるのは非常に難しいものです。 厳しめの返答や処罰がいい考えではないひとつの理由がここにあります。 そのかわりに、ちょっと雰囲気が怪しくなってきたなと感じたら、 議論を友好的に進めるように促す投稿をするようにしましょう。 その際に、特定の人物が意図的にそんなことをしているように非難することは避けなければいけません。 しかし、そのような "町のおまわりさん" 的な投稿は、 時として園児をしつける幼稚園の先生のように見えてしまうという傾向があります。
まず最初にひとこと。個人攻撃につながる (あるいはその恐れのある) コメントは控えてください。たとえば、J が設計したセキュリティ層について "コンピュータのセキュリティに関する基礎知識に欠ける無能な設計だ" と語るようなことです。それが正しいかどうかは別にして、 これは議論の進め方としては間違っています。 J は信念を持ってこの提案をしたわけです。 もし問題があるならその問題を指摘しましょう。 そして皆でそれを修正するか、新しく設計をやりなおせばいいじゃないですか。 M は決して J を個人攻撃するつもりがないことは知っています。 でも、その言い方はちょっとまずかった。もっと建設的な議論を進めましょう。
さて、提案内容に話を戻しましょう。 私は、M の言うことはもっともだと思います……
ちょっと堅苦しく感じるかも知れませんが、これはかなりの効果があります。 何かあったら必ず口を出すが、決して攻撃側に謝罪を要求したり落ち度を認めさせたりしない。 そうではなく、そのまま放っておいて次回はよりおだやかに振舞うように促すのです。 そうすれば彼らはきっとそれに従ってくれます。 これをうまく行う秘訣のひとつは、どっちが悪いかとかどうすべきかといった メタ議論を主題にしてしまわないことです。そうではなく、 本題に入る前の前置き程度の扱いにしておくべきです。 「ここではそんな振る舞いはやめてください」と指摘した後はすぐに本題に移ります。 そうすることで、相手側にも本題に返答する機会を与えることができるのです。 もしそれでも「あなたに非難されるいわれはない」といったことを言われたら、 もうそれ以上その話題を引きずるのはやめましょう。 単にその話題に関する返信をやめておく (単に彼らは自分の主張を振りかざしているだけであり、 返事を求めているわけではなさそうな場合) か、あるいは 「出すぎたまねをしてしまってごめんなさい。メールではなかなかニュアンスが伝わりにくいので」 と謝ったうえで本題に戻ればいいのです。 不適切な振る舞いをした人たちの主張は、公開の場であるか否かにかかわらず 決して認めないでください。もしかれらの方から謝罪があればすばらしいことですが、 こちらから謝罪を要求しても相手をさらに怒らせるだけでしょう。
最終的な目標は、その集団に「礼儀をわきまえる」という空気を作り上げることです。 これは、プロジェクトにとって大きな助けとなります。なぜなら、開発者が (自分が好んでサポートしようとしている) プロジェクトで罵倒合戦に巻き込まれる心配がなくなるからです。 そんなことが原因で開発者候補がプロジェクトが離れていることに、あなたは気づかないかもしれません。 誰かがメーリングリストにひっそり参加してそのプロジェクトの状況を観察し、 参加するための障壁が厚いことがわかり、結局参加することをあきらめるということがあるかもしれません。 フォーラムを友好的な雰囲気にしておくことが、長期的に生き残るための作戦として有効です。 また、これはプロジェクトが小さいうちから心がけておいたほうが実現しやすいことです。 いちどそんな文化ができあがってしまえば、あなたひとりがいちいちそれを主張して回る必要もなくなるでしょう。 皆がそういうふうに持って行ってくれるからです。
開発コミュニティーをうまく育てていくために最適な方法は、 開発者どうしがお互いのコードを見せ合うことです。 これを効率的に行うには、技術的な支援が効果的です。特に便利なのが、コミット時のメール通知です。 これについては 「コミットメール」 で詳しく説明します。 コミットメールとは、誰かがソースコードに加えた変更をコミットするたびに そのログメッセージと変更内容をメールで送る機能のことです (「バージョン管理に関する用語集」 の 差分 を参照してください)。 コードレビュー とは、コミットメールがやってくるたびにその内容を確認し、 バグや改善点がないかどうかを探す作業を指します。 [14]
コードレビューは、さまざまな点で役立ちます。 オープンソースの世界におけるコードレビューの最大の効果は、 ソフトウェアの品質を一定に保つことです。 ソフトウェアにバグが含まれる原因は、 コミットされたコードをきちんとチェックしなかったことにあります。 コミットの内容を多くの目でチェックすることで、 バグを残したまま公開してしまう危険性を減らすことになります。 しかし、コードレビューの目的はこのような直接的なものだけではありません。 コードレビューによって、自分たちの作業の内容を確認させることができます。 コミットの内容をレビューするには、その作業についてよく知っておく必要があるからです。 他の人が自分の作業を評価すると知っていれば、 人は最善を尽くして作業を行うようになります。
レビューは公開の場で行わなければなりません。 開発者同士が物理的に同じ部屋にいる場合であっても、 誰かがコミットしたときにそのレビューを部屋の中だけで済ませてしまってはいけません。 面倒でも開発者用のメーリングリストに投稿するようにしましょう。 そのレビューを見ることで、参加者全員が何かを得ることになります。 レビューの結果、何らかのコメントをしたり、 場合によっては不具合を見つけたりすることもあります。 レビューは日常の作業のひとつととらえましょう。 そう。ちょうど皿洗いや芝生の手入れと同じような感覚です。
Subversion プロジェクトの開始当初は、日常的なコードレビューの習慣はありませんでした。 すべてのコミットがレビューの対象になるという保証はありませんでしたが、 変更されたコードの内容に興味のある人がそれを眺めるということはありました。 当時のコードに紛れ込んでいたバグは発見可能でしたし見つけられるべきでした。 当時の開発者のひとりである Greg Stein は、 過去の経験からコードレビューが役立つことを知っていました。 彼は、リポジトリへの すべてのコミット の１行１行の内容を詳細にまでわたってレビューするようになりました。 誰かがコミットするたびにそのコミットについての Greg からのメールが 開発者用メーリングリストに流れました。メールの内容は、 コミットの内容を細かく切り刻んで分析し、起こりうる問題を指摘するといったものです。 時には、優れたコードに対して賞賛を送ることもありました。 コミットがあるたびに、バグを見つけたり 注意しないとつまづくく恐れのあるあまりよい書き方ではないコードを見つけたりしていたのです。 彼は、コミットの内容をレビューするのが自分ひとりであることについて、 表立っては不平を述べることはありませんでした。 かなりの時間をレビューに費やしていたにもかかわらずです。 その代わりに、ことあるごとにコードレビューのすばらしさについて発言していました。 やがて、私を含めた他のメンバーもコミットの内容を定期的にレビューするようになりました。 何がそうさせたのでしょう? 決して Greg が私たちにそれを強制したわけではありません。 彼は「コードのレビューが時間をかけるだけの価値のあるものである」こと、そして 「他人のコードをレビューすることは新しいコードを書くのと同じくらいに重要である」 ことを自身の行動をもって証明したのです。 いざそういう習慣が身につくと、自分のコミットに何の反応もなければ逆に不安になります。 開発者用メーリングリストで「誰か私のコードをレビューしてくれないかな?」 と聞いてみたりなんかして。後に、Greg は別の仕事を得ることになり、 Subversion にあまり時間をかけられないようになってしまいました。 彼は定期的なレビューをあきらめざるを得なくなったのです。 しかし、そのときにはすでにレビューの習慣が私たちにも深く根付いていました。 まるで太古の昔からそれが当たり前であったかのように。
コードのレビューは、最初のコミットの時点から始めましょう。 差分を見れば簡単に発見できる問題としては次のようなものがあります。 たとえばセキュリティ上の脆弱性やメモリリーク、 コメントや API ドキュメントの不足、「ひとつずれちゃった (off-by-one) エラー」、呼び出し元と呼び出し先の規約の不一致などです。 また差分の前後を確認することで発見できる問題もあります。 しかし、より規模の大きい問題、 たとえば繰り返し登場するパターンを一か所にまとめていないことなどは、 定期的なレビューをしていないと見つけにくいものです。 過去の更新の履歴の記憶を今回の差分と組み合わせることで、 このようなの問題も見つけやすくなるのです。
何もコメントすべき点が見つからないんじゃないかとか、 すべてのコードについて熟知しているわけじゃないとかいったことを気にしないでください。 あらゆるコミットには何かしら言うべきことがあるはずです。 何も疑問点が見つからなかった場合は、何か賞賛の言葉を贈ればいいだけのことです。 大事なのは、すべてのコミッターに対して 「あなたの作業内容を見ているし、理解もしている」というメッセージを伝えることです。 もちろん「後でほかの人にレビューしてもらえるから、コミット前のチェックやテストは不要」 というわけではありません。本来自分自身で発見すべき問題を、 他人のレビューに頼ってはいけません。
既存のプロジェクトをオープンにする場合は、 クローズド環境での開発に慣れきった既存の開発者がいることに注意しましょう。 環境が大きく変わることを彼らに理解してもらうこと、 また、彼ら側の視点で考えた場合に何がどのように変わるのかを あなた自身が理解することが大切です。
彼らにとってその状況がどのようなものかを想像してください。 これまでは、どのような設計でどのようなコードを書くのかを決めるのは 特定のプログラマーの集団でした。また、彼らは同じ管理者のもとで働き、 同じような重圧を受けていました。 そしてお互いのスキルや弱点もよくわかっていました。 今やそうではありません。自分の書いたコードをチェックしてもらうために どこの誰ともわからない人に向かって公開しなければならないのです。 彼らは純粋にコードの内容だけをもとにして判断を下します。 それ以外のビジネス上の問題などは考慮しません。 自分のコードについて、見知らぬ人からさまざまな質問が寄せられることになります。 あんなに苦労して作ったドキュメントが、まだ 不十分であることが判明して (お決まりのパターンです) 衝撃を受ける瞬間です。 新入りさんは、みんな誰も知らない得体の知れない人たちばかりです。 もし既存の開発者の中に自分のスキルに不安のある人がいたとしましょう。 新入りさんが何も考えずに彼のコードの問題を指摘したら、 彼にどのような悪影響を及ぼすでしょうか。特に、 彼の同僚の目の前でそのようなことが起こったら、さらに状況は悪くなります。 完全無欠のプログラマーが集まったチームでもない限り、 このような問題が起こることは避けられません。 実際、すべてのメンバーが一度はこのような経験をすることになるでしょう。 これは、決して彼らがプログラマーとして劣っているからではありません。 ある程度以上のサイズのプログラムには、必ずバグが含まれるものです。 そして、コードのレビューによってそれが見つかることになります (本章の前半にある 「きちんとしたコードレビューの習慣」 をご覧ください)。 と同時に、新入りさん自身は最初のうちは自分のコードをレビューされることはないでしょう。 というのも、そのプロジェクトにある程度なじむまではコードを書くことができないからです。 既存の開発者にとっては「奴らからさんざん批判されるだけで、 こちらからは言い返すことができない」という状況になるわけです。 そのため、古株の開発者たちに対する総攻撃状態になる危険性があります。
これを避ける最良の方法は、これから何が起こるのかを彼らに説明することです。 最初のうちは不快に感じるかもしれないがそれは当然の心理であること、 そしていつかはうまくいくようになることを説明しましょう。 これらの警告は、プロジェクトをオープンにする前に 閉じた場所で行わなければなりません。 また、公開されたメーリングリスト上で 「プロジェクトの開発方式が新しくなった」「なれるには少々時間がかかる」 ということを知らせるのも効果的です。 一番いいのは、なにか例を示すことです。 既存の開発者たちがあまり初心者の質問に答えていないようなら、 彼らに「もっと返事を書いてあげてよ」といってもあまり意味がありません。 彼らは単に、どう答えればいいのかがわからないだけかもしれません。 あるいは、他人の質問に答えるよりも 実際にコードを書くほうが大切だと思っているのかも知れません。 彼らを質問に答えさせるようにするには、まずあなた自身がお手本を見せましょう。 公開されているメーリングリスト上で、誰かの質問に対して答えてみましょう。 その質問をうまくさばくだけの専門知識がない場合は、 それに対応できる開発者に明示的に対応を依頼するようにしましょう。 そして、彼が確かに答えを返すこと、 あるいは少なくとも何らかの返事をすることを確認しましょう。 長年プロジェクトにかかわってきた開発者にとっては どうしても閉じた場での議論のほうがやりやすく感じられることでしょう。 これまではずっとそうしてきたのですから。 そんなことが起こらないように内輪のメーリングリストの動きもチェックし、 必要な議論は公開の場で行うように彼らを誘導しましょう。
これまでは閉じた環境にあったプロジェクトをオープンにするにあたっては、 これら以外にも長期的な懸案事項があります。 5章カネに関する問題 では、給料をもらって開発に参加している人たちと 無償で開発に参加している人たちとをうまく共存させる方法を考えます。また 10章ライセンス、著作権、特許 では、法的な努力の必要性について考えます。 他の団体が書いた、あるいは "所有している" コードを含むかもしれないソフトウェアを公開する場合は、 それなりの注意が必要となります。