12.2 チェックリスト

これらのチェックリストは、実践的で、すぐに使えるクイックリファレンスです。どのチェックリストも、プルリクエストのテンプレート、wikiのページ、チケット、レビュー会議のアジェンダにコピーし、項目を自分の文脈に合わせてください。各項目を、人が検証して「はい」か「いいえ」で答えられるものとして扱います。チェックリストは記憶の助けと共有の標準であって、判断の代わりではありません。当てはまらない項目は削除し、自分の領域が要求する項目を加えてください。

これらをうまく使うための指針:

• 人々が実際に完了できる程度にチェックリストを短く保ちます。チェックリストが日常的に飛ばされるなら、長すぎるか、一般的すぎます。
• 機械が検証できる項目(書式、テスト、スキャン)は自動化し、人間の注意が判断の項目に向かうようにします。
• チェックリストをバージョン管理し、定期的に見直します。決して変わらないチェックリストは、おそらく使われていません。
• プロセスにとって区別が重要なときは、ブロックする項目と助言的な項目を区別します。

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

他の人の変更を調べるレビュアー向け。

• 変更が、その説明とリンクされたチケットが述べることを行っている。
• 範囲が単一の論理的な関心事に集中していて、無関係な変更は分けられている。
• 設計が既存のアーキテクチャに合い、避けやすい結合を持ち込んでいない。
• ハッピーパスだけでなく、エッジケース、エラーの経路、失敗の様式が扱われている。
• テストが存在し、意味があり、挙動が退行したら失敗する。
• 命名、構造、コメントが、コードを将来の読み手に理解できるものにしている。
• シークレット、資格情報、トークン、個人データがコミットされていない。
• セキュリティ上機微な入力が適切に検証、エンコード、パラメータ化されている。
• 公開インターフェース、契約、後方互換性が保たれている、あるいは意図してバージョン管理されている。
• ロギング、メトリクス、エラー報告が、変更を本番で運用するのに十分である。
• ドキュメント、ランブック、設定が変更に合わせて更新されている。
• フィードバックがブロックする問題と提案に分けられ、人ではなくコードについて述べられている。

プルリクエスト作成者のチェックリスト

レビューを依頼する前の作成者向け。

• PRが、一度に注意深くレビューできる程度に小さく集中している。
• 説明が、何が変わったか、なぜ、どう検証したかを述べている。
• リンクされたチケット、課題、設計文書が、レビュアーに必要な文脈を与えている。
• すべての自動チェックが、ローカルあるいはCIで通っている(ビルド、リント、書式、テスト、スキャン)。
• 新しい、あるいは変更された挙動がテストでカバーされている。
• 機械的なリファクタリングが、挙動の変更から分けられている。
• セルフレビューが完了している。自分の差分を一行ずつ読んだ。
• デバッグコード、コメントアウトされたブロック、シークレット、余計なファイルが残っていない。
• データベースのマイグレーション、フィーチャーフラグ、設定の変更が文書化され、元に戻せる。
• 破壊的変更が、移行の経路とともに明示的に指摘されている。
• レビューの助けになる所には、スクリーンショット、録画、サンプル出力が含まれている。
• 適切なレビュアーと、必要な役割ベースの承認者が依頼されている。

完了の定義

作業項目が完了と見なされる前に満たさなければならない、共有の標準。

• チケットの受け入れ基準がすべて満たされ、実演できる。
• コードが同僚にレビューされ、必要なレビュアーに承認されている。
• 自動テストが書かれ、通り、変更とともにマージされている。
• コードがメインラインにマージされ、パイプラインを通じてきれいにデプロイされる。
• 合意された重大度の閾値の既知の欠陥が、開いたまま残っていない。
• ドキュメント、ヘルプテキスト、ランブックが更新されている。
• オブザーバビリティが整っている。関連するログ、メトリクス、アラートが存在する。
• セキュリティとプライバシーへの含意が検討され、対処されている。
• ユーザー向けの所では、変更のアクセシビリティ要件が満たされている。
• フィーチャーフラグが設定され、展開計画が合意されている。
• プロダクトオーナーあるいは利害関係者が成果を受け入れている。
• 後続の仕事が、暗黙に残されず、追跡されるチケットとして捉えられている。

本番ローンチ/ゴーライブの準備

重要な変更や新しいサービスを本番に出荷する前に。

