Repro Team / Feature Unit の下村です。 Reproで行っている技術書の読書会をどのように運営しているのかについて紹介します。
Reproの技術書読書会の現状
現状は2週間に1回のペースで1時間ほど時間をつかって読書会を行っています。参加者はその時々によって変わりますが、2-5人程度が参加しています。
今までは以下のような本を読んできました。
- システム設計の面接試験 (半年程度で読破)
- ソフトウェア設計のトレードオフと誤り (半年程度で読破)
- 分散システムデザインパターン (現在読んでいるところ)
Reproでは高トラフィックなシステムの保守運用や開発が求められる場面が非常に多いです。せっかくなのでそのようなReproの特性に合う本を読もうという方針のもと、参加者間で議論して読む本を選んでいます。
モチベーション
そもそもなぜ読書会をやりたいのか?という理由はチーム間の会話を増やすという目的からでした。
現在Reproの開発組織はチームトポロジーに影響をうけたチーム構成になっています。詳細は割愛しますが*1 、各チームの役割と開発を担う機能が明確に分けることで、できるだけチーム間コミュニケーションを減らし、1チームで素早く意思決定して開発ができる状態を実現しています。 素早く開発できるメリットがある一方で、開発に直接関わる必須な会話以外のコミュニケーション頻度が少なくなるというデメリットもあります。それにより、チーム間での直近の開発には必ずしもつながらないようなナレッジ共有頻度が減ってしまうことが発生しえます。
また、技術に関する会話がチーム内で閉じがちになり、技術に関する知的好奇心をReproで十分に満たすことができずにエンゲージメントが下がるということも考えられます。
これらを解決するために、技術に関する会話をできる場として読書会の運営をし始めました。
読書会運営における課題
過去これ以外にも読書会を各チームや有志で行うことはありましたが、うまく続けられないこともしばしばでした。弊社だけではなくどの会社でもあるあるな課題ではないでしょうか。
なぜ読書会は続かないことがあるのでしょう?以下が続かない理由かなと考えています。
読む時間がない
宿題として対象部分を読んでくるという形にすると、ハードルはあがりがちです。いくら読みたい本であったとしても、忙しかったり、疲れているなどタイミングによっては読めないこともありますよね。読んでいないので不参加、という判断をすることで参加者が徐々に減っていくことはあるあるだと思います。
参加者がいない
会の時間になっても誰もいない…なんてこともあるのではないでしょうか。直接業務に紐付かないこともあるため、直近の業務を優先して出席しなかったり、そもそも今日読書会があることを忘れていたり…。そうして人が少なかったり参加者がいないことを理由に延期しがちになれば、参加のモチベーションが下がってしまうこともあります。
読むモチベーションが続かない
読了まで時間がかかってしまうと、読み初めたときに感じたワクワク感も薄れがちです。そのようなことになればどんどん参加者が減っていくなんてこともあるでしょう。
読書会を続けるために行ったこと
コミュニケーションに関する問題を解決するための解決法として読書会を選びましたが、1冊読んだら終わりではなく、読書会を長く続けていかなければ問題は解決に至りません。 そのため、「どうしたらうまく続けられるか」を念頭にこれまで運営を行ってきました。前述の課題をつぶしながら進行できることを意識しつつ、運営をしています。
宿題なしでも参加できる内容にする
「読む時間がない」という課題に対しての解決策です。 宿題などの事前準備なしでも、なんなら本を持っていなくても参加できる内容にして参加ハードルをさげました。
具体的には以下の2つのスタイルのどちらかで進めていました。参加者の読んできた状況や対象の章の長さに合わせて、適宜どちらかのスタイルで行くかを選択しています。
- 事前に分からなかった部分や興味深かった部分を書いておき、会の中でそれらを議論
- その場で20分ほど黙読、その後気になった部分を議論
特に1.については読んできた人と読んでこなかった人で持っている情報量に差が出てしまいます。その場合は読んできた人が要約と気になった部分の背景を説明したうえで議論に入ることで、議論ができる状態を作っています。
ファシリテーターが確実に出席する
「参加者がいない」という課題に対しての解決策です。 参加してみたけど誰もいない…という悲しい状況を避けるため、ファシリテーターの自分が絶対に出席するという形にしました。また出席者が少なかったとしても、会を延期することなく読み進めるようにしています。ファシリテーターの負担はちょっと大きくなりますが、やるのかやらないのか分からず参加判断に迷う、という参加者の精神的な負担を下げるためにもこのような形にしてみました。
読書会を行っているアピール
これも「参加者がいない」という課題に対しての解決策です。 とにもかくにも認知されていなければ参加者は増えません。 Reproではslackを利用していますが、slackの開発者用チャンネルにリマインダーと、行ったあとのアピールを流すようにし、読書会でどういう内容が話されているのかを把握できるようにしました。 最初から参加してなくてもOK、読んでなくてもOKなことを事前に認識してもらえるように、また実際にどういう内容を話しているかを書くことで興味をもってもらおうとしています。
たまには本を読まない(!)
「読むモチベーションが続かない」という課題に対する解決策です。 読んでいるだけだとモチベーションが徐々に下がっていくようなタイミングもあるはず。ちょっと気分転換をしつつ、読書の内容を活かしてモチベーションをあげていくという目的で、本に書かれている内容を実装してみるという催しもやってみました。
システム設計の面接試験という本では、そのタイトルのとおり、面接試験で出てくるようなシステムやアルゴリズム実装のお題が書かれています。自分だったらそのシステムをどう作るか?を実際に参加者が実装してみて他の参加者に披露していました。実装会は2回おこない、1回はシステム設計の面接試験にでてくるURL短縮の仕組みを実装するもの、もう1回はその本の中に出てきた問題や関連話題で各々気になったものを実装していました。実際作成したものは以下です。
URL短縮
- https://github.com/shim0mura/system-design-interview/tree/main/url-shortener
- https://github.com/mkanenobu/url-shortener
- https://github.com/akihiro17/shorturl
自由お題
- 本のなかに出てきたコンシステントハッシングの実装
- 本には書いてないものの、読書会中で話題になった共同編集に利用されるアルゴリズムの実装
- GoogleDriveに似た仕組みの実装。同じファイルでも差分がでている箇所のみアップロードするデルタ同期も実装済み
本の内容に対する理解も深まりますし、会話も結構盛り上がるので読書会に対するモチベーションや楽しさを感じられるようにする一手としては良いものだったと感じています
続けてどうなった?
チーム間の会話を増やすという目的で行っていた読書会でしたが、結果としては別チームに属するメンバー間の会話を生み出す場としての効能は得られたかなと思っています。 特にReproに新しく入社したメンバーが多く参加している状況もあり、別チームでお互いをよく知らないという人たち同士が技術をネタに会話を行えています。
おわりに
以上のようなことを意識しつつ、これまで2年弱ほど継続して読書会を続けられています。 読書会が続かない、参加者が少ない…などの課題でお悩みの方々の一助となれば幸いです。
*1:詳細はこちらのエントリーをご覧ください https://tech.repro.io/entry/2023/09/28/101708