オフショア開発向けＵＭＬ適用ガイドライン
Ver １．０

2007 年 5 月

特定非営利活動法人 ＵＭＬモデリング推進協議会
オフショアソフトウェア開発部会

Copyright ©

特定非営利活動法人 UML モデリング推進協議会 2007 All rights reserved

1

目次
１． 目的

･･････････････････････････････････････････・・・・・・・・・・・・・・・・・・・・・・ 3

２． オフショア開発における現状の問題点と対策
３． ＵＭＬの特徴･･･････････････・・・・・・・・・・・・・・・ 9･･････････････････････････････････････････・・・・・・・・・・・・・・・・ 12

４． ＵＭＬの適用範囲と、開発のノウハウ（Hints & Tips）
付録．成果物サンプル･･････・・・・・・・・・・・・・・・・・ 15･･････････････････････････････････････・・・・・・・・・・・・・・・・・ 47

2

１．目的
(1)（オフショア開発全体における）本ガイドラインの位置付け
オフショアでのシステム開発においても、オフショアではない国内開発と同様、要求/設計/構築/テストの開発サイクル各工程に関するテクノロジー視点での開発方法論、プロセスやコストに関するプロジェクト管理手法、成果物の品質管理手法などが利用される。
本ガイドラインは、その中でも”UML を用いたオフショアでのソフトウェア開発”に焦点をあて、オフショア開発特有の、かつ、UML を用いた開発に共通に見られる課題点への Hints & Tips を、実践経験に基づきまとめたものである。
なお、開発方法論、プロジェクト管理、品質管理の各手法に関するオフショア開発以外にも共通の要素については、本ガイドラインでは言及していない。それらについては、他の参考資料を参照されたい。

3

(2)本ガイドラインでの対象
本ガイドラインでは、以下の範囲をガイド対象としている。
まず、「システム開発」という広義の開発を考えてみると、UML2 などを主に用いるソフトウェア・エンジニア
リングと、SysML なども用いるシステム・エンジニアリングに分けられる。本ガイドラインでは、このうち、ソフトウェア・エンジニアリングに焦点をあてて検討した成果を記している。

ソフトウェア・エンジニアリング

システム・エンジニアリング

UML 2

SysML

Requirement diagram
クラス図

Block difinition diagram

パッケージ図State machine diagram

Interrnal block diagram

コミュニケーション図

Sequence diagram

Package diagram

オブジェクト図Use case diagram

Parametric diagram

コンポーネント図

Activity diagram

合成構造図
配置図
相互作用概要図
タイミング図4

次に、そのソフトウェア・エンジニアリングを詳細に見てみる。
ソフトウェア・エンジニアリングは、大きく・要求～設計～構築～テスト～保守の、開発サイクルの各工程での開発技術の要素

・

ツールや開発方法論、構成管理方法といった成果物作成支援の要素

・

開発のプロセスやコストに関するプロジェクト管理の要素

・

仕様書、プログラムなど成果物に関する品質管理の要素に分けられる。
一方、そのエンジニアリング対象となるソフトウェアは、1) 組み込みを前提としたソフトウェアと、2)業務
アプリケーション用ソフトウェアとに分けられる。 さらにその業務アプリケーションは、2a) ソフトウェア製品をパッケージとして利用し、その製品仕様のカスタマイズ範囲内で設計・構築を行うケースと、2b) 適用
パッケージを考えにくく、自由度は大きいが、新規設計・構築部分が多くなるカスタム開発を行うケースとがある。
本ガイドラインは、この中で、開発サイクルの各工程での開発技術要素、それもパッケージではなく、カスタムの業務アプリケーション・ソフトウェア開発に焦点をあてて、Hints & tips とするものである。

ツール
/手法

要求

設計

構築

テスト

保守

組み込み系
パッケージ系
カスタム系

その他業務アプリ系

5

構成管理

プロセス

マネジ
メント

品質

さらに開発サイクルの各工程を、より詳細に見てみる。
開発サイクルは、要求工程の後半の要件定義から、設計を経て、構築、テストへと続いていく。 これを”UML”という切り口から見ると、ビジネスプロセスを実現する IT システムの要件定義を行う工程から、プ
ログラミングを始める構築工程までが、UML を利用する局面の対象であると考えることができる。 具体的には、要件を UML により記述する、設計による仕様を UML により記述する、その仕様を UML によりオフショアメンバーに伝え、UML に基づき実装を行う、といった場面になる。
本ガイドラインは、要件定義や外部、内部設計の各工程で UML により仕様記述を行う部分に着目することになるが、モデリングの観点からすると、仕様モデリングや実装モデリングが該当の範囲となる。
モデリングの
３つの観点

要求

要件定義

ビジネス
プロセス

構築

設計
基本設計
外部設計

詳細設計
内部設計

実装・
単体テスト

テスト
統合テスト・
システムテスト

ＩＴシステムユースケース図アクティビティ図
シーケンス図
相互作用概要図

コンポーネント図

クラス図

合成構造図

オブジェクト図コミュニケーション図

ステートマシン図

パッケージ図
配置図タイミング図なお、ここでは要件定義、外部設計、内部設計、実装という名称を用いたものの、後述の本ガイドライン
内では、
・

業務分析

・

要求分析

・

システム分析

・

アーキテクチャ設計

・

詳細設計

・

実装、単体テスト・

結合テストの分け方・用語を採用しているので、注意されたい。
6

最後に、前述の UML 関連の工程において、オフショア開発の視点でどのように整理されるかについて触れる。
本ガイドラインにおいて、オフショアは、外部設計（アーキテクチャ設計）完了後、内部設計（詳細設計）
から実装を担当することを想定してまとめている。 開発者の視点では、「オフショアのメンバーに渡す仕様は、UML を用いて何をどう作成すればよいだろうか？」「オフショア開発特有に気をつけるべき点は何になるのだろうか？」があるし、一方、そのオフショア成果の品質を点検する視点では、「オフショア開発用に、どのような点に気をつけて点検するのがよいだろうか？」「オフショア開発用には何が満たされていればよいと考えればよいだろうか？」という関心事項が挙げられよう。
本ガイドラインは、特にこの点に着目したノウハウを示すものである。
基本設計
外部設計

詳細設計
内部設計

要件定義
成果物

基本設計
成果物

要件定義
→ 基本設計

基本設計→ 詳細設計

詳細設計
→ 実装

日本側

どのように利用・作成すればよいのか

どのようなものを渡せば
よいのか

－

中国側

－

どのようなものを受取りたいのか－

日本側

どのような内容を点検すればよいのか

どのような内容・レベルを達成すればよいのか

－

中国側

－

どのようなものを受取りたいのか

－

要件定義

実装・
単体テスト

統合テスト・
システムテスト実装
成果物

開発者の視点

品質点検の視点

開発者
の視点

品質
点検の
視点

実装 →
統合テスト・システムテスト

以上、本ガイドラインで、どの範囲を対象としているのかを示した。
オフショア開発において典型的なパターンである「オフショアでの内部設計～構築」を想定し、日本側での要件・設計のまとめと、それらのオフショアメンバーへの伝達、オフショア側・日本側双方でのオフショア
開発成果の点検、に関してが本ガイドラインの対象である。

7

補足として、やや異なる視点での対象範囲を示してみる。
要求を分析する、それに対応するシステムを設計する、仕様をオフショアに伝える、伝達結果に基づいて作成し、その成果の品質を点検する、という開発過程において、・国内開発にも共通の点と、オフショア開発特有の点があり、そこでオフショア開発特有の点に着目しても、開発に利用する要素として、・言語として UML 利用する際の技術とノウハウ

・モデリングを行うにあたっての技術とノウハウ

・経験に基づく知的資産となった開発方法論の技術とノウハウが関連事項として挙げられる。
しかし、本ガイドラインでは、「UML を利用するオフショア開発で、要求や仕様を記述し、仕様を伝えて、成果を点検する」という点に絞って記述している。すなわち、UML そのものの解説や使い方、モデリングの解説や具体例、開発方法論の解説や使い方については、本ガイドラインで示してはいない。
以上のことから、本ガイドラインの読者には、UML、モデリング、開発方法論、ソフトウェア開発技術要素
それぞれに知識があることを前提とし、本ガイドラインをそれらの知識をベースに前提知識に紐付けながら
読み進められることを期待したい。 （本ガイドラインは、「オフショア開発に固有でない UML、モデリング、
開発方法論、品質管理、プロジェクト管理のすべても解説し、かつ、オフショアソフトウェア開発のノウハウも合わせて詳述する」ことを目的としていない。）

要求分析する

言語としての
UML利用

モデリング
の技術

設計する

仕様伝達する

国内にも
共通視点
オフショア
開発視点

発注者／日本側からの視点で

