0034 号 巻頭言

初稿：2011-06-12

『アート・オブ・コミュニティ』を読む

Rubyist Magazine 第 34 号をお届けする。

今号は、 Ruby 関西の重鎮 (と書くとご本人は謙遜されそうですが) の小波先生が登場する Rubyist Hotlinks 【第 27 回】 小波秀雄 さん、 郡司さんが Ruby 1.9 で導入された Fiber の基本的な考え方を解説する Fiber と Proc ―― 手続きを抽象化する二つの機能、 antimon2 さんが Enumerable に遅延評価を導入する enumerable_lz を紹介する enumerable_lz による遅延評価のススメ、 Rubyist に他言語を紹介するべく今号から始まったシリーズ『他言語からの訪問』の記事として、上原潤二さんが Groovy のオプショナルタイピングとAST変換を紹介する 他言語からの訪問 【第 1 回】 Groovy (前編)、 最近行われた内外の Ruby 関連イベントの参加レポート記事として RegionalRubyKaigi レポート (21) 松江 Ruby 会議 02、 RegionalRubyKaigi レポート (22) 関西 Ruby 会議 03、 RegionalRubyKaigi レポート (23) 大江戸 Ruby 会議 01、 そして Ruby 関連イベント となっている。

　巻頭言に書くテーマが思いつかず悩んでいたところ、渋川よしきさんより『アート・オブ・コミュニティ』を献本いただいた(ありがとうございます！)。今回はこの本について書きたい。

　Jono Bacon『アート・オブ・コミュニティ』は、Ubuntu のコミュニティ・マネージャである Jono が、 自身の体験を元に、コミュニティの作り方、運営の仕方について書いたものである。 オープンソースソフトウェアのコミュニティについての書籍と言えば、同じくオライリーから 出た Karl Fogel『オープンソースソフトウェアの育て方』があるが、そちらは FLOSS 開発に 特化した内容が多いのに対し、『アート・オブ・コミュニティ』はもう少し広いターゲット向け、 一般的なボランタリーなコミュニティに関する内容になっている。

　まずは一番良かった章について書く。第 9 章『対立への対処』は、 ありがちでありながら、なかなか難しい、メンバー同士が対立した場合どうすれば よいかについて分かりやすく書いている。とりわけ 9.3「対立解決のプロセス」では、 一般的な話から始まり、さらには架空の対立の例について、ページを大きく割いて、 それをどのようなプロセスで対処すればいいかを順を追って説明するという、 なかなか読み応えのある内容になっている。 ここでは比較的スムーズに解決に進んでいるが、そうはいかない場合でも、 十分参考になるだろう。 また、9.4「燃え尽き症候群」についてもしっかり読んでおきたい。 実際に燃え尽きるまでいかなくても、それに近い状態になってしまうことは、 残念ながらそれなりにある。自身の甘さについての苦い記憶がよみがえって読んでて辛いこともあるのだが、 「貢献したい」という祈りから始まり呪いで終わるサイクルを繰り返さないためにも広く共有したい。

　それ以外の章については、 確かに書いてあることは確かなことで、読むべき内容ではあるのだが、第 6 章、第 7 章あたり まで読んでいると何やら疲れてきてしまうようではあった。 少なくとも、コミュニティの運営経験が少ないうちは、知識として把握しておいた上で、 あまり頭から参考にして実践しない方がよいかもしれない、と思わなくもない。

　コミュニティとは一般的に、参加者の成長の場であり、またコミュニティそのものが 成長するものである。Dave と Andy は『達人プログラマー』の中で 「ソフトウェアは建築と言うよりもガーデニングに近いのです」(p.188) と書き、 その「成長する」「育てる」メタファーについて触れているが、 ソフトウェアのコミュニティも同様である。 いくら準備に力を入れたとしても、一足飛びに理想型になるものではない。 少なくとも本書で記載されている形を上手く実現するには、 コミュニティ・カウンシル等運営側のメンバーと、運営にはあまり興味のない一般的な参加者を 含む全体として、それなりに経験を積んでいる必要があるのではないか。

　具体的には第 6 章『Buzz の波を起こす』では、積極的に Buzz の起こし方について詳しく書いているが、 ここまで作為的に行動するのはあまり得策ではない(こともある)。 往々にして Buzz は自分の身の丈以上に成長して、制御しきれなくなりがちである。 ある程度経験を積んでいれば、スルー力を駆使して大事には至らないようすることもあるが、 失敗してしまうと後々まで禍根が残りかねない。 一般的に言って Buzz は本来そのコミュニティが求める成果の道具であって成果そのものとは異なるものだが、 そのようなものに足を引っ張られるのはコミュニティとして残念でしかない。

　もう一点感想を付け加えておくと、ボランタリーな組織についての重要な点として、 いい意味での「隙」がなければいけないのではないか、と思っている。 ここで言う「隙」とは、大なり小なり問題があるのだけれど、 余裕がないとか、手が足りてない等の理由により解決されていないところ、である。 これには二つの効用がある。

  • 準備に時間をかけずに動き出すことが出来る
  • 新しい人が入り込む余地になる

　先ほどのガーデニングのたとえからいっても、動き出すこと自体は早く小さくはじめるに越したことはない。 そうすると、もちろん足りてないところがあるのだが、 それは大きな問題ではない。むしろ、そのような「誰にでもできそうだけど実は 誰もやっていない」ところは、そのコミュニティの新参者が積極的に関わりやすい ところである。そのような余地を残しつつ、あまり肥大化させないようにしくみを 充実させておいた方が、コミュニティとして硬直化しづらくなるような気がする。 本書にはたくさんの ToDo リストが載せられているが、それをあらかじめつぶしておく必要はなく、 むしろ分かりやすい ToDo が後から参加する人のための余地として残っているくらいでいいように思う。 とはいえ、それを極端に押し進めてしまうと不安定になるので、 やはり最後はバランス重要、という話ではある。

　もっとも、このようなアドバイスもまた、 育てていくもの・育つものとしてのコミュニティにとってみては外野からの一般論でしかなく、実際には気休め程度のにしかならない。 それぞれのコミュニティのメンバーが、よいコミュニティを作りたいという意識を持ちあうなかで合意形成しつつ、 前述の『対立への対処』のような障害対処には心を配りつつ、 成果をあげていくことを目指していくしかないのだろう。そのための中長期的な指針として、本書は役に立つと思う。