エンジニアの市川と申します。
LIFULL HOME'S の売買領域の開発を担当しています。
さて、皆さんは普段からコードレビューをしているでしょうか。
私たちLIFULL HOME'Sのエンジニア組織では、他者のコードレビューを通過しないとリリースできないというルールを設けています。
そんな中、コードレビューがボトルネックになってしまったアプリケーションがあり、それを解決するために行った取り組みを3点紹介します。
課題
今回対象としたのは、近年基盤を刷新したアプリケーションのコードレビューです。
リプレイスによってアーキテクチャや言語、フレームワークが刷新されたことで、開発しやすくなりました。しかし、設計思想を深く理解しレビューできるメンバーが限られてしまいました。
初期段階では開発メンバーが少なく、レビューの頻度も低く問題になることはありませんでした。しかし、開発案件の増加や組織拡大に伴い、レビュー待ちのプルリクエストが目立つようになってきました。
また、弊社でもGitHubのコードオーナー機能を利用しており、重要なビジネスロジックを追加・変更するような箇所についてはコードオーナーによるレビューを必須化することで品質を管理しています。
したがって、人数を増やせば良いというわけではなく、人数と質の両面のバランスを考慮した対策が必要になりました。
ここからは、メンバーがコードオーナーに昇格するまでのプロセスの見直しと改善について説明します。
1. 昇格ルールの明文化
問題点: コードオーナーに求められるスキルレベルがわからない
まず、どのような状態になればコードオーナーになれるのかが不明確でした。
これまで初期の実装に関わったエンジニアをそのままコードオーナーとしていたため、明文化する機会がありませんでした。
解決策
現コードオーナーと開発リーダー間で議論し昇格ルールを作成しました。 そしてその昇格ルールを、開発しているGithubリポジトリのドキュメントに追加しました。
コードオーナーに求められるのは「実装能力」 だけでなく、「設計思想から逸脱した実装を見逃さず指摘できる能力」 です。その点を満たしているかを確認できるプロセスにしました。
結果、いつでも確認できる場所に昇格ルールがあることで、昇格候補者にとって目指すべきゴールが明確になりました。
2. 昇格状況の可視化
問題点: 昇格プロセスの進捗が不明確
次に、現状自分や周囲が昇格プロセスの中でどの段階にいるのかが不明確でした。 そのため、あとどの領域のレビューを何回経験したら良いかがわからず、ネクストアクションが立てづらい状態でした。
解決策
現状自分がどの段階にいるのかを可視化するため、昇格状況のチェックリストを作成しました。
下記のように、各自の状況を一覧にした表を作成しました。
私の担当するアプリケーションでは、クリーンアーキテクチャやDDDといった手法を採用しているため、それらの経験を積むことが重要です。 また、LIFULL HOME'Sの知識もドメイン知識として必要ですので、項目に入れています。
導入してみた結果、自身に必要な経験やスキル不足が明確になっただけでなく、誰にどのレビュー案件を担当させるべきか、管理側としても判断しやすくなりました。
3. 昇格課題の用意
問題点: レビュー経験を積む機会が少ない
ルールの明文化と自身の現状が可視化されたため、あとはレビュー経験を積むだけです。 しかし、都合よくレビュー依頼が来るとは限らないため、待っているだけではレビュー経験を積むのに時間がかかりすぎます。
解決策
レビューの経験を積むという観点では、対象が新規実装である必要はありません。そのため、リリース済みのプルリクエストの中から学びの多そうなものを選定し、それらをレビューの課題として再利用することにしました。
再利用したいプルリクエストの番号と、レビューコメントの直前のコミットハッシュさえわかれば、当時のプルリクエストと同じものを作成できるスクリプトを用意しました。
# 引数でPR番号とレビューを始める前のコミットハッシュを受け取る PR_NUMBER=$1 END_COMMIT_HASH=$2 # 一時ディレクトリを作成し、そこにクローン TMP_DIR=$(mktemp -d) git clone $REPO_URL $TMP_DIR cd $TMP_DIR # PRの最初のコミットハッシュを取得します FIRST_COMMIT_HASH=$(gh pr view $PR_NUMBER --json commits --jq '.commits[0].oid') # 親のコミットハッシュを取得します PARENT_COMMIT_HASH=$(git rev-parse ${FIRST_COMMIT_HASH}^) # 日時をフォーマットします（例: YYYYMMDDHHMMSS） TIMESTAMP=$(date +"%Y%m%d%H%M%S") # ベースブランチと子ブランチの名前を作成 BASE_BRANCH="practice-base-${TIMESTAMP}" CHILD_BRANCH="practice-child-${TIMESTAMP}" # ベースブランチを作成してプッシュ git checkout -b $BASE_BRANCH $PARENT_COMMIT_HASH git push origin $BASE_BRANCH # 子ブランチを作成してプッシュ git checkout -b $CHILD_BRANCH $END_COMMIT_HASH git push origin $CHILD_BRANCH # 新しいPRを作成 gh pr create --base $BASE_BRANCH --head $CHILD_BRANCH --draft --title "Practice PR ${TIMESTAMP}" --body "This is a practice PR. Based on PR #${PR_NUMBER}."
こちらを昇格課題として利用し、コードオーナーがピアレビューを行うことで、昇格候補者が経験を積むことができます。
結果、事業状況により改修案件の頻度や粒度が異なる中で、昇格候補者が均等に経験を積める環境を整えられました。
また、「中規模以上のレビューを経験する」というルールにしても定義が難しいですが、コードオーナーが選定したプルリクエストを使うことで問題は解決されます。
まとめ
今回は、設計やコードの品質を保ちながら開発スピードを維持するための、コードオーナー増員の取り組みを紹介しました。
このしくみを活用して昇格課題に取り組み、私は先日コードオーナーに昇格しました。 また、もう1名昇格間近な若手メンバーがいます。
年次や役職によって役割を与えるのではなく、明確な道筋を整えて若手でもコードオーナーを目指せるようにしたいと考えています。
そして、このようなしくみはコードオーナーだけでなくレビュアー育成にも応用できると考えています。
最後に
最近ではAIによるコードレビューの精度も高くなり、そのうち人によるレビューがほぼ不要になるかもしれません。
そうなればレビューする機会が減るだけでなく開発者が実装に集中する時間が増えるので、より開発サイクルが早くなりそうですね。
最後に、ともに開発フロー改善に取り組んでくださる仲間を募集しています。
