社内勉強会を立ち上げて 3 年で 100 回続けてわかったこと

これはフェンリルデザインとテクノロジー Advent Calendar 2019 5 日目の記事です。

ウェブ共同開発部の小原です。

フェンリルではほぼ毎週「ウェブ勉強会」という社内勉強会を開催しています。この勉強会は約 3 年前から継続しており、最近第 100 回目の開催を迎えました。

長く継続したことでいくつかわかったことがあります。 100 回を良い機会と捉え、これまでを振り返ってみたいと思います。

どのような勉強会か？

まず「ウェブ勉強会」がどのような勉強会か紹介します。

ウェブ勉強会は社内でいくつかある勉強会のうちの一つです。週に 1 回、1 時間、会議室に集まって実施します。一部リモートです。毎回、一人または二人が自由なテーマでスライドを用いた発表をします。主にウェブ共同開発部のエンジニアメンバーが自由に参加します。数人のチームで運営しています。

発表テーマは自由なので様々ですが、直近はこのような内容です。活動の記録は社内の Wiki にまとめているので、そこのスクリーンショットをとりました。

f:id:KoharaKazuya:20191204160314p:plain — ウェブ勉強会の直近10回分の発表テーマ

勉強会の始まり

私が入社した当時、2015 年になるのですが、私から見ると部内で各プロジェクトをまたいでの知識の共有が少ないように思えました。これは今考えると、私が新卒入社したばかりで視野が狭かっただけなのですが、当時は課題意識を持ちました。そこで勉強会を 5 年以内に開始したいと考えました。

私は新卒一年目で影響力はなかったため、まずは小さく始める必要がありました。タイミングよく所属していたチームの定例ミーティングが自由な雰囲気だったので、そこで試しに勉強会風の発表を初めてみることにしました。

これをしばらく続けていたところ、先輩が「定例ミーティングでやっている知識の共有を部の単位でもやってほしい」と私に声をかけてくださいました。その後、先輩はあれよあれよという間に許可を取り付けてきて、勉強会が始まることになりました。勉強会は私含めた 3 名で運営することになりました。初回は 2016/09/15 でした。

当初は 5 年ぐらいの長期で実現したいと考えていたことが 1 年程度で叶ってしまいました。このことから小さくても行動を始めて継続することの重要さを実感しました。また、先輩のフットワークの軽さは手本にしたい姿です。

勉強会をする動機

勉強会を実施するのにあたり、動機をはっきりさせておく必要があります。どのようなことがしたくて勉強会を実施するのか、を考えました。以下に書くことは当初から明確だったわけではなく、勉強会を継続していく中で整理していったものです。

一つは「私たちはスペシャリストであるべきだ」という考えです。組織のメンバーがそれぞれ最も得意な分野で活躍して協調できるようにするため、サポートしたいです。協調ためには誰が何が得意なのか知っておく必要があります。勉強会がそれを知れる場になるように目指しました。

一つは交流です。同じ会社のメンバーといえど、プロジェクトが違うと Face to Face で話をする機会は案外ありません。勉強会が交流の場の一つになれるように目指しました。

一つはチャレンジの場です。私がやりたかったことを形にすることを先輩がサポートしたように、誰かが新しいことをチャレンジするための場があると嬉しいです。勉強会がその場になるように目指しました。

勉強会の設計と結果

勉強会を実施するにあたり、どのような内容にするか決める必要があります。前述したように動機を整理しつつ、それを達成できるような内容を考えました。

主もにすることは「スライドショーを用いたプレゼン形式の発表」となりました。恐らく勉強会という単語を聞いてイメージするとおりの形式だと思います。

発表のテーマは自由としました。ウェブ勉強会と銘打っていますので、そこから大きく外れるようなことはありませんでした。

プロジェクトを越えた情報共有をする

自由としつつも「私たちはスペシャリストであるべきだ」だという思いから、誰がどんなことに詳しいか、詳しくなったかを共有するため、実際のプロジェクト内容と振り返りを紹介する「案件紹介」というカテゴリを設けて推奨しました。案外、他のプロジェクトで何をやっているか、どんな技術を使っているか、などは知らないもので、そういった知識の共有に繋がったのではないかと考えています。

誰もが発言できるようにしたい

勉強会を交流の場として活用したかったので、気軽に話しやすい雰囲気作りは重要でした。

先輩・後輩の立場関係なくフランクに発言できるよう、なるべく全員が発言できるよう、「チャット会」「ミニ共有会」という名前の取り組みを実施しました。これらは雑談にテキストチャットの並列性の長所を組み込み、誰でも発言しやすくしようと狙ったものでした。

しかしこれらは思うように効果が出なかったように思えます。フェンリルでは社内コミュニケーションの一つにテキストチャットツールを用いていますが、 Face to Face であっても雑談がテキストチャットと同じような性質を持ち、よく発言する人だったりその量は変わりませんでした。

Face to Face の効果はもちろん他にもあるとは思いますが、うまく掴みきれなかったため「チャット会」「ミニ共有会」は継続しませんでした。

