✏️

チーム内での共有会のやり方を検証してみた

2024/04/03に公開

今回の概要

弊社のフロントエンドチームで開催している共有会だが、近年では報告会に似た形で開催されており、発表者からの発言のみでチーム内での質疑応答等もあまりなく、コミュニケーションも希薄となってきている。

そこから発表内容に対して以下意見があると想定した。

  • 「自分のレベルにあわず難しく質問するのが恥ずかしい。」
  • 「この分野にはあまり興味がないためあまり聞けていなかった。」
  • 「新入社員でチーム内の空気感がわからず質問がしにくい。」

ただ、トレンドの移り変わりが激しく、技術分野が幅広いフロントエンドに所属しているからには他分野に目を向けず、チーム内でのコミュニケーションが希薄となっていくことはチーム内での技術衰退および組織としての結束力低下から業務パフォーマンス低下が考えられた。

そこで今回は共有会のやり方を今までと変更し、上記問題を解消できるかを検証した。

新規パターンの概要

新しい共有会の内容としては以下。

進め方

  • 用いるフレームワークはSveltekit。(マサカリを防ぐため弊社で馴染みのない言語)
  • ハンズオン内容はTodoリストの作成。(事前に用意したServerMiddleのAPIに対してGET,POST,PUTをするもの)
  • 実際に完成物を作成してそこから実際にハンズオンで使用するものまで削ぎ落とす。
  • LiveShareを使用し、自分の開発環境を用いるため環境構築は不要。

ハンズオン参加者のレベル感

4名のレベル感内訳。
ハンズオン参加者が同じレベル感になるようにも調整。

レベル感 人数
実際にSvelteを使って何かしらを作成したことがある 2名
Svelteを触ったことがない 2名

検証方法

下記①と②の手法からそれぞれの観点で比較し、効果を検証。

①新規パターン

項目 内容
参加者人数 ハンズオンメンバー:4名 オブザーバー:任意参加
時間 2.5~3時間
形式
ハンズオン形式(LiveShareにて行うため環境構築は不要)

「詳細」

  • 極力ハンズオンメンバーから質問がメイン、オブザーバーからの質問は共有会終了後にあれば受ける。

②既存パターン

項目 内容
参加者人数 全員
時間 0.5~1時間
形式
報告会形式(最後に質疑応答)

新規パターンを用いることで解消できると思った点

  • ハンズオンのためチーム内の雰囲気にのまれずに新入社員でも質問ができる。
  • 少人数に絞ることによるコミュニケーションの活性化。
  • 題目に興味がある人をハンズオンに参加していただき、そこまでの方にはオブザーバーに参加していただき、それぞれのレベルに合わせた参加ができる。(イメージ以下)
ハンズオン参加者:興味はあったが触る機会なく、何からはじめて良いのかわからないレベル感
オブザーバー:聞いたこともないためまずどのようなものかを見たいレベル感

検証結果

実際にチーム内で開催した。
チーム内でのアンケートをとりその結果を踏まえた検証結果を以下観点から記載する。

  1. 参加者の理解度
  2. 開催者のコスト
  3. コミュニケーション頻度

1.参加者の理解度

結論新規パターンの方が参加者とオブサーバーとで理解度の二極化になってはしまった。
しかし、仮定でも挙げた通り新規パターンはそれぞれのレベル感に合わせた勉強会を想定したため予想通りのものとなった。

ただ、ハンズオン参加者にとっては既存パターンよりは深く理解してもらえ、オブザーバーにとっては実際に手を動かし疑問点問題点を目にすることで実践に近い形で体験できたかと考えられる。

理解度の分類分け

  • 理解度3:できた
  • 理解度2:まあまあ
  • 理解度1:興味が出ててきた

①新規パターン

パターン 理解度3 理解度2 理解度1
ハンズオン参加者 2名 1名 0
オブザーバー 1名 0 2名
合算 3名 1名 2名

②既存パターン

パターン 理解度3 理解度2 理解度1
合算 4名 3名 2名

開催者のコスト

新規パターンの方コストしては少なくとも3倍~4倍へと膨れあった。
しかし一度用意してしまえば複数回開催できる点および開催時間事態も3倍ほどなので費用対効果としては悪くない。
ただ連続での開催は共有会として偏りが生じるため要検討。

パターン かかった時間 内訳
新規パターン 7時間 完成品、使用するもの作成:5時間
ドキュメントおよび手順の作成:1.5時間
環境整備などハンズオンメンバーとの疎通:0.5時間
既存パターン 1.5~2時間 共有資料作成:1.5~2時間

コミュニケーション頻度

新規パターンの方が質問等が多く、ハンズオン参加者からは全員からコミュニケーション頻度は適切だったとの声があがった。
またハンズオン参加者からの質問が積極的にあり、今回の範囲と外れた部分の話にも展開しあいまいな理解の見直しにも活用できた。

既存パターンは話だけのため、実際の問題に直面することがなく、質問まで発展できない可能性があったのではと考えられる。

結論

今回の新規パターンのメリット大きく続けいく価値あり。
その場合以下は改善の余地あり。

改善点

  • ハンズオン参加者の固定化の懸念
  • 理解度による二極化
  • 開催者のコストおよび1内容の長さへの懸念

改善点における対策

ハンズオン参加者の固定化の懸念

JS、CSS、HTML、デザインのメイン担当者みたいなものを決めて担当者基準でハンズオンメンバーを募り開催。

理解度による二極化

個人的見解だが必要最低限の知識は必要としてもJSが苦手な方に対してJSを強要する気はない。そのためある程度の二極化は目をつむるほかない。だが上でも述べた通りそれぞれの開催者の得意分野で役回り性で開催し各分野の必要最低限のレベル感をこれで上げていきたい。

開催者のコストおよび内容の長さへの懸念

成果物をしっかりと作成でなく、公式ドキュメントのものを一、二個拾って開催でも対応可能かと思われる。
それにより開催時間の短縮と開催者のコストを削減できる。

Discussion