![見出し画像](https://assets.st-note.com/production/uploads/images/97819330/rectangle_large_type_2_a76e4c5baeeb969524563d626307a5d9.png?width=1200)
ひとりのちいさなこだわりがコミュニティの成長を妨げる…?管理したい欲望とどう折り合いをつけるか◆『遠くへ行きたければ、みんなで行け』(2)【ぷろおご伊予柑の大預言 番外編】
『遠くへ行きたければ、みんなで行け』読書会
![](https://assets.st-note.com/img/1676118159255-NIWeP4oAF6.png?width=1200)
2022年12月8日に行われた読書会は、『遠くへ行きたければ、みんなで行け』の訳者の方々を特別ゲストにお招きしました。
今回より、木曜の読書会スペシャルをお送りします。
◆『遠くへ行きたければ、みんなで行け』編
No.1 木曜の読書会スペシャルの背景とゲスト紹介
No.2 『People Powered』のコミュニティ観について
No.3 「遠く」ってなんだろう
No.4 コミュニティは手段?それとも目的?
No.5 心地のよいコミュニティってなんだろう
No.6 コミュニティの価値に気づくには?
No.7 コミュニティに入るときに気をつけたいこととは?
No.8 コミュニティのサイズとバリエーションの相関関係
![](https://assets.st-note.com/img/1676118297234-iaQCrz81nR.png)
『遠くへ行きたければ、みんなで行け』の前提になるコミュニティの捉え方
伊予柑:訳者の方の前で恐れ多いのですが、一応この本をさっくりまとめてきました
ぷろおご:挑戦的ですね
伊予柑:前提になってることとして、コミュニティって非常にいろんな意味があります。人々の集まりというのはめちゃくちゃあるので、地元のお祭りのような地域コミュニティや野球やサッカーのようなファンコミュニティ、企業が主催するユーザーコミュニティなどいろんなコミュニティがありますよね。
この本がとくに強いのがコミュニティ開発と呼ばれるもので、オープンソースと呼ばれるITエンジニアが協力してすごいものを作るよ!というのが事例の中心になっています。なので、まったく知らない人にはちょっと読みにくい部分はあると思います。普段、コミュニティって聞いて、地元のお祭りかなあと思っちゃう人にはちょっとなじみにくいかもしれません。
三ツ星スラムに集まってる人たちはコミュニティに関する悩みを抱えているのですが、そのうちでもメンバーが変えられないコミュニティでの悩みが多いです。学校とか会社、家族、そういったコミュニティはメンバーがそう簡単には変えられないですよね。
この本に書いてあるのは、メンバーが可変のコミュニティについてです。サッカーファンのコミュニティや開発者コミュニティ、Slackもそう。メンバーが変えられないコミュニティについてはあんまり扱っていないよというのが前提としてあります。
では、メンバーが変えられるコミュニティでどのようにするのがいいかというと、この本はビジネス的に超ゴリゴリにつくっていこうというスタンスで、「ベーコンメソッド」という方法が書いてあります。
![](https://assets.st-note.com/img/1676152783120-6b4ENhjBES.png)
上司が部下におすすめしたいコミュニティ設計本『遠くへ行きたければ、みんなで行け』
伊予柑:かなりマーケティングゴリゴリに設計方法が書かれています。そういう意味では、新しいことを書いてあるというよりもコミュニティというものをビジネスモデルとして捉えて、きっちり作りきるという、上司が部下におすすめしたい本みたいな感じの内容になっています。
コミュニティというのは、ものを作ったり大きな何かをやるときに素晴らしい成果をうむけど、とてもとてもとてもとても大変だよということがかなり強調されています。なぜなら、ものを作ったりするときに、コミュニティつくればいいじゃん。というのがマーケティングで流行ってるので非常に安易に言われるからです。
「ファンコミュニティをつくりましょう」「そこで有料課金をしましょう」と言われるわけですけど、そんな甘くねえよ、というのが実務的にかなり強調して書かれています。
ある漫画を出した時に「漫画好きが勝手に集まって任意創作してくれますよ」とか、ある商品を出した時に、「ファンの人が勝手になんかやってくれますよ」みたいな話によくなると思うんですが、そんなことはねえよ。自動的にはうまれねえよ、ちゃんと設計しろ!ということがかなりしっかり書いてあります。
そして、設計すればそれでいいかというと、そういうわけではなくて、人なんだよ、人!人間の心が大事なんだよっていうことがしっかり書いてあるわけです。そのためには中にいる人と一対一の人間的なやりとりをしようね、それができないと絶対無理だからな。というようなこともかなりしっかり書かれています。
なので、すごく真面目にコミュニティというものの価値に真剣に取り組めよ!という本だと僕は読みました。
ここまでであってますかと訳者の方に聞きたいです
![](https://assets.st-note.com/img/1676153215231-C1iLVGVw6q.png)
山形さん:著者ではないけれども、あってると思います。おっしゃる通りで、「コミュニティつくりましょうよ、ファンが勝手にやってくれますよ」みたいな話は、ある意味で甘い。一方で育てなきゃダメよ、それを作れるようにするための基盤がいるというのもその通りです。
個人的にはLinuxとかその手のやつ、みんなが勝手に集まってくれていつの間にか貢献してくれました。みたいな自然発生コミュニティが好きだから、こういうのは捏造じゃねえの?と思わなくもない。
でも、コミュニティは勝手にできるものではなく、条件が揃わないとできない。無数のフリーソフトとかオープンソフトとかその手のものが崩壊するのは、まさにそこらへんをちゃんとやっていないからで、それこそ成功したコミュニティには、偶然にせよこういう条件が揃ってますね。
フリーソフトなんかの場合には、貢献するとソフト自体がよくなる。それが報酬になるみたいなところがあるけど、自分でもコミュニティをつくりたいなら、人為的にでもやってかないと勝手にできるもんじゃないよね、できるという保証はできないよね。という、おっしゃる通りで、非常に正確に読んでいただいていると思います。
![](https://assets.st-note.com/img/1676118111934-bqKHXvjjTp.jpg?width=1200)
「ひとりのこだわり」はコミュニティづくりでは役に立たない?
高須さん:くわえて、この本でもう一個読んだ方がいいポイントは、本の中にいっぱい書いてあるこれはやっちゃだめだよっていうこと。あれは暗記するぐらい読んだほうがよいですね。みんなあれをやっちゃうんですよ。やる人のほうがやらない人よりも多いんです
伊予柑:そうですね
ぷろおご:コミュニティメンバーを部下だと思うな、とかあったよね
高須さん:ユーザーがすごく頑張ってYouTubeに、この商品が大好きだって動画を上げてくれたりした時に、売る側の人が「写真の使い方が違います」とか
ぷろおご:(笑)
高須さん:製品にもっと光をあててください、とかそういうことを言っちゃうクリエイターがすごく多いんですよ。もっと細かい、コミュニティにすらなっていない一対一の例でもそういうことがある。
たとえば、僕が本や原稿を書いてネットにあげたりするじゃないですか。そうすると、ここの英語ちょっと違ってますよ。とか教えてくれる人いますよね。そこで、ありがとうって言わないとだめなんです。
これまでもらったまちがい探しとかを全部ネットにあげて、誰でも書けるようにするねって言った方が絶対いいんだけど、やらない人の方が多いんですよ。山形さんはすごくちゃんとそういうことをやるんだけど、逆ギレをするとかブロックをするとか、いろんなモノを引っ張って、それは間違いじゃないんだと言うとかある
ぷろおご:こだわりがあるね
高須さん:どっちの方が明るい未来が待っているか、わかるじゃないですか。もちろん、そうやっていろんな人と仲良くしていると自分の時間がなくなるとか、そういうのはあるんだけど、それは対応できなくらい人からコミュニケーションしてもらってから考えればいい話で、
大体の人は、自分が売ってる製品をTwitterで見かけた時にせめて最低限は無視すべきで、「そうじゃないよ」って言い出すのは最悪じゃないですか。でも、やる人が多いんですよ。そういう使い方をしないで欲しかったとか、こういう本の読み方はしないでほしかったとか、それは一番言っちゃいけないし、書評だったら絶対RTしたほうがいい。そういう細かいところから全部やった方がよいですね。今、部下にしないという話が出たけど、3人か4人急に人が集まってくると急に態度が大きくなる人とかも、いるわけですよね
伊予柑:補足すると、日本の企業はお客さまを全員平等に扱いましょうという気風が強いです。この本には、こっそりえこひいきしよう!とある。バレないように上手くやろう!と
ぷろおご:女だったらゼミ入れます、みたいな?
伊予柑:それはだめです!製品を愛してくださるお客様は相応に大事にしましょうと書いてあって、そういう部分で日本の企業理念とは相反しやすい
えこひいきは悪いことじゃない。熱意をえこひいきすると、みんなが得をする
高須さん:たとえばこの本だと、お客さんをなるべく友達みたく扱った方がいいという話のなかに、むしろお客さんにマニュアルとかをなるべく書いてもらえ、とあります。売ってる方がマニュアルを書くと、これはやらないでください。あれはやらないで下さい、これをやると壊れる可能性があります、みたいなのを書きたくなるし、書かなきゃいけないんですよ。
あと、派手に宣伝するとき、どう考えてもこの製品が好きでたまらないお客さんがこの製品はこう使おうって書いてくれた方がありがたいんですよ。
で、そういうことをやってくれた人に売る方から言わなきゃいけないことは、まず、あなたが好きです。あなたがやったことを歓迎しています。写真とかなんだったらいいものをもっとあげるからバンバンやってくださいとか、製品作った人が外国から日本に来る時があったら、あなたを呼ぶから呼ぶから対談してくださいとか、なんなら飛行機代出しますとか、
![](https://assets.st-note.com/img/1676156464994-m2y9MIN7Lf.png)
高須さん:えこひいきになると言ったらえこひいきになるんだけど、そういうのをやった方がほかの買った人も、全員得するだろうみたいなのはある。
たとえばなんだけど、仕事で質問に答える人は午後5時なったら仕事を終えるし、やりたくてやってる人の方が、お金もらってやってる人に比べるといいサービスができることって世の中にはすごくいっぱいある。そうじゃないこともあるんだけど、特に開発関係だとそういうのが多いですね。
給料をもらってないけどいいパフォーマンスを出せるみたいな人が世の中にはすごくいっぱいいるので、そこの人たちをうまくデザインするにはどうすればいいんだろう、というところを読むことが大事だと思います。
実際、外国の会社よりも日本の会社の方がコンプライアンスがきついせいもあって、古くて大きい会社、みんなが「やーい!ジャパニーズトラディショナルカンパニー!」って馬鹿にするような会社の方があんまりえこひいきしてくれなかったりする。開発者がわざわざ来たというような時であっても、仕事関係の人間しかいなかったり……
絶対ユーザー代表みたいな人を呼んだほうがよくて、外国から来る人もユーザー代表に会えた方が絶対嬉しいはずなのに、
どちらを選べばいい…?制作を管理したい気持ち VS 品質を向上させたい気持ち
伊予柑:人の気持ちを考えようというのはかなり、この本で重要に扱われてますよね。「好きって言おう」もそうですけど、感情まじだいじ!っていう強調がありますね
ゆーさん:ちょっと質問いいですか。さきほどのやらない方がいいことで、例として、ネットにあげたものを指摘してくれたら「ありがとう」と言う、それはなかなか難しいという話に、たしかに僕もそうだなと思ったんですけど、
発明家コミュニティとかで、特許とか自分のものだという意識があるじゃないですか。自分のものだから、攻撃されるとあたかも自分が攻撃されたかのように思うから強くでてしまう。
コミュニティの中で開発が進むということは、これは誰のだよねというのがすごくぼんやりしてくると思うんですよね。つまり、誰もこれは俺のだと言わないようなものを作り上げていくわけで、そこで成功するのは、素朴に考えて奇跡に近いようなものですよね。
そのへんがどういうふうに起きるのか知りたいのと、個人的に「所有」に関心があります。僕が持っているとか持っていないとかそういうふうに言えるのかって話ですね。僕は「これは俺のだからとるな」みたいなことを言いたくないんですよ。
そういうことにつながる話かなと思ったんですけど、権利関係とか、コミュニティ開発の所有してる感の薄さみたいな部分の発生源、そのへんなんでうまくいったんだろうというところを聞かせてください
高須さん:「物として良いか、悪いか」ということより大事なことは基本ないですよね。
たとえば、Wikipediaはほかの同じようなもののなかで一番見られていて、金払って作られた百科事典よりも圧倒的に見られている。それはよいからですよね。簡単にアクセスできるとか、そういったところも含めて。
あれは、別に直しても自分が直したと目立っては表示されないけど、書きたくてたまらない人がいっぱいいますよね。だから炎上しているいくつかの記事は信用できないんだけど、そういった何枚かの記事を除いて、全体的にはすごく信用できるものになってますね。
ソフトウェアでもそういうものはいっぱいあって、最近とくにGoogleとかFacebook、お金をすごくいっぱい持ってるところがオープンソースのソフトを作り始めることが多いです。
それはなんでかというと、Googleでも、Googleにいるエンジニアを全部集めるより世界のエンジニア全員の方が人数が多いし強いからで、そうするとよいソフトができあがりますよね。結果的に自分の会社が儲かる仕組みができているのであれば、開発そのものは世界みんなでやった方がいいことが多いですよね。
![](https://assets.st-note.com/img/1676156042094-PIAkdQMEPR.png)
高須さん:WikipediaはたまたまWikipediaで大儲けしてる人がいないという状況になってるけど、LinuxはLinuxで大儲けとは言わないまでも、オープンソース開発でまあまあ儲かってる会社はほかにいっぱいある。Googleみたいな会社もGoogle独裁OSを作ろうみたいな方向にいくかっていうと、作ってもまあまず勝てないしみたいな考え方で。
だからAndroidもオープンソース化するし、Googleに閉じて開発しようとするとまあ負けますよね、みたいな話になって、自動運転のOSもそう、世界中のみんなをなるべく集めて、大きいものを作ろうとすると、オープンソースにしないとそうじゃないものによく負けるみたいなことがあります
ゆーさん:プログラミングされる方々にはそういうオープンソースを尊ぶという文化がすでにあるということですか?
高須さん:それもあるかもしれない。ただ、Wikipediaで考えるとわかりやすいと思うんだけど、誰でも書けるようにした方が信頼性があがるんですよね
コミュニティの核は輪郭が揺さぶられるときに明らかになる
山形さん:あと、とくにこの本の場合は作品というよりは製品およびサービスに関する話であって、作品になってくると「これはオレのという署名がちゃんと入ってます」という世界になる。
作品をこう使いました、ああ使いました、というのと製品をこういうふうに使いました、というのは同じではないので、この本での製品みたいなものと、それに対するアウトプットみたいなものは、比較的切り分けしやすい部分があるんだと思います。
そのなかでコミュニティ、あるいはその一部の人が絶対こうするのは許せない、ここはこうすべきだとか、ああすべきだと態度がデカくなってきた時に、やっぱりどこかで切らなきゃいけないよね。という話はこの本でもしていて、あらゆるものをハイハイ受け入れましょうという話ではない。
ただ、一応聞くだけは聞きましょう。そのうえで、それを言われた通りにするかというは、次のまた別の問題で、それは開発者なりサービス提供者としての判断が必要になる。そして、その判断において、「オレはこうした。お前の言うところは、ここの一線を超えてるので、ご意見はありがたいけど受け入れられない」というのは明確にして、最悪の場合に切り捨てるしかないよね、という話をしてますよね。
だから、コミュニティづくりでも、最終的にはコミュニティの中の人と外の人という、どこかに境界線はあるわけですよね。
その境界線を誰かがどこかで引かなきゃいけないということは、著者も決して反対ではない。そういう意味で、製品を持ってる人がこだわりを持っちゃいけないというわけではない。
その一方で完全に「これしかだめ」という切り分けもできない。そこのところ、最終的には柔軟にやれ、様子を見ろという、やりすぎても、やらなさすぎてもいけないというという話になるんだけれども。
境界がないわけではない、全部受け入れらなければいけないわけではないし、そこらへんはコミュニティとして何を守るのかを明確にしなきゃいけないというのはこの本でも言われてるし、おそらくは成功してるところはみんなそうなってると思います
![](https://assets.st-note.com/img/1676155888065-5KIPFW7vej.png)
報酬はお金だけじゃない。報酬にふさわしい貨幣はどこを流通しているのか?
高須さん:開発意外の話でも、コミュニティってあくまで他の人に仕事をしてもらう一個の方法だと思うんですよね。たくさんお金を払って雇うのも一個の方法で、どっちの方がいいかなと考える時に、金を払って雇う、そっちのやり方はみんな知ってるんですよね。
どうやってお金を払ってうまく優秀な人を雇えるかみたい本は本屋に行くといっぱいあるんだけど、そうじゃないやり方はまだあんまり多くないし、それは運なんじゃないの、とか"仕事といわない"んじゃないの?って言ってる人が多いんだけど、実際は金持ってる人も持ってない人も、できればいい人と一緒に仕事したいわけで。
そのなかで無料でボランティアにした方が、実はいい人が集まってるみたいなことも世界のいろんなところではあったりしますよね
![](https://assets.st-note.com/img/1676156703281-95hFV51jzp.png)
伊予柑:オープンソースコミュニティというのは基本、名前が全部出るので貢献がたどれるようになってるんですね。なので、作品づくりでも問題が起きにくい
高須さん:あともう一個、オープンソースのコミュニティで、なんでみんながコードを書くのか説明した方がいいと思っていて、あれは自分が直したいから書くんですよね
ぷろおご:(笑)
みんなのためではなく、ごく個人的な欲求からロジックを検証しつづける人たちがいる
高須さん:本でいうと、僕の授業で、誰かが書いた本を参考文献として使おうとするとして、内容は概ね合ってるんだけど、ここだけ直したいという時に直せた方がいいじゃないですか。僕が最近調べたらこうだったってことはみんなに言いたいじゃないですか。だからオープンソースのソフトの方ができがよくなるんですよ
ゆーさん:更新が早い
![](https://assets.st-note.com/img/1676156775080-MA7AqOqW4c.png)
高須さん:更新が早いのもあるし、すごい細いところだったら俺の方が正しいみたいなことって世の中にいっぱいあるじゃないですか
ぷろおご:その原理って健常者に効くんですか?
健常者というか、「オレが調べたことをちゃんと言いたい」みたいな気持ちって一般的にあんまりないとおもうんですよね。エンジニアリングをする人々に共通する性質ですよね
高須さん:ないと思う。世の中の多くの人が、あれはボランタリーでやってると思ってると思うんだけど、全然ボランタリーではやってなくて、単に自分にとって一番いいことをやりたいからやってるんですよ。で、やったものは告知した方が、他の人間がそれを見てくれるわけだし。
そこでは、オレの名前を言いたいみたいな欲求よりも、間違ってるから直したいみたいな欲求の方が強いんですよ。そうすると、誰も直してないバージョンと、いろんな人がすごく直したバージョンがあったら、いろんな人がすごく直したバージョンの方がより人の目に触れるから、より直されるじゃないですか。だから結果として、自分の持ってる会社でオープンソースやりたがるんですよ
ぷろおご:だから修正が集まるのね
高須さん:そう。逆にGoogleみたいな会社でも、開発する人間の規模がすごく小さいソフトっていっぱいあるんですよ。で、だいたいそういうソフトは給料もらって開発されてて、特許もたくさんとる
投げ銭の魔力、お金を払うことで「誰か」を所有できるか?
伊予柑:「貢献すると所有したくなる」のやつが今VTuberの世界でも発生してしまっていて、本でいうところのエンゲージモデルを作るっていう話なんですけど、VTuberファンの人は投げ銭ができるんですね。ここでいうと、コンシューマーから支援者の間の人たちなんですけど、その人たちがたくさん増えてしまった時に、私はこれくらい投げ銭をしたんだから、私の思う姿になれ〜という圧力がある。
このゲームをやりなさいとか、この圧力がかなり強烈なんです。なぜなら現生を扱っているからで、それによって潰されてしまうというVTuberがかなりいるという問題があります
![](https://assets.st-note.com/img/1676157669319-OCcmKpApdD.png)
ぷろおご:手をつけてきた愛すべきなにかの所有に関してはなんとなくうまいこと配分されてるんだけど、そこにお金が割り込んでくると、「オレのものかもしれない」ってなるんだ
伊予柑:これが商品とかサービスだったらお金の魔力はないんですけど、投げ銭というかたちで笑顔に対して支払うと、そこに所有欲がうまれてしまうんですよ
ぷろおご:お金に結びついた所有
山形さん:「何かをオレは買ったはずだ」っていう話ですよね
伊予柑:何かを買ったはずである。オレの思い通りになれ。これは「貢献すると所有したくなる」に入ると思うんですよ
ぷろおご:僕、めちゃくちゃお金もらうんですよ。誰かに対して「何万円くれ。」とは言わないんですけど、基本的に向こうがあげたいです。って言ってくるんです。でも、やっぱね、そんなに向こうから圧は感じないですね
ゆーさん:言ってこないでしょ
ぷろおご:言われない
ゆーさん:言っても無駄だと思われてる
伊予柑:それは何か発達にチャレンジドな部分があるんじゃない?
ぷろおご:わァ…僕が気づいてないだけってコト…?
次回へつづく
この記事が参加している募集
こちらのアカウントへのサポートは、スラム編集部への支援となります。よろしければ感想やご要望なども頂けると嬉しいです!