Communities of Practice

実践コミュニティとはなにか？

コミュニティ・オブ・プラクティスというのは、日本語で言うと『実践コミュニティ』です。同名の本が以下でございます。このセッションの内容はほとんどこの本を参考にしたものですわ。

コミュニティ・オブ・プラクティス

posted at 2015.3.3

Etienne Wenger,Richard McDermott
翔泳社
売り上げランキング: 35319

Amazon.co.jp で詳細を見る

実践コミュニティの定義は以下。

あるテーマに関する関心や問題、熱意などを共有しその分野の知識や技能を、持続的な相互交流を通じて深めていく人々の集団

堅苦しい感じがしますな。でもそんな難しく考えなくてもいいです。コミュニティとはいろんなところにあります。例えば、あなたの会社でお昼休みに一緒にご飯を食べている仲間も、そこで話されている会話が会社のことで「ここをこうしたらいいんじゃないか」とか話してたらそれはもう立派なコミュニティです。はたまた、業務時間後に会社に残って話し合うミーティングといったものもコミュニティ言えるでしょう。

実践コミュニティというのは通常のビジネスユニット、プロジェクトとは違ってラインが曖昧です。例えばビジネスプロジェクトであれば、デザイナーは誰々、エンジニアは誰々、ディレクターは誰々と明確にされているでしょう。

しかし、コミュニティというのは参加の度合いというものがあります。全てのコミュニティの構成員が同じ参加度合いとは限りません。コミュニティの発起人やその手伝いをしている人のような方であればコア・グループと考えれますし、コア・グループよりも密に関わっては来ませんが、それなりに参加している人はアクティブ・グループと言えるでしょう。またコア・グループの人たちを遠巻きから単に見てるだけといった周辺グループといった層もいます。

参加の度合いが高ければ全て良いのかと言えばそうでもなく、周辺グループでも参加してこないだけで注意深く耳を傾け各自のレベルで何かを得ているといったことも考えれますし、何かのきっかけにアクティブ・グループと移行することもありますので、常に広く門戸を開けておくべきでしょう。

実践コミュニティというのは主に3つの要素から成り立っています。

• Domain : コミュニティが取り組む分野
• Community : 相互交流している人たちの集団
• Practice : 知識を生み出す活動

まずはじめに、コミュニティが扱うテーマ・分野です。kanazawa.jsならば、もちろんJavaScriptです。そしてこの場にいるコミュニティのメンバー、人です。最後に、実践である知識を生み出す活動。今回のセミナーから何かを得てそれをブログなどにアウトプットしたり、会社でその知識を活かすなどといったことが考えられます。

3つの要素それぞれが適切でなければコミュニティの運営はすぐに立ちゆかなくなってしまうでしょう。また、コミュニティがあることでそのメンバーにとって利益があります。

コミュニティメンバーにとっての利益

仕事のあり方を改善する（短期的）

• 難問解決のための支援
• 専門知識へのアクセス
• チームのより良い貢献
• 問題のアプローチへの自身
• 同僚といる楽しみ
• 参加の意義が高まる
• 帰属意識

専門的能力の開発を促す（長期的）

• 技能や専門知識を拡張するための場
• 専門分野で遅れを取らないようにするためのネットワーク
• 専門家としての名声を高める
• 自らの商品価値と雇用可能性を高める
• 専門家としての強いアイデンティティ

ブラブラーとこれだけのものがありますし、企業などの組織がコミュニティを運営するのであればその組織にも多くの利益をもたらすでしょう。

組織にもたらす利益

事業成果を改善する（短期的）

• 問題解決のための場
• 質問への即答
• 時間と費用の節約
• 決断の質向上
• 問題に対する多様な考え方
• すべてのユニットにまたがる連携、標準化、相乗効果
• 戦略実行のための諸資源
• 品質保証の強化
• コミュニティの後ろ盾のもとでリスクを負う能力

組織能力を開発する（長期的）

• 戦略計画実行能力
• クライアントへの影響力
• 人材確保の改善
• 知識開発プロジェクトの遂行能力
• 業界他社とのベンチマーキングを行う場
• 知識に基づく提携
• 意図しない能力の出現
• 新しい戦力上の選択を生み出す能力
• 技術開発を予見する能力
• 新たな市場機会に乗じる能力

