チームを強くする輪読会のすすめ

ここにタイトルを入力します.jpg

現職で初めて輪読会を経験したのですが、非常に良い学びの機会だと感じたので共有します。

輪読会導入により、組織にどんな変化があったのか、「やらなくてよかったな」と思うこと、「業務時間を使うべきか?」のなど諸々を共有します。

輪読会の進め方

ざっくり以下の方法で進めています。

①事前準備: 本の選定、タイムボックスを設定

②輪読会実施:本に合わせた進行を選ぶ

①事前準備: 本の選定、タイムボックスを設定

本の選定はいろいろな切り口があります。

  • 現在の業務で苦手意識や勉強が足りないと感じている分野の本(FW, ライブラリ, テーブル設計など)

  • チーム共通でキャッチアップしておきたい概念(SOLID原則、TDD、Agileなど)に書かれている本

  • 一人で読むには難しくて、複数人でキャッチアップしながら読み進めたい本(抽象的な内容の本)

などの意見を元にメンバで意見を出し合い、本を決めます。

現職では以下の本を選定しました。

  • 負債を作らないためのコーディングの理論を抑えたい→Clean Architecture

  • DDDの概要を抑えたい→ドメイン駆動設計モデリング実践ガイド

  • 直近でVue.jsのコンポーネントのテストがボトルネックになっている→ZennのVue.jsのテスト方法をまとめた本

以下のように本を選定の基準するとおすすめです。

  • チームとして恩恵を得られるもの。輪読会の結果、チームの成果につながると、継続的に輪読会を続けていく強い指針になる

  • 分厚すぎない本を選ぶ。15章ぐらいある本だと週1時間の輪読会で2章ずつ読んでも2ヶ月弱かかる計算。その間にチームの関心ごとや課題が移り変わっている可能性が高い。1ヶ月で読み切れると理想(そんな薄い本は多くないが…)。重要な章だけ読むのもあり

  • 具体的なプラクティスが学べる本を選ぶと、短期的な恩恵を得られる。Clean Architectureは良本だったが、実際実務にどれだけ落とし込めたかというと微妙。基本原則を抑えるという上ではもっと端的にまとまっている本の方がチームとしてはよかったかも(例: プリンシプルオブプログラミング)

また、輪読会を実施するためのタイムボックスを設定しましょう。

特にこだわりがなければ以下を留意してやるとおすすめです。

  • 週1時間決まった日程

  • 業務時間の末尾など、メンバのコンテキストスイッチに負担がかからないタイミング

  • 納期やスプリントレビュー直前など、追い込みが必要になりそうな箇所を避ける(時間内からスキップ!となりがちなので)

②輪読会実施:本に合わせた進行を選ぶ

準備ができたら、いざ実践です。

本の難易度や、種類(概論, 具体的なプラクティス紹介, etc…)によってやり方を使い分けるのがおすすめです。

  • 概論的な本の場合: 15分程度で区切りのいいとこまで読んで、メンバが共有する時間を作る

  • 具体的なプラクティスがコードベースで紹介されている場合: 一人が音読ライクに読み進めて、途中でメンバが解説や質問を投げかける

輪読会からチームが得たもの

ざっくり3つ挙げると以下のような感じです。

メリット1: 一人でスルーしがちな疑問を、知見のある人が拾ってくれる

メリット2: 程よい緊張感が質の高い読書になっている

メリット3 : チーム内の共通言語ができる

メリット1: 一人でスルーしがちな疑問を、知見のある人が拾ってくれる

1人で読んでいるとスルーしてしまうような疑問を、チームメンバが拾ってくれます。

A: 「ここに書いてあることがイメージできないんですよね」

B: 「あ、実は私もよくわかってないです…」

C: 「ここは、私たちのプロジェクトではここの機能が近いことをやっていて〜(知見がある人がメンバに説明)」

A,B: 「なるほど!なんとなくイメージできました」

上記のようにわからないところをチームが補足してくれます。

また、メンバはチーム内のプロジェクトを例にしてもらえると、不思議とスッと入ってきて、知識が一人で読んでいる時以上に定着する感覚が個人的にはあります。

そのため、以下がチームに求められます。

  • 本を読む中でわからないことは素直に「わからん!」と声をしっかり上げること

  • 自分の解釈を他の人に共有する。曖昧な理解でも共有すると他の人の学びになったり、補足してくれるメンバがいるとさらに理解を深められるため

メリット2: 程よい緊張感が質の高い読書になっている

輪読会では「この章を一旦15分までよんでください」という感じで進めると程よい緊張感が生まれます。

私は本を読むスピードが遅めで、頭になかなか入ってこず、同じ箇所を往復してしまうことがよくあります。しかし輪読会では、この緊張感が集中力を上げ、いつもより早く本が読めている実感があります。

