お客様事例 ライオン株式会社様

メインフレーム上の基幹アプリケーションを、オープン環境に全面移行

ライオンが、メインフレーム上の基幹アプリケーションを
オープン環境に全面移行

HPEのモダナイゼーションサービスを利用して、メインフレーム上の膨大な基幹業務資産をオープン環境へ全面移行

業界

製造業


目的

複雑化、老朽化したメインフレームベースの基幹業務システムを一新し、現場部門の変化対応力とシステム管理効率の向上を実現する


アプローチ

メインフレーム上の基幹業務資産に対し、アプリケーションモダナイゼーションを実施することにより、最小限のコスト、期間、リスクで、大規模な基幹業務システムすべてのオープン化を実現した


導入効果

  • システム維持管理コストの削減
  • サービスレベルの向上
  • システム管理レベルの向上
  • 変化対応力の向上

ビジネスの効果

  • 現場部門の業務ニーズに応じたデータ提供、分析環境を整備
  • ビジネス環境の変化に柔軟に対応できるシステム環境を提供
  • 災害時でも事業継続が可能にできるシステム基盤を実現

ソリューション概略

HPEサービス

  • HPEアプリケーションモダナイゼーションサービス
 

「私たちは30年使ってきたメインフレームを捨て、基幹業務システム全体をオープン環境に移行することを決断したのです」

– ライオン株式会社 統合システム部 宇都宮真利部長

30年使い続けてきたメインフレーム環境


ライオン株式会社は、我が国を代表する家庭用品メーカーである。洗剤、石鹸、歯みがきなどの日用消費財をメインとするライオン製品は、長年人々の健康で快適な生活を支えてきた。創業120周年を迎えた2011年には、新経営ビジョン「Vision2020」を発表し、「くらしとこころの価値創造企業」という新たな企業像をめざしている。


このライオンが、今までのメインフレームによる基幹業務システムを全面的にオープン環境に移行したという。その狙いは何か。今回のプロジェクトを指揮した統合システム部長 宇都宮真利氏にお話を伺った。


「新たな経営ビジョンに向かって全社が業務を革新していく中で、情報システムには大きな役割が期待されています。その期待に応えるためには、従来の基幹業務システムを一度、整理する必要があったのです」


ライオンの基幹業務システムの歴史は長い。現行システムのベースは、1980年にライオン歯磨とライオン油脂が合併したときに構築されたもの。その基本設計のまま30年間運用する中で、様々な問題が顕在化してきたという。


「ひとつは複雑化の問題です。長年の間にシステム全体が非常に複雑になっていたのです」


メインフレームでできる業務は決まっている。ユーザーインタフェースも改良できない。会計、生産管理、人事などの分野では、このメインフレームの使いにくさを補完する独自のシステムが次々構築されていったという。1990年代はオフコン、2000年代はUNIX®サー バーが数多く導入され、ERPパッケージなどによる個別業務システムが乱立していった。いつの間にか基幹業務システムは、メインフレームを中心に新旧の技術がつながった複雑な構造になっていった。これが、管理コストの増大とサービスレベルの低下を招いていたのである。


「もうひとつは老朽化の問題です。30年前のシステムでは、現在の経営に必要な情報が得られなくなっていました」


データの粒度が荒く、販売管理などの業務データは基本的に月次ベースだったという。データの保持期間も短く、過去の業績との比較も難しかった。スピーディーな変化対応が求められる中で、これらの制約は大きな問題だった。


「部門業務の高度化や変化対応力の強化を支援しながら、システムの効率化も推し進めたい。そう考える中で、私たちは30年使ってきたメインフレームを捨て、基幹業務システム全体をオープン環境に移行することを決断したのです」


2008年、宇都宮部長をはじめとする統合システム部は、次期システム構想の検討に着手した。


現行のシステムをそのままオープン環境へ


主要なサブシステムについては、当初、ERPパッケージの導入やスクラッチ開発も考慮したという。しかし、結局断念せざるを得なかった。


「開発費がかかり過ぎて、費用対効果が得られないことがわかったのです。最終的に、現行の資産をそのままオープン環境に持っていくマイグレーションを中心に考えることにしました」(宇都宮部長)


2009年、メインフレーム上で稼働していた85のサブシステムのうち8割に関してはマイグレーション、残り2割を再構築するという方針が決まった。再構築対象には、複雑化や老朽化が特に顕著なサブシステムが選ばれた。マイグレーション対象のプログラムの大半はCOBOLである。ただ、一部にアセンブラやPL/1のものもあり、これらについては、その言語に精通した人材の確保が難しいためCOBOLで書き直すことにしたという。


方針決定後に、メインフレーム上の既存資産のアセスメントを実施。外部パートナーに実際の作業を委託する上で前提となるRFP(提案依頼書)を用意するために、保有しているアプリケーションやデータの状況をきちんと把握しておく必要があったのである。この作業は、Hewlett Packard Enterprise(HPE)が担当した。30年の間に膨れ上がった資産を約3ヶ月間かけて詳細に調べ上げ、不要な資産を整理していったことで、移行資産を約半分に減らせたという。


このアセスメントに基づいてRFPが作成され、マイグレーション作業を請け負うパートナーの選定が始まった。このとき提示されたライオン側の要望を統合システム部の主任部員 雨宮一男氏にお聞きした。


「低コストで移行するということと既存資産はできるだけ変えないということです」


ユーザーインタフェースを変えると、現場部門に対する教育が必要になる。プログラミング言語をJavaなどに変えてしまうと、COBOLに特化したエンジニアは扱えなくなってしまう。今後の安定した運用保守のためにも、プログラム資産には手を付けずにそのまま移行することが重要だったのである。



パートナー選定には数社が参加したが、その中にHPEも含まれていた。雨宮主任部員はライオンの意向に一番合致していたのが、HPEの提案だったと言う。


「短期間で低コスト、画面もツールもメインフレームと同じ環境が利用できるというものだったのです」


他社の提案の場合、バッチ系、オンライン系のどちらかに不安要素があるものが多かったが、HPEの場合はそのどちらにも実績のある手法を提示していて安心感も違ったという。


2009年の暮れ、移行プロジェクトのパートナーが決定した。選ばれたのは、もちろんHPEである。


1 2