財務会計システム FAST オフショア開発でのＵＭＬ適用事例インタビュー報告2009 年 12 月

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

ジャパンシステム株式会社
Copyright © 2009 Japan Systems Co.,Ltd All rights reserved
1

目次
開発の概要 ................................................................................ 3
UML/ガイドラインを使用したきっかけ .................................... 5
UML/ガイドラインの使用方法 ─ 使用した図とタイミ
ング/効果 ................................................................................... 7
UML/ガイドライン活用のポイント ......................................... 10
質疑応答 .................................................................................. 12
成功へのポイント .................................................................... 142

インタビューの内容
インタビュー日付：2009 年 8 月 25 日
インタビュアー：長田 真理亜 (一部 中原俊政、正田塁)
インタビュイー：鴨下 明

開発の概要
今日は、オフショア開発で UML を使用されたということで、お話を伺いたいと思います。まず、プロジェクト名を教えてください。
「地方自治体向け財務会計システムの改修と機能追加」です。
その中にはいくつかのプロジェクトが含まれているそうですが、オフショアに出した先の企業は変わってきているのでしょうか。
今回、複数プロジェクトを発注したオフショア先は、中華人民共和国の 1 社です。
仮に A 電子さんとします。これが中国の発注先ですね。
はい、そうです。
所在地はどこですか。
遼寧省の大連です。
どれくらいのお付き合いですか。
今年で 3 年目になります。
では、最初から 3 年間ずっと、地方自治体向けの改修をされているのですか。
はい。私の部門としては、この製品だけです。相手先も 1 社だけですし、私の部門としてオフショ
アに出している他の発注事案はありません。
その 1 製品について、A 電子さんにこの 1～19 の案件を発注されているということですね。
№

案件名

1

○○区予算執行

作業工程

2

〃

２次開発

3

〃

３次開発

4

5

○○区郵送料金○○区契約管理

6

〃

２次開発

7

〃

３次開発

製造・単体試験

8
9

〃

４次開発

○○区備品管理

10

〃

２次開発

11 ○○区財産管理

当社計画 BP実績
工数
工数（人月） （人月）

作業量

差異

作業期間

伝票修正

25 本

1.5

1.4

0.1 2008/6/16 ～ 2008/7/25

帳票新規

5 本

0.8

1.5

-0.7 2008/7/22 ～ 2008/8/22

0.5

0.5

0.0 2008/8/18 ～ 2008/9/12

1.5

1.7

-0.2

2008/7/7～ 2008/8/22

2008/7/8～ 2008/8/14

画面新規

1 本

帳票新規

7 本

伝票新規

1 本

画面新規

1 本

画面修正

2 本

伝票修正

30 本

1.5

2.5

-1.0

画面新規

3 本

2.5

2.4

0.2 2008/7/18 ～ 2008/8/28

画面新規

1 本

画面修正

2 本

2.1

2.3

-0.1

2008/8/1～ 2008/9/10

帳票新規

2 本
2008/8/8～ 2008/8/29

伝票修正

20 本

1.0

1.1

-0.1

伝票修正

7 本

0.4

0.6

-0.2 2008/7/14 ～ 2008/8/15

帳票修正

11 本

0.9

0.9

0.1 2008/7/22 ～ 2008/8/29

帳票新規

8 本

1.6

2.0

-0.4 2008/8/25 ～ 2008/9/26

12

〃

２次開発

帳票新規

3 本

1.2

1.2

0.0

13

〃

３次開発

帳票新規

6 本

1.2

1.3

-0.1 2008/10/10 ～ 2008/10/31

14 ○○区用品管理

帳票修正

9 本

15 ○○市予算執行

設計・製造・結合試験 伝票修正
（帳票設計除く） 帳票新規

12 本

16 ○○市契約管理
17 ○○市予算執行

製造・単体試験

3 本

伝票修正

18 本

設計・製造・結合試験 伝票修正
（帳票設計除く） 帳票新規

11 本

製造・単体試験（ﾃｽﾄﾊﾟﾀｰﾝ作成）

帳票修正

4 本

画面修正

5 本

製造・単体試験（ﾃｽﾄﾊﾟﾀｰﾝ作成）

帳票新規

2 本

一括修正

1 本

18 ○○市予算編成

19 ○○市行政評価
合

3 本

計

はい、そうです。
3

2008/9/1

2008/7/7～ 2008/9/30

0.8

0.6

0.1

2.1

2.2

-0.2 2008/11/25 ～ 2008/12/19～ 2008/8/15

0.7

0.7

-0.0 2008/11/25 ～ 2008/12/19

1.8

2.0

-0.2 2008/12/1 ～2009/1/9

1.3

1.3-0.0 2008/12/1 ～2009/1/9

1.0

1.0-0.0 2008/12/26 ～ 2009/1/23

24.2

27.0

-2.7

備

考

