こんにちは、プレックスの石塚です。この記事は開発生産性 Advent Calendar 2022の21日目の記事になります。

前々回の記事で、10月に開発合宿を開催し、「普段できていない開発プロセスの改善」というテーマのもと、各々が開発に取り組んだ様子をご紹介させていただきました。その中で、個人が取り組んだ内容を次回以降のブログで詳しく書いていくと言っていましたが、気付けば早2ヶ月が経過、さすがに年をまたいでしまってはまずいという思いで、焦り筆を取っている次第です。

そういったわけで、今回は自分が開発合宿の中で取り組んだテーマである「コードレビューのプロセス改善」のお話をさせていただきます。

コードレビューの目的
- エンジニアリング的観点
- ビジネス的観点
以前のプロセスと発生していた課題
どう改善したのか
- 原因の特定
- プロセスの改善
  - 1. プルリクエストの大きさを小さくする
  - 2. GithubのSlack連携を軸にプロセスを構築
終わりに

コードレビューの目的

まずプロセス改善の話をする前に、なぜコードレビューを開発プロセスに組み込んでいるのかという話をしたいと思います。コードレビューは多くの現場で開発プロセスの一貫として取り入れられていることが多いですが、絶対必要というわけではありません。特に事業フェーズが初期段階かつシニアなメンバーが集まる組織では、コードレビューを省略しているパターンが多いイメージがあります。

個人的にコードレビューを導入する目的に関してはエンジニアリング的観点とビジネス的観点の2つがあると考えていますが、弊社の開発組織においては導入するメリットの方が大きいと感じています。

エンジニアリング的観点

エンジニアリング的観点としては以下のような、いわゆるコードレビューのメリットとして語られることが多い事柄です。

プロダクトをチームでメンテナンス可能な状態に保つ
- リーダビリティや一貫性、品質の担保
プロジェクト、ドメイン、技術における知識の共有
オーナーシップを高める
ログが残る

ビジネス的観点

コードが目的を達成できる正しい挙動をしているか確認する
不具合を減らす

ビジネス的観点は上記の2つです。現在のプレックスの開発では、PdM、エンジニア、デザイナーの分業体制がきっちりと明確になっているわけではないので、コードの変更がユーザーストーリーのゴールを達成するものかを確認するといった目的も含まれています。

コードレビューの責務が増えてしまい、余計なコストが掛かってしまうので、本来は仕様の是非まで確認するのは理想的とは言えません。とはいえユーザーに提供してからこの機能は無駄だったよねとなってしまうと、今まで開発に掛けてきたコストが無駄になってしまうので、開発プロセスのなるべく早い段階で発見できるように、タスクの種類や大きさによって確認するようにしています。

※このあたりの生産管理の話はHIGH OUTPUT MANAGEMENTが詳しいです。

以前のプロセスと発生していた課題

前置きが長くなってしまい恐縮ですが、改善前のコードレビューのプロセスとそれにおいて発生していた課題についても軽く紹介しておきたいと思います。

以前のプロセスではSlackのワークフローを活用していました。このようなプロセスに落ち着いた背景として、最初はSlackのメッセージでテキストで直接コードレビュー依頼を実施していたので、ワークフローを使って自動化したという経緯があります。入力値は以下の3つで、レビュワーとレビューイにメンションが飛ぶようになっています。

レビュワー
緊急度（お手すき・なる早・大至急の3種類）
プルリクのURL

この運用では特に大きな問題はなかったものの、以下のような課題がありました。

コードレビューが溜まりがち
コードレビューが漏れる
コードレビューに時間が掛かる
レビュワーのコンテキストスイッチが発生する
コードレビューの知識がレビュワー、レビュイー以外のメンバーに共有されない
Githubでのコードレビューの後、Slackでメンションする手間がある

どう改善したのか

原因の特定

合宿の前からどんな課題があるかを議論したり、書籍やブログでのインプットをした結果、主に以下の2点が根本的な原因だと考えました。

