「非機能要件は？」「止まっていい時間は？」と聞かれて、「高可用で」「なるべく速く」と形容詞で返した経験はないでしょうか。形容詞のまま設計を始めると、あとから構成のコストや運用の負担が想定とずれ、誰も悪くないのに揉めます。この記事は、非機能要件を数字で合意するとはどういうことかを、可用性を中心に整理します。
この記事の結論
- 機能要件は「何をするか」、非機能要件は「どの品質でするか」です。形容詞ではなく、測れる数字と期間で合意します。
- 可用性は「一定期間のうち、使える時間の割合」です。99.9% は年間約8時間45分、99.99% は約52分の停止までを許す目標です。
- 目標の数字が一段上がると、テスト・自動復旧・運用の水準もコストも上がります。本当に必要な水準を先に決めます。
- 止まると全体も止まる依存が増えると、稼働率は掛け算で下がります。独立した部品を冗長にすると、逆に上がります。
- Well-Architected の柱は見落とし防止の問いです。数字にして合意するのは自分たちで、数字が衝突したら判断を ADR に残します。
非機能要件とは何か｜機能要件との違いを「何をするか／どの品質でするか」で分ける
機能要件は、システムが何をするかです。「注文できる」「在庫を引き当てる」「請求書を PDF で出す」のように、できること・できないことで書けます。
非機能要件は、それをどの品質でするかです。同じ「注文できる」でも、月に何時間まで止まってよいのか、混んだ時間帯でも何秒以内に確定したいのか、誰が見てよい情報なのか、障害が起きたら誰がどう気づくのか、で作り方がまるで変わります。
大事なのは、非機能要件は測れる形で書くということです。「止まりにくい」は感想ですが、「1か月のうち停止してよいのは合計で◯分まで」は確かめられます。確かめられるから、あとで実際の値と見比べられ、構成を比べる物差しにもなります。
WHAT VS HOW WELL要件の2種類
機能要件は何をするか、非機能要件はどの品質でするか
機能要件
何をするか
- 注文できる
- 在庫を引き当てる
- 請求書を PDF で出す
非機能要件
どの品質でするか
- 止まってよい時間を決めて測る
- 応答時間の目標を決めて測る
- 誰が見てよいかを決める
CHECK 1ここまでの確認
次のうち、非機能要件にあたるものはどれか?
答えと解説
答え: 2. 月間に止まってよい時間の上限を決める
非機能要件は「どの品質で動かすか」を測れる形で決めるものです。ほかの2つは「何をするか」で、機能要件です。読み直すのは「非機能要件とは何か」の章です。
非機能要件はどんな観点で出るか｜可用性・性能・セキュリティ・運用・コストを Well-Architected の柱に対応づける
非機能要件は、思いつくまま挙げると抜けます。抜けを防ぐ枠として使えるのが、AWS の Well-Architected フレームワークの柱です。柱は6本（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性）で、機能要件以外の観点を見落とさないための枠として説明されています。柱の中身はWell-Architected フレームワークとは何かに譲り、ここでは「それぞれをどんな数字で合意するか」を見ます。
| 観点 | 合意する数字の形（値は案件ごと） | 対応する柱 |
|---|---|---|
| 可用性 | 一定期間のうち使える時間の割合、1回の停止の上限 | 信頼性 |
| 性能 | 応答にかかる時間の目標、同時に捌く量 | パフォーマンス効率 |
| セキュリティ | 誰が何を見てよいか、記録を残す期間 | セキュリティ |
| 運用 | 障害に気づくまでの時間、復旧に着手するまでの時間 | 運用上の優秀性 |
| コスト | 月の予算の上限、増えたときに知らせる線 | コスト最適化 |
持続可能性の柱も含めて6本ありますが、案件によって数字にする優先度は違います。重要なのは、表の右の列を埋めること自体が目的ではなく、左の観点について「数字で言えるか」を確かめることです。言えない観点が、あとで揉める場所になります。
FIVE VIEWPOINTS5つの観点
観点ごとに数字で言えるかを確かめる
-
1.可用性 — 使える時間の割合と測る期間
柱: 信頼性
-
2.性能 — 応答時間の目標と同時に捌く量
柱: パフォーマンス効率
-
3.セキュリティ — 誰が何を見てよいか
柱: セキュリティ
-
4.運用 — 気づくまでの時間と連絡の経路
柱: 運用上の優秀性
-
5.コスト — 月の予算と知らせる線
柱: コスト最適化
可用性の目標はどう数字にするか｜稼働率の式・「9 の数」・年間の停止許容時間
可用性（availability）は、一定の期間のうち、システムが使える状態にある時間の割合です。AWS の Reliability Pillar では、稼働時間を全体の時間で割った割合として扱われます。
稼働率 ＝ 使えた時間 ÷ 期間全体の時間
1年は8,760時間です。目標の稼働率から、年間に許される停止時間が逆算できます。
| 稼働率の目標 | 年間に許される停止（目安） |
|---|---|
| 99.9% | 約8時間45分 |
| 99.99% | 約52分 |
どちらも Reliability Pillar の可用性のページに載っている値です。「99.9%」「99.99%」のように9が何個並ぶかで目標を言い表すので、「9の数」と呼ばれます。9がひとつ増えるごとに、許される停止はおよそ10分の1になります。
数字にしたら、次の3点も一緒に決めます。
- 測る期間：年間か、月間か。短い期間で測るほど、1回の長い停止の影響が大きく見えます。
- 何をもって「使えている」とするか：画面が返れば使えているのか、注文が最後まで通って初めて使えているのか。
- 計画停止を含めるか：メンテナンスの時間を数えるのか、数えないのか。
ここを曖昧にしたまま「99.9%」と書くと、双方が違う意味で合意したことになります。SLO の細かい設計はSRE の記事側の話題なので、ここでは、数字には期間と定義が付くことだけ押さえてください。
CHECK 2ここまでの確認
稼働率の目標を99.9%としたとき、1年間に許される停止はおよそどれか?
答えと解説
答え: 2. 約8時間45分
1年は8,760時間で、その0.1%が約8.76時間（8時間45分ほど）です。約52分は99.99%の目標の値です。読み直すのは「可用性の目標はどう数字にするか」の章です。
依存と冗長化で稼働率はどう変わるか｜ハード依存は掛け算、独立した冗長は失敗確率の掛け算
自分の稼働率を決めても、それだけで全体が決まるわけではありません。止まると自分も止まる依存（ハード依存）があると、全体の稼働率は掛け算で下がります。Reliability Pillar でも、ハード依存の稼働率は掛け合わせて求めると説明されています。
たとえば稼働率99.99%のシステムが、同じく99.99%の独立した2つのシステムにハード依存しているとします。自分を含めて3つが直列につながるので、理論上は次のようになります。
0.9999 × 0.9999 × 0.9999 ≒ 0.9997 → 約99.97%
どの部品も「9が4つ」なのに、全体は「9が3つ」に落ちました。依存先の数が増えるほど、目標は守りにくくなります。
逆に、独立した部品を冗長にして、どちらかが生きていれば動く形にすると、止まるのは両方が同時に止まったときだけです。止まる確率は掛け算になります。たとえば稼働率99%の部品を独立に2つ並べると、両方が止まる確率は 0.01 × 0.01 ＝ 0.0001 で、全体の稼働率は理論上99.99%になります。
ただし、この計算は部品が独立していることが前提です。同じ原因（同じ設定ミス、同じ電源、同じデプロイ）で一緒に止まる2つは独立ではないので、並べても期待どおりには上がりません。AZ をまたぐ構成が語られるのは、止まる原因をなるべく切り離すためです。復旧方式（DR）の設計はDR の設計の記事で扱います。
TARGET VS COST高い目標の代償
稼働率の目標を上げると、コストと作り方も一緒に重くなる
稼働率の目標を上げる
- 許される停止が短くなる
跳ね返るもの
- コスト
- テストと自動復旧
- デプロイ速度
本当に必要な水準
CHECK 3ここまでの確認
稼働率99.99%のシステムが、同じく99.99%の独立した2つのシステムに止まると全体も止まる形で依存するとき、理論上の稼働率は?
答えと解説
答え: 2. 約99.97%
止まると全体も止まる部品が3つ直列になるので、0.9999を3回掛けて約99.97%になります。依存は掛け算で稼働率を下げます。読み直すのは「依存と冗長化」の章です。
なぜ高い目標をむやみに置いてはいけないのか｜コスト・テスト・デプロイ速度への跳ね返り
「止まらないに越したことはない」ので、つい高い数字を置きたくなります。しかし Reliability Pillar は、高い可用性を目指すほどコストがかかる点を明示しています。目標を一段上げると、次のものが一緒に重くなります。
- コスト：冗長な構成を常に動かす費用がかかります。
- テスト：障害を想定した検証が必要になります。
- 自動復旧：人が気づいて直す時間が許容に収まらなくなるので、検知と復旧を自動化します。
- 運用：待機体制や手順の整備が要ります。
- 変更の速度：本番に出す前の確認が厚くなり、デプロイの頻度や速さに響くことがあります。
つまり目標は、数字だけを上げるものではなく、その数字を守れる作り方と体制をまるごと選ぶことです。社内の業務システムと、止まると売上が直接止まる決済では、必要な水準が違って当然です。必要以上に高い目標は、コストと運用の負担という形で、静かに事業側へ返ってきます。
だから順番は、「構成を決める → 数字を言う」ではなく、「許容を聞く → 数字にする → 構成を比べる」です。数字が先にあるから、構成を比べられます。
CHECK 4ここまでの確認
稼働率の目標を一段上げたとき、あわせて上がるものはどれか?
答えと解説
答え: 1. テストと自動復旧と運用の水準、そしてコスト
目標が上がると、その停止時間に収めるために、検証・自動化・運用体制も同じ水準に揃える必要が出ます。読み直すのは「高い目標をむやみに置いてはいけない理由」の章です。
非機能要件はいつ誰と決めるか｜要件の聞き方の型と、決まらない場合の置き方（仮置きと見直し日）
非機能要件は、設計の後半で慌てて聞くと手戻りが大きくなります。構成を選び始める前に聞いておくものです。
聞き方のコツは、数字を直接聞かず、困りごとから聞くことです。事業側は「99.9%がいい」とは答えづらくても、「1時間止まったら何が起きますか」「いちばん止まって困る時間帯はいつですか」には答えられます。そこから、技術側が数字に直します。
| 聞くこと | 数字にするときの形 |
|---|---|
| 止まったら何が困るか（誰が・どのくらい） | 稼働率の目標と測る期間 |
| 混む時間帯と、そのときの待ち時間の許容 | 応答時間の目標と同時に捌く量 |
| 見られてはいけない情報は何か | アクセスできる範囲、記録を残す期間 |
| 障害に誰がいつ気づくべきか | 気づくまでの時間、連絡の経路 |
| 月にいくらまで使えるか | 予算の上限、超えそうなときに知らせる線 |
役割分担は、事業側が「どこまで止まると困るか」という許容を出し、技術側が実現の可否とコストを出す形が基本です。それを突き合わせて合意します。
それでも決まらないことはあります。そのときは、仮置きの値と見直す日をセットで決めておきます。「いまは月間99.9%を目標にする。リリースから3か月後の実績を見て決め直す」のように書けば、決まらないことが先送りではなく、期限付きの前提になります。
数字が衝突したらどうするか｜トレードオフ・ADR・ポストモーテムへの接続
観点ごとに数字を決めると、必ずどこかで衝突します。可用性を上げればコストが上がり、セキュリティを厳しくすれば運用の手間が増えます。Well-Architected のフレームワークは、各決定の長所と短所を理解するためのものとして説明されており、レビューも監査ではなく建設的な対話とされています。柱は答えを出してくれるものではなく、問いを立てる枠です。
衝突したときは、次の流れで進めます。
- 衝突している数字を並べ、どちらを守ると何を諦めるかを書き出します。選び方の型はトレードオフの考え方にあります。
- 決めたら、なぜそうしたかをADRに残します。数字と前提と理由が残れば、あとで条件が変わったときに見直せます。
- 実際に障害が起きたら、目標と実績を見比べます。目標を超えて止まったのか、想定どおりだったのかは、ポストモーテムの材料になり、次の非機能要件の見直しに戻ります。
この輪が回ると、非機能要件は一度書いて終わる文書ではなく、実績で更新される合意になります。
Cloudory 執筆者（AWS 認定 全冠）
形容詞を数字に直す作業は地味ですが、設計のいちばん上流で効きます。数字がなければ構成の比較も、あとの振り返りもできません。まずは自分の担当するシステムについて、「許容する停止時間」を一つ、期間と定義つきで言い切ってみてください。
参照ソース
- AWS Well-Architected Reliability Pillar：可用性 — 可用性の定義と稼働率の式、99.9%・99.99% の年間停止時間、ハード依存の掛け算、冗長コンポーネント、高い可用性とコストの関係の根拠に使用
- AWS Well-Architected Framework：The pillars of the framework — 6つの柱の名前と、柱が機能要件以外の観点を見落とさないための枠であることの根拠に使用
- AWS Well-Architected Framework：Welcome — 決定の長所と短所を理解するための枠であること、レビューが建設的な対話であることの根拠に使用
