株式会社プラハエンジニアの村上です。
社内で技術書の輪読会を毎朝実施したところ、とても捗ったので共有します。
TL;DR
- 毎朝ちょっとずつ読み進める輪読会は、いい
- A Philosophy of Software Designは、いい
弊社代表（輪読会参加者）が、podcastで同じことを話しているので、耳で聞きたい方はこちらからどうぞ。
きっかけ
A Philosophy of Software Designを読みたいと思ったのがきっかけです。本書はまだ日本語版が出版されておらず、英語を日本語に翻訳しながら内容を理解する必要がありました。英語の本をひとりで挫折せずに読み切る自信がなく、輪読会を開催することにしました。
しかし、輪読会を実施したところで、本を読み切る前に参加者のモチベーションが低下してしまい、輪読会が継続できなくなってしまう可能性もあります。モチベーション低下の原因として、以下のようなものが考えられます。
- 毎回の準備が大変
- 一度欠席すると、キャッチアップが大変で復帰しづらい
- 開催のスパンが長いと、本への関心が薄れてしまいがち
前述の通り今回読みたい本は英語の本であるため、これらの問題に引っかかる可能性が日本語の本を読むよりもさらに高そうです。
そこで、これらの問題を回避するために毎朝輪読会を考案し、実践してみました。
毎朝輪読会
毎朝輪読会とは、その名の通り毎朝実施される形式の輪読会です。
実施形式
毎朝輪読会では、毎日少しずつ本を読み進める形式で本を輪読します。
- 毎朝決まった時間に短い時間（15〜30分くらい）で実施する
- 短時間で翻訳・要約が用意できるペース（1節ずつ、1ページずつ、など）で輪読を進める
少しずつ読み進めるため、毎回の準備が少なくて済みます。欠席した場合のキャッチアップも少しで済みます。また、毎日開催されるので、本への関心が薄れる問題も回避できそうです。
朝実施する理由は、業務ミーティングなどによる欠席を回避するためです。朝会やデイリースクラムよりも前の時間に設定するとよいと思います。
準備すること
輪読会をスムーズに進行させるために、読書範囲の要約を用意します。
- 要約担当を日替わりで決め、担当者は輪読会が始まるまでに担当範囲の要約を用意しておく
- 要約担当じゃない人も、可能な限り読書範囲に目を通しておく
ここで用意する要約は、プレーンテキストのかんたんなもの（手間がかからないもの）がよいです。
今回の輪読会ではzennのスクラップ機能を利用しました。主催者である私がスクラップを用意し、要約担当者に読書範囲1回につきコメントを1つ用意してもらいました。
輪読会当日にやること
輪読会当日は、全員が読書範囲に目を通している前提で、内容についてみんなで語ります。
- まず5分ほど時間をとり、要約担当が用意した要約を全員で黙読する
- 全員の黙読が完了したら、読書範囲の内容について語る
- 最後に次回の読書範囲と要約担当を決め、終了
原則、全員が読書範囲に目を通している前提ですが、どうしても時間が取れなくて読めなかったという場合もあるため、最初に5分間要約を黙読する時間を設けています。
黙読したあと、参加者で自由に語ります。内容がよくわからなかった、実務で同じ経験したことある、要約の内容が自分の解釈と違う、などなどたくさん語りポイントがあるはずです。私達の輪読会では、語りの中で有益そうな意見や疑問があった場合、スクラップのコメントに返信をつけて記録に残したりしてみました。
スクラップでのやりとり
やってみてどうだったか
英語の本を読むために考えて実施した形式の輪読会でしたが、日本語の本を読むのもこの形式でやるとよさそうに感じました。
👍 準備が楽・関心が薄れないので楽に続けられた
少しずつ読み進めるため、毎回の準備が少なくて済みます。欠席した場合のキャッチアップも少しで済みます。また、毎日開催されるので、本への関心が薄れる問題も回避できそうです。
目論見通り、一度も「きついな」と思うことなく最初から最後まで読みきることができました。3か月毎日（平日のみ）継続して開催できました。
👍 本の内容を深く掘り下げて読むことができた
これは想定してないよかったことでした。毎回の読書範囲が狭く、20分くらい語る時間があるので、普通に読書してたら読み飛ばすようなところもじっくり読んで意見を交わすことができました。ただ、これはこの本が「ソフトウェア設計の複雑さにどのように向き合うか」というかなり抽象的（？）な内容であるためより効果的であっただけの可能性があります。
また、書いてある内容を翻訳するだけでなく自分で要約した形にする作業もあるので、より、内容を深く理解できた気がします。
👍 定期的な学習の習慣がついた
毎朝（人によっては前日？）翻訳・要約の作業をする必要があるのですが、そのついでに調べ物をしたりコードを書いたりといった学習をする習慣がつきました。
👍 ちょっとだけ英語の勉強になった
基本的に英文はサッと目を通した後あとDeepLに食わせてた（英語の勉強が主目的ではないため）のですが、たまに参加者（英語ネイティブ）による表現の解説などが入ったりして、勉強になりました。
👎 自分のペースで読めなかった
これは輪読会あるあるだと思うのですが、「あー、先が気になる！もっと読みたい」と思っても、輪読会のペースに合わせる必要があります。毎日開催でちょっとずつ読む形式なので、より強く感じたように思います。
本の感想
せっかくなので「A Philosophy of Software Design」を読んだ感想を書きます。
設計の価値観が変わった
この本を読む前までは、アーキテクチャは、いわゆるClean ArchitectureとかDDD的で厳密・クリーンなものであればあるほどよいものだと思っていました。しかし、コードを読む人にとってはそれが結果的に負担になっている可能性があり、場合によっては可読性を重視して少し崩したほうが複雑性の小さいアーキテクチャになる、という視点を得ることができました。
また、モジュールについての新しい考え方も得ることができました。以前は、 モジュールは責務を分けて、小さく小さく分割！ みたいに考えていたのですが、それはこの本では「浅いモジュール」を量産することにつながってしまいます。インターフェイスは小さく、実装はしっかり書かれたモジュールが「深いモジュール」だそうです。
コメントに関する価値観が変わった
一番大きかったのは、コメントに関する考え方です。 コメントは書いたら負け！適切な変数名のモジュール、わかりやすいロジックにコメントは要らない、とか、コメントは嘘をつく！テストは嘘をつかない！ などと考えていました。しかし、そうなってしまうのは私のコメントの書き方が悪かったのだなと思わされました。コードに価値を追加するコメント、嘘をつかないコメントの書き方が紹介されており、かなり納得感がありました。
テストに関する言及が少なかった
一点気になったのは、本全体を通してテストに関する言及がかなり少なかったことです。また、著者の方がテスト駆動開発とテストファーストを混同しているっぽいところも気になりました。一人で読んでたらモヤモヤするだけでしたが、輪読会なのでモヤモヤをぶつけあうことができてよかったです。
まとめ
毎朝ちょっとずつやる輪読会は継続しやすい & 本の内容を深く理解できるので、ぜひやってみてください。A Philosophy of Software Designはこの形式にバッチリハマるし、内容もすごくいいことたくさん書いてあるので、ぜひ買って輪読してみてください。
Discussion