データ量の増加にシステムが対処できない、ビジネスのスピードを上げられない、ITコストの削減が進まない――。自社が直面する悩みの要因を突き詰めた結果、20年以上にわたって“塩漬け”にしてきたバッチ処理、すなわち「レガシー・バッチ」にたどり着く企業が増えている。もちろん、レガシー・バッチの解体は生易しいことではない。だからこそ、塩漬けにしてきた。では、先進企業は、どのようにして挑んだのか。JFEスチールやジャックス、サントリーなどの取り組みと、バッチの解体を支援する新製品の動向を追う。
|
本記事は日経コンピュータ8月21日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。なお本号のご購入はバックナンバーをご利用ください。
今年1月18日、東京証券取引所は、株式の注文をオンラインで受け付ける「売買システム」を通常よりも20分早い、午後2時40分に停止した。東証の歴史のなかで初めてのことである。
原因は、“ライブドア・ショック”をきっかけに個人投資家などの売り注文が殺到し、前月平均の1.5倍を超えるペースで約定が発生していたこと。約定とは売りと買いの注文が合致して取引が成立した状態で、1日の取引が終わると、すべての約定の結果を「清算システム」で集計・清算する。1月18日は、約定件数が清算システムの処理能力を超える恐れがあった。そのために東証は売買システムを停止し、集計・清算の対象となるデータの件数を抑えた。バッチ処理システムである清算システムの処理能力の限界が、オンライン・システムである売買システムを停止に追いやったわけだ。
浮上する三つの問題
東証のケースは特殊ではあるものの、ユーザー企業にとって無関係とは言い難い。
社内外から受け付けたデータを蓄積し、集計や仕分け、印刷などを一括してこなす「バッチ処理」――。多くの企業は、「顧客と直接やり取りするオンラインや情報系などの開発のほうが優先順位が高い」、「業務の流れが変わらないため、再構築の費用対効果が低い」といった理由で、「これまでバッチ処理に手が回らなかった」（JFEスチールの原田敬太IT改革推進部主任部員）。そうしてメインフレーム上にバッチ処理を“塩漬け”してきたツケが今、一気に回ってきている。
既存のバッチ処理システム、いわばレガシー・バッチがもたらす問題は、三つある。オンラインへ悪影響を及ぼす、ビジネス・スピードの向上を阻害する、コストを削減しにくくする、である。
一つ目の問題は、“夜間バッチ”で起こりやすい。オンライン終了後に動かす夜間バッチは、翌朝のオンライン・システムの稼働開始時間までに処理が終わっていなければならない。その状況でバッチ処理の対象となるデータの量が増えると、バッチ処理の実行時間が延び、規定の時間内に終わらなくなってしまう。いわゆる“突き抜け”だ。これが発生するとシステム運用に余裕がなくなり、トラブルを引き起こしやすくもなる。冒頭の東証は、こうした突き抜けを避けるためにオンライン・システムの稼働時間を短縮し、約定件数そのものを減らしたのである。
「コンピュータを効率よく利用する」というバッチ処理の目的がビジネスの現状に合わなくなってきた、というのが、二つ目の問題。大量のデータを蓄積してから一括で処理するのは、コンピュータを効率的に使うためだ。しかし、この形態では、顧客から「注文の翌日に回答を返してもらっているが、当日中に変更してほしい」と言われても、即座には対応できない。バッチ処理はデータベースのテーブルを一括ロックするので、通常はオンライン・システムと同時に動かせないからである。
 |
| 表1●バッチ処理のオンライン化/オープン化に踏み切った主なユーザー企業の取り組み |
見えてきた脱却の道
もちろん、バッチ処理が適している業務は今でもある。金融機関における定期預金の利息計算や、電力会社における顧客への請求書の印刷などが、その例だ。
しかし、レガシー・バッチが担っている業務がすべて、バッチである必然性はない。むしろ、レガシー・バッチの弊害は深刻度を増している。だからこそ、バッチ処理をなくしてオンライン化したり、プラットフォームをオープン系サーバーへ変えてメインフレームを撤廃するといった、レガシー・バッチの解体に踏み切る企業が相次いでいる（表1）。最近になって、複数のITベンダーがオープン環境でバッチ処理を動かせるようにするためのミドルウエアを出荷し始めたことも、オープン化を後押しする。
続きは日経コンピュータ2006年8月21日号をお読み下さい。この号のご購入はバックナンバーをご利用ください。