そうすると、最初のもので 2008 年 6 月から、至近のものは 2009 年 1 月 23 日ですね。
はい、その通りです。
対象製品の名前を教えてください。
「地方自治体向け財務会計システム」です。製品名は「FAST」で、「ファスト」と発音します。
開発工程について教えてください。
現状私の部署では、個々のお客様にパッケージ製品を適用するという形で各プロジェクトが走ります。つまり、もともとのパッケージ製品があり、お客様に実際にそのパッケージをお使いいただくに当たって、細かい個々の機能がお客様のお仕事に合っているかを確認するということが要件定義の工程になります。通常のプロジェクトであれば、色々な資料類やユースケース図等を使って「このようなお仕事の手順で間違いないですか?」という確認をお客様とすり合わせするかと思いますが、パッケージ製品の顧客適用の場合は、実際の画面の動きを見て、システム導入後の仕事進め方を想像していただきながら、打ち合わせを進めるという形になります。要件定義については、現在のところは国内で弊社プロパーの SE が担当します。
パッケージ製品として各業務処理は基本仕様ベースで完成していますので、本来の意味での基本設計の工程は通常は実施しません。要求定義からいきなり詳細設計に入ります。続く詳細設計の進め方のスタンスとして 2 種類に大別できます。パッケージで持っている既存の機能を部分的に改修するというケースと、機能的に不足していて、お客様がご予算のご用意が可能な場合に、その機能を新規に追加するというケースです。この 2 種類のケースに対する詳細設計については、現状ではほとんどが、まだ国内で弊社のプロパーSE が行っています。
当部門の場合、これ以降の工程からがオフショアの対象になるのですが、今のところ、オフショア
対象プロジェクトの内の 8 割くらいは製造と単体テストの工程を中国の A 電子さんに発注し、結合テストから後は弊社で引き受けるという形になっています。残りの 2 割については、詳細設計を含めてA 電子さんに依頼しています。現在は発注対象の工程を広げ始めているところです。詳細設計を発注
すると、通常は当然に結合テストも受注先が行う形になります。総合テストと現地の運用テストなど、テストの後半部分は、お客様先で実施しなければいけない工程となりますので、以降は弊社のプロパ
ーSE が担当する形になります。
役割分担についてもう一度確認させてください。要件定義はジャパンシステム様で実施されるのですね。
はい。要件定義については全て弊社で担当しています。
パッケージ製品のエンハンスは基本設計に影響しないため、基本設計の工程は実施しないのですね。
詳細設計の役割はどうですか。
現在はほぼ弊社の担当です。課題として、詳細設計もオフショア先に出したいと思っています。
将来的には詳細設計から A 電子さんにお願いしたいということですね。
はい。現状は 2 割くらいしかできていません。
製造・テストは全面的に A 電子さんに依頼されているのですね。
はい。発注対象サブシステムごとに原則製造とテストは A 電子に発注しています。
結合テストはどうですか。
結合テストは詳細設計とリンクしており、詳細設計を担当したところが結合テストをするというのが通常は効率的だと考えているので、同じような割合になります。
ということは、ジャパンシステム様でほぼ結合テストを行っていて、将来的には A 電子さんに移行したいということですね。
はい、そう考えています。双方の体制構築も含めて急ぎ対応すべき課題となっています。
総合テストについて最後に触れていただきましたが、こちらはジャパンシステム様が現地に赴いて実施されているのですね。
はい。お客様から稼動判断を頂かなければいけないので、どうしてもプロパーが担当する必要があると考えています。

4

では次に、オフショアを実施した規模について教えてください。基本設計は省いて、要件定義、詳細
設計、製造・テスト、結合テスト、総合テストについて教えていただければと思います。
中国側企業の方についてですが、発注全体で 27.0 人月です。
各プロジェクトごとの全体工数と中国側の工程別工数内訳は表をご参照ください。
№

1

案件名

作業工程

実績工数
詳細設計

工程別内訳
製造

伝票修正

25 本

1.4

1.4

2

〃

２ 次開発

帳票新規

5 本

1.5

1.5

3

〃

３ 次開発

画面新規

1 本

0.5

0.5

帳票新規

7 本

伝票新規

1 本

1.7

1.7

画面新規

1 本

4

5

○ ○区予算執行

BP実 績
工数
（人月）

発注作業量

○ ○区郵送料金○ ○区契約管理

6

〃

２ 次開発

7

〃

３ 次開発

製造・単体試験

8
9
10
11

〃

４ 次開発

○ ○区備品管理〃

２ 次開発○ ○区財産管理

画面修正

2 本

伝票修正

30 本

2.5

2.5

画面新規

3 本

2.4

2.4

画面新規

1 本

画面修正

2 本

2.3

2.3

帳票新規

2 本

伝票修正

20 本

1.1

1.1

伝票修正

7 本

0.6

0.6

帳票修正

11 本

0.9

0.9

帳票新規

8 本

2.0

2.0

〃

２ 次開発

帳票新規

3 本

1.2

1.2

〃

３ 次開発

帳票新規

6 本

1.3

1.3

0.6

0.6

帳票修正

9 本

伝票修正

12 本

15

○ ○市予算執行

設計・製造・ 結合試験
（帳票設計 除く）

帳票新規

3 本

16

○ ○市契約管理

製造・単体試験

伝票修正

18 本

17

○ ○市予算執行

設計・製造・ 結合試験
（帳票設計 除く）

伝票修正

11 本

帳票新規

3 本

製造・単体試験（ﾃｽﾄﾊﾟﾀｰﾝ作成）

帳票修正

4 本

画面修正

5 本

製造・単体試験（ﾃｽﾄﾊﾟﾀｰﾝ作成）

帳票新規

2 本

一括修正

1 本

18

19

