バッチ処理プログラムのオープン移行で生じた
パフォーマンスと開発生産性問題
導入前に比べ、処理性能は6倍以上、開発生産性は5倍以上に

1.　メインフレームを超える高速なデータ処理速度
2.　エンジニアを夢中にさせる高い開発生産性
3.　複雑なデータ加工処理もこのツール1つで実現

数年にわたるメインフレームのダウンサイジング・プロジェクトの総仕上げとして着手されたバッチ処理プログラムのオープン環境移行。JavaやPL/SQLを使ってスクラッチから再構築を開始しましたが、社内エンジニア2名で300本あまりあるプログラムを書き換えていくのは至難の業で、その上データ処理件数が増えると、処理性能が大きく低下したり、データベースのOracleに大きな負荷がかかってしまう事態が発生しました。情報システム課は、“このままでは、2010年度中に主要なバッチ処理プログラムの移行を完了するという年初の計画を達成できない”という大きな危機感を抱きました。

アシストとの相談の結果、ETLツールを試してみた中で最も有望な候補となったのが、データ統合アクセラレータSyncsort DMExpress（以下、DMExpress）でした。実際、2ヶ月かけて試用して性能検証を行ったところ、作成したプログラムは、このプロジェクト最大の要件だった、“メインフレームクラスの処理速度”を十分満たしていました。また同社は、コスト管理と技術スキルの蓄積という観点から、社内エンジニアによる自社開発を望んでいましたが、試用によりDMExpressの開発生産性の高さが実感できました。高い処理性能、高い開発生産性を評価して、DMExpressを採用することにしました。

開発技術研修1日コースを受講した社内エンジニア8名全員が意欲的な開発担当者となり、次々と担当のバッチ処理プログラムをDMExpressで再構築していきました。非常に複雑なデータ加工もこのツールだけで開発できることもあって、それまで開発に8時間かかったプログラムがDMExpressで30分で完成するなど、導入前に比べて非常に高い開発生産性を発揮しました。また処理性能も、40分かかっていたものが20秒に、12分かかっていたものが45秒になるなど、驚異的なスピード改善を果たしました。その結果、計画どおり今年中に主要なバッチ処理プログラムがオープン移行できる目処が立ちました。

小島プレス工業株式会社は、自動車の内外装部品を生産するメーカーです。トヨタ自動車の主要協力企業として知られ、創業から70年にわたって、プレス部品、プラスチック部品を開発・生産。品目数は10,000点以上におよび、しかもその精度・品質・安全性において、世界トップレベルを誇っています。近年は、電気・通信分野の部品製造についても積極的に挑戦しています。

経営理念は、ずばり「和」。“人をつくり 人をまもる”ことを旨とし、“人”中心の経営を推進しています。昼食を福利厚生として無償で提供するなど、労働環境の充実ぶりは有名です。また、リサイクルに力を入れており、鉄材端板を有効活用したり、オフィス古紙をトイレットペーパーへ自社内で再生するなど、ユニークな活動を長く続けています。あらゆる物を徹底的に使いきる精神に、“ものづくり”企業ならではの資源への敬意が表れています。

2005年、同社ではメインフレームからオープン環境へのダウンサイジングを決定しました。同時に、それまで21のグループ会社それぞれで構築していた基幹シス テムを全面統合、1つのシステムをグループ共有することになりました。同社は、ここでアシストの、Oracleデータベースを事前検証済みハードウェアで提供するDODAIを採用、この上に次々と基幹システムを移行していく壮大なプロジェクトが始まりました。
　
その総仕上げとして2010年から着手されたのが、バッチ処理プログラムの再構築です。主要なものに、仕入れ処理システム、内示処理システム、照合処理システムの3つの系統がありました。仕入れ処理というのは、仕入れ先から納められた資材の検収データを集計して、月々の支払い予定を仕入れ先に提示するというシステム、 内示処理システムは、自動車メーカーから送られる最初の発注情報を集計して生産部門に展開するシステム、照合処理システムは、売り掛けデータと買い掛けデータを突き合わせて、請求・支払いに関して抜け漏れがないかどうかをチェックするシステムです。これら3システムを合計すると、プログラム本数にして300本以上あります。こうしたバッチ処理プログラムは、月次処理のように夜間に定期で行われるものもあれば、ユーザ部門のリクエストにより逐次処理されるものもあります。

