英語の技術書の何気ない社内輪読会の効率を劇的に改善した4ステップのフォーマット

こちらの記事はmybest product dev Advent Calendar 2022にも参加しています。

https://adventar.org/calendars/8007

# 概要
1年前から社内のエンジニア2名で本の輪読会を行っています。最初は手探りで開催していたのですが、改善の結果開催フォーマットが整い、なかなかいい感じになったので、今回はそのフォーマットをぜひ紹介したいと思います。

## 輪読会の4つのステップ
1. 事前に要約を作成
2. 要約と本文を照らし合わせながら読み進める
3. 章ごとに実務のPull Requestと照らし合わせながら議論する
4. 小さなTRYを話し合う

# 背景
ちょうど1年前くらいに、社内で「『[A Philosophy of Software Design](https://www.amazon.co.jp/dp/1732102201)』というソフトウェア設計の本を読みたいのだけど、一人でやるのは挫折しそうなので誰か一緒に輪読しませんか？」という提案があり、今年の頭から2人の輪読会を行っています。

こちらの本はソフトウェア設計のテーマとして、より早く、より安くソフトウェアを書くために、ソフトウェアの複雑さを最小限に抑えていくという考え方や実践の内容が書かれている本です。全22章から構成されており、なかボリュームと読み応えがある1冊となっています。

まだ翻訳されていない本でもあるため、英語で読むというハードルありました。

# 手探りのためあまり効果を実感できなかった輪読会
そうして始まった輪読会なのですが、当然参加者が2人とも業務が忙しく、準備に時間をかけずに開催していました。
二人集まってDeepL等の翻訳ツール等を使いながら一緒に読みすすめる→章が終わったら感想を言い合うというような流れです。

この方法だと、読むことや初見の内容を理解することに時間や労力がかかってしまい、なかなか内容についての込み入った議論にはなりませんでした。
もしも参加者のうちどちらかが本を読んだことあったり、内容に通じていればもうひとりがわからなかったことを質問するなどの形式でうまくいきそうだったのですが、今回はふたりとも初見の内容だったためそれが難しいような状況でした。

結果として、時間を使ったわりには理解度や満足感が足りていないような感覚がありました。

# 改善の結果作った輪読会の4ステップのフォーマット
しかし、回を重ねることに少しずつ改善を重ねた結果、1年経った今ではとても満足感がある時間となりました。
下記で紹介するようなステップに従って実施しています。
## 1.要約を作る
時間が取れないとはいえ、僕の方でなんとか時間を作って輪読会の前にざっと次の回に読む箇所を読んで、まとめを作るようにしました。
どうしても時間がとれないときは、せめて段落の最初の文だけでも翻訳するようにしました。今回の本は洋書であったこともあって、パラグラフライティングがきちんとされているため、それでもあるだけで内容の全体像を作るには役立ちます。
このあたりは新卒初年で身につけた読書まとめの作り方がうまく活きてくれました。

https://speakerdeck.com/isaka1022/xin-zu-1nian-demo-ita-ji-shu-shu-matome-falsezuo-rifang

## 2.要約と本文を照らし合わせながら読む
要約があることで、その段落の全体像が見渡す地図ができたような感覚があります。
その場で翻訳ツールなども使いつつ読み進めていくのは前と変わらないですが、要約と本文を照らし合わせながら読むことで、お互いわかっている内容についてはスキップしたり、また、僕が読んでいてわかりにくかったところを重点的に読むなどのグラデーションをつけることができます。
ここで、お互いの認識や解釈、あるいは知識の差分を埋めていくようなことができました。
以前はどこがわかってどこがわからないのかもわからないような手探り感があったのですが、要約や段落ごとに解釈を揃えていくことで共通の認識を持って次の議論のステップに進むことができるようになりました。

## 3.実務のPull Requestと照らし合わせながら議論する
セクションや章が変わるタイミングで読むことをやめて、議論に入ります。今回の本のテーマがソフトウェア設計の話だったので、
- 最近設計に困ったPull Requestはあったか
- 普段はコメントを書きながら実装しているか
- 命名がわかりづらくて箇所はあるか
- もっと複雑性を下げるためにリファクタリングできそうな箇所はあるか

などを、実際のコードを見ながら議論します。
ここが社内で行う輪読会のメリットで、お互い共通の認識があったり、システムのコードやPull Requestをすべて見ながらできるので議論がとてもやりやすかったほか、身近な具体例が交わるｊことで内容の理解がすごくはかどりました。

## 4.小さなTRYを話し合う
そうして話しながら、実践できそうなことも合わせて出していきます。
今回の本は22章あるので、もし毎週1章ずつ読んで試せることを出して実践していけば、半年ほどでかなりの実践につながります。

とはいえ、章の内容によってはなかなか実践につながらないものもあります。
そういうときにはなぜ実践しづらいのかを議論します。
例えば、
- 内容はとてもわかるけど説明が抽象的すぎて具体的にどうすればよいのかわからない
- 期日があるものだとスピード優先になりがち、など現実の問題と理想的な設計の折り合いの付け方が難しい
- 採用しているフレームワークと筆者の主張の相性が悪い

などがこれまでの会の中ではありました。

実際に使っている要約ページもこちらで紹介しておきます。

![スクリーンショット 2022-12-02 9.40.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/238254/7caf87a5-edb9-f56c-f8ca-3393689fd825.png)


# 実感している効果
この方法に沿って読み進めたことでかなりの効果を実感しています。
お互いの解釈が揃うようになったほか、日々の実践にもつながるので、本の内容の身につき度が格段に向上しました。さらに、次回の勉強会のときに前回のTRYのふりかえりもできるので、本の内容がゆっくりじっくり身につきながら理解できるようになった感覚があります。

さらには、要約を作ったドキュメントに議事録のように話したことを記録しておけるため、復習やほかの社内メンバーへの共有にもつかえるという嬉しさもありました。

# フォーマットに沿って輪読会を行ってみた感想
今回のフォーマットがすべての勉強会に当てはまるとは思っていないですが、少し抽象化すると、勉強会を行う際には以下のような要素があるとよいのかなと思っています。

- その回で勉強すべき内容のアウトラインを用意する
- 参加者の共通の認識を取る
- 議論ができる共通の題材を用意する
- 日々実践できるTRYへの落とし込みを会のゴールとする

# じっくり読みたい本で使うのがおすすめ
このように書くとすごいいい方法のように見えますが、今回の4つのステップは輪読の中でもじっくりやる方法なので少しばかりコストがかかってしまうのが難点です。

事前に読んで要約を作らなくてはいけないですし、内容を読むのと議論を会の中で一緒に行うため、章の内容によっては議論も膨らみ場合によっては2時間近くかかってしまったこともありました。
読みすすめるペースも遅くなるため、けっこうな長期戦となっています。

読みたい本のテーマやレビューに応じて 「この本は！」というものに対してやるのがおすすめかと思います。

ということで普段使っている輪読フォーマットを紹介しました。
ぜひ、みなさんの輪読会がよりよいものになりますように！