547
410

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

有志の社内勉強会を1年で50回くらいやった結果 伝えたいこと

Last updated at Posted at 2017-11-25

#はじめに
##自分がやったこと
こんなことやった結果の、経験談です。
参加募集先:部門の人(200人くらいだった気がする)
平均的な参加人数:5人前後
運営:1人
頻度:50回くらい/年(週一くらいのペース)
枠:1時間
場所:社内の会議室
補足:個人PCは持ち込み禁止/会議室にはプロジェクターのみ
時期:2014年くらい(私is5年目)
スタンス:有志
PJ:そこそこ長い期間やってる汎用機の保守(金融系)

##記事のターゲット
この記事は、「勉強会に対してモチベーションの低い、そこそこの人数を相手に勉強会を開催した場合1」に特化して記載しています。
(そうじゃない場合でも有用な情報ではあると思うので、せっかく来たならぜひ読んでってください。)

社外での勉強会や、ビジネスとしての勉強会、比較的意識の高い小集団での勉強会についての記事は多く見かけます。
一方で、こういうニッチな記事をあまり見かけない/見かけたとしても、「あきらめましょう」的な内容で終わってたりするので、せっかくなら記事化してやろう、という感じで記載していきます。

#運営について
##始めるために
「気負わない事」と、「勢い」が大事です。
いろいろと「思った通りにはなりません」ので、あまり気負わないのが良いかと思います。

参加者の少ない勉強会は、参加者によって大きく左右されます。
なので、とりあえずはじめてから、徐々に修正していきましょう。
そう言った意味で、ひとまず「はじめちゃおう!」くらいの勢いが大事です。

どんな勉強会であれ、「勉強会に出たら良いことがある」と「参加者が」思わないと参加してもらえないですし、そんなのを事前に抑えきるのに労力つかうくらいなら、トライアンドエラーしていった方が早いです。

##継続の仕方
よく「勉強会ってどうやったら継続できるの?」「パイの少ないところでなぜ継続できたの?」とか聞かれます。
個人的に思う「継続のコツ」と「アンチパターン」について記載します。

###継続のコツ
大きく3つです。見落とされがちな「運営側の動機付け」から触れていきます。

  • 運営側の動機付け
  • 参加者側の動機付け
  • 協力者を増やす

####運営側の動機付け
コツと言えるかどうか分かりませんが、個人的には「運営側の動機付け」が大事だと思っています。
そもそも、継続するかどうかは、参加者が決るものではなく、運営側が決めるものですし。

以下は、自分の時はどうだったか?という話です。

個人的に1番の目的は「自分が勉強会を回せるようになること」だけでした。
勉強会って(色んな人にほんのりと)期待されている割に、誰もやらない/やれないので、こういうのが回せるようになれたら良いだろうな・・・と。
「いかにローコストで勉強会をするにはどうすれば良いか?」「どういうテーマが興味ある人が多いのか?」とかを実験して、運営側の知識を身に着けよう・・・みたいな感じです。
こんな記事を書くくらいには、身についていると思っています。

二番目は自分自身のブランディングが目的で、「こういう面白いことをやれば、面白い話がきっと舞い込んでくるだろう」というものでした。
実際効果はあって、他部門の勉強会に呼ばれて参加したり、人脈が広がりました。

「人のために!」とかは、ほとんどなかったですね。「人のためになりたいな」とは思ってましたが、目的として掲げては無かったですね。

繰り返しになりますが、運営側自身こそが、興味を持って継続できるような勉強会をすることが、継続するには大事だと思います。

####参加者の動機付け
次に大事なのが、参加者の動機付けです。
「勉強会に参加すること」自体をポジテイブに受け取ってもらわないといけません。

結論からいえば、「既に勉強会にポジティブな人を中心に巻き込んでいきましょう」。

そもそも、興味が無い人達を相手にしてするのだから、正面切って声を上げたところで通じません。
それは、大勢の参加者にとって、以下のようなネガティブな要素があるからだと感じました。(アンケートで実際聞いた)

  • 勉強会に参加すると、自分の時間が奪われる
  • 知らない人とコミュニケーションを取らなければならない(可能性が高い)
  • 勉強会が面白く無いかもしれない
  • 面倒臭いことに巻き込まれたく無い

身もふたもないですが、最初にこういう人達を相手にするのはやめましょう。
相手にしているうち、運営側のモチベーションが下がって死にます。