当初、情報システム課では、Javaでのバッチ処理プログラムのスクラッチ開発を検討していました。しかし、始めてみると、 高いJavaプログラミング能力が必要で、 担当可能な人員は2名のみでした。しかも、処理するデータ件数が数十万件レベルになると、プログラムは期待したパフォーマンスを発揮しません。

そこで今度は、Oracleの手続き型言語であるPL/SQLを使ってみることにしました。これはJavaに比べるとパフォーマンスが向上しましたが、担当可能な人員はやはり2名でした。その上、PL/SQLベースのプログラムはOracleへのI/Oが頻繁に発生してOracleの負荷が高まるため、オンライン処理プログラムが走る日中は使いづらいということが判明しました。このままでは、2010年度中にバッチ処理プログラムの移行を完了するという年初の計画が達成できません。何か抜本的な解決策が必要でした。

情報システム課にとって、このバッチ処理プログラム移行における最大の要件は、メインフレームクラスの高速処理を維持することでした。オープン環境への移行で処理スピードが落ちたのでは、ユーザ部門の業務処理効率を低下させてしまうからです。
　
一方、開発生産性の高さも外すことはできません。プログラム本数は300本以上あり、それをすべて自社開発する予定だったからです。

そして、コストへの懸念もありました。 ハードウェアを増強すれば、このままの業務体制でも処理スピードを改善することは可能かもしれませんが、それには膨大なコストがかかります。

上記3つの悩みをアシストに相談し、提案として挙がった解決策がETLツールの利用でした。試した中で最も有望に思えたのが、DMExpressでした。実際、情報システム課は試用版を使って、2カ月間にわたり性能を検証。そこで判明したのが、画期的な高速処理性能と開発生産性の高さでした。

例えば、JavaとPL/SQLを使って28時間かけて開発した、ある仕入れ処理プ ログラムは80万件のデータを処理するのに65分を要しました 。それが 、 DMExpressを使うと開発時間は5時間に、処理スピードは10分に短縮されました。つまり、開発生産性は5倍以上、処理性能も6倍以上に向上したのです。

このような結果を見て、情報システム課はバッチ処理プログラムの移行を全面的にDMExpressで進めることを決断しました。小島プレス工業株式会社 総務統括部 情報システム課 課長 橋本春彦氏は、 選定当時を次のように振り返ります。
「DMExpressを使って、高速処理が可能なプログラムを社内のエンジニアで迅速に開発できるなら、それが最善だと考えました。社内で開発できないとなれば外注することになりますが、そうなると自社開発の何倍ものコストを覚悟しなければなりません。

また、プログラムは完成しても社内にノウハウが残りません。修正を加えたいのに自分たちでは行えない、という事態は回避したいと考えていました。付け加えていうなら、当社はものづくり企業だけに“手作り”が好きなのです。それは情報システム部門でも同じで、これまでの内製率は80％。それを維持したい気持ちもありました。そのために、社内の人間が高い生産性で使える“いい道具”を選ぶ必要があったのです」

2ヶ月間の検証で驚くべき性能と開発生産性を発揮したDMExpressでしたが、 情報システム課は、今回はスモールスタート戦略を取りました。ほんとうの実力は本番環境でしかわからないと考えたからです。DMExpressを搭載するサーバ はエントリークラスのPCサーバを、開発者用の開発クライアントは2ライセンス用意。その一方で、エンジニア8名がオンサ イトのDMExpress開発技術研修1日コースを受講しました。
　
そして、2010年のゴールデン・ウイーク明けから本格的に開発に着手。橋本氏は当初、バッチ処理プログラムのすべてをDMExpressで構築し直すのは難しいかもしれないと考えていました。なかには非常に複雑なデータ加工があり、そこは別の方法でプログラムを開発しなければならないかもしれないと覚悟していたのです。しかし、いざふたを開けてみると、それは杞憂だったことがわかりました。

これまでは、開発技術研修を受講した全員がそのまま開発担当者になるということはあまりありませんでした。実際にプログラミングを始めてみると予想以上に難しかったり、どうも操作性になじめないというようなことがあったからです。しかし、DMExpressの場合は違いました。研修を受講した全員がプログラム開発に積極的に取り組み始めたのです。この開発クライアントをインストールしたPCを誰もが利用しようとするため、時には順番待ちが生じるほどでした。そこで情報システム課は、レンタルという方法でライセンスを4つ追加します。それぞれが担当を持ち、前向きな開発を進める中で、驚異的な結果が次々に現れました。

