オフショア開発におけるUML適用事例紹介セミナー

オフショア利用による販売基幹システム開発でのUML適用事例
日本アイ
日本アイ・
アイ・ビー・
ビー・エム株式会社
エム株式会社
グローバル・
グローバル・ビジネス・
ビジネス・サービス事業
サービス事業 ＩＴアーキテクト
ＩＴアーキテクト
吉田 亮© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

本事例紹介の概要
 社内フレームワーク
社内フレームワークを
フレームワークを利用した
利用したオフショア
したオフショア開発
オフショア開発（
開発（ Java によるカスタム
によるカスタム・
カスタム・アプリケーション開発
アプリケーション開発）開発）を例に、どのように UML や UML 支援ツール
支援ツールを
ツールを活用したか活用したかをしたかを具体的に
具体的に紹介する紹介する。
する。
本事例における
本事例における開発のように活用しているにおける開発では
開発では UML を主に次のように活用
活用している。
している。

 UML が有効である
有効である場面である場面において場面においては
においては、UML ツールやツールや社内資産も
社内資産も活用し活用し、オフショア先オフショア先に仕様や仕様や範囲を範囲を伝えた UML でカバーできない
カバーできない部分
できない部分に部分においては
おいては事前定義した
事前定義した補足資料
した補足資料を
補足資料を作成し作成し、それらをオフショア
それらをオフショア先オフショア先と共有した
共有した オフショア先
オフショア先に開発依頼する
開発依頼する際する際の進捗管理や進捗管理や Q&A 管理等の管理等の管理作業
は、事前に事前に洗い出し、ツールを
ツールを用いて情報共有
いて情報共有できるよう情報共有できるよう対策できるよう対策した
対策した

2© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

本事例紹介の構成
1.
2.
3.
4.
5.

事例として
事例として取として取りあげる開発
りあげる開発プロジェクト
開発プロジェクトのプロジェクトの概要
プロジェクトにおけるプロジェクトにおける UML 利用方法
オフショア開発
オフショア開発としての開発としての協業としての協業
IBM 製品（製品（Rational）
Rational）や社内アセット
社内アセットによるアセットによる開発
による開発
併用した
併用した IBM 社内アセット
社内アセット

6.
7.
8.
9.
10.

具体的な
具体的な UML 活用工程 － なぜ UML を用いたか
UML 活用 － 日中それぞれの日中それぞれの技術者
それぞれの技術者と技術者と作業分担
UML 活用 － 成功箇所、
成功箇所、工夫箇所
UML 活用 － 利用ダイアグラム
利用ダイアグラムとダイアグラムと補完作成資料
UML 活用 － 開発ツール
開発ツール

11. UML 利用の利用の効果と効果と課題 まとめ3

IBM, Rationalは米国及びその他の国におけるInternational Business Machines Corp.の商標です。他の製品名等は、それぞれIBMの商標である場合があります。
Javaは Sun Microsystems, Inc.の米国及びその他の国における商標です。
UML, モデル駆動開発はObject Management Group Inc.の商標又は登録商標です。
© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

事例として取りあげる開発プロジェクトの概要
 製造業のお製造業のお客様のお客様における
客様における販売系基幹における販売系基幹システム
販売系基幹システム再構築
システム再構築 － Java 言語による
言語による
 開発期間：
開発期間： 2007年
2007年7月 ～ 2008年
2008年12月
12月
 日本側にて日本側にて要件定義にて要件定義～要件定義～詳細設計と詳細設計と結合テスト
結合テスト以降
テスト以降を以降を担当。
担当。オフショアに
オフショアにて製造工程（
製造工程（単体テスト
単体テスト含テスト含む）を担当
 実施にあたっての実施にあたっての当にあたっての当プロジェクト方針
プロジェクト方針：方針：– Rational ツールやツールや社内アセット
社内アセット(アセット(フレームワークやフレームワークや成果物)
成果物)利用を利用を前提とした
前提としたモデルとしたモデル・モデル・ベース開発
ベース開発を開発を実施。
実施。

