図1●星光堂は三つの工夫でマイグレーションを完遂星光堂は,1980年稼働の旧システムの再構築を三つの工夫で乗り越えた
図1●星光堂は三つの工夫でマイグレーションを完遂星光堂は,1980年稼働の旧システムの再構築を三つの工夫で乗り越えた
[画像のクリックで拡大表示]
図2●バッチ開発にはCOBOLを再選択し,OB人脈を有効利用星光堂は当初「脱COBOL・脱メインフレーム」を目指していたが,技術制約上,他言語では不安があった。COBOL関連の技術進歩があったことから,バッチはCOBOLで再構築することに決めた
図2●バッチ開発にはCOBOLを再選択し,OB人脈を有効利用星光堂は当初「脱COBOL・脱メインフレーム」を目指していたが,技術制約上,他言語では不安があった。COBOL関連の技術進歩があったことから,バッチはCOBOLで再構築することに決めた
[画像のクリックで拡大表示]
図3●共通処理の情報をWikiで共有三つの画面開発チームは,MVC(Model-View-Controller)パターンで画面開発を実施。モデル部分で共通利用できる部品を増やすため,設計情報をWikiで共有した
図3●共通処理の情報をWikiで共有三つの画面開発チームは,MVC(Model-View-Controller)パターンで画面開発を実施。モデル部分で共通利用できる部品を増やすため,設計情報をWikiで共有した
[画像のクリックで拡大表示]

 音楽ソフト卸大手の星光堂は2005年8月,1980年稼働のホスト・システムの再構築をほぼ完了した。約4000店舗の販売取引先のPOSシステムなどと連動して,受注・在庫引当・発注・在庫管理を受け持つ基幹システムだ。「音楽ソフトはレコードからCD・DVDへと変わり,販売チャネルはレコード店からレンタル・ビデオ店やスーパーマーケットなどにも広がった。何度か大幅に修正を加えてきたが,ここにきて抜本的に見直すことにした」(取締役 執行役員 落合洋一氏)。

 基幹システムの再構築に当たり,星光堂,ならびに旧システムから開発・保守を請け負うプラネットは三つの工夫を凝らして乗り切った(図1[拡大表示])。

バッチ処理はやはりCOBOL

 今回,システム稼働時間の延長や各種マスターの刷新,DBのオープン化などが必要なため,ロジックは一から作り直した。2003年の企画当初,星光堂とプラネットは「脱COBOL・脱メインフレーム」を目指していた。「COBOL技術者の減少と,技術者がモチベーションを維持できないのではないかと心配していた」(プラネット 開発本部 本部長 取締役 田林滋氏)ためだ。だが技術的な進歩を吟味した結果,オンライン部分はJavaで開発するものの,バッチ部分はCOBOLで再開発することに考えを改めた(図2[拡大表示])。

 再びCOBOLを選んだ経緯はこうだ。まず企画を進める中で,“ビッグバン”でオープン化するという当初の構想は,開発規模や印刷業務の必要性から見直しがかかった。結果,段階的にオープン化していくこと,伝票出力用に富士通製メインフレームを継続利用することに路線変更した。同時に進めていた開発言語の検討では,「JavaはCOBOLと比べてバッチ性能が3分の1程度という富士通からの説明からも不安が残り,Cでは保守容易性に問題があった」(プラネット 田林氏)。

 この二つの問題をどう解くかを考えていたときに,星光堂のメインフレームのメーカーである富士通から二つのソフトを紹介された。CORBA通信でメインフレーム上のCOBOLプログラムからUNIXサーバー上のCOBOLプログラムを介してDB(Oracle Database 10g)にアクセスできる「INTERSTAGE for GS」と,UNIX上のCOBOL開発実行環境「NetCOBOL」である。星光堂のニーズを満たせるCOBOL系新技術の提案と,約186万ステップのCOBOL資産の3割程度が新システムでも参考にできること,プラネットの技術者は主にCOBOL開発者であることなどを検討した結果,星光堂は既存技術者のスキルを生かせるCOBOLでバッチ処理を開発することに改めた。

不良資産をOBが解きほぐす

 旧システムが本稼働したのは,構造化設計が一般的に広まる以前だった。そのため,「星光堂,プラネット,取引先のどこにも,旧システムの全体像を分かる人がいない。ドキュメントもメンテナンスされておらず信用できない。プログラムもデータの流れも“スパゲティ”ばかり」(星光堂 システム室 室長 松本淳氏)という状況だった。

 旧システムには十数件の取引先ごとに個別対応するロジックも点在していた。こうした個別処理がどこに存在していて,どのような仕様なのかをまず明らかにしなければならなかった。

 そこでプラネットの田林氏は,旧システムを長く保守していたOBにプログラムの分析を依頼した。そのOBが3カ月をかけて調査した結果を持って,星光堂の松本氏は取引先と個別処理の今後の仕様を詰めた。その後の設計は,「Xupper」を使ったデータ中心アプローチと構造化手法で進めた。「ドキュメントやプログラムが整理され,業務面の理解も進んだ。結果的にCOBOLを選択してよかった」(田林氏)。

紙ではなくWikiで情報共有

 2004年春からは開発がスタート。バッチ処理をCOBOLで再構築する一方,オンライン処理はJavaで再構築を進めた。Java開発ツールには,コンポーネントEベースでノンプログラミングを指向する「Webtribe」を選択した。

 オンライン処理の開発チームは,ユーザーの利用現場に合わせて,「販売店向け受発注画面」「コールセンター向け受発注画面」「マスターEメンテナンス画面」の3チームに分けた。アプリケーションはMVC(Model-View-Controller)パターンで開発。「モデル」はDBアクセスや業務ロジックの処理を担う部分であり,「3チームで共通して利用できる部品を増やしたかった」(プラネット 開発本部 ソリューション1部 主任技師 桐野覚氏)ため,設計情報をWikiで共有した(図3[拡大表示])。

 部品は粒度を大きくせずに,例えば「文字変換」などのように極力小さく作ることにした。また,機能名・入出力・利用目的など登録フォーマットを統一することで,誰が見ても分かりやすく,検索しやすくした。「Wikiは編集も容易なので,仕様書よりもメンテナンスしやすかった」(同氏)。