この記事は Wano Group Advent Calendar 2023 の10日目の記事となります。
この記事に書いていること
- 輪読会の一般的ないくつかの方法の紹介
- 実際に弊社で行った輪読会を具体的に紹介
- 実施してみてわかったことなど
輪読会
輪読会と一口に言ってもやり方は様々です。
実際に弊社で1年ほど前から行っている輪読会のやり方を、経緯を含めて紹介していこうと思います。
今現在も開催して良かったと非常に感じているので、これから輪読会を行おうと思っている方々の参考になれば幸いです。
輪読会の目的
個人的に輪読会の目的について重要だと思うことは以下です。
- チームへのアウトプットを前提とした継続的なインプット
- 技術を軸とした相互コミュニケーションの機会
- チーム内の認識をすり合わせでき、コードベースの一貫性につながる
同じ本を読んでいても人それぞれ理解の仕方は違います。
自分一人で読んでいたら気づかなかったことや理解できなかったことなどを人から教えてもらえる機会にもなります。
輪読会の形式
輪読会の形式について、大きく分けてこのようなパターンがあります。
1. 発表会方式
事前に読んで資料などを用意する担当を持ち回りなどで決め、当日スピーカーになって資料を発表する
Pros
- 担当以外は事前準備が必要ない
- 整理された資料なので本の内容を理解するのに効率がいい
Cons
- 担当をしたとしても負担が大きく、輪読会に対しマイナスのモチベーションになってしまいかねない
- ケース例
- カンファレンスなどでスピーカーになる予行練習を兼ねる
- 分量が多い本を選定している
2. ディスカッション方式
各自が事前にピックアップした疑問点や議題についてディスカッションをメインで行う
Pros
- 会の時間で本を読む時間を取られず、最もディスカッションに時間を割ける
Cons
- ある程度全メンバー事前に読んでくることが求められる
- ケース例
- ディスカッションをすることのウェイトが輪読会の目的として大きい
- 抽象度が高く解釈が異なりそうな本を選定している
3. 読書会方式
その場で本を読み進める
Pros
- 事前準備が不要
Cons
- ディスカッションの時間が不足しがち
- ケース例
- 本を読むこと自体のウェイトが輪読会の目的として大きい
- 難易度が高い本を選定している
実際にどう輪読会を進めたか
| # | 備考 | |
|---|---|---|
| 人数 | 3 ~ 6名ほど | 強制参加ではないので毎回人数が変動 |
| 時間 | 1時間 | 時間配分は本によって調整 |
| 方式 | 各自事前に読んでくることを推奨したディスカッション方式 or 読書会方式 | 読んでいなくても大丈夫なように工夫 |
現在進行形のものも含めて、これまで読み進めた本は以下の3冊です。
| # | 本 | 方式 |
|---|---|---|
| 第一回 | A Philosophy of Software Design | ディスカッション方式 |
| 第二回 | ［試して理解］Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識 | 読書会方式 |
| 第三回 | 単体テストの考え方/使い方 | 読書会 & ディスカッション方式 |
投票で決めたり、話し合って決めたりしてます。
第一回: A Philosophy of Software Design
ソフトウェア設計におけるベーシックな問題である複雑性の管理にフォーカスした本です。
具体的な進め方
週2回 リモート業務日 朝の1時間
| 内容 | 時間配分 |
|---|---|
| 事前に読んで気になった文章などをそれぞれ書きだす（下画像） | 10分 |
| 読んでいないメンバー向けにサマリーを共有 | 5分 |
| 書き出した内容について共有・ディスカッション | 45分 |
選定理由
- 本
- 世間の書評がよく複数メンバーが元々興味があった
- 翻訳本がないので個人では読み進めづらかった
- 分量が少ないので第一回に採用しやすかった
- 方式
- 抽象度がある程度高く、洋書なため解釈が別れそうだったのでディスカッションをメインに行いたかった
やってみて
- ディスカッション形式だと盛り上がり、シンプルに楽しい
- 洋書であることと頻度が週2と高いことで、少し事前に読むことが負担に感じる時も
- 洋書を難なく1冊読破できた
第二回: ［試して理解］Linuxのしくみ
Linux OSの仕組みが実験とその結果の図などを中心に解説されており、OSとハードウェアに関する仕組みについての本です。
具体的な進め方
週1回 終業前の1時間
| 内容 | 時間配分 |
|---|---|
| ファシリテーター中心に読み進める | 40分 |
| サーバーで実際に試す | 20分 |
選定理由
- 本
- エンジニアとしてOSについて理解することはとてもベーシックで重要である
- インフラ業務に関わるメンバーが偏っており、業務で学ぶ機会が少ないメンバーが多い
- 方式
- 本の内容的にディスカッションする余地がほとんどなく、勉強会的な側面が大きかった
やってみて
- 本の内容から派生して、実際に稼働しているサーバーで試すことでより理解しやすい
- 理解度が高いメンバーがファシリテートする必要があり、負担が偏る
- ディスカッションがないので、一方向のコミュニケーションになりがち
第三回: 単体テストの考え方/使い方
具体的な進め方
週1回 終業前の1時間
| 内容 | 時間配分 |
|---|---|
| ファシリテーター中心に読み進める | 40分 |
| 業務でどう活かせるかをディスカッション | 20分 |
選定理由
- 本
- チーム内でテストについての関心が高まっていた
- いくつかの候補の本を挙げた上で投票を行った
- 方式
- 特に大きな理由はなく、第二回の延長で行った
やってみて
- 業務に実際にどう活かせそうかを話すことで、アウトプットにつながりやすい
- テストとは という部分の認識を揃えることができた
- 全体で本を読み進めつつ事前に読んだ人が要点をかいつまんでいくといったように、発表会と読書会の間をとることで負担が軽減され、無理のない運営ができた
参加メンバーの声
1人目 Dさん
少なくとも参加者のうち誰か一人が該当箇所に対して事前に目を通していれば会が成立する形にした点は本当に良かったと思う。おかげで、1年間無理なく継続できた
2人目 Sさん
キーワードを参加者で共有して、ちょっとしたミームみたいな扱いにできる点が輪読会のいいところだと思います。
deep module とか red flag とか、何人かで単語を共通言語にすると定着度も高いというか。
3人目 Mさん
ジュニアレベルのメンバーとして参加しても、輪読会を通してシステム開発の知見と、各メンバーそれぞれの考え方を同時に吸収できる良い機会だと思います。
また、メンバー間で共通認識を持つことにより、「次実装するときは、このアイデアを使ってこうしてみよう」と次の行動に繋げやすい面もありました。
A Philosophy of Software Design はキャッチーなワードが多く、読んだその場でスタンプを作ってみんなではしゃいでいました。
最後に
輪読会で特に優れている点は、メンバーのレベルアップはもちろんチームとしての認識を相互のコミュニケーションを経た上で統一できる点であると思います。
また、個人的に A Philosophy of Software Design は様々ないい気づきをくれた本なので、輪読会関係なくおすすめです！
改めて、この記事が輪読会に興味ある方の後押しになればと思います。
現在、Wanoグループ / TuneCore Japan では人材募集をしています。興味のある方は下記を参照してください。
Wano | Wano Group JOBS
TuneCore Japan | TuneCore Japan JOBS