○ ○市予算編成○ ○市行政評価
合

計

備

考

48.5

13

○ ○区用品管理

ﾌﾟﾛｼﾞｪｸﾄ
全体規模(人 月 )

79.3

12

14

結合試験

2.2

0.6

0.7
2.0

15.1

6.0
0.5

0.7
0.5

1.0

0.5

1.1

24.8

11.5

6.6

1.0

1.0

7.1
8.4

1.3

1.3

27.0

1.1

15.9

11.8
1.0

210.2

UML/ガイドラインを使用したきっかけ
では、ここからインタビューの中枢部分である UML の使用、その方法、成果、ポイントなどについて伺います。UML を使用したきっかけを教えていただけますか。
UML 導入の契機としては、弊社の上層部から UML を使って生産性を上げるよう指示があり、UML
関係の資料やノウハウをチームで収集、研究して、導入したことがきっかけです。
ガイドラインについては、先ほどの説明で、ジャパンシステム様が使っている JSTAD の開発標準と、オフショア UML 適用ガイドラインがうまく符合するということで、そのすり合わせをして実際の適用に臨んだとおっしゃっていましたが、ガイドラインを使用したきっかけとしてはそれでいいでしょうか。

5

２.ＵＭＬ導入に向けて（１）UML適用ガイドライン導入
弊社開発標準（方法論）

ＵＭＴＰ

ＪＳＴＡＤ
弊社開発標準オフショアＵＭＬ適用
ガイドライン

ＪＳ版
オフショア適用
ガイドライン

FASTカストマイズ作業の海外発注（中華人民共和国）①発注範囲（工程）の明確化。

④ﾊﾟｯｹｰｼﾞ原本資産の再整備②発注先の選定⑤工数見積（弊社側）③準備すべき資料の明確化と整備⑥発注先の口座登録と決済手順の確認
2009/ 2/17
All Rights Reserved , Copyright © ジャパンシステム株式会社 2009

ガイドラインを使用したきっかけも、上層部から UMTP を紹介され、ガイドラインのドラフト版の提供を受けたことを契機としています。そのときは Ver1.0 だったのですが、実際に弊社で持っている開発標準と、オフショアに向けてのチェックポイントを取りまとめていた WBS とをすり合わせして、
有効なところを使わせていただこうという方針で UML 導入に着手しました。
当初弊社で考えていた WBS に漏れている事項があれば補足するという視点もあり、その情報源として使用しました。
上層部のメンバーが UMTP のオフショアの分科会に参画させていただいており、比較的早いタイミ
ングでガイドラインを入手できましたので、その情報を個別のプロジェクトにも配布して、活用させていただきました。
[中原] 御社開発標準と比べて、モデリングに関してガイドラインの情報量はいかがでしたか。
表現や分類の違いはありましたが、8 割程度は弊社の必要事項を満たしていたと思います。
[中原] 2 割程度を追加したということですね。
そうです。「必ず UML である必要はない」というところは斬新でした。UML バージョン 1.1 の頃に別の大手ベンダーさんのお仕事で UML を使ったことがありましたが、総合的に導入すべきかと考えていました。その頃は UML をよく分かっていませんでした。このときはスクラッチの開発だった
のでユースケース図から始めたのですが、大枠の図を描いて、その下に説明文と称してダラダラと従来方式のように仕様条件等を書くなど、UML 本来の要点すら分からずにやっていました。それに対して、UML の利点を活かす形で導入するという意味では、ガイドラインの各項目に記述されている あ
たりまえのことも邪魔だとは感じませんでした。 私のように導入当初 UML のスキルが低かった者
から見ると、あたりまえのことも完結に記述していただいた方が、理解が正しくなります。 事例とまではいかなくても多少実務ベースに近い形の説明がガイドラインに記載されていることで、テキス
ト類（入門書や参考書）から理解した「UML はこうあるべき」の実践指針が間違っていないのだと再確認でき、安心できます。
ガイドラインに指針や、UML 導入の方向性に関して 22 の項目別に示されているという点からも、要点の抽出がしやすい構成となっているので一読で概要もつかみやすく参考になりました。
[中原] ガイドラインに不適切なところはありませんでしたか。
特には思い当たりません。
今のお話について少し確認したいのですが、当初ガイドラインをお使いの際、ご自身の UML のレベ
ルはどのくらいでしたか。
初心者でした。
6

UML 初心者の鴨下さんにとって、JSTAD とガイドラインをすり合わせる際に、ガイドラインが実務ベースに近かったので読みやすかった、それまで手探りでやっていたけれどガイドラインの中に指針や方向性を見出せたということでしょうか。
はい。以前に別の大手ベンダーのお仕事で UML を使ったときは、参考にすべきものが入門書、参考書とリファレンスしかありませんでした。ですから、これら参考書類に出ているサンプルくらいしか事例のダイアグラムが手元にありませんでした。
今回は、実務に近いサンプルが、資格取得用の問題集などに豊富に入っていることを知っていたので、そこから図の書き方などのスキルを身につけた記憶があります。個別のダイアグラムをどう書くかとか、文法がどうとか、こういうクラス図はいい/悪いということとは別次元で、プロジェクトを推進する上でこういう点に気をつけて導入すべき、といった通常のテキスト類（入門書や参考書）には比較的記載の少ない留意事項や指針の理由等がガイドラインの各項目に記述されていました。
上流のプロジェクトマネージャとして有効性等の判断しなければいけない項目に関わるヒントとなる内容が記載されていて参考になりました。
上流工程に関するところが役立ったということですか。
実際のプロジェクトで UML を使って、たとえばどの図を選んで先方に提供するか、先方にどの図をどのように書かせる、といったことを決定し先方と調整する際に、弊社としてどう指針を設定する
か検討する際の参考になりました。
UML をどのようにプロジェクトに導入していくかという部分ですね。
はい。UML のダイアグラムを描くスキルというより、UML をプロジェクトとして採用するにあたって留意なければいけない点が指針として示されているので、プロジェクトマネージャの立場として、
比較的安心してオフショアプロジェクト進める事ができたと思っています。

