「頑張ったのに差し戻し」を減らす：Apexレビュー観点チェックリスト（設計／UT）
Contents
導入：Apex開発あるある（差し戻しが起きる瞬間）
Apex開発で、こういう場面はよくあります。
- 動くのに差し戻される（UATで動いたのに「運用できない」で戻る）
- レビュー指摘が毎回同じ（Bulk、Sharing、CRUD/FLS、例外処理、ログ）
- 見積がブレて説明コストが増える（影響範囲が後から増える）
- UTが「薄い」と言われる（カバレッジはあるのに分岐・assert・runAsが弱い）
- Sandboxは通るのに本番で落ちる（権限、共有、既存データ、レコードタイプ差）
これは根性の問題ではありません。多くは レビュー観点の抜け（前提・境界・運用想定の欠落） で起きます。
つまり、気合より チェックリスト が効きます。
結論：差し戻しは「観点漏れ」を潰せば減る
差し戻しを減らすコツはシンプルです。
レビューで突かれがちな観点を 事前に自分で通す。これだけです。
この記事では、Salesforce（Apex中心）で頻出する差し戻し原因を分解し、
設計レビュー用／UTレビュー用のチェックリスト に落とし込みます。
この記事で得られること
- 設計レビューで突かれやすい観点を、漏れなく先回りできる
- UTレビューで「薄い」と言われにくい、最低限のテスト設計が分かる
- 指摘の再発を減らし、差し戻し＝やり直しを減らせる
- 見積・説明・調整のコストも下げられる
想定読者
- Salesforce開発（特に Apex／Trigger／Batch／Queueable）担当
- 設計レビュー／UTレビューの差し戻しで消耗している
- 「言われがちなこと」を 自分の型 にして再発を止めたい
差し戻しが起きる原因トップ10（Apexあるある）
差し戻しは、だいたいこのあたりで発生します。
- Bulk対応不足（ループ内SOQL／DML）
- 例：forループ内でSELECT／DMLしている
- 対策：集約して1回で処理、Map／Setで突合
- Sharing／権限（CRUD／FLS）未考慮
- 例：管理者では動くが一般ユーザーで落ちる
- 対策：with sharingの方針、CRUD／FLSチェック、runAsでUT
- 例外処理が弱い（握りつぶし／ログ不足）
- 例：try-catchで握って終わる、原因が追えない
- 対策：例外方針、ログ方針、ユーザー通知方針
- ガバナ制限の想定がない
- 例：大量データでLimit超え
- 対策：件数見積、Query最適化、非同期化検討
- 既存自動化（Flow／Validation等）との干渉
- 例：Apexは正しいがFlowで別挙動
- 対策：影響範囲に「自動化」を必ず含める
- トランザクション境界が曖昧
- 例：部分成功、ロールバック、再実行設計がない
- 対策：再実行可否、冪等性、失敗時の扱い
- データ設計の前提が漏れている
- 例：レコードタイプ、必須項目、参照整合性
- 対策：前提データ条件を設計に明記
- 非機能（監視・運用・リカバリ）がない
- 例：障害時に検知できない、復旧できない
- 対策：ログ、監視、再処理手順、手動救済
- テスト観点が「正常系だけ」
- 例：境界値、権限差、異常系、分岐が未カバー
- 対策：分岐表／観点表で網羅
- 「何をもってOKか」が曖昧
- 例：完了条件がない → レビューが終わらない
- 対策：受入条件、期待結果、確認手順を定義
設計レビュー観点チェックリスト（Apex）
レビュー前にこれを通すだけで、差し戻しはかなり減ります。
A. 目的・前提・境界（まずここ）
- 目的（何を解決するか）が1文で言える
- 前提（対象ユーザー、対象データ、件数規模）が明記されている
- 非対象（やらないこと／除外条件）が書いてある
- 成功条件（受入条件／期待結果）が明確
B. 影響範囲（Salesforce特有の落とし穴）
- 対象オブジェクト／項目／権限（プロファイル・権限セット）
- 既存自動化（Flow／Validation／Workflow相当）
- 連携（API、バッチ、外部IF）
- レコードタイプ／共有設定／組織の設定差分
C. 実装観点（Apexの地雷）
- Bulk対応（ループ内SOQL／DMLなし、集約・Map化）
- ガバナ制限の想定（データ量、実行回数）
- with sharing方針、CRUD／FLSの扱い
- 例外処理：握らない／ログ／ユーザー通知の方針
- 冪等性（再実行で壊れない）とロールバック方針
D. 運用・監視・復旧（ここが刺さる）
- 監視できるログが残る（原因が追える）
- 障害時の手動救済手順がある
- 再処理手順（再実行条件／対象抽出）がある
UTレビュー観点チェックリスト（Apex）
「カバレッジはあるのに薄い」を防ぐ観点です。
A. テストの基本設計
- 正常系だけでなく、異常系／境界値がある
- 分岐（if／else、例外、権限差）を狙って踏んでいる
- assertが「結果の意味」まで見ている（数だけで終わらない）
B. 権限・共有（runAsが鍵）
- runAsで一般ユーザー条件でも通る／落ちるが検証できている
- CRUD／FLS想定がある（参照不可項目の扱いなど）
C. データ設計（テストデータが雑だと落ちる）
- レコードタイプや必須項目を満たしている
- 依存関係（参照整合性）が正しい
- データ件数を増やしてBulkを踏むテストがある
D. 非同期（Batch／Queueable／Future）
- startTest／stopTestが適切
- 期待する副作用（更新件数、状態遷移）をassertしている
あわせて読みたい
バッチ処理とガバナ制限の仕組みを理解しよう
【Salesforce】Apexテストクラス開発で使うアノテーション「＠IsTest」とは何かまとめてみた
【システムエンジニア】主従関係と参照関係について学ぼう
まとめ：差し戻しは「気合」ではなく「観点の型」で潰せる
差し戻しを減らす最短ルートは、レビューで刺さる観点を 先に自分で潰す ことです。
まずは「設計レビューのA〜D」をテンプレ化し、次にUTの「分岐＋runAs＋Bulk」を最低限押さえる。これだけで再発が減ります。
本日はここまで。では、また次の記事でお会いしましょう。
