結論：業務システムの非機能要件は、要件カテゴリごとに整理し、担当部門・役割ごとに確認項目を割り振ることで、抜け漏れや認識ズレを防げます。対象業務の契約や情報管理の条件を確認し、専門的判断が必要な事項は適切な相談先へ確認します。専任部署の存在は前提にしません。

1. 非機能要件整理の前提条件と判断基準

  • システムの利用者規模（社内ユーザー数、外部取引先数）
  • 取扱データの機密性・重要度
  • 既存インフラや運用体制との整合性
  • 対象の業務に適用される契約、社内規程、必要な基準。任意の規格と法的義務を混同しない

上記が明確であれば、非機能要件のカテゴリ別整理に進めます。

2. 非機能要件の主要カテゴリと定義

カテゴリ定義（何を測るか）代表的な項目例
性能（Performance）システムが処理すべき速度・容量応答時間、スループット、同時接続数
可用性（Availability）システムが利用可能である時間・頻度稼働率、障害復旧時間（RTO）、復旧点（RPO）
信頼性（Reliability）障害発生頻度やエラー耐性障害間隔（MTBF）、エラーハンドリング方針
保守性（Maintainability）システムの変更・修正のしやすさコードモジュール化、ドキュメント整備、変更管理手順
セキュリティ（Security）情報資産を保護するための対策認証方式、アクセス制御、暗号化、監査ログ
拡張性（Scalability）将来的な機能追加や負荷増大への対応力水平・垂直スケーリング方針、プラグイン構造
運用性（Operability）日常運用・監視のしやすさ監視項目、アラート設定、運用マニュアル
コンプライアンス（Compliance）法令・規制への適合性個人情報保護、データ保存期間、監査証跡

3. 担当者別確認フローとチェックリスト

以下の表は、非機能要件カテゴリごとに「決定責任者」「レビュー担当」「最終承認者」を明示したものです。

カテゴリ決定責任者（要件定義）レビュー担当（技術的妥当性）最終承認者（組織的合意）
性能業務要件を整理する人基盤を確認する人技術と費用を判断する人
可用性業務要件を整理する人日常運用する人停止時の対応を判断する人
信頼性業務要件を整理する人品質を確認する人品質を判断する人
保守性開発リーダー開発する人変更範囲を判断する人
セキュリティ情報を管理する人業務要件を整理する人・開発リーダー情報の扱いを承認する人
拡張性業務要件を整理する人構成を検討する人技術と費用を判断する人
運用性日常運用する人リーダー開発リーダー運用統括
コンプライアンス情報の扱いを確認する人情報セキュリティ担当経営層（取締役）

4. 具体的な整理手順（担当者別アクション）

  1. 要件抽出ワークショップの実施（業務要件を整理する人が主導）
    • 利用部門からの業務要件と合わせて、非機能要件の期待値をヒアリング
    • 「性能」「可用性」などのカテゴリシートに記入し、担当者ごとに配布
  2. 技術レビュー（インフラ・開発リーダーが実施）
    • 各カテゴリの要件が現行インフラ・開発方針で実現可能か評価
    • 実装上の制約や代替案をコメントシートに追記
  3. リスク評価と対策立案（試験する人と情報セキュリティ担当）
    • 要件ごとにリスクレベルを「低・中・高」で判定
    • 高リスク項目は対策案（冗長化、暗号化方式等）を策定し、別紙で管理
  4. 合意形成・承認（技術を判断する人・情報の扱いを確認する人等）
    • 全カテゴリの要件シートを統合し、経営層へ報告
    • 承認後、要件定義書に正式反映
  5. 文書化と共有（プロジェクトマネージャー）
    • 要件定義書の非機能要件章を作成し、Gitリポジトリや社内Wikiに掲載
    • 変更管理プロセスに非機能要件の追加・修正手順を組込む

5. よくある失敗とその対処法

  • 要件が抽象的すぎる → 「応答時間は『速い』」ではなく「対象操作、同時利用の条件、許容できる待ち方を具体化し、測定する方法を合意する」と数値目標を設定。目標値は業務と計測から決め、根拠なく固定しない
  • 担当者の責任範囲が曖昧 → 上記表のように「決定」「レビュー」「承認」を明文化し、RACIチャートで可視化
  • 法令対応が抜け落ちる → 対象業務で必要な確認を行うステップをプロセスに組込み、コンプライアンスチェックリストを併用
  • 運用フェーズでの負荷増大 → 運用性要件に「監視項目」「アラート閾値」の具体例を入れ、日常運用する人と事前合意

6. 想定例：中小メーカーの在庫管理システムにおける非機能要件整理

※以下は「想定例」として示すもので、実際の数値や金額は記載していません。

  • 性能：同時利用者数が多い業務時間帯でも、検索画面の表示が遅延しないように設計。
  • 可用性：必要な利用時間帯と停止時の影響を確認し、復旧までに待てる範囲から対策を比較。冗長化を一律の前提にしない。
  • セキュリティ：在庫データは社内限定の機密情報として、閲覧できる役割と変更できる役割を決め、必要な操作履歴を選ぶ。
  • 保守性：コードはモジュール単位で管理し、影響する画面、帳票、連携を確認できる記録を残す。
  • コンプライアンス：自社に適用される契約と保管方針を確認して、データ保存期間と削除手順を文書化。

このようにカテゴリごとに要件を列挙し、担当者がレビューすることで抜け漏れを防げます。

7. 短いQ&A（FAQ）

Q: 非機能要件は必ず数値で示す必要がありますか？

A: 可能な限り測定可能な指標で表すことが望ましいですが、定性的な要件（例：「使いやすさ」）は評価基準やテストシナリオで補完します。

Q: 既存システムがある場合、非機能要件はどの程度引き継ぐべきですか？

A: 既存システムの実績データを基に、性能や可用性の実績値を評価し、継続する条件と見直す条件を確認します。過去の実績が新しい利用規模にも通用するとは限らないため、変更する範囲を照合します。

Q: 情報の扱いを確認する人が関与しないとリスクがある要件は？

A: 個人情報の取扱いや保存期間、監査証跡の保持など、法令や業界規格に直接関わる項目は対象に適用される条件を調べ、必要な場合は適切な相談先へ確認します。

8. まとめ（実務での活用ポイント）

  • 非機能要件は「カテゴリ」「項目」「担当者」の3軸で整理し、表やチェックリストに落とし込む。
  • 決定・レビュー・承認のフローを明文化し、RACIで責任範囲を可視化する。
  • 法令遵守が必要な項目は必要な確認先と判断の手順を組み込み、リスク評価シートで対策を明示する。
  • 整理した要件は要件定義書に統合し、変更管理プロセスで常に最新状態を保つ。

関連サービスと基礎資料

システム・アプリ開発の対象範囲もご確認いただけます。

本記事の手順・確認項目は一般的な検討のための提案です。AIを使って草案を作成し、構成・表現の点検を行っています。個別の契約・運用条件は実際の環境に合わせて確認してください。