UML/ガイドラインの使用方法 ─ 使用した図とタイミング/効果
ここまで、UML とガイドラインを使用したきっかけ、ガイドラインのよかった点などを伺いました。
次に、A 電子さんとのやり取りで実際に使用したクラス図とそのタイミングを教えてください。
使ったのはクラス図、シーケンス図、ステートマシン図の 3 つです。詳細設計の内容を先方に伝えるために導入しました。
既存のパッケージ製品の設計を先方に知ってもらう必要があったので、そのときに 3 つの図を使ったということですか。
そうです。パッケージ詳細設計の基幹的な部分と改修対象の改修前の仕様がどうなっているかを知ってもらうのに必要な部分について 3 種類のダイアグラムを作って、それを先方に元資料として渡しました。

作成者は鴨下さんですか。
私ではなく、私の配下のメンバーです。

どのレベルのメンバーですか。
中堅メンバーで、サブリーダークラスです。
サブリーダークラスの方がクラス図、シーケンス図、ステートマシン図を詳細設計の時に作成して、中国側に渡したということですね。そのときのそれぞれの図の目的を教えていただけますか。
クラス図は、個々の部品プログラムがどういう構造で作られているかを理解してもらうために使いました。
それによってどのような効果がありましたか。
クラス図の導入効果は、各プログラムからそれぞれどんなサブプログラムが呼ばれているか、逆に、末端のプログラムがどの上位のプログラムから関連付けられて呼ばれているか、が明確に理解できることです。
7

シーケンス図を詳細設計で使ったときの目的を教えてください。
シーケンス図にはスコープがいろいろとあると思いますが、まずスコープを除外してお答えします。
ある 1 つのプログラムの中で各サブプログラムを呼び出すときに、プログラム間通信が行われます。
上位のプログラムが下位のプログラムに対して「××をしなさい」という命令を投げ、下のプログラ
ムは「命令を受けた結果」を上に向かって返す、という動きです。その命令が何をトリガーに発行されるか、命令を受けて処理した結果をどのように返すか、というやり取りの関係を明記します。それが 1:1 から 1:N になった場合や、階層が 2 階層から 3 階層になった場合にも、それぞれ同様の関係があります。これらそれぞれの場合に応じて、呼ぶ/呼ばれる、どういう答えを返す、といった処理の順
番を意識した時系列的なタイミングを明確に記載できるのがシーケンス図の導入効果です。
[中原] シーケンス図を書くと作業量が大変なことになると思いますが、複雑なクラス間のシーケンス
図を書くときに何か工夫をされましたか。
多少工夫しました。いったんは、あるブロックについて全部書くように指示をしたのですが、期限を経過しても仕上がってこないので状況を確認すると、ミクロフォーカス的に延々と作業をしていたのでブレーキをかけました。
以降はスコープ条件を設定させて、一定階層以降をブラックボックス化することとしました。先ず 3階層までに限定して概要レベルの図を書かせました。ところが、3 階層に限定すると、シーケンス図として役に立たないものになりました。細分化されすぎていてドキュメントの沢山のページを渡っていかないと全体を理解できないので、シーケンス図の意味を持たないものとなってしまいました。
そこで、必要となるクラスグループのブロックをクラス図の中で経験的に切り出して、それに関していったんシーケンス図をざっくりと書いて、深くなる部分はブラックボックスにして止めるようにしました。
おおまかなシーケンス図を書いて、細かく枝分かれしていくところは抜き出して別にシーケンス図を書いたということですか。
はい。私たちは当初作図の経験が少なかったために失敗をしたのですが、いったんはざっくりとした記載で止めて、レビューをしながら最適な粒度を割り出していく方法でしかまとめられませんでした。品質に関わる重要な部分については、スコープを変えて切り出しながら書いていくのが現実的には良いと思います。
これは既にあるシステムについて図を作成する場合です。スクラッチ開発のケースで UML を導入する場合は、基本的な部分や処理の錯綜が予想できる箇所について優先的にシーケンス図を作成して、極力整合性を明確にしておくことは設計品質の確保につながると思います。
また、当初想定外の成果として、今回は１件だけでしたがシーケンス図を書くことによって障害を発見することができました。
[中原] まずは概略を作って、あとはレビューしながら必要なところを書いていくということですか。
はい。それが良いと思っています。
では次に、ステートマシン図の目的を教えてください。
ステートマシン図は、あるプログラムが何をきっかけにどういう順序でどんな処理を実行するかを、
比較的フリーな形で各処理単位にボックスを設けて、その関連を記述していく図です。ある機能が、何をトリガーとして、どの条件の時に、どんな処理を実行するのかを、時系列に関係なく記述します。
（開始、終了、と条件別の処理内容を記述します）
それもサブリーダーの方が書かれたわけですね。同じ方ですか。
着手当時に L2 の資格を持っていた人が 2 名いたので、そのメンバーを専任にして書かせました。
クラス図、シーケンス図、ステートマシン図それぞれを別の方が作られたわけですか。
担当リーダ皆が 3 種類の図を書きました。
ステートマシン図を実際に使って、どのような効果がありましたか。
それぞれの部品のプログラムが何をトリガーにどういう動きをするかを図で表しているので、処理の全体像が一目で理解しやすいという点です。
工夫された点は何かありますか。

