輪読会を1Q通して運営してみて

こんにちは、キャディでMLOps をやっている志水です。昔から本を読むのが好きなので輪読会には以前から興味があり、今回Q(四半期)を通して運営したのでその様子を共有します。

[toc]

なぜ輪読会を始めたか

ばんくしさんが「Googleのソフトウェアエンジニアリング本はいい本だからみんな読んだ方がいいけど、重い本だから輪読会をやるといいよ」ということを常日頃から言っていました(遡ったら2022/01あたりから言ってました)。やろうやろうとはなっていたもののやっていなくて、1章を読み込んで資料をまとめてTech全員に招待を送って第1回を開催したのが昨年の10月でした。 そこから少しずつ姿を変えて現在に至ります。

輪読会のフォーマット

現在は輪読会を毎週金曜日に開催しており、週ごとに次のフォーマットで進めています。

事前準備:
1. 該当章をあらかじめ各々で読んでおく
2. 読んでいて思ったことや関連するアイデアを Miro (オンラインホワイトボード)に付箋コメントとして書き起こす

当日:
1. 深堀りしたい付箋コメントに 1人 3票,4分で投票する
2. 似ているコメントをグループ化し、グループごとに得票の多いものから議論する
3. 議論後、自分達のチームに何を持ち帰れるかを言語化してみる
4. 必要に応じてworking agreementに加筆、あるいはチーム内で方針を合意する

やり始めた頃は、事前に担当者が該当章のまとめを作ってきて、それを全員で聞くようなフォーマットを試したこともありましたが、労力の割に得られるものが少ない感触がありました。毎回会の開催後に+/Δ(プラス/デルタという振り返りの1手法で会自体の良かった点と改善点を挙げていく)を何回か繰り返して現在のフォーマットに落ち着き、いい感じになりました。

こんな感じで意見を出した後に投票し、表が集まったものを中心に議論していきます。

初回は大体1章を読みますが、以降は特に順序を決めず都度投票して来週読む章を決めていきます。次の章より次の本が多く票が集まるようになったら次の本に行くイメージです。本のボリュームにもよりますが、大体3〜7週間で次の本に変わります。

投票の様子

カバーした本

前Qは以下の3つの本を対象に輪読会を実施しました。

Software Engineering at Google

https://www.amazon.co.jp/Software-Engineering-Google-Lessons-Programming/dp/1492082791

最初に読んだのは『Googleのソフトウェアエンジニアリング』です。去年の末から読み始め、チームでは9章分をカバーしました。リーダーシップ、テスト、CI/CD等エンジニアリングを広くカバーしていて最高の本でした。実務に直結する指針もたくさんあります。

Team Topologies

https://www.amazon.co.jp/Team-Topologies-Organizing-Business-Technology/dp/1942788819

次に読んだのが『チームトポロジー』(通称ちいとぽ)です。チームがソフトウェアを作る、という思想をベースにチームのあり方やチーム間のコミュニケーションのあるべき姿を示していて、チーム運営をしていく上での共通認識や共通言語ができたのがすごくよかったです。またキャディ全体でもTECH組織の組織形態はこの影響を強く受けています。

Designing Data-Intensive Applications

https://www.amazon.co.jp/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321

前Qの最後は『データ指向アプリケーションデザイン』を読みました。データベース内のデータ構造や分散合意、列指向フォーマットのバイナリ配列、バッチ処理とストリーム処理など、データに関わる仕事をしてきた上でもう一歩踏み込んだ理解を進めてくれる非常にいい本でした。

なぜ輪読会がいいか

ここで改めて輪読会の良さを言語化してみます。

実務的なメリットとして一例を挙げると、推論基盤のテストを設計する際に「Google のソフトウェアエンジニアリング」の輪読会が役に立ちました。輪読会以前は開発チームにテストに関する統一的な見解は無かったのですが、輪読会をきっかけに「我々が他チームに提供する機能は何なのか」や「それを担保するにはどうすればよいか」について議論が発展しました。本をベースにした適切なテスト設計について共通の指針をチーム全体が持てたことで、実装もスムーズに進みました。

もう少しふわっとしたところでは、チームの引き出しや共通言語が増えた感触があって、チームの雑談やちょっとした話の中でちいとぽの言葉が出てきたりソフトウェアエンジニアリング本の言葉が出てきているように感じます。

個人的には自分の感じているモヤっとした課題を既に言語化してくれている部分も多く、マネージャーやチームとの1on1のなかで何がやりたいかや何を期待しているかを少しうまく表現できるようになった気がします。 おまけとしてこの輪読会を起点に本全てを読破できるようになり、読書量が増えました。

またチームメンバーからの意見をまとめたところ

  • 自分が普段読まない本や、名著なのは知っているけど読むのが大変な本を読むきっかけになる
  • チームとの議論があることがわかっているので、目が滑らず咀嚼するモチベーションがある

のような意見もありました。確かに深く読もうというプレッシャーがあるのはいいことですね。

他チームの輪読会

またこのTechブログを書いている時に、他人のカレンダーを覗いてたところ別のチームでも輪読会をやっていることを発見したので、少しだけお邪魔させていただいて話を聞きました。

山下さんがリードするキャディの別プロダクトのチームでは業務で必要になりそうな知識を先取りして読むように輪読会を運営していて、「ボトムアップDDD」「SQLアンチパターン」などの書籍をカバーし、「チームが同じ言葉で話せるようになる」「レビューがスムーズになる」などのいい影響があったとのことでした。大体1ヶ月に1冊くらいのペースで、全員で意見を書き出して議論するようなフォーマットで、図らずも同じような形式になっているのが面白かったです。輪読会がチームを超えて組織全体に浸透していて本好きの一員としては嬉しい限りです。

終わりに

今回は輪読会の具体的な開催方法とその良さを紹介しました。 キャディでは一緒に働く仲間を探しているので、募集要項 から気になる求人があればご気軽にご連絡いただければ幸いです。