技術

非機能要件を6分類で合意する。機能一覧だけでは決まらない品質の話

目次

「画面と機能の一覧は固まったので、要件定義はほぼ終わりです」。開発の相談でそう聞いた後に、停止できる時間、同時利用者数、バックアップ、権限の話を尋ねると、まだ決まっていないことがあります。

どのボタンで何ができるかだけでは、業務システムの使い勝手や守り方までは決まりません。必要なのは、機能要件と非機能要件を分け、事業への影響が大きい条件から発注者と開発者で合意することです。IPAの「非機能要求グレード2018」が示す6分類を使うと、話し合う範囲を見渡しやすくなります。

非機能要件とは何か

非機能要件とは、システムが「何をするか」ではなく、「どの程度の品質で動くか」「どの条件で運用するか」を定める要件です。画面や帳票、計算処理のような機能要件とは分けて考えます。

同じ機能でも、使えるシステムの条件は違う

たとえば、受注を登録する機能が同じでも、平日の日中だけ使えればよいシステムと、24時間止められないシステムでは、構成も費用も変わります。月末に10人が使う業務と、毎日100人が同時に使う業務でも、求める性能は同じではありません。

「受注を登録できる」という機能だけを合意しても、次の問いには答えられません。

  • いつまで動き続ける必要があるか
  • 何秒以内なら待てるか
  • 障害後、どの時点のデータまで戻せればよいか
  • 誰が閲覧し、誰が更新できるか
  • 誰が監視し、障害時に誰へ連絡するか

こうした条件を後回しにすると、開発者はどこかで前提を置かざるを得ません。その前提が発注者の期待と違えば、「機能は合っているのに業務では使いにくい」というずれが起きます。

非機能要件は、品質を上げるためだけの一覧ではない

非機能要件は、あらゆる品質を最高にするための注文表ではありません。必要な水準と、許容できる水準を選ぶための判断材料です。

停止を限りなくゼロに近づけ、処理を限りなく速くし、何重にもバックアップを持てば、一般に構築と運用の負担は増えます。一方で、水準を下げすぎれば業務停止や情報漏えいの損失が大きくなります。どこに費用をかけるかを決めることも、非機能要件の役割です。

IPAは、非機能要求についてユーザと開発者の認識の行き違いを防ぐため、項目を分類し、要求レベルを段階的に示す「非機能要求グレード」を公開しています。2018年版では、項目を6つの大項目に整理しています。

非機能要件の6分類では何を確認するのか

6分類は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーです。分類名だけを転記するのではなく、自社の業務に置き換えた問いにすることが重要です。

分類決めることの例発注者側で考える問い
可用性稼働時間、障害対策、復旧何時間止まると、どの業務に影響するか
性能・拡張性処理量、応答時間、将来の増加繁忙時に何人が使い、何件を処理するか
運用・保守性監視、バックアップ、問い合わせ、保守日々の確認と障害対応を誰が担うか
移行性移行時期、方式、対象、計画どのデータを、いつ、どの精度で移すか
セキュリティ利用制限、秘匿、追跡、対策、復旧誰に何を見せ、どの操作を記録するか
システム環境・エコロジー制約、規格、設置・利用環境既存端末やネットワークにどんな制約があるか

可用性と性能は「速く、止まらない」で終わらせない

「止まらないシステム」「速い画面」では、設計やテストに使える要件になりません。まず、業務上の許容範囲を数字に変えます。

可用性なら、利用する曜日と時間、計画停止を許せる時間、障害時に復旧を待てる時間を確認します。性能なら、通常時と繁忙時の同時利用者数、1時間あたりの処理件数、主要操作の応答時間を決めます。

数字を決めるときは、理想値だけでなく理由も残します。「月末の請求確定は15時までに終える必要があるため」「工場の2交代勤務で利用するため」のように、業務とのつながりを書けば、後から水準を見直しやすくなります。

運用・保守性と移行性は、リリース後と切替時を扱う

運用・保守性では、監視、バックアップ、ログ、問い合わせ窓口、障害時の連絡、定期メンテナンスを決めます。誰が何を見るかまで決めなければ、監視機能を作っても通知が放置されかねません。

