こんにちは。開発部門HR（技術人事）のOKANOです。
前回は、それまで勉強会文化がなかったぐるなび社内に、学びの文化が芽吹くまで についてご紹介しました。
今回はこの話の「それから」についてお伝えしたいと思います。
- とりあえずスタートを切った！けどこれからどうしよう、という方
- 社内の文化づくりに奮闘されている方
こんな皆様のご参考になれば幸いです。
「勉強会プロジェクト（以下、勉強会PRJ）の芽生え」は、「0を1にするお話」でした。この中でもそれなりにもがいてはいたのですが、成長期（1を5に増やすお話）に移る過程の今回のお話でも、かなりもがいてきました。
未だ努力の最中であり、完結はしていない事をご承知おきください。
運営体制の甘さが発覚
まずは行動を起こすこと！ が「芽生え」フェーズでの行動指針になっていたこともあり、なかば勢い（だけ）で運営していたところがありました。
具体的には、
- イベント開催自体が目的になっている
- プロジェクト体制を仕組み化できておらず、ナレッジを蓄積してもフル活用できていない
このような視点が欠けていたのです。
次に挙げるような動き方がその象徴だったかと思います。
イベント開催することが目的になっており、目的意識が欠けている
勉強会PRJでは週次の定例mtg（1時間）にて勉強会や交流イベントの企画を生み出しています。
問題は、この1時間という限られた時間の中で、
- 開催したイベントの振り返り（反省）
- 次に行う勉強会の企画
- 直近にせまった勉強会・イベントのオペレーション確認
などなどをしていた事もあり、良さそうなアイデアが出れば飛びついていたのが実情でした。
そして企画する勉強会の目的は都度設定する形で運営していました。アイデアが先にあり、目的はあとから考えるような形になっていたのです。
結果として、運営側では勉強会・イベントが終わる毎にその結果に一喜一憂しているところがありました（「今日はたくさん集まったね！」とか「なんか今日はイマイチ盛り上がらなかったね・・」とか）。
本質的には、勉強会は何かの目的を達成するための「手段」であることが望ましい状態でしょう。
しかし当初は、勉強会を開催すること自体が目的になっており、目的意識が欠けていたのです。
仕組み化できておらず、ナレッジのフル活用に向けて本当の意味での組織化が必要に
そんな少しのモヤモヤが芽生え始める中、定例mtgの中で勉強会PRJメンバーの宮原さんから課題提起が。
「勉強会PRJの活動自体はとてもよいものだとPRJメンバー全員が自覚しているものの、その活動の一つ一つの結果は本当に組織へ蓄積できているのだろうか？」
という問いかけでした。
やはり組織としてやる以上、一時的な「流行り」で終わらせることなく仕組み化のうえ、継続して効果を発揮できる状態であること。これが必要不可欠です。
この言葉にはハッとさせられました。
僕たちのプロジェクトが一喜一憂していた発言の中には、勉強会・イベント企画時に設定した狙いと別の観点での反省や感想が混じっていました。
例：目的は「CI活動のシェアが出来ていること」なのに、 感想として、「盛り上がらなかった」みたいなものが挙がること
加えて、勉強会PRJに新メンバーとして前田さん がジョイン。
どういう考えのもとでこれまで活動していたか、フォローアップと情報共有の必要性が出てきたことで、キャッチアップしてもらうツールが必要になったこともこの動きの追い風になりました。
どうやってプロジェクトの目的意識を統一したか
この大きな問いは、今後の活動の上でもとても大切なことだと考え、定例mtgの中でしっかりと時間をとって議論につぐ議論を重ねました。
「なんのために勉強会というのは必要なのか？」といった問い（というかテーマ）に対する一人一人の価値観を付箋にアウトプット。書いた付箋をカテゴリ分けしたり、「ミッション・ビジョン」という言葉の共通認識を定めたり、ラジバンダリ。
ミッション・ビジョンを常に目に付くようにした
そうして作ったミッション*1がこちら。（上位である会社や部門のビジョンを支えるものとして設定しています）
- 「勉強会を通してコミュニティの活性化」
常に意識するために、これを議事録*2の一番上に貼り付けています。
※ビジョンについてはちょっとヒミツ
このミッションが正しいかどうかの確認は「運用してみてから考えよう」という事とし、まずは全てにおいてこの考えを軸にする動き方を実践しています。
ミッションという共通言語ができ、議論が分散しづらくなった
ミッションという共通言語の誕生によるものだとは断定できませんが、しかしこれが功を奏したのか、定例mtgでの議論が分散しづらくなりました。
判断に迷った時に「Whyの観点」で戻ってこれる場所が出来たのだと感じています。
また、勉強会企画・運営の面においても特に良い影響が2つありました。
1つ目は、これまでに開催した勉強会・イベントの対象者やミッションとのひも付きを明記した要件表（チェックリストのようなもの。 「この観点は大丈夫？」みたいな問が列挙してあります）が出来た事。
これにより新メンバーの前田さんとの情報共有もうまく出来ました。 もう少しブラッシュアップできれば公開したいなと思っています！
2つ目は勉強会・イベント実施後の振り返り観点が固定出来たことです。 「真のナレッジ蓄積」とでも言いましょうか。
これまでの企画では都度の振り返りは出来ていたものの、全てに通ずる共通観点がなく、反省を活かす事ができないケースもありました。企画ごとに細部の要件が違っていたとしても、こうした共通観点があることで同じ土台で比較することができるようになりました。
運営Tips
主題とは少しそれますが、勉強会PRJで実践しているノウハウを少しシェアしたいと思います。
施策1. 勉強会の宣伝を自動化
エンジニアで構成される勉強会PRJではオペレーションもハックしています。その一つが、勉強会の申込時点での盛況情報を逐次Slackに投稿するよう自動投稿を設定している点。
企画が立ち上がると、ぐるなびではまず、勉強会ごとにGoogleフォームを立ててSlackにて参加者を募集しています。
実際のGoogleフォーム
ちなみにコードはこちらでも公開しています！
slack_form_applications（Googleフォーム投稿から取得した結果をslackへ定期通知するbot）
function BenkyokaishowStatus() {
// シートを取得
var spreadSheetURL = "[シートのURL]";
// 取り扱いたいスプレッドシートのURL
var spreadSheet = SpreadsheetApp.openByUrl(spreadSheetURL);
// シートを指定
var sheet = spreadSheet.getSheetByName("[シート名]");
var message = '';
var arr = sheet.getRange("[対象範囲]").getValues();
var list = {};
var count = 0;
// ラベルを除いた対象行数を取得
var lastRow = sheet.getLastRow();
var length = lastRow - 1;
for (var i=0 ;i <= length ; i++) {
if (arr[i][2] =='参加します') {
list[i] = arr[i][1];
}
}
if (length > 0) {
var datetime = Utilities.formatDate(new Date(), "Asia/Tokyo", "HH:mm")
message = datetime + '現在の参加者数 ： ' + length + '人 :bakushou: \n';
message = message + "<" + spreadSheetURL + "|詳細はこちら>\r\n"
BenkyokaislackPost(message);
}
}
function BenkyokaislackPost(message) {
//slack_token
var token = "[Slack APIのトークン]";
var slackApp = SlackApp.create(token);
var ChannelId = "[投稿するSlackのチャンネル]";
var botName = "[投稿するbot名]";
var Options = {
username: botName,
}
slackApp.postMessage(ChannelId, message, Options);
}
参加者がGoogleフォームに入力すると、スプレッドシートに一行追加。
そのシートの命名規則を「YYYYmmdd」の形式にしておくことで、カレンダーと連携し自動的にシートを判定。何行あるか計測し、参加者数をSlackに投稿してくれるものです。（※カレンダーとの自動連携部分は今後実装予定で今は手動変更）
これによって、追加宣伝のタイミングなどでやきもきする機会がへり、企画の本質にかける時間が増えました。（やきもきすると定例mtgの時間を侵食します...）
お昼の勉強会観覧応募状況はこんなふうに、
そしてLT大会開催時の応募状況はこんなふうに通知されます。状況にあわせて勉強会PRJで追加で宣伝したり、飲食物の発注量を調整したりします。
観覧応募状況だけでなく、登壇者も通知可能です。
施策2. 登壇順の決定を自動化し政治をなくす
登壇が必要な勉強会において、登壇順を決める作業は結構重要。
これまでは「希望を聞く」→「かぶったら相談」みたいな事をしていたのですが、一人一人の返答状況も違うので調整に多少ではありますが時間がかかることもありました。
これを自動設定されるURLを用意することでプロセスがまるっとなくなりました。
コードはこちらに公開しています！
slack_shuffle_sort（特定のメンバーの順番を決定しslackへ通知する）
<?php if ($_GET['channel']) { $channel = $_GET['channel']; } else { $channel = "[投稿するSlackのチャンネル]"; } $ary = array([参加メンバーの配列]); $text = "\n発表順は・・・\n"; $text .= "ジャラジャラジャラジャラドン！！！！！！\n\n\n"; shuffle($ary); foreach($ary as $key => $val) { $new[$key] = $val; $text .= $key + 1 . " 番 : " . $val . "\n"; } print str_replace("\n", '<br>', $text); //gnavi slack_token $slackApiKey = "[Slack APIのトークン]"; $channel = urlencode("#" . $channel); $text = urlencode($text); $url = "https://slack.com/api/chat.postMessage?token=${slackApiKey}&channel=${channel}&text=${text}"; file_get_contents($url); ?>
こういったオペレーション効率化によってタスクが消えると精神衛生上とてもよいです。
施策3. 過去開催の内容をサマリにして抽象化
過去に開催したイベントを一般化（テンプレート化）することで、次回以降に開催するイベントをどういった形式・体系で行うのか議論しやすくなりました。
とは言っても、まだそれほどテンプレートが揃っているわけでもないですし、かといって量が必要なわけでもない。亜種が出たら違いを踏まえてこの資料をアップデートしていく予定です。これにより、改めてナレッジの蓄積ができました。
内容の一部。空白部分も文字が入っていますが、ここでは伏せさせてください。
施策4. 分科会体制を発足しイベントを量産化
みんなでミッションを定めた事でイベントの目的も明確になり、これまでは常に全員で議論しながら進めてきた勉強会企画を個別体制で進めることが出来るようになりました。
ツーマンセル（2人1組）でチーム分けをして、イベントの量産化に向けて取り組んでいます。
施策5. 議事録ダイジェストの運用
今回の主題と完全にそれるのですが、mtg運用において試して機能してそうなので挙げます。
mtgの始まりはいつも先週の終わりの時点の記憶をたどるところから始まり、全員の認識が合うまでにちょこっと時間を消費していました。
そこで、毎回ダイジェスト*3を書いておくことに。mtg開始 or 開始直前にそこだけ読めばすぐに認識合わせができるようになりました。（欠席者との認識合わせにも役立ってます）
最近とこれから
ミッション・ビジョンの設定後最初に開催したのは過去にエンジニアブログでも何度かご紹介しているLT大会の企画。
ミッションを意識して、以下のような取り組みを導入しました。
- 名札をつけてもらう
- 当日参加者同士で盛り上がるためのWebツール（通称：ワクワクメーター）を開発
- 開催事後のレポートの制作（社内向け）
ほかにも細々としたチャレンジもありますが、今回は割愛します。
ワクワクメーターはWebに設置したボタンを押すと会場前方に設置された全体向けモニターに表示されたグラフのメーターが動くという仕様です。結果的にボタンが26,000回押されたのには驚きました...！
「ワクワクメーター」と連動する「わくわくボタン」
「わくわくボタン」を押すとスクリーンの「ワクワクメーター」が動く仕様
ネタはまだまだ湧いている
もともと定例mtgの場におけるネタ出しでは結構な量のアイデアが出ていました。 そういった過去の財産をミッション・ビジョンと照らすことで新たなアイデアも出てくるようになりました。
ネタが有り余っているとついつい消化に走りたくなってしまうのですが・・・あまり追われすぎることなく、余白を持ちながら少しずつ発信できればと考えています。
まとめ
文化の芽生えから成長期へのプロセスをつらつらと書いた結果、おもいのほか長文になってしまいました。。
少しでも読んで頂いた方のお役に立てれば幸いです。
このプロセスを体験してきたまとめとして、以下の３つがコアになるのかなと思います。
- 組織の行動を定期的に振り返ること
- 振り返った結果を活かして次の行動を計画すること
- 次の行動を確実に実行すること
言ってしまえば、PDCAや経験学習といったフレームワークと同じ動きをしているだけなのですが、体現するのはなかなか難しいものだと感じました。（特に”みんなでやる”というのは時間の都合もあり、職場によってはなかなか難しいケースもあると思います）
今回は、もともと掲げていたビジョンを再構築するプロセスを歩みましたが、正解があるわけではないので...例えばそもそも論から入るアプローチもありだったかもしれません。
まずは至った結論を信じて、引き続き定期的に振り返りながらエンジニアのワクワクする環境を作っていきたいと思います。
お知らせ
2020年度新卒エンジニア募集中！
