スポンサーリンク

◆適切な応答時間を設定するには?

企業システム戦略

◆応答時間という麻薬
 仕様書の主な要素には、機能の他に性能がある。いわゆる、応答時間のことだ。利用者にとって応答時間は早ければ早いにこしたことは無い。ただし、それが、開発費用・期間に何の影響が無いのであれば。ここで、利用者と顧客は違うものだと言うことを忘れてはならない。顧客とは、システムに対価を支払うものであり、その利益を享受するものである。利用者は、システムによって、作業が楽になると言う利益を享受するが、対価を支払わない。作業者の作業効率が向上して、最終的に利益を享受するのは、対価を支払った顧 客である。

 従って、応答時間による作業効率向上が、どれだけ利益に結びつくのかを、それに支払う対価と相関的に評価しなければならない。利用者からすれば、応答時間は麻薬のようなもので、どんどん要求はエスカレートしていく。最初は、10秒くらいで十分のつもりが、5秒、3秒、1秒以下と要求は留まるところを知らない。実際、一度、応答時間1秒の世界に慣れてしまうと、3秒は、非常に遅く感じるものである。後戻りは、できないのであ る。

 しかし、冷静に考えると、応答時間2秒の差が、どれだけ作業効率に影響を与えるのだろうか。確かに、遅いとイライラするが、大して差はないのである。良く高速道路で120km/hで飛ばしている人がいるが、90km/hと比べても、到着時間は30分しか違わない。それと、同じで応答時間の早いシステムは疲れる上に、大して作業効率に差は でないのである。

 それまで、手作業で半日かかっていた作業が、システムで5分で可能となるのであれば、応答時間の数秒の差は問題ではない。銀行のATMのように、月末に使用率が跳ね上がり、応答時間の1秒の差が、長蛇の列を生んでしまうようなシステムは、そんなに多くはない。あるいは、処理の受付完了だけ直に応答を返して、裏側で処理を続行するという、擬似オンラインという手もある。こうすれば、利用者は、その間に別の作業をすることができるので、処理が完了するまで、数分かかったとしてもイライラしなくてすむという業務もあ る。

 ところが、仕様書に応答時間10秒以内と書くのと、3秒以内と書くのでは、ハードウエア/ソフトウェアの投資額が、1桁も違ってしまう。扱うデータ量、同時利用者数、最大利用者数、平均利用量、最大利用量を、ビジネスの面から投資採算性が妥当であるかを確認することを怠ってはならない。

 ちなみに、インターネットを利用したWebオンラインでは、応答時間8~10秒程度、イントラネットでは、3~5秒、CAD系では、1秒以下というのが平均的な数値である。逆に、これに収まるように、1画面あたりのデータ処理量などを制限する必要がある。処理量に関係なく、応答時間3秒を保証せよというのは、どだいムリな話である。軽自動車のエンジンを、トラックに積み込んでも走るわけがない。結局、最大負荷時における応答時間3秒確保を想定して、ハ-ドウェアを準備することになる。これが、どれほど無駄なことかは、お分かりいただけると思う。

 同様によくある誤解が、24時間365日稼動できるシステムである。これからのシステムは、こうでなければならないと主張する向きもあるが、良く聞いてみると、繁忙期には、夜12時まで仕事をしたり、日曜日に1部の人間が出勤することがあるというもので、24時間勤務体制でも無く、土日営業するわけでもない。それを、流行の言葉で「24時間365日」などと格好良く表現しているだけである。これを間に受けて、業者の推奨する本当に24時間365日稼動できるようなハードウェアを準備したりすれば、とほうもなく高価なものとなる。

 実際に私の知る例では、データ量100万件、利用者数2000人、応答時間3秒以内というWebシステムに対して、業者から総額1億円近い、UNIX機を2台使用した二重化システムを提案されたが、利用は非定常的であり、同時利用によるアクセスの集中は少ないこと、扱うデータは、キーによる一点処理であることなどを聞き出し、パソコンサーバ1台と既存のメインフレームを連携することで、ハードウェア費用は、数百万円で済んだこともある。それでも、業務上なんら支障は出ていない。

 最小の投資で、最大の効果を生む、儲かるシステムを構築したいのであれば、利益を生まないようなムダな投資は、極力さけなければならない。  

コメント

タイトルとURLをコピーしました