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

事例カテゴリー

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

東日本ICTソリューション事業部 東京ICTソリューション課 課長 上田貴史氏
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をケースバイケースで使い分けられるような仕組みを模索していくという。

jirei_download_2.png