8

ステートマシン図は従来のフローチャート図に近いので、従来型の仕事をしていたメンバーも、ス
テートマシン図の文法を覚えるだけでかなり深く（的確に）理解、作図することが可能となりますので、比較的導入は容易でした。もちろん、ステートマシン図も全部を書こうとすると多くの労力がかかりますので、どの部分をステートマシン図に落とすかの選択に注意が必要でした。
先ずは設計全体の中で出現頻度の多い典型的な処理について一連の処理セットの開始から終了までを作図対象として選定しました。
次に作図対象として、過去に新任メンバーがよく誤解して障害等を起こしがちな部分をピックアッ
プして対象箇所として選定しました。このケースは作図対象を徐々に増やす事ができますが、ある程度ソースレベルまで読み込んだあとに補足的にダイアグラムを見るようにしないとダイアグラム自体を理解しにくいかと思います。
とはいえ、ステートマシン図については、フローチャートに近いダイアグラムなので、間違いなく
発注先に伝えなければならないのはこの部分だという絞り込みに、担当 SE とレビューアーでズレがほ
とんど無く、すんなり導入できました。 特殊な工夫をしたという記憶がありません。
実際の効果としては、フローチャートよりも表現できる範囲が少し広いので、フローチャートを描くくらいならステートマシン図を描いた方が、同じ労力でも正確に仕様が相手方に伝わると思います。
[正田] この 3 つの図はすべてジャパンシステム様で書かれていて、中国側はそれを読んで理解するだ
けということですか。
そうです。ただ、昨年の後半の何本かのプロジェクトでは、新規で作成する機能について何枚かス
テートマシン図を作ってもらいました。成果物を UML で書いてもらうことにはまだ本格的に着手していないので、今年も含めてその形を増やしていきたいと思っています。
[正田] その場合には中国側で書かれた図を日本側でレビューするということですか。
はい。少しづつですが中国側にも設計工程を発注していますので、その際に担当リーダが必要と判断した場合はステートマシン図やシーケンス図を作成させます。中国側で作成した図は当方のレビュ
ー承認後に次工程へ進むよう指示する手順となります。
今のところは、ジャパンシステム様でクラス図を作成して、A 電子さんがそれを読んで理解すると言う状況ですね。
はい、大半はそうです。確実に実績があるのはジャパンシステムで作図して先方に渡すというところにとどまっています。
それは詳細設計の部分ですね。実際に A 電子様がこの図を使うことで効果があると感じたことはありますか。
初回にクラス図もシーケンス図もステートマシン図も部分的に作成したのを用意して先方に説明した際は、実際にプログラミングを担当する方が 7、8 名の出席でした。彼らは、ドキュメントに日本語を書くことはできるけれども、会話はできないというレベルの日本語力であったのですが、仕様説明の冒頭から、「なぜこういうクラス構成になっているか」というような、クラス図の意味合い自体は正しく理解したうえでの、質問をしてきました。
パッケージ製品といっても、お客様から改修の要望がよく出てきがちな部分があります。スクラッチでの構築の場合なら動作の効率や処理の汎化などを考えるかと思いますが、パッケージの場合は、「この部分の仕様はお客様によってかなり要件が違う」という箇所があり、一見非効率でも、あえてその部分を別のクラスに引き継がせて後で入れ替えるような作りをする部分があります。そのため、出来上がっているプログラムだけを見ると、多少奇異な感じがする箇所があります。そういった部分について、何故そうなっているのかという質問を受けましたので、「この人はダイアグラム中の仕様を正しく解っているな」という印象を受けました。従来型の設計資料を渡した場合には、おそらく今回と同じ様な短い時間でここまでの理解はされなかっただろうと思いました。
従来型の設計資料よりも、UML を使ったクラス図などの方が、日本語が不得意な中国側の SE にとっても理解しやすいということですね。
母国語が違うということが障壁になりにくいのだと思います。
その他に成果はありましたか。
ステートマシン図には処理に関する動詞や名詞が記述されるのですが、各 PG にダイアグラムを渡すにあたってその翻訳が必要です。この際、図の中に表記されているものが基本的に単語/熟語のレベ9ルなので、資料を中国語に翻訳する作業は無償で先方がやってくれました。初回訪中時はステートマ
シン図が 25～26 枚くらいだったのですが、先方の日本語ができるメンバーがおそらく 1 日で翻訳できるだろうということで、特に翻訳についての経費はかかりませんでした。従来型のドキュメントなら、翻訳に経費がかかる上、ニュアンスは伝わらず問題が起きていたと思います。そもそもニュアンスが入っていること自体が設計書として問題があると思います。比較はできていませんが、UML の導入によって曖昧さ排除の効果があったのだと思っています。
[中原] 従来のドキュメントとは具体的に何を指していますか。
機能概要書などです。
[中原] たとえば DFD などだと変わらないようにも思うのですが。
DFD なら同じかもしれません。私の知っている範囲では、中国語は英語の語順に近いですね。そのためか比較的白黒はっきりしているので、日本人のように仕様書の行間を読んでくれなどということは通用しません。中国だからというより、日本以外、グローバル標準的にそうだと思います。設計書に書いてあることはやるが、書いてないことはやらないという姿勢で仕事を進めます。そういう意味
でいうと、文章表現の設計書はトラブルの元だと思います。ですから、ビジュアルドキュメントである UML をどんどん導入すべきだと思っています。
[中原] 成果として質問の質がよかったという話がありましたが、後工程での品質やバグ密度などについて、感覚的にでも効果はありましたか。
UML を最初から使ったので、使ったときと使っていないときとの比較ができていません。
[中原] 逆に、UML を使わないで、質問のやり取りがひどく大変だったとかトラブルが生じたという
プロジェクトがよくあるのですが、そういうトラブルはなかったのですか。
今の所は発注範囲が限定的であることもあり、トラブルと言うほどの問題は発生していません。
先ほどの説明には含めませんでしたが、このシステムは VB で作っているため、発注先にプログラ
ムスキルが付いてきた後は、ドキュメントを省略して、「このサンプルでよろしいでしょうか」というように VB のプログラムで返してくることが増えてきました。VisualStudio の開発環境はとても充実していますので、システムの大筋が分かってしまえば、直接プログラムのソースのサンプルをやり取りすることは仕様確認の範囲であれば有効な方法です。当初はステートマシン図を介して要件の確認等をしていましたが、あまり形式だけに拘ってしまうと効率を下げるケースがありますので留意が必要でしょう。発注内容が新規か改修か、また規模や段階（仕様伝達段階か、実装方法の質疑応答段階か）によってはサンプルソースを使うことも、ケースや状況によっては正解となりえるものと認識しています。

