最新技術ばかりが問題解決の糸口ではない。 1997/11/26

渡辺久のパソコン蘊蓄

学生時代、世話になった先輩から「助けてコール」（電話）があった。
彼は東京のある卸関係の会社で、現在ＳＥというかパソコンエンジニアをやっている。
最近迄、かなり高価なオフコンを使用していたのだが、現在はすべてパソコンへ移行しているという。

彼は大変な苦労をして、自社でなんとかシステムを構築したのである。
データエントリー用ＰＣ（伝票入力端末）が３０台あるという。
この入力処理スピードが異常に遅いというのだ。

１伝票入力後の待ち時間（次の伝票が入力可能になるまで）が約３秒から５秒掛かるらしい。

数枚の伝票入力であれば、別に気にする程でもないが、数百枚の伝票入力となると、パンチャーさんがイライラするばかりか、運用時間の大幅な無駄にもなってしまう。

なにか良い解決方法はないかと相談を持ち掛けられたのである。

データの流れを詳細に聞いてみると、クライアント側で作成したひとつの伝票が確定すると（１伝票の入力処理が終了）すると、伝票データをサーバーに送る仕組みという事だ。

彼が考えた解決策は、ＬＡＮの通信規格の設定を、現在使用している１０ＢＡＳＥ−Ｔ（伝送速度が１０Ｍビット／秒）から１００ＢＡＳＥ−Ｔ（伝送速度が１００Ｍビット／秒）に変更する事である。
これに伴い、ＬＡＮボードの変更も発生する。
この変更でいかがなものかと相談されたのである。


私の返答は「ＮＯ」である。
通信トラフィックの増大がひとつの原因ではあるが、サーバー側の伝票を溜め込むデータベースにも処理が遅くなる要因がいろいろ隠されてあるような気がしたのである。
排他ロックの開放待ちで遅くなるとか、データベースの環境設定とか........。
一番簡単にできる解決策は、伝票入力処理におけるデータの流れを変える事であると私は説明した。

具体的に説明すると、１伝票入力が終了した時点で、データをサーバーへ送るのではなく、クライアント側のデータベースに溜め込むのである。
こうして作成した伝票データはクライアント側にどんどん溜め込まれる。
伝票入力がすべて終了した時点で、クライアント側から伝票データを一括してサーバーへ送るのである。

非常に効率的だと思いませんか？

例えば、工場で、製造所（クライアント）と倉庫（サーバー）が少し離れていたとします。
製造所にて、ひとつの製品が出来上がりました。
台車に製品を積んで、倉庫に運びました。
ひとつの製品が出来る度に、台車で倉庫に運んでいます。
非常に効率が悪いのです。

そうか！まとめて倉庫に運べばいいじゃないか！
製品が溜まってから、まとめて台車で運びました。
おお！これは効率がいいぞ！
という、超「あたりまえと言えばあたりまえ」の理論です。

その後、彼はプログラムの修正に取り掛かりました。
いろいろ悩んでいたようで、
クライアントに溜めたデータと、サーバー側に同一データがあったらどうするの？
とかいろいろ質問された時には、思わず自分で考えろ！
と言ってあげましたが、可哀相なので教えてあげました。

先日、この修正プログラムが稼動したところ、パンチャーさんから「絶賛の声」があがったとの事。
１伝票入力後の待ち時間は 「0.何秒」とかで、気にするに値しないらしい。
めでたし、めでたし。

問題点としては.....。
上記の対策は、すべての仕様にマッチするものではありません。
私が記した対策は、伝票データを溜め込んだ後、一括して更新（在庫マスタとかの更新）する仕様です。
１伝票入力する毎に在庫を更新してしまうシステムでは私が記した対策ではマッチしません。
その辺は良く理解して頂けたらと思います。

最新技術が上手に活用されるには、ベースとなる「基本」がしっかりしていなければお話になりません。
この辺を履き違えてる方々は最近多いのではないのでしょうか。
問題が発生したら、頭の中を初心に戻し、基本を考え直してみる。
これは、すべてのトラブル対応に言える事だと思います。

先輩からの「ＨＥＬＰ」にえらい労力を使ってしまった.....。
先日の先輩との電話で、

渡辺：先日のシステムコンサルティングに関する「ご請求書」は月末でよろしいでしょうか？
先輩：あれ、渡辺コンサルは「廃業」したって聞いたんですけど.....。
今度先輩と飲みにいったら、大暴れしてやる！

ＥＮＤ....。