カネと開発者とプロジェクトの不思議な関係：オープンソースソフトウェアの育て方（2/3 ページ）

[Karl Fogel， ]

動機を隠し立てしない

　あなたの組織がプロジェクトで目指していることを、できる限り隠さないようにしましょう。ただし、ビジネス上の秘密は漏らしてはいけませんが。例えば、自分の顧客から強く要求されているという理由で、ある機能をプロジェクトに取り込んでもらいたいのであれば、メーリングリスト上で率直にそう言うようにしましょう。顧客から自分のことを秘密にしてほしいと頼まれることもありますが、その場合は匿名で事例を紹介させてもらえるかどうかを少なくとも聞くようにします。開発コミュニティーがあなたがやりたいことの動機を知れば知るほど、あなたが何を提案しても違和感が少なくなります。

　これは、知識は力であり、他人が自分の目標を知れば知るほど多く干渉される、という直感に反するものです――直感を受け入れるのは簡単ですが、取り除くのは難しいものです。しかし、ここではその直感は間違っています。新機能（バグ修正でもなんでも）を公の場で主張することで、あなたは既にカードをテーブルに置いているのです。その時点で唯一問題になるのは、目標を共有できるようにコミュニティーを誘導できるかどうかです。

　仮に望むことだけを主張して、その理由となる具体例を述べなければ、その主張は弱くなってしまいますし、隠れた意図があるのではないかと疑われてしまいます。しかし、現実世界のシナリオを2、3述べ、提案している新機能がなぜ重要なのかを示すだけで、議論する上で劇的な効果があります。

　別の視点から考えてみましょう。新機能やプロジェクトの新しい方向性に関する議論は長く、退屈なものです。人々の主張は「個人的にはXが欲しいんだよね」とか、もっとよくあるのは「ソフトウェア設計を長い間やってきたんだけど、Xはユーザーにとってもの凄く重要だ／誰も満足しない余計な飾りだよね」といったものになります。現実世界での使い方が示されていないと、議論の短縮や決着につながらないばかりか、実際のユーザー体験からは程遠い議論になってしまいます。そういった議論をとどめる力が働かない限り、結局は最も口が達者な人や、頑固な人、あるいは一番の古参によって結論が決まってしまうでしょう。

　大量の顧客データを持つ組織として、あなたにはそういった議論をとどめるチャンスがあります。ほかの人が開発コミュニティーに伝えることができない情報へのパイプ役になれるのです。あなたが望むことの根拠になる情報は恥ずかしいものでも何でもないのです。ほとんどの開発者は自分が書いたソフトウェアがどのように使われているのかについて、広い見聞を持っているわけではありません。開発者はめいめいが、自分独自のやり方でソフトウェアを使っているのです。そしてほかの使い方については、直感や当て推量、そして本能に頼って作っていることを知っているのです。非常に多くのユーザーの信頼できるデータを提供することで、あなたは開発コミュニティーに酸素に似た何かを与えることになります。そうした情報を適切に示す限り、彼らは熱狂的にそれを受け入れるでしょうし、物事はあなたの望む方向に進むでしょう。

　鍵となるのは、もちろん情報を適切に示すことです。あなたが大量のユーザーを抱えていたり、ユーザーがある機能を必要としている（またはそう思っている）からといって、自分の解決策を実装すべきだと主張してもうまくいかないでしょう。むしろ、ある特定の解決策についてではなく、問題となっていることがらをはじめに投稿するとよいでしょう。

　あなたの顧客が経験していることを詳細に記し、できるだけ多く分析しておきます。その上で、考えられうるだけの現実的な解決策を提示するのです。解決策がどれくらい有効かを人々が考え始めたら、あなたは彼らの発言を擁護したり、異議を唱えたりするのに自分のデータを示すことができます。あなたははじめからずっと特定の解決策が頭にあるかもしれませんが、はじめからその解決策を選んで特別な配慮をしてはいけません。これは相手をだましているのではありません。単に普通の「公正な仲裁者」として振る舞うことです。

　結局、あなたの本当の目標は特定の問題を解決することです。特定の解決策は、そのための手段でしかないのです。仮にあなたが好む解決策が優れていれば、ほかの開発者たちもそれを結局は認めてくれ、彼らの自由意思で応援してくれるようになるでしょう。彼らを威嚇して自分の解決策を実装させるより、この方があなたにとってよいでしょう。（彼らが自分より優れた解決策を考えているかもしれません。）

　これは、特定の解決策を好んでいることを言ってはいけないということではありません。しかし、あなたが既に内部で終えている分析が、開発用の公開メーリングリストで繰り返されるまで我慢しなければなりません。「すべての解決策をみてきたけれども、それはA、B、Cという理由でうまくいかない。突き詰めて考えていくと、結局唯一の解決策は……」などと発言してはいけません。

　問題なのは、こうした発言が尊大に聞こえるということよりも、むしろあなたがその問題を分析するためにある未知数の（たぶん大きいと人々は思うでしょう）リソースを既に裏で投入しているという印象を与えてしまうことです。これは既に物事が進行していて、たぶん決定もなされていて、公にはそれについて何も知らされていないように見えてしまいます。これは人々の怒りを買う原因になります。

　当然、あなたはその問題について裏でどのくらい努力してきたかを知っています。その知識はある意味不利なものです。あなたが雇っている開発者は、メーリングリスト上にいるほかの開発者とは違った精神状態に置かれてしまい、その問題について考えたことがない開発者の視点から物事を見る能力が欠如します。より早い段階でほかの人にあなたと同じ言葉で考えさせれば、こうした溝は小さくなります。

　この論理は、個々の技術的な状況だけでなく、自分の目標をできるだけ隠さないという広義の要請にも適用できます。知らないことは知っていることよりも不安定なものです。あなたがやりたいことの動機を人々が知れば、彼らはたとえそれに反対であってもあなたと気軽に話してくれるでしょう。あなたの動機が分からなければ、彼らは物事を悪い方向に考えてしまうこともあります。

　もちろんすべてを公にはできないでしょうし、人々もそんなことを期待していません。すべての組織には秘密があります。おそらく営利組織には多くの秘密があるでしょうし、非営利な組織でもあるでしょう。ある方向性を擁護する義務があるが、その理由をまったく公にできない場合は、そうした制約の中でできる最も優れた主張をするようにしましょう。そして、議論の中で自分が望むほど影響力を行使できない可能性がある、という事実を受け入れましょう。これは、開発コミュニティー全体に給料を払わないために行う妥協の1つです。