最近何かと話題の「非機能要件」だが、これほど分かったようで分からない妙な気分になる言葉も珍しい。「機能要件以外のすべての要件」と言ったところで、説明になっていない。性能や信頼性などと例示しても、心にストンとは落ちていかない。ところが、この非機能要件についてよくよく考えると、実は恐ろしい。なんせ、今どきの非機能要件を定義するには、占い師にでもならなければ不可能なことが多いからだ。

　システム開発に携わる技術者は、この非機能要件になかなか思いが至らない。だから、ITベンダーは非機能要件で躓くケースが多い。テスト段階になって、客から「こんなの遅くって使えるか！」などとダメ出しされる事態に立ち至る。これはユーザー企業でも同じのようで、少し前に先進企業との誉れの高い金融機関の人に聞いたら、要件定義で抜け落ち運用部隊に指摘されて手戻り発生という事件もちょくちょくあるらしい。

　では、この非機能要件をどうのように考えればよいのだろう。まず機能要件だが、システムが業務プロセスを実現するうえで必要な動作や処理内容の定義のこと。だから、利用環境なんかを全く考慮しなければ、システム的には機能要件だけで業務プロセスを実現できる。ただ、大概の業務プロセスはシステムだけでは動かない。というか、多くの人が様々な条件の下でシステムを道具として使うことで、業務プロセスは回る。

　だから非機能要件は、システムの利用環境、利用シーンが明確にイメージできていないと定義することなんかできない。応答時間1秒が「遅くって使えない！」と怒られるか、「スゲェ、速いじゃん」と感心されるかは、使う人の環境や心理次第。システムの安定性にしても、「またかよ」と舌打ちされてリセットで済むのか、経営トップが直立不動、45度のお辞儀で謝罪会見を開かなければならないかで、要件は全く異なる。

　さらに厄介なのは、今どきのシステムが利用環境、利用シーンをイメージできなくなってきたことだ。その典型がECサイトやWebマーケティングのサイト。最近ではベンチャー企業などで随分ノウハウも溜まったが、今でもトラフィック・バーストなど予測が付かないケースが結構ある。その結果、非機能要件の定義があまく、アクセス数に耐えられずシステム・ダウンっていうのもよくある話だ。

　例えば以前、こんな話があった。ある大手流通がECサイトを構築した。先行他社に比べて、より利便性の高いサービスを提供する自信のサイトで、EC分野への本格進出と併せて、その企業の先進性を大きくアピールすることになるはずだった。ところが初日に事件が起きる。テレビ局の取材依頼が入り、すっかり喜んだ経営トップが取材を受けてしまったのだ。

　そのインタビューが放映されると、当然ECサイトへのトラフィックが急増。あっという間にシステムはパンクし、システムトラブルの格好のネタを提供してしまった。こういった事態は、システム開発側で事前に予測するのは不可能。当然、非機能要件の定義では、こうしたトラフィック・バーストに耐える性能は盛り込まれていなかった。

　昔はよかった。業務プロセスが確立しているバックオフィス系の業務プロセスのIT化では、利用環境や利用シーンは明確。非機能要件の定義もそんなに難しい話ではない。それでも開発現場では、非機能要件は機能要件に比べて軽視されていた。今は反対に非機能要件の重要性が叫ばれるようになったが、システムの利用シーンがよく見えない。何が起こるか予測できないから、非機能要件も正確に定義しようがない。

　「新しいビジネスを創るためのシステム案件では、ユーザーもやりたいことが明確でなく、完璧な要件定義ができない」といった類の話を、ITベンダーからよく聞く。この場合の要件とは、もちろん機能要件もあるが、その多くが非機能要件。これから作るシステムが、どのような条件でどのように使われるかをイメージするのは、もう予測というよりも予言、占いの領域で、非機能要件なんぞは「そんなもの、分かるか！」である。

　だからITベンダーも、非機能要件について“松竹梅”のメニューを用意するぐらいでは、対処できないだろう。なら、どうするのか。一つの方法は、アラン・ケイのあの名言に従うことだ。「未来を予測する最善の方法は、未来を作り出すことである」。つまり、システムの利用シーンなどを事前に固定してしまうことだ。「社長、カットオーバー直後はマスコミに登場しないでください」とか、「当初は会員限定でスタートしましょう」とかである。

　結局のところ、非機能要件の多くはシステムとユーザーの妥協の産物。ユーザー側からばかりではなく、たまにはシステム側からユーザーに“利用シーンの要件”を突きつけても、バチは当たるまい。