輪読会、してますか？
こんにちは。ログラスのQAをしています、コタツと申します。普段はnoteやXで発信しています。
このたびテックでもなんでも無い私がテックブログにお誘いいただき、何の話ができるかな〜と思って出てきたのはこの「輪読会」というネタでした。
ログラスでは、直近1年ちょいでこんな本を開発チーム全体で輪読しました。 （以下アジャイルテスト本と呼びます）
（以下単体テスト本と呼びます）
おかげで、開発チーム内でのQAの役割についてや、具体的な取り組みについての理解が格段にアップし、チームの品質に対するステージ（？）が1段上がった感覚がありました。私が主催した輪読会は前者のアジャイルテスト本のみですが、この少ない経験の中から、輪読会を開催したい！と思っている誰かのためになりそうなノウハウを書いていきたいなと思います。
また、「どんな本を読んだらいいか？」についてはこの記事では取り扱いませんのであしからず。
（前提）なぜ輪読会を開催するのか？
本を読むだけなら一人でもできます。あえてみんなで読んでいくには以下のような狙いがあると思っています
- より多くの人達と同じ本を読んで共通言語を獲得することで、チーム全体のスキルを底上げする
- 一人では成し遂げられない難解な本の読破を、みんなで励まし合うことで完遂したい
というわけで、沢山の人を巻き込んでいるので、絶対に有意義な会にしたいのです。
輪読会の設計
- 目的を決める
- 本を決める
- 会の方針を決める
- やり方を決める
具体例を上げながら、一つずつ見ていきます。
目的を決める
簡単でいいです。三行とかでいいので、まず目的を決めます。
目的が決まらないと本も決まらないです。でも、「読んでみたらめちゃ良かったからみんなと読みたい」というモチベーションも良いと思います。
実践アジャイルテストの輪読会の際にとりあえず置いた目的はこんな感じでした。三行にも満たない目的でした。
荒くてもいいので目的を決めて、それからどんな本が良いか考えていきます。私は課題ベースでなりたい姿を目的に置くことが多いです。
本を決める
突然具体の話になりますが、私は「課題があって目的だけ決めたので、これを達成するためにはどんな本が良いと思いますかね〜？」という話を周りの人にしていきます。
一人で本を決めるよりもいい本が見つかるのはさることながら、興味を持ってくれそうな人がどのぐらいいるのか参加者の総量がだんだん見えてきます。
会の方針を決める
以下のようなことを決めて、参加者が有意義に過ごせる会議体設計をしなければなりません。要所要所を解説していきたいと思います。
- 対象となる参加者
- いつ開催するのか
- 頻度、1回あたりに使う時間
- 何回で完結するか
対象となる参加者・いつ開催するのか
過去開催した2つの輪読会は、業務時間内に行いました。業務に密接に関わる知識を扱う本なので、業務時間内で、かつエンジニア全員がわかっていないと意味がないので、なるべく全員に予定をあけてもらい、全員に参加してもらいたいという温度感で（参加必須ではなく任意でしたが）開催しました。
業務時間内に開催することについては上記のような理由で開発チーム全体に理解していただいていましたし、過去業務時間内に開催していた輪読会があったというところからも抵抗感が薄かったように思います。また、会社の風土として常に学び続ける文化づくりをしていることもあり、業務時間内に輪読会を開催することが当たり前の雰囲気がありました。
何回で完結するか
輪読会は終りが見えないとモチベーションが出ないので、無理のない範囲で設定することが大切です。本の全部を読む必要もないので、特に今必要な事が書いてある箇所のみをスコープとして設定したりしました。
たとえばアジャイルテスト本で言うとそもそもアジャイルQAの認識をチームで揃えたい目的だったため「第2部組織的なチャレンジ」「第3部アジャイルテストの4象限」までを対象とし、そこまで読み終わったら一旦輪読会としては簡潔としました。
やり方を決める
輪読会は色々なやり方がありますが、今回実際にやったやり方を紹介します。
| 頻度と量 | 事前準備 | ファシリテーター | ワーク | |
|---|---|---|---|---|
| アジャイルテスト本 | 毎週 章単位 |
事前に読んでこなくても良い | ローテーション | あり |
| 単体テスト本 | 毎週 章単位 |
事前に読んでこなくても良い | 固定 | プレミアムコースのみあり |
※「ワーク」は本の内容によって異なります。
アジャイルテスト本
開発チームのアジャイルQAやテストに関する認識を揃える目的だったので、ファシリテーター以外の人が本を読んでこなくてもある程度議論に入れる設計にしました。（もちろん全員が本を読んできてくれると最高ではあるんですが）
輪読会当日にはファシリテーターが章の内容をまとめ、参加者がその内容を通読し気になる部分に各自投票します。そして気になる部分についてオープンディスカッションを行います。主なテーマは各々の開発チームでの現状はどうなっているのか、この理想に向かうためにはどうすればいいか、という観点です。結果的に現状の課題を整理した上でチームをまたいだ知見共有ができました。
単体テスト本
単体テスト本で得た知識や技術を現場に持ち帰ることを趣旨としていたので、ファシリテーターは言い出しっぺの輪読会オーナーで固定で開催しました。面白かったのが、同じ時間の中でプレミアムコースとベーシックコースで参加者を二分し実施していたことです。
プレミアムコース
本を読んできた人のみプレミアムコースとして議論に参加できるという建付けになっていました。プレミアムコースはオーナーが毎回ざっくりまとめと話したいこと・もしくはやりたいことを宿題と称し用意しており、例えば現場の実コードの中で該当章で取り上げられているようなものがあるかどうかということを話し合い、実際にコードを書いていきました。
ベーシックコース
本を読んでこなかった人はベーシックコースとして毎週の輪読会の時間を使って読書していきます。
モクモク読書をするのですが、解釈が難しいポイントが結構有ったので、どういうことなのかslackで話し合ったり、最後に読み終わった感想を話し合いました。
具体的なTips等
本を読んでこなかった人が脱落しないような仕組みを考える
上記2つの輪読会は離脱者が多くなるということも起こらず、最後まで完走することができました。常に学び続けるという会社の文化もあると思いますが、上記の「やり方を決める」に書いたように、本を読んでこなかった人が脱落しないような会議体設計になっていたのがポイントだったなと思います。
やはり理想は全員が読むことですが、実務との兼ね合いがあってなんだかんだ忙しく、準備が難しいのはよくある話です。そんな場合でも、読んでこなかった人に優しい設計にしていることで目的に達成に近づけたなと思います。
notionで一回ごとに議事録を管理する
ログラスでは社内ドキュメントや議事録など、すべての情報がNotionに一元化されています。
輪読会記録DBは私が入社した時にすでにあったので、私が導入したわけでもなんでも無いんですが、完遂したらやっぱり達成感はあるし、前回の内容にいつでもアクセスできるのでとてもいいなと思います。
こんな感じで過去やってきた内容もわかるので、新たに入社された方に私達はシェアすることもできるのも良いです。スクショには写していませんが、ファシリテーターを毎回ローテーションしており、その割当をNotion上で管理しています。
人を集めるときは楽しげに
これはもはやTipsでもなんでもないんですが、楽しそう！と思ってもらったほうが人も集まりますし、参考程度にということでこんな感じで人を募っておりました。
そもそもこの投稿をするまでに何人もの人に「この本どう？」という壁打ちを何度も重ねていました。その結果、色々な人に興味を持ってもらうことができ、自分も含めると18名の参加表明をいただくことができました。
成功事例
開発チーム全体で、取り扱ったテーマに対しての解像度が高まった
当たり前なのですが取り扱ったテーマに対しての解像度が高まりました。開発チーム全体という広い範囲に対してアプローチできて離脱者も少なく完了することができたので、開発チーム全体の底上げに繋がったと思います。
アジャイルテスト本に限って言うと、「QAって何する人なの？」というチームの疑問は晴れました。
現場で実際に試してみることができた
単体テスト本を読了後、開発チーム全体を巻き込んで、実際のテストコードを書き直す会を開催しました。そこで本を読んで得た知識を活かしてみることで、「実際に読んだけどあんまり活用できていない」という悲しい状況を回避することができました。これは余談ですが、チーム戦にして、最も多くのコードを書いたチームに優勝景品として豪華景品をプレゼントしました。
まとめ
総じてまとめると、無理ない範囲で達成可能なゴールを設定して、参加者が脱落しないような仕組みを作ることが輪読会設計のコツかなと思います。
以上になります、お読みいただきありがとうございました！
株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。
Discussion