Dave Neary氏

さまざまなオープンソースコミュニティがあるが、コミュニティが活発で円滑にプロジェクトが順調に進むところもあれば、そうではないコミュニティもある。成功するコミュニティになにか秘密はあるのだろうか? オープンソースコンサルタントのDave Neary氏が経験を基に、コミュニティ運営のポイントを伝授してくれた。

Neary氏は、自身の会社Neary Consultingでフリーソフトウェアコミュニティ開発にコンサルティングを行っている。これまでGNOME Foundationの取締役会などを務め(「Gnome Census」の作成も行った)、オープンソースプロジェクトを熟知している人物。Neary氏は昨年11月にアイルランド・ダブリンで開催された「MeeGo Conference 2010」で、集まったオープンソース開発者やコミュニティを前に、"コミュニティのアンチパターン"として、悪い例を挙げながら対処法を紹介した。

例1 タスクをいつまでも抱えているメンバーがいる

期限内に処理できそうにないのに、タスクを抱えてしまっていることはないだろうか? あるいはそういう人がいないだろうか? Neary氏はこれを、最後に残ったクッキーにつばをつけておく"クッキーリッカー(Cookie Licker)" - すぐには食べないが、キープはしておきたい人と形容する。「コミュニティから他の人に回そうといわれても、自分がやると言い張る。次第に、コミュニティにとって、道路を遮断する"障害物"になる」とNeary氏。

対処法

コミット後に「やっぱりできなかった」といえる環境づくり。途中でできなくてもOKで、できないと言ってもいいということを周知徹底させる。クッキーリッカーの心理として、「自分では"間に合う、できる"と思っている。コミット後に他の人にタスクを渡すことは失敗を認めることになると思うから」とNeary氏は説明する。なお、「優秀な人に多い」とも警告。「"できなかったと伝えてくれてありがとう"というような環境が理想」とNeary氏。

例2 質問魔の新メンバー

コミュニティに新しくメンバーが加わった。わからないことだらけだろうが、それにしても質問が多すぎる……。助けなきゃいけない、親切にしなければ、でも自分もそれほどヒマではない…… 気が付いたらすごい顔をしながら答えていた自分がいた -- そんな経験はないだろうか? このようなメンバーがいると、コミュニティのリソースが大きく食われてしまう。

対処法

わかりやすい新規参加者向けのドキュメントを用意する。新しいメンバーにどうやって質問の答えを調べればよいかを伝える。比較的最近加わったメンバーなら、同じような疑問を経てきた可能性があるので、「最近入った人に答えるよう奨励するのもよいかもしれない」と。ただし、「全部のドキュメントを自分で読むよう強要するのはダメ」とも。

例3 方向性について意見が対立

明確なリーダーシップがあれば別だが、コミュニティでは対立することも常。なかなか議論が進まず、そうなるとプロジェクトも先に進まない。

対処法

対立するアイデアやビジョンが出てきた場合、一定期間を設けた後に2つの案を比較して決めてみてはどうだろう。「だいたいの場合、単に反対したいだけの人は反対するだけで代案らしい代案を出さないことが多い。結局はデファクトに決まることが多いだろう。もし反対案になったとしても、比較した後のことなのでWin-Winだ」

例4 談話室で決定(企業に多い)

メーリングリスト(ML)でいちいち上げるのが面倒くさい。自分たちだけで決めてしまって、その後で結果をコミュニティに公開する。

対処法

"ガラス張りの部屋"で作業してよいようにする。MLを面倒がる心理として、「コミュニティに上げると、決定のスピードなどの効率が落ちるという恐怖感がある。あらゆることをオープンにしてディスカッションしながら決めることに恐怖を感じている」と説明する。Neary氏は、「オープンな作業とは、必ず他の人の見解を入れるということではない」とした上で、「非公式な作業はだめだが、一時的に全員が議論に参加できないというのもありでは」と提案。「コミュニティは意思決定が行われた理由を知りたい。アーカイブの公開などでフォローできるようにすることが大切。モデレータを使うのもよいだろう」とのことだ。

例5 関係ない行動が増える

MLにトピックと関係ないようなスレッドが立ったり、Wikiの記事の質が下がってきた。

対処法

ベストプラクティスをドキュメント化する。関係ない行動を取る人を、早期に、やさしく警告する。「当の本人は良かれと思ってやっていて、自分が及ぼしている影響に気が付いていないことも多い」とNeary氏。コミュニティのポリシーを再度伝えるというのも手だという。

Neary氏は悪い例からベストプラクティスを紹介する理由として、「うまくいかないプロジェクトの多くが、ベストプラクティスや良いアイデアを間違った方法で適用してしまったために、望んでいたものとは異なる結果が出ているのではないか」と述べる。「なぜ成功しているのかをちゃんと理解して、単なる模倣ではなく中核となるアイデアを取り込んでほしい」と述べた。

コミュニティとは人がやりとりする場所だ。人がやり取りするのだから、当然ながら感情はつきもの。オープンソースコミュニティもその例外ではなく、苦痛な場にも楽しい場にもなりうる。Neary氏は最後に、「楽しく、フレンドリーで、安心して、進んで共有できる環境を作ることを目標にしてほしい。そして、フリーソフトウェアならではの素晴らしい成果を得てほしい」と期待を込めた。