第13回Xupper事例紹介セミナーレポート

公開日 : 2014年04月06日

更新日 : 2022年10月28日

京セラコミュニケーションシステム株式会社様

Xupper＋MDFrame/Xを活用し上流から下流までの一貫した標準化を目指す

要件定義の失敗に起因する品質問題や納期遅れ、開発スキルの属人化による品質のばらつき、変更管理のためのメンテナンス工数増加。これらは今日、多くのITベンダーが直面する、システム開発の共通課題となっている。京セラコミュニケーションシステムでは、こうした課題を解決するツールとして、Xupper＋MDFrame/Xを選択。要件定義を中心とした上流工程の効率化および開発の標準化に取り組んでいる。

システム開発のさまざまな課題をいかに解決するか

　京セラコミュニケーションシステム（以下、KCCS）では、今日のシステム開発において解決すべき代表的な課題を、外的要因と内的要因に分けて捉えている。

　外的要因による課題としては、IT投資額の削減、品質問題、納期遅れなどがあるが、特に品質問題と納期遅れに関しては、その多くが上流工程に起因するものだという。

　また、内的要因による課題としてKCCSが重視しているのが、スキルの属人化、変更管理に関する課題、原本管理に関する課題だ。

　上流工程でいかに要件を汲み取り、プロジェクトを推進できるかはプロジェクトマネージャ個人の能力に依存する部分が大きく、下流工程でもコーディングのレベルやスピードはプログラマ個人のスキルに左右されるケースが多い。こうしたスキルの属人化は、品質のばらつきにつながる。

　変更管理に関する課題とは、たとえば、ドキュメントレベルの標準化が不十分な場合、記載レベルにばらつきがあるため、変更時のドキュメント修正や影響調査に時間を要してしまうといったこと。これにより、メンテナンス工数が増加してしまう。

　原本管理に関する課題は、ドキュメントの保存方法が統一されていない場合などに発生しがちなデグレーションの問題を指している。デグレーションの発生は、新たな障害を引き起こす危険性がある。

　KCCSでは、これらの課題を解決するためには上流工程（特に要件定義）を効率的に行い、下流工程（開発）を標準化することが不可欠と考えている。そして、それを実現するツールとして選択したのが、XupperおよびMDFrame/Xだ。

DOAによる上流設計とフレームワークによる開発への取り組み

　KCCSでは1999年頃より、要件定義を中心とした上流工程を効率的に行うという観点から、DOA（データ中心アプローチ）でシステム構築を行うことを模索。そして、DOAによる上流工程を支援するツールの採用を検討し、2000年にXupperを導入している。

　ただし、当時は上流設計の標準ツールとしては定着せず、あくまで「便利ツール」として利用するレベルにとどまっていたという。そのため、しばらくは一部のチームだけでXupperが使われる状態が続いていたが、2007年に改めて標準ツールとして見直しを図った後、全社で本格的に利用するようになった（図1）。

　一方で、KCCSは下流工程の開発標準化にも取り組んできた。1995年の会社設立直後より自社フレームワークの開発を検討し、1996年にVisualBasic版フレームワークを開発。

　続いて1998年にはWeb（ASP）版、2000年にはWeb（J2EE）版のフレームワークを開発した。このJ2EE版のフレームワークは自社ERPパッケージの開発などにも広く利用され、さらに2006年にはライブラリ化されたことで、Strutsなどと連携させることも可能となった。

　このように、Xupperを活用した上流設計および自社フレームワークによる開発に以前から取り組んではいたものの、上流工程と下流工程における標準化を別々に進めてきたため、ドキュメントレベルの共有や品質・スキルのばらつき抑止などを含め、十分な標準化が実現できていないのが実情だった。

　こうした背景から、KCCSでは改めて上流から下流までの一貫した標準化を行うためのツール導入を検討することになり、今回のXupper＋MDFrame/X採用に至ったのである。

　ツール選定にあたり、まずXupperについては、これまでの利用実績から必須であると判断。次に、自社フレームワークとのつなぎ込みを検討したが、クリアすべき課題が多数存在していたため、「即戦力」という観点で見ると自社フレームワークは除外せざるを得なかった。そして、Xupperの資産を活かし、一元管理ができるツールが必要であると考えた結果、順当にMDFrame/Xの導入が決定した。

Xupper＋MDFrame/X 導入後の効果と課題

　導入後は順次、Xupper＋MDFrame/Xによるシステム開発を実際に行いながら、評価を進めている。主にXupperの設計に関する部分で、KCCSがこれまでに認識できた導入効果は以下のとおり。

