◆性能
「遅い！」そんなことは珍しいことではない。応答時間や処理時間は、要求仕様書に明確に記述してあれば、検査自体は、それほど難しいものではない。想定した利用状況において、定められた目標値をクリアすれば可、目標値に達しなければ不可である。問題は、目標値をクリアしなかった場合に、どのように対処するかということだ。目標値に達するように是正を求めるのは簡単だが、そのために払う時間的損失などの代償は、決して安くは無い。
なぜなら、性能を向上させるための労力は、機能的な不具合を是正するより、遥かに大きくなるケースが多い。これは、取りうる対策に正解が無く、試行錯誤的にならざるをえない性格があるからだ。しかも、冒頭に書いたように「遅い」と感じるシステムが納品されるケースは、意外と少なくない。その時、要求仕様で提示した性能を満足していないからといって、不具合であるとは言い切れない。判例でも、目標値をクリアしていなくても一定の性能を発揮し、実業務に支障が無い場合は、即、これを不具合であるとは認めていない。
従って、性能を向上させる作業については、これを別途、契約して実施するという業者もいるくらいである。追加の費用を支払ってまで、目標値をクリアすることに、どれほどの意味があるか良く考える必要がある。例えば、オンライン・システムに対する要求仕様での目標値が、５秒であったとしよう。ところが、実際に納品されたシステムでは６秒であった場合、追加投資をして１秒を短縮したところで、どれほど利益貢献するのだろうか？
「遅くて使い物にならない」というのは、利用者が新しいシステムや業務プロセスを受け入れたくない場合の理由として、もっとも利用されるところだ。ほんとうに、遅くて使い物にならないならば、今までどうり手作業で業務を遂行してもらうのも良いだろう。その場合、システムを使わないことを非効率の理由にしないことを約束してもらえばよい。たった数秒のことで、手作業のほうが効率が良いというならば、実際に証明してもらうことだ。それで、本当に手作業のほうが効率的ならば、そのシステムは思い切って捨ててしまえば良い。そもそも、システム化による効率化が間違っていたのであるから、それ以上ムダな投資をすることはない。
このように考えると、それまで手作業で１日以上かかっていた作業を、オンライン化して即時処理にした場合、例えその応答時間が１０秒であっても、いや３０秒であっても十分、効果はある。コンピュータが仕事をしている間、別の仕事をすればよいではないか。リアルタイム処理だからといって、１秒以下で応答が返らなければ満足しないというのはいかがなものだろう。「自動化の落とし穴」もあるので、いっそ、受付完了のみを１秒で応答し、その後、システムが裏側で処理し、結果は３０分後に返すというようなディレイドタイム処理を前提に、業務プロセスを設計するのも手である。これは極論かもしれないが、実際のケースでは、目標値に固執し、終わりの無い性能向上対策の泥沼に入って、本来の目的を見失っていることが少なくない。
確かに、劣悪な応答時間のシステムを納品する業者も存在する。しかし、その非を認めさせるには、かなりの専門知識と経験を要する。そのような人材が社内に存在するか、別のルートから専門家を招いて、調査にあたらせることになる。時間とお金が余っているなら、性能向上に力を注ぐのも良いが、そんな余裕が無いか、最小の投資で最大の効果を生むシステムを構築するのであれば、実際の業務上での影響を考慮した割り切りが必要である。業務システムは、Ｆ－１マシンではないということだ。
そうはいっても、やはり「遅い」システムは、実に腹立たしいものである。業者に「異常に」遅いと認めさせるには、一般的な指標が必要である。例えば、最近流行りのＪａｖａを使用したＷｅｂ画面システムなら１画面当たり、１００件のデータを表示するのに５～８秒を確保したい。この程度であれば、別に高価なハードウェアでなくても、パソコンサーバでも十分である。もし、応答時間が３０秒もかかるようであれば、データをデータベース（ディスク装置など、外部記憶装置）からの読み取りに時間がかかっているケースが多い。
やや専門的になるが、コンピュータの主要な構成要素である、ＣＰＵとメモリの処理速度は、今日では極めて高速である。例えば、周波数１ＧｈｚのＣＰＵなら、１秒間に数億もの命令を処理できる。業務システムのプログラムなら、せいぜい命令数は多くても数万のオーダである。メモリの処理速度もＣＰＵと１桁程度の差しかない。ところが、ディスクなどの外部記憶装置の処理速度は、ＣＰＵやメモリの数百分の１、つまり、数百倍遅いということである。従って、プログラムのアルゴリズム（解法）による性能の優劣を疑うより、この外部処理装置に対する入出力処理が遅いということを疑うべきである。
データベース処理では、ＳＱＬと呼ばれる操作命令の書き方が悪く、索引が使われておらず全件データを、総ナメしていないかどうか、同じデータを何度も読み取っていないかなどが疑わしい。実際に性能問題で、最も多く原因となっているのが、このデータベース処理に対するＳＱＬの優劣である。乱暴な話であるが、ハードウェアに追加で投資することが可能であるならば、メモリを大幅に追加して、データベース全体が、メモリに収まるようにしてしまえば、ディスクとメモリの相対速度から単純計算で、性能は１００倍近く 向上する。
これは、ちょうど人間が考え事や仕事をするのに、一々辞書や辞典を調べながら作業するよりも、全て頭の中に記憶してしまうほうが効率が良いのと同じ考え方である。時間を掛けて、ＳＱＬ命令を逐一調査して是正するより、このほうが手っ取り早い。コスト的にも、調査費用よりも、パソコン用メモリのほうが、遥かに単価が安い。とにかく、性能を向上させたいのであれば、外部記憶装置に対する入出力処理を極力行わず、メモリの中で処理できるように設計することである。また、要求仕様においても、１回の処理データ量を減らし、メモリ中だけで処理できるようにすることである。例えば、１画面当たりのデータ表示件数を１００件以下に制限し、数ページに分割して表示するような配慮である。
もう一つ、性能に影響する要素としてネットワーク負荷がある。今日では、ネットワークを介して、複数のコンピュータが接続されている。そのような環境下では、時間帯や曜日によってネットワーク負荷が変動する。負荷の重たい処理は、別の処理と曜日や時間帯をずらすなどの配慮も必要である。メモリの増加とは異なり、ネットワークを増強するには、かなりの投資が必要になる。該当のシステムだけのために、会社のインフラであるネットワークに投資するのは、投資対効果に対する相応の検討を要する。
コメント