発表準備の負荷を下げたい

発表の形式はどうしても内容決めや資料作成に時間がかかります。忙しい人が勉強会での発表に高いハードルを感じるようになる原因だと思います。

なるべく発表負荷を減らすため、発表の呼びかけをする際に以下のガイドラインを案内するようにしました。

案件紹介_発表ガイドライン

# 案件紹介\_発表ガイドライン

この文書は案件紹介の発表ガイドラインを提供する。発表資料を作成する際に考慮しなければならない点を減らし、資料作成のコストを減らすことを目的とする。

**この資料はあくまでコスト削減のための参考資料であり、従わなければならないルールではない。**

## タイトル

タイトルを愚直に `<顧客名>/<プロジェクト名> の案件紹介` とすると共に、アナウンスした際により多くの人の興味を引けるよう、短い概要文を考えると良い。

もしくはキャッチーなタイトルを付ける。

## 観点

以下の観点が案件紹介で求められている情報だと考えられる。

- 顧客の背景
- プロジェクトの目的
- 開発メンバー/担当範囲
- 使用技術
- 得たノウハウ

## ツール

発表資料は装飾にこだわらず簡易な見た目としたほうが良い。
(単なる社内の勉強会のため、資料作成に過度なコストをかけるべきではない)

簡易的に資料を作成できるツールとして [Marp](https://yhatt.github.io/marp/) が利用できる。実際の利用例として [第 11 回 -- テストツール紹介](../presen/20170223/kohara/) のディレクトリが参考にできる。

## テンプレート

これらを考慮した [テンプレート](./README.md) を示す。
必ずしもこれを使用しなければならないわけではなく、資料作成時の参考となるものである。
要・不要な項目の判断は、各自で行い適切な量の資料作成を心がけること。

特に Marp は自然と広まり、手軽に資料を作成するために役立ったようでした。

発表依頼が強制になってしまわないようにしたい

発表が持ち回り性で損な役回りとなってしまわないように、発表依頼が実質的に強制にならないように気をつけました。あくまで本人の動機によって発表してほしいという思いです。

そのため、ダイレクトチャットを使用しました。口頭だと落ち着いて考える時間が取れない、断る建前（有り体に言えば嘘）がバレやすい、パブリックな場だと断りづらい要因が発生する、などを懸念したためです。

結果的に体感で半数程度が辞退する状況となりました。完全ではないとは思いますが、概ね気が乗らなければ辞退してもらっていたように思います。

プロジェクトのタスクに追われて参加しづらいのをなんとかしたい

常にこのような意見はありました。しかしこれは勉強会を内容を考える問題の外側にあるような気がしたため、特に対策は考えませんでした。

勉強会を実施していることはプロジェクトマネージャー陣にも伝えているため、配慮はしていただいているようです。

運営負荷を下げたい

勉強会の運営もそこそこの負荷があります。スケジュール調整や発表者の募集や依頼、活動記録など。真面目にきっちりやらなくてもそれなりの時間は必要となります。

私の考えとしては、私自身含め 運営としてやりたことがなければ勉強会は終わらせてもいい というものだったので、特にこの課題を解決しようと思いませんでした。運営として多少大変でもやりたいことがあればやりたい人がやればいい、というスタンスです。そのようなスタンスだったため、私は運営メンバーを増やそうという発想もありませんでした。

一方で、当時の運営の一人の西山は負荷の分散と属人化を避けたいという観点で、新たに 4 人の後輩の運営メンバーを集めました。のちに彼らが現在の運営メンバーとなりました。

私になかった観点で運営が改善されていく様子は見ていて気持ちのいいものでした。チャレンジできる場としての価値を十分に発揮するため、後輩に場を譲る重要性を気づかされました。最終的に後輩のメンバーたちに完全に運営を引き渡すことになり、チャレンジできる自由な場を与えられたのではないかと思っています。

現在の運営チームによる工夫

上記のとおり運営は引き継ぎ、現在の運営チームに関して私が知らないことも多いため、現在の運営メンバーの一人の水野に補足してもらいました。現在は以下のように工夫されているようです。

プロジェクトのタスクに追われて参加しづらいのをなんとかしたい

ビデオ会議による自席参加をやりやすくする、という取り組みを実施しました。

プロジェクトのタスク面の不安から参加しづらいのをなんとかしたいという思いと、できる限り参加へのハードルを低くしたい、裾野を広げたいという思いがあっての決定でした。

結果的には、忙しさによってこれまで参加したことのないメンバーにも参加してもらえたので、成功だったと考えています。

運営負荷を下げたい

細かい点を多く改善しました。

司会・議事など定期タスクの持ち回り制にした
- 逆に打ち合わせの進行、会議室の取得などの非定期タスクは属人化させた
- 直前になって慌てることのないようにするため
GitHub Projects を使って発表スケジュールを管理するようにした
運営メンバーによる発表でスケジュールの空きを埋めるようにした
- 発表者にスケジュールの心配なく引き受けてもらえるように
チャットボットを導入して定期タスクや開催の連絡を全て自動化した