合意と投票で構築されるOSS開発の社会構造：オープンソースソフトウェアの育て方（2/4 ページ）

[Karl Fogel， ]

合意に至らなければ投票する

　議論によっては、結論がでないことが必ずあります。行き詰まった状態を打開するあらゆる手段が失敗に終わった場合、投票が打開策になります。投票を行う前には、結論の候補となる選択肢を明確にしなければなりません。ここで、普段やっている技術的な議論をしてみると、結論を出す手続きと意外によく合っていることが再び分かるでしょう。

　投票になる論点は、複雑で多面的な問題を含むことがたびたびあります。こういう複雑な議論では、仲裁人の役割を果たす人が普通1人か2人はいます。彼らは定期的にさまざまな主張をまとめたものをポストし、反対（賛成）意見の核がどこにあるのかを追いかけています。こうしたまとめは、議論がどのくらい進んでいるのかを知ったり、どういう問題に取り組んでいるのかを覚えておくのに役立ちます。また、実際に投票が必要になった場合に、投票用紙のひな型として役立つかもしれません。

　仲裁人が仕事をうまくこなせば、時が来れば皆に投票しましょうと呼びかけることもできるでしょうし、プロジェクトは彼らが作ったまとめをベースにした投票用紙を使うことができるでしょう。仲裁人自身は、議論に参加していても構いません。つまり、対立する人の意見を理解し、中立的に表現でき、自分の同志の気持ちが議論を中立的にまとめるのを妨げなければ、賛成、反対の立場を超越した立場にいる必要はないのです。

　投票用紙の実際の内容は、議論の余地がないものになるのが普通です。投票が実際に行われるまでに、反対意見は2、3のキーとなる問題にまとめられ、理解できるラベルや簡単な説明がつけられます。開発者が投票用紙の形式そのものに反対する場合もあります。そういう人は、例えば重要な選択肢が抜けていたり、選択肢に対する正確な説明がないといった、投票が正しいものかどうかを心配していることがありますが、投票によって出る結論が自分の望むものに絶対ならないことをたぶん知っていて、投票を避けようとしているだけの場合もあります。この手の妨害行為をどう扱うかは、章6.コミュニケーションの扱いにくい人たち項を参照してください。

　投票システムを必ず決めるようにしましょう。なぜなら、投票システムにはたくさんの種類があり、どういった手続きが取られるのかについて参加者が間違った想定をしている可能性があるからです。

　ほとんどの場合に適しているのは認定投票です。このシステムでは投票者が自分が好む選択肢をできるだけ多く投票できます。認定投票は説明するのも、得票数を数えるのも簡単ですし、ほかの方法と異なり、一回の投票で済みます。認定投票とほかの投票システムの詳細は、Voting systemを参照してください。しかしながら、どの投票システムを使うかについて、長く議論するのは避けるようにしましょう（当然、投票システムを決めるのにどの投票システムを使うかを議論することになるからです）。認定投票が優れた選択となる理由は、反対意見を表明することが難しいからです――つまり、投票システムはできるだけ公平であるべきということです。

　最後に、投票は公開の場で行いましょう。どちらにせよ、公開の場で議論した問題について、秘密投票にしたり、匿名投票にしたりする必要はありません。オブザーバが投票を記録し、結果をチェックできるように、そしてすべてをアーカイブに記録するために、投票の参加者には、プロジェクトのメーリングリストに自分の投票をポストさせるようにしましょう。

いつ投票を行うべきか?

　投票で最も難しいのは、いつ投票を行うかです。一般的には、投票に実際に踏み切ることはめったにすべきではありません――つまり、ほかのあらゆる手段が失敗したときの最後の手段にすべきです。

　投票が議論を解決する素晴らしい手段だと看做さないでください。実際、そうではないのです。投票は議論を終結させ、それによって問題について創造的に考えることもやめさせてしまうのです。議論が続いている限り、皆が好む新しい解決策を誰かが思いつく可能性があります。これは驚くほどたびたび起こります。活発な議論は、問題について新しい考え方を生み出しますし、結局皆を満足させる提案にもつながります。たとえ新しい提案が生まれなくても、投票を行うよりは、妥協案を仲介してもらった方が通常はまだマシです。

　妥協した後は、皆がちょっと悲しい思いをします。一方で、投票をした後は喜ぶ人がいる一方で、悲しい思いをする人もいます。政治的な観点からは、前者の方が好ましいといえます。なぜなら、少なくとも一人一人が自分の悲しい思いに対して対価を支払っているからです。満足はしないかもしれませんが、それはほかの誰もが同じなのです。

　投票の主な利点は、皆が次に進める形で問題を最終的に解決してくれることです。しかし、投票は皆を理性的な対話によって同じ結論に導くのではなく、頭数で問題を解決してしまいます。わたしは、オープンソースプロジェクトで経験を積めば積むほど、人々が問題を投票によって解決したがらなくなるのが分かってきました。むしろ、以前考えたこともない解決策を探ったり、もともとの計画よりも厳しい妥協をしようとします。

　早まった投票を避けるためにさまざまなテクニックがあります。最も明白なやり方は、「まだ投票を実施する段階ではないと思うよ」といって、何故かを説明することです。別のやり方として、非公式に賛成の人は手を挙げてもらう（拘束力はありません）ことがあります。その反応が明らかに一方に偏っていたら、正式に投票を行うのを避けるために、積極的に妥協することを人々に促すことになるでしょう。最も効率的なやり方は、人々が同じ主張を繰り返さずに問題に再び取り組みるように、新しい解決策や、以前の提案に基づいた新しい視点を示すことです。

　まれなケースとして、示されたすべての妥協案は、妥協していないすべての案よりも劣っていることで全員が一致することがあります。この場合、投票を実施することに反対しにくくなります。なぜなら、投票の方がより優れた解決につながる可能性がありますし、どのような結果になっても全員が過度に悲しい思いをすることはないからです。たとえそうであっても、投票を急ぐべきではありません。投票に至るまでの議論は有権者にいろいろなことを教えるので、議論を早い段階でやめてしまうと、投票の結果出てくるものの質が悪くなるかもしれません。

　（投票をしたがるなというアドバイスは、章7.パッケージの作成、リリース、日々の開発のリリースを安定させるプロセス項で説明している、ソースコードに大幅な変更を加える投票には当てはまりません。そこでは、投票は対話のメカニズムとして働き、有権者を変更をレビューする手続きに参加させる手段となります。それによって、有権者は与えられた変更がどの程度のレビューを経ているのかを区別できるのです）