Zenn
🫡

20% Review で変わる開発効率

に公開
coding
review
idea

はじめに

こんにちわ。

今回は、開発チームの生産性を劇的に向上させる「20% Review」を中心としたコードレビュー体制についてご紹介します。
「20% Review」とは、20年前に本かブログで読んで以来ずっと使っている表現なのですが、探してもそれらしいものが出てこず。。。ご存知の方がいらっしゃいましたら教えてください。

で、これは弊社の開発チームで実際にこれから運用させようと議論している3段階レビューのプロセスで、Juniorエンジニアの不安解消と実装やり直しの低減を目的としています。

従来のコードレビューの課題

よくある問題

開発していると、チームでこんな経験をすることはありませんか？

  • 実装完了後に「そもそもアプローチが違う」と指摘される
  • Juniorエンジニアが一人で悩んで時間を浪費する
  • レビューで大きな手戻りが発生し、スケジュールが遅延する
  • バグ発見に時間を取られ、設計の本質的な議論ができない

根本的な問題

従来のコードレビューは、実装完了後の品質チェックに重点を置いていました。

しかし、現代の開発環境では技術的な発展により以下のような変動が起きています：

  • 構文エラーや基本的なバグ → 自動化ツールでリアルタイムに検出が可能
  • コーディング規約 → 生成AIで自動修正まで可能
  • セキュリティ脆弱性 → CI/CDでプロセスとして検出や管理が可能

つまり、人間がレビューすべき本当に価値のある部分に集中する事が容易になっていますし、むしろそこは人間がヒューマンレビューで担保するべきポイントとなります。

20% Reviewとは何か

アプローチ

20% Reviewは、実装の20%完成段階（例えばフローチャートやコードコメントのみの状態）で方向性を確認する初期アプローチです。

なぜ20%なのか

## 20% Review のタイミング

### コードコメントの段階
- [ ] 実装予定の処理フローをコメントで記述
- [ ] 主要な関数・クラスの役割をコメントで説明
- [ ] データ構造・API呼び出しの概要をコメント化
- [ ] エラーハンドリング方針をコメントで明記

### 壁打ち・相談の実施
- [ ] 「この実装アプローチで合ってますか？」
- [ ] 「この部分の修正で影響範囲は適切ですか？」
- [ ] 「要件の解釈はこれで正しいですか？」
- [ ] 「使用するライブラリ・技術選択は妥当ですか？」

この段階なら、大きな方向転換も容易で、心理的な負担も少ないのです。

20% Reviewの4つの目的

  1. 🎯 Juniorエンジニアの不安解消

    • 実装前の方向性確認で悩む時間を削減
    • 「これで合ってるかな？」の不安を早期解決

  2. 🔄 実装アプローチの早期検証

    • コーディングやり直しの防止
    • 効率的な開発サイクルの実現

  3. 📍 改修箇所の適切性確認

    • 影響範囲の妥当性チェック
    • 予期しない副作用の防止

  4. 🚨 基本的なミスの早期発見

    • 設計理解不足・要件誤解の防止
    • 手戻りコストの最小化

グローバルと戦っていくためのレビューの真の目的

人間の洞察力でしか発見できない、コードの価値に集中するためにレビューを活用しましょう。

1. システム思考・アーキテクチャ洞察（最重要）

  • 設計の一貫性: 全体アーキテクチャとの整合性
  • 将来拡張性: 3-5年後のスケール要件への対応
  • 技術的負債の予防: 短期的解決が長期的問題を生まないか
  • システム境界の適切性: マイクロサービス間の責任分離

2. ビジネス価値最大化

  • 要件の本質理解: 表面的な仕様ではなく、真のビジネス課題解決
  • ユーザー体験の一貫性: 機能間でのUX統一性
  • 競合優位性: 他社では実現困難な実装アプローチ