• 展開計画が、段階的あるいはカナリアのステップと成功基準を含めて文書化されている。
• ロールバック計画が文書化され、テストされ、素早く実行できる。
• 容量と負荷のテストが、システムが期待されるピークの需要を満たすことを示している。
• 監視、ダッシュボード、アラートが稼働しており、ローンチ前に検証されている。
• オンコールのカバレッジが予定され、対応者がシステムを知っている。
• 最もありそうな失敗と運用のシナリオにランブックが存在する。
• 依存関係、統合、サードパーティが準備できていることが確認され、レート制限が理解されている。
• セキュリティレビューと必要な承認が完了している。
• データ移行があれば、検証済みの巻き戻しとともにエンドツーエンドでテストされている。
• フィーチャーフラグが、再デプロイなしに変更を無効にできるようにしている。
• 必要な所では、法務、プライバシー、コンプライアンスの承認が得られている。
• コミュニケーション計画が、利害関係者、サポート、顧客をカバーしている。
• 実行か中止かの決定が、名指しされた所有者によって、明示的な基準に照らして下されている。

セキュリティレビュー/脅威モデルのチェックリスト

変更やシステムのセキュリティの姿勢を評価するために。

• 信頼の境界とデータフローが特定され、文書化されている。
• 認証が、それを必要とするすべての入口で徹底されている。
• 認可のチェックが、すべての行動とリソースに最小権限を徹底している。
• すべての外部入力が検証され、出力がその行き先に合わせてエンコードされている。
• シークレットが、コードや設定ではなく管理されたボールトに保存され、ローテーション可能である。
• データが、分類が要求するとおり、転送中と保存時に暗号化されている。
• 依存関係が既知の脆弱性についてスキャンされ、最新に保たれている。
• 信頼できない入力について、インジェクション、デシリアライゼーション、SSRFのリスクが緩和されている。
• セキュリティ上関連するイベントが、機微なデータを記録せずにログに残される。
• レート制限、クォータ、悪用への保護が、公開されたエンドポイントを守っている。
• エラーメッセージが、スタックトレース、内部、機微な詳細を漏らさない。
• STRIDEなどで特定された脅威が、緩和策あるいは受け入れたリスクとともに記録されている。
• セキュリティテスト(SAST、DAST、侵入テスト)が計画されている、あるいは完了している。

プライバシーとデータ保護(DPIA形式)のチェックリスト

個人データや機微なデータを伴う処理向け。

• 収集される個人データが目録化、分類され、必要なものに最小化されている。
• 各処理目的の適法な根拠あるいは権限が文書化されている。
• 目的の制限が徹底されている。データは述べられた目的にだけ使われる。
• 保持期間が定義され、削除あるいは匿名化が自動化されている。
• データ主体の権利(アクセス、訂正、削除、可搬性)を果たせる。
• 同意に頼る場合、それが自由に与えられ、特定され、撤回できる。
• 第三者と処理者が、適切なデータ保護の条件に拘束されている。
• 国境を越える移転が、適切な法的な移転の仕組みを持っている。
• 個人データへのアクセスが、制限され、記録され、レビューされている。
• 個人へのプライバシーのリスクが評価され、緩和あるいはエスカレーションされている。
• データ侵害の検知と通知のプロセスが定義されている。
• 機能について、設計段階と初期設定でのプライバシーの選択が文書化されている。
• 必要な所では、データ保護責任者あるいはプライバシーのレビュアーが承認している。

アクセシビリティ(WCAG)のチェックリスト

WCAGの原則に沿った、ユーザー向けインターフェース向け。

• すべてのコンテンツがキーボードだけで到達でき、操作できる。
• フォーカスの順序が論理的で、目に見えるフォーカスの表示がある。
• テキストの色のコントラストが目標の比率(本文では通常4.5:1)を満たしている。
• 画像と非テキストのコンテンツに、意味のある代替テキストがある。
• フォームの項目に、関連づけられたラベルと明確なエラーメッセージがある。
• 見出し、ランドマーク、構造が意味的にマークアップされている。
• インタラクティブなコンポーネントが、支援技術に正しい名前、役割、状態を公開している。
• コンテンツが200%のズームと小さな画面でリフローし、使えるままである。
• 時間制限が調整可能で、動きや自動再生のコンテンツを一時停止できる。
• 色が情報を伝える唯一の手段ではない。
• メディアに字幕があり、必要な所には書き起こしあるいは音声解説がある。
• インターフェースがスクリーンリーダーと自動のアクセシビリティツールでテストされている。

