「何秒で動けば満足か」を決め忘れないために ── IPA「非機能要求グレード」で非機能要件を整理する

「画面遷移が遅いと言われたが、契約書にも仕様書にも応答時間の取り決めがない」

「夜間バッチが朝までに終わらなくなったが、データが何年でどれだけ増えるか誰も見積もっていなかった」

「サーバー障害で半日止まって初めて、『何時間以内に復旧できる構成なのか』を発注時に確認していなかったことに気づいた」

システム開発のトラブルというと機能の認識ずれが思い浮かびますが、実際に運用が始まってから揉めるのは、こうした機能以外の要件、いわゆる非機能要件の決め忘れであることが少なくありません。

この決め忘れを防ぐための公的なツールが、IPA(独立行政法人情報処理推進機構)の非機能要求グレードです。この記事では、その中身と、中小企業の業務システムでの現実的な使い方を、発注側にも分かる言葉で整理します。

1．まず結論

• 非機能要件とは、「何をするか」ではなく「どのくらいの品質・条件で動くか」の要件。IPAの分類では、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーという6つの大項目に整理される
• 非機能要求グレードは、この6大項目の要求項目を網羅的にリスト化し、0から最大5までの6段階のレベルで発注側と開発側がすり合わせるためのIPAのツール群(無償)。実物のレベル定義は3.1節に抜粋した
• 全項目を埋める必要はない。自社に近い「モデルシステム」を選び、重要項目から順に、自社の実情に合わせて調整していく使い方が想定されている
• 非機能のレベルは上げるほど費用が増える。「なんとなく高い水準を要求する」のではなく、業務への影響から逆算してレベルを選ぶ
• 決めた結果は要件定義の文書に残す。ここで決めた前提が、見積もりの比較と、運用開始後の「言った・言わない」の防止に効く

この記事の知識マップ

非機能要求グレードは、IPAが公開する非機能要件整理のための無償ツール群で、可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジーという6大項目に非機能要件を分類し、0から5までの段階的なレベルで発注側と開発側がすり合わせられるようにする。グレード表は社会的影響の大きさで分けた3つのモデルシステムごとの目安レベルを示し、これを出発点に重要項目を調整したうえで、必要な範囲だけ238のメトリクスを収録した項目一覧で詳細化するという手順が想定されている。IPAの「情報システム・モデル取引・契約書」は要件定義工程の成果物として非機能要件の文書化を想定しており、非機能要求グレードは要件定義の段階でその作業を進めるための道具として位置付けられる。

flowchart LR
    accTitle: 非機能要求グレードの知識マップ
    accDescr: IPAの非機能要求グレードが非機能要件を6大項目に分類し、モデルシステム・グレード表・項目一覧という道具立てで要件定義段階のすり合わせを支えること、情報システム・モデル取引・契約書との関係を示す図
    non_functional_requirements_grade["非機能要求グレード"]
    non_functional_requirement["非機能要件"]
    nfr_availability["可用性"]
    nfr_performance_scalability["性能・拡張性"]
    nfr_operability_maintainability["運用・保守性"]
    nfr_migration["移行性"]
    nfr_security["セキュリティ"]
    nfr_system_environment["システム環境・エコロジー"]
    grade_table["グレード表"]
    item_list["項目一覧"]
    model_system["モデルシステム"]
    ipa["IPA(独立行政法人情報処理推進機構)"]
    requirements_definition["要件定義"]
    model_transaction_contract["情報システム・モデル取引・契約書"]
    non_functional_requirements_grade -->|"利用する"| non_functional_requirement
    non_functional_requirements_grade -->|"利用する"| nfr_availability
    non_functional_requirements_grade -->|"利用する"| nfr_performance_scalability
    non_functional_requirements_grade -->|"利用する"| nfr_operability_maintainability
    non_functional_requirements_grade -->|"利用する"| nfr_migration
    non_functional_requirements_grade -->|"利用する"| nfr_security
    non_functional_requirements_grade -->|"利用する"| nfr_system_environment
    non_functional_requirements_grade -->|"利用する"| grade_table
    non_functional_requirements_grade -->|"利用する"| item_list
    non_functional_requirements_grade -->|"利用する"| model_system
    grade_table -->|"より先に行うべき"| item_list
    grade_table -->|"前提とする"| model_system
    ipa -->|"実装を担う"| non_functional_requirements_grade
    non_functional_requirements_grade -->|"推奨される対応"| requirements_definition
    model_transaction_contract -->|"前提とする"| non_functional_requirement
    model_transaction_contract -->|"利用する"| requirements_definition

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全16件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2．非機能要件とは ── 「動く」と「使える」の間にあるもの

