💨

1日で作る「非機能要件テンプレ」

に公開
AWS
要件定義
非機能
idea

1日で作る「非機能要件テンプレ」

――ECSやクラウド設計の前に、最低限ここだけ押さえる

システム設計をやっていると、必ずと言っていいほど出てくるのが 「非機能要件」 です。

  • 「なるべく落ちないようにしてほしい」
  • 「バッチは朝までに終わっていてほしい」
  • 「セキュリティはちゃんと」

こういうフワッとした言葉は出てくるのに、
数字や担当範囲まで落ちた“まとまった資料”がない ことが多い。

その結果、

  • ECSやインフラ設計に落とすときに悩む
  • レビューのたびに「非機能の整理が足りない」と指摘される
  • アプリとインフラの責任範囲があいまいになる

といったことが起きます。

この記事では、

1日あれば作れるレベルの「非機能要件テンプレート」

を紹介します。
PowerPointでもドキュメントでも、Notionでもいいので、
2ページだけのシンプル構成 で作れるようにしています。

全体構成：たった2ページでいい

テンプレートの構成はシンプルです。

  1. 1ページ目：サマリ
  2. 2ページ目：非機能要件一覧表

これだけです。

細かい章立てやISOっぽい分類は一旦捨てて、

  • 「このシステムで何が大事か」
  • 「どの観点で、どのレベルを目指すか」
  • 「誰の担当か」

だけをハッキリさせることに集中します。

1ページ目：非機能サマリテンプレ

まずは「このシステムが何を重視しているか」が一目で分かる1枚を作ります。

# 非機能要件サマリ（システム名：＿＿＿＿＿＿＿＿）

## 1. 対象・前提

- 対象システム：
- 対象範囲（今回のスコープ）：
  - 例）日次バッチ、公開API、管理画面　など
- 想定ユーザ／利用時間帯：
  - 例）社内ユーザ 50名、平日 9:00〜18:00 利用がメイン

## 2. 非機能の優先度（Top3）

1. 第1優先：＿＿＿＿＿＿＿＿（例：可用性、業務時間中の安定運用）
2. 第2優先：＿＿＿＿＿＿＿＿（例：性能、バッチ完了時刻）
3. 第3優先：＿＿＿＿＿＿＿＿（例：セキュリティ、監査ログの確保）

※「全部大事」ではなく、あえて3つに絞る。

## 3. 前提条件・制約

- インフラ基盤：
  - 例）AWS ECS Fargate、RDS、ALB など
- 運用体制：
  - 例）平日日中は有人監視、夜間はアラートのみ対応 など
- その他前提：
  - 例）既存システムとの連携あり／停止時間は最大1時間まで許容 など

ここは 1〜2時間でざっと埋める くらいの気持ちで十分です。

大事なのは「何を優先するシステムなのか」が1枚で伝わること。
完璧さより、まずは“書いてあること”を優先します。

2ページ目：非機能要件一覧表テンプレ

次に、非機能をカテゴリごとに並べた一覧表を作ります。

カテゴリは最小限に絞っています：

  • 性能
  • 可用性
  • 監視・運用
  • セキュリティ
  • ログ・監査
  • 保守・拡張性

表のフォーマットはこんなイメージです。

# 非機能要件一覧

