◆応答時間という麻薬
仕様書の主な要素には、機能の他に性能がある。いわゆる、応答時間のことだ。利用者にとって応答時間は早ければ早いにこしたことは無い。ただし、それが、開発費用・期間に何の影響が無いのであれば。ここで、利用者と顧客は違うものだと言うことを忘れてはならない。顧客とは、システムに対価を支払うものであり、その利益を享受するものである。利用者は、システムによって、作業が楽になると言う利益を享受するが、対価を支払わない。作業者の作業効率が向上して、最終的に利益を享受するのは、対価を支払った顧 客である。
従って、応答時間による作業効率向上が、どれだけ利益に結びつくのかを、それに支払う対価と相関的に評価しなければならない。利用者からすれば、応答時間は麻薬のようなもので、どんどん要求はエスカレートしていく。最初は、１０秒くらいで十分のつもりが、５秒、３秒、１秒以下と要求は留まるところを知らない。実際、一度、応答時間１秒の世界に慣れてしまうと、３秒は、非常に遅く感じるものである。後戻りは、できないのであ る。
しかし、冷静に考えると、応答時間２秒の差が、どれだけ作業効率に影響を与えるのだろうか。確かに、遅いとイライラするが、大して差はないのである。良く高速道路で１２０ｋｍ／ｈで飛ばしている人がいるが、９０ｋｍ／ｈと比べても、到着時間は３０分しか違わない。それと、同じで応答時間の早いシステムは疲れる上に、大して作業効率に差は でないのである。
それまで、手作業で半日かかっていた作業が、システムで５分で可能となるのであれば、応答時間の数秒の差は問題ではない。銀行のＡＴＭのように、月末に使用率が跳ね上がり、応答時間の１秒の差が、長蛇の列を生んでしまうようなシステムは、そんなに多くはない。あるいは、処理の受付完了だけ直に応答を返して、裏側で処理を続行するという、擬似オンラインという手もある。こうすれば、利用者は、その間に別の作業をすることができるので、処理が完了するまで、数分かかったとしてもイライラしなくてすむという業務もあ る。
ところが、仕様書に応答時間１０秒以内と書くのと、３秒以内と書くのでは、ハードウエア／ソフトウェアの投資額が、１桁も違ってしまう。扱うデータ量、同時利用者数、最大利用者数、平均利用量、最大利用量を、ビジネスの面から投資採算性が妥当であるかを確認することを怠ってはならない。
ちなみに、インターネットを利用したＷｅｂオンラインでは、応答時間８～１０秒程度、イントラネットでは、３～５秒、ＣＡＤ系では、１秒以下というのが平均的な数値である。逆に、これに収まるように、１画面あたりのデータ処理量などを制限する必要がある。処理量に関係なく、応答時間３秒を保証せよというのは、どだいムリな話である。軽自動車のエンジンを、トラックに積み込んでも走るわけがない。結局、最大負荷時における応答時間３秒確保を想定して、ハ－ドウェアを準備することになる。これが、どれほど無駄なことかは、お分かりいただけると思う。
同様によくある誤解が、２４時間３６５日稼動できるシステムである。これからのシステムは、こうでなければならないと主張する向きもあるが、良く聞いてみると、繁忙期には、夜１２時まで仕事をしたり、日曜日に１部の人間が出勤することがあるというもので、２４時間勤務体制でも無く、土日営業するわけでもない。それを、流行の言葉で「２４時間３６５日」などと格好良く表現しているだけである。これを間に受けて、業者の推奨する本当に２４時間３６５日稼動できるようなハードウェアを準備したりすれば、とほうもなく高価なものとなる。
実際に私の知る例では、データ量１００万件、利用者数２０００人、応答時間３秒以内というＷｅｂシステムに対して、業者から総額１億円近い、ＵＮＩＸ機を２台使用した二重化システムを提案されたが、利用は非定常的であり、同時利用によるアクセスの集中は少ないこと、扱うデータは、キーによる一点処理であることなどを聞き出し、パソコンサーバ１台と既存のメインフレームを連携することで、ハードウェア費用は、数百万円で済んだこともある。それでも、業務上なんら支障は出ていない。
最小の投資で、最大の効果を生む、儲かるシステムを構築したいのであれば、利益を生まないようなムダな投資は、極力さけなければならない。
コメント