勉強会に対してポジティブに感じてる人はきっといるはずです。
探しましょう。

勉強会にポジティブな人は、他にもポジティブな人を知ってます。
コネクションをどんどん繋げて、勉強会を大きくしていきましょう。

小さいパイで勉強会を行う場合は、リピーターがとても大事です。
ポジティブに感じている人だからと言って、毎回参加してくれるわけでは無いです。(考えてみれば当たり前ですが・・・)
だいたい20人くらいまで広げて、勉強会には平均5人来てくれる感じでした。

1人でケアできるのは、20人が限界だったので、これ以上参加者を増やしたい場合は、運営メンバを増やした方が良さそうです。
(当時、運営側を増やして下手に仕事っぽくしたくなかったので、運営を増やす活動は積極的には行ってませんでしたので、そこに対するtipsは無いでございます。。。)

最終的に、参加者の動機で多かったのは、「チーム外の関係性が作れるところ」でした。
当時は、チーム移動も少ない部門だったので、チーム外との接点が希薄だったという背景はあります。

動機付けは、こちらから提供できる部分もありますが、想定外の部分を動機に感じている場合もあります。
「継続すること」自体は少なからず意識付けに貢献していたように感じます。

####協力者を増やす
権力者
協力者を増やす際に、できれば抑えておきたいのが、「権力者」です。
社内で行う場合、「残業代は出るのか?」「残業時間にカウントされるのか?」ってのは結構ポイントになったりします。
今はそうでも無いですが、当時は36協定ギリギリまで残業する人が多く、勉強会を残業時間にカウントすると、参加できない!っていう声も多くありました。
仕事自体を調整したりするのに、権力者の声が必要だったりします。
こういうのは、下の声だけでは上手くいかなかったりします。

一般協力者
権力者以外にも、協力者は居た方が望ましいのは、想像に難くないと思います。

注意するべきなのは、協力者のスタンスを尊重することです。
「運営ではなく参加者である」とか、「ここまでなら協力できる」などの線引きです。
目的は協力を得ることなので、そのスタンスを無理やり壊して関係を悪化させるのは避けましょう。

協力者が興味あるものがわかっている場合は、それを餌に運営側に引き込めるかもしれません。
が、前述の通り、運営側を大きくする活動は積極的には行ってなかったので、「かもしれません」レベルの情報です。

###アンチパターン
だいたいが前述した「動機付け」に絡んだものになります。

運営する人をローテで回す
「運営側のモチベーション」が「全員高い」なら良いですが、だいたいモチベーション低めの人に当たった時に、止まりがちになって、最終的には勉強会が死にます。

ローテさせる目的は、運営コストの低減を狙ってのことだと思いますが、正直、あまり運営コストの低減には繋がらないと思っています。
止まった時、次点繰越なのかとか、厳しい場合は代わりのテーマを用意しておくなど、運営側のアクションをちゃんと用意しておく必要があるからです。
色々考えての、ローテだったり、トライアンドエラー前提でローテを始めるとかはありかもしれませんが、安直なローテは「悪」です。

ローテ始めた直後に死ぬってのは、実際よく見かけるアンチパターンでした。

運営してない人の意見が強い
上司などが、口を出してくるパターンです。
自分は運営していないのに、好き勝手言ってくるヤツです。
無視できる意見なら、無視してしまえばいいですが、無視できないような強い意見に振り回される状況だと、運営側のモチベーションが維持できずに死にます。

幸いなことに、自分の周りには居ませんでしたので、このアンチパターンは想像の域を出ません。
が、まぁダメだろうなという直感があります。

事前課題
運営側としては、なるべく質の高い勉強会を提供したいものですし、事前課題は有用だと思います。
とはいえ、初期の頃に事前課題を課すのはオススメしません。

対象はモチベーションが低いのだから、動機付けがさらに弱くなってしまいます。

課題を事前にやってもらった方がより高みに行けるのは確かです。
ただ、課題をやることに対して十分な動機付けができてから、行うのが望ましいと思われます。

実体験としては、事前課題を出したこともありましたが、9割が「やってこない」感じでしたので、途中から出すのをやめました。

強制参加
「これは強制じゃない、説得して納得してもらっている!」ってのもダメっす。準強制も強制に入ると思っています。
対象はもともとモチベーションが低いのだから、動機付けがさらに弱くなってしまいます。

