 |
Oracleデータベースをデータ加工エンジンとしてフル活用 ノンプログラミングでバッチが生まれ変わる！ バッチ自動生成ツール「101will」 |
| 「いつまで待ってもシステムが立ち上がらないじゃないか。これじゃ仕事にならないよ！」「すいません、昨夜の夜間バッチ処理がまだ終わっていなくて……」こんな経験をしたシステム管理者は、決して少なくないだろう。企業システムのフロントエンドはオープン系技術の導入により大きく進化を遂げたが、バックエンドでのバッチ処理の高速化や効率化は今も昔も変わらぬ永遠の課題だ。その解決を支援するのが、ワン・オー・ワンが提供する「101will」（ワンオーワン ウィル）だ。そのソリューションの鍵は、データベースをデータの保管場所としてだけではなく、データ加工エンジンとして活用する発想にあるという。これは具体的にはどういうことなのか、詳しく見ていくことにしよう。 |
| 進化が求められているバッチ処理 | ||
 |
||
メインフレームのダウンサイジング、あるいはオープンシステム化がIT業界で叫ばれるようになってから、すでに長い年月が経過している。とはいえ、メインフレームはまだまだ健在だ。むしろ最近では、SOA技術でメインフレームを含めた既存システムをいかに有効活用するかが焦点になっている。
メインフレームを活用している企業では、バッチ処理は必須であろう。日中の受発注などのトランザクション処理の結果を夜間に集計・加工し、翌日にさまざまな形で業務に活用する。ところが最近では、業務のIT化の進展に伴うデータ量の増加や、データ活用の多様化によるバッチ処理の複雑化などにより、夜間の限られた時間内にバッチ処理が終了しないといった問題も多く発生しているという。
さらに、変化への柔軟な対応も課題だ。ビジネス状況は日々変わりつつあり、必要な情報も頻繁に変化する。新たな情報が必要になれば、その基となるデータを新たに取得・加工しなければならない。データの集計・加工を行うバッチアプリケーションでは、日々発生する変化への迅速な対応が必要になっているのである。
| データベースをデータ加工処理エンジンとして活用 | ||
|
||
バッチ処理のこうした課題の解決を支援するのが、ワン・オー・ワンが提供する「101will」（ワンオーワン ウィル）である。COBOLで構築したメインフレームのバッチアプリケーションをオープンシステムに簡単に移行でき、さらに処理能力の大幅な向上を図ることができるバッチアプリケーション開発ツールだ。
メインフレーム上のレガシーシステムでは通常、COBOLで構築されたバッチアプリケーションがデータの抽出・集計処理を行う。オープンシステムでこれらのデータを活用するには、メインフレームで加工済みのデータをOracleなどのオープン系データベースに格納し、BIツールなどを使って参照する（図1）。
 |
| 図1 レガシーシステムでのバッチ処理 |
一方、101willで開発したアプリケーションでは、データの集計・加工処理をメインフレーム上のCOBOLプログラムではなく、Oracleデータベース上で行う（図2）。こうすることにより、バッチ処理に関するさまざまな問題を解決することができるのだ。
 |
| 図2 101willで開発したバッチアプリケーション |
ワン・オー・ワン 開発本部長の兒玉敏幸氏（写真1）は、こう説明する。
「集計したデータを結局データベースに保存するのであれば、集計や加工処理もデータベース上でやってしまおうと考えました。もともとデータベースエンジンは、大規模データを処理するのが極めて得意なのです」
 |
