PrAha Inc.

PrAha Inc. のブログ、あるいは社員の観察日記

勉強会が秒で過疎った話

どうも、株式会社プラハCEO兼エンジニアの松原です

 

弊社ではメンバーの技術力を高めるために数々の勉強会を開催してきましたが、色んな失敗を経験してきたのでひとまず共有したいと思います

 

 

TL;DR

  • 何も考えずに勉強会を開催してたら過疎った
  • なので色々と変えた
  • ISUCONやSECCONやハッカソンなど、何かしらのアウトプットがあるタイプのコンテストに参加するための交通費、宿泊費、懇親会費用などを会社で負担することにした
  • 有識者を呼んで講義をしてもらうための有識者クーポン」を発行した
  • 輪読会に使う技術書は全額会社負担にした

 

 

何も考えずに勉強会を開催したら過疎った

文献によると弊社で行われた最古の勉強会は2年前に「各々が好きな内容をLTする」という(良くある)形式で行われました。この形式の勉強会は「LT用の資料を用意するの半端なく大変なんですけど?」の一声と共に秒で過疎りました

 

デブサミとかオーディエンスの多いLTなら労力に見合うかもしれませんが、オーディエンスが少ない勉強会のために資料を毎回用意するのは気が引けちゃいますよね...

 

また聞いている側からも「興味を持てないテーマだった時に辛い」といった声もあり、喋る側も聞く側も辛いLOSE-LOSEの状態になっていました

 

(教訓)

・準備の手間がかかる割にオーディエンスの少ない勉強会はすぐ過疎る

・ある程度テーマを絞っておかないとオーディエンスに興味を持ってもらえない

 

 

じゃあ勉強会のテーマを揃えてみよう

「LTの内容に興味を持てない」を紐解いていくと、以下のように細分化できました:

  • ジャンルの問題(フロントエンドは好きだけどインフラは興味がない)
  • レベルの問題(簡単すぎて眠い、難しすぎて同じ日本語とは思えない)
  • 必要性の問題(直近の業務で使わない知識なのでアンテナが反応しない)

 

「じゃあ勉強会のジャンルと、レベルと、必要性を揃えよう!」

 

ということでDDD勉強会が社内で定期的に開催されるようになりました。

 

ジャンル:揃ってる(DDD)

レベル:みんなで同じ本を読みながらハンズオンで進めるので、レベルも揃ってる

必要性:業務ですぐ使える

準備負荷:資料を用意する必要がない(書籍を読んで不明点をまとめておくだけ)

 

「これで完璧やんけ!」と思ったのも束の間、DDD勉強会も過疎りました

 

 

なぜDDD勉強会は過疎ったのか

弊社では6プロジェクトほど並行しており、プロジェクトごとに求められるスキルセットも異なります。プロジェクトによってはDDDより他テーマの方が学ぶ優先度が高いため、少しずつ参加者の気持ちがDDDから離れていきました

 

また勉強会が進むほどメンバーの知識も増えるので、後から参加するメンバーと昔から参加していたメンバーの知識差が拡大するのも問題です

 

スキルもバラバラなエンジニアが沢山いる会社で常に優先度最上のテーマが揃うことは殆どないので、勉強会のジャンルを会社全体で絞るのはあまり良い解決策ではなかったなぁ、と振り返っています

 

(教訓)

・勉強会のテーマを絞ると、より優先度の高い学習内容に直面した参加者が離脱する

・同じテーマをずっと勉強していると参加時期によって知識差が生まれて、レベル感をそろえた勉強会が実現しづらくなる

 

 

 

ダイソンプロジェクト爆誕

しかしWEBの世界は日進月歩。最新の知識に触れ続けなければ競争力を失います

 

・準備の手間がかからず

・ジャンルは絞らない

・それでいて万人に役立つ(明日から使える)知識に触れられる

 

そんな勉強会の方法を模索した結果、ダイソンプロジェクトが立ち上がりました

 

説明しよう、ダイソンプロジェクトとは!

 

一般的にソフトウェア開発の現場はプロジェクトを新規作成した時が最も生産性が高く、既存コードが増えるほどに変更が困難になり、生産性が落ちる傾向にあります

 

プロジェクトが肥大化しても生産性が落ちない事こそが開発者の腕の見せ所、ということで日々プラハの社員が生産性を落とさないために実施した工夫をお互いに共有する、というコンセプトで誕生した勉強会です

 

こんな感じで各々が毎週スレッドに自身の工夫を列挙して

f:id:praha-inc:20210406115357p:plain