機能要件は「受注を登録できる」「帳票を印刷できる」のような、システムが何をするかの要件です。開発の打ち合わせは自然とこの話に集中します。

一方、次のような問いは、機能の一覧には出てきません。

• このシステムは、何時から何時まで動いていればよいか。土日は？夜間バッチ中は？
• 障害で止まったとき、何時間以内に復旧しないと業務が回らなくなるか。データはどの時点まで戻れれば許容できるか
• 何人が同時に使い、1日に何件処理するか。5年後にはデータ量はどれだけ増えているか
• 誰が監視し、バックアップを取り、障害の一報を受けるのか
• 旧システムのデータは、どこまで新システムへ持っていくのか

これらが非機能要件です。厄介なのは、決めていなくてもシステムは一応「動く」ことです。問題は運用が始まり、負荷が増え、障害が起きたときに初めて表面化します。そしてその時点では、サーバー構成や設計の根幹に関わるため、直すのに大きな費用がかかります。

3．非機能要求グレードとは

非機能要求グレードは、非機能要件をめぐる発注側と開発側の認識の行き違いを防ぐことを目的に、IPAが公開しているツール群です。初版は2010年4月に公開され、現在の最新版はセキュリティと仮想化(クラウド)まわりの変化を反映した「非機能要求グレード2018」(2018年4月公開)です。現在はIPAサイトのアーカイブ扱いのページに置かれていますが、非機能要件の抜け漏れを確認する基準として、実務では今も定番として使われています。

中身は、次の道具立てで構成されています。

各メトリクスには段階的なレベルの選択肢が定義されていて、「高い/低い」のような曖昧な言葉ではなく、レベルの選択として要求を表現できるのが特徴です。

3.1．レベルとは何か ── グレード表の実物を見る

「段階的なレベル」と言われてもイメージが湧きにくいので、実物を見てみます。レベルは0から最大5までの6段階で、数字が大きいほど実現の難易度が上がり、一般に開発・運用のコストも上がります。ただし全メトリクスが6段階あるわけではなく、選択肢が3つ(0〜2)しかない項目もあります。

たとえば可用性の最初の項目「運用時間(通常)」(項番A.1.1.1)は、次のように定義されています。カッコ内の時間は一例で、レベル選定の条件そのものではありません。

「うちのシステムは24時間動いていてほしい」という漠然とした要望が、この表の上では「レベル5を選ぶ」という具体的な選択になります。そして選んだ瞬間に、運用の交代要員や冗長構成の費用が付いてくることも同時に見えます。

もう1つ、発注側が数字で語りやすい「稼働率」(項番A.1.5.1)を見ておきます。こちらはグレード表の備考に、レベルごとの年間停止時間の目安まで書かれています。

「99%と99.9%はほとんど同じでは」と感じるかもしれませんが、年間の停止時間で見ると87.6時間と8.76時間、丸1日と半日弱の違いです。非機能要求グレードの本当の効果は、この「言葉では近いが、業務影響は10倍違う」を数字で並べて見せてくれることにあります。

なお、グレード表にはモデルシステムごとの目安レベルも記入済みです。上の2項目では、たとえば次のようになっています。

自社に近いモデルの列を出発点にして、「うちは夜間バッチがあるからもう1段上」「その代わり稼働率はここまで要らない」と上げ下げしていく。これがグレード表の使い方です。

3.2．3つのモデルシステム

