本日のメニューはこちら

社内勉強会について、

準備に時間をかけたけど、ノウハウの定着につながっていない
スライドを眺めるだけで、言いたいことが言えなかった

そんな風に感じたことはありませんか？

この記事では「有益な勉強会を開くにはどうすればいいんだろう？」という視点で僕が試してみたことを書いています。

「ちょっと面白そう？」と思った方は、ぜひ覗いて行ってください。

こんにちは。秋田県のIT企業、北日本コンピューターサービスのR&Dチーム「AUL（アウル）」に所属しています。トラフクロウです。

R&Dに求められる役割の１つに、新しい技術の検証があります。
日々の業務を通じてノウハウは溜まっていくのですが、それを社内に浸透させるのがなかなかうまくいかないというのが目下の悩みです。

従来は講義形式の勉強会を開いたり、資料を展開したりして発信してきました。
しかし正直なところ、それで社内に定着したという手応えはありません。

もっと広くノウハウを伝播させる方法はないものか？それが今回の出発点です。

そもそも勉強会を主催するのってタイヘンですよね？
時間をかけてこだわりの資料を作り、当日は一生懸命プレゼンをして、それでも「何か質問ありますか？」でしーんとなる。
自分の時間を溶かすだけならまだしも、参加者の時間まで浪費してしまうのはあまりに忍びない。

そこで、自分の負担を減らしつつ参加者への影響を最大化できないかと考えついたのが資料を用意しないディスカッション形式の勉強会でした。

先日この形式で社内勉強会を開催してみたので、今回は「資料を作らないで勉強会を開催したらどうなったのか」について結果や気づきをまとめていこうと思います。
ちなみに題材は、現在社内でホットな「AIを使ったコーディング（AI駆動開発）」についてです。

「参加するだけ」の勉強会に時間を使いたくない

僕が勉強会を開催または参加するうえで、「これはやりたくないな」、「こんな勉強会は嫌だな」と思うものは次の通りです。

① 事前の資料作成に時間がかかる

② 参加したけど質問したいタイミングで質問できない

③ 用意された資料をその場で読み解く（しんどい）

④ 勉強会の前と後でなにも変化が感じられない（やってよかった、参加してよかったがない）

⑤ 講師から言われたことにモクモクと従うだけ（自力で再現できる感じがしない）

これらを払拭した「参加してよかった」と思える勉強会とはどんなものでしょうか？

定期テスト対策みたいな勉強会が理想的？

少ない準備でスッと始めることができて参加者全員にメリットがある勉強会、これって実は学生の頃にやっていた定期テスト対策の勉強会がそうなのでは？と思いました。

みなさんも友達同士で集まってノートを見せあったり、教えあったりした経験はありませんか？

分からない人は知っている人から教えてもらえる、知っている人は教えることで頭の中を整理できる。 まさに参加者がみんなハッピーな勉強会です。

さらに、テスト勉強なら堅苦しい資料を事前に用意する必要がありません。
「いついつに勉強会しようよ」だけで済みます。後は流れでワイワイ進めていけばOKです。

このような、参加者が主体となって没入できる勉強会を社内で開けないものかと思いました。

実際にやったこと

テスト前の勉強会が成立する理由の１つは、参加者それぞれが「ここが分からない」と気兼ねなく話すことできるからだと思います。

そこで次の目的を置きました。

参加者が自分の疑問を発信して、他者の考えを受け取り、思考を動かせるようにする

受け身にならず、自分に足りない情報を自分で取りに行ける環境をつくる。

勉強会のテーマは、社内で盛り上がりつつある「AI駆動開発」です。

現在社内ではプロジェクトによってAIの使いかたはマチマチです。
今後AIを使った開発は業界のスタンダードになるでしょうし、それに向けた情報共有の土台を作りたいと思いこのテーマをチョイスしました。

実際にやった準備は次の3つです。

① 事前に「疑問点」を集める

資料を作らない代わりに参加者の疑問点を用意することにしました。
社内の掲示板で2〜3週間で募集をかけて疑問を集めました。

📕 募集内容

お疲れ様です。

最近社内でもちらほらClaudeCodeなどの生成AIを使ったコーディングを行うプロジェクトが出てきました。
一方で、他の人が普段どのように生成AIを活用しているかは見聞きする機会は少ないと思います。

そこで、Claude Codeを中心に、生成AIを使った開発の知見や悩みを共有する
勉強会を開催します。

Claude Codeをすでに使っている方はもちろん、
「最近使い始めた」「まだ使っていないけど興味がある」という方も歓迎です。

当日は一方的な講義形式ではなく、参加者から事前に聞いた気になるトピックを中心に、
普段の使い方や困っていることなどを参加者でヤイヤイ共有しながら進める予定です。

日頃AIを使ってコーディングを行う中で
「こんなときどうすればいいの？」
「こんなとき他の人はどうしているんだろう？」
と思うことがあればコメントで教えてください。

気になる人が多いトピックを勉強会で取り上げます。

ちなみに、集まったトピックはこちらです。

