非機能要件の進め方｜炎上を防ぐ「実戦ヒアリング術」と顧客が納得する交渉のコツ
この記事は「要件定義の実践ガイド（全9回）」の第4回です。
本記事は単体でもお読みいただけますが、システム開発の最難関である要件定義を成功に導くためのノウハウを体系的にまとめています。
前後のプロセスもあわせて読むことで、より深い理解に繋がります。ぜひ他の連載記事もご活用ください！
全9回のシリーズ記事一覧はこちら（ページ下部へ）
「いよいよリリース直前というタイミングで、『動作が重すぎて業務で使い物にならない！』とクレームが来た……」
「障害発生時、誰も復旧手順を知らずに現場がパニックになった……」
システム開発において、このような背筋が凍るようなデスマーチやトラブルの原因の多くは、非機能要件の定義不足・後回しにあります。
機能のヒアリングは得意でも、可用性や性能といった専門的で目に見えない要件になると、途端にお客様へどう説明し、どう合意形成していいか迷ってしまうPMやリーダーは少なくありません。
本記事では、数多くのプロジェクトの成功と失敗（デスマーチ）を見てきた経験から、プロジェクトの炎上を未然に防ぐための「実戦ヒアリング術」と、顧客の納得を引き出す「4つの交渉テクニック」を徹底解説します。
非機能要件とは？「システムの価値」を支える土台
要件定義で扱う事項は、大きく「機能要件」と「非機能要件」の2つに分かれます。これらを「建物」に例えると、その役割の違いが非常に明確になります。
| 項目 | システムにおける役割 | 建物での例え |
|---|---|---|
| 機能要件 | ビジネスの仕組み（請求発行、在庫管理など） | 間取り、システムキッチン、内装 |
| 非機能要件 | 品質・性能・運用（レスポンス、セキュリティなど） | 耐震性、断熱性、防犯セキュリティ |
一見するとビジネス（業務）に直接関係ないように見えますが、非機能要件はシステムを安全・安定して使い続けるために絶対に欠かせない土台です。
「過剰」と「不足」の罠を回避する
「お客様から特に要望がないから、標準的なインフラ構成にしておこう」というエンジニア側だけの判断は非常に危険です。非機能要件には、常にコストと品質のトレードオフが存在します。
- 不足のリスク
検索結果が出るまでに10秒かかるシステムは、どれほど高機能でも現場からは欠陥品扱いされます。リリース直前の修正作業や、追加費用の負担を巡る深刻なトラブルに直結します。 - 過剰のリスク
数日止まっても業務に支障がない社内システムに、銀行並みの「24時間365日無停止」の構成を組むのは、お客様の予算を無駄に圧迫する過剰投資です。
PMの役割は、お客様の事業にとってどこまでの品質が必要か（妥当か）という判断材料を提示し、納得感のある合意を導き出すことにあります。
顧客の「ペイン」から逆算する！5W1Hの実戦ヒアリング術
お客様に対して、いきなり「システムの可用性はどうしますか？」「セキュリティ強度は？」と専門用語で質問しても、納得感のある答えは返ってきません。
まずは、普段の業務での困り事（ペインポイント）から逆算するのが最も確実な近道です。 例えば、「今のシステムは月末に動作が重くなる」という不満がある場合、以下の「5W1H」の切り口で具体化していきます。
| 項目 | 現場への質問の切り口（例） | 導き出される要件 |
|---|---|---|
| When（いつ） | 毎月何日の何時ごろですか？ 特定の締め日にアクセスが集中しますか？ | 性能目標（ピーク時の想定負荷） |
| Who（だれが） | 全社員が一斉に使いますか？ 特定の部署の担当者だけですか？ | 同時接続数（ライセンス数の最適化） |
| Where（どこで） | 本社内のLANからアクセスしますか？ 外出先や在宅環境（VPN）からですか？ | 通信環境・インフラ要件（ネットワーク帯域） |
| What（なにが） | どの画面のどの操作（検索、保存、帳票出力）が重いですか？ | 処理優先度・DB設計（バッチ処理の分離など） |
| How（どのくらい） | どのくらい遅くなりますか？ 業務上の許容範囲は何秒以内ですか？ | 応答時間目標（SLA：サービス品質保証） |
このように、具体的な「痛み」から紐解くことで、エンジニアの主観ではなく、ビジネスの実態に即した要件が見えてきます。
抜け漏れを防ぐ「IPA非機能要求グレード」の賢い使い方
自分の頭の中の経験だけで要件項目を洗い出そうとすると、どうしても抜け漏れが発生します。そこで現場で活用したいのが、【外部】IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」です。
1. 6つのカテゴリで全体像を把握する
まずは以下の6つのカテゴリを意識して、システム全体で守るべき要件の大枠を捉えます。
| カテゴリ | 主な検討事項 |
|---|---|
| 1. 可用性 | 稼働時間、耐障害性、災害対策、復旧目標時間（RTO/RPO※） |
| 2. 性能・拡張性 | レスポンス時間、スループット、将来のデータやユーザー増の予測 |
| 3. 運用・保守性 | バックアップ体制、保守対応時間、運用監視のルール |
| 4. セキュリティ | 認証管理、アクセス制御、ログ取得、ウイルス対策 |
| 5. 移行性 | 現行データの移行量、新旧システム並行稼働の期間 |
| 6. システム環境 | 設置場所、クラウド（SaaS/PaaS）利用時の要件確認 |
※RTO（目標復旧時間）：いつまでに復旧させるか。RPO（目標復旧時点）：どの時点のデータまで戻せればよいか。
2. 膨大な項目で挫折しないための「3つの絞り込み手順」
IPAのツールは非常に網羅的ですが、全200項目以上あるため、そのままお客様に見せると高確率で挫折します。実務では以下の手順で現実的な範囲に絞って進めるのがコツです。
- 手順1：主要な16項目から検討を開始する
「モデルシステムシート」にある、システムの大枠を決める最重要16項目だけで、まずはお客様とレベル感（重要度）を合わせます。 - 手順2：コストやリスクに直結する92項目に絞る
見積もり金額やアーキテクチャ設計に直接影響を与える重要項目（92項目）について、具体的なレベルを決定します。 - 手順3：必要に応じて残りの詳細項目を詰める
プロジェクトの特性に合わせて取捨選択します。すべてを完璧に埋める必要はありません。
顧客の納得を引き出す「4つの実戦交渉テクニック」
非機能要件をスムーズに決定し、開発後半での「言った・言わない」の蒸し返しを防ぐためのPMの秘策を4つ紹介します。
1. 最適な要求レベルを「松・竹・梅」で提示する
ヒアリングをすると、お客様は悪気なく「絶対に止まらない、最速のシステム（最高レベル）」を求めてしまいます。そこで、コストとセットで選択肢を提示するのが効果的です。
「レスポンス3秒以内なら標準コスト内で収まりますが、1秒以内を保証する場合は追加のインフラ費用として〇〇万円かかります」
このように具体案を見せることで、お客様自身が「そこまでコストをかける必要はないな」と、コストと品質のバランスを冷静に判断できるようになります。
2. TCO（全体コスト）の視点を持つ
システムのコストには、作るための初期費用（イニシャルコスト）と、動かし続けるための運用保守費用（ランニングコスト）があります。これを合わせたものをTCO（Total Cost of Ownership：総所有コスト）と呼びます。
初期費用をギリギリまで抑えても、日々のバックアップや監視の手間（人件費）がかかりすぎるようでは本末転倒です。常にTCOの視点を持って提案しましょう。
3. 合意内容は必ず「明文化」して防波堤にする
サービスレベルの判断は、そのままコストとスケジュールに直結します。決定した「やること・やらないこと」は、必ず議事録や要件定義書に明記してください。
明文化されたドキュメントこそが、後から「そんなに費用がかかるとは思わなかった」「これもやってくれると思っていた」と言われるのを防ぐ、PMにとって最強の防波堤になります。
4. システム運用部門を必ず巻き込む
システムの運用方法を最も熟知しているのは、現場の運用部門のメンバーです。バックアップのサイクルや監視要件を決める際は、必ず運用担当者を打ち合わせに同席させましょう。
彼らを早期に巻き込み合意を得ておくことで、リリース後の「こんな運用は回せない」という現場の反発やトラブルを未然に防ぐことができます。
まとめ：非機能要件は「システムの信頼」を築く土台
非機能要件は地味で技術的に難しい側面がありますが、それこそがシステムが現場で価値を発揮し続けるための大切な土台です。
プロジェクトを地獄から救い、成功へ導くためにPMが覚えておくべきアクションは以下の3点に集約されます。
- 「ペインポイント」から逆算する
専門用語で直接聞くのではなく、現場の困り事を「5W1H」で深掘りし、実態に即した要件を導き出します。 - 「松竹梅」でコストと品質のバランスを提示する
過剰投資を防ぐため、お客様自身が納得して選択できる具体案（選択肢）を提示します。 - 運用部門を必ず巻き込む
リリース後の運用を担うメンバーと事前に合意し、現場の反発や将来のトラブルを未然に防ぎます。
「エンジニアによきに計らってもらおう」と放置するのではなく、PMが主導してお客様としっかり対話し、納得感のある基準を作る。それが結果としてプロジェクトをトラブルから守り、お客様の事業を成功に導く最短ルートになります。
要件の中身が固まり始めたら、次はそれを確実にやり遂げるための「実行計画」が必要です。 第5回では、成果物とスケジュールを漏れなく管理し、プロジェクトを完遂させるための要件定義のWBS・タスク一覧作成術を公開します。
要件定義シリーズ：実践ガイド一覧
[第1回] 要件定義の失敗しない進め方
[第2回] 企画構想の落とし穴を回避する点検ポイント
[第3回] 要求定義の具体的な進め方
[第4回] 非機能要件の進め方とヒアリング術（本記事）
[第5回] 要件定義のWBS・タスク一覧
[第6回] 要件定義の準備術（体制と成果物）
[第7回] 業務フローの基本的な書き方
[第8回] 業務フローのフレームワーク活用術（5W3H・As-Is/To-Be）
[第9回] 業務フローの書き方完全ガイド