もう一つの特徴が、システムが停止したときの社会的影響の大きさで分けた3つのモデルシステムです。

• 社会的影響がほとんど無いシステム
• 社会的影響が限定されるシステム(企業の基幹システムなど)
• 社会的影響が極めて大きいシステム(社会インフラなど)

グレード表には、モデルごとの目安レベルが記入済みです。つまりゼロから議論を始めるのではなく、「うちはこのモデルに近い」と当たりをつけてから、実情に合わせて上げ下げしていく使い方ができます。

4．6つの大項目 ── 発注側の言葉に翻訳する

非機能要求グレードの6大項目を、発注側が答えられる問いに置き換えると次のようになります。

こうして見ると、6大項目のほとんどは技術の質問ではなく業務の質問であることが分かります。「月末の請求処理が半日遅れたら何が起きるか」に答えられるのは、開発会社ではなく発注側です。非機能要件の主導権は、実は発注側にあります。

5．現実的な使い方 ── 238項目を埋めようとしない

項目一覧には238のメトリクスがありますが、全部を一つずつ議論するのは中小企業の案件では現実的ではありませんし、利用ガイドもそういう使い方を想定していません。想定されている流れはこうです。

1. モデルシステムを選ぶ
   (自社のシステムはどの影響度に近いか)
        ↓
2. グレード表の重要項目について、
   モデルの目安レベルを出発点に自社の実情で調整する
        ↓
3. 必要な部分だけ、項目一覧で詳細化する

中小企業の業務アプリなら、ステップ2の「重要項目のすり合わせ」だけでも効果は十分にあります。経験上、少なくとも次の点だけは要件定義で文書にしておくことをおすすめします。冒頭に挙げた3つの事例が、どれもこの表のどこかを飛ばしたために起きていることに注目してください。

このとき忘れてはいけないのが、レベルとコストのトレードオフです。たとえば「絶対に止まらないシステム」を目指すと、サーバーの冗長化や監視体制で費用は跳ね上がります。「業務が翌朝まで待てるなら、当日中の復旧で十分」と判断できれば、その分を他へ回せます。非機能要求グレードのレベルは、要求を上げる道具ではなく、業務影響と費用のバランスを話し合うための共通言語として使うのが正しい距離感です。

6．契約・見積もりとの関係

非機能要件は、契約とも直結します。

まず見積もりの比較です。非機能の前提を揃えずに複数社から見積もりを取ると、A社は冗長構成、B社はサーバー1台で見積もっているかもしれません。金額の差が構成の差なのか見込みの甘さなのか、発注側には判別できなくなります。

次に検収と運用開始後です。応答時間やバックアップの取り決めが文書にあれば、「遅い」「想定外」という水掛け論は、基準に照らした事実の確認に変わります。

IPAの「情報システム・モデル取引・契約書」でも、要件定義工程の成果物として非機能要件を文書化することが想定されています。要件定義を準委任で行い、決まった内容をもとに開発を請負で契約するという多段階契約の流れの中に、非機能要求グレードは自然に組み込めます。契約のかたちについてはIPA「モデル取引・契約書」の解説記事をご覧ください。

まとめ

IPA「非機能要求グレード」のポイントを整理します。

• 非機能要件は「どのくらいの品質・条件で動くか」の要件。決めなくても動くが、運用開始後に表面化して揉める
• 非機能要求グレードは、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6大項目・238メトリクスを段階的なレベルですり合わせるIPAの無償ツール群
• レベルは0から最大5までの6段階。たとえば稼働率なら99%(年間87.6時間の停止)がレベル2、99.99%(年間52.6分)がレベル4というように、言葉では近い要求の違いが数字で並ぶ(第3章)
• 3つのモデルシステムの目安レベルを出発点に、重要項目から調整する。全項目を埋める必要はない
• 6大項目の中身はほとんど業務の質問。答えを持っているのは発注側
• レベルは上げるほど費用が増える。業務影響から逆算してバランスを選び、結果を要件定義の文書に残す

