非機能要求をはかるための指針
「非機能要求グレード検討会」の検討結果が発表されました。2008年4月にこんなようなニュースが流れた事を覚えておいでの方もおられるかと思います。
非機能要求グレード検討会<http://www.nttdata.co.jp/nfr-grade/>のサイトを見てみると「公開成果物」という形でPDFファイルが公開されていました。なおPDFの閲覧には利用規約への同意が必要です。IDとパスワードが設定されていますが、原則として誰でも利用できるようです。詳細はリンク先をご確認下さい。
非機能要求（機能外要求）とは、上のITmediaのニュースから引用しますと
非機能要求とは、ユーザーの業務をシステム化する際に、その実現レベルに大きく影響する情報システムの応答速度などの性能や障害時の耐性など、システムの機能要求と比較すると従来は表しにくかったシステムの強度や品質を示すもの。
ということになります。私の実感からすると、お客様が「こうしたい」と考える要望に付随して、開発者側が考慮しなくてはならない点です。特に、お客様自身が気付いていなかったり、見えていなかったりということが多く、開発者側からすれば気を遣わなければならないポイントになります。
そこで発注側と受注側に共通したガイドラインがあることは大きな価値を持ちます。発注側は自分達がこれから構築しようというシステムに関係してきそうな項目を確認しておき、受注側もプロの目線から必要となる項目を確認しておくことが必要になるかと思います。ここ最近の景気動向ではグリーンITやDRPなどは発注側から言い出さなくては受注者側が強く勧めずらいように思いますし、受注側からすれば応答性能や運用時間帯などは最初の打ち合わせから固まってくれていると話が早く進んでありがたく感じるのではないでしょうか。
なお、こちらに関する話はオルタナティブブログでも森崎さんが既に取り上げていらっしゃいます。森崎さんのブログにこのようにある通り、
曖昧になりがちな非機能要求を計測可能な指標とすることは事前合意やスムーズな開発に必要になる。しかしながら指標による検討が難しいのが現実だろう。
森崎修司の「どうやってはかるの？」 > 非機能要求をはかる - JUAS「非機能要求仕様定義ガイドライン」 - : ITmedia オルタナティブ・ブログ <http://blogs.itmedia.co.jp/morisaki/2008/08/juas-f5e2.html>
「応答性に配慮してシステムを構築いたします」や「CO2の排出量削減につながる第一歩としての役割を果たすものとして機器選定を行ないます」などと仕様書に記述するだけに留めては意味がありません。SLAなど文書の形で構築前に合意形成を行なうに留まらず、更に言えば構築した半年や1年後になってから「この性能要求は余裕がありすぎたね」や「可用性の見通しが甘かったね」と受発注双方で振り返り、その次の構築に活用することが大切であると思います。