【項目一覧】非機能要件のヒアリングシート｜現場で後悔しない必須項目と顧客への質問例

「システムは動いて当たり前」。 発注側の顧客がそう考えるのはごく自然なことです。しかし、その「当たり前」を現場で支える土台こそが非機能要件です。

要件定義の打ち合わせで、このような苦い経験をしたことはないでしょうか？

• 「可用性はどうしますか？」と聞いたら、「止まったら困るから100%で」と返された
• 「ログは念のため永久保存で」と言われ、運用開始後にストレージ費用が跳ね上がって揉めた
• 本番稼働後、「深夜にパッチ適用でサーバーを止めます」と伝えたら「勝手に止めるな」と怒られた

インフラエンジニアとして18年間、大手SIerで200台規模（10システム）の仮想基盤やサービスマネジメントを統括してきた私も、若手の頃は数々のヒアリング漏れによって手戻りや炎上を経験してきました。

顧客の多くはITインフラの専門家ではありません。

「目標復旧時間（RTO）は何時間ですか？」「RPOは？」と専門用語を並べたヒアリングシートを突きつけても、防衛本能から「全部最高スペックで、予算は安く」という無理な回答が返ってくるだけです。

非機能要件のヒアリングで最も大切なのは、「専門用語を、顧客のビジネス言語に翻訳して問いかけること」です。

この記事では、現場で後悔しないために厳選した「非機能要件ヒアリングの必須項目一覧」と、顧客の本音を引き出す「実践的な質問の言い換えフレーズ」を余すところなく公開します。

後工程での手戻りを防ぎ、顧客と強固な合意を築くための指針としてぜひお役立てください。

現場で後悔しない非機能要件ヒアリング項目一覧＆顧客への質問例

現場で必須となる主要4分野（可用性、性能、運用・保守、セキュリティ）の重要項目と、打ち合わせでそのまま使える具体的な質問例をまとめました。

① 可用性（システムを止めないための要件）

項目名	技術的観点	【重要】顧客への質問言い換え例	現場での決定目安・考え方
サービス提供時間	稼働時間（24/365 or 平日日中）	「夜間や土日・祝日に、システムが止まっていても業務に支障がない時間帯はありますか？」	業務時間外に停止可能であれば、夜間の有人監視や過剰な冗長化構成を省き、コストを大幅に抑えられます。
目標復旧時間（RTO）	障害発生から何時間で復旧させるか	「万が一サーバーが完全にダウンした場合、何時間以内なら業務が手作業や待機で持ちこたえられますか？」	「即時」ならマルチAZ/リージョン等の高額構成が必要。「半日〜翌営業日」ならバックアップからのリストア運用で安価に設計可能です。
目標復旧時点（RPO）	障害時、何時間前のデータまで巻き戻って許容されるか	「最悪の場合、何時間前のバックアップデータまで巻き戻っても、伝票や手入力で業務リカバリできますか？」	「1秒も失わない」＝リアルタイムレプリケーション。「前日夜間時点」＝1日1回の日次スナップショットで対応可能です。
計画停止の許容度	メンテナンスによる計画停止枠	「OSパッチ適用や機器メンテナンスのために、**月1回・深夜に2〜3時間停止できる『定期メンテナンス枠』**をあらかじめ設定してもよろしいですか？」	【最重要項目】 ここを合意しておかないと、運用開始後にセキュリティパッチの適用すらできなくなります。

② 性能・拡張性（システムを遅くしないための要件）

項目名	技術的観点	【重要】顧客への質問言い換え例	現場での決定目安・考え方
目標レスポンス時間	画面表示・API応答速度	「画面をクリックしてから、何秒以上待たされると業務で『遅くてストレス・業務遅延』と感じますか？」	一般的なWebシステムでは「通常画面で2〜3秒以内、重い条件検索で5秒以内」がひとつの目安となります。
ピーク時アクセス	同時接続数・リクエスト集中	「月末・期末、特定イベント（セールや締め日など）で、アクセスや処理データが普段の何倍に跳ね上がりますか？」	サーバースペック（CPU/メモリ選定）の最重要インプットです。平均値ではなく「ピーク時」の数値を必ず握ります。
データ増加予測	ストレージ容量の拡張性	「今後3〜5年で、取引データや登録ユーザー数は現在の何倍くらいに増える見込みですか？」	年間増加率を算出し、3年後・5年後のディスク枯渇を防ぐ初期容量とスケールアウト方針を決定します。

③ 運用・保守性（現場を疲弊させないための要件）