UML/ガイドライン活用のポイント
UML 活用推進に向けてのジャパンシステム様の課題として、先ほどの発表の中に 3 点挙げられていましたが、それを含めて、今後の活用に向けて、ポイントを教えてください。

10

３ .ＵＭＬ導入の効果(２)UML活用推進に向けての弊社課題

ツールの導入を改めて検討する。
ツールの導入を改めて検討する。
顧客との仕様打合せへの導入を試行する。
顧客との仕様打合せへの導入を試行する。

実務を経験したメンバーがリーダ級メンバーの半数の状況なので、担当の横展開を実務を経験したメンバーがリーダ級メンバーの半数の状況なので、担当の横展開を推進する。
推進する。 メンバーローテーションの実施
メンバーローテーションの実施
UMTP
資格の取得推進を進める。 ※現在※現在 L1
UMTP 資格の取得推進を進める。
L1：：60%60% L2
L2：：20%20%
現状
現状 最小限の図を導入しているが今後は発注内容が高度になるに応じ、発注先と最小限の図を導入しているが今後は発注内容が高度になるに応じ、発注先とも合議して有効な図を厳選して導入する。
も合議して有効な図を厳選して導入する。
2009/ 2/17
All Rights Reserved , Copyright © ジャパンシステム株式会社 2009

弊社の課題をふまえての今後のポイントについては、先ほどの正田さんからの質問と重なりますが、まだまだ一方通行で、弊社のパッケージシステムの改修前の仕様を説明するためにしか UML を使っていません。設計の工程も含めてオフショア先に依頼できるようにしないと、オフショア対象の業務量の上限が低くなってしまうので、発注工程を広げなければならないという課題があります。この課
題をクリアする過程として設計段階が終わった中間の成果物を UML で納品してもらい、レビューを実施する必要が出てくると認識しています。
また、UML に関して言うと、今導入しているのはベーシックな 3 種類の図だけで、たとえば配置図なども場合によっては必要になると想定していますので、対象のダイアグラムの種類を増やしていき
たいと思っています。目的はあくまでもオフショア対象の工程範囲を広げるためです。
UML とガイドラインを使用したことを概観して、今回のやり取りの中でのポイントとして PR するものはありますか。
UML の採用を検討しているプロジェクトでも、使える経費の範囲内でダイアグラムを選んで導入できるか否か がポイントだと思います。まずはパイロット的にでも UML を使ってみて、効果を体感しながら導入してもらいたい。部分的導入も可能ということで、それが可能である点も良いところだと思います。
[中原] ガイドラインに対して、こういった内容があればいいなどの要望はありますか。
私の場合は導入当初はサンプルの情報が一番欲しかったものでした。
ガイドラインの中に入れるのは構成上難しいですし、サンプルのダイアグラムに馴染まない項目もたくさんあると思いますが、テクニカルノートのような別冊のサンプル集があると導入検討しやすい
かと思います。上流工程のメンバーには今のガイドラインの内容で十分役に立つと思いますが、具体的にどのダイアグラムをいつまでに作成するのかを検討するサブリーダーレベルの方にはサンプル集があると判断がしやすいと思います。UML の経験が少ないメンバーでも方針判断ができるように、事務系、制御系、学術系など、主だった分野のダイアグラムが別冊のサンプル集としてあると良いと思います。ISO のテクニカルノートのようなイメージです。想定した業務サンプルとそれに対応するクラス図や、処理想定とそれに対応するステートマシン図のように、キーワードで分野が選べるようになっていると良いと思います。というのも、私の場合 L2 資格試験向けの問題集サンプルが当初非常に参考になったからです。具体的な例が含まれていて、設問を要件、回答例がサンプルダイアグラムとみなした場合、要件と成果物の両方が揃っているので理解を深めるのに役にたちました。
当然ですが、リファレンスは UML の何たるかは理解している人が文法の確認をするために使う形が本来的なものだと思いますので導入当初の段階では参考にはなりにくいと思います。
11