国内にも
共通視点

オフショア
開発視点

国内にも
共通視点

開発方法論
オフショア
開発視点

8

品質点検する２．オフショア開発における現状の問題点と対策
オフショア開発の発注側に対してアンケートを実施した。アンケートは、オフショア開発における課題、Ｕ
ＭＬに対する期待・見解とオフショア開発にＵＭＬを活用した時のメリットについて行った。アンケート結果のポイントをまとめると下図のようになる。多くの発注者は、ＵＭＬに対する期待が大きく、ＵＭＬの活用で、課題がかなり解決されると認識している。

UMLに対する期待・見解

オフショア開発における課題
不慣れな言語での読み書きによる
意図・理解の相違

図表現と様式の統一

日本語文章による仕様記述の難しさ
書き手の、読み手に対する過度の理解の期待（行間を読む、など）

オフショア開発へのUMLの活用仕様のあいまい性の低減
将来性

日本・オフショア間での同一認識の共有
仕様の誤解の、開発後半での発覚

UML+オフショア開発のメリット
言語に依存しない、ビジュアルなドキュメント表記方法
上流・下流で統一されたコミュニケーション手段
仕様書やコードにおける変更箇所、一貫性の調査のしやすさグローバルスタンダードな表記法・開発方法

9

（１）アンケート結果の詳細を以下に説明する。
・オフショア開発における課題
オフショア開発におけるいくつかの課題の深刻さを調査した結果である。

4

19

14

全く深刻で 深刻の割
はない
合
13
10
83

1

15

16

18

10

83

1

11

14

22

13

79

4

17

21

14

4

93

2

13

19

16

10

83

6

19

19

13

2

97

3
3
5

14
14
13

11
22
14

26
14
22

6
8
6

90
87
90

12

22

13

9

3

95

極めて深刻 かなり深刻
1 言語や文化の差が原因で誤解が生じる
オフショア企業側に伝達内容を正確に伝えるのに時間がかかり
2すぎる
3 仕様書の曖昧さが原因で誤解が生じる
仕様書とオフショア企業側から納品されたソースコードに乖離が4生じる
5 仕様書に漏れ・抜けが起こる
オフショア企業からくる大量の質問への対応で業務が圧迫され
6
る
7 テスト段階以降になって品質の問題が多く露呈する
8 仕様書を詳細に記述するための負担が大きい
9 オフショア企業側でのテスト内容に不備、不足がある
オフショア企業の担当者が離職することで、業務の継続に支障10がある
オフショア企業が保守・メンテナンスを担当する場合、バグの改11修におけるリードタイムが大きい
12 オフショア企業と同じイメージで効果的な情報共有ができない

深刻

やや深刻

11

23

16

7

2

97

7

27

17

6

2

97

課題に対する解決策
課題に対しての解決策として、以下に示す調査結果より、図表（ＵＭＬ）を使用することで軽減が可能であるとの認識が示されている。
全く反
対

意見
1 UMLは上流工程に関わる人だけが知っていればよい
2 UMLを使っても目に見えるほどのコストは下がらない
3 周囲にUMLを使っている事例がほとんどない
4 UMLは教育が難しい、教育にコストがかかる
5 UMLによって生産性が向上する
6 UMLによって下流工程の手戻りが少なくなる
7 UMLによって品質が向上する
8 UMLは専門的すぎて難しい
9 UMLを使うと見積が難しくなる
10 UMLを使うと進捗管理が難しくなる
11 仕様にUMLを使うと曖昧性を低減することができる
12 仕様にUMLを使うと仕様書変更の影響範囲が把握しやすくなる
13 レビューでUMLを使うと、説明内容を効果的に伝えることができる
14 UMLを使うと開発に混乱が生じる
15 上流工程ではUMLよりも、それに特化したツールの方が優れている
16 UMLを使うと発注元や発注先との間のコミュニケーションが促進される
17 UMLを使うと維持管理のトータルコストを下げることができる
18 UMLは開発を自動化するのに有効である
19 UMLは国内開発よりオフショア開発でより沢山利用されている
20 UMLは国内開発よりオフショア開発の方が向いている

29
3
10
4
1
2
2
9
5
6
1
2
2
12
5
2
1
3
3
4

どちら
か言う
と反対

28
9
17
10
4
5
4
22
20
20
2
6
4
29
15
3
13
15
6
6

どちらと
ある程 非常に 賛成のも言え度賛成 賛成
割合(%)
ない

8
28
9
17
38
30
27
24
32
37
18
17
15
20
36
30
36
26
42
29

2
21
22
31
19
24
29
10
8
4
37
32
35
6
9
23
12
18
12
24

0
6
9
5
5
6
5
2
2
0
9
10
11
0
2
9
5
5
3
3

UML に対しては、以下の点で期待されていると推測できる
又 ＵＭＬはプロジェクトに関わる全ての人が知っている必要があるとの認識を示している。
•

仕様の曖昧性の低減•

図表様式の統一

•

将来性

10

3
40
46
54
36
45
51
18
15
6
69
63
69
9
16
48
25
34
23
41

ＵＭＬに対する期待・見解
調査結果より仕様書やレビューで、ＵＭＬに限らず、図表を利用している人は、全体の７４％であり、大多数の人が、図表の利用を実践し重要性は認識されている。
平均割合
(%)
19%
38%
17%
14%
5%
3%
4%

ケース
(a)
(b)
(c)
(d)
(e)
(f)
(g)

UML（そのダイアグラム1つでも）を利用する
UMLではないが、組織内で図表の描き方を統一して利用する(a)(b)には該当しないが、個人的に図表の描き方を統一して利用する
統一されていない描き方で図表を使用する
文字は用いるが、その中に図表は使わない
口頭で行う
その他の方法74%

ＵＭＬをオフショアに使ったときのメリット
オフショア開発の場合、発注先とのコミュニケーションが重要になる。そのため発注先の国の言語でコミュニケーションができる（⑫）というのは重要であるが、アンケート結果を確認すると、さほど重要度が高くな
い。むしろＵＭＬの特徴である自然言語に依存せず（⑩）、ビジュアルで（②）、ユーザ企業側でも理解しや
すいドキュメント表記方法（③）が求められている。
また、開発の上流から下流までシームレスになっている（⑤）、上流と下流で統一されたコミュニケーショ
ン手段がある（⑥）などが求められている。さらにソースコードを見ないでも仕様書の修正個所が調査できるので保守しやすい。（④）仕様書とソースコードの一貫性が確認できる（⑪）などの支持も多数ある。これ
らもＵＭＬの特徴として挙げられる。
ＵＭＬは、グローバルスタンダードな表記法が使える（①）、などもオフショア開発においては重要なポイントと考える。
全く重要で ある程度重 非常に重
ない
要
要

メリット
①
②
③
④
⑤
⑥
⑦
⑧
⑨
⑩
⑪
⑫
⑬

グローバルスタンダードなドキュメント表記方法が使える
ビジュアルなドキュメント表記方法が使えるユーザ企業側でも分かるようなドキュメント表記方法が使える
ソースコードを見なくても仕様書で修正箇所が調査できるので保守しやすい
開発の上流から下流までシームレスになっている
オフショア開発と国内開発で共通の開発支援ツールが使用できる上流と下流で統一されたコミュニケーション手段がある
グローバルスタンダードな開発方法が使える開発されたものが再利用できるできるだけ自然言語に依存しない表記法が使える仕様書とソースコードの一貫性が確認できる
発注先の国の言語（例：中国語）によるコミュニケー
ションできる
品質指標が確立されていて、品質に保障が取れる

11

計

重要度

13

26

22

61

78.80%

10
13

26
27

24
20

60
60

83.80%
78.20%

14

31

15

60

76.70%

16
9

27
21

18
30

61
60

73.80%
85.00%

8

26

26

60

86.70%

10
15
13
8
24

27
28
30
31
22

24
17
17
21
14

61
60
60
60
60

83.60%
75.00%
78.30%
86.70%
60.00%

13

21

26

60

78.30%

３．ＵＭＬの特徴（１）ＵＭＬとは
ＵＭＬ(Unified Modeling Language)は、ＯＭＧ(Object Management Group)により標準化された、ソフトウ
ェアの成果物を仕様化、図式化するときに使用する表記法である。

（２）ＵＭＬの特徴
ＵＭＬの特徴としては次のようなものが挙げられる。
・ 世界標準である。
世界中の異なる国間でも、異なるプロジェクト間においても、コミュニケーションが容易である。
・ 表現力が高く、しかも理解が容易である。
ＵＭＬが提供する複数のダイアグラム（図）により、多様な視点で分析・設計対象を表現できる。しかし、どのダイアグラムも直感的で理解しやすい。
・ 開発の全ての工程で一貫して使用できる。
開発の各工程における成果物のトレーサビリティが確保されており、各工程間で開発者の間のコミュニケーションが容易である。