項目名	技術的観点	【重要】顧客への質問言い換え例	現場での決定目安・考え方
監視・通報体制	有人監視 / 自動発報 / エスカレーション	「夜間や休日にサーバー障害が発生した場合、保守担当者が即座に駆けつけ・電話対応する必要がありますか？ それとも翌営業日の初動で問題ないですか？」	24/365有人監視をつけると運用人件費が跳ね上がります。システムの業務重要度（SLA）に応じて現実的な境界線を引きます。
バックアップ保管期間	世代管理・アーカイブ	「バックアップデータは何世代（何日分 / 何ヶ月分）残す必要がありますか？ 過去データの参照頻度はどの程度ですか？」	無期限に残すとストレージ費用が破綻します。「日次バックアップは14世代、月次バックアップは1年」などの明確な基準を作ります。
ログ保管期間と用途	監査ログ・アクセスログの保管	「操作ログやアクセスログは、社内監査や法的な規制で保管義務が決まっていますか？（例：1年、3年など）」	【トラブル多発項目】 「とりあえず全部永久保存」を阻止し、利用目的に応じた有限の日数を設定します。

④ セキュリティ・制約事項

項目名	技術的観点	【重要】顧客への質問言い換え例	現場での決定目安・考え方
アクセス元制限	ネットワーク境界・認証	「社外（テレワーク環境や外出先）から直接アクセスさせますか？ それとも社内ネットワークやVPN経由に限定しますか？」	IP制限、VPN必須、多要素認証（MFA）の導入要否を切り分ける基準になります。
準拠すべき業界基準	ガイドライン・監査基準	「貴社で準拠が義務付けられているセキュリティ規定（FISC、ISMAP、プライバシーマーク、PCI DSS等）はありますか？」	後から発覚するとアーキテクチャの根本的な再設計が必要になるため、初手のヒアリングで必ず確認します。

顧客の「予算はないが、全部最高で」を崩す合意形成術

ヒアリング項目のリストがあっても、多くのエンジニアが突き当たるのが「予算は潤沢にないが、システムが止まったり遅くなったりするのは困る」という顧客の要望です。

この無理難題を論理的に整理し、双方が納得して着地させる3つのテクニックを解説します。

① 「松・竹・梅」の3案でコストとリスクのトレードオフを可視化する

顧客に「可用性はどうしますか？」と単一の選択肢で尋ねると、責任回避の心理から「100%（止まらないこと）」と答えてしまいます。

最初から以下のように3つの選択肢（松・竹・梅）を提示するのが鉄則です。

• 松（高可用性プラン / 稼働率99.99%目安）
  • 構成: マルチAZ冗長、自動フェイルオーバー、24/365有人監視
  • コスト: 高（★★★） / 許容停止時間: 年間約52分以内
• 竹（標準推奨プラン / 稼働率99.9%目安）
  • 構成: クラウド標準冗長、自動再起動、平日日中オンコール、深夜定期メンテナンス枠あり
  • コスト: 中（★★☆） / 許容停止時間: 年間約8.7時間以内
• 梅（コスト最優先プラン / 稼働率99.0%目安）
  • 構成: 単一インスタンス、日次バックアップからのコールドリストア
  • コスト: 低（★☆☆） / 許容停止時間: 障害発生時は翌営業日まで復旧待ちの可能性あり

このように選択肢を並べることで、顧客自身が「社内利用の業務システムであれば、夜間停止を許容して『竹』にするのが最も費用対効果が高い」と、リスクとコストを天秤にかけて主体的に判断できるようになります。

② 「システム停止時の損失額」から逆算させる

「RTO（目標復旧時間）をどこまで短縮すべきか」で意見が分かれた場合は、感覚的な議論を避け、「システム停止時のビジネス損失額」を顧客と一緒に試算します。

もし「半日止まっても、社内事務が一時的に滞る程度（損失額：数十万円）」であれば、数千万円の追加投資をして即時復旧の仕組みを構築する経済合理性はありません。

「この規模感であれば、RTOは4時間（半日）に設定するのが投資として最も適切です」と論理的に提案できます。

③ 「やらないこと（非スコープ）」を要件定義書に明記する

非機能要件定義において、「何を実現するか」と同じくらい重要なのが「何を対象外とするか」の明文化です。

• 「大規模広域災害（リージョン全体のダウン）時の即時自動復旧は対象外とし、別リージョンへの手動復旧手順の確立にとどめる」
• 「平日業務時間外（18:00〜翌9:00）に発生した軽微な警告アラートは、翌営業日の調査開始とする」

「予算内で何を優先し、何をあえて割り切ったのか」を書面に残しておくことが、将来障害が発生した際の不要な責任追及やトラブルからチームを守る盾となります。

【実録】私が現場で痛感した「ヒアリング漏れ」の落とし穴

「運用が始まってから、現場でうまく調整すればなんとかなるだろう」。

そんな甘い見通しがどれほどのトラブルを引き起こすか。私がこれまでのキャリアで実際に直面した2つの苦い失敗事例を紹介します。

① 「ログ保存期間」を決めなかった代償