移行性では、旧システムから何を持ってくるかを扱います。全履歴を移すのか、現在有効なマスタと未完了データだけにするのか。移行中に業務を止めるのか、並行稼働するのか。切替に失敗したときに旧環境へ戻すのか。これらは一時的な要件ですが、本番開始の成否を左右します。

セキュリティとシステム環境は、前提と責任の境界を決める

セキュリティは「しっかり対策する」と書いて終わりにせず、扱う情報と想定するリスクから決めます。役割別の閲覧・更新権限、認証方法、操作ログ、データの暗号化、脆弱性対応、インシデント時の連絡と復旧などが対象です。

システム環境では、利用端末、対応ブラウザ、ネットワーク、クラウド利用の制約、設置場所の条件などを確認します。古い端末を残すのか、社外から利用するのかによって、必要な対応は変わります。環境条件が曖昧なままでは、開発後に「現場の端末で動かない」という問題が起きます。

6分類を文書過多にせず合意するにはどう進めるか

最初からすべての項目を細かく埋める必要はありません。業務停止、情報の重要度、利用規模の3点から影響の大きい項目を選び、測れる条件と担当者を決めるところから始めます。

1. まず業務上の損失を聞く

「稼働率は何％必要ですか」と聞かれても、業務部門は答えにくいものです。それより、現場の言葉で影響を確認します。

  • 1時間使えないと、どの仕事が止まるか
  • 翌日まで復旧しないと、顧客や取引先へどんな影響が出るか
  • 1日分の入力が失われたら、再入力できるか
  • 誰かに見られると困る情報は何か
  • 月末や繁忙期に利用者と処理件数はどこまで増えるか

答えを集めると、優先すべき分類が見えてきます。停止の影響が小さい社内ツールなら、可用性に過剰投資しない判断もできます。個人情報や取引価格を扱うなら、権限と操作記録を先に詰めるべきです。

2. 曖昧な希望を、確認できる条件に変える

次に、「速い」「十分に保存する」「担当者だけ使える」といった言葉を、設計とテストで確認できる条件へ変えます。

たとえば「検索は速くする」ではなく、「通常の検索条件で結果が3秒以内に表示される」のようにします。「バックアップを取る」なら、取得頻度、保管期間、保管先、復元確認の頻度まで分けます。「管理者だけ更新できる」なら、対象画面と操作、管理者の定義を明記します。

ここで大切なのは、根拠のない厳しい数字を置かないことです。現行システムの計測、業務の締切、利用者への確認を材料にします。測れていない場合は、仮の目標であることと、いつ検証するかを残します。

3. 水準、費用、残るリスクを同時に比べる

要求水準には費用との関係があります。たとえば、夜間の短い計画停止を許す案と、常時稼働を求める案では、構成や保守体制が変わります。バックアップを持つだけの案と、別環境へ短時間で切り替える案も同じではありません。

発注者と開発者は、「高・中・低」の水準だけでなく、それぞれの概算費用と残るリスクを並べて選ぶ必要があります。選ばなかった水準も記録しておくと、事業規模や利用時間が変わったときに見直しやすくなります。

システムの作り方そのものを検討している段階なら、SaaSで足りる会社とスクラッチが向く会社の見分け方も先に整理しておくと、非機能要件にかけられる費用の考え方が明確になります。

非機能要件の合意で避けたい3つの失敗

失敗しやすいのは、テンプレートを埋めることが目的になる、抽象語のまま契約する、運用担当を決めない、という3つです。どれも一覧は完成して見えますが、判断や検収には使えません。

テンプレートの全項目を同じ深さで埋める

IPAの非機能要求グレードは、抜けを見つけるための広い地図として有用です。ただし、すべての業務システムで全項目を最高水準にするものではありません。

小規模な社内ツールと、社会的な影響が大きい基幹システムでは、必要な水準が違います。対象外にした項目は削除するのではなく、「対象外」と理由を残します。未検討と判断済みを区別できるからです。

「可能な限り」「十分な」「原則として」を残す