開発工数の
開発工数の削減と削減と品質の品質の向上を向上を実現する
実現する– 製造工程の製造工程の約97%を97%をオフショアにオフショアに依頼。
依頼。Rational ツールを
ツールを用いた社内標準
いた社内標準の社内標準のプロジェクト管理手法
プロジェクト管理手法を
管理手法を適用して
適用して、
して、
管理や
管理やコミュニケーションをコミュニケーションを効率よく
効率よく実施よく実施する
実施する– 各作業において各作業において当において当プロジェクトのプロジェクトの成功だけでなく成功だけでなく、だけでなく、横展開可能な
横展開可能なナレッジの
ナレッジの抽出と抽出と蓄積に蓄積に重点を重点を置き、
成果物
成果物の最適化を最適化を実施する
実施する※オフショアではあるが、同じ IBM グループ内での開発依頼となるため、統一された IBM 社内ツールや手法がそのまま利用可能であることに留意
 開発規模：開発規模：
このタイミング
このタイミングでタイミングで日本から日本からオフショア
からオフショアにオフショアに引継ぎ
引継ぎ↓

基本設計 レビュー
要件定義 (ｱｰｷﾃｸﾁｬ Q&A対応
詳細設計
説明)
弊社お客様
日本アイ・ビー・エム
70
オフショア
4