（３）ＵＭＬのダイアグラム（図）ＵＭＬのダイアグラム（図）には次のようなものがある。

ダイアグラム（図）

構造図

クラス図

振る舞い図

ユースケース図

合成構造図

ステートマシン図

オブジェクト図アクティビティ図パッケージ図

相互作用図

相互作用概要図

コンポーネント図

シーケンス図

配置図

コミュニケーション図

タイミング図

12

・構造図
●クラス図

●合成構造図分析・設計領域の物や事を概念的に捉え、クラスやコンポーネントの内それをクラスおよびその関係により静的部構造を階層的に表現する。

に

表

現

す

る

。

ビル

：部屋

1

1

1..*

職種

従業員

1
従業員リスト

：廊下

技術職

営業職

：トイレ

事務職

●パッケージ図●オブジェクト図

ＵＭＬ要素をまとめるパッケージ間の関システムのある瞬間の状

係を表現する。

態をオブジェクトおよびその関係により表現する。

従業員

コントロール画面：従業員リスト

田中：従業員

鈴木：従業員

佐藤：従業員

技術職
営業職

事務職

●コンポーネント図●配置図

ソフトウェアコンポーネント（再利用可

システムの実行環

能な部品）の構成を表現する。

境を表現する。
<<device>>: ApplicationServer：給与計算：アカウント<<executionEnvironment>>：J2EEServer13

・振る舞い図●ユースケース図●ステートマシン図

システムが提供する機能と外部との関一つのオブジェクトの時間経過に伴係を表現する。

う状態の変化を表現する。
正社員

正式採用

従業員情報を
追加する

試用期間

技術職

[営業職]

職種
変更

術

]

職種
変更

