はじめに
こんにちは、虎の穴ラボ所属のFantiaでエンジニアをしているよしだです。
私の所属しているチームではここ数ヶ月でありがたいことに新しく参加するメンバーが多く、人数も倍になりました。
虎の穴ラボは複数年エンジニア経験のある中途採用のメンバーで構成されており、エンジニアのスキルは一定あるのですが経験してきた技術背景がバラバラであったり、そもそも参画したばかりのメンバーは改修経験の範囲が狭く、システム理解に差が出やすいです。その結果、要件や実装で認識がずれていたことによる手戻りで開発速度が落ちる課題がありました。
Fantia全体でも一ヶ月に一度勉強会を実施していますが、そちらでは直近あった大規模な開発をメインに取り扱っており、新規メンバーに焦点が当てられているわけではありません。
そこで主に新規のチームメンバーに対して利用技術やドメイン知識を共有するためにチーム内での定期的な勉強会を実施したので、どのように勉強会を設計・運営したかをご紹介します。
想定読者
本記事は次のような方を想定しており、何らかの参考になれば嬉しいです。
- チームで勉強会を始めたいと考えている方
- 新規メンバーが急激に増え、知識共有の仕組みに悩んでいる方
- 社内勉強会を始めてみたものの思ったように手応えを感じられていない方
社内勉強会で起きがちな課題と失敗パターン
エンジニアが社内勉強会を実施する際、以下のような課題が多くあるかと思います。
- モチベーション低下：扱うテーマの難易度が極端に易しい・難しい・自身には関係ないことで参加者のモチベーションが低い
- 時間の調整：業務の多忙に押され事前準備の時間が取れない・だんだんと参加者が減っていく・空中分解する
- 勉強会中の活気：発表者が一方的に発表するだけになってしまい、双方向のコミュニケーションになりにくい
こういったよくある課題には事前に手を打ち、参加者に満足してもらうための工夫をしたいと考えていました。
その上で特に参考になったのが、昨年読んだFearless Changeという書籍で紹介されているパターンです。勉強会を行うメリットはありつつも新しいことを始めるには困難が付きものであることはイメージできたので、書籍に出てきたパターンも上手く取り入れることを意識しました。
勉強会を設計する際に工夫したこと
上記で述べたような課題の対策として、チーム内勉強会の開催にあたって以下のような工夫を行いました。
アンケートで参加者の興味を数値化してテーマ選定する
利用している技術や、ドメイン知識（過去に全体の勉強会で取り扱ったものが中心）に関して、チームメンバーがどういった内容に興味があるのかをアンケートを実施しました。
多数決ではなく、他の勉強会で見かけたボルダルール（順位に応じて点数を配分する投票法）というスコアリングルールと、参加者が近い将来で開発するであろう内容を加味して扱うテーマを決めました。
一つのテーマに決めて数回に渡り掘り下げる形だとメンバーの興味と合わなかった時に方向修正しにくいので、一回で扱えそうなテーマを都度決めています。
チームのニーズに合わせたことにより*1、参加者からも満足できたとのフィードバックがありました。
内容はマスクしていますが、スプレッドシートで各自見える形でアンケートを取りました。
参加者との双方向性を重視する
発表は勉強会の半分ほどにとどめ、残りの時間は発表を聞きながらGoogleドキュメントにメモしてもらった質問・感想を議論したり発表内容と関連する過去の経験を話し合う時間に充てました。
フルリモートということもあり、聞き手がただ受け身になるのではなくより身近に感じてもらうようにしました。
既存資料を再利用しつつ、勉強会議事録もNotebookLMへ集約して後追い可能に
チーム内勉強会では事前準備のハードルを下げるため、過去資料を元に発表するようにし、ドキュメントには書ききれない画面操作やコンソール操作などは画面共有で実演もOKとしました。*2
勉強会で作成された各種ドキュメントをまとめてNotebookLMのソースとすることでチーム外のメンバーにもマインドマップや音声概要という形で共有できるようにしています。参考にした記事
- NotebookLMのソースに設定する資料
- 勉強会の発表資料
- Google Meetの文字起こし
- 質問・感想を記載したGoogleドキュメント
実際の進め方
毎回のおおまかな流れは次のような形でした。
- テーマ決定 2〜3回分を見越して、チームメンバーにアンケートを実施し、テーマを選定。
- 準備段階 発表者は既存の資料をベースに準備し、負担を最小化。
- 開催頻度 本業を圧迫しないように月2回、各1時間を目安に実施。
- 当日の進行 各回は30〜40分の発表、その後は質疑応答に時間を充てる。
- 終了後の共有 終了後、各資料をNotebookLMに投入。生成されたマインドマップや音声概要を添えてチーム内外に共有し、参加できなかったメンバーもキャッチアップしやすい形に。
勉強会で取り扱ったテーマ一覧
半数ほどは利用技術の話もありますが、一般的な話だけではなく自システムの特性や過去にあった障害も絡めて話されていました。
- ドメイン知識について（2回ほど）
- 生成AI関連のツールのTips共有
- 機械学習関連のAIについて
- 主にDB周りの負荷対策・パフォーマンスについて
- インフラについて
- 半年間のチームのふりかえり
勉強会の効果
勉強会後にいきなり生産性がn倍になるような即効性は無いので定量評価は難しいものの、参加者からのフィードバックから以下のような効果があったと考えています。
開発時のスムーズなキャッチアップ
一番多かったのは自身の改修では直接関係することのなかったコアドメインについて知ることができたという声でした。
システムの全体像が頭に入っていることで、エンハンス開発をする際も改修する箇所の勘所が掴めたり、リグレッションテスト時も何が現行の仕様なのかがスムーズにキャッチアップできるようになりました。
歴史的経緯やコンテキストの共有
新規メンバーはシステムの現在の断面を中心に考えますが、既存メンバーからすると複雑な箇所の設計の経緯や障害に繋がった落とし穴など見えない部分は多くあります。
議論の焦点となるポイントを事前に勉強会の場で共有・共同化することによりコードレビューやテストの際にいきなりダメ出しをされた、というような摩擦を減らせると考えています。
コミュニケーションの活性化や気付き
テーマのアンケートをお互いが見える形式で取ったことで、チームメンバーの興味関心があることをメンバー同士が知れたり、経験のあるエンジニアにとっては当たり前のように意識しているポイントが実は皆曖昧なまま開発しているんだなという気付きに繋がったような場面も見受けられました。
フルリモートでは率直に話すことがないことも勉強会を通じて共有できたのが良かったかなと感じています。
おわりに
生成AIのおかげでアウトプットのスピードは格段に上がりました。しかし、暗黙知をチーム内で共有すること（共同化）や、形式知を自分ごととして身につけること（内面化）は、AIが自動でやってくれるものではありません。
今回の勉強会は、人にしかできない部分にあえてフォーカスした場だったように思います。 AI時代だからこそ、こうした「チームでの学びのプロセス」も継続していきたいと感じました。
Fantia開発採用情報
虎の穴ラボでは現在、一緒にFantiaを開発していく仲間を積極募集中です！
多くのユーザーに使っていただけるtoCサービスの開発をやってみたい方は、ぜひ弊社の採用情報をご覧ください。
toranoana-lab.co.jp