まぁ、こんな感じに。上記のようなことをメリットに勉強会などを開いてみるのも良いでしょう。

コミュニティとの出会い

まぁ、小難しいことを言ってきたのですが実際にコミュニティとはどうゆうのものかと理解しているのか、自分のケースだとこんな感じだよってことを次に紹介します。

私がWebデザイナーとなって5年目ですが、当初はHTMLもろくに知らない奴でしたので、いろいろ本読んだりググったりがんばってきたのですが、それだけでは物足りずセミナーというのものに行ってみようと思ったのでした。

で、最初に行ったのがCSS NiteのWeb標準の日々というものでした。参加費が1万で東京での開催だったので、当時バイトだった僕は会社を休んで夜行バスで行ったものでした。でも、やはり１万払ってでも学んでやる！っていう輩がそこかしこにいましたから、めちゃくちゃモチベーションがあがりました。「俺負けたくねぇ！！」って。

ただ単に知識量を得たいのならやっぱり一人で家で本読んでたほうが圧倒的に効率も量も多いです。セミナーや勉強会に求めるのはやっぱりモチベーションとかやる気とか勉強するためのガソリンを補充するものだと考えるようになりました。

次に、行ったのがDevelopers SummitとLightweight Language Futureというエンジニアのイベントでした。HTML+CSSもろくにできない駆け出しのデザイナーが何を血迷ったか分からないのですが、とりあえず行ってみました。

いやーおもしろかった。

今こそライトニングトークっていったらデザイナーでも聞いたことがあると思うのですが、当時はそんな風習なかったよデザイナーさんたちには（僕が知らないだけかもしんないけど）。とりあえずLTというのを初めて見て、思ったのが普通におもしろいかったってゆう。別に前に出て喋るからといってそんな堅苦しい内容じゃなきゃいけないって理由もないし、喋っている人がそこまで聖人君子である必要もないんだなって理解しました。またそこで話されている内容もエンジニアさんたちが日々の仕事で困ったこととかハマったこととかを共有しあうっていうスタンスがすごく良かった。やっぱりそうゆうのはオープンソースソフトウェア的な考え方かもしれない。とにかくいろいろ衝撃的で、しかもあたたかく心地良いコミュニティだと感じました。

まぁそんなこんなでいろいろなセミナーや勉強会にお邪魔するようになって自然と自分でもコミュニティを持ちたいと思うようになりましたのが次のお話。

コミュニティの立ち上げ

JavaScript 第6版

posted at 2015.3.4

David Flanagan,村上 列
オライリージャパン
売り上げランキング: 10796

Amazon.co.jp で詳細を見る

最初に始めたのが社内の4人ではじめたJavaScript勉強会でした。これは週1時間だけど（されど1時間）業務時間内からJavaScriptの勉強に充てることが認められて始めました。サイ本（JavaScript第5版）をプログラミングもろくに知らないデザイナー4名で読み進めていくという、今考えればかなり無謀なことをしたなと思うけど、当時はとりあえず前に進むしかなかった。やっぱり会社から投資されているのでそれなりの結果を残さなければならないというプレッシャーがありましたから、がんばりました。それに一人なら絶対数章読んでフェードアウトしていたであろうことも、4人ならなんとか理解はしてないけどとりあえず読み終えることもできたし、いろいろ力は付いたかと思う。そのおかげでこの勉強会は2期、3期とデザイナーのためのJavaSript入門講座的な位置づけで現在も続いています。

社内 Tech Talks

続きまして、やったのが社外、社内問わず講師を立てて月1回ペースで開催した社内Tech Talksです。JS勉強会は人数を絞った勉強会なので、それとは別にデザイン部全体を巻き込んだ勉強会をしたくて企画したものです。月1回で12回開催したので1年間続けました。回を重ねる毎にデザイン部内から発表する人も多く出てきて、人前に出て喋るといったことが特別じゃないってことを分かってもらえたかなと感じていますし。またセミナーや勉強会にに参加したことがない人にも社外から講師を招いて半分社外セミナー的な雰囲気を味わいつつもセミナー慣れに一役かったのではないかと個人的に思っています。

kanazawa.js