3. チームのナレッジ / 資産の蓄積

  • ドメイン知識の伝播: ビジネスロジックの背景・意図の共有
  • 技術判断の透明化: なぜその技術選択をしたかの記録
  • 暗黙知の形式知化: 経験豊富なメンバーの知見の言語化

4. イノベーション創出

  • 新しいアプローチの発見: 従来手法を超える革新的解決策
  • 技術的ブレークスルー: 業界標準を上回る実装手法

レビュー対象外（自動化で担保が出来るため）

❌ 構文エラー・型エラー
❌ コーディング規約
❌ 基本的なバグ (単体テスト・統合テストで検証)
❌ セキュリティ脆弱性

3段階レビュープロセスの詳細

時間が書いてありますが、エンジニアの成熟度：ジュニア / ミドル / シニア で設定時間は変えても良いと思っています。また、レビューア / レビューイのそれぞれのスキルや得意範囲でも変わると思いますので、アサイン時にアレンジすると良いと思います。

Stage 1: 20% Review（15分以内）

時間配分と観点

要件理解・設計解釈（8分）

  • 要件の解釈は正しいか？
  • 設計意図を正しく理解しているか？
  • ビジネスロジックの理解に誤りはないか？
  • エッジケースの考慮は適切か？

実装アプローチ（5分）

  • 実装方針は適切か？
  • 修正箇所の選択は妥当か？
  • 影響範囲の見積もりは正しいか？
  • 技術選択は要件に適しているか？

リスク回避（2分）

  • 大きな手戻りが発生しそうか？
  • 追加調査・確認が必要か？
  • 他チームとの調整が必要か？
  • GAPがある部分はリクエスターに報告できているか？

判定基準

  • ✅ APPROVE: アプローチに問題なし → 実装開始
  • 🔄 REQUEST_CHANGES: 実装方針見直し必要 → 実装方針議論へ
  • 💬 COMMENT: 軽微な確認・提案のみ → 実装開始

Stage 2: Second Review（30分以内）

実装完了後の品質確認に集中します。

ビジネスロジック実装（15分）

  • 要件の完全な実現
  • エッジケースの考慮
  • データ整合性の保証
  • ユーザー体験の一貫性

コード品質（10分）

  • 適切な抽象化レベル
  • 保守性・可読性
  • パフォーマンス最適化
  • 並行処理の安全性

システム統合（5分）

  • 他機能への影響
  • API設計の一貫性
  • 運用監視の考慮
  • ログ出力の適切性

Stage 3: Final Review（10分以内）

チーム資産化と全体整合性の確認に焦点を当てます。

ドキュメント（5分）

  • 設計判断の記録
  • 複雑なロジックの説明
  • 運用時の注意事項
  • 次に改修する開発者への申し送り

知識共有（3分）

  • 学習ポイントの明確化
  • ベストプラクティスの抽出
  • 他機能への応用可能性

最終確認（2分）

  • マージ準備完了
  • 関連タスクの完了
  • デプロイ計画の確認

効果的な戦略

変更規模別での時間配分の目安

変更規模 20% Review Second Review Final Review Total
Small (1-50行) 5分 15分 5分 25分
Medium (51-200行) 10分 25分 8分 43分
Large (201-500行) 15分 45分 15分 75分
Extra Large (501+行) 分割必須

相談しやすい環境作り

文化的な取り組み

  • 「分からないことは恥ではない」文化の醸成
  • 積極的な質問を評価する仕組み
  • Senior エンジニアの壁打ち対応時間確保
  • Slack等での気軽な相談チャンネル活用

レビュイー（実装者）の準備

  • 実装方針をコメントで記述
  • 不安な点・確認したい点を明記
  • 参考にした資料・ドキュメントをリンク
  • 想定している影響範囲を記載

レビュアーの対応

  • 迅速なフィードバック（24時間以内、というか当日か翌朝）
  • 具体的な改善提案
  • 参考資料・サンプルコードの提供
  • 必要に応じて口頭でのコミュニケーション活用

