Well-Architected Operational Excellenceの詳細 → DevOpsプラクティス
ソース駆動開発
パターン
| 参照すべき場所 | 外観 |
|---|---|
| バージョン管理の設定 | ✅ 無関係なファイルを除外するように.forceignoreが設定されたSalesforce DXプロジェクト構造を使用して、Gitソース形式で保存されたすべてのメタデータ。すべてのチーム メンバーが中央リポジトリからコピー |
| スクラッチ組織の使用 | ✅ 開発者は機能作業のためにソースから一時的なスクラッチ組織を作成し、バージョン管理に変更を確定して、機能完了後にスクラッチ組織を破棄します。 |
| Commit Messages (コミットメッセージ) | ✅ すべてのコミットメントには、変更内容と理由を説明する明確で簡潔なメッセージが含まれます。メッセージはチームの慣習 (例: "feat:"、"fix:"、"docs:") に従います。 |
| 変更追跡 | ✅ バージョン管理で取得されたすべてのメタデータの変更 (著者 ID、タイムスタンプ、正確な変更を示す差分を含む) |
| コードレビュープロセス | ✅ 本番でバインドされたすべての変更は、マージ前にレビュー承認が必要な取り込みリクエストを通過します。宣言型構成ではコードと同じ精査を受けます。 |
| ロールバック手順 | ✅ Checkoutまたは復元操作でGit履歴から以前のバージョンをリカバリ可能。本番以外の環境でテストされたロールバック手順をチームが文書化済み |
| 監査履歴 | ✅ コンプライアンス要件とセキュリティ調査をサポートするバージョン管理で保持される完全な変更履歴 |
| ブランチ戦略 | ✅ チームの規模とリリース頻度に適した一貫した Git ブランチモデル (GitFlow、GitHub フロー、またはトランクベース) が文書化および適用される |
| 組織ベースからの移行 | ✅ 組織ベースの開発で習慣が定着する前に、ソリューションライフサイクルの早い段階でソース駆動開発への移行を完了 |
| .gitignore 設定 | ✅ リポジトリでは、生成されたファイル、ユーザー固有の設定、ログイン情報は除外され、チームがバージョン管理するソースファイルのみが含まれます。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| 情報源としての組織 | ⚠️ 開発は共有 Sandbox で直接実行され、メタデータは後からバージョン管理にエクスポートされます。組織とバージョン管理が異なっているとリリースに失敗します。 |
| 不適切な .gitignore | ⚠️ リポジトリには、生成されたファイル、ユーザー固有の設定、大きなバイナリ、またはログイン情報が含まれるため、リポジトリが肥大化し、セキュリティが侵害されるリスクがある |
| あいまいなコミットメッセージ | ⚠️ 「バグ修正」や「更新」などのコミットでは、何が変更されたのか、なぜ変更されたのかが説明されず、監査調査や将来のメンテナンスの妨げになる |
| 大規模な頻度の低いコミット | ⚠️ 開発者は小さな増分コミットではなく大きな変更セットを毎週複数回コミットする。レビューが困難で、障害を切り分けるのが難しい |
| メインに直接コミット | ⚠️ 開発者がレビューと検証をスキップしてメイン/本番ブランチに変更を直接プッシュし、品質ゲートを排除 |
| 分岐戦略なし | ⚠️ チームに一貫したブランチモデルがなく、開発者が任意のブランチ名とマージパターンを作成し、混乱とマージの競合が生じる |
| Git のバイナリファイル | ⚠️ リポジトリサイズが肥大化し、コピー操作が遅くなる Git 専用の大きなバイナリファイル (PDF、動画、アーカイブ) |
| Committing Credentials (ログイン情報の確定) | ⚠️ バージョン管理にコミットされた API キー、パスワード、インテグレーションログイン情報、またはセキュリティトークン。後のコミットから削除された後でもセキュリティの脆弱性が生じる |
| マージの競合の無視 | ⚠️ マージの競合は、分析なしで片側を受け入れることで解決され、変更が失われたりバグが発生したりする |
| コミット検証なし | ⚠️ チームは、確定されたメタデータが実際に意図した変更を表していることを検証しません。メタデータ形式のエラーや意図しない変更は見逃されます。 |
Sandbox 戦略
パターン
| 参照すべき場所 | 外観 |
|---|---|
| Developer Sandbox | ✅ 個々の開発者は Developer Sandbox を使用して機能作業、単体テスト、迅速な反復を行います。各開発者には専用の環境があります。 |
| Developer Pro Sandbox | ✅ 管理パッケージを開発しているチームやストレージ制限の引き上げが必要なチームは、Developer Pro Sandbox を使用してコラボレーション作業を行います。 |
| Partial Copy Sandbox | ✅ インテグレーションテストでは、データテンプレートを使用して設定された代表的なデータサンプル (オブジェクトあたり 10,000 レコード) を含む Partial Copy Sandbox を使用します。 |
| Full Copy Sandbox | ✅ パフォーマンステスト、本番同様のステージング、データ移行の検証では、完全な本番データと設定が含まれる Full Copy Sandbox を使用します。 |
| データ機密性コントロール | ✅ Full Copy Sandboxアクセスは本番データを必要とするロールに制限され、必要に応じて本番以外の用途にもShield Platform Encryptionデータ マスキングが適用されます。 |
| インテグレーションエンドポイント設定 | ✅ 各 Sandbox 層は外部インテグレーションの対応するテストエンドポイントに接続します。本番インテグレーションは Sandbox から接続しません。 |
| 環境固有の設定 | ✅インテグレーションアーキテクチャでは、カスタムメタデータ型またはカスタム設定を使用して、環境ごとにエンドポイント URL、ログイン情報、機能フラグを外部化します。 |
| 更新後の自動化 | ✅ Sandboxの更新により、自動化されたSalesforce CLIスクリプトがトリガーされ、インテグレーション認証情報、テスト データのシーディング、機能のフラグ状態、メールの送信可能性など、Sandbox固有の設定が復元されます。 |
| 更新スケジュール | ✅ Sandbox の更新スケジュールが文書化されて通知されます。チームの中断を最小限に抑えるために、活動の少ない期間に更新が計画されます。 |
| データテンプレート | ✅ Partial Copy Sandbox では、適切に設計されたデータテンプレートを使用して、参照整合性を維持しながらオブジェクト全体の代表的なデータを選択します。 |
| 命名規則 | ✅ Sandbox は、目的、所有者、更新サイクルを示す明確な命名規則 (「dev-integration-q2」、「uat-release-2-4」など) に従います。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| 共有開発 Sandbox | ⚠️ すべての開発者が 1 つの共有 Sandbox で互いの変更を上書きして作業するため、リリース可能な状態について混乱が生じる |
| 古い Sandbox | ⚠️ Sandbox が本番構成から大幅に乖離して数か月間更新されず、担当外の環境でテストするとリリースの失敗につながる |
| フルコピーのデータガバナンスなし | ⚠️ 本番 PII、財務データ、HIPAA データを含む Full Copy Sandbox。アクセス制御やデータマスキングなしで開発チーム全体がアクセスできます。 |
| Sandbox からの本番インテグレーション | ⚠️ Sandbox は本番インテグレーションエンドポイントに直接接続するため、本番データや外部システムに影響するテストトランザクションのリスクが生じる |
| 更新後の手動設定 | ⚠️ Sandbox の更新では、設定の復元を手動で数時間行う必要があります。オーバーヘッドにより、Sandbox を必要な頻度で更新することができなくなります。 |
| Sandbox ドキュメントなし | ⚠️ Sandbox の目的、更新スケジュール、データコンテンツ、アクセス手順に関するドキュメントがチームになく、開発者がどの環境を使用するかを推測している |
| 単一環境種別 | ⚠️ チームはすべての目的で 1 つの Sandbox 種別 (通常は Developer または Full Copy) のみを使用しているため、活動ごとに適切な Sandbox 戦略の利点を享受できない |
| Sandbox Hoarding | ⚠️ 個人またはプロジェクトに割り当てられ、不要になった Sandbox がリリースされない。ライセンスが使用可能であるにもかかわらず、人為的に不足している。 |
| 不十分なテストデータ | ⚠️ Sandbox のテストデータは本番データの特性 (量、リレーション、エッジケース) を表していないため、非現実的な環境でのテストでは本番の問題を見落とします。 |
CI/CD パイプライン
パターン
| 参照すべき場所 | 外観 |
|---|---|
| ソースコミットフェーズ | ✅ 開発者がコンテキストと根拠を説明する明確なコミットメッセージを使用して Git の機能ブランチに変更をコミットする |
| 静的分析フェーズ | ✅ Salesforce Code AnalyzerはApexでセキュリティの脆弱性(OWASP Top 10)、パフォーマンスのアンチパターン(ループのSOQL、ループのDML)、コード品質の問題(複雑さ、重複)、ガバナ制限のリスクをスキャンし、数秒で実行して迅速にフィードバックを提供します。 |
| 単体テストフェーズ | ✅ Apexテストは、一時的なスクラッチ組織または専用のインテグレーションSandboxでビジネス ロジックとガバナ制限コンプライアンスの検証を実行し、適切に分離されたテストを5分以内に完了 |
| 検証リリースフェーズ | ✅メタデータは、Salesforce CLIを使用してインテグレーションSandboxにリリースされます。変更を確定せずにテストを実行する検証のみのリリースの場合は --checkonlyフラグを使用します。 |
| インテグレーションテストフェーズ | ✅ 自動テストでは、マルチコンポーネントワークフロー、外部インテグレーション契約、プラットフォームイベントフロー、非同期処理チェーンをテストデータ管理と共有インテグレーション環境に対して検証します。 |
| セキュリティスキャンフェーズ | ✅追加のセキュリティ ツールがハードコードされたログイン情報、脆弱な連動関係、CRUD/FLS違反、コンプライアンス ポリシー違反をスキャンし、重要な発見でビルドが破損する |
| UAT リリースフェーズ | ✅ すべての自動化ゲートを通過する変更は、ビジネス検証のためにユーザー受け入れテスト環境にリリースされます。リリースは自動化される場合もあれば、変更リスクに基づいて手動での承認が必要な場合もあります。 |
| 本番リリースフェーズ | ✅ UAT承認後、自動ワンクリック実行、包括的なログ記録、即時ロールバック機能を使用して変更を本番にリリース |
| Pipeline Execution Time (パイプライン実行時間) | ✅ 一般的な変更ではエンドツーエンドのパイプラインが15分以内で完了し、迅速なフィードバックが可能。大規模な導入や広範なテスト スイートではより長い |
| アーティファクトの作成 | ✅パイプラインでは、コンプライアンスとトラブルシューティングのためにリリースパッケージ、テスト結果、セキュリティスキャンレポート、実行ログが保持されます。 |
| Pipeline Tooling (パイプラインツール) | ✅チームはプラットフォーム ネイティブCI/CDにSalesforce DevOpsセンターを使用するか、外部プラットフォーム(GitHubアクション、GitLab CI、Azure DevOps、CircleCI、Jenkins、Copado、Gearset、AutoRABIT)と統合します。 |
| 失敗通知 | ✅ パイプラインの失敗により、診断コンテキストを使用して著者および関連チャネルを確定するための通知がトリガーされ、迅速な修正が可能になります。 |
| 支店の保護 | ✅ マージ前にCIチェックと承認レビューに合格する必要があるメイン/本番ブランチが保護され、直接コミットが防止される |
| 環境プロモーション | ✅ 定義されたプロモーションパス (開発 → インテグレーション → UAT → 本番) と各フェーズでの検証による変更フロー |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| 手動リリース | ⚠️ 変更セットまたはSalesforce CLIコマンドを使用して手動でリリースされ、ステップが統一されていない。人為的ミス、ステップの欠落、監査証跡がない。 |
| 静的分析なし | ⚠️ パイプラインで Salesforce Code Analyzer や同様のツールがスキップされる (セキュリティの脆弱性、パフォーマンスのアンチパターン、コード品質の問題が本番環境に達する) |
| 不十分なテスト | ⚠️ Pipeline はインテグレーションテストを実行したり主要なユーザーフローを検証したりせずに、75% 以上のカバー率のみを検証します。回帰は通過します。 |
| セキュリティスキャンなし | ⚠️ パイプラインでハードコードされたログイン情報、脆弱な連動関係、CRUD/FLS 違反がスキャンされることはありません。本番またはセキュリティレビューでセキュリティ問題が発見されます。 |
| パイプライン実行に時間がかかる | ⚠️ 頻繁なコミットとフィードバックループの遅延を緩和し、開発者が大きな変更を累積する頻度を減らすには、エンドツーエンドのパイプラインに 45 ～ 60 分以上かかります。 |
| Ignored Pipeline Failures (無視されるパイプラインの失敗) | ⚠️ チームはパイプラインの失敗を無視または上書きして期限に間に合わせる。品質ゲートは実際の管理ではなく劇場用になる |
| テスト環境パリティなし | ⚠️ CI/CD は、本番とは異なる構成、制限、データ特性の環境で検証されます。検証に合格しても本番での成功は保証されません。 |
| 欠落しているロールバック機能 | ⚠️ Pipelineはリリースを自動化するが自動ロールバックは提供せず、不適切なリリースからの回復には手動の緊急手順が必要 |
| リリースログなし | ⚠️ 包括的なログなしで導入が実行され、失敗のトラブルシューティングや導入の監査が困難になる |
| All-or-Nothing テスト | ⚠️ Pipeline では、変更内容に関係なく、変更ごとにすべてのテストが実行されます。ドキュメントの更新に対しても 30 分間のテストスイートが実行されます。 |
安全なリリース方法
パターン
| 参照すべき場所 | 外観 |
|---|---|
| 機能フラグ | ✅ 高リスクの変更は、カスタムメタデータ型またはカスタム設定の背後で機能を無効にしてリリースされ、ユーザーを危険にさらすことなく本番環境でのテスト、セグメントへの段階的なロールアウト、A/Bテスト、設定変更による即時ロールバックが可能です。 |
| 機能フラグの範囲 | ✅ 重要なビジネスプロセス、パフォーマンスを重視する業務、新しいインテグレーションパターンに影響するリスクの高い変更のために予約された機能フラグ。すべての機能にフラグが必要なわけではありません。 |
| カナリア諸島配備 | ✅ ビジネスクリティカルな変更は、まず小規模なユーザーサブセットにリリースします (権限セットまたはユーザー属性の絞り込みにより 5 ～ 10 %)。カナリアコホートでは、ロールアウトを拡張する前に成功率、パフォーマンス、エラー率を測定するために 24 ～ 48 時間集中監視します。 |
| リリースウィンドウ | ✅ 実際のトラフィックパターンを示す Event Monitoring API 使用状況ログによって通知される、使用量の少ない期間にスケジュールされたリリース。ピーク使用量、月末の完了、四半期末の完了、主要なビジネスイベントを回避 |
| リリースコミュニケーション | ✅ 予想される所要時間、影響を受ける機能、ロールバックの決定タイムラインなど、リリース期間に関する事前通知を関係者に送信 |
| ロールバック手順 | ✅ リリース種別ごとに文書化およびテストされたロールバック手順。チームは必要に応じて30分以内にロールバックを実行できます。 |
| ロールバックテスト | ✅ 重要なリリースの前に本番以外の環境で検証されたロールバック手順により、リカバリ機能が存在することを確認 |
| リリース検証 | ✅ リリース後のスモークテストでは、リリース直後に重要なユーザーフロー、インテグレーションエンドポイント、主要な機能を検証します。 |
| 調整の変更 | ✅ 変更が複数のシステムにまたがる場合や、Salesforce および外部プラットフォーム間で同期リリースが必要な場合の調整されたリリース戦略 |
| リリース中の監視 | ✅ リリース期間およびリリース後の観察期間 (24 ～ 48 時間) に有効な、エラー率の急増、パフォーマンスの低下、ユーザーフロー障害の監視を強化 |
| インテグレーションの青と緑のパターン | ✅ Salesforce の外部サービスは、2 つの本番のような環境を維持し、最初に無効にリリースし、検証後にトラフィックを切り替える青緑のリリースを使用します。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| Big Bang リリース | ⚠️ 段階的なロールアウトを行わずに多くの機能、リファクタリング、変更を同時にリリースする大規模なリリース。失敗するとすべてのユーザーにすぐに影響 |
| ピーク時のリリース | ⚠️ 最も使用量が多く、問題によるユーザーへの影響が最大になるピーク営業時間 (日中、月末、四半期末) にスケジュールされたリリース |
| ロールバック計画なし | ⚠️ 導入は文書化およびテスト済みのロールバック手順なしで進められるため、問題が発生した場合、チームは慌てて復旧方法を考える |
| 後付けの機能切り替え | ⚠️ リスクの高い変更に対してプロアクティブに設計するのではなく、問題が発生したときに反応的に追加される機能フラグ。ロールバックオプションをリリースの完全な取り消しに制限 |
| リリース検証なし | ⚠️ リリース後の発煙テストなしで本番に変更がリリースされ、チームはリリースが成功したと想定して次に進みます。数時間後にユーザーが問題を発見 |
| テストされていないロールバック手順 | ⚠️ ロールバック手順は文書化されているが本番以外の環境でテストされたことはなく、実際のインシデント中に手順が失敗したり不十分であることが証明されたりする |
| 同時マルチシステム変更 | ⚠️ 同期や互換性テストなしでリリースされた Salesforce および外部システム全体で調整された変更により、インテグレーション障害が発生する |
| 監視の強化なし | ⚠️ リリース期間中は監視を強化せずにリリースが進む。プロアクティブなアラートではなく、ユーザーからの苦情によって問題が検知される |
| 週末のリリース | ⚠️ メジャーリリースのリリースは、金曜日の夕方または週末 (オンコールの対象範囲が縮小され、ベンダーサポートの対応可能状況が制限される場合) |
テスト戦略
パターン
| 参照すべき場所 | 外観 |
|---|---|
| 単体テストの対象範囲 | ✅ ビジネスルール、エッジケース、エラーパス、ガバナ制限アプローチを検証する有意義なテストカバー率。最小要件の75%を大幅に上回る |
| 単体テスト品質 | ✅ テストはプラットフォーム機能ではなくビジネスロジックを検証します。適切に記述された単体テストは高速 (ミリ秒)、分離 (共有状態なし)、集中 (各テストで 1 つの動作が検証されます) |
| テストデータ戦略 | ✅ テストでは、一般的なテストデータに @TestSetup メソッドを使用します。テストでの SOQL クエリは可能な限り避けます。静的リソースの読み込みには Test.loadData() を使用します。 |
| 外部連動関係のモック | ✅ 単体テストでは、テストスタブと連動関係インジェクションを使用して外部コールアウトをモックし、実際の HTTP 要求なしで高速に実行できます。 |
| インテグレーションテスト | ✅ Sandbox で実行されているトリガー、フロー、プラットフォームイベント、一括処理ジョブ、外部コールアウト間のインタラクションを代表的なテストデータで検証 |
| インテグレーションテストの信頼性 | ✅ インテグレーションテストは反復可能で確定的です。散発的な失敗は、プラットフォームイベントリプレイ ID や一括処理ジョブポーリングなどの同期メカニズムで対処します。 |
| エンドツーエンドテスト | ✅ 自動ブラウザーテスト (Selenium、Playwright、Provar) は、ユーザーが操作するのとまったく同じ方法で UI を使用してシステムを実行するビジネスクリティカルなフローのユーザージャーニーを完全に検証します。 |
| E2E テストの焦点 | ✅ E2E テストでは、実行時間 (テストあたりの分数) が遅く、UI の変更によるメンテナンスの負担が大きいため、最も価値の高いユーザーパスに焦点が絞られます。 |
| 負荷テスト | ✅ Salesforce 負荷テストサービスまたはサードパーティツールを使用して、実際の同時ユーザー負荷とデータ量でパフォーマンスを検証します。ガバナ制限の問題、ロックの競合、パフォーマンスの低下を明らかにします。 |
| Load Test Frequency (読み込みテスト頻度) | ✅ メジャーリリース前および定期的 (四半期ごと) に負荷テストを実行し、現在の生産量の 3 倍から 5 倍のパフォーマンスを検証します。 |
| テストピラミッド | ✅ バランスの取れたテスト分布: 多数の単体テスト (数百、数分)、少数のインテグレーションテスト (数十、数分)、少数の E2E テスト (20 分未満)、基本の迅速なフィードバック、上部の包括的な検証 |
| テスト分離 | ✅ テストは相互に連動せず、任意の順序で実行できます。各テストはシステムをクリーンな状態にしておくか、@TestSetup を使用して開始点の一貫性を確保します。 |
| ネガティブテストケース | ✅ テストでは、エラー処理、入力規則の適用、権限の適用、悪条件下での正常な機能低下を検証します。 |
| ガバナ制限テスト | ✅ SOQL クエリ制限、DML 制限、CPU 時間、ヒープサイズなど、ガバナ制限に近づいている動作を具体的に検証するテスト |
| 継続的なテスト実行 | ✅ CI/CDパイプラインを介してコミットごとにテストが自動的に実行され、テストが失敗すると上位環境へのリリースが妨げられます。 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| 対象範囲のテスト | ⚠️ ビジネスルールやエッジケースを検証しないで 75% 以上のカバー率を達成するためだけに作成されたテスト。何もアサートしないテストや簡単なコードパスをテストするテスト |
| プラットフォーム機能のテスト | ⚠️ テストでは、ビジネスロジックの検証ではなく、Salesforce がレコードまたは SOQL クエリの作業を保存することを検証します。プラットフォーム保証の労力を浪費します。 |
| 模擬戦略なし | ⚠️ 単体テストでは外部システムに対して実際のコールアウトを実行します。テストは低速で、外部システムの可用性が脆弱であり、API 制限を消費します。 |
| 散発的なテストの失敗 | ⚠️ 実行タイミング、データの状態、テスト実行順序に基づいてテストが予測外に合否判定される。チームは失敗を無視してテストに合格するまで再実行することを学ぶ |
| インテグレーションテストなし | ⚠️ 単体テストのみが存在し、チームはトリガー、フロー、プラットフォームイベント、一括処理ジョブが正しく連携することを検証しない |
| 手動 E2E テストのみ | ⚠️ 各リリース前に手動で検証された重要なユーザーフロー。自動化された E2E テストなし。手動テストでシナリオが満たされない場合に本番環境でリグレッションが発見 |
| 負荷テストなし | ⚠️ 実際の同時負荷ではパフォーマンスが検証されていない (本番で検出されたガバナ制限の問題、ロックの競合、パフォーマンスの低下) |
| テストデータの連動関係 | ⚠️ テストは、組織に存在する特定のレコードに依存するか、特定のユーザー設定を前提としています。Sandbox の更新時または設定の変更時に中断されます。 |
| 陰性テストケースなし | ⚠️ テストではハッピーパスシナリオのみを検証し、エラー処理、検証適用、権限チェックはテストしません。障害モードは検出されません。 |
| スキップされたテスト | ⚠️ 失敗したテストは @isTest からコメントアウトされ、修正されるのではなくスキップされます。無視されるテストが増えるにつれてテストスイートは経時的に劣化します。 |
コードレビュー
パターン
| 参照すべき場所 | 外観 |
|---|---|
| 補償範囲の確認 | ✅ 本番でバインドされたすべての変更は、マージ前の承認を必要とする取り込みリクエストを介したコード レビューで流れます。これには、Apex、Aura、LWC、フロー、入力規則、権限セット、共有ルールが含まれます。 |
| 条件チェックリストの確認 | ✅ セキュリティ (CRUD/FLS 適用、入力検証)、パフォーマンス (一括処理、SOQL 最適化)、ガバナ制限コンプライアンス (処理パターン、再帰防止)、メンテナンス性 (命名、ドキュメント、複雑さ)、テストカバー率 (有意義なテスト、エッジケース)、アーキテクチャの一貫性 (設計パターン、懸念の分離) をカバーする明示的なチェックリスト |
| サイズ制限の確認 | ✅ プル要求は 400 行未満の有意義な変更に抑えられ、徹底的なレビューが可能。大きな機能は小さな増分変更に分割され、個別にレビュー可能で個別にリリース可能 |
| Review Timing (タイミングの確認) | ✅ 1営業日以内にレビューを完了することで、開発の勢いを維持し、迅速なフィードバックを提供。レビューの遅延によりコンテキストの切り替えオーバーヘッドが発生 |
| 自動事前レビューチェック | ✅ 静的分析、単体テスト、セキュリティスキャンは人間がレビューを要求する前に自動的に実行されます。自動チェックで機械的な問題が検出されるため、レビュー担当者は設計とビジネスロジックに集中できます。 |
| 分散レビュー責任 | ✅ コード レビューの責任をチーム全体に分散してボトルネックを回避し、Knowledgeを共有します。ジュニア開発者はシニア コードを確認し、レビュー中に自分のコードを説明します。 |
| コメント品質の確認 | ✅ レビュー担当者は、論理的根拠に基づいて具体的でアクション可能なフィードバックを提供します。必要な変更 (ブロッキング問題) と提案 (改善すべき点) を区別します。 |
| ドキュメントの確認 | ✅ プル要求の説明では、変更された内容、変更された理由、実行されたテスト、および特別なリリースの考慮事項やロールバック手順が説明されます。 |
| 宣言型設定レビュー | ✅ フロー、入力規則、権限の変更はコードと同じ審査厳格度が適用されます。構成はアーキテクチャであり、精査が必要です。 |
| コメントのフォローアップ | ✅ マージ前に解決されたすべてのレビューコメント、回答された質問、変更された内容、提案を採用しなかった理由 |
アンチパターン
| 参照すべき場所 | どんな悪い感じか |
|---|---|
| コードレビューなし | ⚠️ ピアレビューなしで本番ブランチに直接コミットされた変更。主欠陥検出メカニズムを排除 |
| ゴム印 | ⚠️ レビュー担当者は実際に変更を確認することなく数秒で取り込み要求を承認し、レビューは品質ゲートではなくチェックボックスのコンプライアンスになります。 |
| 単一レビュー担当者のボトルネック | ⚠️ コードのレビューを承認された上級開発者は1人だけ。ボトルネックと単一障害点が発生し、Knowledgeが分散ではなく集中化 |
| 大量の取り込み要求 | ⚠️ 複数の機能にまたがる数千行の変更が含まれる取り込み要求で、表面的な検査につながる徹底的なレビューができない |
| 遅延レビュー | ⚠️ プル要求は数日または数週間レビューされず、開発者はコンテキストを失って他の作業に移行します。レビューコメントは、開発者が精神的なコンテキストを切り替えたときに届きます。 |
| レビュー条件なし | ⚠️ チームは、レビュー担当者が何を調べるべきかの明示的な基準がない。レビューの品質はレビュー担当者によって大きく異なる。スタイルを重視するレビュー担当者もいれば、ロジックを重視するレビュー担当者もおり、包括的なレビュー担当者はいない。 |
| テストなしで確認 | ⚠️ レビュー担当者は、ブランチを取得してローカルでテストしたり、自動テストに合格したりすることなく、コードインスペクションのみに基づいて変更を承認する |
| 無視される自動チェック | ⚠️ レビュー担当者は静的分析、セキュリティスキャン、単体テストに失敗したにもかかわらず取り込み要求を承認し、自動化された品質ゲートの目的を逸脱する |
| 敵対的レビューの文化 | ⚠️ レビューがコラボレーションによる品質向上ではなく、個人的な批判や競争的課題になり、学習や心理的安全性が低下する |
| 宣言型レビューなし | ⚠️ フロー、入力規則、権限セット、共有ルールは、Apexコードが精査を受けている間にレビューなしで導入され、宣言型構成で品質ギャップが生じる |