ソフトウェアの生産性、品質向上ならケン・システムコンサルティング

事業の急成長に対応すべく基幹システムを刷新

 24時間365日完全生放送のテレビショッピング専門チャンネル「ショップチャンネル」を運営するジュピターショップチャンネル（以下、JSC）。同社では1997年以来、既成パッケージのカスタマイズによって構築した基幹システムを運用してきたが、事業の成長に伴い、さまざまな問題が顕在化してきた。
 たとえば、同システムは日次サイクルでの受注・出荷業務の運営を前提としており、夜間バッチ処理中はリアルタイムな在庫引き当てを伴う受注処理ができなかった。これは、24時間の放送・受注を行うJSCにとって、ビジネス上大きな障害となる。また、業務上の要請に応じて機能拡張を繰り返してきたためシステム構造にゆがみが生じ、トラブル発生の危険性も懸念されていた。
 そこで、JSCでは基幹システムの刷新を決断。保守性を向上すること、24時間365日の在庫引き当てを伴う受注処理を可能にすることなどを目標に、新基幹システムの設計にとりかかった。また、開発・保守の容易性の向上と開発ツールの確立・定着化を図るため、次のような開発方針とした。
 1つは、開発の標準化。具体的には、DOA（データ中心型アプローチ）に基づいた開発を行い、工程化開発法に基づく開発工程の標準化や、データアクセスの標準化を図るというものだ。そしてもう1つが、文書化管理の徹底。旧システムでは設計情報などの文書化が十分に行われていなかったため、新基幹システム構築にあたってはツールを活用して文書管理を行うこととした。
 JSCでは当初、データモデリングツールとしてERwin、上流設計ツールとしてXupperIIの使用を検討していたが、最終的にはモデリングも含めてXupperIIの採用を決定。業務フローや概念ERDを記述できること、さまざまな情報を体系的に整理できるリポジトリを搭載していること、設計情報を加工して引き出せることなどが、XupperII導入の決め手となったという。

新システムサービスイン後、変更管理の課題に取り組む

 新基幹システムは、2005年12月にサービスイン。旧システムの抱えていた問題を解決するために構築された新基幹システムだが、サービスイン直後から大きな課題に直面することとなった。それは、機能改善・新機能追加などの変更要求だ。2005年以降もJSCの事業は大きく成長を続けていた。「ショップチャンネル」の売上や視聴世帯数の増加に加え、Webやモバイルサイトなど販売チャネルも拡大。それらに対応するために、ユーザ部門からの新基幹システムに対する変更要求も頻繁に発生していたのである。
 ユーザからの変更依頼に対して、現場ではアプリケーション開発担当チームやデータベース担当チームなどがそれぞれ個別に対応していた。変更作業に関して一元的に管理する人や部署も決められていないので、対応した担当者以外は作業状況や進捗を確認することもできず、本番環境リリース後の切り戻しが多発するような状況だったという。
　こうした問題を解決するため、JSCでは2007年3月より本格的な変更管理の仕組みづくりに着手。従来、個別に対応していた変更作業は、IT本部内に新設したサービスデスクで一元管理することとした。
 変更要求対応のフローとしては、まず変更要求を受けたサービスデスクが各チーム（アプリケーション開発チーム、データベースチーム、構成管理チーム）に影響調査を依頼。その結果をサービスデスクが集約し、全チームが参加するシステム変更会議にて作業内容を確認する。なお、システム変更会議の前に、DB変更内容をXupperIIに登録しておく。そして、各チームで変更作業を行った後、再度システム変更会議を実施。XupperII上のDB変更内容を確認し、後述する確定用のリポジトリに移行する。リリース前にはクロスリファレンス調査やCRUDの確認を行い、最終的にリリース判定会議での承認を経て、リリースとなる（図1）。

変更用リポジトリと確定用リポジトリによる二元管理

  JSCが構築したこの変更管理の仕組みにおける最大の特徴は、複数のリポジトリを使用できるXupperIIの特性を活かし、2つのリポジトリを使って変更管理を行っていることだ（図2）。

  常に発生する変更要求とリリースに対応するために、開発者が変更・修正・追加情報を登録するのが「変更用リポジトリ」。そして、本番機に実装された状態の内容を保持するために使うのが「確定用リポジトリ」である。
 基本的には、アプリケーション開発チームの各サブシステムの担当モデラが変更用リポジトリの内容を追加・更新し、データベースチームのDA（データ管理者）とDBA（データベース管理者）がそれを確認する。最終的にリリースが承認されると、DAはXupperIIのシステム差分チェックやクエリAPI差分検査の機能を使ってチェックを行い、リポジトリ統合機能を使用して変更用リポジトリの内容を確定用リポジトリに統合する。こうして、常に確定用リポジトリが最新の状態に保たれる仕組みだ。
 このような取り組みにより、JSCでは効率的かつ的確な変更管理のための基盤を確立。開発者間の情報共有、影響範囲確認なども、変更作業工程の検討段階で行えるようになった。
 また、基幹システムの設計当初はXupperIIで管理していなかった業務プロセスやドメイン、CRUDなどの情報も整備し、XupperIIでの管理対象を広げたことで、システム保守効率を大幅に向上している。

今後もさらにXupperIIの利用範囲を拡大

 JSCの基幹システムは、インタフェースを介して会計システムやWMS（倉庫管理システム）などのさまざまな外部システムと連携している。JSCでは現在、その1つであるDWH（データウェアハウス）システムを新BIシステムに移行する作業を進めている。現行DWHシステムは基幹システム以前に設計されたこともあり、DB定義やフィールド定義、ERDがメンテナンスされていない部分もあった。そこで新BIシステムでは、設計時よりXupperIIにDB定義情報を登録することになっている。現行DWHシステムの独自項目から脱却するために、新BIシステム移行にあたってはXupperIIの活用によって基幹システムのリポジトリからデータを取り込み、インタフェース元基幹システムのDB定義と合わせることで、データ整合性を高めることを目指す。
 また、JSCでは2010年より、次期基幹システムの設計・開発に着手する予定となっている。現在はその検討フェーズとして、現行システムの設計情報の分析などにXupperIIを使用しているそうだ。さらに、次期基幹システムの設計における業務フローの整備やTo Beデータモデルの検討など、今後もさまざまな場面でXupperIIを活用していくことになるという。

導入事例PDFファイル