【SE必見！】非機能要件の定義って何をすればいい？

はじめに

現代のシステム開発では、スピードとコストの要求が日々高まっています。

その中で、プロジェクトを成功させるには、適切なタイミングで必要な決定を下し、成果物（資料）を確実に準備することが不可欠です。

しかし、実際のプロジェクトでは「どのタイミングで何を決めるべきか」「どんな成果物を用意すればよいのか」が曖昧なまま進められることも少なくありません。

そこで本記事では、私のこれまでの経験をもとに、現代のITプロジェクト管理において「いつ、何を決めるべきか」や「どんな成果物（資料）が必要か」を解説します。

特に今回は、「要件定義」フェーズの「非機能要件の検討」 に焦点を当て、この段階で必要な検討事項と成果物について詳しく紹介します。

検討項目	内容	成果物	参考記事
業務変化の可視化	現在の業務と新しい業務を比較し、どのように変わるのかを明確にする。	業務フロー図 業務要件一覧	こちら
必要な機能の整理	新しい業務を実現するために求められる機能を整理する。	機能要件一覧	こちら
システム要件の検討	機能を実装するために必要なシステムや、連携すべき外部システム・データを整理する。	機能配置図 IF一覧	こちら
データ構造と画面設計	データの関連性を設計し、表示・入力のための画面構成を検討する。	テーブル一覧 ER図 画面遷移図	こちら
非機能要件の検討	性能やセキュリティなど、システムの品質要件を定義する。	非機能要件一覧	本記事

非機能要件とは？

非機能要件が果たす役割は？

機能要件の検討は進めやすい一方で、非機能要件の検討が後回しになりがちです。
しかし、非機能要件を曖昧なままにすると、開発後のパフォーマンスや運用に深刻な影響を及ぼすことがあります。

本章では、まず非機能要件の基本的な考え方を整理し、次章でIPAが提供する「非機能要求グレード」を活用してどのように非機能要件を定義すればよいかを解説します。

機能要件と非機能要件の違いは？

システム開発において定義すべき要件は、大きく「機能要件」と「非機能要件」に分かれます。

• 機能要件：システムが「何をするか」を定義するものです。
  例）「ユーザーがログインできる」「データを検索できる」「帳票を出力できる」といった要件
  
• 非機能要件：機能の裏側で「どのように動作すべきか」を定義するものです。
  例）「1秒以内に応答する」「24時間365日稼働」「データは暗号化して保存」といった要件

非機能要件は、ユーザーの体験や運用コストに直結する重要な要素であるため、機能要件と同等、もしくはそれ以上に丁寧に検討する必要があります。

Schooで無料講座をチェックする

非機能要件定義の進め方は？

ステップ1　非機能要件の洗い出し

非機能要件の定義は、まず「何を満たす必要があるか」を明確にすることから始まります。

• プロジェクト関係者（ユーザー部門、セキュリティ担当、運用担当など）からヒアリング
• システムの目的・利用者・想定利用状況などを整理
• 参考として過去プロジェクトのドキュメントを確認

ステップ2　非機能要件の分類と体系化

洗い出した非機能要件を、体系的に整理するために役立つのが、IPAが提供する「非機能要求グレード」です。

IPAとは？

IPA（独立行政法人情報処理推進機構）は、日本のIT分野における技術開発や人材育成を支援する政府機関です。非機能要件定義の支援ツールとして、「非機能要求グレード」や「安全なウェブサイトの作り方」などを提供しています。

非機能要求グレードの概要

IPAの非機能要求グレードでは、非機能要件を以下の6カテゴリに分類し、0～5の6段階のグレードで評価します。

カテゴリ	説明
可用性	システムの稼働率、ダウンタイムの許容範囲
性能・拡張性	レスポンス速度、同時接続数、負荷テスト
運用・保守性	ログ管理、監視、運用のしやすさ
移行性	他システムへの移行の容易さ
セキュリティ	認証・認可、データ暗号化、脆弱性対策
システム環境・エコロジー	クラウド対応、省電力設計

ステップ3　システム特性に応じたグレードの決定

次に、システムの種類や重要度に応じて、各カテゴリにどのグレードを設定すべきかを検討します。

カテゴリ	グレード	非機能要件
可用性	4	システム稼働率99.99%以上
性能・拡張性	3	通常時レスポンス順守率90%
運用・保守性	1	運用時間（通常）定時内

まとめ