運営側だと、「偉い人を読んだから/外部講師を読んだから、人を集めなきゃ」っていうプレッシャーに狩られますが、そういう場合でも強制参加はやめましょう。
その回は人が集まるかもしれませんが、継続性という観点では、悪手です。
どうしても参加者を増やしたいなら、単純に参加者のパイをでかくした方が良いです。(声かける先を増やすべし)

これは、単純に反省です。

勉強が目的ではない勉強会
「全員の意識向上」とか、「会社/部門の風土改善」とかの類を目的にする、なんちゃって勉強会のことです。
「結果的にそういう効果がある」というのは否定しませんが、最初からそれを目的にするのはNGです。

なぜなら、「参加者の動機付けにならない」&「効果が見えにくい」からです。

参加者からするとどうでもいい目的なので、参加者が集まりにくいです。
言い換えてしまえば、参加者に望まれていないということなので、運営側の徒労感が半端ないです。
しかも効果が見えにくいので、運営側が疲弊するか混迷した末に終わるという悲惨な結果2になります。

ツラいのは、こういうケースは「上司から言われてやる勉強会」の時に頻発するもので、運営側に逃げ道がないことが多いことですね。

できることはあまり多くないですが、可能なら、勉強会の方向性を見直すか、勉強会以外の手法を取ることを提案すると良いと思います。
(失敗の実績を作るために、わざとやるという話しもありますが、次の施策を行う際に余計な足枷になるので、やっぱりやらない方が無難だと思います。)

##テーマ設定について
###テーマと参加人数の関係性
魅力的なテーマなら参加者が多く集まるのでは?と考えた時期もありましたが、
結論から言えば、部内でやる限りは、魅力度と参加者の人数は比例関係には無いというのが実感です。

全く興味ない・あまり興味ない・どちらでもないのタイプの人は、参加しません。
少し興味ある・メチャクチャ興味あるのタイプの人が参加します。
そもそも、興味を示すタイプは、普段からアンテナを貼っているタイプの人なので、だいたいなんでも興味を示します。

そうなってくると、部門内で既に来る人/来ない人というのは、ある程度絞られていることに気づきます。
テーマ設定による人数の変動は、正直誤差レベルです。(実際、誤差レベルでした)

###テーマの選び方
前述の通り、基本的にはテーマはなんでも良いと思ってますが、選び方の基準はいくつかあります。
以下にいくつかのポイントを記載しますが、バランスが大事です。

####継続性
運営側が興味あるテーマであること。
最悪、参加者は0に近いことケースもあると思いますが、その時間を運営側自信が勉強の時間に使えるので、徒労感もあんまりなく、継続しやすいです。
ただ、参加者の少ない自分よがりなテーマ設定を続けているのは、他の人にポジティブな印象を与えないので注意しましょう。
(ポジティブな印象が減ってしまうと、「あの勉強会なら参加してみたいな!」みたいな人が離れていってしまうので・・・)

####集客性
人数を集めようとすると、ある程度の魅力は必要です。
参加人数重視なら、あんまり奇をてらったテーマは不要で、「品質について」とか「タスク管理について」とかの永遠のテーマ系をあげときゃいいです。
(言い方はあれですが、実感としては、この表現が近いです。)

それ以外にも、現時点で関わっている仕事に直結するテーマは、比較的ウケが良かったです。
(採用しているフレームワークを紐解いてみよう!とか)

####アンチパターン
何を失敗と捉えるかによって、アンチパターンかどうかは変わりますが、「あまりプラスの効果がない」物をいかに記載します。
(マイナス効果ではないモノもあります。)

上から目線
「こういう勉強をしなさい!」とか、「これはみんな意識してないけど、知っておいて欲しい!」とかのテーマ設定だと、あんまり集まらないな、というのが実感です。
(パイがでかいなら、それでも一定数は集まりますが、パイが小さい場合はそうではないです。)

『参加者自身』が「魅力的だな」と感じなければ意味がなく、運営側が魅力的だと感じていても無意味/無価値です。

結構、「これ良いテーマだと自分(運営側)は思うけど、人集まらないなぁ・・・」ってのは、自分もありましたし、周りでもちらほら見かけました。

テーマの募集
その集団にもよると思いますが、テーマをアンケートにとっても、当時の部門では大した回答は返って来ませんでした。
だいたいの参加者はあくまでも受け身でしかないんだろうな・・・というのが感想です。

