ディップ Advent Calendar 2023の15日目です。
普段はGoを使ってバイトルID（バイトル・バイトルPROの共通ID）や社内ツールなどの運用を行っています。
はじめに
所属している課で、8月ごろから新卒3人で輪読会を主催しています。
読んでいる本はリーダブルコードです。
リーダブルコードの中身については、すでにまとめてくださっている記事が多くあるので割愛します。
幸いなことに途中で挫折せずに継続できているので、ここでは輪読会の主催者になって学んだことを振り返っていきたいと思います。
そもそも輪読会って何？
輪読会とは、複数人で同じの本を読み、その内容について意見を交わすことです。
その場で本を読むのか、誰かがまとめた資料を読むのか、などは自由なようです。
輪読会の具体的なやり方についても様々な記事が書かれているため、それらを参考に目的に合ったやり方を考える必要があります。
経緯
きっかけは、同じチームの同期（11日目の記事を書いてくれています）がリーダブルコード読んでみたいです、とチーム内で発言していたことからです。
チームリーダーからドキュメント化することを勧めていただき、やり方について課長に相談したところ、
新卒で輪読会やってみたら？という提案をいただきました。
そこで、課の新卒3人で輪読会を開いてみることにしました。
どうやってやるか
先輩に学ぶ
同部署で輪読会主催の経験がある先輩を紹介いただき、まずは過去の経験から学ぶことにしました。
輪読会のやり方はもちろんですが、先輩の「主催が辛くならないように、とにかく継続することが大事」といった言葉が印象に残っています。
一度始めたら期間を守って定期的にやらなければと思っていたため、この言葉は記事を読んでくださっている皆さんにもお伝えしたいと思います。
輪読会の流れ
その後主催で会議を重ねながら、まずは目的を定めました。
- コード品質の中でも一貫性・可読性を高める
- コードの一貫性・可読性に対しての提案や改善しやすい環境を作り、現状のよい部分についても再確認できる場となる
- コードレビューの観点がわかることで、新卒が積極的にレビューや質問ができるようになる
そして、初回はこんな進め方にしました。
1. 事前に主催がリーダブルコードを1章ずつ読む
2. 章の要点をまとめたものを作成
3. 週1の定例で各自作ったものをまとめ、輪読会当日に共有する資料を作成
5. 隔週で45分の輪読会を開く(zoom)
6. その場で作成した資料を読んでもらう
- 読んだ後、3~4人ごとにブレイクアウトルームに分かれ、意見を付箋に出し合う
- 話し合う内容
- ex ) 課の中で実践してみたい、と思ったこと
- ex ) すでに実践できていること
- ex ) 資料のまとめ方についての別意見
7. 最後に、ブレイクアウトルームの中で出たよい点や課題点を発表する
8. 話し合ったことをもとに次週の輪読会定例で資料を修正し、公開する
試行錯誤...
課題が山積み
第1回の輪読会終了後の議事録タイトルがこちらです。；；
1回目を経て大量に改善点が出てきました。
新卒だけでは見えていない課題の発見のために、アンケートを取ったり、直接感想を聞いたりと、まずは洗い出しを行いました。
どんな課題が出たのか？
以下は輪読会をやっていく中で出てきた課題の一部です。
- 初歩的なミス
- 意見を書き出すボードにログインできない！
- Zoomが40分で切れた！
- 話し合いがうまくいかない
- 話し合う時間が足りない
- 全員に話を振れない
- 黙読してから疑問を書き出すまでの考える時間が足りない
- 主催が大変
- 自分の業務が忙しくて本を読んでまとめている時間がない
- 話し合いが長引きすぎて業務に影響が出る
- 隔週にしても参加者のスケジュールが空いてない
毎回ブレイクアウトルームと黙読の時間を変えて調整しながら、どうしたらもっと会話できるか、意見が聞けるか、出しやすいかを考えて改善を重ねていきました。
どうにかしてうまくやる
初歩的なミスから中身のブラッシュアップまで、とにかく話し合いを重ねて改善していきました。
具体的には、こんな内容です。
- 時間を調整する
- 黙読する時間よりも、ブレイクアウトルームで議論する時間の方が長く必要だった
- 意見を書き出すボードの項目を工夫することで意見を引き出す
- アンケートを設置し、参加者の感想から課題を見つける
といった改善を行っていきました。
また問題が
話し合いを重ねる中で起きたのが、主催の業務が遅れる問題です。
話し合いが長引いたり、個々の作業が多いことが原因でした。
そのため、資料まとめ担当を毎週一人にする、など作業を役割分担していきました。
主催の作業を分担したことにより話し合いで決めることが減り、業務が圧迫されることも減りました。
輪読会の開催自体も隔週という縛りをなくし、業務が詰まっている時は延期して、とにかく続けることを重視しました。
改善の結果は？
参加者の感想
輪読会はこれまで6回開催してきました。
ここまでの感想を、参加者の皆さんに聞いてみました。
- 実際のプロダクトでもできているかを考えた時に、意識していない部分が明確になった。
- 現在の自分の書き方を見直す機会は定期的に必要だなと感じました。。。
- メンバーがどのような思考で実装に取り組んでいるかわかった。
- 推奨される書き方をみんなで学んで、認識が揃っている状態で、ユニットの開発ルールとかこれまで働いてきた現場ではどうだった、という話ができたのは良かった。
（アンケートから引用）
輪読会の場を通して、コードの書き方を見直したり、共有したりすることができました。
目的に対しての成果
最初に定めた目的に対して、どうなったかを書き出してみました。
- コード品質の中でも一貫性・可読性を高める
- 開発メンバーにより意識してもらうことができており、新卒も意識できるようになった
- コードの一貫性・可読性に対しての提案や改善しやすい環境を作り、現状の良い部分についても再確認できる場となる
- 議論の中で、課で定めているコード規約の話が挙がることもあり、現状の良い部分の確認ができた
- コードレビューの観点がわかることで、新卒が積極的にレビューや質問ができるようになる
- レビューの際に開発者が可読性を意識して書いている部分を理解できるようになった
- 輪読会で得た知識を使って指摘ができた
これからの課題
輪読会を通して解決できた課題・成果は多くありましたが、課題も残っています。
- すべての参加者から満遍なく意見を引き出せていない
- 輪読会で話し合ったことを記録してはいるが、学びとして昇華できていない
良いコードの書き方を意識し直すということだけでなく、学びのアウトプットをできるように考えていきたいと思います。
輪読会を通しての学び
まだコードを書いた量が少ない新人エンジニアの私にとっては、リーダブルコードは少し難しい本でした。
しかし、何度か経験していくうちに業務の経験も増えていき、
自分が書いたコードを見たら
→この書き方はよくないってリーダブルコードで読んだ！
課のコード規約を見返したら
→同じ内容をリーダブルコードで読んだ！
などなど、進研ゼミでやったところだ！的な嬉しい発見が何度もありました。
また、主催としては、参加者や先輩社員の意見を取り入れて改善を重ねる、わからないことはどんどん聞きにいくといったコミュニケーション面や、主催の作業をしながらも他のタスクを疎かにしない、など、仕事の仕方で身についた部分が大きかったと思います。
輪読会をやってみてよかったです。
最後に
提案してくださった課長や、協力いただいている課の皆さんをはじめとするすべての方に感謝したいです。
輪読会やってみたいなーとお考えの皆さん、たまには休みながら続けてみてください。
拙い文章ですがここまで読んでいただいた方、ありがとうございました！