agentやskills、commandsの扱いと育て方は？
トークン節約方法は？
生成されたもののレビューってどうやってる？
プロンプトは一回で全部投げるべき？段階的に投げるべき？
どのタイミングでローカルの資産をGitに上げていますか？
モデル選択やエフォートの設定をどうしていますか？
AI駆動開発をしてもいい人の基準をどう設け、どう判断するか？
手法が複数あるとき、どんな観点で採用可否を判断すべきか？
これからAIを使った開発を始めるなら、何から勉強すればよいか？

参加者から話題を募集することで、ニーズに沿ったコンテンツを提供できたような気がします。

② 集まった質問を3つに束ねる

届いた９件を眺めて３つのトピックに分類しました。

人間が瞬時に記憶できる対象はせいぜい $4 \pm 1$ 個と言われています（マジカルナンバー）。
今回はトピックが９個と多かったので、大きく３つに分類して見通しを立てやすくしたわけです。

トピック１：AIにどう仕事を頼むか
トピック２：AIが作ったものをどうレビューするか
トピック３：AI前提で開発のやり方をどう変えるか

当日の流れは「オープニング → トピック1〜3 → クロージング」で、所要時間は2時間としました。

③ Teamsの会議メモを共同ノートにする

今回の勉強会には遠隔地からリモートで参加される方もいたので、Microsoft Teams で実施しました。

初めて知ったのですが Teams には参加者で同一のドキュメントを編集できる会議のメモ機能があるんですね。

💻 Teamsのメモ機能

Teamsのスケジュールから会議を設定してダブルクリックで開きます。

「予定一覧を通知する」からメモを追加できます。

会議で参加者に見せたい内容を書き込みます。

会議に参加すると登録したメモがデフォルトで表示されるようになっています（メニューバーからも開けます）。

みんなで１つのワークスペースに書き込みができたら没入感が出るかも？と思って目的やトピックを事前に書いておきました。
テスト勉強でいうところの、みんなで覗き込むノートですね（↓が現物です）。

【テーマ】
生成AIの登場によって我々の仕事が変化しつつある中で、
これからエンジニアとしてどのように振る舞うべきかを考える

【テーマをクリアするために】
・AIで何ができるのかを知る
・みんなの使い方・悩み・疑問を持ち寄る
・AIに何をどう頼めばよいか、具体的な使い方を考える
・自分たちのプロジェクトにどう取り入れられるかを考える

※本日、トラフクロウは資料を作っておりません。みんなで頭を使いましょう。
※全員の知識を底上げし、発展させるために不明点や疑問は積極的に提示してください。
※自分のやり方で確立しているものがある場合は、ぜひそれを全体に共有してください。
※分からないことは、その場で調べちゃいましょう（AIの使いどころでは？）
※発言がしんどい場合はチャットに書き込んでください
　（話しかけられたくない人はカメラをOffにしてください）

- トピック１：AIにどう仕事を頼むか
- トピック２：AIが作ったものをどうレビューするか
- トピック３：AI前提で開発のやり方をどう変えるか

事前準備はこれだけです。かかった時間は20分程度でした（資料作るよりずっと楽）。

今回はTeamsでしたが共同編集できるメモならなんでも構いません。
全員で見れて、その場で編集できる場所を用意できればOK。

勉強会ではファシリテーターに徹する

当日は進行役に徹していました。いかに参加者が主体といっても、目的を意識したうえで舵を取る人がいないと勉強会（というか会議全般）は瓦解します。

ファシリテーションで意識したことは次の通りです。

すでにAIを使っていそうな人を指名して積極的に話してもらう（一度誰かが話せば、場はなごむ）
相手の発言を自分の言葉で言い直して「こういうことですよね？」と確認する
「なぜそう思ったのか」を掘って、広げられそうな話を次の話題につなげる
間が空いたら、自分の経験談を差し込む
時間内に終えられるように残り時間と残りの話題、その場の論点を意識する

ここで、「意外とコレいいな」と思った魔法の言葉を紹介します。

「これ、僕もわかってないんですよね。知ってる人います？」

「知っている人よろしく！」と話題を投げることで他の人の発言機会になることに気づきました。
そしてその人の発言に他の人が反応することで場の空気が盛り上がっていきました。
知っている人がいないときは時間を区切って各自で調べる時間にするのもいいかもしれません。

そしてなにより 「勉強会の主催者は誰よりも詳しくあるべき」という重圧から解放されたような気がしました。

なお、今回の勉強会では資料は作らなかったものの、画面共有はたくさん行いました。
業務で使っているプロジェクトのフォルダや CLAUDE.md を話の流れで開いて見せた形です。
資料の代わりに実物を見せるとライブ感が出るので、これもいい方法かもなと思いました。

準備20分、資料なしでも勉強会はちゃんと成立した

資料なしで勉強会を行ったらグダグダになって収拾がつかなくなるのでは？とハカハカしていましたが意外とちゃんと形になりました。

また、次のような嬉しい発見もありました。

参加者からのポジティブフィードバック