| 写真1 株式会社ワン・オー・ワン 取締役 開発本部長 兒玉敏幸氏 |
兒玉氏いわく、101willの特徴はデータベースをデータ処理エンジンとして最大限に活用するところにあるという。経験豊富な技術者でも、データベースを単なるデータの保管場所としかとらえていないことが多い。ワン・オー・ワンのメンバーは、かつて日本オラクルでデータベース製品の中核機能の検証・評価を行っていた技術者で構成されている。そのため、Oracleデータベースのことなら隅から隅まで知り尽くしているのだ。
「普段からOracleデータベースを扱っている技術者でも、データベースをデータ加工処理エンジンとしてとらえている人は少ないでしょう。処理エンジンとしていかに活用するか。これができて初めて、データベースを本当に使いこなしているといえるのかもしれません」（兒玉氏）
COBOLでバッチ処理を実行する場合、プログラムの中でデータを1件1件順番に取得して順次加工し、集計処理の中間結果をファイルに出力し、さらにその内容と別のデータを組み合わせて再度加工するといった処理を繰り返す。処理が複雑になると中間結果のファイルの読み書き処理が頻繁に発生し、システムに大きな負荷がかかって処理時間が長引いてしまう。
一方、101willで開発したバッチアプリケーションでは、抽出したデータに対しOracleデータベースの機能を使って一括で集計・加工処理を施すのだ。
「101willには、通常のバッチ処理では必須となる条件分岐や繰り返し処理といった概念はありません。これらは、集計対象となるデータを条件で絞り込む処理ですが、データベースならSQLの条件検索で一気に処理できます」（兒玉氏）
Oracleデータベースで一括処理すれば、中間結果ファイルの読み書きも必要ない。仮にバッチ処理のログ情報として中間結果が必要なのであれば、データベースの機能を使って中間結果を適宜テーブルデータとして保存すればいい。この場合でも、ファイルの読み書きを発生させず、データベースのメモリ空間内で一気に高速処理することが可能だ。
データをプログラムで逐次処理するのではなく、データベース上で一括処理する。この違いが理解できれば、101willがいかに効率的なバッチ処理を実現するか理解できるはずだ。
| 「処理が速すぎる！ エラーで落ちたのでは？」 | ||
|
||
101willの最初のユーザーであるジャパンエナジーの開発現場でのこと。COBOLプログラムでの集計処理に13分ほどかかる約3000件のテストデータを、101willで開発したアプリケーションで処理してみた。その結果は、ほんの数十秒で終了。あまりの速さに、当時のジャパンエナジーの担当者は「えっ、エラーで落ちたのではないか？」と漏らし、実際に出来上がった結果データを見るまで、処理の速さを信じなかったという。評価プロジェクトで101willによる開発生産性の向上、性能の向上を実感した同社は、基幹システムのダウンサイジングプロジェクトに101willを採用。同プロジェクトは、当初の予定より大幅に短い2年4カ月という短期間で完了した。
また、101willは大規模システム以外でも効果を発揮する。比較的小規模なシステムでの事例を紹介しよう。ゲームエンターテイメントやレジャー施設の企画開発・運営を行うオアシスグループでは、パチンコ店の経営で重要となる「パチンコ釘調整支援システム」を101willで開発した。パチンコ店経営では、各パチンコ台の出玉結果を基に釘を適切に調整する必要がある。出玉情報を得る「ホールコンピュータ」と呼ばれるシステムがあり、従来はそこで収集された出玉データを数百枚の紙に印刷し、店舗責任者がそれを目視で確認して釘の調整の指示を行っていた。
釘の調整作業は、閉店後すぐに始まる。そのため、紙による確認作業は極めて短時間のうちに行わなければならない。これは担当者にとっては大きな負担であり、人的ミスも少なくなかったという。こうした状況を改善するためにシステム化を検討したものの、高速な集計処理システムの開発をシステムインテグレータに打診したところ、数千万円の費用と半年から1年の期間がかかるといわれ、半ばあきらめていたという。
しかし、101willを採用することにより高速なバッチアプリケーションを極めて短期間のうちに安価に開発できたという。当初は閉店後にデータ集計処理を実行する予定だったが、出来上がったバッチアプリケーションが予想以上に高速であったため、営業時間中に1時間おきに集計を行うように変更した。その結果、店舗運営状況がほぼリアルタイムで確認できるようになった。これにより、営業時間中に自動的に出玉データの異常値を検出し、その場で不正行為を発見する手掛かりを得られるようになったという。また、1時間ごとの集計では差分データのみが処理対象となるため、処理データ量が減り、さらなる高速化も図られた。
| UIは使い慣れたMicrosoft Excelで | ||
|
||
101willの特徴は、Oracleデータベースをデータ加工エンジンとして活用することだけではない。あえて専用のユーザーインターフェイスを設けずに、Microsoft Excelを活用することで誰にでも簡単に扱えるツールに仕上がっている。
101willを用いたバッチアプリケーション開発は、あらかじめ用意されている3種類のExcelシートに必要な情報を記入することで行う。まず初めに、データベースに接続するための情報や開発プロジェクト名、ログの出力設定などの情報を「共通情報シート」に記入する。次に、バッチアプリケーションの入出力データの構造を「構造定義シート」に設定する（画面1）。ここには、メインフレームなどから抽出したデータの何バイト目から何バイト目までが、Oracleデータベース上のどのデータに当たるのかを表形式で順次記述していく。
 |