API設計レビューのチェックリスト

APIを公開あるいは変更する前に。

• リソースと操作の命名が一貫していて予測可能である。
• 契約が機械可読なスキーマ(たとえばOpenAPI)で規定されている。
• バージョニング戦略が定義され、後方互換性が保たれている、あるいは管理されている。
• ページネーション、フィルタリング、ソートが一貫した慣習に従っている。
• エラー応答が、一貫した構造、コード、対処可能なメッセージを使っている。
• すべての操作について、認証と認可が規定されている。
• 入力の検証とサイズの制限が定義され、徹底されている。
• 再試行が期待される操作について、冪等性が定義されている。
• レート制限、クォータ、スロットリングの挙動が文書化されている。
• タイムアウト、再試行、失敗のセマンティクスがクライアントに明確である。
• 応答での機微なデータの露出が最小化され、正当化されている。
• ドキュメントに、各操作とエラーのケースの例が含まれている。
• 廃止の方針とサンセットのタイムラインが定義されている。

アーキテクチャ決定(ADR)レビューのチェックリスト

提案されたアーキテクチャ決定記録をレビューするために。

• 文脈と解決される問題が明確に述べられている。
• 決定が、単一の選択として曖昧さなく述べられている。
• 少なくとも二つの現実的な代替案が検討され、比較されている。
• 良い面と悪い面の両方の帰結が文書化されている。
• 非機能への影響(パフォーマンス、セキュリティ、コスト、運用性)が扱われている。
• 決定が既存の原則と先行するADRに合っている、あるいはそれらを明示的に置き換えている。
• 影響を受けるチームと利害関係者に相談した。
• 可逆性と変更のコストが評価されている。
• 前提と制約が明示的にされている。
• ステータス(提案、承認、置き換え)が設定され、日付が付いている。
• 決定が見つけやすく、関連するシステムからリンクされている。
• 後続の行動や移行が、追跡される仕事として捉えられている。

インシデント対応のチェックリスト

進行中の本番インシデントの間。

• インシデントを宣言し、単一のインシデントコマンダーを割り当てる。
• 深刻度、範囲、顧客への影響を評価して伝える。
• 専用のコミュニケーションチャンネルとインシデントの記録を開く。
• 明確な役割を割り当てる。コマンダー、コミュニケーションリード、運用リード。
• 根本原因の分析より、緩和とサービスの復旧を優先する。
• 決まった周期で、利害関係者に定期的な状況の更新を投稿する。
• 出来事、行動、決定のタイムラインを、起こると同時に捉える。
• 必要なときは、追加の対応者あるいはベンダーにエスカレーションする。
• データや規制が関わる場合は、法務、セキュリティ、コンプライアンスに通知する。
• 修正を検証し、システムが完全に回復したことを確認する。
• インシデントを正式に閉じ、解決を伝える。
• 人々が散らばる前に、責めないポストモーテムを予定する。

ポストモーテムのチェックリスト

インシデント後の振り返りレビュー向け。

• レビューが責めないもので、システムと寄与した要因に焦点を当てている。
• インシデントの事実に基づくタイムスタンプ付きのタイムラインが文書化されている。
• 顧客と事業への影響が定量化されている(期間、範囲、コスト)。
• 検知が分析されている。問題がどのように、いつ気づかれたか。
• 対応が分析されている。何が役立ち、何が復旧を遅くしたか。
• 単一の根本原因だけでなく、寄与した原因が特定されている。
• 何がうまくいかなかったかだけでなく、何がうまくいったかも記録されている。
• 行動項目が具体的で、所有者に割り当てられ、期限がある。
• 行動項目が、予防、検知、緩和に対処している。
• 後続の項目が、通常の積み残しで完了まで追跡されている。
• 他の人が学べるよう、ポストモーテムが広く共有されている。
• インシデントにわたる構造的なパターンが定期的にレビューされている。

オンコールの準備のチェックリスト

誰かがオンコールのシフトに入る前に。