質疑応答
質問者：中原俊政、正田塁
回答者：鴨下 明[中原] 工程会議などで進捗をフォローした頻度はどのくらいですか。
製造工程の進捗確認は、結構粗くて、週次で済んでいました。スライドで少し触れていますが、進捗報告のところです。
２ .ＵＭＬ導入に向けて（４）コミュニケーション方法の確立
オフショアベンダーの選定と契約

プロジェクトの準備

プロジェクトの実施

プロジェクト
の評価

改善施策
の実施

コミュニケーションの良否がプロジェクトの成否左右する
参考事例：コニュニケーション規定
No.
内容
1 進捗報告ドキュメント
進捗報告書
予実管理表
問題管理台帳方法
メ ー リ ン グ リ ス ト 、T V（電 話 ）会 議

頻度
週次

備考
進 捗 の メ ト リ クス は 事 前 定 義 、周 知 。
TV 会 議 設 備 整 え な い 場 合 は S K Y P E※
代 替 可。

2 仕様伝達設計書
補足資料

現 地 説 明 、T V（ 電 話 ）会 議

適宜

仕 様 説 明 完 了 後 は Q A管 理 に 移 管 。

3 Q &AQ A管 理 表
設計書
補足資料

メ ー リ ン グ リ ス ト 、T V（電 話 会 議 ）日次

口 頭 で の 回 答 禁 止 、但 し、 確 認 レ ベ ル
は 可 とす る。

4 試験状況

試験項目消化予実管理表

メー リング リス ト

日次

5 故障処理故障処理票

メー リング リス ト

日次

6 仕変対応設計連絡票

メー リング リス ト

適宜

7 そ の他

－

臨機応変

随時

リアル タイム の 確 認 事 項 。

フェイス トゥフェイス コミュニケーションについて
プロジェクト開始直後や工程の開始・終了等の重要な局面においてはJS技術者の現地滞在あるいは現地SEの来日も検討する。
2009/ 2/17
All Rights Reserved , Copyright © ジャパンシステム株式会社 2009[中原] オフショア側では日次で、国内との会議を週次で行っていたということですね。それで特に問題はありませんでしたか。
はい。オフショア先が優秀だったことが大きいですが、最初の 2 週間くらいは月水金で状況確認を実施していましたが、「順調」という報告と、質問内容もしっかりしていて作業精度も高いと評価できたため、週次にサイクルを変更しました。最初は質問が非常に多かったので、逆に安心した記憶があります。サブリーダーは最初の 2 週間、毎日 20～30 件もの質問にメールで返答していて、苦労していました。
[中原] 質問の内容にもレベルがあると思うんですが、よく分かっている質問が来たということですか。
そうです。8 割くらいは内容をよく分かっている質問でした。2 割は的外れな質問もありましたが、人に問題があったようで、その人を外してもらった後は非常に順調でした。ただ、初回はエース級のメンバーを充ててくれているはずですので、2 年目、3 年目と逆に留意する必要があると考えています。
[中原] 次に、仕様変更についてお伺いします。通常、業務アプリケーションですと、仕様変更で結構トラブルがあるのですが、パッケージのカスタマイズの場合は、そういうトラブルはあまりないのですか。
仕様認識の齟齬による大きな問題は今のところ発生していません。まだ内容浅いというか、比較的
誤解のしようがない発注内容のためだとご理解ください。
[中原] 仕様が膨らんでくると、見積もりなおしをするようなことはありませんでしたか。
見積りなおしは 2 回くらいありました。
[中原] それで納期が遅れるなどのトラブルはありませんでしたか。
今回は少なかったです。通常は見積もりなおしをする時点では納期も危なくなります。今回は、もともと安全を見たスケジュールで発注していたので、たまたま収まったともいえます。
12

中国も今年は仕事の絶対量が減っているようで、投げやりな成果物にはなったりはしていません。
オリンピックイヤーと同じような好景気が続くのであれば注意が必要かもしれません。プロジェクト
管理者は中国に限らず常に疑ってかかる必要があるかと思います。
[中原] UML 導入の課題のスライドですが、資格取得の推進について、現在は L1 が 60%、L2 が 20%と結構高いのですが、目標はどのくらいに置いていらっしゃいますか。
３ .ＵＭＬ導入の効果(２)UML活用推進に向けての弊社課題

ツールの導入を改めて検討する。
ツールの導入を改めて検討する。
顧客との仕様打合せへの導入を試行する。
顧客との仕様打合せへの導入を試行する。

