アート・オブ・コミュニティ

『アート・オブ・コミュニティ』は長年Ubuntuコミュニティでマネージャー的なことをしてきた著者が、その経験に基いてコミュニティ運営について語る、なかなか他に類を見ないテーマを扱った書籍。OSSコミュニティのマネジメントについて書かれているが、会社組織に通じる話題も多い。

アート・オブ・コミュニティ ―「貢献したい気持ち」を繋げて成果を導くには (THEORY/IN/PRACTICE)

僕はQiitaというサービスを作っていて、ユーザの中にはOSS活動している人も大勢いるので（自分もその中の一人ではあるが）ユーザ理解の一環として読み始めたのだが、直ぐにチームマネジメント的な文脈で読む方が適切だなと姿勢を改めた。

というのも、OSSコミュニティは参加者たちの自発的な行動によって支えられている面が非常に大きい訳だけど、その姿はIncrementsが志向する「自律的な組織」と目指す方向性が近いと思ったからだ。

「Ubuntu流の自律的な組織」を運営するためにさまざまな点が語られているが、以下個人的に印象に残った点を書き記す。

とにかくオープンにする

本書を読んでいて特に印象的だったのは、OSSコミュニティというそもそもがオープンなソースコードを土台にした組織を運営するために、可能な限りあらゆることをオープンにしようと徹底している姿勢だった。

それは組織のミッション・ステートメントの策定に始まり、どういう領域で人材を必要としているか、プロジェクトに参加するための方法を書いた手順書、今期の戦略計画の目的とそれを構成する目標などなど。

どの章を読んでいても「これは誰でも読めるように公開しましょう」と書いてあるし、そのドキュメントをどういったツールで公開するのがいいか書かれている。

Qiita:Teamのドッグフーディングも兼ねて、普段から積極的に情報公開するように努めているつもりではあるが、もっともっとやれることはあるなと再認識した。

マネージャーの役割

マネージャーの役割として「チームがどのようにコミュニケーションをしているのか常に確認すること」を上げていたのも興味深かった。例えばデザインチームとWeb開発チームの間で十分に意思疎通ができているかを調べる、みたいなことなんだけど、ちょうど最近公開された伊藤直也さんとフリークアウトの明石信之さんの対談で同じようなことをいっていた。

naoya: 基本的には営業とエンジニアリングって、放っておくと逆を向いちゃう性質のある職業だから、現場の人たちだけで同じ方向を向くっていうのは、確率として相当低いんですよ。それを向いていくように組織の構造を調整するってなると、それはもうマネジメントの仕事だと僕は思ってて

【後編】大先輩のフリークアウトCTOが語ってくれた、マネジメントの深くてイイ話

変化しないプロセスが官僚制度をもたらす

参考にしたいなと思ったのは、プロセスの見直し方法について（ここでいうプロセスというのは「プロジェクトに興味をもった人が参加するためのプロセス」のように特定のゴールを達成するための一連の手順を定めたもののこと、と大雑把に理解してもらいたい）。

Ubuntuコミュニティにはさまざまなドキュメント化されたプロセスがあるが、それらは定期的に振り返って変更している。その振り返りを行う前の事前準備として以下のことをしているそうだ。

1. まず最初に、コミュニティ内にある全てのプロセスのリストを作ります。これはどのように新しい人が参加するか、どのように一緒に働くか、どのようにチームが働くかなどのトピックをすべてカバーするようにします。Wikiのようなオンライン上で行う方が良いでしょう。
2. それぞれのプロセスに対して、今まで聞いてきた良い点、悪い点のフィードバックを箇条書きにしていきます。
3. 次にできあがったリストを全て眺め、あなたが優先だと思う順序に並び替えます。多くの場合、コミュニティのボトルネックや問題を引き起こしているものを優先します。
4. 最後に、コミュニティ全体にこのリストを告知して、フィードバックのお願いをします。また、もっと議論が必要なプロセスについてもフィードバックを求めます。再評価のセッションの前に締め切りを設定します。このフィードバックをドキュメントにマージして、コンセンサスに基いて、優先順位を振り直します。

4.5.1 習慣化する より

こうして出来上がったリストをミーティングのアジェンダにして、Ubuntuコミュニティではプロセスの見直しを行っているらしい。

Incrementsでも定期的にKPTを軸にした振り返りの機会を設けているが、自由記述で問題点を出してくださいと言われても、質問が大きすぎてなかなか意見が出ない印象があった。振り返りの叩き台として既存のプロセスを一旦整理してそれぞれの良し悪しを上げてもらう、というアプローチはよさそうだと思った。

プロセスの導入は小数の主要メンバーから

Ubuntuコミュニティには大勢の人が参加している。何か新しいプロセスを導入しようと思ってもなかなか浸透していかない。

コミュニティの主要なメンバーの中から4〜5人選び、アナウンスを行ったプロセスがきちんと使えることを確認する方法が便利です。彼らがそのプロセスを使用することを定期的にチェックして、もし使用していなければその理由を聞くと同時に、そのプロセスが何故必要かを思い出してもらいます。

プロセスが無視された時は、それはプロセスの目的を再び告知する機会であると認識しましょう。2つの方法があります。1つめはプロセスを利用したおかげで、素晴らしい結果を得ることができたというサクセスストーリーを示す方法です。（略）もう一つは、プロセスの目的を思い出させる機会として、プロセスに従わないとさまざまな支障をきたす例を示す方法です。

4.4.3 プロセスを使用する より

Qiita:Teamを会社に導入しようと頑張ったが根付かなかったので止めます、みたいなことがたくさん起こっているような気がしていて、その問題に対するアプローチとして参考になる。

あと会社で何か新しいことを始める場合も。

---

このブログでは主に書籍の前半部分のことを取り上げた。後半はOSSをどうやって盛り上げていくか、的な話題になっていくので、地域コミュニティをどうやったら活性化できるのか、みたいなことに興味がある人なんかはそっちを読むといいかも知れない。

扱っている話題は非常に多岐にわたっているので、何かしら面白いと思う章があるだろうと思う。