ある業務システムの構築プロジェクトで、ログの保存期間について明確な取り決めを交わさないまま、「念のため多めに取っておこう」と曖昧にした状態で本番稼働を迎えました。

運用開始から半年が経過したある月曜日の早朝。監視サーバーから「ディスク使用率95%超過」を知らせるCriticalアラートが一斉に発報しました。

適切なログローテーションとアーカイブ設計がなされておらず、肥大化したアクセスログとデバッグログがストレージ領域を限界まで圧迫していたのです。

急ぎログの削除を試みたものの、顧客からは「障害調査や社内監査で過去のデータが必要になるかもしれないので勝手に消さないでほしい」とストップがかかりました。

結果、業務影響を出さないよう別ストレージを手配し、深夜までログ退避作業に追われることになりました。

「ストレージ容量は有限である」という原則に立ち、設計段階で「ログの保存期間は〇日、それを超えたものは〇世代保管後に自動パージする」と明確に合意しておくことの重要性を痛感した出来事でした。

② 「メンテナンス枠」を握らなかった苦労

別のプロジェクトでは、「24時間動かしたいが、夜間ならある程度融通が利くよ」という顧客の口頭ベースの言葉を信じ、定期メンテナンス枠を定義書に明記していませんでした。

稼働後、OSの重大な脆弱性が発見され、緊急セキュリティパッチを適用してサーバーを再起動する必要が生じました。

しかし、いざ停止の相談を持ちかけると、顧客の業務部門から強い反発を受けました。「夜間も夜勤シフトが参照している」「バッチ連携が走っているため止めては困る」。

結局、わずか30分の再起動作業を行うために、関係部署との調整会議を複数回行い、深夜作業の手続きに膨大な時間と労力を費やすことになりました。

「運用が始まってから、顧客と『止めていい時間』を合意するのは極めて困難」です。

要件定義の段階で「第〇水曜日の深夜2:00〜4:00は定期メンテナンス時間とする」と枠を確保しておくことが、安定運用の絶対条件となります。

IPA「非機能要件グレード」は現場でどう使い倒すのが正解か？

非機能要件を体系的に学ぶ上で、IPA（独立行政法人 情報処理推進機構）の「非機能要件グレード」は業界標準とも言える優れたフレームワークです。

しかし、現場でありがちな失敗が「IPAの膨大な管理シートをそのまま顧客との打ち合わせに持ち込んでしまうこと」です。

• 項目数が数百項目に及び、顧客が開いた瞬間に圧倒されてしまう
• 大規模エンタープライズや金融向けの高難度な項目が多く、中規模システムの実態と乖離しやすい

現場で実践すべき使い方は、「顧客向けヒアリングシート」と「社内設計レビュー用の辞書」という2層構造で使い分けることです。

1. 顧客との打ち合わせ: 本記事で紹介した「実務に直結する15〜20の必須項目」に絞ったシートを使用する
2. 社内の設計検証: IPA非機能要件グレードを参照し、アーキテクチャ全体に重大な考慮漏れがないかチェックする

この役割分担を徹底することで、顧客との合意形成をスピーディに進めつつ、システム基盤の品質を確実に担保することができます。

サービスマネージャーが本当に伝えたい「設計の魂」

18年のキャリアを経て、現在サービスマネージャーとしてインフラ運用を統括する立場から、強く伝えたいことがあります。

それは、「なぜその仕様や数値に決めたのか」という『設計の思想・背景』を必ずドキュメントに残し、運用チームへ引き継ぐことです。

• 「コストの都合上、ストレージの自動冗長は見送ったが、その代替案としてスナップショットの取得頻度を倍にしている」
• 「将来のユーザー急増に対応するため、あえて現行負荷に対して1サイズ上のスペックを採用した」

サーバーの構成値やコマンド手順は、後から実機や設定ファイルを見れば把握できます。しかし、「設計者がなぜその制限を設け、どのような意図で決断したのか」という背景は、文字として残さない限り二度と復元できません。

要件定義で顧客と議論を重ねたその「思考のプロセス」こそが、運用フェーズで障害や仕様変更に直面したとき、現場のエンジニアが迷わず正しい判断を下すための「指針」となるのです。

まとめ：ヒアリングは顧客との「安心の合意」を作るプロセス

非機能要件のヒアリングは、単にチェックシートの空欄を埋めるだけの作業ではありません。

顧客とリスクやコストの現実を率直に共有し、運用フェーズでの手戻りや後悔を未然に防ぐための「安心の合意形成プロセス」です。

本記事の必須項目一覧と質問例を道標として、ぜひ次回の要件定義に自信を持って臨んでください。

💡要件を具体的な「インフラ設計書」へと落とし込む

非機能要件が固まったら、次はその数値をサーバー構成やパラメータへと具体化する設計フェーズに移ります。現場での設計書作成や運用設計については、以下の記事で詳しく解説しています。