・設計情報・記述レベルの属人的な知識を組織的な知識にできること
・設計情報の一元管理や変更時の影響調査が容易であること
・原本性の確保（デグレーションの予防）ができること

　一方、主にMDFrame/Xの開発に関する部分では、次のような効果が得られたという。

・設計からシームレスに連携し、設計から一貫した管理ができること
・ソース記述レベルの属人的な知識を組織的な知識にできること
・メンテナンス性が高いこと（変更管理の容易性）
・原本性の確保（デグレーションの予防）ができること

　また、開発コスト削減の効果が確認できた実例もある。当初、原料需給システムの開発において、新規開発時の想定工数が約22人月、変更時の想定工数が約10人日としていたが、Xupper＋MDFrame/Xを利用したところ、開発時の実績工数は約15人月、変更時の実績工数は約5人日という結果になったそうだ。それぞれ約1.5倍と約2倍の生産性向上を実現したことになる。

　確かな導入効果が得られた一方で、明らかになった課題もある。意外と大きいのが、操作性に関する課題だ。すべてGUIで設定・変更を行うため習得に時間を要し、メンバー全員が習得するまでには、開発総工数の半分程度の工数を別途要したという。

　そのため、技術レベルの高い開発者がケン・システムコンサルティングの講習会に参加し、社内展開することで、開発者全員が技術を習得できるようにしたそうだ。

　また、開発工程では「実現できない機能」が存在するという課題もあり、これについてはスケルトンの変更やマクロファンクションの開発・追加で対応を行った。

将来的には自社フレームワークとの連携も

　ほかに、XupperおよびMDFrame/Xの仕様上の制約が開発工程での課題となっているケースもあっため、KCCSでは製品の機能拡張や改善についてケン・システムコンサルティングに要望事項を提出している。

　本セミナー開催時点でケン・システムコンサルティング側の対策もかなり進んでいたようなので、それらの機能が実装される日もそう遠くないだろう。

　これまでに確認できた効果や課題も踏まえた上で、KCCSでは今後も継続してXupper＋MDFrame/Xを利用し、評価していく方針だ。また、将来的にはXupperと自社フレームワークとの連携も目指している（図2）。

上流工程のXupperを軸に、下流工程では自社フレームワークとMDFrame/Xをケースバイケースで使い分けられるような仕組みを模索していくという。

京セラコミュニケーションシステム株式会社様の事例PDFは下記よりダウンロードできます

事例PDFをダウンロードする

ジュピターショップチャンネル株式会社様

変更用と確定用の2つのリポジトリを使いXupperで効果的な変更管理を実現

テレビ通販を中心にダイレクトマーケティング事業を展開するジュピターショップチャンネルでは、頻繁に発生する基幹システムの機能改善・新機能追加などの要件に的確に対応すべく、Xupperを活用した変更管理の仕組みを整備。DB変更に関してXupperへの情報整備を進めるとともに、効率的な変更要求対応フローを確立し、変更作業工程の検討段階での開発者間の情報共有や影響範囲確認などを可能とした。

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

　24時間365日完全生放送のテレビショッピング専門チャンネル「ショップチャンネル」を運営するジュピターショップチャンネル（以下、JSC）。同社では1997年以来、既成パッケージのカスタマイズによって構築した基幹システムを運用してきたが、事業の成長に伴い、さまざまな問題が顕在化してきた。

　たとえば、同システムは日次サイクルでの受注・出荷業務の運営を前提としており、夜間バッチ処理中はリアルタイムな在庫引き当てを伴う受注処理ができなかった。これは、24時間の放送・受注を行うJSCにとって、ビジネス上大きな障害となる。

　また、業務上の要請に応じて機能拡張を繰り返してきたためシステム構造にゆがみが生じ、トラブル発生の危険性も懸念されていた。

　そこで、JSCでは基幹システムの刷新を決断。保守性を向上すること、24時間365日の在庫引き当てを伴う受注処理を可能にすることなどを目標に、新基幹システムの設計にとりかかった。また、開発・保守の容易性の向上と開発ツールの確立・定着化を図るため、次のような開発方針とした。

　1つは、開発の標準化。具体的には、DOA（データ中心型アプローチ）に基づいた開発を行い、工程化開発法に基づく開発工程の標準化や、データアクセスの標準化を図るというものだ。

　そしてもう1つが、文書化管理の徹底。旧システムでは設計情報などの文書化が十分に行われていなかったため、新基幹システム構築にあたってはツールを活用して文書管理を行うこととした。

