そのプロジェクトが目指すゴールに向かってみんなで協力してがんばっていくには、 ただ単に「メンバーがみんな仲良くやっており、 決定的な機能不全は起こしていない」というだけでは不十分です。 プロジェクトのメンバーを管理する役割の人が必要となります。 ボランティアを管理するという技術は、 コンピュータプログラミングの「技術」とは少々異なるかもしれません。 でも、学習と実践を通してうまく行えるようになるという点では、 ボランティアの管理も一種の「技術」であるといえるでしょう。
本章では、ボランティアの管理に関する手法を取り上げます。 これまでの章に比べて、より Subversion プロジェクトでの実例を引き合いに出すことが多くなるでしょう。 というのも本書の執筆時には私はこのプロジェクトで作業しており、 Subversion プロジェクトの過去の資産については熟知しているからです。 また、ちょっと微妙な話題などでは身内のネタのほうが扱いやすいという面もあります。 もちろん、その他のプロジェクトについても調査をしました。 本章で扱う内容に従った (あるいは従わなかった) 結果、 そのプロジェクトはどうなったのか。 政治的な問題をクリアしたものについては、 他のプロジェクトの例も本章で取り上げます。
政治という言葉が出てきたついでに、 みなさんがあまりよく思っていないであろうこの言葉についてよく考えてみましょう。 技術者の多くは「政治的な話なんかうんざりだ。どこか別のところでしてくれよ」と考えがちです。 「僕は はただ、 このプロジェクトのために一番いいのはどの方法なのかを考えて意見を言っているだけなんだ。 なのに 彼女 はといえばいつも政治的な理由であれこれ文句をつけてくる。」 私が思うに、技術者という人種は政治 (あるいは彼らが政治であると思っているもの) を嫌う傾向が特に強いようです。というのも技術者は、 「あるソリューションが他のものより優れているかどうかは客観的に判断できるはずだ」 という考えを持っているからです。 プロジェクトのメンバーが、あまり本質的でない問題に気をとられている (たとえば自分の評価だけを気にする、他人の評判を落とそうとする、 あからさまな駆け引きを行う、他人に嫌われないことばかり考えるなど) ようだと、他のメンバーはあまりいい気がしないでしょう。 もちろんほとんどの場合は、 他のメンバーも重大な関心事については同じように本質的でない振る舞いをしてしまいます。
もしあなたが「政治」という言葉を何か汚らしいものだと感じ、 自分のプロジェクトでは政治的な話を避けるようにしたいと思っておられるのなら、 そんな考えは即刻捨ててしまいましょう。 複数の人間が資源を共有して作業を進めていく以上、 政治的な話は避けることができないものです。 何かのアクションを起こしたときに、 そのプロジェクトにおける各メンバーの影響力がどのように変化するかを考慮する。 これはまったくもって合理的なことです。 結局のところ、もしあなたが多くのプログラマーと同様に 自分の判断とスキルに自信を持っているのなら、 何らかのアクションによって影響力が落ちたとしても、 それは単なる技術的な問題だと考えなければなりません。 同じことが、その他のいかにも「政治的」な振る舞いにだっていえるでしょう。 実際のところ、純粋に「政治」といえるようなものはありません。 人の行動というのは現実社会のさまざまな因果関係の中で行われるので、 人はまず最初に政治的なことを意識するようになります。 政治というのは、一言で言ってしまえば「すべての因果関係を考慮すること」 という合意にすぎません。 とある決定がメンバーの多くを技術的に満足させるものだったとしましょう。 ただ、それによってメンバー間の力関係に変化が生じ、 主要なメンバーが仲間はずれにされたと感じるようなことがあったとします。 この場合、主要なメンバーが感じる気持ちはかなり重要なものとなります。 それを無視してしまうのは、 気高いというよりはむしろ目先のことしか考えていないといえるでしょう。
さて、これ以降のアドバイスを読む際には、 そしてプロジェクトで活動をする際には、 政治のことだけを考えている人なんて どこにもいない ということを心にとどめておきましょう。 政治をしているように見えるのは単なる戦略に過ぎず、 時には有効でしょうが決して現実の政治ではありません。 政治というのは、単に意見の相違が生じたときに起こるもので、 成功しているプロジェクトはそういう状況を建設的に解決するような 政治の仕組みを確立させています。
フリーソフトウェアプロジェクトでボランティアとして働くのは、なぜでしょう? [30]
「なぜ?」と聞かれたら、たいていの人は 「よりよいソフトウェアを作りたいから」とか 「個人的にバグの修正にかかわりたいから」などと答えることでしょう。 ただ、これだけがすべてだというわけではありません。 もし彼らに感謝の言葉を一言もかけなかったとしたら、 もし彼らの言うことに一切耳を傾けなかったとしたら、 それでも彼らはボランティアとして関わり続けてくれると思いますか? もちろんそんなわけはありませんね。 人がわざわざ時間を割いてフリーソフトウェアに関わるのは、 よりよいコードを書きたいなんていう抽象的な重いだけからではありません。 彼らの真の動機を理解しておけば、ボランティアの人たちとうまくやっていくのに役立つでしょう。 「優れたソフトウェアを作り上げたい」とか 「難しい問題に挑戦してみたい」などという思いもその動機のひとつかもしれません。 しかし、人にはもともと「他の人たちと共同作業をしたい」 「他の人に尊敬されたい」といった願望もあります。 共同作業を進めていくにあたっては、 何らかの行動基準を定めた上で 目標に向かってともに進んでいけるようにしなければなりません。
そんな行動基準は、いつも自然に立ち上がるというわけではありません。 たとえば、プロジェクトによっては「頻繁に繰り返し発言する人がよりよい立場を得る」 ように見えるものもあります (オープンソース界で長年すごしてきた人なら、 おそらく「ああ、あれのことね」と頭に思い浮かぶものがあることでしょう)。 決して偶然そうなっているわけではありません。 複雑な議論を長々と続けていることに対する敬意のあらわれとして、 立場が上がってきているのです (実際にその議論がプロジェクトにとって有用かどうかは関係ありません)。 名声を得るための行動が、同時に建設的な行為となるような空気を作り出す。 そのための方法を以下で説明していきます。
「委任」は、単に負荷を分散させる方法というだけでなく 政治的・社会的な道具にもなります。 人に何か作業をたのむことにはどんな効果があるか、考えてみましょう。 いちばんわかりやすいのは、 「お願いを聞き入れてもらえたら、実際の作業は彼が行うことになってあなたは行わない」 ということです。しかし、それ以外の効果もあります。お願いをすることによって 「私はあの人に頼られているんだ」と彼に気づかせることができます。 さらに、もしそのお願いを公開の場でしたのなら、 「『私はあの人に頼られている』ということを、みんなも知っているんだ」 ということにも彼は気づくでしょう。 彼は「あの人の言うことだから、聞かなきゃ」というプレッシャーを感じるかもしれません。 したがって、人に何か頼みごとをするときには、 もし嫌なら気兼ねなく断れるように気配りしなければなりません。 彼に依頼する作業が、プロジェクト内の別の人との調整を要するようなものであった場合、 それは彼に「あなたは他の人とは違う。もう一段階すすんだ協力を頼みたい」 と言うのに等しいといえるでしょう。 そのプロジェクトのひとつのサブドメインを管理させるくらいのことになるかもしれません。 あまりやりすぎると威圧的に受け取られかねず、 彼はその責任の重大さから逃げ出してしまうかもしれません。
これらの効果を考慮すると、 人に何か作業をお願いするのは理にかなったことでしょう。 たとえそれを自分でやったほうが手際よくできることがわかりきっていたとしても。 もちろん、何らかの事情で人にお願いをせざるをえないということもあります。 あなたが自分でそれを行うのがコストに見合わない (他にもっと重要な作業がある) 場合などです。 しかし、そんな差し迫った事情がない場合であっても、 人に作業をお願いすることがあるかもしれません。 将来的にその人にもっと深くプロジェクトに関わってほしいと考えている場合、 最初のうちは少々余分な時間を使ってしまってもかまわないでしょう。 また、逆も成り立ちます。誰か他の人の作業を手伝ってあげれば、 あなたに対する相手の印象はよくなるでしょうし、 相手から尊敬されるようになるでしょう。 委任したり代理をお願いしたりすることは、何も個々の作業だけのことではありません。 プロジェクトへのより深い関わりを持たせることにも関係します。
誰かがその作業を引き受けてくれるであろうことが、ほぼ見当がつくこともあります。 たとえば、誰かがコードにバグを仕込んでしまったとか、 誰かがコミットした内容がプロジェクトのガイドラインに明らかに反しているといった場合です。 そんな場合は、問題点を指摘した上でその当人に対応をお願いするだけで十分です。 彼はきっとその作業を引き受けてくれるでしょう。 しかし、時には相手がそのお願いを聞き入れてくれるかどうかが判断できないこともあります。 お願いを聞いてくれるかもしれないし、拒否されるかもしれない。 「○○をやってくれて当然でしょ」といった態度で頼まれると、 誰もあまりいい気はしません。 人に作業をお願いするときには、状況に応じた適切な方法を考えましょう。
相手がもっともいらつくであろうパターンは、 本人にはその気がないのに「これはあなたがやるのが当然でしょ」 といったことを匂わせてお願いすることです。 たとえば、バグ対応の担当者を決めるときに このパターンがしばしば発生します。 プロジェクトのメンバー間では、誰がどの分野に詳しいかは だいたいわかっています。何かバグ報告を受け取ったときに、 「これは彼にやってもらえばすぐに修正できるだろう」 と見当がつくこともよくあるでしょう。 しかし、だからといって、 何の前置きもなしにいきなりその人に対応をお願いしたりすると、 相手は気を悪くするかもしれません。 「私は期待されているんだ」と喜んでもらえるかもしれませんが、 それと同時に「私にこの技術があるばっかりに、 こんな作業を押し付けられるんだ」と感じることもあるかもしれません。 バグ対応というのは技術を身につけるためのよい作業でもあります。 こんな場合は、あえて誰か他の人に対応を任せるのもいいでしょう! (バグ追跡システムの中には、バグ報告の内容に応じて 自動的に担当者を決める機能を持つものもあります。 このようなシステムを使用すれば、「押し付けられる」 という感覚はあまりなくなるでしょう。というのも、 これはあくまで機械的に割り当てられるものであり、 私情が挟まれていないことがわかっているからです)。
特定の人に負荷がかからないよう、 できるだけみんなに均等に作業を割り当てることは大切です。ただ、時には、 いちばんわかっている人に一刻も早く対応してもらいたいこともあるでしょう。 そんなときに毎回根回しをする (「このバグ、ちょっと見てくれないかな?」 「いいよ」「わかった。じゃあ担当者を君に設定するよ」「オーケー」) 時間が割けないのなら、できるだけ圧力を感じさせないように 淡々とお願いするようにしましょう。 ほぼすべてのバグ追跡システムには、 担当者を決めるときにコメントをつける機能が備わっています。 そのコメントで、次のように言うといいでしょう。
君にお願いするよ、jrandom。たぶん君がいちばんこのコードに詳しいだろうから。 もしその時間がなかったら、気兼ねせずにつき返してくれてもいいよ。 (で、もし今後こんな依頼を受けるのがいやだっていうのなら、 そう言ってほしいんだ)。
こうすれば、誰かに作業を 依頼 することと相手がそれを 受諾 するかどうかということを明確に区別することができます。 ここで、このやり取りは当事者間だけでなく全員が見ていることに注意しましょう。 その人に技術があるとみなされていること、 そしてその人に依頼を受諾するかどうかの決定権があることが全員に伝わるのです。
誰かに何かの作業を依頼したら、 その後のフォローも忘れないようにしましょう。 これは通常、公開のフォーラムで行います。次のような形式になるでしょう。 "ところで、X についてはどうなっていますか? 教えてください。 別に無理ならそれでも気にしません。ただ単に気になっただけなので。" 返事があるかもしれませんし、あるいはないかもしれません。 あまり状況が芳しくないという返事があったら、 X について何か別の対応策を考える必要があります。 順調だよという返事があったら、しばらくはその作業の進捗を気にしないようにしましょう。 進捗状況について、簡単にコメントだけしておきます (人はみな、自分の作業が他人に認められていることを知るとうれしいものです)。 数日待っても返事がなかった場合は、 もう一度聞いてみるか、あるいは 「返事がなかったんだけど、誰か他に X についての状況を知っている人はいますか?」 という投稿をすることになります。あるいは自分で調べることになるかもしれませんが、 その場合でも「最初の問いかけに対して返答がなかったので」 という投稿をしておくようにしましょう。
返事がなかったことをわざわざ投稿するのは、 決して その相手を非難するものではありません。 また、周りにそのように受け取られないように言い回しには注意しましょう。 目的は、単に「この前たずねたことをまだ気にかけていますよ。 何か反応があったらすぐ気づきますよ」という姿勢を示すことです。 そうしておけば、次に同じようなことがあったときに反応を得られやすくなります。 周りの人たちから、あなたはどんなちょっとしたことでも見逃さない人だ ということを認識してもらえるからです。
自分が何に興味を持っているのかをわかってもらえていると、 人はうれしいものです。一般論として、 周りの人たちの性格をしっかり把握しておけば彼らはいい気分になるでしょう。 そして、あなたと一緒により多くの作業をしたいと思うようになることでしょう。
たとえば Subversion プロジェクトにおいては、 「まずは何とかしてバージョン 1.0 のリリースにこぎつけたい (現在はリリースされています)」 という人たちと 「新機能を追加したり興味深い問題を解決したりといったほうが先決だ。 バージョン 1.0 がいつリリースされるかなんて、そんなの関係ないよ」 という人たちとに明確に区別することができました。 どちらがいいとか悪いとかいうことではありません。 世の中には二種類の開発者がいるというだけのことです。 そしてどちらのタイプの開発者もプロジェクトに多大な貢献をしてくれています。 私たちにはすぐにわかりました。 「1.0 のリリースに向けてがんばろう!」 といった動機付けでみんなを一丸にできるなんて思わないほうがいいということを。 電子メディアは非常にあてにならないものです。 この気持ちはみんなで共有できていると感じていたとしても、 実際にそう思っているのは当事者だけで、 周りの人たちはまったく別の方向を見ていることもあるのです。
みんながそのプロジェクトに何を求めているのかに注意すればするほど、 周りに効率よく作業を依頼できるようになります。 実際に作業を依頼しなくても、 「あなたが何を求めているのかはわかっているよ」 ということを示すだけでも大事です。そうすれば、 自分がその他大勢のひとりではないということをみんなに気づかせることができます。
賞賛と批判は決して相反するものではありません。 多くの場合において、両者は非常に似通っています。 両者はともに、相手の気を引くことが主目的であり、 全体的なことを言うよりも特定のことに絞った方が効果的です。 また、どちらも具体的な目標を定めた上で行わなければなりません。 やり過ぎると、どちらの効果も薄れます。 必要以上にほめすぎたり、あまりにも頻繁にほめまくっていたりすると、 あなたのほめ言葉の価値が下がってしまうことでしょう。 批判だって同じです。ただ実際は、 批判のほうについては価値が下がる速度は多少遅くなるでしょう。
技術者の文化の中で重要なのは、詳細かつ冷静 (個人的な感情に左右されていない) 批判は、一種の賞賛とも受け取られるということです (6章コミュニケーション の 「何が失礼にあたるのか」 で説明しました)。なぜなら、 その作業はきちんと精査するだけの価値があるものだということが暗示されているからです。 しかし、あくまでも 詳細 かつ 冷静 というふたつの条件を満たしている場合のみであることに注意しましょう。 たとえば、誰かがコードにいい加減な変更を加えたとしましょう。 そんなときに単に「そんないい加減な変更はするな」とだけ言うのは無意味です (というか、有害でさえあります)。いい加減なのは、 結局はその人の性格の問題であり、その作業成果とは関係ありません。 実際の作業成果に対してのみ反応するようにしましょう。 変更内容の中でまずいところを、淡々と指摘していくほうがずっと効果的です。 同じ人が何度も何度も同じようなケアレスミスを繰り返すようなら、 批判の最後に「同じことが繰り返されている」と指摘するのもいいでしょう。 ただし、その場合も、怒りを抑えることを忘れないようにしましょう。
批判を受けても相手が何も変わらなければ、 もう少しきつめな対応をすることになります。 この場合の対応としては、 できるだけ相手を傷つけないように彼の地位を奪うといったことがあります。 本章の後半の 「引き継ぎ」 で、この実例をご覧いただきます。 しかし、これは滅多に起こることではありません。 たいていの人は、具体的で詳細な批判を受け取れば (口には出さずとも) 何らかの改善の姿勢を見せるものです。
ほめ言葉は誰も傷つけることはありません。 ただ、だからといって何も考えずにほめまくればいいというものでもありません。 賞賛は、一種の道具であるともいえます。 使う前には、なぜ そうするのかを検討するようにしましょう。 一般論として、人がふだんからごく普通に行っていることをほめるのはあまりいい考えではありません。 あるいは、そのグループに参加する上で当然のこととして期待されている作業に対しても、 特にほめることはないでしょう。 それをやり始めると、いつやめるかの判断が難しくなってしまいます。 当然のことをやっている人たち 全員 を個別に賞賛してまわりますか? どこかで線を引いてしまうと、 ほめられなかった人は「なぜ?」と思うでしょうね。 それよりも、いつもとは異なる働きをした人や 予期せぬ活躍をした人に対して 控えめに賞賛の言葉を贈るほうがずっと効果的です。 そして、「これからももっとがんばってね」と励ますわけです。 メンバー全体の生産性が一段階向上したと見なせるようになったら、 賞賛の言葉を贈る基準もそれにあわせて少し厳しめに変えましょう。 通常の行いに対して賞賛を繰り返すと、そのうちにそれは無意味になってしまいます。 みんなが高い生産性を発揮してくれているのは もはや予想以上の働きでもなんでもなく期待通りのものであるわけで、 それをさらに上回る働きをした時点で改めて賞賛の対象となるわけです。
もちろんこれは、みんなの貢献を受け入れてはいけないという意味ではありません。 でも、知っておいてほしいのです。 プロジェクトがうまく機能していれば、みんなが何をやっているのかは すでにわかるようになっているわけです。 そして、誰かがやった作業はメンバーみんなが知っている (ということを、それをやった本人も気づいている) わけです。 直接賞賛の言葉を贈る以外にも、人の作業に対して何らかの意志を表明する方法はあります。 たとえば、何らかの議論をしているときに 「このへんについては彼女が多くの作業をしてくれているし、 彼女が詳しいだろう」と言ってみる。 あるいは、みんなに見える場所でコードの内容について彼女に尋ねてみる。 または、もっとも効率的な方法としては、 彼女の作業成果に基づいてさらなる作業を行うといったものもあります。 そうすれば、自分の作業が他人に認められているということを彼女も感じてくれるでしょう。 これらの行為は、別に計算の上で行わなければならないというものではありません。 プロジェクトに多大な貢献をし続けている人は、 何もしなくても自然にプロジェクト内での影響力を高めていくものです。 正当な評価を受けていないとあなたが感じた場合を除き、 それを後押しするために何らかの作業をする必要はありません。
プロジェクトの特定の分野において、 だれかが作業を独占しようとし始めたら要注意です。 誰かが始めようとした作業を積極的に引き継いだりといったことなどがそれにあたります。 そのような振る舞いは、最初のうちは健全なものに見えるかもしれません。 表面的には、その人がより多くの作業を引き受けてくれることで その分野の作業を活発にさせてくれるように見えるかもしれません。 しかし、長い目で見た場合、これはあまりよい兆候ではありません。 周りの人が "あそこに立ち入っちゃいけない" と感じるようになると、 みんなそこにはかかわらなくなります。 その結果、どうなるか。その分野のレビューが機能しなくなり、 もろいものとなってしまいます。 一人の開発者がすべての責任を負ってしまい、 その人が欠ければそれでおしまいになってしまうからです。 さらに悪いことに、それは プロジェクトの平等主義や協力体制を壊してしまうことになります。 理論上は、すべての開発者が 好きなときに好きな作業に参加できるようにしておくべきです。 もちろん、実際には多少異なることはあるでしょう。 その人によって得意な分野やそうでない分野があるでしょうし、 素人は達人の言うことに従うしかないという分野もあるでしょう。 しかし、重要なのは、これらはすべて自発的に参加する作業であるということです。 能力や実績にもとづいて非公式に権限を与えることもありますが、 決してそれを積極的に受け入れることがあってはなりません。 権力を欲している人が仮に有能な人であるとしても、 あくまでもその権威は非公式なものとすべきです。 つまりメンバー間の合意によるものということです。 また、その権威によって他のメンバーの介入を妨げることがあってはなりません。
誰かの作業内容を、技術的な理由で取り消したり編集したりするのは、 もちろん全然違う話です。 この場合、決定的な要素は作業の中身であり、 誰がその作業の責任を負っているかではありません。 たまたま特定の分野のレビューを行うのが特定の人に集中してしまうかもしれませんが、 その人が他人の介入を拒否しない限りは特に問題はありません。
縄張り主義が登場するのを防ぐために、 多くのプロジェクトではソースファイルから作者名や保守担当者名を取り除くようになっています。 私は心からこの習慣に賛同します。 Subversion プロジェクトでもこの方式を採用しており、 Apache Software Foundation でもそれは事実上の公式方針となっています。 ASF のメンバーである Sander Striker は次のように述べています。
Apache Software foundation では、ソースコードに author タグを使用しないことを推奨しています。 これには、法的な問題以外にさまざまな理由があります。 共同開発とは、みんなで一丸となって作業に取り組み、 みんなで一丸となってプロジェクトにかかわるということです。 クレジットを与えるのもいいでしょう。というか、むしろすべきでしょう。 でも、間違った情報を与えることになってしまってはいけません。 どんなときに author タグを追加するのか。 あるいはどんなときに削除するのか。 明確な基準などありません。 コメントを書き換えただけのときにあなたの名前を追加しますか? たった 1 行だけ修正したときは? コードをリファクタリングして、元のコードとは 95% ほど違うものになったとしましょう。 こんな時に、元の作者の author タグを削除しますか? すべてのファイルをちょっとずつ修正して、 自分の名前がすべてのファイルに登場するようにする人がいたとしましょう。 あなたはそれを見てどう思いますか?
クレジットを与えるよりもいい方法があります。 私たちとしてもそちらをおすすめします。 技術的な側面から見て、author タグは不要です。 特定のコードを誰が書いたのかを知りたければ、 バージョン管理システムを使用すればすぐにわかることです。 また、author タグは更新が遅れて現状を反映しなくなりがちです。 5 年前に書いたっきりで忘却の彼方にあったコードについて 個人的に問い合わせられたとして、あなたはどう思いますか?
ソフトウェアプロジェクトにおいて、 ソースコードファイルこそがその存在の証となります。 開発者コミュニティー全体でソースコードに責任を持つべきであり、 小さなグループに分けてしまってはいけません。
ソースコードで author タグや maintainer タグを使用したいと文句を言う人もいるでしょう。 そうすれば、誰がもっともがんばっているかが一目瞭然になるからというわけです。 しかし、この意見にはふたつの問題があります。 まず、「どの程度の作業をしたら名前を追加してもいいのか」 といったどうでもいい問題が必ず立ち上がってきます。 次に、クレジットを得ることがまるで権威を得ることであるかのような勘違いを起こしてしまいます。 過去にその部分の作業をしたからといって、コードのその部分が作業をした人のものになるわけではありません。 しかし、ソースファイルの先頭に個人の名前が並べられていたら、 そんな風に勘違いしてしまうことが避けられません。 いずれにせよ、クレジットは既に得られているわけです。 たとえばバージョン管理システムのログやメーリングリストのアーカイブなどでそれがわかります。 したがって、ソースファイルからクレジットを削除したところで 何も失われる情報はありません。 [31]
あなたのプロジェクトで「ソースファイルには作者の名前を記載しない」
ことに決めたとしても、決してやり過ぎないようにしましょう。
たとえば、多くのプロジェクトには contrib/
という領域があって、細々したツールやヘルパースクリプト類をここで管理しています。
これらの中には、特定の人が作成したものであってプロジェクトとは関連のないものもあります。
そんな場合には作者の名前を含めてもかまわないでしょう。
だって実際のところ、そのファイルはプロジェクト全体で管理しているわけではないのですから。
一方、そのようなツールをプロジェクトの他のメンバーがハックするようになり、
本格的にプロジェクトに含めたくなることもあるかもしれません。
そのような場合は、原作者の承認を得た上で作者のクレジットを削除し、
プロジェクトで管理している他のリソースとあわせるようにします。
原作者がそれをいやがった場合、妥協案としては次のようなものが考えられます。
# indexclean.py: 古いデータを Scanley インデックスから削除する # # 原作者: K. Maru <kobayashi@yetanotheremailservice.com> # 現在の保守担当者: The Scanley Project <http://www.scanley.org/> # そして K. Maru. # # ...
しかし、できればこうした妥協は避けたいものです。 また、ほとんどの人は、言うことを聞いてくれることでしょう。 自分の作ったものがそのプロジェクトにより深く組み込まれていくというのはうれしいものです。
大事なのは、どんなプロジェクトであっても その中心部と周囲はきっちりつながっているということです。 本体のソースコードファイルは明らかにプロジェクトの中心となるものであり、 コミュニティー全体で管理しなければなりません。 一方、周辺のツールやドキュメントの中には特定の個人が保守しているものもあるかもしれません。 たとえそれがプロジェクトに関連するものであったり プロジェクトとともに配布されている場合であっても、 本質的にひとりで保守を担当していることになります。 すべてのファイルに対して画一的な規則で縛る必要はありません。 ただし、コミュニティー全体で管理しているリソースは 決して個人で囲い込んでしまってはいけないということを覚えておきましょう。
機械にできることは、わざわざ人間にさせずに機械に任せてしまいましょう。 おおざっぱに言って、定型作業を自動化すれば少なくとも効率が 10 倍にはなるでしょう。 頻繁に行う作業であったり複雑な作業であったりした場合は、 20 倍以上になることも珍しくありません。
ここでは、あなたが単なる一人の開発者ではなく "プロジェクトの管理者" になったつもりで考えてみましょう。 各開発者は、各個人がやっている枝葉の作業に精一杯で プロジェクト全体の様子 (自動化できる作業をわざわざ手作業でやってしまっているなど) が見えていないかもしれません。 それに気づいている人であっても、わざわざ時間を割いて問題を解決しようとは思わないでしょう。 実際のところ、各個人の作業自体は重荷となるほどのものではなく、 「何とかしなきゃ」と思うほどには困っていないのです。 たとえ個々の作業にかかる時間はわずかなものであったとしても、 各開発者がそれを行う回数だけ掛けるとどうなるでしょう。 さらにその結果を開発者の人数分だけ掛けたら? ……ということを考えだすと、自動化は無視できなくなります。
ここでいう "自動化" とは、広い意味の自動化を指しています。 いくつかのパラメータを指定して同じ動作を繰り返すというものだけでなく、 人間の作業を支援する技術的な仕組み一般を指して "自動化" といっています。 いまどきのプロジェクトの運営における最低限必要な自動化については 3章技術的な問題 で説明しました。 しかし、これら以外にも各プロジェクトに固有の問題もあることでしょう。 たとえば、ドキュメント担当チームの場合は、 常に最新版のドキュメントが公開されているウェブサイトが必要かもしれません。 たいていの場合、ドキュメントは XML などのマークアップ言語で作成されるので、 コンパイルが必要となるかもしれません。 表示用とダウンロード用のドキュメントを作成するなど、 このコンパイル処理は複雑なものになることもあります。 コミットがあるたびに最新版をコンパイルしてウェブサイトに反映させるというのは、 複雑で時間のかかる処理です。 しかし、何日かかけてでもその仕組みを作成する価値はあります。 最新の状態を確認できるようにする仕組みがないとしても、 それで困るのはほんの一握りの人たちだけかもしれません。 それでも、その仕組みを作ることによる利益は計り知れないものがあります。
このように自動化すると、時間の浪費が解消されるだけでなく 人間が手動で作業したときの作業ミス (ミスは必ず発生します) でいらいらすることもなくなります。 何段階にも及ぶ複雑な定型作業なんて、まさにコンピュータにやらせるべきものです。 そもそもコンピュータが発明されたのはそういう作業をやらせるためだったのですから。 そんな作業はコンピュータに任せ、 人間はもっと創造的な作業に時間を割くようにしましょう。
テストの自動化はどんなソフトウェアプロジェクトにとっても有用ですが、 オープンソースプロジェクトでは特に有用となります。 自動テスト (特に回帰テスト) を行うことで、 不慣れな分野のコードでも安心して変更できるようになります。 これは、開発の効率を大きく向上させます。 問題の原因を人間の目で検出するのは大変 (まず「このあたりに問題があるのではないか」と見当をつけ、 その部分に問題がないかどうかあらゆる手段で調べることになります) なので、それを自動化すれば 大きな 時間の節約になります。
回帰テストは決して万能というわけではありません。 バッチ処理的なプログラムではうまく動作するでしょうが、 たとえばグラフィカルなインターフェイスで操作するプログラムに適用するのは難しいものです。 もうひとつの問題として、回帰テスト用のフレームワークが非常に複雑なものであるということが挙げられます。 まともに使いこなせるようになるまでにはかなりの時間がかかることでしょう。 この複雑さをなんとか軽減させることが大切です。 たとえ時間がかかったとしても、 その努力は必ず報われます。 新しいテストをテストスイートに追加しやすくすればするほど、 多くの開発者がテストを作成してくれるようになります。 その結果として、リリース後に見つかるバグも少なくなるでしょう。 テストを書きやすくするために費やした努力は、 将来にわたってそのプロジェクトに大きな効果を及ぼします。
多くのプロジェクトでは "Don't break the build!" という決まりがあります。これは、コンパイルできなくなったり 実行できなくなったりするような変更はコミットするなという意味です。 そんなコミットをしてしまった人は、 かなり気まずい思いをすることになるでしょう。 回帰テストを採用しているプロジェクトの場合、この決まりはもっと明確になります。 つまり「テストが失敗するような変更はコミットするな」 ということになるのです。 テストスイート全体を毎晩自動実行するようにしておけば、 このようなコミットを検出することは容易です。 そして、テストの実行結果は開発者向けメーリングリスト (あるいはテスト結果専用のメーリングリスト) に送るようにすればいいのです。 ほら、ここにもまた自動化の例がひとつ登場しました。
わかりやすくて作業しやすいテストシステムがあれば、 たいていの開発者は喜んで回帰テストを作成してくれるでしょう。 変更をするときはテストも作成するというのは共通認識となっています。 この作業は、複数で協力して行うこともあります。 バグ修正作業を二人で分担し、一人が実際の修正を行って もう一人がテストを書くといったようにです。 テストを書く側の担当者のほうが、作業量は多くなりがちです。 もともと実際のバグ修正にくらべてテストを書く作業はつまらないものなので、 テストを書くのが苦にならないようにする必要があります。
プロジェクトによっては、さらに厳しい規則を設けていることもあります。
バグ修正や機能追加を行う際は、必ず
新しいテストを追加しなければならないといったものです。
このような規則を設けることのよしあしは、多くの要素に依存します。
「そのソフトウェアがどんな類のものなのか」
「開発チームの構成はどのようなものなのか」
「新しいテストを書く難易度はどれくらいか」
などが考慮の対象になります。
CVS (http://www.cvshome.org/)
プロジェクトでは、長年この厳しめの規則を採用しています。
理屈の上では、これはよい方針でしょう。
CVS はバージョン管理用のソフトウェアであり、
ユーザーのデータを壊して復旧できなくしてしまうようなことがあってはならないからです。
ただ、実際に運用していく上では問題がありました。
CVS の回帰テストスイートは、ひとつの巨大なシェルスクリプトでできています
(sanity.sh という変な名前がついています)。
これは非常に読みづらく、また修正したり拡張したりするのも大変なのです。
新しいテストを追加するのが大変であること、
そしてパッチが受け入れられるためには新しいテストが必須であること。
これらによって、CVS は事実上パッチの受け入れを拒否しているようなものだと言えます。
かつて私が CVS プロジェクトで作業をしていたころ、
「CVS のパッチを作成したんだけど、sanity.sh
にテストを追加しなきゃならないっていう話を聞いて結局あきらめた」
という人を散々見てきました。
バグの修正そのものより新たな回帰テストを書くほうが時間のかかるというのは ごく普通のことです。ただ、CVS の場合はそれがちょっと極端すぎます。 数時間かけて自分用のテストを作ったとしても、まだそれが間違っているかもしれません。 35,000 行にもおよぶシェルスクリプトの中には、 思いもよらぬような込み入った仕組みが潜んでいるからです。 長年 CVS にかかわっている開発者でさえも、 新たなテストを追加するときには不満をもらすことがあります。
このようになってしまった原因は、 私たちが自動化の割合について考えていなかったことです。 自前で作るなり既存のものを使うなりして、 本物のテストフレームワークに移行しようという試みはありました。 [32] しかし、長年それを怠ってきたツケが今まわってきているというわけです。 この使いづらいテストスイートのせいで現在の CVS に取り込まれて いない バグ修正や新機能って、いったいどれくらいになるんでしょう? 実際のところは知りようがありません。ただ、 新しいテストシステムを開発 (あるいは既存のシステムを採用) する時間を確保するために減ってしまうバグ修正・機能追加の数よりはるかに多いことは確かです。 テストシステムを移行するのにかかる時間は有限のものですが、 何もせず現状のテストスイートを使い続けることによる被害は永遠に続くわけですから。
ここで言っているのは、「テストを書くよう厳しく要求するのはダメ」 ということではありません。また、 テストシステムをシェルスクリプトで書くのが必ずしも悪いというわけでもありません。 きちんと設計した上であれば、それが有用な場合もあるでしょう。 言いたかったのは、「もしテストシステムが開発の障害になっているのなら、 何か手を打たなければいけない」という単純なことです。 その他の定型作業も一緒です。 もしそれが障害やボトルネックになっているのなら、 何らかの対処が必要です。
ユーザーとのやり取りは、 そのプロジェクトに新たなメンバーを迎え入れるためのチャンスでもあります。 わざわざ時間を割いてプロジェクトのメーリングリストに投稿してくれたり バグ報告をしてくれたりといった時点で、その人は その他大勢 (の、そもそもそのプロジェクトのことなんか知らない人たち) よりもより深くプロジェクトに興味を持ってくれていることがわかります。 そんな人たちをうまく釣り上げてしまいましょう。 バグ報告を受け取ったら、その人に感謝したうえで 「ところで、それを自分で修正してみる気はない?」 と聞いてみるといいでしょう。 FAQ に載せるべき質問が欠けているだとか プログラムのドキュメントが不十分だとかいう指摘を受け取った場合は (実際にそんな問題があったと仮定します)、 指摘をしっかり受け入れた上で 「ところで、それを自分で書いてみる気はない?」 と聞いてみましょう。 当然、たいていの場合は「いえ、そこまでは……」と断られるでしょう。 でも、聞いてみること自体にはそんなに手間はかかりません。 それに、毎回そのように返事をしていれば、 その他の参加者も「何か自分ができることで プロジェクトに参加できるんだな」と気づくはずです。
目標は、単に新たな開発者やドキュメント作者を確保することだけではありません。 みんなによりよいバグ報告をしてもらえるように仕向けることは、 長い目でみれば十分に採算の取れることです。 ほんの少しの手間で彼らが将来多くのバグ報告をしてくれるようになればすばらしいと思いませんか? そのためには、初めてバグを報告してくれた人に対して建設的な反応を返すことが大切です。 建設的な反応とは、単にバグを修正するということだけではありません (もちろんそれが理想ではあります)。 たとえば、より詳細な情報を提供するよう相手に求めたり、 あるいはただそれがバグであるということを認めるだけでも建設的な反応といえます。 人は誰でも、自分の意見に耳を傾けてほしいものです。 また、バグを報告した人はそのバグが修正されることを望んでいます。 後者の望みはすぐにはかなえられないこともあるかもしれません。 しかし、あなた (というか、あなたのプロジェクト) が前者の望みをかなえてあげることはできるはずです。
当然のことですが、 「何か言いたいのはわかるけれども具体的なことがさっぱりわからない」 ようなバグ報告にたいしても腹をたてたりしてはいけません。 個人的に、私はこのような態度は気に入りません。 さまざまなオープンソースのメーリングリスト上で、このような開発者が見られます。 そして、その害は明白です。 かわいそうな新入りさんが、次のような無意味な報告を送ってきたとしましょう。
Scanley が動かないんだけど。 起動しようとするとエラーが出るんだ。 他のみんなは大丈夫なのかな?
過去にこの類の報告を数限りなく見てきた開発者のなかには、 こんな答えを返す人がいます。
ちっ。そんな情報だけでいったいどうしろって言うんだよ。 もっと詳しい情報を教えてくれないと。 せめて Scanley のバージョンとか OS の種類、あとエラーメッセージくらいは必要だ。
こんな答えを返す人は、ユーザーの目線で考えることができていないのでしょう。 そして、そんな反応が その他の 人たちにどんなふうに思われるかにも考えが及んでいないのでしょう。 プログラミングの経験がない人やバグ報告の経験のない人などは、 正しいバグ報告の方法なんて知らないかもしれません。 そんな人への対応はどうしたらいいのでしょう? 教育しちゃえばいいんです! どうせするなら、よりよい返事をもらえるようにしてみましょう。
ご迷惑をおかけして申し訳ありません。 何が起こったのかを調べるためには もう少し詳細な情報が必要です。 Scanley のバージョンと使用している OS、 そしてエラーの正確な内容を教えてくれませんか? あと、実行したコマンドとその出力結果を正確に教えてもらえると助かります。 詳細は http://www.scanley.org/how_to_report_a_bug.html をご覧ください。
必要な情報をユーザーから引き出すには、 こういった感じの返答のほうがずっと効果的です。 なぜなら、この返答はユーザーの視点に立って書かれているからです。 まず 1 点目。この返答では「問題があったんですね。 お察しします。さぞ大変だったことでしょう」 と同情の意を表しています (バグ報告に対して毎回このようにする必要はありません。 バグの深刻度、そしてユーザーがどの程度困っているのかに応じて使いわけます)。 次に 2 点目。バグ報告のお作法を知らないことをバカにするのではなく 「どうしたらいいのか、どんな情報がほしいのか」といったことを説明しています。 ごく一般的なユーザーは、「エラーの内容を教えて」と言われても、それが 「エラーメッセージを正確に教えてください。途中までで切ったり 変に省略したりしないこと」という意味であるとはわかりません。 そんなユーザーに対応する場合は、とくに事細かに説明しなければなりません。 最後に 3 点目。より詳しい、きちんとしたバグ報告をするための方法がわかるよう、 ポインタを示しています。うまく対応すれば、 きっとこの報告者はリンク先のドキュメントを読んでその内容を理解してくれるでしょう。 もちろん、事前にそのためのドキュメントを用意しておかなければなりません。 そのドキュメントでは、開発チームが バグ報告の際にどんな情報を欲しているのかを明確に説明しておくようにします。 理想を言えば、プロジェクトにおけるユーザーのバグ報告の内容にあわせて そのドキュメントを日々改良していくことが大切です。
Subversion プロジェクトにおけるバグ報告の説明は、まさにこの形式のよい例といえます (付録E バグ報告のやり方を説明した例 をご覧ください)。 最後のほうに、バグを修正するためのパッチの提供を促している箇所があることに注目しましょう。 そうしたからといって、バグ報告におけるパッチの添付率が上がるわけではありません (バグを修正できるくらいのレベルの人なら、 いちいち言われなくてもパッチが有用であることを知っているはずですから)。 真の目的は、すべての読者 (特にそのプロジェクトに初めて参加する人たち、 あるいはフリーソフトウェアの世界に初めて足を踏み入れる人たち) に対して「このプロジェクトは多くのボランティアの貢献によって成り立っている」 ということを示すことです。プロジェクトの開発メンバーだからといって、 バグ修正に対する責任がバグの報告者より重いということはありません。 新入りさんにはあまりなじめない考え方でしょうが、これは重要です。 それをみんなに理解してもらえれば、 バグ修正のための手助けをより多く得られるようになるでしょう。 コードが書けない人であっても、バグの再現手順を詳細に説明したり だれかのバグ修正の内容を検証したりといった支援は可能です。 最終的な目標は、みんなに「自分とプロジェクトのコアメンバーの間には 本質的な 違いはない」ということを理解してもらうことです。
失礼なユーザーに対しては、多少きつく対応しても許されるでしょう。 たまに、バグ報告や苦情を書く際に 状況を考えずにプロジェクトをバカにした態度をとる人がいます。 このような人は、バカにしたかと思えば急にこびへつらってきたり、 態度をコロコロ変えることがよくあります。かつて Subversion のメーリングリストにこんな投稿をした人がいました。
6 日もたったのに、いまだに Windows 版のバイナリがないってどういうこと?!? 毎回こんなことが続くんで、もういらいらしっぱなしだよ。 そんなの自動化しちゃえばいいだけのことでしょ?? "RC" 版を出したってことはそれをみんなに使ってほしいんでしょ? なのにこんな状態だと使うこともできないじゃないか。 試しようがないのなら、テスト期間なんて無駄じゃない??
この煽り気味の投稿に対する返信は、どれも驚くほど落ち着いたものでした。 このプロジェクトではバイナリ版をリリースしない方針になっていることを指摘し、 そんなにバイナリが大事なのなら自分でそれを作って提供するべきだと返信したのです。 驚くなかれ、彼の次の投稿はこんな一文から始まっていました。
まず最初に一言。Subversion は最高のツールだし、 プロジェクトのすべての参加者には本当に感謝してるんだよ。[...]
...といった舌の根も乾かぬうちに、また バイナリを提供しないことに対するプロジェクトへの批判を続けたのです。 彼は自分では何もしようとしませんでした。それに対して、 50 人ほどが彼を批判する返信をしました。 私はそれを見ても、とくに気に病むことはありませんでした。 2章さあ始めましょう の 「炎上を阻止する」 で説明した、 失礼な人に対する「ゼロトレランス (情け容赦なく)」という考え方は、 そのプロジェクトに対して継続的にかかわり続ける人たちに対するものです。 しかし、相手がただ単に不満をぶちまけているだけなんだということがわかってしまえば、 彼に対して気配りをしても無意味です。
幸いなことに、こんな状況になることはほとんどありません。 初心者に対してもより建設的な対応を心がけているプロジェクトでは、 まずこのようなことはありえないでしょう。
24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.
poss2 tbd
Some examples to use: Ubuntu community sprints, Adam Hyde's flossmanuals doc sprints, and the Danese/Noel-style public hackathons. Distinguish between purely dev events and dev+user+funder+enterprise events — all are useful, but don't confuse audiences.
[30] この疑問について詳しく調査したところ、興味深い結果がでました。 Karim Lakhani と Robert G. Wolf による論文 Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects にまとめられています。 http://freesoftware.mit.edu/papers/lakhaniwolf.pdf をご覧ください。
[31] しかし、http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee の "having authors names in .py files" というスレッド、特に William Stein の投稿は、その反論となるでしょう。 私が思うに、この場合のキーとなるのは、 作者の多くが「ソースに直接クレジットを書くのが当然であり、 それが高く評価される」という文化 (数学者のコミュニティー) の出身であるということです。 このような場合はソースファイルに作者名を埋め込んでもいいでしょう。 そして個々の作者が具体的に何をしたのかを正確に記載しておきます。 そうすれば、今後新たに開発に加わる人たちにも 「そういうものなんだ」と認識させることができます。
[32] 既存のテストをすべて新しいフレームワークに移行させなければならないというわけではありません。 両者を共存させることもできるでしょう。 必要になったものだけを新しい形式に変換すればいいのです。