また、理解できない箇所は一旦スルーして、そのあとメンバに「〇〇が頭に入ってこなかったです」と共有することで「実はあそこはxxで〜」と噛み砕いて説明をもらう機会が生まれます。これはメリット1で揚げたものです。

蛇足ですが、この学びは一人で読書する際にも役立てています。

  • 1章単位で時間を決めて読む(締切効果)

  • 読んでいるうち感じたこと、学びをdocsに呟く(わからん!も含め)

  • 読み終えたor時間切れになったらdocsのことについて調べてみる

調べてわからなかったことは、後日メンバに聞いてみたりすると、いい記事を紹介してくれたりととても役立ちます。

メリット3: チーム内で共通の指標ができる

これはコードレビューなどのタイミングで役立ちました。

「どっちの書き方が(設計的に)いいか」でレビュアーとレビュイーが空中戦を繰り広げてしまうケースがあったのですが、以下のように解決するパターンが増えました。

A:「ここってインターフェース分離の原則的にはこっちにメソッド持たせた方がいいよね」

B:「確かに、Clean Architectureで書いてあったね、じゃあこっちにしよう〜」

共通の指標があり、それにチームが合意できていればレビューもスムーズに進められると考えられます。

輪読会アンチパターン

最後に、「これはやらない方がいいな」と思っている輪読会の形を紹介します。

この本のここを次回までに読んできて〜

これは以下の点でデメリットがあると考えます。

  • 業務時間外の宿題にする場合、メンバに強制することになるため負荷が高い

  • 「読み忘れていました」「読んだ内容をあんまり覚えていません」となると輪読会が進まないし、チーム内の空気も悪くなりがち

  • 読んでいる瞬間に生まれた新鮮な疑問が酸化してしまう。

そのため、「業務時間内に決まった時間みんなで読む」が良いと私は考えます。

感想を言う時間を作らない

読書時間だけを確保してしまうパターンです。(これをやるチームはほとんどないと思いますが…)

輪読会最大の旨味は「教え合って理解を深める」ことだと私は考えます。

自分と違うバックグラウンドのメンバが、自分と違う解釈で本を噛み砕きます。それを理解し、また共有するという濃密な学習の機会はなかなかないです。

むしろ本はコミュニケーションのきっかけで、チームの対話こそ最大の学びの材料、ぐらいでいいと思います。

輪読会を業務時間を使えない場合

私は「業務時間」を使って輪読会をしていますが、

  • 業務が忙しくてそんな暇ない!

  • 客先常駐だとそんなことできない!

  • 業務時間を使うなんて上司が許さない!

と言う方も多いと思います。私は「チームの生産性向上」のための輪読会であれば「ビジネス的に必要だから」という理由で業務中にやるべきと考えています。しかし現実的には理解を得られない状況があることは事実だと思います。

そのため、「もし自分が業務として輪読会を取り入れるならどう立ち回るか?」を考えてみました。

まず、できることは以下が挙げられます。

①利害関係者への提案、説得を試みる

②業務時間外に取り組み、成果を共有して①に移行する

③社外のコミュニティで輪読会に参加し②に移行する

「①利害関係者への提案、説得を試みる」に取り組む際は、以下の訴求ポイントがあります。

  • 中長期的にみて、組織全体のスキルが向上し、生産性が上がる

  • 組織内に継続的学習をする習慣が芽生える

  • 技術書から学びを得たという成功体験をメンバが感じることができる

  • 組織の教育に力を入れているという採用アピールの一つになる

  • 週40時間のうち、1時間でいい→労働力のうち2.5%の投資である

輪読会にはコストを上回るメリットが豊富にあると考えます。なので①の手段で取り組むと思います。

「②業務時間外に取り組み、成果を共有して①に移行する」は①で説得できなかった場合のケースです。

①で利害関係者の合意を得られなかった理由が「本当に意味があるのか疑問」である場合に有効だと考えます。

注意点は「業務時間外なので強制してはいけないこと」です。有志のメンバを募って実行必要があります。その際一部のメンバだけで輪読会をやってもチームとしての恩恵は大きく得られないです。チーム共通の知識にならないからです。最終的には全員を巻き込むためにも①にシフトしていきたいです。

「③社外のコミュニティで輪読会に参加し②に移行する」は②で有志が集まるどころか、社内のメンバからも輪読会に同意が得られない、前向きに考えてもらえなかったケースにできることです。

「コミュニティでこんな学びがあった」と共有し、社内を巻き込んでいくスタイルです。

ですが、ここまでストイックに取りくむには「チームをより良くしてビジネス的な価値を提供していくんだ!」という確固たる意志が必要ですね。

まとめ

今回は「組織での輪読会の取り組み」についてご紹介しました。

「個人開発」に関するブログだったのですが、最近は組織作りやアジャイルに関心があるのでこういう記事も書いてみようかなと思いました。

組織が輪読会を取り入れる際のヒントになれば幸いです。