　JSCでは当初、データモデリングツールとしてERwin、上流設計ツールとしてXupperの使用を検討していたが、最終的にはモデリングも含めてXupperの採用を決定。業務フローや概念ERDを記述できること、さまざまな情報を体系的に整理できるリポジトリを搭載していること、設計情報を加工して引き出せることなどが、Xupper導入の決め手となったという。

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

　新基幹システムは、2005年12月にサービスイン。旧システムの抱えていた問題を解決するために構築された新基幹システムだが、サービスイン直後から大きな課題に直面することとなった。

　それは、機能改善・新機能追加などの変更要求だ。2005年以降もJSCの事業は大きく成長を続けていた。「ショップチャンネル」の売上や視聴世帯数の増加に加え、Webやモバイルサイトなど販売チャネルも拡大。それらに対応するために、ユーザ部門からの新基幹システムに対する変更要求も頻繁に発生していたのである。

　ユーザからの変更依頼に対して、現場ではアプリケーション開発担当チームやデータベース担当チームなどがそれぞれ個別に対応していた。変更作業に関して一元的に管理する人や部署も決められていないので、対応した担当者以外は作業状況や進捗を確認することもできず、本番環境リリース後の切り戻しが多発するような状況だったという。

　こうした問題を解決するため、JSCでは2007年3月より本格的な変更管理の仕組みづくりに着手。従来、個別に対応していた変更作業は、IT本部内に新設したサービスデスクで一元管理することとした。

　変更要求対応のフローとしては、まず変更要求を受けたサービスデスクが各チーム（アプリケーション開発チーム、データベースチーム、構成管理チーム）に影響調査を依頼。その結果をサービスデスクが集約し、全チームが参加するシステム変更会議にて作業内容を確認する。

　なお、システム変更会議の前に、DB変更内容をXupperに登録しておく。そして、各チームで変更作業を行った後、再度システム変更会議を実施。Xupper上のDB変更内容を確認し、後述する確定用のリポジトリに移行する。リリース前にはクロスリファレンス調査やCRUDの確認を行い、最終的にリリース判定会議での承認を経て、リリースとなる（図1）。

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

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

　常に発生する変更要求とリリースに対応するために、開発者が変更・修正・追加情報を登録するのが「変更用リポジトリ」。そして、本番機に実装された状態の内容を保持するために使うのが「確定用リポジトリ」である。

　基本的には、アプリケーション開発チームの各サブシステムの担当モデラが変更用リポジトリの内容を追加・更新し、データベースチームのDA（データ管理者）とDBA（データベース管理者）がそれを確認する。

　最終的にリリースが承認されると、DAはXupperのシステム差分チェックやクエリAPI差分検査の機能を使ってチェックを行い、リポジトリ統合機能を使用して変更用リポジトリの内容を確定用リポジトリに統合する。こうして、常に確定用リポジトリが最新の状態に保たれる仕組みだ。

　このような取り組みにより、JSCでは効率的かつ的確な変更管理のための基盤を確立。開発者間の情報共有、影響範囲確認なども、変更作業工程の検討段階で行えるようになった。

　また、基幹システムの設計当初はXupperで管理していなかった業務プロセスやドメイン、CRUDなどの情報も整備し、Xupperでの管理対象を広げたことで、システム保守効率を大幅に向上している。

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

　JSCの基幹システムは、インタフェースを介して会計システムやWMS（倉庫管理システム）などのさまざまな外部システムと連携している。JSCでは現在、その1つであるDWH（データウェアハウス）システムを新BIシステムに移行する作業を進めている。

　現行DWHシステムは基幹システム以前に設計されたこともあり、DB定義やフィールド定義、ERDがメンテナンスされていない部分もあった。そこで新BIシステムでは、設計時よりXupperにDB定義情報を登録することになっている。

　現行DWHシステムの独自項目から脱却するために、新BIシステム移行にあたってはXupperの活用によって基幹システムのリポジトリからデータを取り込み、インタフェース元基幹システムのDB定義と合わせることで、データ整合性を高めることを目指す。

　また、JSCでは2010年より、次期基幹システムの設計・開発に着手する予定となっている。現在はその検討フェーズとして、現行システムの設計情報の分析などにXupperを使用しているそうだ。

　さらに、次期基幹システムの設計における業務フローの整備やTo Beデータモデルの検討など、今後もさまざまな場面でXupperを活用していくことになるという。

ジュピターショップチャンネル株式会社様の事例PDFは下記よりダウンロードできます