(名前を公開されたくないメンバーが居るため塗りつぶし)

 

全員が毎週の全体定例(WEB会議)でスレッドに目を通して、気になった工夫に質疑応答するような形式です

 

過去の勉強会との差異としては

 

・手間がかからない

 ・自分がやったことをSlackに書くだけ

・目的が統一されている

 ・「生産性を上げる」という目的が統一されているため万人受けする

 ・工夫のジャンルが幅広いので(人によってはインフラだったり、人によってはフロントエンドだったり)様々な事例に手軽にキャッチアップできる

・レベル感が揃ってる

 ・各々が実際に現場で実施した創意工夫なので、すぐに実務で役立つ可能性が高い

 

 

 

「吸引力生産性が落ちないただ1つの開発組織を目指す」というコンセプトで発足したダイソンプロジェクトですが、これも過疎りました

 

吸引力が、落ちた

最初こそみんな頭を捻って

「aspidaを使ってフロントエンドにAPIに準じた型を付与しました!」

「docker-compose upだけでローカル開発環境が立ち上がるようにしました!」

「スナップショットテストを追加しました!」

 

など様々な知見を共有していたのですが、半年も経つと徐々に知見が出なくなり

 

f:id:praha-inc:20210406115731p:plain

 

何も知見を出せなかった人には某調査兵団の「何の成果も!あげられませんでしたぁぁ!!」スタンプを付けるという謎の文化が発生する始末

 

なぜ吸引力が落ちたのか

仮説としては以下2点です:

割れ窓理論

・対話と深度の不足

 

 

割れ窓理論

イデアが底をつき始めたタイミングで「まぁそういう週もあるよね」となぁなぁにしてしまったのは良くなかったなぁ...と反省しています

 

毎週必ず自分の創意工夫を発表しなければいけないプレッシャーが最新事例への探究心や現プロジェクトに対する改善意識を刺激する」と期待していたのですが、そのプレッシャーが弱すぎたことで望む結果が得られなかったのではないでしょうか

 

ただプロジェクトの状況次第では改善の機会が少ない時もあるし、この取り組みが苦痛になって欲しくない気持ちもあり、強制力を発揮できませんでした

 

 

対話と深度の不足

限られた会議時間で毎週10人超から事例を投げられると、事例ごとに取れる時間が短くなってしまい

 

「Docker Composeで全部立ち上がるようにしました!」

「いいですね」

「はい」

「・・・」

「・・・」

 

思春期の娘と距離感を測りかねている父親みたいな会話が増えてしまいました

 

知っている人からすれば「おう、俺もやったわ

知らない人からすれば「え、イメージつかない・・・聞きたい・・・でも時間が・・・」

 

と、どちらにとっても中途半端な深度になってしまったのが原因ではないかと反省しています。気になるテーマを深掘りする余地が欲しかった

 

 

ダイソンプロジェクトの活かし方

とはいえ自身もダイソンプロジェクトを通じて「Storybookにfigma連携機能があったのか」とか新しい気づきを得ることもあり、情報にキャッチアップするためのフィード的な役割は果たしてくれているように思います

 

なのでダイソンプロジェクトは勉強会というよりはフィードとして延命していく事になりました。勉強会を企画するときは幅を優先するのか深さを優先するのか、事前に決めておくのが良さそうです

 

しかし「フィードだけじゃなくて、もっと深いところを学びたい!現場を経験している人ならではの知見に触れたい!」という欲求が抑えきれず、議論型勉強会が誕生しました

 

議論型勉強会の進め方

YESかNOで答えを出せるテーマを選ぶ(例:export defaultするべきか?)

参加者をペアに分ける

ペア同士で議論してもらい、YES/NOいずれかの立場を選んでもらう

・ペアを集めてグループを組んで議論してもらい、YES/NOいずれかの立場を選んでもらう

全員で議論して、YES/NOいずれかの立場を選んだら終了

・議論が白熱したら次回に持ち越し

 

特に「YES/NOで答えを出せるテーマを選ぶこと」と「まずペアに分けて議論すること」が特に重要だと考えています

 

 

なぜYES/NOで答えられる議題が大事なのか

YES/NOで答えを出せない問いを選んでしまうと(例:設計ってどこまで考えるべき?)「あぁそういう意見もあるよね〜」「それもいいよね〜」「それな」と、お互いの意見を全受容するだけの時間になってしまい、あまり対話が生まれません。最終的に「なんか分かった気がするけど、実際やってみたらわからん」状態に陥りがちです

 

