非機能要件は、聞かれなかったから決まらなかった、で済んでしまう領域です。だから発注側から聞きます。
非機能要件とは何か、なぜ自分たちで聞くのか
機能要件が「何ができるか」だとすれば、非機能要件は「どれくらいの速さで、どれくらい止まらず、どれくらい安全に動くか」です。これらは機能一覧に載らないため、話題に上らないまま設計が進みがちです。そして、後から変えようとすると、作り直しに近い費用がかかります。技術の言葉で語る必要はありません。このシートの質問を、そのまま打ち合わせで読み上げてください。
1. 性能: どれくらいの速さと量を想定するか
速さの要件は、利用者数と処理の量から決まります。どちらも、事業側にしか分からない情報です。現時点の見込みで構わないので、数字を出してください。数字が無いと、開発側は安全側に倒すか、逆に楽観的に見積もるかのどちらかになります。1年後の想定も添えると、無駄な作り込みを避けられます。桁が合っていれば十分で、精密な予測は必要ありません。
- 同時に使う人数の想定(開始時と、1年後)
- 一日あたりの利用回数・登録件数の想定
- 遅いと困る操作はどれか(検索、一覧表示、決済など)
- アクセスが集中する時間帯やイベントがあるか
- 扱うデータの量(ファイルのアップロードがあるか、その大きさ)
2. 可用性: 止まったときに何が起きるか
「絶対に止まらないシステム」は費用が大きく膨らみます。現実的なのは、止まったときの影響を見積もり、それに見合う備えを選ぶことです。1時間止まると売上が失われるのか、翌営業日まで待てるのかで、必要な構成は変わります。あわせて、計画的なメンテナンスをいつ行えるかも決めておきます。止めてよい時間帯が分かっていると、更新作業の段取りが立てやすくなります。
3. データの保全: 消えたときに戻せるか
可用性と並んで重要なのが、データが失われないことです。バックアップを取っているかだけでなく、実際に戻せるかを確認してください。取得していても、戻す手順を試したことがなければ、いざというときに機能しません。どの時点まで戻せるか、戻すのにどれくらいかかるかを、具体的に聞きます。人の操作ミスでデータが消える場合もあるため、そこも含めて確認してください。
- バックアップの頻度と、保存する期間
- どの時点まで戻せるか(直前か、前日か)
- 戻すのにかかる時間と、その手順を誰が実行するか
- 戻す手順を実際に試したことがあるか
- 誤って削除したデータを復元する手段があるか
4. セキュリティ: 何をどこまで守るか
扱う情報の重要度によって、必要な対策は変わります。個人情報や決済情報を扱うなら、標準的な対策は必須です。ここでは専門的な用語の説明を求めるのではなく、「何が守られていて、何が守られていないか」を、自社の言葉で説明してもらってください。説明できない相手は、設計していない可能性があります。完璧を求めるのではなく、標準的な対策が入っているかを確かめます。
- 通信の暗号化と、保存するデータの扱い
- 管理画面へのアクセス制限(誰が、どこから入れるか)
- 権限の分け方(全員が全部を見られる状態になっていないか)
- 誰が何をしたかの記録(操作の履歴)が残るか
- 使っている部品の更新をどう続けるか
- 外部からの不正なアクセスに気づく仕組みがあるか
5. 運用: 公開後、誰が何を見るか
システムは公開してから動き続けます。異常が起きたときに誰がどう気づくか、日常的に何を確認するかを決めておきます。社内に技術者がいない場合、監視と一次対応を保守の範囲に含めるかどうかが重要な判断になります。連絡が取れる時間帯と、緊急時の扱いも確認してください。通知が届いても誰も動けない体制では、監視を入れた意味が薄くなります。
- 異常が起きたとき、誰にどう通知されるか
- その通知を受け取った人が、最初に何をするか
- 日常的に確認する項目(エラーの発生、処理の滞留など)
- 保守の対応時間と、時間外の扱い
- 自社側で見られる管理画面やダッシュボードがあるか
6. 拡張と引き継ぎ: 将来動かせるか
最初の設計は、将来の選択肢を狭めることがあります。利用者が増えたとき、機能を足したいとき、別の会社に引き継ぐときに何が必要になるかを、着手前に聞いておきます。一般的に使われている技術で作られているか、資料が残っているかは、後から人を採用できるかにも関わります。移行するつもりが無くても、移行できる状態にしておくこと自体が交渉力になります。
- 利用者が想定の何倍になったとき、何を変える必要があるか
- 採用している言語・フレームワーク・クラウドは一般的なものか
- 設計や運用の資料はどの範囲で残るか
- 他社や自社の技術者へ引き継ぐ場合の手順
- 外部サービスへの依存が強い箇所はどこか
7. 費用への跳ね返りを確認する
非機能要件の多くは、費用に直結します。止まらない構成にすれば運用費が増え、細かい監視を入れれば設定と保守の手間が増えます。すべてを高い水準に設定するのではなく、事業として必要な水準を選ぶことが目的です。各項目について、水準を上げた場合と標準的な場合で、初期の費用と月々の費用がどう変わるかを聞いてください。金額は構成や規模によって案件ごとに異なります。
- 水準を上げると、初期費用と月額のどちらがどれくらい増えるか
- 後から水準を上げられる項目と、最初に決める必要がある項目
- 月々かかる外部サービスの費用と、その見込み
使い方のまとめ
この6分野のうち、自社にとって重要なものを2つか3つ選び、そこだけを厚く議論してください。すべてを最高水準にする必要はありません。選んだ理由と、選ばなかった理由を記録しておくと、事業が成長して見直す時期が来たときに、判断の出発点になります。なお、個人情報の取り扱いについては一般的な情報であり、個別の事案は専門家にご確認ください。
関連するインサイト
- スタートアップのセキュリティと個人情報保護 — 最低限の実務スタートアップが最低限押さえたいセキュリティと個人情報保護の実務を、アカウント管理や秘密情報の扱い、個人情報の取得と削除、CI/CDへの検査組み込み、インシデント初動、生成AI利用の注意まで整理します。
- クラウドインフラコストの圧縮 — 見直しの順番と落とし穴クラウドの利用料が事業の成長より速く増えているとき、どこから手を付けるべきか。可視化から監視の継続運用までの手順と、可用性や開発速度を損なう落とし穴を経営者向けに整理します。
- コンテナとクラウドの活用 — 小規模チームでの現実的な構成コンテナで環境差を解消し、マネージド実行環境・サーバーレス・PaaSから小規模チームに合う構成を選ぶ判断軸を整理します。IaCとCI/CD、監視・ログ・バックアップ、コスト管理まで実務の要点を解説します。
関連するサービス
監修: フィリット・コンサルティング株式会社公開