ライオンが、およそ30年使い続けてきたメインフレーム上の基幹アプリケーションをオープン環境に全面移行した。大規模なホストマイグレーションを支援したのはDXCテクノロジーである。ライオンは、このオープン化への取り組みを起点に、基幹システムのインフラ統合およびデータセンター統合を進め、災害対策の強化にも取り組んでいる。
「新たな経営ビジョンに向かって全社が業務を革新していく中で、情報システムには大きな役割が期待されていました。その期待に応えるためには、従来の基幹業務システムを見直す必要があったのです」
宇都宮 真利 氏 ライオン株式会社 統合システム部 渉外専任部長
30年使い続けてきたメインフレーム環境
ライオン株式会社は、我が国を代表する日用品メーカーである。洗剤、ハミガキなどをメインとするライオン製品は、長年にわたり人々の健康で快適な生活を支えてきた。2030年に向けた新経営ビジョン『次世代ヘルスケアのリーディングカンパニーへ』を掲げ、中期経営計画「ＬＩＶＥ計画（LION ValueEvolution Plan）」に基づく成長戦略を加速させている。
2012年、ライオンはメインフレームによる基幹業務システムを全面的にオープン環境に移行した。その狙いを、プロジェクトを指揮した統合システム部の宇都宮真利氏は次のように話す。
「新たな経営ビジョンに向かって全社が業務を革新していく中で、情報システムには大きな役割が期待されていました。その期待に応えるためには、従来の基幹業務システムを見直す必要があったのです」
ライオンの基幹業務システムの歴史は長い。現行システムのベースは、1980年にライオン歯磨とライオン油脂が合併したときに構築されたもの。その基本設計のまま30年間運用する中で、様々な問題が顕在化してきたという。
「ひとつは複雑化の問題です。長年の間にシステム全体が非常に複雑になっていたのです」
メインフレームでできる業務は固定的で、ユーザーインタフェースも改良できなかった。会計、生産管理、人事などの分野では、メインフレームの使いにくさを補完する独自のシステムが次々構築されていったという。1990年代はオフコン、2000年代はUNIXサーバーが数多く導入され、ERPパッケージなどによる個別の業務システムが乱立していった。いつの間にか基幹業務システムは、メインフレームを中心に新旧の技術がつながった複雑な構造になっていた。これが、管理コストの増大とサービスレベルの低下を招いていたのである。
「もうひとつは老朽化の問題です。30年前のシステムでは、現在の経営に必要な情報を得るのに手間と時間を要していました」
販売実績のデータをもっと詳細かつタイムリーに参照したい、過去の実績と自由に比較したい、といった現場のニーズも高まっていた。
「部門業務の高度化や変化対応力の強化を支援しながら、システムの効率化も推し進めたい。そう 考える中で、私たちは30年使ってきたメインフレームを捨て、基幹業務システム全体をオープン環境に移行することを決断したのです」
現行のシステムをそのままオープン環境へ
主要なサブシステムについては、当初、ERPパッケージの導入やスクラッチ開発も考慮したという。しかし、結局断念せざるを得なかった。
「開発費がかかり過ぎて、投資対効果が得られないことがわかったのです。最終的に、現行の資産をそのままオープン環境に持っていくマイグレーションを中心に考えることにしました」（宇都宮氏）
メインフレーム上で稼働していたサブシステムのうち8割に関してはマイグレーション、残り2割を再構築するという方針が決まった。再構築対象には、複雑化や老朽化が特に顕著なサブシステムが選ばれた。マイグレーション対象のプログラムの大半はCOBOLである。一部にアセンブラやPL/1が使われており、これらはCOBOLで書き直す方法を採ることにした。
方針決定後に、メインフレーム上の既存資産のアセスメントを実施。RFP（提案依頼書）作成のために、保有しているアプリケーションやデータの状況をきちんと把握しておく必要があったのである。プロジェクトは、30年の間に膨れ上がった資産を詳細に調べ上げた。不要な資産を整理することで、移行作業量をおよそ半分にまで減らすことができたという。
このアセスメントに基づいてRFPが作成され、マイグレーション作業を請け負うパートナーの選定が始まった。このとき提示されたライオン側の基本方針を、統合システム部の雨宮一男氏は次のように話す。
「低コストで移行することと、既存資産はできるだけ変えないことです」
ユーザーインタフェースを変えると、現場部門に対する教育が必要になる。プログラミング言語を Javaなどに変えてしまうと、COBOLに特化したエンジニアは扱えなくなってしまう。今後の安定し た運用保守のためにも、プログラム資産には手を付けずにそのまま移行することが重要だったのである。
「短期間で低コスト、画面もツールもメインフレームと同じ環境が利用でき、バッチ系とオンライン系いずれも実績のある手法を選びました」
「私たちは30年使ってきたメインフレームを捨て、基幹業務システム全体をオープン環境に移行することを決断したのです。マイグレーションのパートナーには、DXCテクノロジー様を選びました」
宇都宮 真利 氏 ライオン株式会社 統合システム部 渉外専任部長
大規模な資産移行と徹底的な並行稼動テスト
移行計画に基づき、x86サーバー上の仮想環境で稼働するLinuxベースのオープンホスト環境が構築され、膨大なメインフレーム資産が次々と移行された。マイグレーションにあたっては、DXCテクノロジーが紹介した海外製のリホストツールが使用されたが、実際の移行作業ではツールだけではなく、DXCテクノロジーの技術者の対応力が大きく貢献したという。
「機能面での不足や不具合もあったのですが、DXCテクノロジー様はツールメーカーと緊密に連携して、機能追加や修正対応にスピーディにあたってくれたのです」（雨宮氏）
最も困難だったのが、現場部門のユーザーが開発したプログラム資産の移行だった。1990年代に第4世代言語（4GL）によって書かれたユーザープログラムが基幹システムと同じメインフレームで稼働していた。ユーザープログラムのうち、重要な処理は統合システム部がマイグレーションを担当した。
移行作業の最終段階はテストである。メインフレームと同じ業務データをオープンホストにも入力し、その結果を照合していく並行稼働テストだ。
「資産規模が大きいので、データやアプリケーションの動作を一つ一つ追うわけにはいきません。システム全体としてメインフレームと同じ動きをするかどうかをチェックすることにしました」（雨宮氏）
テスト環境の構築に半年ほどかかり、さらに半年以上、並行稼動テストとして日次、月次の並行処理と結果照合が続けられた。その間、メインフレーム上の既存のプログラムには様々な変更が入ったが、DXCテクノロジーはきめ細かく対応して、オープンホスト側のアプリケーションを更新し続けたという。
2012年、長期にわたるテストを経てすべての問題点が解消され、オープン環境上の基幹業務システムは完成し、全面移行したのである。
ベネフィット
維持運用コストを大幅削減
オープン環境への切り替えは2012年に無事に終了し、メインフレームは直後に撤去された。雨宮氏はプロジェクトを振り返って、「基幹業務システムに関わる全体の維持費が大幅に削減できました」と評価する。
「本プロジェクトを通じて、推進体制とテストの重要性を改めて認識しました。移行作業においては、特定のプログラムの問題点が他に影響を与えることが多くあります。プロジェクトチームは、膨大なプログラムの影響調査から、テスト、問題解決までを確実にやり遂げてくれました」と宇都宮氏は話す。
テストフェーズではDXCテクノロジーの技術者が、統合システム部のメンバーと同じ目線で対応した。DXCテクノロジーの中国デリバリーセンターのスタッフを動員したことが、膨大な作業量に短時間で対処できた大きな要因だ。
「2015年には、首都圏の2拠点で運用してきた基幹システムを関西圏のデータセンターに移設・統合しました」（雨宮氏）
基幹システムのインフラ統合に際しては、オールフラッシュストレージを採用して高負荷の集計処理を高速化。週次のバッチ処理時間を1/2以下にするなど大きな成果をあげたという。
「今後は、BCP計画の一環として災害対策をいっそう強化する計画です。データセンターの統合もDRサイト構築も、基幹システムのオープン化が完了していたからこそ可能になりました」（宇都宮氏）
ライオンは、2018～2020年の中期経営計画「ＬＩＶＥ計画」において、事業成長を牽引する生産インフラへの投資、先進的なサプライチェーンの構築、グループ経営高度化のための情報システム基盤強化等を掲げている。宇都宮氏は次のように語って締めくくった。
「業務や部門の連携を強化し、サプライチェーン全体を統合化する全社方針がいっそう明確になりました。将来の基幹アプリケーションの抜本的な見直しも、『統合化』がキーワードになることは間違いありません。」