強制的にYES/NOの結論を出す制限を設けることで意見が適度に対立し、細かな部分まで理解を深められるのではないかと考えました

 

例えば

・フォームコンポーネントを作った際、入力情報の状態はコンポーネントで持つべきか、上位層(ページなど)で持つべきか?

・フロントエンドのドメインロジックを切り出す際はクラスを使うべきか、関数を使うべきか?

 

みたいなテーマを用意して20分ぐらい議論していると適度に賛成と反対が分かれて、議論を通じて「なるほど、こういうケースだと確かに困るな」みたいな学びが得られます

 

 

 

なぜペアに分けるのが大事なのか

弊社は争いを好まない平和の民が多いので、血気盛んなサイヤ人が混じらない限り議論が発展しません。よしんば発展したとしても発言力の強い人が喋り続けてしまうので、できるだけ均等に発言の機会を与えたいと考えました

 

そこで参加者をペアに分けて

 

・まずペアで議論

・その後、各ペアが出した結論を元にグループで議論

 

というプロセスに分けることで一人当たりの発言時間を増やしました

 

議論型勉強会の評価

個人的には議論型勉強会は他の勉強会より学びが多いように感じていますが、まだ始めて日が浅いので効果検証中です

 

 

勉強会が過疎る理由

というわけでここまでの「勉強会が過疎る理由」を総括すると

 

・準備が大変

・内容に興味がない(レベルが合わない、必要性が低い)

・割れ窓が放置される

・知りたいところを深掘りできない

 

 

今後やってみること

これまでの反省を活かして、これからは以下のような施策を試そうとしています:

 

1)ISUCON、SECCON、ハッカソンなどの参加費用を負担

上記のように何らか手を動かしてアウトプットを伴うイベントに参加する場合は交通費・宿泊費・懇親会費用などを全額負担します

 

ISUCONで言うと過去問を動かすためにベンチマーカーにかかる費用とか、パフォーマンスチューニングに必要な知見を得るための技術書籍等の費用も全部会社が負担します。反省会(という名の暴飲暴食)で鉄板焼きとか食べたら、その費用も会社が負担します。

 

議論型勉強会から「自分の頭で意見を組み立てたり、手を動かしたときほど学びは定着しやすい」というポイントも学んだので、特に手を動かす勉強を積極的に支援したいと考えました

 

2)有識者クーポンの発行

有識者クーポンとは:一人当たり毎月1万円まで使えるお金の名前です。毎月上限1万円まで有識者に技術顧問として質疑応答してもらったり、出張講座を開催してもらうための費用として使えます

 

「データベースの仕組みをさらに詳しく知りたいけど、さすがに社内にはそこまで詳しい人がいない時にクーポンを使って(会社のお金で)データベースの専門家に教えを乞う」みたいな用途で使ってもらえたら嬉しいなと

 

「是非あの人に講師を頼みたいけど1万円だと引き受けてもらえない・・・」

 

そんな時は同じテーマに興味を持つ人を複数人集めてクーポンを組み合わせることで、より高額な報酬を有識者にお支払いできるようになります。なので10人が興味を持つ有識者なら10万円まで使えます(グルーポンみたい)

 

多くの社員が興味を持つテーマなら会社としても手厚く支援した方が良いと思うので、社員の興味が強い領域に自然とお金が使われる制度を考えてみました

 

制度の人気が出たら順次金額を上げていこうと思っています

 

3)技術書は輪読会に使う場合、全部会社負担

技術書の会社負担に関しては議論が紛糾しましたが、輪読会を通じた社員同士の交流に対してなら出費を惜しみたくないと考えて、複数人での輪読会に使用する場合は技術書の購入も全額会社負担にしました

 

というわけで社内のSlackで「この本を輪読したい人いませんか〜?」と募って、2名以上集まったら会社負担で購入してOK、という制度に落ち着きました

 

プラハには部活制度が存在しているので(社内の部活動に5000円まで費用補助する取り組み)輪読会も部活の一種と捉えられるかもしれませんね

 

 

結論:勉強会は難しい

プラハはエンジニアの採用時に「週末も個人的にコードを書いたり、勉強しているか」「ものづくりが好きか」といった点を重視しています

 

なので学習意欲に関しては総じて高いはずなのですが、そんな環境でも質の高い勉強会を維持することは困難でした

 

これからも色んな形式を試して最適化していきたい。そんな初春です

 

 

PR

「技術者として技量を高めたい」

プラハに興味がある」

 

そんな方がおりましたら、ぜひ一緒に働きませんか!

 

www.praha-inc.com