エキサイト株式会社SaaS事業部の菅間です。普段はクラウド経営管理ソフト KUROTEN. の開発を行なっています。
今回は、SaaS事業部のKUROTEN.開発メンバーで「レビューを考える会」を実施したので活動内容に関して記事を書きます。
レビューを考える会とは？
レビューを考える会とは、チーム全員でプルリクエスト（以下PR）に関して意見交換とハンズオンを行う会です。
背景と目的
弊チームのレビューは全員にアサインされます。 ここ1ヶ月で新しいメンバーが3名増えたこともあり、メンバーのレビューの機会が増加しました。
普段はシニアメンバーがコメントをすることが多いですが、その知見を他メンバーに共有することによってメンバーの技術力向上・レビューの質向上を目的として実施をしました。
実施の仕方
出社日に合わせてオンライン・オフラインの同時開催で行いました。 大きな流れとしては以下の流れで行いました。
- 全員一斉レビュー
- PRに対しての意見交換
全員一斉レビュー
実際に業務で出ているPRを題材に20分間で全員がレビューを行います。 （PR提供者の方ありがとうございます）
制限時間終了後に全員一斉に「Submit review」をします。
そのため20分間は他の人のレビューコメントは見ることができません。
そして最後に全員で画面共有をしながらそれぞれのメンバーがどういう意図、観点でコメントをしたのかを発表していきます。
全員でレビューすることで良かった点
- シニアメンバーのレビューの観点を学ぶことができる。
- チームで明文化されていないコーディングルールに関して意見交換ができる。
- コードレビューにおいて何が重要かを話す機会が得れる。
シニアメンバーのレビューの観点を学べるのもそうですが、Go言語の書き方やチームで明文化されていない方針などを話すことができました。 例えば、Repository層から構造体を返却する時のポインタの使い方などを議論することができました。
PRに対しての意見交換
全員一斉レビューを実施した後に、上記の取り組みで学んだこと、発見したことをポストイットに書き出して全員で発表を行いました。
出た意見例
- コメントだけではなく、サジェストまであると親切だよね。
- タイポやインデントは静的解析で対策できるので設定しない人は設定しよう。
- まずはコメントをつけてみることが大事。
- わからなかったらコメントで質問しても大丈夫。
- 一連のユースケースを踏まえた上で最適な書き方をコメントできると良い。
- レビューは実践的な知見が得れるため組織の知見共有になる。
など、PRに対する意識統一から作業効率化までを図ることができました。
実施してみての感想
最近会社の輪読会でGoogleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセスの9章コードレビューを読み終わったところなので個人的にはとても良いタイミングで参加することができました。
本書に出ているような「メンバーの心理的安全性を確保してリリースを早くする」や「可能な場合は自動化する」などに関して話に上がりました。 この会を実施することによって自分も含めてコメントへのハードルが下がって良かったです。
また、新メンバーとの交流の接点ができたのもチームとして良かったと思いました。
最後に
今回はAPIのレビュー会を実施したので、次回はフロントで実施を予定しています。 このようなチームが働きやすくなる、開発がしやすくなる施策を引き続き行なっていきたいと思いました。
今回企画してくださったリーダーの方々ありがとうございました！