• 対応者が、必要なすべてのシステム、ダッシュボード、ツールにアクセスできる。
• アラートが対応者に確実に届き、テストされている。
• エスカレーションの経路と二次のオンコールの連絡先が知られていて最新である。
• 最も一般的で最も深刻なアラートにランブックが存在する。
• 対応者が、これらのシステムのオンボーディングあるいはシャドーイングを完了している。
• 最近の変更、進行中のインシデント、既知の問題が引き継がれている。
• アラートの閾値が、雑音と誤ったページングを最小化するよう調整されている。
• 対応者が、インシデントを宣言してコマンダーに連絡する方法を知っている。
• 対応者の作業環境から本番にアクセスできる。
• コミュニケーションチャンネルと利害関係者の連絡先が文書化されている。
• オンコールのスケジュールが公表され、カバレッジに隙間がない。
• オンコールの報酬、期待、負荷の上限が明確である。

SLO定義のチェックリスト

サービスレベル目標を定義するとき。

• SLOが守るユーザーの旅あるいは能力が明確に特定されている。
• サービスレベル指標(SLI)が、明確で測定可能な量として定義されている。
• SLIが、可能な所ではユーザーの視点から測定されている。
• 目標が、100%ではなく、ユーザーが実際に必要とする水準に設定されている。
• 測定の窓(たとえば28日間のローリング)が規定されている。
• 目標から導かれるエラーバジェットが計算され、理解されている。
• エラーバジェットが尽きたときに何が起こるかを定める方針がある。
• SLIのデータ源が信頼でき、計装されている。
• アラートが、単なる閾値の違反ではなく、バーンレートに結びついている。
• 所有者と利害関係者が、SLOが現実的で意味があることに合意している。
• SLOが文書化され、ダッシュボードで可視である。
• サービスが進化するにつれてSLOを見直し改訂する予定がある。

CI/CDパイプラインのチェックリスト

継続的インテグレーションとデリバリーのパイプライン向け。

• すべてのコミットが、自動のビルドとテストの実行を引き起こす。
• パイプラインが速く失敗し、結果を作成者に明確に報告する。
• リント、書式、静的解析が自動的に走る。
• ユニット、統合、関連するエンドツーエンドのテストがパイプラインで走る。
• セキュリティと依存関係のスキャンがすべてのビルドで走る。
• ビルド成果物がバージョン管理され、不変で、レジストリに保存されている。
• シークレットが安全に注入され、ログに決して出力されない。
• デプロイが自動化され、環境にわたって繰り返し可能である。
• デプロイ戦略(カナリア、ブルーグリーン、ローリング)が定義され、使われている。
• ロールバックが自動化されている、あるいは文書化された単一の行動である。
• パイプラインの権限が最小権限に従い、監査可能である。
• パイプラインの設定がコードとしてバージョン管理に保存されている。
• 必要な所では、ビルドの出所とソフトウェア部品表が生成されている。

インフラストラクチャ・アズ・コードのレビューのチェックリスト

コードとして定義されたインフラストラクチャをレビューするために。

• 変更がすべてコードで表現され、パイプラインを通じて適用されている。
• 適用の前に、計画あるいはドライランの出力がレビューされている。
• 状態が、同時の変更を防ぐロックとともに安全に保存されている。
• リソースが、命名、タグ付け、所有の慣習に従っている。
• 最小権限のIAMのロールとポリシーが使われ、避けられる所にはワイルドカードがない。
• ネットワークの露出が最小化されている。意図しない公開アクセスがない。
• シークレットと機微な値が、ハードコードではなくボールトから参照されている。
• ストレージ、データベース、転送で暗号化が有効である。
• 変更が冪等で、再適用しても安全である。
• 影響範囲が理解されている。破壊的な変更が指摘されている。
• 変更のコストへの影響が考慮されている。
• モジュールが再利用可能で、バージョン管理され、テストされている。
• 帯域外の変更を捉えるドリフト検知が整っている。

AI/MLモデルのリリースのチェックリスト

機械学習モデルを本番にリリースする前に。

• モデルの意図した使用、範囲、限界が文書化されている。
• 学習と評価のデータの出所、ライセンス、同意が検証されている。
• データとモデルがバージョン管理され、再現可能である。
• 性能が、代表的で、取り置いたテストデータで評価されている。
• 公正さと偏りが、関連するサブグループにわたって評価されている。
• モデルが、現行のものあるいはベースラインに対して評価されている。
• 失敗の様式、エッジケース、分布外の挙動が理解されている。
• 安全性、誤用、有害な出力のリスクが評価され、緩和されている。
• ドリフト、データ品質、性能の劣化の監視が整っている。
• 以前のモデルあるいはルールベースの経路へのロールバックまたはフォールバックが存在する。
• 重大な決定に対して、人間による監督あるいは異議申立てが提供されている。
• プライバシーレビューが、学習データと推論の入力と出力をカバーしている。
• モデルカードあるいは同等の文書が、利害関係者向けに公表されている。

