Step12: 非機能要件の検討
このStepでは、Step 1〜11 で積み上げてきたプラットフォームを非機能要件の観点でチェックし、対応すべき項目を優先度で整理します。本コースでは実装まで進めず、検討で終わらせて半年の総まとめとします。
1. 課題の実施
1.1 目的・背景
半年かけて自分で組み立てた自作アプリケーションのプラットフォームを、フレームワークに沿って俯瞰的に評価し、対応すべき項目を優先度で整理します。「作ったものに対して自分で足りないものを見つける力」を養うとともに、この後実装する場合の優先順位を自分でつけられるようになることが目標です。実装まで進めるかどうかは、本コース終了後の学習方針として自分で判断してください。
1.2 実施要件
チェック基準
ここまで構築したプラットフォームを、以下のいずれかのチェック基準に沿って非機能要件の観点で評価してください。
非機能要件チェックリスト
非機能要件チェックリスト は、DevOps Camp の教材内容に沿って観点と実装例を具体的にまとめた独自のチェックリストです。学んだ内容との対応関係が明確で、実装イメージを持ちながら評価を進めやすい点が特徴です。
一方、業界標準として広く採用されているチェックリストではないため、業務で採用する際には対外的な共通言語として使いにくい面があります。
DevOps Camp で学んだ内容を教材の並びに沿って振り返りたい場合や、実装イメージを持って評価を進めたい場合に向いています。
チェックリストの内容は TSV としても提供しています。Excel や Google スプレッドシートに取り込んで、対応状況や所感を記入していくとスムーズです。
AWS Well-Architected Framework
AWS Well-Architected Framework は、AWS が提唱する設計原則で、業界で広く採用されているフレームワークです。運用・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性の6つの柱に沿って評価します。
社外での認知度が高いため、業務で「Well-Architected の観点で見直した」と説明する際の説得力があります。一方、フレームワークとしての性質上、具体的な実装例は抽象的な記述にとどまるため、評価時に自分の構成に照らして読み替える必要があります。
業務でも通用する共通言語で評価したい場合や、抽象的な観点から自分で具体化する練習をしたい場合に向いています。
Well-Architected Framework の 6 柱に含まれる Question（合計 57 個）を、AWS 公式ドキュメントから抽出した TSV として提供しています。Excel や Google スプレッドシートに取り込んで、対応状況や所感を記入していくとスムーズです。
その他のチェック基準
上記以外にも、以下のようなチェック基準があります。本課題では扱いませんが、実際にはこれらを組み合わせて使う場面もあります。
- NIST Cybersecurity Framework：米国 NIST がサイバーセキュリティ全般を体系化したフレームワークです
- CIS Benchmarks：各種システム・サービスのセキュリティ設定に関するガイドラインです
チェック方法
採用したチェック基準の項目ごとに、以下の観点で状況を整理してください。
| 観点 | 記載内容 |
|---|---|
| 対応状況 | 対応済み / 一部対応 / 未対応 のいずれかで判定する |
| 対応内容 | 対応済み・一部対応の場合、どのように対応されているかを記載する |
| 対応要否 | 一部対応・未対応の場合、追加で対応が必要か（要 / 否）を判定する |
| 対応方針 | 対応が必要な場合、どのような対応を行うかを記載する |
| 優先度 | 高（すぐに対応が必要）／ 中（対応は必要だが、すぐではない）／ 低（いずれ対応が必要）のいずれかで判定する |
1.3 課題提出
下記内容を提出フォームより提出してください（提出はプレミアムプランでご利用いただけます）。
| 項目 | 内容 |
|---|---|
| 概要 | 評価対象としたプラットフォームの範囲・採用したチェック基準・評価のアプローチを簡潔に記載する |
| チェック結果 | 配布した TSV を Google スプレッドシートまたは Excel に取り込み、チェック方法で示した観点を項目ごとに記入する。スライドに評価結果をまとめる形式でも可 |
| まとめ | 評価中に苦労したこと、気づいたこと、学んだこと。加えて半年間の総振り返り |