#railsdm で @netwillnet さんに聞きたかったのだけど、タイミングがあわなかったのですが…。
— Hiroki OHTSUKA (@HIROCASTER) 2018年7月17日
輪読会をどういう風にやってるのか。とかコツとか苦労話とかブログにまとめられてたりしないのだろううか。
ということで、僕が色んな会社でやっている社内読書会(輪読会)についてまとめます。
社内読書会の流れ
Rails Developers Meetup Day3で話したように、複数のお手伝い先で社内読書会をファシリテートしています。今となっては技術顧問業の一環としてやっていますが、顧問業を始める前から、お手伝い先での社内読書会を頻繁に開催していました。
その時々で多少違いますが、次のような流れで本を読み進めていくことが多いです。
- 出席者の誰か一人が声に出して内容を読む
- キリの良いところで止めて、みんなで感想を話したり質問をしたりする
- 1に戻る
出席者の誰か一人が声に出して内容を読む
基本的に予習の必要がない形式で、その場で読み進める形でやっています。なので、一冊の本を読み終わるまでにかなりの時間がかかります。
参考までに実例を上げておくと、いまメドピアさんで週に1回、1時間づつ読んでいるプロを目指す人のためのRuby入門は4~5ヶ月くらいで読了しそうな雰囲気です(4月から読み始めて今月読み終わりそう)。
予習前提で感想だけ話し合う形式にすればもっと短期間でたくさんの本を読むことができますが、それだと参加者によっては予習が追いつかず、十分な学びを得られないひとが出てくるだろう、と判断してこのようなやり方でやっています。参加者が少人数で予習をやってこれそうな状況であれば、予習前提でやるのが良いと思います。
別の進め方として「本の章ごとに担当者を決め、担当者が内容を要約したものを共有し、共有したものについてみんなで話し合う」形式もあります。実際にEveryday Railsという書籍を読むときにやってみました。この書籍はRSpecについて書かれた本で、参加者は全員すでに業務でRSpecを使っているので、全部音読するよりは要点を共有したほうが効率が良いのでは?と考えたためです。
やってみた感想としては「決して悪くはないが、音読形式でも良かったかもしれない」でした。各自担当している箇所についてはそれぞれ学びがあったようですが、担当外の箇所については興味が薄くなりがちで、短い期間で読み終わるメリットとのトレードオフがある印象です。
キリの良いところで止めて、みんなで感想を話したり質問をしたりする
ここが読書会の肝です。読んでいて疑問に思ったところの解消だけでなく、単純に感じたことを共有することを奨励しています。会話をすることで淡々と読んでいくよりも記憶に残るはずだし、場合によっていはよい方向に話が発散することもあります。
あとは例えば読んでいるのがRuby関連の書籍で、あるRubyの機能が紹介されていたとすると、
- お仕事でこの機能を使うことがあるか?
- あるとしたらどういうとき?
- ないとしたらなぜ使われないのか?
- 社内のプロダクトでこの機能を使っているところがあるか?
- 今後適用したほうが良い箇所があるか?
などはみんな気になるところなので、積極的に話題にしています。
社内読書会の課題
社内読書会は楽しくて勉強になるので是非ともお勧めしたいのですが、とりあえずでやってみると「これ難しいな…」とか「思ったよりうまくいかないな…」となるケースがあります。
その中で大きい課題は
- 題材の選定
- 参加率の維持
の二点です。
題材の選定
参加者の人数やレベル感によりますが、社内のエンジニア全員を対象にした読書会の場合、シニアエンジニアとジュニアエンジニアが混在する形になります。このとき全員に適した書籍を決めるのはとても難しいです。
エンジニアのレベルごとに別の読書会にしてしまうのも一つの手かな、と思ってはいますがまだ実施したことはありません。
また、僕がやっているような週1、1時間くらいのペースで実施する場合は、「以前読んだ章の内容を忘れがち」というのも課題の一つです。本の途中で、「以前のn章で書かれていた内容は実はこういうことで…」のように書かれていても、それが数ヶ月前の内容だと「n章 で書かれていた内容ってなんだっけ?」となります。週1など、ある程度間隔をあけて進める場合は、1章ごとに内容が独立している書籍の方が向いていると言えます*1。
あとは会社の業務時間内に実施できるかどうか、というのも題材に影響します。業務時間内に実施するのであれば、なるべく直近の業務に関係する内容が求められる可能性があります。業務外であれば自由に選定することができるはずです(その代わり書籍を自費で購入することになるでしょうが)。
参加率の維持
業務時間内に業務として読書会を開催した場合、社内のほぼすべてのエンジニアが読書会の参加対象になることでしょう。しかし、毎回全員が参加できるようなケースはめったにありません。業務が忙しくて欠席したり、会社を休んで欠席するということはよくあります。ただこれが続くと、読書会に参加しないことが普通になってしまい、回を重ねるごとにだんだんと参加者が減っていくことになります。先ほど書いたような「以前書いた内容を参照することの多い書籍」が題材だと、休めば休むほど次回参加のハードルが上がるため、復帰しにくくなってしまいます。
今のところ、この課題の対策としての有効な手は打てていません。読書会に出席できないほど忙しい業務を減らしていくしかないのかな、と思います。
また、業務時間外に読書会を開催する場合はさらに気を使う必要があります。なるべく大勢に参加してほしい場合は、各章独立しているタイプの書籍の方が望ましいでしょう。また、業務開始前に読書会を実施したこともありますが、朝の強い人以外は継続して参加できませんでしたね…
まとめ
僕のやっている読書会の内容と課題について紹介しました。楽しくて勉強になるので、まだやったことのない人はぜひ一度試してみてください。
*1:とはいえ、それでも読みたい!という本はたくさんあるのでそういう時は覚悟を決めて読んでいきます