クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

「輪読会ってどうやるの?」が「やってみてよかった」に変わった!"レビューを考える輪読会"のご紹介

こんにちは。クラウドテックの開発チームでエンジニアをしている@tama555です。今回は社内で開催した「レビューを考える輪読会」についてご紹介します。はじめての輪読会で手探りでしたが、毎回ディスカッションが盛り上がって「やってよかった!」と胸を張って言える楽しい会になりました。この記事では「輪読会やってみたいけど、どう始めたらいいのか分からない」という方向けに、具体的な手順やポイントについて書いていきます。

一般的な輪読会とは

人々が集まって、同じ教科書などの本を読み、その内容について意見を交わすことを意味する語。事前に決められた担当者が、本の内容を訳したりまとめたりしてから、他の参加者が理解できるように発表する形式がとられることも多い。

引用元: 「輪読会(りんどくかい)」の意味や使い方 わかりやすく解説 Weblio辞書

輪読会に参加することで、参加者で共通の知識や考え方を身につけることができ、お互いの専門分野や知見を交換できます。また、定期的に輪読会行うことで、参加者同士のつながりを深め、コミュニティの形成にもつながります。

今回の輪読会を始めたきっかけ

去年の夏ごろ、個人的にコードレビューについて悩むことが増えていました。例えば「レビューでどこまで細かくみたらいいか分からない」とか「パッと見良さそうに見えるけど、LGTM出す自信がない」とか、です。これをチームメンバーに相談したところ、あるひとりの方がGoogleが公開している「コードレビューの基準」というドキュメントを紹介してくれました。レビューする側もされる側も何か基準があればやりやすいだろうと考えて「まずは一緒に読みましょう!」とチームに声をかけて始まりました。(輪読会や勉強会など開催する人の背中を押してくれる、いい会社です。)

「レビューを考える輪読会」概要

題材

Googleが公開している「コードレビューの仕方」の日本語翻訳版

目的

  • 題材をきっかけにレビューについて考えて意見交換する
  • どんなレビューが「良い」とされるか、メンバー間で会話して目線を合わせる
  • (できれば)クラウドテック開発チームのレビュー標準化を目指す

参加者

開催頻度

  • 毎週30分
  • 全15回で読了

その他

  • 事前準備は不要 → 題材が一部を切り出して読んでも理解できる内容なので予習復習は不要でした
  • オンライン開催 → 普段から業務で使っているGatherというバーチャルオフィスで開催しました
  • 毎回議事録を残す → ドキュメントのテンプレートを作って毎回記録を残しました

輪読会の進め方

事前にアジェンダの型を作って参加者に共有することで、やることが明確化してスムーズになりました。1回30分の配分も大まかに決めて、会話する時間を多く取るように工夫しました。

パソコン画面のスクリーンショットです。 画面の右半分はブラウザが開かれていて輪読する題材のページが表示されています。タイトルは「コードレビューのスピード なぜコードレビューは素早く行うべきか?」です。ひとりの人が読む範囲が選択されています。 その左には別のブラウザウィンドウが開いていて、輪読会の議事録が表示されています。 タイトルは「レビューを考える#7」で「今日の読む範囲」の項目に「コードレビューのスピード」とハイパーリンクがあり、その下にリストで、コードレビューはどれほど急ぐべきか?/スピード vs 割り込み/素早い応答/タイムゾーンをまたがるレビュー と記載があります。 その下の項目は「アジェンダ」です。 リンクの共有(2分)資料/議事録 議事録の書記を決定(3分) チャンネル #product-dev-service-babubabu/ランダム @cwbit shuffle (伏せられている)/先頭の人が書記をお願いします Googleの「コードレビューの仕方」を読んでみよう(10分) 1人1分くらいで読み終わる分量ずつ/席順に時計回り/わからなかった用語はその場で調べる/どこまで読んだか分かるように議事録に記録する 読んで思ったことを発表しよう(1人1分) (時間が余ったら)チームに活かせそうな具体的なトピックがないか考えてみよう(10分) 一番左端には別の細長いウィンドウがあり、Gatherのコメント欄が表示されています。題材のリンクと議事録のリンクが投稿されており、最新のコメントは「CL=change list でしたよね?」とあります。
オンラインで実施した輪読会の画面共有イメージ(当時のスクショがなかったので疑似再現です)

