2020年9月、私は "Brain Hackers" というコミュニティを立ち上げた。この一見ヘンな名前のコミュニティは、電子辞書 SHARP Brain シリーズのハックが好きな面々が集まる場所としてオープンした。Discord サーバーに参加したい人はこちらを参照してほしい。
もともと「界隈」が存在していたところにわざわざ新しい場所を作ったのには理由がある。Brain のハック界隈が一時期*1より衰退しているだけでなく、2ch スタイルの掲示板が界隈の中心地となっていることに限界を感じていたからだ。当然これまで Web サイトを作ったりして界隈を形成してきた各位には感謝しきれないし、彼らの肩の上で今こうやって活動ができていることに違いはない。それにしても、さらに現代的な脱皮が必要だというのが私の率直な思いだった。そうした中、電子辞書ハックの記事が伸びたことで気持ちに勢いを得て Discord サーバーをオープンすることができた。
こうして晴れて Discord サーバーを立ち上げて「主宰」となった私は、コミュニティがなるたけ健全であるように願いを込めつつルールを制定することにした。
その中でひとつこだわりをもって盛り込んだのが、「Private channel は一切作らない」というルールだ。
「透明」な組織
2020年の4月まで仕事をしていた GROOVE X では、「情報の透明さ」を非常に重視していた。会社全体で Scrum をフレームワークとして採用していたのが源になっている*2。
Scrum の「透明さ」のもともとの定義は「現状の共有がチームメンバー間で行き届いていること」っぽいが*3、これの実現のために、「現状を説明する文章や意思決定のいきさつがすべて明文化されていること」や「隠す必要のある情報でない限り、全社のメンバーがすべての情報にアクセスできること」といったニュアンスも付随していた*4。この視点があることで、「自分はこの組織のことをよく知っている」という自覚が生まれ、チーム間の感情的な分裂や疑心暗鬼を少しでも食い止められていたように思う*5。
人間が組織を作ると、どういうわけか自然と「内輪」を作りたくなってくる。気心知れた少数のメンバーと、限られた範囲の意思決定で動いていたほうが心地よいからだろう。しかしそれは組織全体としては歪みや隔絶を生み出す。それを生じさせないためのキーワードとして「透明さ」はきれいに作用していた。ある物事が「透明でない」と感じられれば、「これの状況が外から見えないので説明してもらっていいですか」と求めることが公然とできるし、自分自身も明示的なコミュニケーションを取ることに違和感がなくなる。「透明さ」を実践することで、組織に自分が参加している + 自分の力が及んでいるという実感が生まれると、結構スッキリする。
この「透明さ」については、他の組織でも応用が効きそうだなーと当時から思っていた。
コミュニティへの応用
組織の分裂・隔絶・内輪化がオープンなコミュニティで起こると、もはや実質的に意味のある集まりはその内輪に限定されてしまい、コミュニティ全体として集まる意味がなくなってしまう。そこで、それを抑止するために採用したのがこの「透明さ」であり、冒頭で書いた「Private channel は一切作らない」というルールだ。
よくよく考えてみると、「真に隠さなければならない情報」は非常に少ない。認証情報、支払情報、住所、あるいはその他のプライバシーに関するもののみだ。企業などの組織であれば NDA などによって仕方なく Private channel を作ることもあるが、オープンなコミュニティにおいてはそういったものがない。
Discord サーバーを作ってまだ3ヶ月も経たないが、既に「Private channel で書けばいいんじゃないですか」という意見を何度かメンバーからもらったことがある。例えば、「コミュニティの意図しない知的財産権の侵害が起こらないようにするためにはどうするかという議論」とか、「Discord サーバーの管理者だけがいるチャンネル」といった具合だ。でも、それらはよくよく考えると隠す必要がないし、むしろ明示的に全員が見えたほうが良い。Private にしたところで、前述の内輪化が起こるだけなのだ。
最終的に、管理者である私が考えたことや、メンバーとの議論といったものは全部見えるようにして、むしろ参照しやすいように別なチャンネルに分けたりもした。そして実際、それ自体は現在のところ問題にはなっていない。
あとは、この透明さが体感を伴ってメンバーに伝われば嬉しいなと思っている。こればかりは今後辛抱強くコミュニティを運営していくほかないだろう。
「そんな仰々しいルールを定めたところで、興ざめするだけだろう」という意見もあると思う。しかし、どのような組織であれ、お友達感覚だけではいつか破綻してしまうだろう。こういうちょっと仰々しくありつつもパリッとしたルールが必要だというのが私の考え方だ。最後に、Python の作者 Guido van Rossum が自身の Python Essays でつづっていた文章を引用して締めくくることにしよう*6。
Any individual creation has its ideosyncracies*7, and occasionally its creator has to justify these.
訳: どんな作品であれ各々に特異な部分があり、作者は往々にしてそれらの正当化を迫られる。*8
*1:もう10年前(2010年)とかそういうスケール
*2:実際はさらに XP (eXtreme Programming) の考え方(短いリリース間隔・テスト重視・傾聴の文化 etc.)やティール組織のエッセンス(フラットな組織・サーバントリーダーシップ etc.)を取り入れたような考え方のもと運用されていた
*3:「現状を認識する」という Scrum の流儀からは外れていないはずだが、流派や解釈により少しずつ異なるかもしれないのであえて濁している
*4:多分独自の解釈とかも入っているはず
*5:「セレモニー」とまとめて呼ばれる行事の増加や情報の濁流の発生など副作用もいろいろにあるが、Scrum の紹介がしたいわけでもないのでここでは割愛する
*6:余談になるが、ルールの起草にあたっては pythonjp の Discord の運用も参考にさせていただいた
*7:idiosyncrasies のスペルミス・原文ママ
*8:この文章は、インデントによるブロック表現にはじまる「Python の一風変わったルール」について、GvR 自身が理由を説明する前段に置いた文章だ。「気持ち悪い」と一蹴されがちなインデント文化も、れっきとした由来と理由があってこそ採用されていることがわかる。