AI支援による効率化

CursorなどのAI Editorの活用

  • 変数名・関数名の適切性チェック
  • コメントの必要性判定
  • 複雑な処理の分割提案
  • リファクタリング機会の特定
  • セキュリティベストプラクティスの提案
  • エラーハンドリングパターンの改善

ヒューマンレビューとの連携

AIからの提案を参考にしつつ、最終的には：

  • ビジネス価値の観点での判断
  • 技術的制約とビジネス要件のバランス評価
  • チーム固有の文脈を考慮した決定

これらは人間にしかできない、重要な判断です。

チーム固有の「宗教的」ルール

なぜ「宗教的」ルールが重要なのか

技術的合理性よりもチーム文化・価値観を重視するルールがあります。

これらは一見非合理的に見えても、チームの一貫性と品質を保つ重要な役割を果たします。

アーキテクチャ面

Lambda Function Design

  • Single Responsibility: 1つのLambdaは1つのビジネス機能のみ
  • Stateless Principle: 状態はDatabaseに外部化
  • Cold Start Optimization: 初期化処理は必ず最適化

API Design Philosophy

  • RESTful Purity: REST原則の厳格な遵守
  • Versioning Strategy: URLパスでのバージョニング必須
  • Error Response: RFC7807準拠のエラーレスポンス

コーディング面

Python/Lambda Specific

  • Type Hints: 全ての関数・メソッドに型ヒント必須
  • Docstring Format: Google Style Docstring必須
  • Exception Handling: カスタム例外クラスの使用必須

React/TypeScript Specific

  • Component Structure: Atomic Design原則の厳格適用
  • State Management: Redux Toolkit使用必須
  • Testing Philosophy: Testing Library優先

宗教的ルール違反への対応

  • Minor Violation: コメントで指摘、修正提案
  • Major Violation: REQUEST_CHANGES、実装方針議論必須
  • Philosophy Conflict: Tech Lead判断、チーム議論

新規機能開発時の特別な観点

システム思考レビュー

Cross-Service Impact Analysis

  • マイクロサービス間の依存関係変化
  • データフロー全体への影響
  • パフォーマンス特性の変化
  • 障害伝播パターンの変化

Scalability Future-Proofing

  • 10倍のトラフィック増加への対応
  • 新機能追加時の拡張性
  • 技術的負債の蓄積防止
  • 運用コストの長期的影響

機能統合性レビュー

Existing Feature Compatibility

  • 既存機能との整合性
  • データ移行の必要性
  • UI/UX の一貫性
  • 権限・セキュリティモデルの統一

User Journey Optimization

  • エンドツーエンドのユーザー体験
  • 機能間の遷移の自然さ
  • 学習コストの最小化
  • エラー回復パスの提供

よくある落とし穴と対策

1. 20% Reviewの形骸化

課題: コメントだけ書いて実質的な検討をしない
対策: 具体的なチェック項目を設定し、レビュアーの質を担保

2. 時間超過の常態化

課題: 設定時間を大幅に超過してしまう
対策: タイマー使用、事前準備の徹底、分割の検討

3. 宗教的ルールの押し付け

課題: 新メンバーへの過度な強制
対策: ルールの背景説明、段階的な導入、柔軟性の確保

4. AI依存の過度な進行

課題: AIの提案を暗黙的に受け入れる
対策: ビジネス価値の観点での最終判断、チーム文脈での考慮

さいごに

私たちは 20% Reviewを中心とした3段階のレビュープロセスを整備することで、
チーム全体の技術力向上、知識共有の促進、そしてチームのイノベーション創出の効果を狙っていきます。

このコードレビュー体制について、皆さんのチームではどのような工夫をされていますか？
特に初期（早い段階での）フィードバックの仕組みやJunior エンジニアの支援方法があれば、ぜひコメントで教えてください！

Discussion