「COBOLerをアーキテクトに」、ホスト移行した日酒販の狙い：メインフレームからオープン系サーバに

[垣内郁栄，＠IT]

　アルコール飲料や清涼飲料水の卸を行っている日本酒類販売（日酒販）がメインフレームからUNIXサーバへのマイグレーションを行った。業界構造の変化に柔軟に対応できるITシステムの実現や、特定ベンダへの依存度を下げてコストを削減するのが目的だが、日酒販の情報物流本部 情報統括部 次長の大西完治氏は「OJTによって部員にオープン技術を習得させ、最終的にはCOBOLerをシステムアーキテクト、アナリストにすることが狙いの1つだ」と話した。

　大西氏は日本ヒューレット・パッカードが1月15日に都内で開催したイベント「HP IT Modernization Forum 2009」で講演した。日酒販は売り上げ4500億円以上、社員900人以上の大企業だが、一般酒販売店の減少や、若者の酒離れなどで業界構造が大きく変化している。日酒販のITシステムもこのような状況変化に対応する必要があり、2005年10月に同社の次期システム基盤を検討するプロジェクトを社長直轄で始めた。

日本酒類販売の情報物流本部 情報統括部 次長の大西完治氏

　その検討プロジェクトで導き出されたのは開発体制の強化が必要ということだった。柔軟な開発体制や特定ベンダへの依存度の低下、内製化比率の向上などが必要との結論となり、その手段の1つがシステムのオープン化だった。同社内では当時、基幹システムが動くメインフレームと、財務会計システム、開発システムが稼働するメインフレームの2つがあった。両メインフレームとも富士通製。「安定稼働だが、耐障害性・拡張性に難がある」（大西氏）。ほかに情報系サーバとして20〜30台があったがこれらはオープン系サーバを使っていた。メインフレームのマイグレーションは「完全オープン化の仕上げ」（大西氏）だった。

移行前の日酒販のメインフレーム構成

　基幹システムは機能を長年追加してできあがったシステムで「機能の充足度は95％」（大西氏）。ビジネスプロセスを変更するBPRを行うと現場のユーザーへの影響が大きいとして、アプリケーションは引き継ぎ、システムだけをオープン系サーバに乗り換えるリホストを行うことにした。そのため、アプリケーションはCOBOLプログラムをオープンCOBOLに変換することにした。財務会計システムはプロセス変更を覚悟して、パッケージを選択した。情報統括部員にOJTでオープン技術を学ばせると同時に、システムアーキテクトなどより上流の知識を習得させ、サービス提供のスピードアップとコスト低減を狙った。

多くの制約を克服

　「卸売業の基幹システムマイグレーションは制約が多かった」と大西氏は振り返る。制約の1つは複数の業務が密接に連携しているため段階的な移行が難しいこと、2つ目は顧客となる小売店が24時間365日稼働しているケースが多く、システム切り替えのタイミングが少ないこと、3つ目は取引社数が800社以上と多く、テストを行いにくいことだった。日酒販はこれらの制約を何とかクリアしてマイグレーションを実施。システムの切り替えは土曜日の夜から日曜日の朝にかけて行うことで乗り切った。

　マイグレーションはCOBOLプログラムの変換を社外のベンダに依頼し、社内は照合テストやシステムテスト、運用テストなどを担当。大西氏はプロジェクトマネージャを務め、総員30人で開発を行った（社内：20人、社外：10人）。既存のメインフレームを担当している部員を徐々に開発プロジェクトにシフトさせてオープン技術を学ばせていった。

　移行で最も苦労したのは既存のCOBOLプログラムの総数が分からなかったことだ。開発計画時は5366本と見積もっていたが、実際は6573本のプログラムがあった。オンライン画面なども同様で「調査のたびに新しい資産が出現する」という状況。開発されたシステムが適切に資産として登録されておらず、管理が不十分だった。同時に移行作業中も取引先の増加などによってCOBOLプログラムは増加し、移行を難しくした。

オープン系システムに移行後のシステム構成

増えるCOBOLプログラムで開発遅延

　結果的にUNIXサーバに載せ替えた基幹システムの稼働は当初の計画から3カ月遅れた。COBOLプログラムの増加と、その増えたプログラムをテストするための工数が増加したのが要因だ。オープンCOBOLに変換したプログラムの入出力が正しく行われているかをチェックする照合テストは当初、1人が1日1本を確認するというペースで進めていたが、さすがに間に合わないと判断し、複数のプログラムをジョブグループとしてまとめて、一括してチェックするようにした。通信テストについても取引先800社とのテストを完全に実施し、動作を確かめた。情報統括部員、支援するベンダの担当者とも「徹夜、徹夜、徹夜の毎日だった」という。

　旧システムから新システムへの移行は「非常に勇気の要る作業だった」と大西氏は振り返る。旧システムと新システムを並行稼働させながら、データを新システムに移行。照合テストでミスが見つかったらすぐに旧システムに戻せるようにした。リハーサルは移行日までに3回実施。最終的に2008年4月20日午前4時に大西氏が移行できることを確認して「Goを出した」。

　新システムには「NAIS」（Nishuhan Advanced Information System）の名称を付けた。マイグレーションについての大西氏の自己評価は85点。稼働後システムがダウンしていないこと、取引先からクレームがないことは100点、オープン系システムに移行したことで30％のコスト削減ができたことが85点だが、稼働が遅れたことや一部の帳票にズレが出たこと、オープン系システムにしたことで夜間バッチに遅れが出たことなどから、85点とした。大西氏は今後「社内向けから社外向けの開発体制を志向する」としていて、NAISの社外販売も検討するという。