勉強会のつくりかた

株式会社ACCESS フロントエンド事業部
主任 松木 晋祐

【講師として】

　なぜ「勉強会」を開催するのが「学ぶ」事に繋がるのか？疑問に思われる方も多いと思います。

　ふつう、学んだ後に催すものではないのか。

　実は「勉強会」でいちばん「勉強」になるのは講師です。まず、多くの人の前で自分の考えや、その場にいる全員の貴重な時間を使って達成したいことを明確にしなければなりません。次に、講義の途中でなぜこれを教えているのか、どうしてこういう教え方になるのか、を論理的に説明できなければならず、最後に、受講者の素朴な、思いがけない質問に回答できるだけの一段上位の理解と考察を、前もって準備しておく必要があります。これだけの要件を、明確に示された日時までに満たすための「学び」は特に効率面において他のどんな方法にも勝るのではないかと私は考えます。

　一点、この「学び」に失敗すると参加してくれた方に多大な迷惑を掛けてしまう点において非常にリスキーな方法ではあります。しかし、成功すれば自分自身の学びと参加者への知識の伝達という大きなリターンを達成できます。ただ、経験的に、期限とゴールと参加してくださる方々が具体的にイメージできる状況で「学び」に失敗する事などそうそう有りません。一見ハイリスク・ハイリターンのように読めますが、リスクの方はほぼ100％自分でコントロールできる種のものです。今回は通り一遍のリスクをコントロールできると確信できたのでさらに、私がこういうセミナーが欲しい！と常々考えていた形式にトライしてみました。要件は以下のとおり。

　(1)ワークショップ形式であること/参加者が具体的な成果物を持ち帰れること
　(2)講師と参加者が一緒にリアルタイムで成果物を作り上げていくこと
　(3)参加にあたって条件となる開発技術経験のハードルは極限まで下げること

　開発入門講座ですので、成果物は実際に動作するアプリケーションになります。最初に講義、次にライブコーディングでそれを実演、参加者がそれに倣う、という形式で、通常想定される数倍のチェックポイントを設けることで講師も含めた参加者全員が同期をとりながら一歩一歩進めるような形を目指しました。実際にはこの参加者全員が同期を取る、というのはとても困難である事が容易に想像できましたので、講師の他に躓いた参加者をフォローして頂く補助の講師に数名ご参加頂きました(宮田さん、津田さん、渡辺さん、加藤さん、東さん、早川さんに感謝です。また、前述の参加者からの思いがけない質問に私が対応できないときも、左記の方々に助け舟を出していただきました)。ワークショップ形式では必ずつまずく方がランダムに発生しますので、ここのフォローアップをどう設計するかが非常に重要なポイントとなります。全員止めてその間に雑学や細かい部分の解説で場を繋ぐ、とりあえず先に進んで次のチェックポイントまでに補助の講師にお任せで追いついてもらう、などの手法があります。

　社内外を問わず、私が講師として何か技術やノウハウを伝えるときに特に気を付けている点として、

　(1)その技術やノウハウで何が/誰が、なぜ嬉しいのか？を論理的に伝える
　(2)今何をやっているのか、全体の中のどんな位置にいるのかを本当にしつこく、くどく伝える
　(3)世の中の8割の人が同意してくれるレベルで簡略化する。2割の嘘はいとわない

　があります。特に (2) は有識者や他の講師の方からすれば本当にくどいので、同席されると眉をひそめられるかも知れませんが、私自身がおよそ有史以来最も鈍い「勉強会」参加者であった経緯からして、こと「わかりやすさ」というパラメータを重視するにはこの方法が最適と信じています。当日はこの講義スタイルでトレードオフになる「スピード」を考慮のうえ、7時間というかなり余裕を持ったタイムテーブルを組みました。結果としては何とかギリギリある問題を解決できる最低限のアプリケーションまでは全員たどり着く事が出来ましたが、想定していたゴールの60%の位置で時間切れとなってしまいました。残り40%がとても楽しい部分だっただけに本当に悔やまれます。次回で必ず挽回したいと思います。ゴールインできていないので明らかな失敗なのですが、散会後に数名の参加者の方から「わかりやすさ」について評価頂けたのは嬉しかったです。