| No | カテゴリ       | 観点/テーマ            | 要件（文章）                                           | 数値・基準（できる範囲で）                        | 担当 (App/基盤/運用) | 状態     |
|----|----------------|------------------------|--------------------------------------------------------|---------------------------------------------------|----------------------|----------|
| 1  | 性能           | API応答時間            | 業務時間帯は、画面操作がストレスなく使えること        | 95%のリクエストが 1 秒以内（候補値）              | App＋基盤             | たたき台 |
| 2  | 性能           | バッチ処理時間         | 日次バッチは業務開始までに完了していること            | 対象日翌営業日 8:00 までに完了                    | App＋基盤             | たたき台 |
| 3  | 可用性         | 計画停止               | 平日 9〜18 時は計画停止を行わない                     | 平日日中の停止 0 回／月を目標                     | 基盤                  | たたき台 |
| 4  | 可用性         | 障害時の復旧時間       | 障害時、業務影響を最小限に抑える                      | 重大障害時は検知から 1 時間以内にサービス再開     | 基盤＋運用            | たたき台 |
| 5  | 監視・運用     | 障害検知               | 異常があれば速やかに気づけること                      | 致命的エラー発生から 5 分以内に一次通知           | 基盤＋運用            | たたき台 |
| 6  | 監視・運用     | 再実行ルール（バッチ） | バッチ失敗時に安全に再実行できること                  | 同一対象日の再実行で多重登録が発生しない          | App                   | 検討中   |
| 7  | セキュリティ   | 秘匿情報の管理         | パスワード等を平文で持たない                          | DB・外部APIの認証情報は Secrets/Parameter で管理  | 基盤                  | たたき台 |
| 8  | セキュリティ   | 通信経路               | インターネット経由の通信は暗号化されていること        | 外部公開は全て HTTPS（TLS1.2 以上）               | 基盤                  | たたき台 |
| 9  | ログ・監査     | アクセスログ           | 操作のトレースができること                            | 主要API へのリクエスト/レスポンスをログに記録     | App＋基盤             | たたき台 |
| 10 | ログ・監査     | 保管期間               | 監査や障害調査に必要な期間、ログを残す                | アプリログ・監査ログともに 1 年保存（候補値）     | 基盤＋運用            | たたき台 |
| 11 | 保守・拡張性   | デプロイ方式           | 業務影響を最小にしたリリースができること              | ECS のローリング更新を使用（無停止を基本方針）    | 基盤                  | たたき台 |
| 12 | 保守・拡張性   | 設定の持ち方           | 環境ごとの差分をコードから切り離して管理すること      | 環境依存値は全て env/Parameter Store で管理       | 基盤＋App             | たたき台 |

この表を作るときのポイント

  1. 最初から完璧を目指さない

「数値・基準」は最初は “候補値” で構いません。
　状態欄に「たたき台」と書いておけば、レビューでの心理的ハードルも下がります。

  1. 空欄より「雑でも埋める」を優先

- 「なるべく早く」 → 「95%が1秒以内（候補）」
　- 「朝までに終わっててほしい」 → 「翌営業日8:00までに完了」

…というように、“業務の感覚”をそのまま数字にしてしまってOKです。

  1. 担当を必ず書く

App / 基盤 / 運用 のどこが主体かを書くだけで、
　「誰に確認しに行くべきか」 がハッキリします。

どうやって1日でここまで持っていくか

午前：サマリ＋枠作り

  • サマリ1ページをサッと埋める（1〜2時間）
  • 一覧表の「カテゴリ」と「観点/テーマ」だけ先に並べる（30分）

午後：中身を入れる

  • 過去の資料、要件定義、会話のメモから
    フワッとした非機能の話を引っ張り出して、表に落とし込む（2〜3時間）
  • 数字を“仮決め”する（1時間）
  • 空欄や「検討中」の行をメモして、
    次回の打ち合わせで聞くべき質問に変えておく（30分）

ここまでできていれば、
「非機能要件がまったく整理されていない状態」からは完全に卒業 です。

ECSやクラウド設計とどうつながるか

このテンプレは、
AWS ECS やコンテナ設計と非常に相性が良いです。

例えば：

  • 性能の行 → ECS の CPU / メモリ、オートスケールのしきい値
  • 可用性の行 → タスク数、AZ分散、デプロイ方式
  • 監視・運用の行 → CloudWatch アラームの条件、通知先
  • セキュリティの行 → Secrets Manager / Parameter Store、SG設計
  • ログ・監査の行 → CloudWatch Logs のロググループ、保持期間

という形で、
「非機能一覧表 → ECS詳細設計」 へ自然にブリッジできます。

Discussion