非機能要件の進め方｜後回しで「地獄」を見ないための実戦的ヒアリング術

「機能のことはわかるけど、非機能要件をどう進めればいいのか自信がない」
「お客様にどう説明すれば、コストの必要性を納得してもらえるだろうか……」

システム開発の要件定義において、目に見える「機能」と同じくらい、あるいはそれ以上に重要なのが「非機能要件」です。

技術的な側面が強いために「エンジニア側で適当に決めておこう」と後回しにされがちですが、ここを疎かにすると、リリース直前に「動作が重すぎて使い物にならない」「障害復旧ができない」といった致命的なトラブルを招きます。現場が「地獄絵図」と化す前に、PMが主導して合意形成を行う必要があります。

本記事では、30年の現場経験に基づき、事業方針やコストに直結する非機能要件をスムーズにまとめ上げるためのポイントを詳しく解説します。

非機能要件とは？「システムの価値」を支える土台

要件定義で扱う事項は、大きく「機能」と「非機能」の2つに分かれます。これらを建物に例えると、その役割の違いが明確になります。

項目	システムにおける役割	建物での例え
機能要件	ビジネスの仕組み（請求発行、在庫管理など）	間取り、キッチン、内装
非機能要件	品質・性能・運用（レスポンス、セキュリティなど）	耐震性、断熱性、セキュリティ

一見するとビジネスに直接関係ないように見えますが、非機能要件はシステムを安定して使い続けるために欠かせない「土台」なのです。

「お客様から要望がないなら、標準的な構成でいいだろう」という判断は非常に危険です。非機能要件には、常に「コストと品質のトレードオフ」が存在するからです。

不足のリスク： レスポンスが10秒かかるシステムは、どれほど高機能でも現場では「欠陥品」扱いされます。リリース直前の修正作業（デスマーチ）や、修正費用の負担を巡るトラブルに直結します。
過剰のリスク： 数日止まっても支障がないシステムに、銀行並みの「24時間365日無停止」の構成を組むのは、お客様の予算を圧迫する「過剰投資」になってしまいます。

PMの役割は、お客様の事業にとって「どこまでの品質が必要か」という判断材料を提示し、納得感のある合意を導き出すことにあります。

お客様に「可用性は？」「セキュリティ強度は？」と専門用語で聞いても、納得感のある答えは返ってきません。まずは普段の業務での「困り事（ペインポイント）」から逆算するのが近道です。

例えば、「月末に動作が重くなる」という不満がある場合、以下の5W1Hで具体化します。

具体的な「痛み」から逆算することで、エンジニアの主観ではなく、ビジネスの実態に即した性能目標が見えてきます。

自分の経験だけで項目を洗い出すと、どうしても抜け漏れが出ます。そこで活用したいのが、【外部】IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」です。

現場では、以下の6つのカテゴリを意識して項目を埋めていきます。

カテゴリ	主な検討事項
1. 可用性	稼働時間、耐障害性、災害対策、復旧目標時間（RTO/RPO）
2. 性能・拡張性	レスポンス時間、スループット、将来のデータ・ユーザー増予測
3. 運用・保守性	バックアップ体制、保守時間、運用監視のルール、TCO
4. セキュリティ	認証管理、アクセス制御、ログ取得、ウイルス対策
5. 移行性	現行データの移行量、新旧システム並行稼働の期間
6. システム環境	設置場所、クラウド（SaaS/PaaS）利用時のSLA確認