前回，オンラインのパフォーマンス要求の定義は，以下のポイントを押さえればよいということを書いた。

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

　「どの画面でも速いこと」などというわがままを言わないで，まずはパフォーマンス要求を定義すべき画面を特定する。例えば，受注入力画面のように利用頻度が高く，レスポンスが低下すると待ち行列ができて業務が障るような画面が，定義する対象として適している。業務的に監視する意味があるだけでなく，処理密度が高いほど取得したデータの母数が多くなって安定してくれるからである。

　コンサルティング会社の中には，システム・パフォーマンスの診断やチューニングと称したサービス・メニューを用意しているところもある。しかし，何百万円もかけて得た報告レポートが，「朝晩でI/O負荷が集中しています」「CPUがフルになる時間帯があるようです」「複数のアプリケーションからのアクセスが競合しているようです」みたいな内容ばかりで，さっぱり要領を得ないことがある。診断のほとんどは，システム資源の状況はレポートされても，ユーザー一人一人，画面一つ一つの状況は分からないからである。だから，アプリケーションに仕掛けを入れないで収集したデータによる診断は，総合的なハードウエア増強のシナリオを描くことはできても，それ以上のものにはなってくれない。

　そこで，新規アプリケーションを導入するときに，あらかじめ定点観測ができるようにアプリケーションに測定ポイントを仕込んでおくとよい。「端末識別ID」「ユーザー識別ID」「トランザクション識別ID」「画面識別ID」に「タイムスタンプ」を加えたデータをログで吐き出すようにしておくのである。本番中は，ログ監視プログラムを動かしておけば，ユーザー側からみたオンライン・レスポスが低下したら直ちに運用側にアラートを出すことが可能になるし，これで得たオンライン・レスポンスの実測値を分析すれば，ユーザーの利用パターンまで分かってしまう。

　あるユーザーで，メーカー提供のパフォーマンス診断ではハードウエア増強くらいしか案が出なかったケースがあった。そこで，この仕掛けを組み込んでパフォーマンスを計測してみた。すると，ランチタイムと休憩時間は注文入力が行われていないのに，それ以外の時間帯はひっきりなしに入力されていることが分かった。しかも，入力を月末まで溜め込んでまとめて入力するのでピークがよりひどくなっていることも分かった。結局，勤務体系を変え，データを都度入力するように現場を指導したら，マシンはすかすかに空いてしまった。

　ユーザーは，マシンやネットワーク資源が競合するといった制約や運用上の事情を知らないし，システム的な事情については最後の最後まで関心を持つことはない。オンライン・ユーザーにとっては，自分からみたエラプス・タイム（経過時間）がすべてであるともいえる。期待通りのパフォーマンスが得られなかった場合，なぜレスポンスが遅いのかという事情を説明しても何の解決にもならない。パフォーマンスに関するユーザー要求はこのような側面を持っている。

　システム構築におけるPDCAサイクル（Plan＝要求定義・設計，Do＝開発・構築，See＝本番・測定，Action＝改修・チューニング）を意味あるのもにしようとするならば，要求定義の内容から改修・チューニングまでが一貫して把握できなければならない。パフォーマンス要求に関しては，意味ある計測が可能なものとして要求定義される必要がある。パフォーマンス要求定義に必要な項目は以下の通りである。

(1)ユーザーにとって有意かつ限定されたパフォーマンス要求の種類
(2)目標数値
(3)測定方法
(4)測定を可能にするしくみの実現可能性

　パフォーマンス要求は，できあがったシステムが当初要求通りのパフォーマンスを出せばよいというものではない。システムの寿命を通じてユーザー要求を満足し続けることができなければならない，ということをまで含むのである。






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