データパイプラインの品質のチェックリスト

分析あるいはプロダクトに供給するデータパイプライン向け。

• ソースデータのスキーマが検証され、スキーマの変更が検知される。
• 取り込みが、遅れた、重複した、順序の乱れたレコードを正しく扱う。
• データ品質のチェック(完全性、一意性、範囲)が自動的に走る。
• 失敗したレコードが、静かに落とされず、隔離されて表面化される。
• 変換が、代表的でエッジケースの入力でテストされている。
• パイプラインが冪等で、失敗後に再実行しても安全である。
• 出力の鮮度とレイテンシが、期待に対して監視されている。
• 利用者がデータの出所を知れるよう、系譜が文書化されている。
• 個人データと機微なデータが分類され、適切にマスクあるいは制限されている。
• バックフィルと再処理がサポートされ、文書化されている。
• アラートが、失敗と品質の違反を所有者に通知する。
• 保持と削除の方針が、保存されたデータに徹底されている。
• 下流の利用者とSLAが文書化されている。

オープンソースの取り込みとライセンスレビューのチェックリスト

オープンソースのコンポーネントを採用する前に。

• コンポーネントのライセンスが特定され、承認済みの一覧にある。
• ライセンスの義務(帰属、コピーレフト、告知)が理解され、満たされている。
• あなたの配布モデルとのライセンスの互換性が確認されている。
• プロジェクトが積極的に保守され、健全なコミュニティがある。
• 既知の脆弱性がチェックされ、バージョンが最新である。
• 依存関係とその推移的な依存関係が目録化されている。
• セキュリティの姿勢と過去のインシデントの履歴がレビューされている。
• コンポーネントが、重大な重複なしに本物のニーズを満たす。
• コンポーネントの出口のコストと置き換え可能性が考慮されている。
• コンポーネントがソフトウェア部品表に記録されている。
• 名指しされた所有者が、更新と勧告の追跡に責任を負う。
• 変更した場合、貢献の還元と社内フォークの方針に従っている。

ベンダー/サードパーティのリスクのチェックリスト

外部のベンダーやサービスをオンボードする前に。

• 事業上の必要性と、ベンダーがアクセスするデータが明確に定義されている。
• ベンダーのセキュリティの姿勢が評価されている(認証、監査、質問票)。
• データ処理の条件、所有、離脱時の削除が契約上明確である。
• ベンダーの再委託先とデータの場所が開示され、受け入れられる。
• 関連する規制への準拠が検証されている。
• 稼働率、サポート、SLAのコミットメントが文書化されている。
• 侵害の通知の義務とタイムラインが契約に含まれている。
• アクセスが最小権限に範囲づけられ、取り消せる。
• 事業継続とベンダー失敗の影響が評価されている。
• ロックインを避ける出口とデータ移行の計画が存在する。
• コスト、更新の条件、価格変更の条項が理解されている。
• ベンダーが、見直しの日付とともにリスク登録簿に加えられている。

政府のコンプライアンス(ATO/FedRAMP形式)の準備のチェックリスト

正式な運用認可を要するシステム向け。

• システムの境界とデータフローが定義され、図示されている。
• データが影響の水準と機微さで分類されている。
• 該当する統制の基準線が選ばれ、調整されている。
• システムセキュリティ計画が、各統制がどう実装されるかを文書化している。
• 統制が実装され、証拠が示され、計画に対応づけられている。
• 継続的な監視と脆弱性スキャンが稼働している。
• 行動とマイルストーンの計画が、開いた指摘を是正まで追跡している。
• アクセス制御、監査ログ、アイデンティティ管理が要件を満たしている。
• 暗号化が、承認されたアルゴリズムと検証済みのモジュールを使っている。
• インシデント対応計画が文書化され、テストされている。
• 緊急時と災害復旧の計画が文書化され、テストされている。
• 統制の独立した評価あるいは監査が完了している。
• 認可職員が、認可を与えるのに必要なリスク評価を持っている。
• 再認可の引き金と、継続的な認可の周期が定義されている。