📚

社内で技術書の輪読会を始めた話

に公開

こんにちは、WED 株式会社でエンジニアをしている篠崎(@sinora_)です。

チームで技術力を高めるために、社内で「輪読会」を始めました。

週に1回、1時間。
メンバー全員で同じ技術書を読み、議論する時間です。

最初は「続くかな?」と不安でしたが、気づけば半年以上続いています。
そして、思わぬ副次的な効果も得られました。

それは、技術書の「積読」が解消されたことです。

一人で読んでいたら間違いなく挫折していたであろう分厚い技術書も、
チームの力を借りることで最後まで読み切ることができました。

今回は、私たちのチームで続けている輪読会の進め方と、その魅力をお伝えします。

輪読会を始めたきっかけ

チームで「もっと技術力を高めたいよね」という話は以前からありました。

個人で勉強するのももちろん大事ですが、チーム全体で同じ知識を持てたら、
コードレビューの質も上がるし、設計の議論もスムーズになるはず。

そう思って、勉強会の開催を考えたのですが...

  • 誰かが発表資料を作るのは負担が大きい
  • 個人学習だと結局続かない
  • 同じ本を読んでも、バラバラのペースだと議論できない

こんな課題がありました。

そこで出てきたのが「輪読会」という選択肢です。

輪読会なら、全員が同じペースで読み進められるし、
ファシリテーターを交代制にすれば負担も分散できる。
何より、「次回までに読んでおかないと」という適度なプレッシャーが、
継続の鍵になると考えました。

試しに始めてみたところ、これが思った以上にハマりました。

輪読会の5つのメリット

実際に輪読会を続けてみて感じたメリットを5つ紹介します。

1. 強制力が働く(最大のメリット)

個人的にはこれが一番大きいです。

一人で読んでいると「今日は疲れたから明日にしよう」となりがちですが、
輪読会があると「次回までに読んでおかないと」というプレッシャーが適度に働きます。

この「適度な」というのがポイントで、
週1回1時間というペースなら無理なく続けられます。

2. ナレッジシェアができる

メンバー全員が同じ本を読むことで、チーム全体の知識レベルが揃います。

「あの本に書いてあったアーキテクチャパターンで...」
という会話が普段の開発でも自然に出てくるようになり、
共通言語が増えるのは大きなメリットです。

3. 難しい本でも理解が深まる

一人で読んでいると、難しい部分で詰まって挫折しがちです。

でも輪読会なら、
「ここってこういう意味ですよね?」
「いや、こういう解釈じゃないですか?」
と議論することで、理解が一気に深まります。

特に抽象的な概念を扱う技術書では、この効果が絶大です。

4. アウトプット前提で注意深く読める

ファシリテーターは要約を作る必要があるので、
ただ読むよりもはるかに注意深く読むことになります。

「これ、どう説明すればわかりやすいかな?」
と考えながら読むので、自然と理解が深まります。

交代制なので、全員がこの経験をすることになり、
結果的に全員の読解力が上がります。

5. 不明点を仲間と解消できる

「ここ、よくわからなかった」という部分を、
その場で議論して解消できるのも大きなメリットです。

一人で悩んでいたら1時間かかることも、
チームで話せば5分で解決することもあります。

誰かの「わからない」は、他のメンバーも同じように感じていることが多く、
お互いに補完し合える関係が築けます。

私たちの輪読会の進め方

では、実際にどのように輪読会を運営しているのか、具体的な流れを紹介します。

基本情報

  • 開催頻度:週1回、1時間
  • 参加人数:4名程度
  • 書籍の選定:メンバー全員で同じ書籍を購入
  • ツール:Notion(要約の作成・共有)

ファシリテーター制

毎回、ファシリテーターを交代制で担当します。

ファシリテーターの役割

  • 担当範囲の要約を Notionに作成
  • 輪読会当日、サマリーを読み上げて説明
  • 議論をファシリテート

その他メンバーの役割

  • 事前に対象ページを読んでおく
  • 不明点・疑問点を Notionに記載
  • 印象に残った点を Notionに記載

実際のNotionでの管理画面はこのようになっています。

Notionでの要約管理

Notionでの疑問点・議論の記録

この役割分担により、ファシリテーターだけが負担を背負うことなく、
全員が適度な責任を持って参加できる仕組みになっています。

当日の流れ

  1. サマリーの読み上げ(20〜30分)

    • ファシリテーターが作成した要約を読み上げ
    • 重要なポイントを解説
  2. 質問・議論タイム(20〜30分)

    • 事前に記載された不明点について議論
    • 印象に残った点についてディスカッション
    • 実務での活用方法を考える
  3. 次回の確認(5〜10分)

    • 次回の開催日を決定
    • 次回のファシリテーターを決定
    • どの章まで読むかを決定

輪読した書籍

これまでに輪読した書籍の一例として「ソフトウェアアーキテクチャの基礎」があります。

ソフトウェアアーキテクチャの基礎_表紙

600ページ近い大著ですが、輪読会のおかげで全員が最後まで読み切ることができました。
一人で読んでいたら、間違いなく積読になっていたと思います。

他にも「Kubernetesで実践する Platform Engineering」など、チームで学びたい技術書を選んで輪読しています。

続けるための工夫・コツ

輪読会を1年以上続けられたのは、いくつかの工夫があったからです。

サマリーは自分の言葉で要約する

ファシリテーターが作成する要約は、本文をそのまま写すのではなく、
自分の言葉で書き直すようにしています。

これにより:

  • 理解が深まる
  • 読み手にとってわかりやすい
  • 自分の解釈が正しいか確認できる

コツ:質問形式にすると良い

「〇〇とは何か?」
「なぜ〇〇が必要なのか?」

このように質問形式で要約すると、
論点が明確になり、議論も活発になります。

理解度チェックリストを活用する

技術書の中には、章末に「理解度チェックリスト」のような
付録がついているものがあります。

これを輪読会の最後に全員で確認すると、
理解度の確認にもなり、議論のきっかけにもなるので非常に有効です。

柔軟性を持たせる

完璧を求めすぎると続きません。
以下のようなルールで、無理なく続けています。

  • できなかったら次回に持ち越し OK

    • 予定していた範囲が終わらなくても問題なし
    • 議論が盛り上がって時間が足りなくなることもある
  • 忙しい時はスキップしても良い

    • 繁忙期や緊急対応が重なったら休む
    • 完全に止めるのではなく、「一時停止」という認識
  • ペースは柔軟に調整

    • 難しい章は時間をかけて
    • 簡単な章はサクッと進める

この「ゆるさ」が、長く続けられる秘訣だと思います。

まとめ

輪読会を始めてから、技術書が「積読」から「読了」に変わりました。

一人では挫折していたであろう分厚い技術書も、
チームの力を借りることで最後まで読み切ることができました。

さらに、単に本を読むだけでなく:

  • チーム全体の技術レベルが向上
  • チーム内の共通言語が増えた
  • お互いの考え方や知識を共有できる

こうした副次的な効果も得られました。

私たちの輪読会は2024年6月にスタートし、年末時点で20回開催。
メンバーの参加率はほぼ100%を維持しています。
この数字が示すように、無理なく続けられる仕組みが作れています。

「技術書を買ったけど、なかなか読み進められない...」
そんな悩みを抱えているなら、ぜひ社内で輪読会を始めてみてください。

GitHubで編集を提案
WED Engineering Blog

Discussion