「非機能要件」ヒアリングの極意：18年の現場経験から語る「後悔しない」ための観点

「システムは動いて当たり前」。 顧客がそう思うのは当然ですが、その「当たり前」を支えるのが非機能要件です。

インフラエンジニアとして18年、大手SIerでオンプレ・クラウド計200台規模の大規模インフラを支えるサービスマネージャーとして、私は数多くの「定義漏れ」による悲劇を目の当たりにしてきました。

この記事では、私が実際に経験した苦い失敗談を独立した章として紹介し、その教訓から導き出した「現場で本当に必要な非機能要件の観点」を解説します。

【実録】私が経験した「非機能要件」の落とし穴

「まあ、なんとかなるだろう」という甘い見通しが、運用開始後にどれほどの工数と精神的負担を招くのか。私の実体験をお話しします。

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

あるプロジェクトで、ログの保存期間を曖昧にしたまま運用を開始しました。結果、適切なローテーションが行われず、膨大なログがディスク容量をじわじわと圧迫。ある日突然、ディスクパンク寸前でアラートが鳴り響く事態に陥りました。 「無限」のディスクは存在しません。容量管理は、設計段階での「有限の合意」から始まることを痛感しました。

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

「いつでも止めていい」という言葉を鵜呑みにし、定期メンテナンス時間を事前に合意していませんでした。運用開始後、セキュリティパッチの適用や再起動が必要になるたび、エンドユーザーとの停止調整に奔走し、毎回多大な労力を費やすことになりました。 運用が始まってから「止めていい時間」を勝ち取るのは、想像以上に困難です。

共通言語としての「IPA 非機能要件グレード」

こうした失敗を防ぐための共通の「地図」が、IPAが公開している「非機能要件グレード」です。顧客とエンジニアの認識を合わせるための最強のフレームワークです。

IPA 独立行政法人 情報処理推進機構：非機能要件グレード

1. 可用性 (Availability)

「システムが止まらずに動き続けること」を定義します。単に「止まらない」だけでなく、止まった時にどうするかまで踏み込むのが現場のポイントです。

• 稼働時間・サービス時間:
  • 24時間365日か、平日9:00〜18:00か。
  • 計画停止（メンテナンス）の許容頻度と時間帯。
• 目標復旧時間 (RTO: Recovery Time Objective):
  • 障害発生から何時間（何分）以内に復旧させる必要があるか。
• 目標復旧時点 (RPO: Recovery Point Objective):
  • データが失われる際、どの時点まで戻せれば許容されるか（例：1日前、直前まで等）。
• 耐障害性:
  • 単一障害点 (SPOF) の排除。サーバー、ネットワーク、ストレージの冗長化レベル。

2. 性能・拡張性 (Performance & Scalability)

「快適に動くか」と「将来の成長に耐えられるか」を定義します。

• オンラインレスポンス時間:
  • 画面ポチっとしてから何秒以内に反応を返すか（平均・最大）。
• スループット（処理能力）:
  • 1秒間、あるいは1時間あたりの最大トランザクション数（リクエスト数）。
• ピーク時負荷:
  • キャンペーン時や月末など、特定時期のアクセス増をどう見積もるか。
• 拡張性 (Scalability):
  • ユーザー数やデータ量が増えた際、スケールアップ（スペック向上）かスケールアウト（台数増加）で対応可能か。

ここでヒアリングした「ピーク時のリクエスト数」や「目標レスポンス時間」は、サーバーのCPUコア数を決定する重要な変数となります。

集めた数値を具体的にどうスペックに落とし込むか、その計算式については以下の記事で詳しく解説しています。

3. 運用・保守性 (Operability & Maintainability)

「日々の運用が回るか」「壊れた時に直しやすいか」を定義します。ここが疎かになると運用チームが疲弊します。

• 運用時間・体制:
  • 夜間・休日の有人監視は必要か。自動通報で十分か。
• バックアップ:
  • 取得タイミング、保管期間、世代数。リストア（復旧）手順の確立。
• 監視要件:
  • 死活監視、リソース監視（CPU/メモリ/ディスク）、ログ監視、外形監視（ユーザー視点）。
• パッチ適用・アップデート:
  • OSやミドルウェアのセキュリティパッチをいつ、どのようなフローで適用するか。

4. 移行性 (Migration)

「旧システムから新システムへ、どう安全に移るか」を定義します。

• 移行対象データ:
  • どの範囲のデータを、どの期間分移すか（古いデータは捨てるのか、アーカイブするのか）。
• 移行スケジュール・停止時間:
  • 切り替え作業に許容されるサービス停止時間。
• 移行リハーサル:
  • 本番移行前に何回リハーサルを行うか。
• 切り戻し（ロールバック）基準:
  • 移行作業に失敗した場合、どの時点で継続を諦めて元の状態に戻すか。

5. セキュリティ (Security)

「外部の攻撃や内部の不正から守れるか」を定義します。

• 認証・認可:
  • ID/パスワードのポリシー、多要素認証 (MFA) の有無、権限管理 (一般ユーザー/管理者)。
• ネットワークセキュリティ:
  • ファイアウォール設定、IDS/IPS（侵入検知・防御）、WAF（Webアプリケーションファイアウォール）。
• データ保護:
  • 通信の暗号化 (SSL/TLS)、保存データの暗号化。
• ログ・証跡管理:
  • 「誰が・いつ・何をしたか」の操作ログをどこに、何年間保管するか。

6. システム環境・エコロジー (System Environment & Ecology)

「どこで動かすか」「物理的な制約は何か」を定義します。

• 設置場所・プラットフォーム:
  • オンプレミス（データセンターの場所・ラック電力・耐荷重）か、クラウドか。
• 法令・ガイドライン:
  • FISC（金融）、ISMAP（政府）、GDPR（個人情報）など、準拠すべき特定の基準があるか。
• 環境負荷（エコロジー）:
  • （大規模な場合）消費電力の抑制目標や、サーバーの集約率など。

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

18年のキャリアを経て、私が最も大切にしているのは、「設計の意図（思想）」を運用チームへ引き継ぐことです。

実機の構成やパラメータ、手順書などは、後から調べたりベンダーに確認したりできます。しかし、「なぜその構成にしたのか？」「なぜその制限を設けたのか？」という設計の方針は、目に見える形で残さない限り、二度と復元できません。

• 「コストの制約から、この部分の冗長化はあえて見送った」
• 「将来の拡張を想定して、あえてこの仕様を採用した」

こうした、ドキュメントに残りにくい「設計者の迷いと決断」こそ、運用担当者へきっちりとバトンタッチしてください。それこそが、運用者が現場で迷ったときに立ち返る「指針」になるのです。

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

非機能要件のヒアリングは、シートを埋めることがゴールではありません。顧客と「リスクとコスト」を誠実に話し合い、運用フェーズでの後悔を最小限にするための「合意」を作ることが真の目的です。

私の失敗談が、皆さんの現場でのヒアリングに少しでも役立てば幸いです。

ヒアリングシートで『要件』が固まったら、次はそれを具体的な『設計書』へと落とし込むフェーズです。要件定義で決めた数値や方針を、どのようにパラメータシートの『根拠』として反映させるか。設計の現場で迷わないための書き方をこちらで解説しています。