Step4 非機能要件のチェック
Step3まで構築したプラットフォームに対して、各非機能要件をどの程度満たしているかを、各種チェック基準に沿って自ら確認します。
- 構築したプラットフォームを非機能要件の観点で評価する
- 不足している項目を洗い出し、次のStep5で実装するための優先度と対応方針を見立てる
- 「とりあえず動く」状態から「安全に、安定して動く」状態を目指す
1. このステップの目的
Step1〜3で構築したサンプルアプリは「ひとまず動く」状態になります。しかし、これと「実務で運用に耐える」状態は別の話です。可用性、性能、セキュリティ、運用性など、各非機能要件の観点で見ると、改善の余地が必ずあります。
ここで重要なのは、その構成を自らの判断で設計・構築したという事実です。「なぜその技術を選んだのか」「他に選択肢はなかったのか」「何を見落としていたか」を、自分が下した判断に対して振り返ることができます。他人が作った構成を評価するよりも、自分が作った構成を評価するほうが、判断の背景を知っている分だけ深い気づきが得られます。この経験は、将来チームや他人が設計したシステムを評価する場面でも、評価軸を持って臨むための土台になります。
本ステップでは、自分が構築したプラットフォームを非機能要件の観点で客観的に評価します。チェックの観点は事前に提示しません。「可用性が要件を満たしているか」をどう確認するかは、自ら設計に組み込みます。確認方法の選択も判断の一部です。
評価はある程度自身の知識や経験に基づく感覚で進めることもできますが、何らかのチェックフレームワーク（基準）に沿って進めることを推奨します。フレームワークに沿うことで、自分の経験や知識だけではカバーできない観点まで網羅的にチェックできます。採用できるチェック基準の候補は次の「実施要件」セクションで紹介します。
評価の際は、不足している項目を洗い出すだけでなく、すでに実装できている項目についても、どの機能・サービス・設定によって実現されているかを把握しておくことが重要です。「実装できているつもりが、実は要件を満たしていなかった」というケースを避けられるとともに、発表時にも「この観点はこの機能で対応できている」と根拠を持って説明できます。
洗い出した不足項目には、本ステップ内で優先度をつけ、Step5で着手する順序や対応方針の見立てまで行います。具体的な実装計画の詳細・設計・構築はStep5で行います。
2. 実施要件
Step3までで構築したプラットフォームを、何らかのチェック基準（フレームワーク）に沿って非機能要件の観点で評価します。採用するチェック基準は自由に選んで構いません。代表的なチェック基準は以下のとおりです。複数を組み合わせて使うこともできます。
| チェック基準 | 概要 |
|---|---|
| 非機能要件チェックリスト | DevOps Camp で独自に整理した観点で、技術選定からセキュリティ・運用まで網羅的に確認できる |
| AWS Well-Architected Framework | AWS が提唱する設計原則で、6つの柱（運用上の優秀性、セキュリティ、信頼性、性能効率、コスト最適化、持続可能性）からシステムを評価できる |
| NIST Cybersecurity Framework | 米国国立標準技術研究所が定めるサイバーセキュリティの枠組みで、識別／防御／検知／対応／復旧の5機能でセキュリティ態勢を評価できる |
| CIS Benchmarks | CIS が公開する各種システム・サービスのセキュリティ設定ガイドラインに照らして、設定の妥当性を確認できる |
評価にあたっては以下のような流れを想定しています。
- 採用するチェック基準を決める
- 各観点について、構築済みのインフラ構成・設定・コードと照らし合わせて現状の達成度を確認する
- 実装できている箇所は、どの機能・サービス・設定によって実現されているかを記録する
- 不足している箇所と、改善の余地がある箇所をリストアップする
- リストアップした不足項目に優先度をつけ、Step5で着手する順序と対応方針を見立てる
確認方法は机上で構いません。実機での負荷試験や障害注入まで行う必要はなく、構築済みのインフラ構成・設定・コードを照らし合わせる形で評価します。本ステップでは現状把握と優先度判断が目的のため、実装を伴う対応はStep5で行います。
3. 提出物
下記内容を提出フォームより提出してください。
| 項目 | 内容 |
|---|---|
| 概要 | 評価対象としたプラットフォームの範囲、採用したチェック基準、評価のアプローチを、提出物全体のサマリとして簡潔に記載する |
| チェック結果 | 各チェック項目について、現状の達成度（実装できている／一部実装／未実装など）と判断根拠を記載する。実装できている項目は、どの機能・サービス・設定で実現しているかを併せて記載する |
| 優先度と対応方針 | チェック結果で不足と判断した項目について、優先度の判断軸と、Step5で着手する順序・対応方針の見立てを記載する。Step5での実装計画の起点となる |
| まとめ | 評価中に苦労したこと、気づいたこと、学んだことを振り返る |