以下、アジェンダについて順番に紹介します。

リンクの共有(2分)

  • 参加者にその日に読むページと議事録ページのリンクを共有します

議事録の書記を決定(3分)

  • 後からいつでも見返せる場所に議事録を残します
  • 参加者の中から毎回ひとり書記をしてもらうので、負担が偏らないように気を配りました
    • 名前をシャッフルしてくれるツールを使ってランダムで決めます
    • 参加者の方の中から積極的に挙手してくださることもありました

Googleの「コードレビューの仕方」を読んでみよう(10分)

  • 1人2分程度で読み終わる分量を4〜5人で順番に回して読みます
  • 資料を開いて画面共有すると今読んでいる範囲が分かりやすかったです
  • 分からなかった用語はその場で調べて議事録にも記録しました

読んで思ったことをコメントしよう(1人1〜2分くらい)

  • その回で読んだ範囲で、気になったこと、思ったことなどを順番に全員がコメントします
    • 例: "レビューは「素早い応答」が大事という記述がありましたが、業務ではなかなかできていないので反省しました。簡単なコメントだけでもこまめに返答するように心がけたいです。"
  • コメントを議事録にメモすることで、後からどんな話になったか見返すことができます
  • コメントに対して他の参加者が自由に発言してOK。賛同の感想や深掘りする質問など、毎回話が盛り上がりました

参加者の会話を促すポイント

コメントのパートで参加者同士のディスカッションが活発になるかどうかは、ファシリテーションが鍵になります。参加者の会話を促すポイントを自分なりにまとめてみました。

  • まずはじっくり話を聞く
  • 全部聞いた後に、聞き返して深掘りする
  • 自分の意見を簡単に言ってから、他の人はどう思うか指名して聞く
    • ただ漠然と「どうですか?」は答えにくい
  • 具体的な事例を聞いてみると、話が発展することが多い
    • 例: "コーディングの最中にレビューを割り込みしてしまうと作業効率が下がるという話がありましたが、実際の業務ではどのようにレビューする時間を確保していますか?"
    • 例: "レビューのスピードを上げたいけれど経験が少なく時間がかかってしまいます。レビューのコツを掴むにはどうしたらいいと思いますか?"

参加者のフィードバックアンケート結果

輪読会の最終回の後で、参加者のみなさんにフィードバックアンケートを回答してもらいました。結果は概ね好評価で、やはりディスカッションが有益だったという意見が多かったです。

輪読会について何かコメントやご意見があれば、お聞かせください。

・輪読会を通じてレビューの目線が揃った状態で運営できているので新しく入ってきた方にどうやって落とし込むかを考えていきたいですね

・開催いただきありがとうございました。RVのベストプラクティスってちゃんと読んだことなかったので、学びが多く、すごくいい機会になりました!

・話が逸れていったときのほうがなんとなく興味深い話になっていった気がしています!

・また別の輪読会があったら参加したいと思いました

・参加者の皆様も積極的にコメントしてくださって盛り上がったので大感謝です

(回答一部抜粋)

 ▼その他のフィードバックアンケート結果(クリックで展開)

Q1. 今回の輪読会の内容は、あなたにとって興味深かったですか?(5段階)
1: 0人(0%)
2: 0人(0%)
3: 0人(0%)
4: 1人(14.3%)
5: 6人(85.7%)

Q2.輪読会の進行や時間配分について、適切でしたか?(5段階)
1: 0人(0%)
2: 0人(0%)
3: 0人(0%)
4: 2人(28.6%)
5: 5人(71.4%)

Q3. 輪読会のディスカッションは、有益だと感じましたか?
1: 0人(0%)
2: 0人(0%)
3: 0人(0%)
4: 2人(28.6%)
5: 5人(71.4%)

Q4. 輪読会に参加することで、新しい知識やアイデアを得ることができましたか?
1: 0人(0%)
2: 0人(0%)
3: 0人(0%)
4: 1人(14.3%)
5: 6人(85.7%)