製造(単体テスト含む）
30～50

単位：人/月 （人数は最大時）

結合テスト 受入テスト
70© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

プロジェクトにおけるUML利用方法
 当プロジェクト実施
プロジェクト実施にあたって実施にあたって UML を使用したが使用したが、
したが、「オフショア開発向
オフショア開発向け
開発向け UML 適用ガイドライン
適用ガイドライン」
ガイドライン」そのものはそのものは参照

していない 当プロジェクトにプロジェクトに UML 技術者や技術者や UML を前提と前提とする開発する開発ツール
開発ツール ( Rational ) 経験者らが経験者らが多らが多く参画し参画していたためていたため、たため、ガイドにイドに頼らず UML を用いて開発可能
いて開発可能な開発可能な素地が素地が揃っていた。
っていた。オフショア開発
オフショア開発のために開発のために UML を採用したわけではな
採用したわけではない 使用した使用した図
した図とタイミング(
タイミング(要件定義～
要件定義～結合テスト
結合テスト）
テスト）

図名

目的

要件定義/
要件定義/基本設計
作成者

効果

目的

詳細設計・
詳細設計・製造・製造・結合テスト
結合テスト
作成者

効果

・お客様の要求の定義
クラス図
・システム(アプリケーション)のアーキテクチャ、構造とユースケース図 振る舞いの定義

日本アイ・
ビー・エム

日本アイ・ビー・エム UMLを前提に開発ツール(Rational)を使用したことで、定義・設計の生産性が向上した。

シーケンス図(ロバストネス図)

図名
日本アイ・
ビー・エム

クラス図
シーケンス図・アプリケーションの設計
日本アイ・ビー・エム シーケンス図に加え、メソッド記述書も定義
仕様を正確に伝えるため。
して作成することで、,メソッドでの処理内容が正確に伝わった。

クラス図

オフショア
シーケンス図5© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

オフショア開発としての協業 － 中国
 IBM 中国グローバル
中国グローバル・グローバル・デリバリ・
デリバリ・センターのセンターの拠点のひとつ
拠点のひとつ、のひとつ、大連センター
大連センターがセンターが製造工程を製造工程を担当
 UML スキルについて
スキルについてはについてはプロジェクト参画
プロジェクト参画の参画の必要要件と必要要件とせず、教育など
教育などはなどは実施していないものの実施していないものの、していないものの、参画メンバー
参画メンバーの
メンバーの多くは UML スキルを
スキルを既に保有。
保有。 当プロジェクト実施上
プロジェクト実施上、実施上、特に UML での仕様
での仕様を
仕様を読んで理解
んで理解することに理解することに支障することに支障なし
支障なし

6© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

IBM製品（Rational）や社内アセットによる開発 － プログラム開発面
 IBM グループ共通
グループ共通の共通のツール＆ツール＆アセットによるアセットによる効率的による効率的な効率的な協業：
協業：

IBM オフショア開発
オフショア開発で開発では、世界各国の
世界各国の拠点において拠点において、
において、IBM グループ共通
グループ共通の共通の開発ツール
開発ツール＆
ツール＆アセットを
アセットを活用すること活用することにより、により、効率的な
効率的な協業を協業を実現し実現し、高品質な
高品質な優れた製造工程
れた製造工程サービス
製造工程サービスをサービスを確保

Japan
India

分析者

ビジネス・
ビジネス・ニーズの分析

IBMのIBMのオフショア開発
オフショア開発

7

Japan
India

アーキテクトモデル・
モデル・アーキテクチャ
アーキテクト

Japan
China

China

China

開発者

テスト担当者

運用管理者

コーディング

機能および機能およびシステム・・テスト
システム

展開

世界中に
世界中に展開されている
展開されている IBM のグローバル・グローバル・デリバリー・
デリバリー・センターは
センターは、IBM グループとしてグループとして、として、共通の共通のツール・・アセット・
ツール
アセット・方法論・
方法論・用語・用語・インフラを
インフラを整備。
整備。このため、
このため、各国の各国のグローバル・
グローバル・デリバリー・
デリバリー・センターのセンターのメンバーがどのようにメンバーがどのようにチームがどのようにチームをチームを組んでも、
んでも、開発手法、開発手法、ツール、
ツール、用語などが用語などが統一などが統一されているため統一されているため、されているため、円滑に円滑に効率的な効率的な協業が協業が可能。
可能。
これにより、
これにより、グローバル・グローバル・レベルでレベルで最適化された
最適化されたひとつのされたひとつのチーム
ひとつのチームとしてチームとして、として、IBM の優れたサービス
れたサービス提供
サービス提供が提供がオフショア開発
オフショア開発でも開発でも可能でも可能になっている
可能になっている。
になっている。
© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

併用したIBM社内アセット
 オフショア開発
オフショア開発チーム
開発チームとチームと協業する協業する前する前に、社内経験
社内経験から
経験から既から既に明らかに問題
らかに問題となっているとこ
問題となっているところとなっているところを整理。それらに対
それらに対してどのようのような施策をとればとればよいか検討
よいか検討した
検討した上した上で、オフショア協業開
オフショア協業開始
協業開始前に対応を対応を行った プログラム開発
プログラム開発面
開発面

UML を使って設計って設計、設計、コーディコーディングをする
ングをする上をする上では共通開発
では共通開発ツール
共通開発ツールとしてツールとして Rational Software Archit
Architecitect
ect を利用
 既存 IP アセットは
アセットは日本側で日本側で開発さ開発されたプログラム
れたプログラム部
プログラム部品などが主などが主
 UML によるメタ
によるメタ・
メタ・モデルなどはモデルなどはプロジェクトなどはプロジェクト（
プロジェクト（お客様要件）
客様要件）により異により異なり、なり、再利用度
再利用度は低い プロジェクト管理
プロジェクト管理面
管理面

日中間あるいは日中間あるいは開発
あるいは開発チーム
開発チーム・
チーム・メンバー間
メンバー間で情報をやりとりする
情報をやりとりする、をやりとりする、共有する
共有する上する上でのひとつの活用
でのひとつの活用例
活用例
 オフショア・
オフショア・チームとのチームとの変更との変更管理
変更管理、管理、進捗状況管理
進捗状況管理↓Rational ClearQuest
rQuest （カスタマ
スタマイズにより進捗状況
により進捗状況管理
進捗状況管理機
管理機能を付与）
付与）
50名というという体制下、各開発チーム
各開発チーム・
チーム・リーダ
リーダが自チームのチームの進捗を
進捗を報告するのではなく報告するのではなく、するのではなく、コーディ
コーディングをングを担当する
担当する
メンバーそれメンバーそれぞそれぞれが自身
れが自身の自身の進捗を
進捗を入力し入力し、日本側
日本側に報告する
報告する仕する仕組み（ウェブ上で自ら進捗を
進捗を入力して入力して更新して更新できる仕できる仕組み）を進捗管理方法
進捗管理方法として管理方法として確として確立↓
社内アセット社内アセット化
アセット化し、アセット登録
アセット登録ライ
登録ライブ
ライブラリにラリに登録
これを用
これを用いた同いた同様の手法が手法が他の後続プロジェクト
後続プロジェクトでプロジェクトでも利用可能
利用可能に
可能に。中国だけでなく中国だけでなく、だけでなく、インドとインドと協業する協業する際する際にも適にも適用可能
Source: If applicable, describe source origin
8© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

具体的なUML活用工程 － なぜUMLを用いたか
 UML の利用工程
 要件定義、
要件定義、基本設計、基本設計、詳細設計の
詳細設計の各工程
 ユースケース図
ースケース図、ユースケース記述
ースケース記述、
記述、シーケンス図
シーケンス図を中心に利用。
利用。 UML に限らず日本語
らず日本語で日本語で記載 UML 利用の利用の成果（成果（メリット）メリット） 「統一さ統一された手法
れた手法・
手法・モデリングによるモデリングによる情報
による情報共有
情報共有」
共有」

標準化さ
標準化されているため、れているため、ユースケース図
ースケース図やシーケンス図
シーケンス図の読み方から説明から説明する
説明する必要する必要がな
必要がないがない UML 導入による導入によるデメリット
によるデメリット お客様と客様と– お客様側
客様側に UML による説明
による説明を
説明を理解できる
理解できるスキルできるスキルがスキルが求められてしまう
められてしまう。
まう。当プロジェクトではプロジェクトでは、
では、そのため、そのため、別途業
別途業務フロー図
フロー図などの資料などの資料を
資料を作成して作成して補完して補完した補完した オフショア・
オフショア・チームとチームと
 詳細設計工程において
詳細設計工程において、
において、シーケンス図
シーケンス図だけで設計仕様
だけで設計仕様を
設計仕様を詳細・
詳細・正確にすべてを伝てを伝えることはることは困難。
困難。また、
当プロジェクトではプロジェクトではオフショア
ではオフショア・
オフショア・メンバーを
メンバーを日本に日本に呼んで口頭
んで口頭で口頭で説明する
説明する機会する機会を機会を全く持たなかった。
たなかった。
そこで、そこで、オフショア・
オフショア・メンバーにメンバーに詳細・
詳細・正確に仕様を仕様を伝えるべく、UML 以外に、メソッド記述書
ッド記述書（記述書（メソッド毎
ッド毎の処理機能記述書）
記述書）を別途作成
別途作成して作成して対応して対応した対応した UML 採用の採用の理由
 当プロジェクトのプロジェクトの特徴としてオとしてオブジェクト指
ジェクト指向／モデル駆動
モデル駆動による駆動による開発
による開発が開発が主体→ それら
それらを実現でき
実現でき、でき、Java での開発
での開発とも開発とも親和性
とも親和性の親和性の高い UML を採用
 標準として標準としてオフショア
としてオフショア・
オフショア・チームにチームにもスキルを
スキルを持つ技術者が技術者が多く、インターネ
インターネットやットや一般書籍などでも一般書籍などでも情報などでも情報が情報が得られて調られて調べやすい IBM Rational ツールを
ツールを利用しての利用しての UML 作成が作成が可能であり可能であり、であり、実績から事例
から事例として事例として展開
として展開する
展開する面する面でも貢献
でも貢献可能貢献可能
9© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

UML活用 － 日中それぞれの技術者と作業分担
 日本側体日本側体制 （最大時最大時 70 名の作業分作業分担）：
 アーキテクト・
アーキテクト・チーム

UML 利用経験
利用経験や経験や実開発経験で実開発経験でスキル・
スキル・レベルのレベルの高い十数名が、アーキテクチャ
アーキテクチャ策定と、作成する
作成する成果物
する成果物の成果物の粒度や粒度や作成方法を
作成方法を決定。それに基それに基づき、標準化チーム
標準化チームがチームがアプリ・
アプリ・チームにチームに対してガイド
してガイドをガイドを作成。
作成。
当プロジェクトではプロジェクトでは、
では、Rational ツールのツールの使い方（プロジェクト独自
プロジェクト独自の独自のツールのツールの使い方があることから）があることから）に関して、して、アーキテクト・アーキテクト・チームからチームから一度から一度だけ一度だけオフショア
だけオフショアのオフショアの現地に現地にて勉強会を
勉強会を開催 アプリ・
アプリ・チーム
ガイドに
ガイドに基づき実際に設計する
設計するメンバー
するメンバーでありメンバーであり、であり、 オフショア・
オフショア・チームとのチームとの Q&A に関しては、
しては、実際に設計書設計書を書いているアプリ
いているアプリ・
アプリ・チームがチームが対応 オフショア
 製造工程は
製造工程は、仕様として仕様として日本側として日本側から
日本側から伝から伝えられた通られた通りにコーデ
りにコーディ
コーディング 単体テスト
単体テストまテストまではオフショア
ではオフショア側
オフショア側で、コーディ
コーディング不良
ング不良の不良の点検と修正し修正し、日本側に
日本側に渡す前に不良箇所
不良箇所は
箇所は解決

していることを前提していることを前提
 ツールで
ツールでテスト実施
テスト実施カ
実施カバレッジを
バレッジを測定するようするようにしておりにしており、
おり、単体テスト
単体テストは
テストはオフショアでオフショアでテスト項目
テスト項目を
項目を消化していればいれば、再度の検収を検収を日本側で
日本側で行う必要はなかった
必要はなかった
 作業分
作業分担
要件定義

日本アイ・ビー・エム

基本設計 詳細設計

管理(ｽｹｼﾞｭｰﾙ
・品質)

製造(単体テスト含む）

結合テスト 受入テスト

お客様

オフショア
10

●

●

●

●
●

●

●

●
© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

UML活用 － 成功箇所、工夫箇所
 成功箇所
 業界で業界で標準化された
標準化された表記法
された表記法のため
表記法のため、のため、各設計書の
各設計書の標準化作業を標準化作業を軽減できた
軽減できた。
できた。オブジェクト指向
オブジェクト指向

言語と言語とツールのツールのサポートによりサポートにより、により、モデルからモデルからコード
からコードを
コードを生成して生成して実装して実装の実装の基盤とすることができ基盤とすることができ、とすることができ、開発生産性の開発生産性の向上につなげるこ
向上につなげることができにつなげることができたとができた。
 工夫箇所 クラス図
クラス図やシーケンス図
シーケンス図の作成方法や作成方法や作成基準などは作成基準などは事前などは事前に事前に定義し定義し、各設計担当者の各設計担当者の間で記述上の記述上の差異、差異、設計上の設計上の差異が差異が生じないようにした。
じないようにした。 また、
また、その他
その他の資料（資料（メソッド毎
メソッド毎の詳細な処理機能記述書など
処理機能記述書など）など）も適宜補完して適宜補完して、
して、オフショアに
オフショアに実装を実装を依頼する
依頼する上する上で、より仕様
より仕様を
仕様を明確に明確にするようにした。
するようにした。
 今後の今後の基本方針
 引き続き UML を積極的に積極的に使用したい
使用したい。
したい。
– 業界標準であることから業界標準であることからオフショアであることからオフショア・
オフショア・チームにチームにもスキルを
スキルを保有している
保有している要員
している要員が要員が多い。また、
また、スキルがスキルが不足している
不足している場合
している場合でも場合でも情報源
でも情報源は
情報源は多く、スキル向上
スキル向上が向上が容易に容易に可能な
可能な環境にある環境にある。
にある。
– 統一された
統一されたモデリング
されたモデリング表記
モデリング表記のため表記のため、のため、日本語・
日本語・英語といった英語といった言語差といった言語差により言語差により仕様理解
により仕様理解が
仕様理解が大きく左右されることが左右されることが少されることが少ない（
ない（言語差による言語差による影響
による影響を
影響を抑えることができる）。
えることができる）。
– IBM 開発ツール
開発ツールの
ツールのサポートによりサポートにより、により、モデルからモデルからコード
からコードを
コードを生成して生成して実装して実装の実装の基盤とすることがで基盤とすることができ、開発生産性を
開発生産性を向上できる
向上できる。
できる。
11© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

UML活用 － 利用ダイアグラムと補完作成資料
 要件定義工程
 UML としてはユースケース
としてはユースケース図
シーケンス図を中心に中心に、クラス図
クラス図とロバストネス図
ロバストネス図も利用
ユースケース図とシーケンス図 お客様による
客様によるレビューによるレビューに
レビューに用いた主いた主要資料としては資料としてはユーケース図ユーケース図とユースケース記述
ユースケース記述、記述、マイクロソフト社
マイクロソフト社エクセルによるエクセルによる業務による業務フロー
業務フロー図
フロー図

図名

日本アイ・
ビー・エム

・お客様の要求の定義
クラス図
・システム(アプリケーション)のアーキテクチャ、構造とユースケース図 振る舞いの定義
シーケンス図(ロバストネス図)

日本アイ・
ビー・エム
オフショア
12

目的

作成者

要件定義/
要件定義/基本設計

効果

日本アイ・ビー・エム UMLを前提に開発ツール(Rational)を使用したことで、定義・設計の生産性が向上した。

工夫した
工夫した点
した点

①業務フローは、お客様がUMLに慣れていないこともあり、EXCELを用いてUMLと異なる記法で作成した。
②クラス図・シーケンス図の作
成方法や作成基準は事前に定義し、各設計書間で担当者に依存する記述レベル差異が生じないようにした。

詳細設計・
詳細設計・製造・製造・結合テスト
結合テスト
図名
目的
作成者
効果
工夫した
工夫した点
した点
①シーケンス図だけでは仕様伝達
シーケンス図に加え、メソッド記述書も定義
・アプリケーションの設計
日本アイ・ビー・エム
クラス図 仕様を正確に伝えるため。
して作成することで、,メソッドでの処理内容が が難しかったため、メソッド記述書(メソッド毎の処理機能記述書)を別
正確に伝わった。
シーケンス図途定義して作成した。メソッド記述
書は、I/P/O記述形式の定型
フォーマットを作成し、各メソッドのクラス図
入力と出力、処理内容を明確にした。
シーケンス図© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

UML活用 － 利用ダイアグラムと補完作成資料
 基本設計、
基本設計、詳細設計工程
詳細設計工程 UML としてはシーケンス
としてはシーケンス図
シーケンス図、クラス図
クラス図とロバストネス図
ロバストネス図 UML 以外に以外に作成した
作成した主
した主要資料として資料として画面定義資料、
画面定義資料、DB 定義(
定義( ER 図)資料、資料、メソッド記述書
メソッド記述書など
記述書など
 メソッド記述書
メソッド記述書は
記述書は当プロジェクト独自
プロジェクト独自で独自で、I/P/O ( Input/Process/Output ） が明確になる
明確になるようになるよう
定型フォーマット
定型フォーマットを
フォーマットを指定。
指定。
 Rational ツール上
ツール上にあるモデルにあるモデルのモデルの、どのクラス
どのクラスにクラスに対する処理
する処理の処理の内容か
内容かが正確に正確に特定可能 文は短く、主語や主語や目的語は
目的語は明確に明確に示すようガイド
ようガイド
 詳細に
詳細に標準化し
標準化し、例えば違えば違うメソッドをメソッドを呼び出す場合の場合の書き方などのレベルなどのレベルまでレベルまで定義まで定義して定義してガイド（例えば、“ここで共通コンポーネントを使う”という場合は、共通コンポーネント名を書き、処理の順番がわかるように、呼び出す箇所についても明確に書くことをガイド） オフショア・
オフショア・チーム作業工程
チーム作業工程 シーケンス図
シーケンス図とメソッド記述書
メソッド記述書を
記述書を中心に中心に読み、仕様を
仕様を理解 Rational ツール上
ツール上、メソッドのメソッドの外枠までツール
までツールによりツールにより自により自動的に生成され生成され定義され定義され定義されるされる。これら

メソッドに
メソッドに対して、して、Rational ツール環境上
ツール環境上で環境上でコーディ
コーディングをングを実施。
（外枠に対して、その処理内容となる中身の業務ロジックを、メソッド記述書を見ながらコーディングするというイメージの作業）
13© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

UML活用 － 開発ツール
 開発

IBM グループ共通
グループ共通の共通の開発環境
開発環境
 Rational Software Architect

現在の Rational ツール群
ツール群

エンタープライズ・アーキテクチャの管理• Rational System Architect• 要求管理及び要求定義•• Rational Requirements Composer, RequisitePro,
DOORS

•

• Rational Software Architect, Application Developer for
WebSphere Software, Rhapsody, PurifyPlus,
Business Developer テスト

担当者による
担当者によるプログラム
によるプログラム動プログラム動作確認
作確認は基本的に基本的にツール
で実施する
実施する方針する方針 （ツールでツールで可能な可能な範囲内範囲内）
 Rational Functional Tester や社内アセット
社内アセットとアセットとしての点しての点検ツール 管理

進捗が
進捗が具体的に体的に見えるようるようにする、にする、コミュニケーション
をとり、をとり、お互いの状況
いの状況を
状況を把握できるよ把握できるようできるようにする
 変更管理
変更管理、管理、進捗状況管理
進捗状況管理には
管理には Rational ClearQuest
 Q&A 管理には
管理には Rational Portfolio Manager

アーキテクチャの管理•変更とリリースの管理• Rational Team Concert, Build Forge, Change,
Synergy, ClearCase, ClearQuest, Software Analyzer

プロセスとポートフォリオの管理• Rational Focal Point, Insight, Method Composer• 品質の管理•• Rational Quality Manager, Functional Tester,
Performance Tester•

ウェブ・サイト・セキュリティとコンプライアンスの確保• Rational AppScan, AppScan Source Edition, Policy
Tester ツール適用
ツール適用にあたって適用にあたって 他社メンバーもメンバーも参画して参画してマしてマルチ・
ルチ・ベンダベンダーで開発する
開発するプロジェクトするプロジェクトとなるとプロジェクトとなると、となると、ツールのツールの使い方など教育
など教育の
教育の工数

が生じる
 当プロジェクトよりプロジェクトより小より小規模な
規模なプロジェクトであれ
プロジェクトであればであれば、ツールのツールの使い方を変えることも検討ることも検討する
検討する（少人数プロジェクトではプロジェクトでは、
では、ツールを
ツールを多く使うことで、ことで、ライセンス費
ライセンス費用や教育工数の
教育工数の相対的
相対的割合増加）
増加）14© Copyright IBM Japan, Ltd. 2012

日本アイビーエムにおける適用事例

UML利用の効果と課題 まとめ
 UML が有効である
有効である場面である場面において場面においては
においては UML ツールやツールや社内資産
社内資産も資産も活用し活用し、オフショア先オフショア先に仕様や仕様や範囲を範囲を伝えた UML でカバーできない
バーできない部分
できない部分に部分においては
おいては事前定義した
前定義した補足資料
した補足資料を
補足資料を作成し作成し、それらをオフショア
それらをオフショア先オフショア先と共有した
共有した オフショアにオフショアに開発依頼する
開発依頼する際する際の進捗管理
進捗管理や管理や Q&A 管理等
管理等の管理作業は
管理作業は事前に洗い出し、ツールを
ツールを用いて
情報共有
情報共有できるよ
共有できるようできるよう対策した
対策した オフショア開発
オフショア開発に
開発に UML を導入する
導入する際
する際、必要を必要を感じるもの：
もの：
当プロジェクト事例
プロジェクト事例から
事例から、から、UML モデリングだけではモデリングだけでは仕様
だけでは仕様伝達
仕様伝達に
伝達に不十分とい不十分といえといえる。 開発工程において開発工程において UML だけ
では不十分な
不十分な箇所を箇所を補足するため補足するため、するため、いつど
いつどのようのような資料をどの
資料をどのレベルをどのレベルでレベルで作っていけばっていけばよいか（
いか（当プロジェクトのプロジェクトの例では、
では、メソッドにッドに関するメ
するメソッド仕様
ッド仕様書
仕様書を作成など
作成など）など）ガイドできるとガイドできると、
できると、より広より広く安心して安心して利用して利用しやすく
利用しやすくな
しやすくなろうUML 以外での成功
での成功の
成功のポイント：イント： 技術面
技術面では、日本側で日本側で事前にアーキテクチャ
アーキテクチャを設計し設計し、また、各種成果物の成果物の標準化を
標準化を徹底して徹底して、して、オフショアへ
オフショアへの引渡し
引渡し前に品質を品質を高めたこと。
めたこと。また、Rational ツールを
ツールを使う、社内アセット
社内アセットを
アセットを使うといった社内といった社内資産
社内資産の資産の活用を活用を積極的に実施したこと実施したこと オフショアでのオフショアでの協業
での協業には協業には管理には管理面
管理面でも様々な障害が生じる。（例えば、えば、進捗状況
進捗状況が状況が見えない、ない、Q&A の内容が共有されず、いろいろな開発担当者から開発担当者から同から同じような質問を繰り返し投げられて、られて、日本側に
日本側に過剰な
過剰な工数負荷
工数負荷が負荷が生じる、など。）など。） それら懸念
それら懸念点
懸念点を事前に洗い出して対策して対策を対策を立て、適切な準備期間を期間を経て、適切なツールをツールを使って対応
って対応
したこと
したこと

15

© Copyright IBM Japan, Ltd. 2012