| 画面1 構造定義シート（クリック >> 拡大） |
続いて、データに対して実行する処理の内容を「データフローシート」で定義する。Excelのシート上に、データのロード、表の作成、構造の変更、定型サマリーやデータマージなどの処理種別を記入していくだけの、極めてシンプルな操作だ（画面2）。この際、最初の段階ですべての処理を完全に定義する必要はない。途中まで作成し、後から少しずつ処理を追加していくことも可能だ。
 |
| 画面2 データフローシート（クリック >> 拡大） |
次に、「データ抽出シート」（画面3）「データマージシート」「定型サマリーシート」などで詳細な処理内容の定義を行う。ここでは、データを抽出する条件の設定などを行うので、SQLの知識が必要になる。とはいえ、Excelシート上に用意されている「列設定」ボタンを押すだけで自動的に該当テーブルの列名を構造定義シートから取得する機能などもあり、それほど作業に迷うことはない。
 |
| 画面3 データ抽出シート（クリック >> 拡大） |
ここまで設定できれば、後はデータフローシートに戻って「スクリプトの作成」ボタンをクリックするだけで、バッチ処理に必要なすべてのスクリプトプログラムが自動的に生成される。プログラムのコーディング作業は一切不要で、慣れ親しんだMicrosoft Excelの操作だけでバッチアプリケーションが完成する。もちろん、Excelシート上でデータ加工処理の内容を定義する際にSQLの知識はある程度必要だが、それさえクリアできれば極めて簡単に開発作業を行うことができる。101willのユーザーであるジャパンエナジーの開発メンバーも、トレーニングを兼ねたプロトタイプ開発を2日間経験しただけで、その後は独力で開発作業を進められるようになったという。
さらに、開発作業で作成した各種Excelシートがそのままアプリケーションの仕様書、あるいは設計書になるというメリットもある。通常、処理フロー定義書や入出力データ定義書といったドキュメント類は設計工程で作成される。それらを基に実際のプログラムが開発されるわけだが、往々にして当初の設計と実際に出来上がるプログラムとの間には差が生じることが多い。従って、プログラム完成後にこの差を埋めるために、あらためてドキュメントを修正する必要が生じる。
その点、101willを使った開発スタイルではアプリケーション設計のドキュメントをExcelで作成したら、後は自動的にプログラムが生成される。ドキュメントとプログラムロジックが完全に同期するため、ドキュメントのメンテナンス作業の工数を削減できるだけでなく、記述ミスや修正ミスによるドキュメントのバグを防ぐこともできるのだ。
| 101willによるCOBOL技術者の復権 | ||
|
||
101willを新たに導入したことにより、それまでとは打って変わって生き生きと仕事に取り組むようになった技術者がいるという。それは、ベテランのCOBOL技術者だとのこと。彼らは自社の業務やシステムアーキテクチャに関するノウハウは多く持っているものの、最新のプログラミング言語を駆使してプログラミングを行うとなると、若い技術者に遅れを取ることもあるという。しかし101willを利用すれば、アプリケーション開発に必要な作業はExcelでデータ構造やデータ処理の定義を行うのみである。最新のプログラミング言語に精通している必要はない。となれば、ベテラン技術者が長年かけて蓄積してきたノウハウが生きてくる。
「101willを導入したことで、いままでプログラム開発から距離を置いていたベテランCOBOL技術者の方々が、自らバッチアプリケーションをどんどん作るようになったという話を聞いています」(兒玉氏）
過去に蓄積してきたノウハウを、101willを使って再び開花させる。メインフレームなどのIT資産だけでなく、人材の有効活用という意味でも101willの導入効果は大きいといえそうだ。
プログラミング作業なしでバッチアプリケーション開発を行うことができる101willは、より開発作業が簡単になるというだけではなく、より広範なユーザーが自分の手で直接開発を行うことを可能にするツールだ。ベテランCOBOL技術者、プログラミング知識に乏しい業務担当者やエンドユーザー、こういった人々が直接開発に参加できるため、より効率的にシステム開発を進めることができるようになるだろう。
日々のバッチ処理の高速化・効率化に取り組んでいる技術者はもちろんのこと、こうした人材の有効活用がもたらす開発効率アップに関心のあるユーザーにとっても、101willは魅力的なツールであるといえよう。
|
ホワイトペーパー
提供：株式会社ワン・オー・ワン
企画：アイティメディア 営業本部
制作：＠IT編集部
掲載内容有効期限：2008年6月11日
 関連リンク |
||||||||||
|
ITmediaはアイティメディア株式会社の登録商標です。
