ユニファ開発者ブログ

ユニファ株式会社プロダクトデベロップメント本部メンバーによるブログです。

複数プロジェクト運用チームにおける効率的なコードレビューの仕組み作り

コードレビュー

はじめに

こんにちは。iOSエンジニアのキムです。私たちのチームでは複数のプロジェクトを並行開発しており、それぞれのプロジェクトに担当者が割り当てられています。この環境で効率的かつ高品質なコードレビューを実現するため、明確なルールとプロセスを整備してきました。この記事では、私たちが実践している具体的な運用方法と、その過程で得た知見を共有します。

コードレビューの重要性

私たちのチームでは、コードレビューに期待する効果を明確に定義しています。

期待できる効果

  • 仕様や実装方針の共有: プロジェクト横断的な知識の循環
  • 潜在的なバグの早期発見: 複数の視点でコードをチェックすることで、単独では気づきにくいバグや設計上の問題を早期に発見
  • コーディング規約の認識合わせ: チーム全体のスタイル統一
  • 継続的な品質向上: 技術的負債の予防
  • 可読性の向上: 「見られる」意識がコード品質を高める
  • バス因数の向上: 属人化を防ぎ、チーム全体でプロジェクトを理解

チーム構成と課題

構成

iOSチーム数名で、複数のアプリを並行開発。各メンバーに主担当プロジェクトがあります。

複数プロジェクト環境での課題

課題1: プロジェクト固有の理解が困難

  • ドメイン知識や専門用語の理解に時間がかかる
  • ビジネスロジックの妥当性の判断が難しい

課題2: レビューの観点がバラバラ

  • メンバーによってチェック観点が異なる
  • レビュー品質にバラつき

課題3: コンテキストスイッチのコスト

  • 頻繁なプロジェクト切り替えで生産性低下
  • 集中力の分散

私たちの基本ルール

プルリクエストのタイミング

基本は「開発・テストが完了したタイミング」でプルリクエスト作成。

プルリクエストに記載する情報

  • 目的や実装の方針: なぜこの実装が必要か、どのようなアプローチか
  • 補足説明: 複雑な部分の理由、プロジェクト固有の用語説明
  • レビュー期限: 急ぎの場合はタイトルに明記、Slackで通知

レビュアーの設定

チームメンバー全員をレビュアーに設定。現在は数名規模のため、2名以上からの承認でマージ可能としています。

コードレビューのチェックリスト

  • メソッド名や変数名が分かりやすいか
  • コードの重複がないか
  • 可読性が悪くないか
  • バグやパフォーマンス低下の心配がないか
  • 分からない部分は質問する
  • 良いコードは褒める
  • 指摘する場合は、なぜ悪いコードなのか説明を書く

今後の改善計画

1. 自動化のさらなる推進（一部運用中・継続改善）

現在導入済み

SwiftLint: コーディング規約の自動チェック

チームのコーディング規約を自動でチェックし、プルリクエストを出す前にローカル環境でも確認できるようにしています。

自動チェック項目の例：

  • 行の長さ制限（120文字以内）
  • force unwrapping（!）の使用を警告
  • 未使用の変数やインポートを検出
  • 命名規則の統一（lowerCamelCase、UpperCamelCase）
  • trailing whitespaceの自動削除

導入効果：レビュアーが「ここの行が長すぎます」「force unwrappingは避けましょう」といった細かい指摘をする必要がなくなり、コーディングスタイルの統一も自動的に実現。

Unit Tests: 自動テスト実行

プルリクエスト作成時に自動でテストが実行され、テストが通らない場合はマージできない仕組みになっています。これにより、「これテストした？」という質問や手動でのテスト確認が不要になりました。 これらにより、形式的なチェックが自動化され、レビュアーは本質的な部分（設計、ロジック、可読性）に集中できるようになりました。

今後の計画: AI活用によるレビュー準備

さらなる効率化のため、AI活用を検討中です。

具体的な活用方法:

プルリクエスト作成前にClaude/ChatGPTにコードをレビュー依頼し、以下の観点でチェック

// 例：AIにレビューを依頼
「以下のSwiftコードの改善点と潜在的なバグを指摘してください」

func updateCell(with data: UserData?) {
    nameLabel.text = data!.name
    ageLabel.text = String(data!.age)
}

// AIからのフィードバック例：
// 1. force unwrapping（!）の使用は危険です
//    → guard let または optional binding を使用
// 2. データがnilの場合クラッシュします
//    → エッジケースの考慮が必要

チェック項目:

  • メモリリークの可能性（RxSwiftのdisposeBag、クロージャの循環参照）
  • 不要な複雑性（ネストが深い、長すぎるメソッド）
  • エッジケースの考慮漏れ（nil、空配列、ネットワークエラー）
  • 命名規則の改善提案（より分かりやすい変数名やメソッド名）
  • パフォーマンスの問題（O(n²)のループなど）

活用フロー:

  1. 実装完了後、AIにコードレビューを依頼
  2. AIの指摘を確認し、必要な修正を実施
  3. 修正後、プルリクエストを作成
  4. レビュアーは人間にしか判断できない部分（設計、ビジネスロジック）に集中

期待効果: 初歩的なミスの減少、レビュアーが設計やロジックに集中可能。プルリクエスト作成者の学習にも繋がる。

2. レビューコメントの質向上（検討中）

コメントの書き方についても、今後ルール化をしても良いか検討しています。

現状の課題:

抽象的なコメント
「ここは改善できると思います」
「パフォーマンスが気になります」

目指す方向:

具体的なコメント
「この部分は weak self を使うべきです。
理由: メモリリークの可能性があります。
提案: guard let self = self else { return }
重要度: must fix」

推奨する構造:

  1. 具体的に指摘（何が問題か）
  2. 理由を説明（なぜ必要か）
  3. コード例を提示（改善案）
  4. 重要度を明記（must fix / suggestion）

期待効果: レビューの往復減少、学習速度向上、建設的な文化の醸成。

まとめ

複数プロジェクト環境で効率的なコードレビューを実現するには、明確なルールと継続的な改善が重要です。私たちのチームでは、基本ルールを定めながらも、自動化の推進やレビューコメントの質向上など、今後も改善を続けていく予定です。 この記事が、同じように複数プロジェクトを運用しているチームの参考になれば幸いです。

ユニファでは子育て環境の充実に貢献していくことに関心がある仲間も募集中です！

jobs.unifa-e.com