アンケートをとる場合に注意して欲しいのは、「参加してくれる人」にアンケートをとる事です。
前述の通り、リピーターこそが、継続の肝です。
「潜在的参加者(≒参加してくれない人/参加するする詐欺する人)」は重要ではありません。

拡大路線なら「潜在的参加者」のニーズを探る事は効果があるかもしれませんが、その場合でもリピーター中心に考えることをオススメします。

今までのリピーター(土台)を捨てての拡大は、実質新しく勉強会を立ち上げ直しているのと同じなので、めちゃくちゃ大変です。

#勉強会の形式について
勉強会もいくつかのやり方に分かれます。実践した形式を以下に示します。
#あくまでも有志での運営を想定した場合を記載します。
#運営チームがタスクとして取り組むのであれば、他にもやり方はあると思います。

継続を考えるなら2.ディスカッション形式を中心に据えつつ、1.講義形式をたまにやる、のが良いかと。

##1. 講義形式
講師と受講者がいる形
メリット:
講師が好きな分野であれば、準備はそこまで苦ではない。
受講者も比較的質の高い内容を享受できる。
デメリット:
狭いグループの場合、講師は偏りがちになる。(部内とか事業部内とか)
1・2回は苦でなくても、継続すると講師はシンドイ。
講師慣れしている人は少ないので、講師と受講者の技術レベルに差がありすぎると、あまり身にならない可能性もある。
補足:
安直に講師をローテさせるのは、前述の通りアンチパターンなので避けましょう。

##2. ディスカッション形式
テーマを決めて参加者同士でディスカッションする。
メリット:
事前準備はテーマを決めるだけなので、そこまで手間ではない。
デメリット:
事前に用意された答えはないので、ファシリテーションできる人を用意する必要がある。
ファシリテーターを用意できない場合は、絶対にやるべきではない。(参加者が勉強会自体に悪印象を抱いて、勉強会が死ぬ)
参加者にも求める部分があるので、前もってこういう形式であることを明確に伝えておく必要がある。
補足:
自分がやってた勉強会の過半数はこれです。

【2018/10/01追記】
ディスカッション形式ってどういうの?っていう疑問がちらほらあるっぽいのですが、以下の記事のような感じがディスカッション形式です。
ドキュメントレビューに対する経験知(レビューを語る夕べのイベントレポート)
※このイベントはあくまで参加者側でした。

##3. 講義型実践形式
「みんなで集まってプログラミング」「特定のケースを想定したワークショップ」など。
プログラミング課題の選定/ケースの準備を、運営側が行う場合。
メリット:
聞くだけよりは身になる。
デメリット:
死ぬほど準備が大変。当日の運営も想定外の質問が多発するので、運営側にもある程度の人数/スキルが求められる。

#最後に
なんだかんだ自分は恵まれた環境下で、勉強会に対しての実験を行うことができました。
当時の部長/副部長始め、権力者の後ろ盾もあり、ありがたい環境でした。

ちなみに最近は、みんなで一緒にreactチュートリアルやろうぜ!つって、reactやってます。
チャット3で、「ここまで進んだよー」とか、「このソースコードはこう解釈したけど、あってるかな?」とか、ワイワイやってて楽しいです。
この形式は、前述のいずれにも当たらないパターンではありますが、語れるほど整理できていないので、ご紹介だけです。

勉強会の形式も徐々に変わりつつあるのかな・・・なんてことを感じつつ、記事にしたような勉強会もまだまだ残り続けるとは思います。
本記事は、やや客観的なデータにかける主観的な記事ですが、今後の勉強会主催者に役に立てば幸いです。

以上です。


追記

2018/08/07 以下記事も合わせてお読みください。
勉強会アンチパターンへの対処例(随時更新)


  1. 当時こういう部門がありました。が、過去の事。現在は風土がだいぶ変わって来ていて、全社ターゲットにした勉強会イベントも開かれてますし、ベンチャーと関わりが増えたりと、どんどん刺激が増えて来ていると思います。(だから記事化できたってのもある。)

  2. 何が悲惨かって、「運営(しても良い人)が減ること」が悲惨です。再起が困難になります。

  3. なんとなくtrelloでやってますが、slackとかrocket.chatとかのが便利かと思います。

547
410
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
547
410

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?