第2回　「応答一律3秒」という性能要件はやめよう

　今回は、性能要件を具体化するポイントを紹介します。皆さんは、性能要件に何を定めればよいと思いますか。

　システムの性能要件で、「Webアプリケーションの画面レスポンス時間は3秒以内であること」「バッチアプリケーションは毎日午前0～午前5時の間に終了すること」としか定義していないプロジェクトを見かけます。この場合、以下のような問題が潜んでいます。

（1）全機能の処理時間を同じレスポンス時間に収めなければならない
　全機能に対して同じレスポンス時間を目標とするのは現実的ではありません。なぜなら、機能によって求められるレスポンス時間と処理の複雑度は異なるからです。

　例えばコールセンターのシステムで、「（a）電話オペレーターが操作する画面」と「（b）管理者がマスターデータをメンテナンスする画面」があるとします。レスポンスの悪化が直ちにビジネス機会の損失につながる（a）の方が、求められるレスポンス時間はシビアなはずです。（b）の方はレスポンス時間が少々かかっても、作業がスムーズに行える機能性を重視すべきでしょう。

　機能性重視と性能重視の区別なく一律の性能目標を定めることは、機能性重視の機能に対して、実現不可能な性能要件を設定することにつながり、工程の終盤で、解決が困難な性能問題へと発展する恐れがあるのです。

（2）前提条件が明確にされていない
　画面のレスポンス時間やバッチ処理時間の目標値は、前提条件とセットで定める必要があります。

　画面のレスポンス目標時間の場合、平常時を前提としているのか、ピーク時を前提としているのかによって達成の難易度は異なりますし、バッチ処理の場合は、処理するデータ件数によって必要な時間は異なります。性能要件には、そうした条件を明記しておくことが求められます。また、何年後の業務量を想定しているのかも前提条件として明確にすべきでしょう。

（3）何割の処理が目標時間を満たせば合格なのかが示されていない
　同じ負荷がかかった状態で同じ処理を実行したとしても、レスポンス時間は毎回同じにはなりません。例えばJavaを使ったWebアプリケーションでは、サーバー上でガーベジコレクション（GC）が発生した時に実行されたトランザクションのレスポンス時間は、平常時より長くなります。「100％目標時間を満たす」ことを合格条件とすると、発生頻度がまれなGC時間を織り込んで設計しなければならず、達成のハードルが高くなります。

　「全トランザクションの90％が目標時間を満たせば合格」というように、ごく一部の例外値を除外できるように決定するのが現実的でしょう。

性能要件の具体例

　上記を踏まえて、性能要件を具体化したときのイメージを表1に例示しました。

　この例ではレスポンス目標時間を機能ごとに設定し、さらにピーク時の目標時間を平常時とは別に定義しています。また、画面でのレスポンス時間とは別に、サーバー内処理時間を定義していることにも注目してください。

　Webアプリケーションのレスポンス時間は、図1のようにWebブラウザーとネットワークにおける処理時間を含めたものですが、この部分は利用環境に依存する部分が大きく、定量的な計測が困難です。

図1●Webシステムにおけるレスポンス時間の内訳

　このため、それらを除いたサーバー内処理時間（Webサーバー、APサーバー、DBサーバーにおける処理時間）の目標時間を設定し、評価対象とするのがよいと考えます。この例では、Webブラウザーとネットワークにおける処理時間を平常時で2秒、ピーク時で3秒とし、その時間を差し引いた時間をサーバー内処理目標時間と設定しています。

　なお機能別に目標時間を設定せよとはいっても、要件定義の段階で機能単位に細かく設定するのは困難かもしれません。その場合は目標値をいったん一律で設定しておき、性能重視の機能と機能性重視の機能について、それぞれで目標を調整する余地を残す形でユーザーと合意を形成しておくとよいでしょう。

　性能重視の機能は機能を落としてでも目標時間を達成することを目指し、機能性重視の機能は目標時間の方を調整するというような合意を得ておきます。ただし「何を持って性能重視の機能」とするかを明確にしないと、結局「すべてが性能重視の機能」となりかねません。性能重視の機能は、「全機能数の20パーセントまで」といった制約を決めておくような工夫は必要でしょう。