非機能要件の中の性能の説明です。
性能は、レスポンスとスループット、リソース使用量の３つの要素で成り立ちます。
ここでは、この３つを要求定義や要件定義でどのように決めていくのかを説明していきます。
１．業務量
性能の要求定義で重要なことは、まず業務量を明らかにすることです。
発注のシステムであれば一日の発注量、稟議のシステムであれば一日の起案件数、POSであれば一日の売上件数、といったものです。一日の業務量だけでなく、ピーク時の業務量があると、なお良いです。
またユーザー数も重要です。一日、どらくらいのユーザーが利用するのか、特に同時接続数はシステムの設計をする上で非常に重要になります。
ただ同時接続数はなかなか決めることが難しいです。同時に何人が利用するかなんて、普通は分からないので、感覚的に決めることが多いのですが、アーランC式というコールセンターの必要席数を算出するロジックを利用すると、何となく科学的に算出しか気になれます。
アーランC式とは、１コールあたりの対応時間、１時間あたりのコール数、応答率をインプットにして、必要な要員数（席数）を算出する公式です。
例えば、１コールあたりの対応時間が６０分で、１時間あたりのコール数が１０００件、応答率が１００％の場合、必要席数は２１０席です。応答率を８０％に下げると、１８１席で済みます。
これをシステムの同時接続数に応用すると、１回の処理時間を３秒、１時間あたりのトランザクションを１万件、応答率を１００％とした場合、同時接続数は２０トランザクションとなります。１時間あたりどれくらいの業務量が発生するかが分かれば、このアーランC式で同時接続数を算出することができます。
２．データの保存期間
性能とは関係のないようですが、主要データの保存期間も意外と重要です。
例えば日別の売上を過去３年分確認したいなんていう要件があると、かなり性能にも影響してきます。マスターも全世代保持するか、カレントだけを保持するかでも性能に影響します。
３．オンライン性能
業務量と保存期間の前提の中で、どれくらいのレスポンスを求めるかを決めます。
オンラインの場合、平常時とピーク時の２つの性能目標とその順守率を決めます。当然、平常時とピーク時の業務量が提示できていることが前提です。
上記例の順守率９０％は、オンラインでの操作の９０％が目標のレスポンス以内であるという意味です。
またピーク時の条件で重要なことは同時処理数です。
例えば発注のシステムで、ピーク時の発注件数が一日２０００件だったとします。これを一人の人が日中の８時間で２０００件の発注をする場合、１分で４件強の発注をすることになります。１５秒前後で１件の発注なので、人間の操作としてはかなり慌ただしいですが、システムとしては１５秒に１回程度しか処理をしないので非常に軽いです。
これが、一日の売上が落ち着いてくる１８時からの２０分で、１００人の人が２０００件の発注をする場合はどうでしょう。１人あたり１分で１件の発注なので、人間の操作としては比較的、落ち着いていますが、システムとしてはそれが同時に１００人分も発生するので、それなりにタイトです。
同じピーク時の発注件数が１日２０００件でも、それがどれくらいの集中度で発生するかで、システムの性能に与える影響が大きく異なるのです。
４．バッチ性能
要求定義や要件定義の段階では、バッチでどのような処理をするか具体的に決まっていないことも多いですが、バッチ処理時間については決める必要があります。
オンライン提供時間を可用性のところで決めるので、それ以外の時間帯がバッチの処理時間帯となりますが、オンライン終了後にメンテナンス作業をしたりする場合もあるので、それらの時間を考慮する必要があります。
上記例の場合、バッファーが４時間あるので、その間に臨時作業をしたりすることができます。またデータ量増でバッチ処理時間が伸びたとしても、余裕があります。オンライン起動を６時にしているのは、起動時に障害が発生した場合に２時間の対応時間を確保したためです。
５．オンライン性能の悩み
オンライン性能で悩ましいのは、レスポンス要求を画面レスポンスとするかサーバー内レスポンスとするかです。画面レスポンスは、オンライン画面で操作ボタンを押して、結果が返ってくるまでの時間をストップウォッチで計ります。サーバー内レスポンスはWEBサーバーのログから処理時間を確認します。
物わかりの良いユーザー部門であれば、サーバー内レスポンスで合意ができますが、一般的には画面レスポンスでユーザー部門とは合意し、ネットワークの細い拠点だと遅くなるという条件付きにします。
ネットワーク含めて構築する場合は別ですが、通常は既存のネットワークを利用するため、ネットワークの通過時間はオンライン性能の目標には含めないのが一般的です。
ただし性能テストで計測する際には、両方の時間を計測してレスポンスのボトルネックを確認しておくことは重要です。
６．サーバーリソース
オンライン提供中と夜間バッチ時間帯で、それぞれサーバーリソースの使用率の上限を決めます。
CPUやメモリーの使用率は、常時50%を超えると不安定になるので、オンライン提供中の日中の時間帯の平均使用率は50%未満が望ましいです。
予め割当てるリソース（CPU、メモリー、ディスク）が決まっている場合には、要求定義書（RFP）にそれを記載し、決まっていない場合には性能要求を満たすリソースをベンダーに提案してもらいます。
ここで決めた使用率の上限が、リソース監視の閾値になっていきます。
【振り返り】
今回は性能の要求定義と要件定義の説明でした。次回は性能の基盤設計（前編）の説明をしていきたいと思います。
①可用性
②性能
③拡張性
④運用保守
⑤移行
⑥セキュリティ
⑦ユーザービリティ／アクセシビリティ
⑧システム環境