例えば、ある内示処理プログラムでは、VB系開発ツールで開発に12時間かかったものが、DMExpressでは3時間で作り上げることができました。またその処理時間は、前者が40分であったのに対して、DMExpressではたったの20秒でした。別の照合処理プログラムの実例は、メインフレームのCOBOLプログラムの移行です。これは開発に8時間かかりましたが、DMExpressで作り直してみると30分で完成しました。それまで処理に12分かかっていたものが45秒に短縮され、メインフレームでの処理より高速になったのです。

2010年8月24日、主要な内示処理プログラムの1つが本番移行を果たしました。開発開始から3ヵ月半。情報システム課としても、このように早いタイミングで本番移行できるとは思っていなかったそうです。“DMExpressでなければできていなかったと思う”というのが、情報システム課メンバーの方々の一致した意見です。プログラミングに携わった小島プレス工業株式会社 総務統括部 情報システム課 花井亮介氏は、DMExpressを使用した感想を次のように語ります。

「私はプログラミング経験が浅く、Javaなどは先輩に聞きながら少しずつ開発していますが、DMExpressでの開発は自分ですべて考えながらできるから楽しいです。複雑なデータ加工も、“ひょっとしてこうすればできるかな”と思ってやってみるとできるんです。アシストのサポートにはお世話になっています 。普通はDMExpressの機能や問題のみの対応だと思うんですが、処理フローの実装などについても相談にのってくれるのでありがたいです」

小島プレス工業株式会社 総務統括部 情報システム課 池田和弘氏は、DMExpressの魅力を“高速処理”だと語ります。
「開発生産性の高さを誇るツールは他にもありますが、処理スピードという点ではこのツールでしょうね。データベース上のデータをいったんテキストでDMExpressサーバへ持ってきて、そこですべての加工を行うというアーキテクチャであるため、OracleへのI/Oが極力抑えられるのがいいですね」

小島プレス工業では、メインフレームのバッチ処理代替案として、DMExpressを使った方法を確立しましたが、これは更新処理が頻発するOracleのパフォーマンス対策としても有効に機能するものと思われます。DMExpressの利用でプログラムテストも行いやすくなったと語るのは、小島プレス 工業株式会社 総務統括部 情報システム課 楠本嘉正氏です。
「プログラムテストを行う際、以前は、本番環境のOracle環境に手を入れるわけにいかないので、対象のテーブルをコピーしたテストOracle環境を事前に準備する必要がありました。しかし、DMExpressだと、そんな用意は不要で、サーバ上に取りこんだテキストデータをエディタなどで編集してテストデータを自由に作り、何度もプログラムを走らせて処理結果を見ることができます」

橋本氏は、アシストの開発技術研修についてもこうコメントしています。
「単なる機能解説にとどまらず、“こういう処理を実現したい”というこちらの問いに、サンプルを豊富に提示してくれました。非常に実践的でした」

DMExpressの導入により、内示処理システム、仕入れ処理システム、照合処理システムに関しては、年初の計画どおり、2010年度中に本番移行が完了できる目処が経ちました。しかも、照合処理システムは100％DMExpressで再構築することができたのです。DMExpress導入以前は、情報システム課の中に“このままでは達成できないかもしれない”という雰囲気が漂っていたとのことで、まさに形勢大逆転です。

また、これによって、今後仕事の進め方が大きく変化するだろうと、橋本氏は予想しています。「これまでは、バッチ処理はメインフレームといえど負荷がかかるので、ユーザ部門の依頼を受けると、情報システム課が処理の空き時間を見計らいながらオペレーション計画表を作成、専任オペレータがそのスケジュールに沿って進めていました。しかし、現在は処理スピードの単位が“時間” や“分”から“秒”になりました。これだけ速くてシステムに負荷をかけないなら、ユーザ部門が情報システム課を介さずに、自分たちが実行したい時に実行して結果を得ることができます。もう一晩、一週間待たなくてもよくなるということで、これによる業務効率向上は大きいと思います。我々情報システム課も、ユーザ部門の依頼を代行しなくてすむ分、他の業務に時間を振り向けることができるようになります。ワークスタイルが大きく変わりそうですね」

今年の計画を達成した後、次はバッチ処理プログラムとして最後に残る売上管理関連の納入処理システムに着手します。順調にいけば来年度中にバッチ処理専用のメイ ンフレームが撤去できるかもしれません。また、このDMExpressサーバは将来的に小島プレス工業グループ全体で共有する予定になっており、必要に応じてアシストと相談しながら増強を図っていくとのことでした。

※お客様情報は取材時の内容に基づくものです。