情報システムの可用性や性能、耐障害性、セキュリティなどを、本来求められる機能要求と対比して「非機能要求(要件）」と呼ぶことは、IT関係者なら周知の事実だろう。では非機能要求は何項目あって、それぞれどんなレベル(グレード）があるかについてはどうだろうか？
実は意外に曖昧で、システムの発注側であるユーザー企業はもちろん、受注側であるITベンダー側においても、非機能要求に関する明確な基準や規約は存在しなかった。それがコストや期間のオーバーランなどプロジェクトの失敗や高価で過剰品質の情報システムを生み出す要因になっている。
こうした状況の中の2010年2月25日、日本の大手システムインテグレータ6社と情報処理推進機構（IPA）は、共同で「非機能要求グレード」を完成したと発表した。NTTデータ、沖電気工業、NEC、日立、富士通、三菱電機インフォメーションシステムズの6社が2008年4月に発足させた「非機能要求グレード検討会（検討会）」が、2年がかりで策定を進めてきた成果であり、検討会のサイト（http://www.nttdata.co.jp/nfr-grade/）から成果物をダウンロードできる。
同グレードの主な構成要素は、「非機能要求項目一覧」「グレード表」「樹系図」の3つ。なかでも中核となるのは項目一覧である。要求定義の段階で明らかにしておくべき非機能要求を、「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つに分類。合計で236に及ぶ項目を洗い出し、整理したものだ。
単に整理しただけではなく、項目ごとの要求レベルを決める際の指標を0～5の6段階で定義したのが特徴である。例えば「運用スケジュール」という項目では、運用時間を指標に設定。「0:規定無し」から、「5:24時間無停止」まで、6段階の要求レベルを提示している。このレベルは、システム障害時の社会的影響に依存しており、影響がほとんどないシステムは2以下、影響が限定されるシステムは4以下、影響が極めて大きいシステムは5となっている。「今回のシステムは、万一停止すると社会的に大きな問題になるので、レベル5で」とか、「ユーザーは企業内の方々なので、コストも考慮してレベル2にしましょう」といった議論がしやすくなるわけだ。
このほか、グレード表はコストや品質への影響度が高い92項目について、一般的にどの程度の要求レベルを設定すべきかを例示している。樹系図は、非機能要求項目をツリー構造に展開したものである。非機能要求項目一覧を中核に据えつつ、使い勝手を高める工夫を施したといっていい。
となると次なる課題は、非機能要求グレードの普及／活用、つまり実際のシステム開発での利用である。というのも非機能要求グレード策定の背景には、2008年当時、社会的な問題を引き起こした大規模なシステム障害が続発したことや、その一方で情報システムの過剰品質が指摘されるといったことがあった。そうである以上、策定した非機能要求グレードを、日本における情報システムの基準や規格にすることを考えるべきと思える。「例えば、今回の鉄道関連のシステムは、レベル5の非機能要求グレードに基づいて開発された」と明示するようなイメージだ。
しかし6社やIPAは「今のところ、そうした考えはない」という。代わりに実施するのは、「自社の開発標準に今回完成したグレードを取り込み、提案や要件定義といったプロジェクトの上流工程における作業のガイドラインやチェックリストとして活用していく。自社エンジニア向けに、教育活動も展開する」（各社）ことだ。つまり6社の間でさえ非機能要求グレードの利用は任意で、何ら強制力はない。
となると、非機能要求グレードは絵に描いた餅になりかねない。使いやすさを重視しているとはいえ、非機能要求グレードを使うには理解／習得の努力が必要で、逆に全く使わなくてもシステム構築は可能だからだ。やはり「政府や自治体の調達案件では利用を義務化する」「少なくとも6社が手がけるシステム案件では利用する」「非機能要求項目一覧のレベルを明記した上で、開発したシステムを引き渡す」といった、ある種の強制が必要だろう。
一方、クラウド基盤への対応などバージョンアップも課題になる。検討会は今回のグレードの完成を持って解散し、成果物の著作権をIPAソフトウェア・エンジニアリング・センター（IPA SEC）に無料で譲渡。2010年4月以降はIPA SECが普及やバージョンアップを担っていく。だが実際にシステム開発を手がけることのないSECがバージョンアップし続けることは可能なのか、疑問は残る。