よかったこと

  • 時間配分について
    • ディスカッションの時間をしっかり確保できたので良かった
    • 30分は集中が途切れないちょうどいい時間だった
  • 参加へのハードルについて
    • 事前の準備が不要なので気軽に参加できた
    • 前の回を聞いてなくても参加できるゆるさが良かった
  • ディスカッションパートについて
    • 参加者の積極的なコメントによって、毎回盛り上がりのある輪読会になった
    • まずは話を聞く、頭ごなしに否定しないことで、自由に話せる空気づくりができていた
    • チャットツールを使った文字でのコメントから話が広がることもあった
  • 得た知識やアイディアの活用について
    • 題材が「レビュー」で毎日の業務と関連が高かったので、学んだことをすぐに実践できた
    • 2チーム合同で実施したので他チームの文化を知れた。良い取り組みを真似することができた

改善できそうなこと

  • 予定の30分をオーバーする日もあった
    • その日に集まった人数から「今日は時間オーバーになるかも」など最初に予想して、後ろの時間に予定がある人から順番に喋ってもらってもよかったかも
    • 話が盛り上がりすぎてオーバーになることもあったので、それはそれで良いことだったかもしれない

筆者の個人的な感想

  • 業務が忙しい期間はお休みをしましたが、無事に最終回までやり切れて達成感!
  • 参加できる日は毎回ファシリテーションをやるようにして経験を積ませてもらったので、ファシリ力が上がったかも
  • それより何より、毎回ディスカッションが楽しかったのが大収穫でした(つまらないことは続かない……)

具体的なアクションにつながった事例

私たちクラウドテックの開発チームでは、輪読会で得た知見からレビューの標準化を進めるべく、ドキュメントにチーム独自の「コードレビューの仕方」をまとめました。

例えば、レビューコメントに内容に応じたラベルをつけることを、チームの合意をとって明文化しました。ラベルは[MUST] [IMO] [NITS] [ASK] [GOOD]があり、チームメンバー間でコメントの粒度を揃えることができ、実装者に修正の必要度を伝え、レビュアーと実装者の心理的負担を軽減するのに役立っています。

レビュー標準化の細かい紹介はいつの日かまた記事にまとめたいですね。

ドキュメントページのスクリーンショットです。左上に「コードレビューの仕方 - クラウドテック(2022/09/29)」とタイトルの記載があります。以下本文です。GOOD良い実装につけるコメントです。レビューは間違い探しになりがちなので、良いところを積極的に賞賛しましょう。実装者のモチベーションアップにつながりますし、レビュワーとしても良いコードを意識することで自分の実装に還元することができます。1つのPRに対して1つ以上GOODコメントをつけるように意識しましょう。「ご対応ありがとうございます」だけでもOKです。観点例: うまくメソッドを使ってスマートに書けている/例外処理が適切に実装されている/面倒な実装を丁寧にやってくれた コメント例: GOOD この書き方、スマートでいいなと思いました!
チーム独自の「コードレビューの仕方」をまとめたドキュメントの一部

今後の展望

今回、良い輪読会体験ができたので、違う題材を使ってまたやりたい欲があります。次回はもっと技術的な内容に特化した題材でも良いかもしれません。例えばクリーンアーキテクチャドメイン駆動設計(DDD)関連の書籍は、今回より分量も多いし難易度も高そうです。でもその分、より多くの知識をチームで共有できるのでチャレンジのしがいがありそうですね。

現在は別の勉強会のシリーズが始まっており輪読会については何も決まっていませんが、また何か実践した時にはブログにまとめたいと思います。

まとめ

今回「レビューを考える輪読会」を通してコードレビューへの理解が深まり、チーム内での目線合わせができました。また、参加者同士が意見交換をし、相互理解を深めることができました。普段一緒に働くチームや、違うチームとの合同開催など、コミュニケーションを深めたいメンバーで輪読会をやることをおすすめします。

もし、これを読んでいるあなたが輪読会をやろうかどうか迷っているのであれば、まずは思いきって第一回を始めてみましょう。やってみて改善点が見えてきたらブラッシュアップしてより良い輪読会にしていきましょう。

ここまで読んでいただいてありがとうございました!

We're hiring!

最後に、クラウドテックでは事業と開発をリードしていただける仲間を募集しています!ご興味のある方は以下のリンクからご応募ください!

herp.careers

© 2016 CrowdWorks, Inc., All rights reserved.