TOP > 導入事例 > 王子エンジニアリング株式会社様(Hybrid SECURITY他)

オカモト株式会社

基幹システムから工場のOracleへリアルタイムにレプリケーション


会社概要

社名 オカモト株式会社
創立 1934年
資本金: 130億4763万円
売上高 754億3500万円
従業員数 892名(2008年3月)
本社 東京都文京区


メインフレームからSystem iへ全面切り替え


情報システム室 主任 松井秀則氏  情報システム室 吉田哲雄氏

 避妊具の製造・販売で海外にも広く知られるオカモトは、今は事業を大きく多角化させ、プラスチックフィルムや建装・産業資材などの産業用製品と医療品・日用品・シューズ・衣料などの生活用品を生産する総合メーカーへ変身している。その同社が、2006年5月から2008年5月まで取り組んだ他社メインフレームからSystem iへの移行に伴うデータ連携システムの構築が、本稿のテーマである。
 同社では従来、他社のメインフレームとミッドレンジ機を使用してシステムを構築・運用してきた。当初はミッドレンジ機を、静岡・茨城・福島の各工場に配置し、運用も各工場のシステム要員による分散体制で行ってきたが、ネットワーク回線が広帯域化し低料金になってきたことから各ミッドレンジ機を本社サーバールームに移設し、集中管理してきた。
 これで運用管理の負荷は、以前と比べてかなり軽減されたものの、「メインフレームの運用コストがふくらみ、これへの対処が必要になったことと、メインフレームベンダーのサポート力、技術力に疑問と不安を感じていたため」(情報システム室の松井秀則主任)、システムの抜本的な変更を検討することになった。これには、同社が利用するプログラム総数約4000本の約半分を占めるCAPEという4GL(第4世代言語)で開発されたプログラム(残り半分はCOBOL)のメンテナンスに問題を抱えており、「これをCOBOLに置き換えるのなら、システムを作り変えるのと同じ」(松井氏)という判断も働いたという。
 そして検討の末、ハードウェア・プラットフォームをSystem iへ全面切り替えすることにした。「安定性と信頼性に定評があり、他社メインフレームからCOBOLプログラムの移行などに実績がある点を評価しました」と松井氏は語る。
 プログラムは、他社システムで稼働していたCOBOLをSystem i用のCOBOLへ、CAPEで開発されたプログラムもSystem i用のCOBOLへコンバージョンすることとし、支援業者にコンバージョンプログラムの開発を依頼し、移行を行った。JCLプログラムなど「すんなりとコンバージョンできない」ものについては改めて開発した。


製造現場への影響をいかに最小限に抑えるか


 ところで、同社ではそれまで、個々の製品の製造現場で使用する生産管理系システムは、各工場の現場担当者が開発する体制としてきた。その理由は、「製品ごとに扱うデータが異なり専門性の高いシステムとなるため、現場のニーズに即したシステムを作るには現場担当者が担当したほうがよい」(松井氏)という考えからだが、その体制は新システムへの切り替え後も継続することとした。
 そこで課題となったのが、新システムへの移行に伴う製造現場への影響をいかに最小限に抑えるか、という点であった。その時の経緯を、情報システム室の吉田哲雄氏は次のように語る。
 「従来、各工場の生産担当者は端末(PC)を利用して本社の工場系基幹データを取り込み、各生産管理システムに展開していました。新システムでも、この環境を極力変更しないように、仕組みを検討することにしました」


システム運用方針に合致した製品


 その結果、採用したのがヴィンキュラムジャパンのリアルタイム・ミラーリングツール「JOURNAL/400」である。吉田氏は、「基幹システム上の工場系データをJOURNAL/400のレプリケーション機能を使って各工場のサーバーに複製し、それを現場担当者が利用すれば従来と同様の環境にすることができます。これにより工場ユーザーへの影響を最小限に抑えることが可能です。また、レプリケーションサーバーを各工場に配置することにより本社−工場間のネットワーク負荷を軽減でき、工場のユーザー端末から本社システムへの直接アクセスをなくすことにより、セキュリティも確保できると考えました」と採用の理由を説明する。
 基幹システムから各工場のサーバーへのレプリケーションは、次のような流れで行われる。

(1)

本社業務により工場系基幹データに変更が発生すると、その変更分のジャーナルデータを基幹システム(System i)上のJOURNAL/400が各工場のレプリケーションサーバー(JOURNAL/400が稼働)へ送信する。

(2)

各工場のレプリケーションサーバーは、ジャーナルデータを受け取ると、その当該のフィールドを変更し、さらにOracle DBのデータを変更するためデータを送信する。

(3)

Oracle DBが稼働するレプリケーションサーバーは、JOURNAL/400よりデータを受け取るとDBの内容を変更し、フィールド名称を変更したビュー(VIEW)を工場ユーザーに提供する。

(4)

工場ユーザーは、ODBC接続でOracle VIEWへアクセスする。


 レプリケーションの対象となっているのは60〜80テーブルほどで、サービスインから約5カ月を経過したが、「まったく問題なく、スムーズに運用できている」と松井氏は評価する。工場側ユーザーも、基幹プラットフォームのリプレースという大きな変更があったにもかかわらず利用環境にほとんど変化がないため、「従来どおりに利用している」という。
 レプリケーションツールの選定にあたっては、JOURNAL/400のほかにも検討した。しかし、その製品は「基幹システムの大きな改修が必要になるのと、日本語対応に難点があり」(松井氏)見送ったという。JOURNAL/400は、基幹システム側に手を入れる必要がない点を評価した。これが結果的に、短期移行とシステム変更に伴うユーザーへの影響を最小限に抑えるところにつながった。
 同社では、システム部門の方針として「運用管理は極力、自動化と外部委託で回すこととし、開発に専念する」(松井氏)ことを掲げている。そして、「エンドユーザーに対して積極的にシステムを提案していく考え方」と松井氏は言う。レプリケーションの自動化を実現するJOURNAL/400は、同社のシステム運用方針に合致した製品でもあった。


オカモトのレプリケーション構成 オカモトのレプリケーション構成 オカモトのレプリケーション構成 オカモトのレプリケーション構成
オカモトのレプリケーション構成 オカモトのレプリケーション構成 オカモトのレプリケーション構成 オカモトのレプリケーション構成
オカモトのレプリケーション構成 オカモトのレプリケーション構成 オカモトのレプリケーション構成 オカモトのレプリケーション構成


本記事は、i Magazine 8号に掲載されたものです
(C)2008 アイマガジン株式会社 www.imagazine.co.jp