プルリクエストのサイズが大きい
- コードレビューに掛かるコストが増える
  - 時間が掛かる
  - コンテキストスイッチが発生する
    - 溜まりがち、漏れる
Githubのリマインダーを適切に使えていない
- 定期的にコードレビューの時間を確保できていない
- 自分がアサインされているコードレビューを一覧できる場所がない
  - 溜まりがち、漏れる
- Githubでのコードレビューの後、Slackでメンションする手間がある

「コードレビューの知識がレビュワー、レビュイー以外のメンバーに共有されない」という課題に関しては、比較的チームの人数が少ないこともあり、今回はコストパフォーマンスを考慮して改善のスコープ外としました。

プロセスの改善

そうした流れから、合宿では次の2つの改善を実施していきました。

1. プルリクエストの大きさを小さくする

こちらの改善はプロセスというよりは、心構えに近いですが、コードレビューガイドというドキュメントを用意して、オンボーディング時に共有する形にしました。実際のコードレビューガイドに記載されている内容をそのまま添付しておきます。

1. プルリクエストを小さくする
- プルリクエストの元となる仕様を小さくする
  - 実装の前にWHYやWHATについて議論しておく
    - スプリントMTGでできると全員参加しているので良い
    - WHYやWHATは本来コードレビューで蒸し返されるべきポイントではないが、リリースしてから気付くよりはコードレビュー時に気付けるほうが手戻りが少ないので気付いたら言うべき
  - 実装の元となるタスク（HOW）を細かく分割する
- 変更が大きくなる際は、設計レビューを実装前に行う
  - モデリングにはドメインモデル図を推奨

コードレベルでプルリクエストを小さくすることも大事なのですが、それ以前の仕様を決める段階での動きがより重要だと思っています。ユーザーストーリーのゴールを達成するミニマムの仕様はどういったものか、仕様が大きいのであればマイルストーンを引いて検証を分割することはできないかを考えるようにしています。また大きな変更であれば、設計レビューも事前に行うことで、プルリクエストの責任範囲を小さくすることも意識しています。

2. GithubのSlack連携を軸にプロセスを構築

Githubにはscheduled remindersというSlackと連携したプルリクエストのリマインド機能があります。この機能は大変便利なのですが、個人ごとに設定をする必要があり、設定がばらついているとうまく恩恵を得ることができません。

なのでプレックスでは以下のようなルールを作って運用していくことを決めました。

SlackのGithub連携をしている部屋にジョインしておく
- Slackのユーザーグループに設定して、デフォルトでジョインするようにしておく
開発者は scheduled reminders を必ず設定しておく
平日に1日2回はリマインダーを設定し、コードレビューの時間を取るようにする
- 時間は任意
コードレビューの依頼はプルリクエストのレビュワーのアサインで行う
- 急を要する場合のみSlack上でメンションする
レビューの修正が完了したらプルリクエストからレビューの再リクエストを行う

またGithubでは自分のアサインされているレビューを一覧できるリンクが取得できるので、そのリンクをSlackのカスタムレスポンスに設定したり、Slackのチャンネルのブックマークに貼っておくことで、区切りのいい時間でレビューを実施する際の手間を減らしています。

↓ゴニョゴニョしていたら取得できたリンク

https://github.com/pulls/review-requested?q=is%3Aopen+is%3Apr+archived%3Afalse+user%3A{GithubのOrganization名}

終わりに

以上の改善の結果、レビューの漏れや溜まりが減る、レビューを依頼する手間が少なくなるといった結果を実現することができました。振り返ってみると、プロセスを改善できたというのはもちろんですが、合宿という全員が参加している場でお互いのレビューに関する共通認識を揃えることができたことも大きかったなと感じています（自分の実装とレビューのどちらが大事なのか等）。

嬉しいことに11月、12月に1名ずつ、フルタイムのエンジニアの方がジョインしてくださり、フルタイムで4名、業務委託・インターンを含め10名弱の開発組織になってきました。組織が拡大していく中で更なる改善として