今さら聞けない RFPによる調達&提案ガイド(12) 非機能要件の仕様の記述が難しい理由

なぜ、非機能要件の仕様を記述するのは難しいのでしょうか。機能要件を仕様化する際、システムの利用者であるユーザーから吸い上げた要求を軸に事業戦略やIT戦略に基づいて行うのが一般的なプロセスです。基本的には、非機能要件を仕様化するプロセスも機能要件のそれと同じです。

しかし、非機能要件はIT戦略上の全体最適がより重要視される点、ユーザーがすべての答えを持っているわけではない点で機能要件とは異なり、こうした要素が非機能要件の仕様化を繁雑にしています。

前号で、機能要件を具体的に説明するために一戸建ての注文建築を例に出しましたが、非機能要件も同じように建築にたとえることができます。

素人ながらプロはだしの料理を作る人にとって、一般家庭のキッチンに備え付けられるコンロや火力では性能が足りないはずです。また、仕事や趣味に忙しくて留守がちの人が「防犯に強い家が欲しい」と建築会社に依頼したとして、「入室後30秒以内に暗証番号が打ち込まれない場合にセキュリティ会社や警察に通報が行くシステムを設置する」と提案されたとしましょう。

しかし、施主は「老齢の両親と同居しているため、両親に面倒をかけることになりそうなそのシステムの導入は無理だ」と言います。かといって、すべてのドアと窓にカギを3つずつ付けるという方法は現実的ではありません。

このように、ユーザー不在の状態、すなわち、求められる機能要件や利用環境を知らずに非機能要件を明らかにすることはできないのです。ただ、建築会社にでも勤務していない限り、施主だけで上記のような命題に対する最適解を求めることはできないということも理解いただけるでしょう。

さらに、今日のITはあまりにも多岐多様に渡るため、IT戦略や機能要件に基づく非機能要件を洗い出すのはただでさえ困難が伴います。

ここで、逆の立場から見てみましょう。あなたがメーカーに勤務していて、顧客に新しいインフラ・システムを提案したとします。その際もちろん、自社製品の優れた点、仕様、アフターサービスについてはあますところなく説明します。

しかし、その提案が顧客にとって価格と仕様におけるバランスがとれた提案と言えるかどうかは別問題です。いかに優れた製品を提案したとしても、機能要件と非機能要件が明らかになっていなければ、それが顧客にとって最適解かどうかはわからないからです。なお、開発に着手してからも、調達時にはわからなかった非機能要件を洗い出していく作業が求められます。