[技

従業員

職

職
種
変
更

営業職

務

職種
変更

[事

職
種
変
更

職

職種
変更

従業員情報を
検索する

]

事務職

従業員情報を変更する
退職

退職

従業員情報を削除する

管理者●アクティビティ図●相互作用概要図●タイミング図

業務フロー、イベントフロ

複数の相互作用図の関係

時間経過とともに変化するライフラインの状態

ー、アルゴリズムの流れ（フを概観し表現する。

の変化やメッセージのやり取りを表現する。

ロ ー ） を 表 現 す る 。

sd タイミング１

ライフライン１

sd 相互作用１

従業員情報の入力

状態１

イベント３

状態２
イベント２

状態３
イベント１

sd 相互作用2sd 相互作用3

職種の選択。
技術職情報の入力

営業職情報の入力

０ １ ２

事務職情報の入力
sd 相互作用4

従業員リストへの登録●シーケンス図●コミュニケーション図

相互作用（分析・設計対象内に存在する“物”

相互作用（分析・設計対象内に存在する“物”や“人”のやり取り）を時系列に表現する。

や“人”のやり取り）を“物”、“人”を中心にその接続関係に着目して表現する。

sd 従業員登録：登録画面：従業員リスト：登録管理

１：従業員情報の入力
２：従業員の登録：管理者

５：従業員リストへの登録：登録画面

従業員情報の入力

：登録管理

：管理者

：従業員リスト

従業員の登録
３：生成

生成
：従業員

４：生成

生成
：技術職

：従業員

従業員リストへの登録

14

：技術職

４．UML の適用範囲と開発のノウハウ(Hints & Tips)
アンケート結果より、多数の人が、オフショア開発に UML を適用した時のメリットを認識している。UML を
オフショア開発に適用すれば、すぐに効果がでるのではなく、開発のどの局面に、どのように適用するかが重要である。本章では、オフショア開発を成功させるには、各工程で、どのような作業をすればよいかのノウハウを説明する。ノウハウは、UML を中心に説明するが、UML に特化しないものも含んでいる。
図４．１に開発の流れ、表４．１に各工程の目的、作業内容、ワーカー、入力成果物、出力成果物を示す。
開発の各工程で注意すべき事項（ノウハウ）をポイント番号で図４．１に示す。各工程のポイント番号ごとに、ノウハウを説明する。
ノウハウは以下の形式で説明する。
・ポイント番号とタイトル
・内容・目的・詳細・補足・関連情報

15

図 4.1 開発の流れ
日本側

中国側

ポイント①
ポイント②
ポイント③
作業範囲
の明確化

業務分析

ユースケース
図

要求定義書

要求分析

ポイント⑤

ポイント④
ポイント⑥

非機能要件定義

用語集

ポイント⑦
クラス図
シーケンス図システム分析

ポイント⑫
命名規約

ポイント⑧
ポイント⑨

ポイント⑩
アーキテクチャ
説明

詳細設計

ポイント⑪
アーキテクチャ設計
アーキテクチャモデル(クラス図
シーケンス図 等）

ポイント⑰
ポイント⑱

詳細設計ガイドラ
イン

ポイント⑬

詳細設計
レビュー

[NG]

ポイント⑭
ポイント⑮

チェックリスト

ポイント⑯

ポイント⑲
ポイント⑳
クラス図
シーケンス図

詳細設計
レビュー

[OK]

レビュー結果

ポイント21
実装ガイドライン

実装・単体
テスト

チェックリスト
ソースコード実装レビュー[NG]
単体テスト結果

レビュー結果
[OK]

結合テスト

16

表４．１各工程の説明
工程名： 作業範囲の明確化
目的（日本側）：目的（中国側）：
作業範囲、作業分担を確認する。

今回のシス テム の作業範囲、作業分担を明確にする。

作業内容（日本側）：

作業内容（中国側）：

中国側に作業委託する範囲および成
果物を明確にする。

ワーカー（日本側）：

作業の受注する範囲および成果物を明確にする。

ワーカー（中国側）：

PM
分析者
入力成果物：

PM
シス テム 分析者（上流に参加して いる場合）
入力成果物：

・業務フロー

出力成果物：

・作業範囲

出力成果物：

・作業範囲

17

工程名： 業務分析
目的（日本側）：目的（中国側）：

今回のシステムの業務内容を理解し、明確にすることで、要求分析工程において、業務のどの部分をシステム化す
るかを明確にしやすくする。

作業内容（日本側）：

今回対象としてシステムの業務内容を理解する
ことで、次工程以下の作業が円滑に進むように準備をする。

作業内容（中国側）：

業務内容を理解し、明確にする。必要に応じて業務流れを整理する。

ワーカー（日本側）：

今回対象としてシステムの業務内容を理解する。

ワーカー（中国側）：

PM
分析者
入力成果物：

PM
システム分析者（上流に参加している場合）
入力成果物：

・業務フロー

出力成果物：

・ビジネス・ユースケース図
・業務フロー・ビジネス・ユースケース記述
・概念クラス図

出力成果物：

・ビジネス・ユースケース図
・業務フロー・ビジネス・ユースケース記述
・概念クラス図18工程名： 要求分析
目的（日本側）：目的（中国側）：詳細設計以降を担当する場合は、直接的にこの工程の成果物を利用するわけではない。
この工程の成果物から、今回システム開発
対象にしているシステムの機能を理解しておく。
システム機能を知っておくことで、なぜこのような設計をすべきかが理解できるようになり、詳細設計以降のコミュニケーションがス
ムースに行なわれる。

システムの機能的要求および非機能的要求を明確にする。

作業内容（日本側）：

作業内容（中国側）：
出力成果物を参考にして、対象システムの機能を理解する。

顧客のシステムに対する要求を明確にする。

ワーカー（日本側）：

ワーカー（中国側）：

要求分析者

システム分析者（上流に参加している場合）
詳細設計者

入力成果物：
・ビジネス・ユースケース図
・業務フロー・ビジネス・ユースケース記述

入力成果物：

出力成果物：

出力成果物：

・システム・ユースケース図
・システムユースケース一覧
・ビジネス・ルール定義
・システム・シーケンス図・システム・ユースケース記述
・画面遷移図・画面・帳票設計書
・非機能要件定義
・用語集
・命令規約

・システム・ユースケース図
・システムユースケース一覧
・ビジネス・ルール定義
・システム・シーケンス図・システム・ユースケース記述
・画面遷移図・画面・帳票設計書
・非機能要件定義
・用語集
・命名規約

19

工程名： システム分析
目的（日本側）：目的（中国側）：システム開発対象の領域の知識を自然な形で分析する。
開発、運用環境に依存しないモデルを作成することで、再利用性、保守性を向上させる。

作業内容（日本側）：

詳細設計以降を担当する場合は、直接的にこの工程の成果物を利用するわけではない。
この工程の成果物から、今回システム開発
対象にしている領域の知識の習得を目的する。
システム開発対象の知識を得ることで、なぜこのような設計をすべきかが理解できるようになり、詳細設計以降のコミュニケーション
がスムースに行なわれる。

作業内容（中国側）：

システムの概要レベルの構造・関連を示すシステムのコンテキストを定義する。その後、システムの地理的分散や運用の複雑さを理解するための概要を整理し、システムの振舞いを分析する。
ワーカー（日本側）：

出力成果物を参考にして、システム開発領域を理解する。

ワーカー（中国側）：

システム分析者
入力成果物

システム分析者（上流に参加している場合）
詳細設計者
入力成果物

・システム・ユースケース図
・システムユースケース一覧
・ビジネス・ルール定義
・システム・シーケンス図・システム・ユースケース記述
・画面遷移図・画面・帳票設計書
・用語集
・命名規約
出力成果物

・分析クラス図・分析シーケンス図・オブジェクト図（・コミュニケーション図）（・ステートマシン図）
・用語集

出力成果物

・分析クラス図・分析シーケンス図・オブジェクト図（・コミュニケーション図）（・ステートマシン図）
・用語集

20

工程名： アーキテクチャ設計
目的（日本側）：目的（中国側）：システムの基盤構造を明確にする。

作業内容（日本側）：

詳細設計のインプットとする。

作業内容（中国側）：

候補となるアーキテクチャを定義し、出力成果物を参考にして、詳細設計を行な
分析結果を元に、再利用可能なモう。
デル要素を取り込みながら、定義されたアーキテクチャを洗練する。コンポーネント設計、データベース設計を行いながら、アーキテクチャの詳細検討、クラス/サブシステムの識別、サブシステム間インター
フェースの識別を行っていく。
ワーカー（日本側）：
ワーカー（中国側）：
アーキテクト
入力成果物

アーキテクト（上流に参加している場合）
詳細設計者
入力成果物

・分析クラス図・分析シーケンス図・オブジェクト図（・コミュニケーション図）（・ステートマシン図）
・非機能要件定義
・用語集
・命名規約

出力成果物

・設計クラス図・設計シーケンス図・オブジェクト図・パッケージ図・コンポーネント図・配置図
・アーキテクチャ説明
・詳細設計ガイドライン
・詳細設計チェックリスト
・データ・モデル図(E-R図）
出力成果物

・設計クラス図・設計シーケンス図・オブジェクト図・パッケージ図・コンポーネント図・配置図
・アーキテクチャ説明
・詳細設計ガイドライン
・詳細設計チェックリスト
・データ・モデル図(E-R図）

21

工程名： 詳細設計
目的（日本側）：目的（中国側）：
実装作業を行なえるほど、モデルを詳細化する。

作業工数が多い部分について、中国側に作業を委託する。

作業内容（日本側）：

作業内容（中国側）：
アーキテクチャモデルやアーキテクチャ説明書を入力として、サブシステム間で調整を行いながら、詳細化して実装モデルを作成する。

中国側の作業が、アーキテクチャから逸脱していないかをチェックする。

ワーカー（日本側）：

ワーカー（中国側）：

レビューアー
入力成果物

アーキテクト（上流に参加している場合）
詳細設計者
入力成果物

・詳細設計クラス図
・詳細設計シーケンス図（・オブジェクト図）
・詳細設計レビュー結果（中国側）

出力成果物

・設計クラス図・設計シーケンス図・オブジェクト図・パッケージ図・コンポーネント図・配置図
・アーキテクチャ説明
・詳細設計ガイドライン
・詳細設計チェックリスト
出力成果物

・詳細設計レビュー結果（日本側）

・詳細設計クラス図
・詳細設計シーケンス図（・オブジェクト図）
・詳細設計レビュー結果（中国側）

22

工程名： 実装・単体テスト
目的（日本側）：目的（中国側）：

引き続き、作業工数が多い部分について、中国側に作業を委託する。

作業内容（日本側）：

システムを稼働させるソースコードを作成する。

作業内容（中国側）：

ソースコード及び単体テスト結果のレビューを行なう。

ワーカー（日本側）：

詳細設計の成果物をもとに、実装および単体テストを行なう。

ワーカー（中国側）：

レビューアー
入力成果物

実装者
入力成果物

・ソースコード・単体テスト結果
・チェックリスト

出力成果物

・詳細設計クラス図
・詳細設計シーケンス図（・オブジェクト図）

出力成果物

・実装・単体テストレビュー結果

・ソースコード・単体テスト結果
・チェックリスト23

工程名： 結合テスト
目的（日本側）：目的（中国側）：
ソースコードの品質をさらに高める。

単体テストを行なったソースコード
を、結合しテストを行なう。

作業内容（日本側）：

作業内容（中国側）：
詳細設計、実装に関するバグがある場合は、修正する。

結合テストを行なう

ワーカー（日本側）：

ワーカー（中国側）：

テスター
入力成果物

詳細設計者
実装者
入力成果物

・ソースコード・単体テスト結果
・チェックリスト

出力成果物

・詳細設計クラス図
・詳細設計シーケンス図・ソースコード
・バグ票

出力成果物

・結合テスト結果

・詳細設計クラス図
・詳細設計シーケンス図・ソースコード・バグ票
・チェックリスト24表 4.2 工程ごとの成果物の例
工程

成果物
セット

業務分析

ビジネス・
プロセス・
モデル
ドメイン・
モデル
ユース・
ケース・
モデル

要求分析
ﾕｰｻﾞ･ｲﾝﾀｰﾌｪｰｽ･ﾓﾃﾞﾙ
非機能要件
用語集

成果物

UML の図ビジネス・ユースケース図
業務フロー
ビジネス・ユースケース記述

ユースケース図アクティビティ図

概念クラス図システム・ユースケース図
システム・ユースケース一覧
ビジネス・ルール定義
システム・シーケンス図
システム・ユースケース記述
画面遷移図
画面・帳票設計書
非機能要件定義
用語集
ロバストネス図

分析モデル

データ・モデル図（E-R 図）
相互作用図
状態図
アーキテクチャ説明

アーキ
テクチャ・
モデル
アーキテクチャ設計/詳細設計

ソフトウェア構成
ハードウェア構成
基本処理方式
設計クラス図/詳細設計クラス図

シーケンス図
コミュニケーション図
ステートマシン図
パッケージ図コンポーネント図
コンポジット構造図
配置図
シーケンス図
クラス図
オブジェクト図

データ・モデル図（E-R 図）
設計
モデル

シーケンス図
コミュニケーション図
ステートマシン図
タイミング図

相互作用図
状態図

実装
単体テスト/
結合テスト
工程

シーケンス図
相互作用概要図
アクティビティ図で作成する場合あり
ステートマシン図

クラス図
オブジェクト図

分析クラス図システム分析

クラス図
オブジェクト図
ユースケース図

実装セット
テスト・セット
成果物
セット

クラス仕様書
実装コード
テスト計画書テスト仕様書成果物

UML の図25

【ポイント 01 作業範囲／作業分担の明確化】
各工程の作業分担を明確にする。各工程の成果物（UML 図、及び UML 図以外）を決定する。オフショアでの開発担当領域を明確にしてモデリング範囲／テスト範囲を決める。
【目的】
システム開発においては、複数の企業（国内、海外）にてプロジェクトを推進する。
企業により、各作業工程の作業内容、成果物が異なる為、プロジェクト開始時に作業工程別の作業内容を明確にして作業工程にずれが生じないようにする。
発注側／受託側での成果物を明確にして納品時のトラブルの発生を削減する。
【詳細・補足】
各工程でのオフショア担当作業対象を明確にし、作業効率を向上させる。
例えば、開発環境面から運用要件、障害対策要件、セキュリティ要件に関する内容はオフショアでは対応困難な面があり、予め日本側で担当する領域／オフショア側で担当する領域に分けておくと良い。
<全般>
・工程単位に使用する成果物を記述する。
・各工程のインプット、アウトプットを明確にする。
・成果物の、書式・内容の粒度のガイドラインを明記する。
・成果物間に関連性があるものは、成果物間の不整合を防止するため、確認方法も明記する。
<アーキテクチャ設計、詳細設計 （モデリング）>・基盤・他開発部分の提供箇所の明確化<実装・単体テスト （製造、作成）>
・開発環境（サーバ、ソフトウェア種類・バージョン etc）の状態
・提供部品スケジューリング （提供可能時期）
・提供部品（一覧、外部仕様）
・使用する開発ツール<テスト>
・開発環境の状態の考慮
・テスト・データの提供有無 （サンプル・データを配布した方が理解度が高い）
特に、オフショアでの開発には、以下の点をプロジェクト開始当初から考慮しておく必要がある。
・オフショアに準備できる開発環境・テスト環境の制約
26

例： 日本語/中国語の文字の使用可能性、大型機の準備の可能性、ファイルの共有可能性。
・オフショアで設計・実装しにくい非機能要件部分に関する制約
例： 統合認証機能が必要になるテスト、準備可能なテスト機のパフォーマンスに依存するテスト、実環境でないことによる制約。
・オフショアで準備しにくいテスト・データの制約
例： セキュリティに基づく顧客データの提供。日本語/中国語の文字に依存する
テスト・データ。

【関連情報】なし

27

【ポイント 02 利用する UML 図の確定】
各工程で使用するＵＭＬ図、補助資料の種類を明確にする。
【目的】
開発の各工程においては、使用するＵＭＬ図が予め決まっているわけではなく、内容に応じて取捨選択し利用する。プロジェクト開始時、工程ごとに、利用するＵＭＬ図を決め、作業効率を向上させる。
【詳細・補足】
各工程で使用するＵＭＬ図を明確にすることにより、各工程の作業開始時のロスを削減する。必須･任
意に応じて作成（モデルの根拠の説明のため必要）などＵＭＬ図のランク分けを行う。業務分析～詳細設
計の各工程では、次に示すＵＭＬ図の利用を考えてみると良い。
<業務分析>
・ユースケース図・アクティビティ図
・クラス図・オブジェクト図△ （状況に応じて）○△ （状況に応じて）△ （状況に応じて）<要求分析>
・ユースケース図・アクティビティ図・シーケンス図・相互作用概要図・ステートマシン図○△ （状況に応じて）△ （状況に応じて）△ （状況に応じて）△ （状況に応じて）<システム分析>・クラス図・オブジェクト図・シーケンス図・コミュニケーション図・ステートマシン図○○○△ （状況に応じて）△ （状況に応じて）<アーキテクチャ設計、詳細設計>（上記の、前工程での作成図の見直しや詳細化に加え）・コンポーネント図
・合成構造図・クラス図
・コミュニケーション図・ステートマシン図
・シーケンス図・オブジェクト図・パッケージ図
・配置図
・タイミング図△ （状況に応じて）△ （状況に応じて）○△ （状況に応じて）△ （状況に応じて）○○○△ （状況に応じて）△ （状況に応じて）【関連情報】
表４．２ 工程ごとの成果物の例を参照。

28

【ポイント 03 必ずＵＭＬである必要はない】
ＵＭＬで、システム開発の全成果物を作成できない。UML として用意されている図以外も必要に応じて
利用する。
【目的】
開発にあたって、UML として定義されている図だけを用いて設計書を記述しようと考える必要はない。開発対象の内容を、よりわかりやすく、より正しく伝えることが設計書の本来の目的であり、この点を見失わないことが目的である。
【詳細・補足】
ＵＭＬの図の特徴を捉えて、情報をまとめる上で最も適切な図を用いる。
ＵＭＬを適材適所で使用し、ＵＭＬで支援していな成果物は、ＵＭＬ以外の図を使用すべきである。たとえば、
まとめる情報によっては、表形式にまとめたほうが、あきらかに分かりやすいものがある。これを、無理やりＵＭＬのモデルで表現しても分かりにくいだけである。
システム開発のあらゆる面をＵＭＬで作成することにこだわり、ドキュメント地獄に陥らないよう注意すべきである。
ＵＭＬ以外の図の利用には以下のようなものが考えられる。
・画面遷移図・画面・帳票設計書
・データ・モデル図（E-R 図）
・ロバストネス図（UML の拡張）・一覧(表)-EXCEL 等※表４．２ 工程ごとの成果物の例を参照。

【関連情報】なし

29【ポイント 04 上流工程への参画】
オフショア開発を行なう場合、国内で行なう上流工程にもオフショア側のＳＥを参画させることが望ましい。
【目的】
詳細設計以降の工程をオフショア開発する場合、詳細設計工程以降を効率的に推進する。.
【詳細・補足】
上流工程をすべて日本企業で行い、詳細設計工程以降をオフショア開発とした場合、十分な成果物を作成したとしても、オフショア先で、完全にシステムを理解してもらうことは困難である。
したがって、上流工程にオフショア先のメンバを参画させることにより、開発するシステムの目的、内容を理解でき、詳細設計工程以降の設計ミスを削減できる。参加人数は、システムの規模にもよるが、数人程度でよい。
また、オフショア先への提供物と、オフショア側で作成してもらう成果物は、早めに指針を送付して合意を得ておく必要がある。

【関連情報】なし

30

【ポイント 05 非機能要件定義】
非機能要件をまとめておく。 非機能要件とは、機能をどのように実現すべきか（システムの性質）を決める要件である。
【目的】
非機能要件は、アーキテクチャ設計時の重要な要件であり、アーキテクチャ設計前に明確にしておく必要がある。 非機能要件は、アーキテクチャ設計時の入力になる。
【詳細・補足】
システム要件には、機能要件と非機能要件がある。
ユースケース図で機能的な要求を明確にすると共に、非機能要件を定義する。 非機能要件の例を次に示す。
・開発／実行環境（ハード、ソフト）
・性能要件
・信頼性要件・コスト（短期、長期）・セキュリティ・保守性要件・運用要件
ここでは、オフショアの開発領域に限らず、システムに要求される非機能要件を指している。
【関連情報】
アーキテクチャ・モデル31

【ポイント 06 分析モデルで業務を理解】
分析モデルはクラス図を中心に作成し、業務内容を理解できるようにする。
【目的】
分析モデルにより、業務内容の大枠を理解する。
モデルの記述内容は日本語を使用するが、あまり長文を使用しないことが好ましい。
オフショア側プロジェクト・メンバの日本語のレベルがあまり高くない場合でも、情報の伝達が確実である。
※アンケートにおいても、図式を使うことのメリットは確かめられている。

【詳細・補足】
分析モデルはクラス図を中心に作成し、業務の内容を表現する。分析モデルは、実現方法を記述しない。
必ずしも詳細な内容を網羅する必要はない。
共通理解ができるような情報をモデリングする。

【関連情報】なし

32

【ポイント 07 用語辞書を作成する】
用語辞書を作成する。用語辞書は、業務用語と共通用語を分けた方が効果的である。
用語辞書は、日本語だけでなく、オフショア先の言語(中国の場合は、中国語又は英語）を入れた方がよい。
特に、業務用語は、オフショア先の言語を入れた方が、オフショア側プロジェクト・チームに正しく伝わる。

【目的】
業務内容の理解度向上と意識の統一を目的とする。
オフショア側プロジェクト・チームに対しては、ネーミング・ルールを明確にしておくことで、下記をねらう。
・日本側プロジェクト・チームから受け渡した設計書の理解度向上
・オフショア側プロジェクト・チームでの仕様書作成の向上
・受け入れ時のチェックに利用【詳細・補足】
用語と内容説明を記述し、業務の理解度をあげるために使用する。
用語辞書のバージョン変更の連絡は明確にする。
なるべく日本側プロジェクト・チーム、オフショア側プロジェクト・チームでの辞書のバージョンをリアルタイムに近い形で統一すること。

【関連情報】なし

33

【ポイント 08 命名規約を作成する】
命名規約(ネーミング・ルール)を作成する。少なくともシステム分析工程で、命名規約(ネーミング・ルー
ル)の標準化を行う。
【目的】
開発で使用する各種名称の命名規則を標準化し、要求分析/システム分析工程の成果物の仕様理解と、以降の工程の成果物の効率的な作成が目的である。
これは、オフショア側プロジェクト・メンバにとって不慣れな言語で記述された設計書の読解と、以降の設計書の作成時に有用である。
さらに、オフショア側プロジェクト・メンバに対して、命名規約(ネーミング・ルール)を明確にしておくことで、下記をねらう。
・日本側プロジェクト・チームから受け渡した設計書の理解度向上
・オフショア側プロジェクト・チームでの仕様書作成の品質向上
・受け入れ時のチェックに利用
日本側プロジェクト・チームにとっても、日本語の誤用や説明不足がある設計書を理解し、レビューする
上での助けになる。
【詳細・補足】
英語表記なのか日本語表記なのか、何桁なのか、各桁はどのように使い分けられるのかなど、事前に統一しておくとよい。
命名規約(ネーミング・ルール)を決定しておく項目の候補としては・サブシステム名/コンポーネント名、・パッケージ名・ユースケース名

・クラス名

・属性名/プロパティ名
・操作名/メソッド名・イベント名、・メッセージ名、・状態名、
・画面 ID、画面遷移 IDなど【関連情報】
用語辞書と並行して利用する。

34

【ポイント 09 モデルの作成規約を作成する】
ソースコードのコーディング規約などと同様に、モデル作成における規約（ルール）を作成する。
【目的】
モデル作成時、作成の規約（ルール）を作成しておくことで、プロジェクト・メンバの作成したモデルが同一基準で作成される。そのため保守性が向上する。
【詳細・補足】
ＵＭＬの要素（クラス、パッケージ、メッセージなど）を独自のルールを設けることにより、分類し、そのＵＭＬ要素の意味をより明確にすることができる。
たとえばクラスを、BCE（Boundary、Control、Entity）に分けて、システム分析、アーキテクチャ設計、詳細設計を行なうのは、一般的に広く行われている。
Boundary は画面や他システムを仲介するクラス、Control は流れを制御するクラス、Entity は現実にあるクラスを示している。
それ以外にも、「データの受け渡しに使用するクラス」、「データベースとのやり取りをするクラス」、「時間制約があるメッセージ」など、開発プロジェクトや企業単位の独自のルールを設けることで、プロジェクト・メン
バ間の意思疎通を図りやすくする。
必要に応じてこれらモデルの作成規約を設けるときに、ＵＭＬの拡張機能を利用することも考えられる。
ＵＭＬでは、ＵＭＬを拡張する仕組みとしてＵＭＬプロファイルを用意している。ＵＭＬプロファイルによるＵＭ
Ｌの拡張は具体的には、ステレオタイプ、制約、メタ属性を用いる。

【関連情報】
ポイント 07 用語辞書を作成する
ポイント 08 命名規約を作成する35

【ポイント 10 共通機能の明確化】
UML モデリング工程での共通機能化の検討を行う。
設計／実装時のオフショア側プロジェクト・チーム独自の共通化を事前に日本側プロジェクト・チームがアーキテクチャとして確立しておく。
【目的】
品質向上、開発効率の向上が目的である。
具体的には、オフショア側プロジェクト・メンバには、次の傾向があり、それを対策する必要がある。
・提供されたサンプルや最初に作成した開発物を繰り返しコピー＆ペーストし、 それを書き直して成果とする。
・コピー＆ペーストにより設計や実装がなされる結果、共通コンポーネント・共通機能・汎用モジュールとして考えられる類似の機能がいくつも作成されることになる。

【詳細・補足】
オフショア側プロジェクト・チームは内部での開発効率を向上させるために、サンプルを元に独自に共通化し、手順が確立後にコピーして作成していく場合が多い。
事前にアーキテクチャおよびガイドラインを日本側が提供し、日本側で早い段階で分析レビューを行う。
コンポーネントが適切に分割され、共通機能化が図られていることを確認するとよい。
ユーティリティと見なせる同じロジックが、複数のコンポーネントに散在することのないようにする。これには、・作業工程の計画時に、共通機能化検討の作業項目を含めさせる
・レビュー内容に、共通機能化が行われているかのチェック項目を含めさせるが考えられる。
【関連情報】なし

36

【ポイント 11 アーキテクチャ・モデル】
ハードウェア、ソフトウェアのアーキテクチャ・モデルは、日本側で作成する。
【目的】
ハードウェアとソフトウェア・アーキテクチャが顧客の業務的な要求を満足しているかどうか判断するた
めには、対象となる業務内容を十分理解しておく必要がある。また、このアーキテクチャの変更は、システ
ムに対して大きな設計変更・仕様変更を生じることになるため、長期的な視点に立ち、将来的なシステム
拡張や変更を考慮してアーキテクチャを設計しておく必要がある。
また、ハードウェア、ソフトウェア・アーキテクチャの設計をオフショア側に任せた場合には、将来のメンテ
ナンスやシステム拡張を行う際に、発注側（日本側）のアーキテクチャへの理解が弱く、適切な変更・拡張の設計を行えないことにもつながる（この点から、メンテナンスも含め、長期的にオフショアのある特定の企業に任せ続けるという選択肢は考えられる）。
【詳細・補足】
開発対象となるシステムのハードウェア、ソフトウェア・アーキテクチャは日本側で作成すべきである。この時に考慮すべき事項としては、・そのアーキテクチャは、機能面／非機能面で妥当であるか
・求められるパフォーマンスやキャパシティを、どう実現しようとしているか
・本番稼働環境／テスト実施環境からくる制約事項は、どう解決しようとしているか・障害対策を含む運用上の要件を、どう実現しようとしているか・セキュリティに関する要件を、どう実現しようとしているか
・開発に参加するメンバのスキルに、どう対応しているかなどが挙げられる。
そして、アーキテクチャ・モデルを日本側で検討、設計してから、オフショア側プロジェクト・メンバに成果としてそれを伝える。必要に応じて、「ハードウェア、ソフトウェア・アーキテクチャに従って開発を行う手順」などを記したガイドを作成するのもよい。
【関連情報】
ポイント 12 アーキテクチャ説明成果物の作成

37

【ポイント 12 アーキテクチャ説明成果物の作成】システムのソフトウェア・アーキテクチャを説明する成果物を作成する。
【目的】
オフショア開発において、日本側での要求分析～アーキテクチャ設計からオフショア側での詳細設計へと開発の主体が移る際、開発対象システムのソフトウェア・アーキテクチャについて、日本とオフショア双方のプロジェクト・メンバが正しく同じように理解することが必要である。 開発対象システム全体がどのような考え方や構造に基づいて設計されているか、日本側プロジェクト・メンバからオフショア側プロジェクト・メン
バへ効果的に伝える目的がある。
【詳細・補足】
プロセスへのインプットとして補足仕様書を用い、ソフトウェア・アーキテクチャを検討して、検討結果となるアーキテクチャを説明する成果物をアウトプットとして作成する。システム分析～アーキテクチャ設計レベ
ルでのクラス図とシーケンス図、および、それらを補足して説明する資料群からなるのが、アーキテクチャ
説明成果物である。
開発対象システムのためのハードウェア/ソフトウェア・アーキテクチャ、なぜそのように設計されたかの理由や判断ポイント、構造の狙いや目的を、主に機能要求面から各図に記述していく。 必要に応じて、コンポーネント図、パッケージ図、配置図も用いるとよい。 モデルを用いて図示することにより、日本語での説明記述であっても、より正確にオフショア側プロジェクト・メンバに伝えることができる。
すなわち、アーキテクチャ・モデル作成プロセスの関連成果物として、・インプットとなる成果物：

非機能要件定義 （補足仕様書）

・アウトプットとなる成果物： アーキテクチャ説明
詳細設計ガイドラインとなる。
【関連情報】
ポイント 11 アーキテクチャ・モデル

38

【ポイント 13 仕様書の記述レベル、書式の指定】
オフショア側の成果物となる各仕様書について、UML の記述レベルや書式を指定する。
【目的】
UML に限らず、オフショア開発においては成果物サンプルを求められることが多い。オフショア側プロジェクト・メンバによる記述に関し、日本側からの指示やガイドの不足は、個々のオフショア側プロジェクト・メ
ンバ間に記述詳細さのばらつきや、書式のばらつきの問題を生じることになる。オフショア側では、プロジェ
クト・メンバ全員で記述レベルや書式を統一しようとする動きがされにくい背景もここにある。
オフショア側成果物をお客様に提出するのか、日本側プロジェクト・メンバが見るにとどまるのかは、このポイントを適用する上での考慮点になる。
【詳細・補足】
成果物に含まれる UML については、実際の書式に従って、日本側で求める記述詳細さやモデル粒度で、オフショア側プロジェクト・メンバの参考にできるサンプルを作成し、ガイドの一部として提供する。 この時、その UML で何を表して欲しいのか、何が示されていればよいか、モデルの目的を指示できるのが望ましい。
これにより、UML の詳細さ／正確さ／粒度が揃いやすくなる。
例外処理／エラー処理についても、記述して欲しいレベルで適切にサンプルに含めておく必要がある（当然追記されるであろうと期待し、サンプルに含めないでおくと、最終的な成果物にも含められてこない結果となりがちである）。
その他に、成果物の記述時の注意点として「あいまいな表現ではなく具体的な表現で記述すること」、「使用する用語について統一して使用すること」も合わせて指示・ガイドできるとよい。
【関連情報】なし

39

【ポイント 14 詳細設計ガイドライン作成】
アーキテクチャにそって、詳細設計を進めるガイドラインを作成する。
【目的】
アーキテクチャは、保守性、効率性、性能などを考慮して作成してある。
詳細設計では、そのアーキテクチャを踏襲することで、システム全体に対して、保守性、効率性、性能を維持することができる。
詳細設計の作業において、アーキテクチャから逸脱しないように、ガイドラインを作成することが重要である。
【詳細・補足】
アーキテクチャ説明においては、クラス図、シーケンス図などのモデルおよび、自然言語において、そのシステムのアーキテクチャの説明がなされている。
詳細設計では、そのアーキテクチャと同様のことを、システム（モデル）の他の部分(機能）に適用する必要がある。
アーキテクチャ説明に記述されているのは、アーキテクチャの考え方だけである。
ガイドラインでは、どのようにモデリング・ツールを使用し、クラス図、シーケンス図をどこに作成し、クラス、
オブジェクトをどこに配置していくか、などを具体的に説明する。
アーキテクチャ説明を全体の方針とすると、ガイドラインは具体的にブレイクダウンされたものになる。
【関連情報】
アーキテクチャ説明の作成

40

【ポイント 15 仕様未決定部分は明確に】成果物における仕様未決部分は、オフショア側に明確に提示する。
【目的】
開発期間不足などの関係で、要求分析～システム分析～アーキテクチャ設計工程の、日本側作業での仕様未確定部分が多いまま、オフショア側に開発依頼をする場合も少なくない。その仕様未決部分が明確に示されていない成果物は、内容の整合性に欠け、オフショア側プロジェクト・メンバに多くの疑問・質問を引き起こすことになる。
【詳細・補足】
オフショア側プロジェクト・メンバに渡す成果物には、仕様未決（未決・仕様変更の可能性大）部分を明記して渡すことで、仕様吸収漏れを抑えることができる。
仕様未決（未決・仕様変更の可能性大）部分については、成果物 UML 内に、・どの範囲が仕様未決であるのか、影響が及ぶのはどの範囲か・現仕様にどのような変更が予想されるのか（今後さらに詳細化される方向性なのか、内容として異なる内容に置き換わる方向性なのか）を、備考や注釈等として明記する。
日本側プロジェクト・メンバがこれら各項目を管理することで、仕様決定時・仕様変更発生時のオフショア
側開発分への組み込み漏れ防止、仕様変更工数の低減を図ることができる。オフショア側との進捗状況
確認会議においても、それら仕様未決事項の一覧を元に、反映状況更新の確認、仕様決定事項の確認ができるとよい。
【関連情報】なし

41

【ポイント 16 オフショア側でのレビュー実施】
オフショア側プロジェクト・メンバによるレビューを確実に実施する。
【目的】
成果物の内容レビューを日本側でも実施することを伝えると、オフショア側レビューが全く実施されない状態での成果物が届くことが起こり得る。「日本側でレビューするのだから、オフショアでもレビューを行うと二重レビューになってしまい、作業の無駄になる」との考え方がその背景にある。
【詳細・補足】
依頼する成果物に関し、オフショア側でレビューする対象の一覧、レビューでのチェック対象となるポイン
ト、レビューでの合格基準について協議し、合意しておくとよい。 その際、オフショア側でのレビューの目
的、日本側でのレビューの目的の違いも明確に理解してもらい、オフショア側でのレビューが確実に実施されるようにしておく。
基本的なレビュー・ポイントとして；・開発予定機能一覧にある機能がすべて網羅されているか・前工程の設計内容に対応する仕様がすべて記述されているか・指定の記述レベル、書式に従っているか
・用語は正しく統一された語が用いられているか
・開発予定機能の静的な構造が正しく伝わり、設計、記述されているか
・開発予定機能の動的な振舞い・挙動が正しく伝わり、設計、記述されているか
・開発予定機能の物理的な配置が正しく伝わり、設計、記述されているか・クラスの責務に混乱はないか
・図間の整合性が確保されているか・仕様変更が反映されているかなどが挙げられる。
【関連情報】
ポイント 17 チェックを繰り返し行なう42

【ポイント 17 チェックを繰り返し行なう】
開発中はオフショア作業開始直後からチェックを行う。
【目的】
オフショア開発におけるオフショア側プロジェクト・メンバにとっては、やはり慣れない言語でのコミュニケーションとなることから、
・（日本側からは）オフショア側プロジェクト・メンバの理解の度合いがわかりにくい・（オフショア側では）誤った理解で思い込んでしまう。関連する内容をお互いで確認することなく進めてしまい、誤解が解消されないことへの対処が目的である。
【詳細・補足】
作業開始直後から、ウォークスルーなどにより日本側からもチェックを頻繁に実施し、ａ）成果物の内容記述は適切か、
ｂ）成果物の形式は標準に従っているか、
ｃ）要件や設計内容の理解に誤解がないかをチェックするとよい。 オフショア側でのレビュー内容を、日本側からも、途中段階で早期から繰り返し行
うべきとも言える。
さらに、開発期間中を通して、お互いの理解や開発成果内容を、オフショア側プロジェクト・メンバ間で確かめるよう習慣づけられれば、さらに好ましい。
【関連情報】
ポイント 16 オフショア側でのレビュー実施

43

【ポイント 18 UML 図間の整合性】
オフショア側プロジェクト・メンバが設計した UML 図の間の整合性に注意する。
【目的】
UML に限らず、オフショア開発においては、成果物内容相互に整合性の欠落が見られることが多い。
日本側から成果物を渡す際の整合性の欠落は、オフショア側プロジェクト・メンバに多数の疑問・質問を引き起こす。日本側で成果物を受け取る際の整合性の欠落は、日本側プロジェクト・メンバが内容を理解するのに困難な状況となり、双方でレビューできない状況を引き起こす。読者に暗黙の了解を期待した成果物ではなく、必要な情報をすべて記載することも重要な点である。
【詳細・補足】
動的な振舞いの面で、・クラス図/シーケンス図/コミュニケーション図の間・シーケンス図/ステートマシン図/アクティビティ図の間
静的／物理的な構造の面で、・クラス図/パッケージ図/オブジェクト図/コンポーネント図/配置図の間など、関連する複数の図の間でお互いに対応する箇所があるはずの図の整合性は、日本側の詳細設計レビューにおいてチェックすべき対象となる。
また、それぞれの図において、同じものを表すのに異なる用語が使われていることがないかも、整合性の面からの点検すべき対象となる。
・あるシーケンスで動作すると記されたオブジェクトが、クラス図から読み取れない・ある状態遷移を引き起こすトリガが、シーケンス図やアクティビティ図から読み取れない・あるノードに配置されるはずのコンポーネントが、クラス図やコンポーネント図から読み取れないといった整合性の欠落は、実装の誤りを生む。
【関連情報】なし44

【ポイント 19 詳細設計のレビュー】
詳細設計では、クラス図とシーケンス図、オブジェクト図、パッケージ図でレビューを行なう。
【目的】
実装を行なう前に、モデルによって方向性を確認する。
モデルの日本側での詳細設計レビューを行なっていくことで、実装の品質を向上させる。
【詳細・補足】
日本側プロジェクト・チームが作成した、アーキテクチャ説明、アーキテクチャのガイドラインに沿って、オ
フショア側プロジェクト・チームは、詳細設計を行い、成果物としてシーケンス図及びクラス図、オブジェクト
図、パッケージ図を作成する。
日本側プロジェクト・チームは、オフショア側プロジェクト・チームが作成した、シーケンス図及びクラス図、
オブジェクト図、パッケージ図のレビューを行なう。
レビューでは、アーキテクチャ説明を参照し、オフショア側プロジェクト・チームが作成したシーケンス図及びクラス図、オブジェクト図、パッケージ図がアーキテクチャから逸脱していないかのチェックを行なう。

【関連情報】
アーキテクチャ説明
アーキテクチャのガイドライン
詳細モデルチェックリスト45

【ポイント 20 工程単位のレビューは確実に】工程単位のレビュー・ポイントを明確にし、レビューをしっかりと行う。
【目的】
通常の開発においてもレビューは重要であるが、オフショア開発においてはさらに重要なポイントである。
オフショア側プロジェクトに任せたままにしていると、成果物が出来ていなかったり、品質が著しく悪かったりすることがある。それらのチェックのためにも、レビューは確実に行なっておく必要がある。レビューの質が良いほど、品質向上・開発工数低減につながる。
【詳細・補足】
レビューは、通常の開発より、オフショア開発のほうがより確実に行なう必要がある。
しかし、細かなチェック項目を作成しすぎて、日本側プロジェクト・メンバのレビュー工数が膨大になってしま
いがちである。ここで、モデルの利用が有効である。
オフショア側プロジェクト・チームに、コーディングを行なう前に、シーケンス図を書いてもらい、コーディングに入る前に、シーケンス図レベルで日本側で詳細設計レビューを行なっておく。
これにより、ソースコードで、流れを追う必要はなく、モデル（シーケンス図など）で誰もが見やすい形でレビ
ューを確実に行なうことが可能になる。
レビュー・ポイント
・用語の統一（ポイント 07 を参考）
・基準と一致しているか（ポイント 08 を参考）
・書式の一致（ポイント 01 を参考）
・成果物の粒度、設計漏れはないか（ポイント 01 を参考）
オフショア側にまかせっきりにならない。日本側にレビューできる人材が必須
・各図単体・図間の関連のチェック（ポイント 01 を参考）
・仕様確定部分、仕様変更部分がきちんと組み込まれているか（ポイント 15 を参考）
（変更部分以外の影響をチェックしていない場合が多いため、関連箇所もチェックする。
関連箇所は UML 図から確認する）【関連情報】なし46

【ポイント 21 実装はツールのコード生成機能を使用する】
実装時はツールのコード生成機能を使用して、ソースコードのテンプレートを生成し、それをもとにコーデ
ィングを行なう。
【目的】
詳細設計において、オフショア側プロジェクト・チームが作成したクラス図及びシーケンス図などの成果
物を日本側プロジェクト・チームがレビューする。
モデルにおいて問題がないことを確認されたレビュー後の(信頼性のある）モデルから、モデリング・ツールのソースコード自動生成機能を利用することで、ソースコードの信頼性も高める。
【詳細・補足】
クラスについては、モデリング・ツールのコード生成機能を利用することにより、ソースコードのスケルトンを生成することが可能になる。
これにより、クラス名、属性名、操作名などは、ソースコードに出力されるため、ソースコード内の内容を、モデル（クラス図）で確認することが可能になる。
処理の流れ（主にシーケンス図）については、一般的なモデリング・ツールではソースコードの生成を行なわないため、手作業でのチェック作業が必要になる（モデリング・ツールによっては、ソースコードの実行したものをリバースし、シーケンス図を作成できるものもある）。
モデリング・ツールのコード生成機能を利用することで、見やすくわかりやすいモデルのチェックにより、ソースコードの信頼性も高めることができる。

【関連情報】なし

47

付録．成果物サンプル(1)各工程の成果物（一部分だけ）①要求定義
Ａ社では、従業員情報の検索システムの開発を検討しています。
従業員の部署、年齢、住所などのキーワードを入力して検索すると、それに適合する従業員情報を表示します。従業員ならば誰でもこの機能を使用することができます。
この会社の従業員は、技術職、営業職、事務職に分かれます。この会社には幾つかの部署があり、従業員はいずれかの部署に所属します。従業員の所属する部署は１つとは限らず、従業員は、複数の部署を兼務する場合もあります。
従業員情報は、あらかじめ管理者が登録しておきます。また、変更や削除をすることもできます。
従業員の所属する部署も管理者があらかじめ登録しておく必要があり、変更、削除ができます。

48

②工程：要求分析（日本側⇒中国側）●ユースケース図
従業員情報を検索する
従業員

従業員情報を登録する

従業員情報を変更する

従業員情報を削除する
管理者
部署登録する

部署を変更する部署を削除する49

●ユースケースのアクテビティ図(イベントフロー)
ユースケース「従業員情報を登録する」のアクテビティ図(イベントフロー)

従業員情報の入力

職種の選択

技術職情報の入力

営業職情報の入力

事務職情報の入力

従業員リストへの登録

ユースケース「部署登録する」のアクテビティ図(イベントフロー)

部署情報の入力

部署一覧への登録※その他、全てのユースケースに対して、このアクテビティ図(イベントフロー)を記述する。

50

③工程：システム分析（日本側⇒中国側）
●クラス図
1..*

部署

1
部署一覧

1..*
1..*
1

1

1..*

職種

技術職

1

従業員

営業職

従業員リスト

事務職●「従業員情報を登録する」のシーケンス図

sd 従業員登録：登録画面：従業員リスト

：登録管理

：管理者
従業員情報の入力
従業員の登録
生成
：従業員
生成
：技術職

従業員リストへの登録（従業員）

部署への登録（従業員）

51

：部署

●「部署登録する」のシーケンス図

sd 部署登録をする
部署登録

部署管理

部署一覧

管理者
部署情報の入力
部署の登録
生成
部署

部署一覧への登録（部署）52④工程：アーキテクチャ設計（日本側⇒中国側）
●クラス図

local

local
local

登録画面
登録管理

部署DAO
部署

parameterparameter

1..*

local

1..*
1
職種DAO

1

職種

従業員

従業員DAO

技術職

営業職

事務職

parameter

local

53

●「従業員情報登録」シーケンス図
sd 従業員登録：登録画面：従業員DAO：登録管理：技術職DAO：部署DAO：管理者
従業員情報の入力
DAOオブジェクト
作成省略

従業員の登録
生成
：従業員
生成
：技術職

従業員情報のセーブ（従業員）
技術職情報のセーブ（技術職）

部署の取得（部署情報）
生成（部署情報）：部署
部署への登録（従業員）

部署情報のセーブ（部署）54⑤工程：詳細設計（中国側⇒日本側）
●クラス図

local

local
local

登録画面
登録管理

部署DAO

この部分を詳細化

部署

parameterparameter

1..*

local

1..*
1
職種DAO

1

職種

従業員

従業員DAO

技術職

営業職

事務職

parameter

local

local

部署登録

部署管理

部署

parameter
local
部署DAO

55

●シーケンス図ｓｄ 部署登録をする

部署登録

部署管理

管理者
部署情報の入力
部署の登録
生成
部署

生成
部署DAO

部署情報セーブ（部署）56

(2)アーキテクチャ説明書
バージョン 0.1

目次
概論
アーキテクチャの表現
アーキテクチャの目標と制約
ユース ケース ビュー
論理ビュー
プロセス ビュー
配置ビュー
実装ビュー
サイズと性能品質概論

57

○永続化について（ユースケースビュー及び論理ビューの一部）
・Data Access Object (DAO)パターンの利用。
目的：
ビジネスロジックと永続化の実装を分離して、永続化の方法、データベースの違いを吸収する。
DAO の役割：
データの CRUD を DAO が受持つ
データベースのコネクションなどの処理を受持つ
・例 簡単な例（従業員登録）でシステム分析モデルに DAO パターンを導入する
システム分析のクラス図
登録画面

登録管理

従業員

システム分析のシーケンス図
登録画面

登録管理

管理者
従業員情報の入力
従業員の登録生成
従業員

58

DAO パターンを導入した設計モデル
クラス図
local
登録画面

従業員
登録管理

従業員DAOlocal※ local とは、依存関係元のクラスが持っており操作の中で、依存関係先のクラスのオブジェク
トを生成することを示す。
シーケンス図
登録画面

登録管理

従業員DAO

管理者
従業員情報の入力
従業員の登録
生成
従業員

従業員情報セーブ（従業員）「従業員 DAO」クラスが、「従業員クラス」のデータベースへのデータのセーブ、ロードを受け持つ。
・
・
・

59

(3)詳細設計ガイドライン（一部）
設計クラスの追加
・永続化 Data Access Object (DAO)パターン
永続化を必要とする１つの entity クラスに対して、１つの DAO クラスを作成する。
DAO クラス名は、entity クラス名 + ”DAO”

従業員

とする。

従業員DAO・クラス図
control クラスは、新規にローカルに、DAO クラスのオブジェクトを作成し、また entity クラスも新規にローカ
ルに作成するので、依存関係を引き、「local」とコメントを入れる。
DAO クラスは、entity クラスを引数として渡されるので、依存関係を引いて、「parameter」とコメントを入れ
る。
local
登録画面
従業員
parameter
登録管理

従業員DAO

local

60

シーケンス図DAO クラスのオブジェクトは、control クラスがローカルに作成して、呼び出す。セーブする場合は、entity ク
ラスを引数に渡す。

control クラス

登録画面

登録管理

管理者
entityクラス
従業員情報の入力
従業員の登録生成
従業員

DAOクラス

生成
従業員DAO

従業員情報セーブ（従業員）

・
・
・
・

61

従業員オブジェクトを引数で渡すオフショア開発向け UML 適用ガイドライン
特定非営利活動法人 UML モデリング推進協議会
オフショアソフトウエア開発部会
ガイドライン作成メンバー
・ 大下 美穂

バブ日立ソフト株式会社

・ 加瀬 直樹

株式会社東芝・ 神岡 太郎

一橋大学商学研究科

・ 今野 隆一

ジャパンシステム株式会社・ 齋藤 肇

日本海隆株式会社

・ 正田 塁株式会社オージス総研

・ 竹政 昭利株式会社オージス総研

・ 中原 俊政

バブ日立ソフト株式会社

・ 幅 洋平バブ日立ソフト株式会社

・ 日高 綱弘

日本インフォメーション株式会社

・ 藤野 博之NEC ネクサソリューションズ株式会社・ 吉田 亮日本アイ・ビー・エム株式会社・ 若林 良二

NEC ネクサソリューションズ株式会社

Copyright © 特定非営利活動法人 UML モデリング推進協議会 2007 All rights reserved62