非機能要件の落とし穴：楽しい旅行を支える「インフラ」や「品質」の決め方

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

こうしたトラブルの原因は、すべて「非機能要件」の検討不足にあります。

それが非機能要件です。今回は、旅行における「燃費」「点検」「セキュリティ」を例に、地味ながらも強力なこの要件の正体を解き明かします。

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

システム開発において、「〇〇ができる（売上計算ができる、検索ができる）」という目に見える振る舞いを「機能要件」と呼びます。

対して非機能要件とは、「どのような品質で」動くべきかを定義したものです。

旅行なら： 「目的地に行ける」のは大前提。その上で、「ガソリン代はいくらまでか（可用性と性能）」「事故が起きたらどうするか（保守性と運用性）」「車が盗まれないか（セキュリティ）」といった要素です。
ビジネスの例： 「画面が表示される」のは大前提。その上で、「何秒以内に表示されるか（可用性と性能）」「24時間365日止まらないか（保守性と運用性）」「不正アクセスを防げるか（セキュリティ）」を指します。

機能要件が「表の主役」なら、非機能要件は「裏の土台」です。土台が腐っていると、どれほど豪華な機能を作っても、システムはすぐに崩壊してしまいます。

複雑な非機能要件を、旅行の例えで3つに絞って整理してみましょう。

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

旅行なら： 「1,000キロ走ってもオーバーヒートしないか（可用性）」「時速100キロで安定して走れるか、燃費は良いか（性能）」です。
ビジネスの例：
可用性： 「年末年始の繁忙期でも、24時間注文を受け付けられるか？」
性能： 「1,000人が一斉にアクセスしても、画面が3秒以内に開くか？」

【落とし穴】 「性能は高いに越したことはない」と欲張ると、F1マシンのような超高額なシステムが必要になり、予算がいくらあっても足りなくなります。

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

旅行なら： 「万が一の故障時にすぐ呼べるロードサービスに入っているか」「タイヤ交換が簡単にできるか（保守）」です。
ビジネスの例：
運用性： 「エラーが起きたとき、管理者に自動でメールが飛ぶか？」
保守性： 「将来、消費税率が変わったときに、プログラムを書き換えずに設定変更だけで対応できるか？」

【落とし穴】 「トラブルなんて起きないだろう」と備えをケチると、いざという時に業務が数日間ストップし、莫大な損失を出すことになります。

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

【落とし穴】 セキュリティをガチガチにしすぎると、「車に乗るたびに指紋認証と顔認証と暗証番号が必要」な状態になり、利便性（使い勝手）が極端に低下します。

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

こんなわがままが通らないのは、誰の目にも明らかですよね。しかし、システム開発の現場では、これと同じことが平然と要求されます。

リーダーの役割は、この「品質」と「コスト」のバランス（トレードオフ）を調整することです。

このように、第1回で決めた「企画構想（コンセプト）」に立ち返って、どこに資源を集中させるかを決めるのがリーダーの仕事です。

2章で挙げた3つの柱をベースに、ユーザーやエンジニアと「最低限ここだけは」と合意しておくべきポイントを表にまとめました。

分類	確認すべき問いかけ	検討のヒント
① 可用性と性能	・いつ使いますか？・どのくらいの速さが必要ですか？	・24時間365日？平日のみ？・検索結果に10秒待てるか？同時アクセスは何人か？
② 保守性と運用性	・データが消えたら、いつまで戻せれば許せますか？・トラブルに誰が気づきますか？	・バックアップは1日前？ 1時間前？・管理者に自動通知が必要か？復旧目標時間は？
③ セキュリティ	・誰に、どこまで見せていい情報ですか？・社外からもアクセスさせますか？	・部署・役職ごとの閲覧・編集制限の有無。・リモートワーク用、二段階認証などの必要性。
【＋α】移行と拡張性	・古いデータはどうしますか？・将来、利用者は増えますか？	・過去何年分を移すか？（データ移行の範囲）・数年後の拠点増、ユーザー増に対応できるか。