要求定義の検討項目の主たるものは機能要求であるが，それ以外にも運用要求やセキュリティ要求，品質要求，そしてパフォーマンス要求などがある。

　パフォーマンス要求は記述の方法が難しい。開発を受託する側との取り決めも容易ではない。システムのパフォーマンスに影響を与える要素の種類が多すぎるののに加え，その多くが変動したり不確定であったりするからだ。そもそも，パフォーマンスという概念があいまいである。特にオンライン・レスポンスに至っては感覚的な側面もあって，当事者間で概念を共有するのが難しい。

　パフォーマンスに関する各社の態度を比べてみると二極化していることが分かる。

第一グループ・・・・ハードウエア・ベンダー，パッケージ・ベンダー
自社製品や提供するソリューションのパフォーマンスの良さを強調する態度が顕著。特に，ライバル製品に対しては決して譲らない。

第二グループ・・・・SIベンダー，ソフトウエア・ハウス
パフォーマンスについてはできるだけコメントしない。滅多に「速い」とは言わない。

　この二つのグループの態度の違いは一体何からくるのか。それは「逃げ切れるかどうか」の違いではないかと思う。意地の悪い言い方になってしまうが，第一グループは，製品や環境や使い方のせいにできたり，「こんなもんです」と開き直ることができる。売った者勝ちみたいな世界でもある。第二グループは，ユーザーが納得する結果が出るまで家に帰してもらえないことが多いし，明日も明後日もそのまた先もあるから未解決問題は結局自分に戻ってくる。

　この問題を顧客の視点でとらえてみると，両グループのどちらの態度も顧客を満足にすることはできていない。ハードウエア・ベンダーやパッケージ・ベンダーの言うことは5割引きくらいにしておかないと後で痛い目に遭うし，SIベンダーやソフトウエア・ハウスはパフォーマンスに関しては慎重であり，いい数字を約束してなんかくれない。

　パフォーマンス要求で失敗しないこつは，パフォーマンスに影響をあたえる不確定要素や変動要素をできる限り排除することである。オンラインを使用するユーザー数が1でも100でも1000でも速いこと，なんていう要求は駄目である。どんな画面を操作しても3秒以内，なんていう要求も駄目である。もう一つの問題として，パフォーマンス要求は数値として測定・記録可能なものでなければならない。人間の手を介在しないシステム的に取得可能なデータを基準にできることが望ましい。

　そのためには，まずユーザー側の理解を得る必要がある。パフォーマンス要求に関する条件を絞り込むのはベンダー側が防衛線を張っているからではないか，と思われたら意味がない。こうすることで，導入後ユーザーの視点でのパフォーマンス維持や改善ができるようになるのだということを良く理解してもらうことが大切である。

　オンラインのパフォーマンス要求を例に挙げると，以下のポイントを押さえたらいいだろう。

・画面を特定すること。
・処理される状況（季節や月末・月初などの時期，利用ユーザー数など）を限定すること。
・測定ポイント（始点，終点）を明確にすること。
・アプリケーションに測定機能を実装し，常時記録可能にすること。
・当初のシステム環境を記録・保存すること。

　次回は，これらを踏まえた上で，オンラインのパフォーマンス要求の具体的な例をご紹介する。

●編集部からのお知らせ 木村哲氏による書籍「本当に使える要求定義」を発売しました。このブログの1回目を執筆中にゲラのチェックをしていると紹介されたものです。要求定義にまつわるエピソードはもちろん，成果物のサンプルやプロセスマップなど実践的なノウハウが満載です。要求定義に苦労している人や自分のやり方が正しいかどうか知りたい人は，是非こちらをご覧ください。