| 大項目 | ポリシー | 思想やアーキテクチャ | ツール(例) |
|---|---|---|---|
| セキュリティ | セキュリティは後付けではなく、最初から組み込むこと。 各セキュリティスキャンやレビューは定期的またはリリース前に実施し、検出事項は放置せず何らかの対処を行うこと。 注） 対処は解決だけでなく、他の施策による対応、あるいは対応不要の判断も含む。ただし対応不要とする場合は理由を記録しレビューで承認を得ること。 | DevSecOps、SAST / DAST / SCA、脅威モデリング (Threat Modeling) | GitHub Dependabot、Checkov、tflint、Trivy、AWS Inspector |
| セキュリティ | 必要ない権限は極力渡さないこと（最小権限の原則）。 どうしても必要な場合はそのときだけ権限を付与すること（例・ブレイクグラスや短命トークンの利用）。 | 最小権限の原則、RBAC / ABAC、JIT (Just-In-Time) アクセス、PIM、ブレイクグラス手順 | AWS IAM AssumeRole、IAM Identity Center、AWS SSO (短命トークン発行)、CloudTrail(PIMの一環として監査ログの保存)、AWS サービスコントロールポリシー（ブレイクグラスで利用） |
| 信頼性 | すべてのコードはプロダクション品質の基準を満たさなければならない。コード品質はリンター、静的解析ツール、フォーマッタなどのツールと人間またはAIによるレビューによって向上させ、テストによって保証する。コードは仕様とコーディング標準に準拠させること。 厳密なテストファースト開発は必須ではないが、自動テストは常に実装すること。ユニットテストのコードカバレッジはあくまで参考とし、重要ロジックが網羅されていることを優先する。ただし決済などのクリティカルな箇所は100%のカバレッジを実施すること。また全ての関数が一度は呼ばれること。 結合テスト機能のカバレッジは全機能を網羅すること。 | CI (継続的インテグレーション)、静的コード解析、自動テスト (ユニット / 結合 / E2E)、AI支援コードレビュー | GitHub Actions、Checkov、tflint、Claude Code、Gemini、各言語の自動テストツール（例・go test）、Playwright |
| 信頼性 | 信頼性向上は仕組みによって担保すること。一個人の能力や注意力、献身に組織として依存しないこと。 | SRE (Site Reliability Engineering)、IaC、プロセス標準化（例・テストやリリース後の確認、ロールバックの用意の義務付けなど）、フェイルセーフ設計、カオスエンジニアリング、冗長性の確保 | Terraform、Fault Injection Service AWS |
| 信頼性 | 頻繁に行う作業や信頼性が重要な作業はなるべくコード化・自動化すること。手動作業と比べてオペミスが少なく、再現性に勝り、かつAIの活用も容易である。 | CI/CD、IaC (Infrastructure as Code)、ChatOps | git + GitHub、GitHub Actions、Terraform、Docker、Ansible、Slack(連携用) |
| 信頼性 | 重要な変更は内容・理由・影響を記録すること。 また独断で行わず、レビューを経て承認を受けること。 | Pull Request、ブランチ保護ルール、GitOps、チケットドリブン、ITS / BTS (課題管理) | GitHub、GitHub RuleSet、GitHub Issue |
| 運用上の優秀性 | どの作業も標準化を推進すること。誰であれ同じタスクは同じ方法で対応できるべきであるし、同じ目的を持つ設計は同じ構造を持つべきである。 | ベストプラクティスやアーキテクチャの採用、ポリシー、コーディング規約、プロセス標準化 | Terraform Official Documents、ADR、OpenAPI、GitHub テンプレート機能 |
| 運用上の優秀性 | ログやメトリクスを用意し、テストや障害調査を可能にしておくこと。すべてのシステムコンポーネントは可能な限り可観測であるべきである。障害の予兆や発生をシステム的に検知できるようにすること。 | 可観測性 (Observability)、APM、分散トレーシング、ログ管理、メトリクス監視 | CloudWatch、AWS X-Ray、S3、Athena、Datadog、OpenTelemetry、AWS Chatbot、Amazon Connect / PagerDuty、Slack、メール |
| 運用上の優秀性 | 重要な事項は記録を残すこと。（例・本番作業やアーキテクチャ決定など） | ADR (Architecture Decision Record)、監査ログ管理、バージョン管理履歴 | AWS CloudTrail、GitHub Issue、Git |
| 運用上の優秀性 | 十分な品質の成果物の生成を目的とすること。既存プロセスを守っていれば不十分な品質の成果物を出してもよい、とはならない。必要に応じてプロセス改善や例外対応を行い、品質を確保すること。その理由と影響を記録し、適切な担当者の承認を得ていれば、例外対応も差し支えない。 ただし正当な理由なく定められたプロセスを無視してはならない。（例・面倒だからテストせずリリース） ※ これは結果責任を作業者に負わせることではなく、劣化あるいは硬直化したプロセスの弊害の軽減を目的としたポリシーである。 | 継続的改善、承認ワークフロー | SonarQube (Quality Gate機能)、GitHub Environments (承認機能)、Jira Service Management |
| 運用上の優秀性 | 障害発生時は個人のミスを責めるのではなく、ミスを誘発した、あるいは防げなかった『システムやプロセスの欠陥』を特定し、根本原因を解決すること。 | 非難なきポストモーテム (Blameless Postmortem)、根本原因分析 (RCA / 5 Whys)、インシデント管理フレームワーク | Slack、GitHub Issues、git(リポジトリにドキュメントを直接保存) |
| 運用上の優秀性 | 作った仕組みは定期的または必要時に見直すこと。 | レトロスペクティブ (KPT等のフレームワーク)、技術的負債の棚卸し、トイル削減 | Slack、GitHub Issues、git(リポジトリにドキュメントを直接保存)、AWS Well-Architected Tool、AWS Trusted Advisor |
| パフォーマンス効率 | パフォーマンス要件は事前に定義し、継続的に検証すること。本番相当のデータ量でスケーラビリティを確かめること。 ただし最適化はバランスを保たなければならない。明確なパフォーマンス上の必要性がない限り、早すぎる最適化や過度な最適化は避ける。 | パフォーマンステスト / 負荷テスト、オートスケーリング、キャッシュ戦略、データベースのインデックスチューニング | k6、サーバレスのマネージドサービス（AWS LambdaやAmazon Aurora Serverless等）、AWS Auto Scaling、Elasticache、スロークエリログ |
| コスト最適化 | 開発・運用のコスト最適化は要件を満たす範囲内で行うこと。ただし不要な支出は避ける。 | FinOps、クラウドコスト監視・アラート、リソースの自動起動・停止スケジューリング、ライフサイクルルール | AWS Cost Explorer、AWS Budgets、AWS Trusted Advisor、EventBridge Scheduler、AWS Backup |
参考・優先順位をつけるなら？
- バージョン管理システムの導入 … ないとは思えないが、もしないなら
- DevSecOps … 特にIAMとSecurityGroupは本番リリースされると権限縮小が困難
- 予算アラート … 悪くするとビジネス継続に関わるリスクになるので予算アラートだけは優先
- 監査ログ管理 … すぐできる、記録が残らず悪用を牽制できないのは危険
- ログ管理、メトリクス監視 … 障害の予兆・発生に気が付けないのは不味い
- IaC … 生成AIが利用できる今なら手間も少ない。変更管理や自動化の基盤
- CI/CD … 最低限の品質ゲートだけでも確保
- その他 … あとは状況次第で