参加者からはこんな声をいただきました。

「ディスカッション形式の会は新鮮」
「口に出して議論することで頭が整理できる」
「知見を共有する場がないので、貴重な機会だった」
「試行錯誤しているのは自分だけではなかった」
「あえて資料がないことで、言いたいときに話せた」
「メモ機能でリアルタイムに情報共有・整理ができたのが良かった」

特にうれしかったのは4つ目です。
新しい技術ってみんな手探りなのに、なぜか「自分だけ遅れているのでは」と不安になりますよね。その不安が、他の人の試行錯誤を聞くことでほぐれるというのは今回の勉強会の形態ならではだと思います。

参加者の「思考が動いた瞬間」を見つけた

「プロンプトは一括で投げるか、段階的に投げるか」を話していたとき、
参加者の１人が「Claude CodeにはPlanモードというのがあって～」と紹介してくれました。

すると別の参加者から

「Planモードのときだけ Opus、実装のときは Sonnet に自動で切り替えるってできるんですか？」

という発言がありました。

とても小さい素朴な問いですが、
人の話を聞いて、頭を動かして、疑問を見つけて、その場で口に出した
という僕の狙いが形になった瞬間だと思います。

こういう場面が勉強会を通して何度もありました。
予定していた枠から話が膨らむのを許せる のが資料を用意しない勉強会の利点かもしれないなと思いました。

とはいえ、まだまだ改善の余地はありです

もちろん、いいことばかりではありませんでした。今回の勉強会を通して感じた反省点を下にまとめています。

参加人数が多すぎた
20人規模は、リモート参加者が混ざると厳しかったです。
全員が満足に議論できるのはせいぜい5〜8人だと感じました。それ以上ならグループ分けなどの工夫が必要そうです。

ファシリテーションが大変だった
聞いて、整理して、メモを書いて、話を振って、時間を気にして、を一人でやるのは大変でした。
可能であれば主催側を複数人にするか、参加者にその場で協力をお願いして役割分担をするのがいいなと思いました。

「その場で調べる」ができなかった
２時間もあるから余裕でしょと思っていたのですが、意外と１つ１つのトピックに割ける時間はあまり多くはありませんでした。
誰も答えを知らない疑問などは、その場で調べても面白そうとは思ったのですが、これは次の機会に挑戦です。

テーマが広すぎた
「AIを使ったコーディング」というテーマは範囲が広く、参加者のレベル差が出すぎたように感じます。
「すでに使っている人向け」「これから始める人向け」のように対象者を絞った方が、議論は鋭くなり、収束もしやすくなるだろうなと思いました。

「明日からの行動」までは届かなかった
これが一番の反省です。この勉強会のあと、目に見える変化は起きていません（少なくとも僕の目には）。
場としては成立したものの、次の行動を設計するところまではできませんでした。
一緒に開発の伴走をする、セットアップやキックオフになる次の勉強会を誘発するなどの工夫が必要だなと思いました。

もともとの目的だった「R&Dに溜まったノウハウを社内に伝播させる」という意味では、まだ道半ばですね。

そもそも、この形式が向かない勉強会もある

実際にやってみて、この形式の向き、不向きも少し分かったような気がします。

今回のように「参加者が主体的に考えることが目的の勉強会」には向いていそうです。

一方で、「全員の状態を揃えることが目的の勉強会」 には向かないような気がします。
ツールの操作説明や全員で同じ成果物を作るハンズオン研修などは難しそうです。

特に 「参加者に確実にこれをやってほしい」がガチガチに決まっている勉強会には向きません（断言します）。
手順の共有や規程の周知が目的なら、資料ありで講義形式の方がいいと思います。

現状シックリくる「資料を作る、作らない」の基準は、「参加者があとで内容を再現する（思い出す）必要があるか否か」です。
常時使うことになるサービスの説明や他人からのフィードバックが必要になる資料であれば、後から動作の再現や、思い出しが必要になるため資料を用意した方がいいかもしれません。

最後まで読んでいただきありがとうございました！

最後まで読み進めていただき、ありがとうございました！

最近、勉強会やその他のイベントで人前に出て話をする機会が増えてきており、如何にすれば参加者にとって有意義な時間を作れるのかを考えることが多くなっています。

というのも、時間をかけて資料を作り込んだ勉強会ほど終わったあとに「あれだけ頑張ったのに、何か変わったんだろうか？」とゲンナリすることが多かったからです。

そこで立てた仮説が、「いっそのこと資料をなくしてみたらどうだろうか？」でした。
そしてやってみた結果、少なくとも「資料がなくても学びの場は成立する」ということは確かめられたと思います。

とはいえ、今回うまくいったのは参加者のみなさんが積極的に発言してくださったからだと思います（ご参加いただいた皆さん、ありがとうございました！）。
誰でも口を開きたくなる場をどう作るかは、今後の宿題ですね。

誰かの疑問が、いつの間にか全員の学びになっている。 そんな場を作れるように今回の教訓を踏まえて、さらによい形を探っていきたいと思います。