レビューガイドラインを作っている件

はじめに

こんにちは、ピクトリンク事業部開発部サーバサイド開発課のkitajimaです。

ピクトリンク事業部開発部サーバサイド開発課ではDX Criteria の観点を改善する取り組みを進めています。
今回はその一環として行っている、メンバーがコードなどをレビューする際に一般的な基準とするガイドライン作成について紹介させていただきます！
本記事が、これから明文化されたレビューガイドラインを策定していきたい方の参考になればと思っています。

背景

まず、チームの現状把握から始めました。
DX Criteria のアセスメントシートに沿って、各項目の達成度を可視化していきました。
その中で特に改善が必要な項目を対象に、週に1回1時間、"改善会"という時間を設け、以下のようなチーム分けでそれぞれ改善活動に取り組んでいます。 - オンボーディングデックの整理 - 参考：DX Criteria オンボーディング・デック - オーナーシップの取り組み - 参考：DX Criteria 属人化排除 - レビューガイドラインの作成 - 参考：DX Criteria コードレビューガイドライン

それぞれが改善会で得られた成果をチーム内外に共有し、フィードバックをもらう運用を行っています。なお、この取り組みは「改善会以外の時間を使ってもよいが、チームタスクを優先する」という位置付けで進めています。

このような経緯で、私を含む3人のメンバーがレビューガイドラインの作成チームとして毎週作成を進めているわけです！

レビューガイドラインとは？

ここでは、レビューを行う際の指針となるドキュメントを指します。レビューの対象物は仕様書、テスト要項書など、コード以外も存在します。そのため、「コードレビューガイドライン」と限定していません。
他社事例として、以下のようなものが公開されています。 - Google社 Code Review Developer Guide - Zaim社チーム共通で使うためのコードレビューガイドラインを作った

レビューガイドラインの利点

それでは、レビューガイドラインがあることで開発者は何が嬉しいのでしょうか？それは以下のように考えています。 - 確認すべき事項がまとめられたドキュメントを整備することで見落としを予防する - レビュワーのスキルに大きく依存することなくレビューができるようになる

このような効果を期待して、特定の技術に依存しないような、サーバサイド開発に一般化した内容のガイドラインになるよう進めています。

作成の流れ

現在5回の改善会の時間を経て、これまでどのように進めてきたのかをまとめてみます。

1回目

レビューガイドラインのうち、まず整備すべきはコードレビューガイドラインであると考えた
レビューガイドラインには大きく観点/進め方(手順)の2つのものがあったらよさそうと目星をつけた
公開されているレビューガイドラインを探し、GoogleのCode Review Developer Guide を参考にすることにした

2回目

コードレビューの対象は以下のようなものに大別されると考えた
- 機能開発
- IaC (Infrastructure as Code)
- リファクタリング
機能開発を対象として、レビュー観点をメンバーで出し合った

3回目

機能開発と同様に、Iacとリファクタリングについても観点をメンバーで出し合った
機能開発のレビュー観点を文書としてまとめ始めた

4回目

機能開発、IaC、リファクタリングのレビュー観点を文書としてまとめた
これを本取り組みの最初の成果物としてチームに共有し、フィードバック対象にした

5回目

コードレビューの手順をまとめ、文書としてまとめた
こちらも本取り組みの成果物としてチームに共有し、フィードバック対象にした

出来上がった成果物

出来上がった成果物は、社内Wikiにて共有しています。 - コードレビューガイドライン - コードレビューの手順

チーム内外からのフィードバック

チーム内外に成果を共有したところ、以下のように様々な感想、意見をいただきました！ - レビュー時に何を意識すべきか文章化されていると有難い！ - フロントチームは「レビューを出す前のセルフチェックリスト」を運用している - 静的解析で済ませられるところは済ませたい - 「複雑でない」という表現が抽象的すぎるので、循環的複雑度(コードの複雑さを測定する指標の一種)を目安とするのはどうか

今後の取り組み

いただいたフィードバックを検討、反映させていきます。特に、レビュイー側のガイドラインとして、セルフレビューを行ってからPRを出すといった手順の文書化は効果的だと予想しており、現在着手しています。
作成したガイドラインを実運用に乗せ、スキルに依存しないレビューの実現や、チームのレビュー精度向上を期待しています。