非機能要件の決め方と重要項目｜失敗を防ぐ「燃費」や「保険」の考え方

本連載について
この記事は、IT現場で最も炎上しやすいと言われる「要件定義」の進め方を、誰もが経験したことのある「家族旅行」に例えてわかりやすく解説する全7回のシリーズです。（※どの回からでも単独でお読みいただけます）

第5回となる今回は、リリース後の地獄（使えないシステム）を防ぐ「非機能要件（品質）の決め方」についてお届けします！

「システムは完成したのに、いざ使い始めたら動作が重すぎて仕事にならない……」
「セキュリティが厳密すぎて、ログインするだけで一苦労だ」

こうしたトラブルの原因は、その多くが「非機能要件」の検討不足にあります。前回（第4回：業務要件とシステム要件の違い）では、プラン（業務）と乗り物（機能）の関係を整理しました。プランも乗り物も決まればいよいよ出発！と言いたいところですが、その前に決めておくべき「目に見えない大切なこと」があります。

それが非機能要件です。今回は、旅行における「燃費」「点検」「保険」を例に、地味ながらもプロジェクトの成否を大きく分けるこの要件の正体を紐解いていきましょう。

非機能要件とは？（「動く」のその先にある品質）
非機能要件の代表的な3つの柱
品質とコストのバランス（トレードオフ）
まとめ：地味な「品質」が、旅の満足度を決める
- 明日から現場で使える！品質チェックリスト
- 次のステップ：「全部盛り」の誘惑を断つ技術

非機能要件とは？（「動く」のその先にある品質）

システム開発において、「〇〇ができる（検索ができる、計算ができる）」という目に見える振る舞いを「機能要件」と呼びます。対して非機能要件とは、「どのような品質で」動くべきかを定義したものです。

項目	機能要件（主役）	非機能要件（土台）
役割	何ができるか（What）	どの程度の品質か（How well）
旅行の例	「目的地に行けること」	「燃費は良いか」「事故の備えはあるか」
ITの例	「画面が表示されること」	「3秒以内に開くか」「24時間止まらないか」

機能要件が「表の主役」なら、非機能要件は「裏の土台」です。土台が不安定だと、どれほど豪華な機能を作ってもシステムは使い物にならなくなってしまいます。

非機能要件の代表的な3つの柱

複雑な非機能要件ですが、実務で特に重要な3つの要素に絞って整理してみましょう。

① 可用性と性能（車のタフさと燃費）

「いつでも、スムーズに動くこと」に関する要件です。

可用性：「繁忙期でも24時間注文を受け付けられるか？」
性能：「1,000人が一斉にアクセスしても、画面が3秒以内に開くか？」
落とし穴：「性能は高いに越したことはない」と欲張ると、F1マシンのような超高額なシステムが必要になり、予算がいくらあっても足りなくなります。

② 保守性と運用性（点検のしやすさと備え）

「トラブルへの備えや、維持のしやすさ」に関する要件です。

運用性：「エラーが起きたとき、管理者に自動で通知が飛ぶか？」
保守性：「将来、税率が変わったときに設定変更だけで対応できるか？」
落とし穴：「トラブルなんて起きないだろう」と備えを省くと、いざという時に業務が数日間ストップし、莫大な損失を出すことになります。

③ セキュリティ（車のカギと貴重品管理）

「情報漏洩や不正操作を防ぐこと」に関する要件です。

認証：「パスワードは何桁にするか？二段階認証は必要か？」
認可：「部署や役職によって、閲覧できるデータを制限するか？」
落とし穴：ガチガチにしすぎると「車に乗るたびに指紋と顔認証が必要」な状態になり、現場の使い勝手が極端に低下します。

あわせて読みたい：後回しにしないためのヒアリング術
非機能要件はユーザーから「お任せで」と言われやすく、後から「こんなはずじゃなかった」と地獄を見るケースが絶えません。具体的な聞き方のコツを知りたい方は、こちらの記事も参考にしてください。非機能要件の進め方｜炎上を防ぐ「実戦ヒアリング術」と顧客が納得する交渉のコツ

品質とコストのバランス（トレードオフ）

非機能要件の議論が一番難しいのは、「こだわり始めるとキリがない（青天井）」かつ「お金がかかる」からです。

ユーザーの理想（わがまま）	現実的なリーダーの視点
「絶対に事故を起こさない防弾仕様の車がいい」	「個人情報を扱うから、セキュリティには予算を重点配分しよう」
「一度も給油不要（無限の燃費）がいい」	「社内用だから24時間稼働は不要。土日は停止してコストを抑えよう」
「どんな故障も1分で直してほしい」	「バックアップは1日前で十分か？復旧目標を現実的なラインで握ろう」

第1回で決めた「旗印（コンセプト）」に立ち返り、どこに資源（予算）を集中させるかを決めるのがリーダーの重要な役割です。

まとめ：地味な「品質」が、旅の満足度を決める

非機能要件は、普段はその存在を意識しません。しかし、トラブルが起きたとき、あるいは使い心地が悪いときに、初めてその重要性に気づかされます。

機能要件：「目的地で何をするか」というアクティビティ
非機能要件：「どう移動し、どう過ごすか」という旅の品質

要件定義の段階で、エンジニアと一緒に「燃費（性能）」や「保険（保守）」のラインをしっかり握っておきましょう。

明日から現場で使える！品質チェックリスト

非機能要件を定義する際、リーダーは以下の3点をユーザーとしっかり合意しておきましょう。

[ ] 「速さ」の定義を握る
「速く動くこと」という曖昧な表現を、「〇〇件の検索結果が〇秒以内に表示されること」と具体的な数字で合意できているか。
[ ] 停止の許容範囲を決める
万が一の障害時に「何時間（何日）までなら業務が止まっても許容できるか」を、ユーザー部門の責任者と現実的なラインで握っているか。
[ ] セキュリティの塩梅
扱うデータの重要度をランク分けし、「どこをガチガチに守り、どこを使い勝手優先にするか」のメリハリをつけられているか。