「何を作るか」と同じくらい、「どのくらいの品質で動き続けるか」を先に決めておくこと。それが、動くのに使えないシステムと、その後の揉めごとを防ぐいちばん安い方法です。

参考リンク

非機能要求グレードはIPAサイトのアーカイブ扱いのページにあり、検索から辿り着きにくいので直リンクを載せておきます。いずれも無償で、利用条件のページを経由してダウンロードする形です。

• システム構築の上流工程強化(非機能要求グレード) ─ IPAのアーカイブ内の入口ページ。ここから各資料へ辿れます
• 非機能要求グレード 紹介ページ ─ ツール群の構成と、モデルシステムの選定から重要項目のレベル決定へ進む利用手順の説明
• 非機能要求グレード本体(日本語版) 使用条件 ─ 利用ガイド(解説編・利用編・活用編)、グレード表、項目一覧、樹系図、活用シート(Excel)一式のダウンロード。まず落とすべきはこれです
• 非機能要求グレード2018 利用ガイド「活用編」第2版 使用条件 ─ 2019年3月に改訂された活用編
• 非機能要求グレード研修教材 使用条件 ─ 社内勉強会に使える教材一式
• 情報システム・モデル取引・契約書 ─ 第6章で触れた、契約と要件定義の関係を扱うIPAの資料

本記事の第3章で引用したレベルの定義と年間停止時間の目安は、上記「本体(日本語版)」に含まれる活用シート(項番A.1.1.1「運用時間(通常)」およびA.1.5.1「稼働率」)によります。

業務システムの要件整理でお困りの方へ

非機能要件のすり合わせには、業務の実情(ピーク時期、データ量、止まったときの影響)と、それを実現するシステム構成の両方を行き来する作業が必要です。

合同会社小村ソフトでは、Windows業務アプリやWebシステムの受託開発・改修のご相談の際、この記事で紹介した考え方に沿って、性能・運用・障害時の挙動を要件の段階で一緒に整理しています。「今のシステムの処理がだんだん遅くなってきた」「更新を機に運用の取り決めを見直したい」といった段階からでもご相談いただけます。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

非機能要件とは何ですか？

システムが「何をするか」(機能要件)以外の、「どのくらいの品質・条件で動くか」に関する要件です。たとえば、システムをいつ使えるようにするか(可用性)、何人で使って何秒で応答するか(性能・拡張性)、誰がどう運用・保守するか(運用・保守性)、旧システムからデータをどう引き継ぐか(移行性)、どんな防御をするか(セキュリティ)、どんな環境に設置するか(システム環境)などが該当します。決め忘れると「動くけれど使いものにならない」システムになりがちです。

非機能要求グレードは無料で使えますか？どこで入手できますか？

IPAのWebサイトから無償でダウンロードできます。グレード表・項目一覧・樹系図・活用シートと利用ガイド(解説編・利用編・活用編)がセットになっており、最新版は2018年4月公開の「非機能要求グレード2018」です。現在IPAサイトではアーカイブ扱いのページに置かれていますが、非機能要件の抜け漏れ確認の基準として、実務では今も広く使われています。

238項目すべてを決めないといけないのですか？

いいえ。全メトリクスを一つずつ議論することは、利用ガイドでも想定されていません。まず自社に近いモデルシステムを選んで全体の目安を決め、グレード表にある重要項目を中心に自社の実情に合わせて調整し、必要な範囲だけ項目一覧で詳細化する、という段階的な使い方が示されています。中小企業の業務システムなら、重要項目のすり合わせだけでも「決め忘れによる揉めごと」の大半は防げます。

非機能要件はいつ決めるべきですか？

要件定義の段階です。可用性や性能の目標は、サーバー構成や設計の根幹に関わるため、開発が進んでからの変更は費用と期間に大きく影響します。IPAの「情報システム・モデル取引・契約書」でも、要件定義の成果物として機能要件だけでなく非機能要件を文書化することが想定されています。見積もりを比較する段階で非機能の前提を揃えておかないと、金額の違いが構成の違いなのか、見込みの甘さなのか判断できなくなります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。