・0 pv・5 min read
PMがAIと行うコードレビュー：技術者でなくても品質をチェックする方法
「コードが読めないPM」の限界を打ち破る
「開発チームから『コードレビューお願いします』と言われても、正直何をチェックすればいいか分からない...」
PM・システム企画として働いていると、こんな場面に遭遇することありませんか？技術的な詳細は分からないけれど、品質管理の責任は感じている。でも具体的に何をすればいいのか分からない。
私も同じ悩みを抱えていました。しかし、生成AIを活用することで、非技術者でも有意義なコードレビューができることを発見したんです。
今日は、技術的なバックグラウンドがなくても実践できる、AIを活用したコードレビュー手法をお伝えします。
非技術者がコードレビューで果たすべき本当の役割
まず、PMがコードレビューで何を見るべきかを整理しましょう。
技術者が見る観点
- 構文エラー、パフォーマンス、セキュリティホール
- コーディング規約、設計パターンの適用
- テストの網羅性、リファクタリングの必要性
PMが見るべき観点
- 要件との整合性：実装が仕様通りになっているか
- ビジネスロジックの妥当性：業務フローを正しく反映しているか
- 運用観点の考慮：エラー処理、ログ、メンテナンス性
- ユーザー体験への影響：パフォーマンス、使いやすさ
実は、PMだからこそ気づける観点がたくさんあるんです。
AIを使った非技術者向けコードレビューの5ステップ
Step 1：要件理解の確認
コードを見る前に、まず「このコードが何をするものか」をAIに説明してもらいます。
プロンプト例：
このコードが何をする処理なのか、
ビジネス的な観点で説明してください。
特に、ユーザーからの視点で
どんな機能を実現しているかを教えてください。
[コードをここに貼り付け]
AIの回答例：
「このコードは、ECサイトでユーザーが商品を購入する際の決済処理を実装しています。具体的には、クレジットカード情報を受け取り、外部の決済サービスAPI に送信し、結果を データベースに保存する機能です...」
Step 2：要件との整合性チェック
AIの説明を聞いて、仕様書と照らし合わせます。
チェックポイント：
- 実装されている機能が仕様書の記載と一致しているか
- 想定していない処理が含まれていないか
- 仕様書にある機能が漏れていないか
発見できる問題例：
- 「仕様では『支払い方法はクレジットカードのみ』だったが、コードにはコンビニ決済の処理も含まれている」
- 「ポイント付与の処理が実装されていない」
Step 3：エラーハンドリングと運用観点の確認
プロンプト例：
このコードについて、運用面での問題点を教えてください。
特に以下の観点で分析してください：
1. エラーが発生した時、ユーザーにどんな影響があるか
2. 障害時の原因調査に必要なログが出力されているか
3. システム管理者が異常を検知できる仕組みがあるか
4. データの整合性が保たれているか
[コードをここに貼り付け]
PMだからこそ気づける問題：
- 「決済エラー時にユーザーに分かりやすいメッセージが表示されない」
- 「障害調査に必要な情報がログに記録されていない」
- 「処理途中でエラーが発生した場合のデータ不整合リスク」
Step 4：ビジネスロジックの妥当性チェック
プロンプト例：
このコードのビジネスロジックについて、
以下のような業務上の問題がないか分析してください：
1. 業務フローとして不自然な処理はないか
2. 法的な制約や規制に抵触する可能性はないか
3. 他のシステムとの連携で問題となりそうな点はないか
4. 将来的な仕様変更時に対応が困難になりそうな箇所はないか
業務背景：[ここに業務の説明を入力]
[コードをここに貼り付け]
Step 5：ユーザー体験の観点での評価
プロンプト例：
このコードが実装されたシステムを
エンドユーザーが使用する際の体験について、
以下の観点で問題点を指摘してください：
1. 処理時間が長すぎてユーザーが離脱しそうな箇所
2. エラー時にユーザーが混乱しそうな点
3. 使いにくさを感じさせる可能性のある処理
4. データの見せ方で改善できる点
[コードをここに貼り付け]
実践事例：決済システムのレビューでバグを未然防止
発見した問題
技術的には問題ないが、業務的に問題があったケース：
AIの分析により、以下の問題を発見：
-
決済処理のタイムアウト設定が5秒
- 技術的には適正値
- しかし、業務要件では「外部API応答時間は最大10秒想定」だった
- ユーザーが決済途中でエラーになる可能性
-
エラーメッセージが技術者向け
- システムエラー詳細がそのまま表示される仕様
- 一般ユーザーには理解困難
- サポート業務の負荷増加が予想される
-
ログ出力の不備
- 成功ケースのログは詳細
- しかし、失敗ケースの原因特定に必要な情報が不足
- 障害対応時に原因調査が困難になる
修正提案と効果
修正提案：
- タイムアウト値を業務要件に合わせて調整
- ユーザー向けエラーメッセージの整備
- 障害調査に必要なログ項目の追加
効果：
本番リリース後、決済関連の問い合わせが 60%削減、障害対応時間が 40%短縮 されました。
PMがコードレビューで使える実践テンプレート
基本レビューテンプレート
【1. 機能理解】
このコードの機能を、ビジネス的な観点で説明してください。
[コード貼り付け]
【2. 要件整合性】
以下の仕様と照らし合わせて、漏れや相違がないかチェックしてください。
仕様：[仕様書の該当部分を貼り付け]
【3. 運用観点】
エラーハンドリング、ログ出力、監視の観点で問題点を指摘してください。
【4. ユーザー体験】
エンドユーザーの体験で問題となりそうな点を教えてください。
【5. 総合評価】
PMの立場から見て、このコードで考慮すべき追加観点があれば教えてください。
専門分野別テンプレート
【決済・課金システム】
- 金額計算の精度は適切か
- 決済エラー時の処理は適切か
- 法的な要件（消費税、領収書等）は満たしているか
【会員管理システム】
- 個人情報の取り扱いは適切か
- 退会処理でデータが適切に削除されるか
- 不正アクセス対策は十分か
【在庫管理システム】
- 在庫数の整合性は保たれるか
- 同時更新時の制御は適切か
- 在庫切れ時の処理は業務フローに合致するか
よくある質問：「技術が分からないのに口出ししても...」
Q: 技術的な詳細が分からないのに、レビューコメントをして良いものでしょうか？
A: むしろ、非技術者の視点こそが重要です。技術者は技術的な正しさに注目しがちですが、PMはビジネス要件との整合性や実際の運用での問題に気づくことができます。
Q: AIの分析結果をどこまで信頼して良いですか？
A: AIの分析は「問題の可能性」を示すものとして捉えましょう。最終的な判断は、開発チームとの議論を通じて行うことが重要です。
Q: 開発チームからの反発はありませんか？
A: 最初は「技術が分からないのに...」という反応もありました。しかし、実際に業務的な問題を発見できるようになると、「PMならではの視点」として評価されるようになりました。
まとめ：PMだからこそ気づけるコード品質の問題
PMがAIを活用してコードレビューに参加することで、
- 要件と実装の乖離を早期発見できる
- 運用・保守の観点から品質向上に貢献できる
- ユーザー体験の視点で改善提案ができる
- チーム全体の品質意識を向上させられる
技術的な詳細が分からなくても、ビジネス要件を熟知しているPMだからこそ気づける問題がたくさんあります。
AIという強力なパートナーを得た今、私たちPMもコード品質の向上に積極的に貢献できる時代になったのです。
明日のレビュー依頼から、ぜひ試してみてください。きっと新しい発見があるはずです。
次回は「要件定義書をAIに壁打ちしてもらう：抜け漏れを防ぐ企画術」をお届け予定です。企画段階での品質向上にAIを活用する方法を詳しく解説しますので、お楽しみに！