「可能な限り停止しない」「十分な性能を確保する」といった表現は、受け入れ時の判定ができません。発注者には安心感があっても、開発者には到達点が見えない言葉です。

すぐに数値化できない条件は、確認方法を決めます。負荷テストで測るのか、運用リハーサルで確かめるのか、利用部門の責任者が業務シナリオを実施するのか。合否の見方まで要件に含めます。

運用する人を決めず、機能だけ作る

バックアップ、監視、ログが実装されていても、確認する人と対応手順がなければ機能しません。特に、開発会社、社内の情報システム担当、業務部門の責任範囲は、運用開始前に線を引く必要があります。

既存システムを引き継ぐ場合は、新規開発よりも現状の運用条件が見えにくくなります。業務システム保守を引き継ぐ前の整理も使い、アカウント、契約、バックアップ、問い合わせ経路を先に確認してください。

非機能要件は、契約書や要件定義書へ項目名を並べただけでは合意になりません。業務上の理由、水準、確認方法、担当者がつながっているかを確認してください。

発注前に使える最小チェックは何か

初回の打ち合わせでは、6分類ごとに1問ずつ確認するだけでも、機能一覧だけの状態から前進できます。次の質問に答えがなければ、その項目を次回までの宿題にします。

  1. 可用性：利用時間と、許容できる停止時間は決まっているか
  2. 性能・拡張性：繁忙時の利用者数、処理件数、待てる時間は分かるか
  3. 運用・保守性：監視、バックアップ、問い合わせ、障害対応を誰が担うか
  4. 移行性：移すデータ、切替方法、失敗時の戻し方は決まっているか
  5. セキュリティ：情報ごとの閲覧・更新権限と、残す操作記録は決まっているか
  6. システム環境・エコロジー：利用端末、ブラウザ、ネットワーク、設置条件に制約はあるか

この6問は完成版の要件ではありません。話し合いの入口です。答えが事業判断を伴う項目は発注者が決め、実現方法と費用への影響は開発者が示します。一方だけに任せず、理由を共有して決めることで、認識違いを減らせます。

見積もりを比較する段階では、非機能要件の前提が各社でそろっているかも確認してください。片方だけがバックアップや監視、移行作業を含めていれば、総額だけの比較はできません。リプレース見積もりの妥当性を見極める3つの基準と合わせて、見積範囲を読み解くことが大切です。

まとめ

非機能要件は、システムの品質を際限なく高めるためのものではありません。業務に必要な水準、費用、受け入れるリスクを、発注者と開発者が同じ言葉で選ぶためのものです。

まずはIPAの6分類を地図にして、停止の影響、情報の重要度、利用規模を確認してください。そのうえで、重要項目を測れる条件に変え、確認方法と担当者まで決めます。全項目を同じ深さで埋めるより、判断理由が残る小さな合意から始める方が実務では役立ちます。

非機能要件を含め、業務システムの要件整理や既存環境の見直しが必要な場合は、現状の資料と運用を確認したうえで、優先順位を一緒に整理できます。

Webシステム開発

業務の整理から要件定義、設計、開発、運用まで、必要な範囲を一緒に組み立てます。

/service/development/

参考にした一次資料

よくある質問

非機能要件は小規模な社内システムにも必要ですか

必要です。ただし、大規模システムと同じ量の文書を作る必要はありません。利用時間、バックアップ、権限、問い合わせ先など、止まったときや情報が漏れたときの影響が大きい項目から決めます。対象外にする項目は、その理由を残してください。

非機能要件は発注者と開発会社のどちらが決めますか

業務上必要な水準と許容できるリスクは、発注者が判断します。開発会社は、実現方法、費用、技術上の制約、確認方法を示します。どちらか一方だけでは決められないため、業務上の理由と技術上の選択肢を並べて合意します。

IPAの非機能要求グレードを全部埋めれば十分ですか

全部を埋めること自体が目的ではありません。6分類から抜けを探し、対象システムに重要な項目を選びます。水準、理由、確認方法、担当者まで決まって初めて、設計と受け入れに使える要件になります。

関連記事