んな感じで、いろいろ社内ではやって来たのですが、これを社外にも広めるとなるといろいろめんどくさいなーと思いつつもこれまでの経験上やっぱりコミュニティのメリットは理解しているのでやるぞと宣言してしまいました。

とりあえず、細ーく長ーく続けていきたいと思っているのであんまり気張らずにやっていこうと思っています。

そんなこんなで、個人的にはなかなかうまくやってきたと思っているつもりなのですが。参加してくれた皆様、喋ってくれた皆様の協力があった賜物なのは重々承知のうえですが、運営の上でなぜうまくやれたかというのを振り返ってみると、２つのポイントがあると考えています。

メンバーの中で、コミュニティが領域に焦点を当て、さまざまな関係を維持し、実践を開発することができるように手助けをする人

まずは、コーディネータ ーという存在を理解したこと。社内Tech Talksを始めた頃は自分ばかり喋っていて、それでは限界があるとすぐ理解できました。自分が得意とする分野も限られていますしなにより毎回話すネタを作るのが負担です。そこで話してもらう人を探すわけですがそうも簡単には見つからないです。みんなが聞きたい内容とその人が話せる（したい）内容というのはかならずしもマッチングはしません。そこで日頃からコーディネーターとして自覚していれば、その人のキーワードを（Flashならこの人喋ってくれそうとか）を探して、きたるべき時にお願いするといったことができます。みんな最初は謙遜して断るけど案外喋りたいものです。粘り強くいきましょう。でも無理強いさせてはいけません。

つぎのポイントはドキュメントを作ること。勉強会を開くのにお金は特に必要はないですけども、それでも会社の設備を使ったり、外部の人を招けばセキュリティうんぬんがいろいろと問題になってきます。ということで、会社の偉い人の承認が必要になってきます。ここで問題なのは会社の偉い人と私みたいな一兵卒では住む世界が違うわけですよ。というかあんまり出会わない。そこでデザイン部のリーダーをなどを通してお願いをするわけですが、ここでコミュニケーションロスが生まれる可能性がでてきます。あなたがどんだけ熱意を持ってても紹介してくれる人次第では10分の1も伝わらないかもしれない。紹介する人も別に悪意があってしてないだろうけどやはり自分のことではないので熱意というのは半減すると思う。そこでドキュメント。ドキュメントであれば、それを渡してくれさえすれば済む話です。仲介者のコストも少なくて済みます。

そのドキュメントを書くことでなにかコミュニティの直接的な利益になるかといえば、あまりならないだろうとは思うけども、世の中好きなことばかりやれないものです。時として信用を得る手段としてパフォーマンスとして必要なことも理解しましょう。そうすることでサポーター（支援者）やチャンピオン（擁護者）といった協力者がでてきます。

次の一歩

んなこんなで、これからのためのお願いというか理解してほしいこと。

やっぱり、いやらしい話、お・か・ね♥はかかります。善意で喋ってくれる人も多いけど、東京の有名な人を呼んだりするにはそれだけで交通費とか宿泊費かかります。そこに講演費とか施設費用とか入れるとやっぱり3,4千位の参加費徴収することにもなるかと思います。でも、やっぱり多くの人参加してもらいたいから安くしたりもします。その場合、誰かがなんかしら負担しているということなのでそうゆうの理解しておいてほしいかなと思います。

別に高いからダメとか安いからダメとゆうあれはなくて、いろんなコミュニティの考え方があっていろんな選択肢があったほうが良いと個人的に考えています。

そいで、コミットメント（献身）をしてほしいということ。これはもっと金を払えってことではなくて、普通にセミナーに参加していただけるのもこれ以上無いコミットメントだと思うし、セミナー参加できなくても、都合が悪いとか会場が遠いとか、そういう場合はイベント告知のツイートをRTしたり興味のありそうな周りの人に教えたり、はてブしてソーシャルブックマーク集めたりとその時で、できる範囲のコミットメントというのがあると思うのでそれをしてほしいと思います。

そうすることで、互恵主義が成り立つのではないかと。つまりコミュニティのメンバーがコミュニティに対して利益を与えることで、コミュニティがメンバーに利益を還元できると考えます。具体的に言えば、kanazawa.jsはアツイやつらが集まってるぜ！って周りから思われたら、有名な人を連れてきやすくなったりするかもしれません。

そんな感じうまくやっていきたいです！