実務を経験したメンバーがリーダ級メンバーの半数の状況なので、担当の横展開を実務を経験したメンバーがリーダ級メンバーの半数の状況なので、担当の横展開を推進する。
推進する。 メンバーローテーションの実施
メンバーローテーションの実施
UMTP
資格の取得推進を進める。 ※現在※現在 L1
UMTP 資格の取得推進を進める。
L1：：60%60% L2
L2：：20%20%
現状
現状 最小限の図を導入しているが今後は発注内容が高度になるに応じ、発注先と最小限の図を導入しているが今後は発注内容が高度になるに応じ、発注先とも合議して有効な図を厳選して導入する。
も合議して有効な図を厳選して導入する。
2009/ 2/17
All Rights Reserved , Copyright © ジャパンシステム株式会社 2009

弊社経営層からは基本的に、L1 は SE 全員が取るようにと指示されています。ですが、それはなかなか難しいので、当面、私の部門の今期の人事考課上の目標は L1 が 80%として、対象者を指名して必ず取得するように指導しています。L2 は 30%を目標にしています。L3 は、5%を目標としています
が、まだ 1 人しかいません。
[中原] 全員に取らせようとすると、かなりの投資が必要ですね。
そうですね。予算を取って、バウチャーを先着 50 人に割引で分けるようなことを実施しています。
他にも資格手当てとして一時金を出しています。それよりも、私が L2 を取ったのが効いているかもしれません。「上司に先に取得されてしまったので仕方がない…」といったプレッシャーは有効なようです。
[中原] 資格を取らせても、そういう仕事がなかなかないと、取らせるほうの立場がないですね。
それはあります。事実「取れ取れと言った割にはそんなに仕事がないじゃないか」とは言われています。ここは問題です。オフショアのレベルを上げて、プロパーの SE は上流工程だけにシフトしようという目標設定は良いのですが、実務配置を十分に推進できていない点は課題です。
個別のプロジェクトで見ると、まだまだオフショアを怖がっていて、自分の手元でやったほうが安心感があるようです。常識的な納期で受注できればいいのですが、最近はお客様も業者選定が慎重であったりするため業者決定が 1 ヶ月、2 ヶ月、遅れるような事例が多くあって、工期が短くなっています。そんな関係もあって、注文が取れたのは良いが、改修の期間が 3 ヶ月しかないというような仕事が多く、オフショア実施の準備が間に合わないので二の足を踏んでしまうことも多くあります。プロ
ジェクトが細かくなりがちなのが私の部署の今年の傾向です。
[中原] 全体のうちで UML を適用する業務の割合はどのくらいですか。半分以上あれば資格も取らせやすいですが。
1 割くらいです。私が在籍しているパッケージ製品を扱っている部隊よりも、中央の公官庁や銀行などのお客様の方が概してロットが大きいので、そこで UML を導入できると良いのですが、規模の大
きいものはなかなかフロントで受注できず、他社の二次請けで入ることが多くなっているという事情があります。この場合、開発手法を弊社側で選択することができません。
13このためプロジェクト推進の基本指針を自由に決められるということで、どうしても自社パッケージの部隊に指示が下る形になってきます。これらが当社の課題となっています。
[正田] オフショア開発評価シートの UML の導入評価という項目がありますが、これはもう少し詳細
化されていますか。
２ .ＵＭＬ導入に向けて（９）ＢＰ評価について
オフショアベンダーの選定と契約

プロジェクトの準備

プロジェクトの実施

プロジェクト
の評価

改善施策
の実施

オフショア開発評価シート（参考事例）
N o
1

大 分 類
品 質 評 価

2

中 分 類
総 評
バ グ 摘 出 件 数

3
生 産 性

ＪＳ 基 準 との 比 較
規 模 （FP又 は K LO C）

7

工 数 （人 月 ）コ ス ト 削 減 効 果

89ＪＳ 基 準 との 比 較
発 注 単 価発 注 金 額1011

発 注 予 算発 注 実 績ス ケ ジ ュ ー ル 評 価

総 評
計 画 と実 績 の 差 異

13
14

採 点

受 入 中
コ ス ト 評 価

612

評 価 内 容納 品 物 （ ドキ ュ メ ン ト /日 本 語 ）

4
5

小 分 類

開 発 中

プ ロ ジ ェク ト 管 理

仕 変 管 理進 捗 管 理15

品 質 管 理16

リ ス ク 管 理

1718

Ｕ Ｍ Ｌ図 の 導 入 評 価

19

コ ミュ ニ ケ ー シ ョン 評 価

20

開 発 コ ー デ ィ ネ ー タ評 価

21

見 積 精 度 ／ サ ー ビ ス

22

全 体 評 価23

今 後 の 課 題

2009/ 2/17
All Rights Reserved , Copyright © ジャパンシステム株式会社 2009

現状はしていません。
[正田] その評価ポイントがあれば、それが次の人のためのいいサンプルになるかもしれませんね。
今回のインタビューは以上とさせていただきます。
皆さん 長時間にわたりご苦労様でした。

成功へのポイント●UML を適用する場合、プロジェクトのメンバーのスキル、経費等を考慮し、その範囲内で 導入可
能なダイアグラムを選択するのがよい。
●いきなり本番適用ではなく、パイロット的に UML 使って効果を体感しながら導入するのがよい。

14