生化学検査機器ソフトウェアの再構築での UML 適用事例
インタビュー報告2010 年 8 月

特定非営利活動法人 UML モデリング推進協議会
オフショアソフトウェア開発部会
Copyright (C) 2010 特定非営利活動法人 UML モデリング推進協議会 All rights reserved
Neusoft Japan 株式会社
Copyright (C) 2010 Neusoft Japan Co., Ltd. All rights reserved

1インタビューの内容
インタビュー日：2010 年 4 月 12 日
インタビュアー：サザーランド真理亜 (一部 中原俊政、鴨下明、藤野博之、竹政昭利)
インタビュイー：Neusoft Japan 費如良 (一部 呼輝)

イントロダクション[中原]
UMTP のオフショアソフトウェア開発部会では、オフショア開発に UML を適用して効果を出そうという目的でガイドラインを作っています。現在、ガイドラインを使った事例を集めている
ところなのですが、御社は UML を使った事例があるということを伺い、今回インタビューをお願いした次第です。よろしくお願いします。
[呼]では、まず弊社について簡単に紹介します。中国系の会社で、親会社は中国東北大学のある研究室の先生が立ち上げた企業です。今はグループ会社全体で 16,000 名弱の社員がいて、インテグ
レーションを専業でやっています。Neusoft Japan は 2003 年に日本で設立し、現在で社員数が250 人弱、そのうち 100 名ほどが中国から転勤してきたもので、残りの 150 名は日本採用です。
事業内容はオープン系と組み込み系を 2 つの柱としていて、私と費が所属している第一システ
ム事業部は、組み込み系の開発をしています。
Neusoft Japan は基本的にオフショアを中心にやっていまして、日本のメンバーがお客様のところに常駐するなどして請け負った仕事を中国に渡し、実際の設計から実装、検証までをやってもらって、その成果物をブリッジ SE（以降 BSE と略す)経由でお客様に納品する、という流れになっています。
今回ご紹介するプロジェクトは、弊社の費が担当したもので、プロジェクトについては費が回答させていただき、私が補足させていただきます。

プロジェクト概要
プロジェクトについて
まず、あらかじめアンケートで基本情報として頂いた内容に沿って進めさせていただきます。
今回 UML を使った事例のシステムは、生化学検査機器のソフトウェアの再構築ですね。そのプロジェクトでの費さんの役割を教えていただけますか。
基本的に BSE として、お客様から仕様と設計を受け取ってオフショア先の中国に伝え、中国で実装した納品物をチェックしてお客様に出すという、ブリッジの役割をしています。
プロジェクトの内容は医療介護ということですね。
検査用の医療機器です。
システムの処理形態は組み込み系ですね。

2

このプロジェクトは 2 つの子プロジェクトに分かれています。1 つは組み込みで、基盤は Vｘ
Works の OS を使った専用のプログラムです。もう 1 つは、データを PC に上げて処理し、ユーザー操作のインターフェイスを提供する PC ソフトウェアです。
対象システムの構築形態は、新規ですが現行システムの再構築だと伺っています。
C 言語で構築されていたお客様の旧システムを、今回はオブジェクト指向の C++で再構築しました。
以前の C 言語のシステムは Neusoft さんで作られたものですか?
違います。お客様が作られたのか、そのあたりはよく知りませんが。
新規のお客様ということですね。プロジェクトの予算規模は数億円で、開発期間は 24 カ月以上ということですが、実際にはどれくらいだったのですか?
2007 年の 4 月から 2009 年の 5 月まで、2 年ほどです。
プロジェクトの特徴的な部分を教えてください。
基盤制御と PC の UI 作成の 2 つの子プロジェクトに分かれていることです。
オフショア先について
オフショア先は中国ですか。
はい、Neusoft 本社です。
オフショア先の規模は中国のトップクラス規模の企業ということで、実際に日本側と中国側の体制は、どれくらいの割合だったのでしょうか。
Neusoft Japan 側は私と上司の 2 人です。Neusoft 本社の体制は、作業内容により 2 年間の間で上下しましたが、大体は 10 名ほど、最大で 20 名ほどでした。我々が行ったのは基本的に実装とテストで、設計はお客様側で 10 名くらいでされました。
お客様とのやり取りは日本語でされて、中国側とのやりとりは中国語だったのですね。
はい。仕様などすべての文書は日本語でした。
中国側の 10 名の方も日本語の仕様を読まれたのですね。
はい、読んで実装していました。
[中原] 開発スケジュールが 2 年となっていますが、実際のオフショア先の作業が 2 年間だったということですか?
そうです。設計が出てこないなどで 1 ヶ月ほど作業が空くこともありましたが、基本的にはオ
フショア先で 2 年間です。
[鴨下] 契約形態についてお答えいたただける範囲で教えて欲しいのですが、お客様は具体的に設計工程のどこまでを担当されたのですか? UI 工程までなのでしょうか?
UI は、機能仕様をお客様から貰って実装しました。制御の方は特別なロジックがあるので、そこはシーケンス図まで提供してもらいました。
[鴨下] 詳細設計や内部設計までお客様が担当された部分があるということですね。今回のプロジェクトの契約窓口が Neusoft Japan 様であり、中国の本社が実装の工程を担当するスキームとのことですが、中国本社との間に契約関係はないと考えてよいですか?

3

[呼] 日本国内のお客様に対しては、法律や税金なども関係するため、ほとんど Neusoft Japanを経由して契約しています。Neusoft Japan で人数や工数などをお客様と相談した上で、契約をしています。Neusoft グループ内部では、日本側と中国側とでまた弊社内部の契約を結んでいます。お客様にとっては Neusoft Japan が契約の相手であり、もちろんお客様向けの窓口ともなっています。
[藤野] 最初から全体の規模を見積もって、最後まで一括で契約されているのですか。それとも 1
つ 1 つの作業ごとに契約されているのですか。
[呼] 2 年先までは見えにくいので、3 ヶ月または半年の期間ごとの契約が主です。その 3 ヶ月でどの程度の工数がかかる、という見積もりを詳細に出しています。
[費] 今回のプロジェクトでは、イテレーションごとに分けています。お客様が一部設計をしたものに対して、こちらで見積もりをして、その回の作業分を契約します。そして、次のイテレー
ション分を再度契約する、という形で進めています。
[藤野] 全体で 2 年間だが、1 つの作業に関しては 3 ヶ月などでテストや受け入れ検査まで終わるという繰り返しですね。前の作業と後ろの作業との関連性はあるのですか?
[費] 不具合の対応はしますが、基本的には分けています。
[呼] 機能ごとに分かれているので、終わったら次の機能に進むという感じです。バックグラウ
ンドは同じですが、機能はまったく新しいものです。
[鴨下] ウォーターフォール的な工程の単位で発注されているのではなく、たとえば 3 ヶ月のス
パン等の期間ごとに発注対象機能を決定しながら進められているということですね。
[呼] そうです。
[竹政] 基盤制御と PC の UI の作成との比率はどのくらいですか?
PC の UI が 60%くらいで、基盤の方はベースとなるソースがあるので 40%くらいだと思います。

UML 活用状況「オフショア向け UML 適用ガイドライン」について
続いて、UML ご活用状況についてお尋ねします。「オフショア開発向け UML 適用ガイドライン」は、存在をご存じなかったということですね。
はい。
UML を採用した工程
オフショアプロジェクトの実施の際に UML をどの工程で採用されましたか?
基本的には、このプロジェクト全体で UML を使いました。お客様の方では、UML のユースケース図で要求分析をし、その後でクラス図とシーケンス図まで作成しています。実装側では、お客様が設計したクラス図とシーケンス図を使って実装とテストを行いました。
要件定義、基本設計、詳細設計の工程はお客様が担当され、製造、結合テスト、総合テストは実装側で行いました。
上流の工程はお客様が担当されていて、システム設計を下流工程に伝えることが大切だと感じられたのですね。そのときのメリットはどのようなものがありますか。

4

今回は組み込みで、機器にたくさんのデバイスがあり、特別のロジックがあります。そのため、実装側はそのロジックをよく理解できていません。ですから、お客様が元のベースソースを分析して、シーケンス図を使ってクラスのメソッドの呼び出し順まできちんとロジックを記述し、実装側はシーケンス図に書かれたロジックを実現する、という進め方になっています。
このロジックがきちんと書かれているので、シーケンス図どおり間違えないように実装すれば、お客様の設計に合っていることを確認できます。
お客様が UML をよく使っていられたようですが、UML を使うことはお客様からの希望ですか?
はい。お客様が決めたことです。
費さんの側では製造工程から総合テストの工程までで UML を使われたのですね。
はい。お客様の UML は 100%正しいわけじゃなかったので、矛盾する部分があった場合には実装側で追加や修正などもしました。
UML を使用したきっかけ
先ほどのご回答と重複しますが、UML を使用したきっかけは何ですか? Neusoft さんも何年か
前から導入されていたのですか?
Neusoft 本社では基本的に UML を設計ツールの一つに採用していて、社内での研修を行っています。組み込み開発のチームは基本的にみんな UML の経験があります。今回のプロジェクトでは、お客様も何年も前から UML を導入されていたようで、両方で経験があったわけです。
本社で行っている UML の社内研修は、どれくらいの期間でどのような内容なのですか。
[呼] 本社の方も事業部やチームが分かれていて、費が担当したオフショア側がたまたまその研修を受けていたのですが、他の部署は、基礎教育として入れているところもあれば、使っていないところもあります。ただ、私が見ているいくつかのプロジェクトでは、クラス図、ユースケー
ス図、シーケンス図くらいの基礎知識は持っていて、それを使ってお客様とコミュニケーションを取っています。そこまではできますが、今回のプロジェクトのようにすべて UML でというケースはそれほど多くないのが実情です。
基本的に Neusoft Japan や本社の社員の方は、何らかの形で基本的な図は勉強されているということで、費さんのプロジェクトはたまたま UML の研修をしっかり行っている部署と仕事をされたということですね。どういった部署か、お伺いしてよろしいでしょうか。
本社の瀋陽の部隊なのですが、日本語を使ったオフショア作業も 10 年ほど経験があるようです。
UML の研修をいつ頃からしているかは知りませんが、他のプロジェクトでも UML を使ったことがあるようです。
費さんも研修で UML を勉強されたのですか?
[費] このプロジェクトの 2 年ほど前にも、小さなプロジェクトで UML を使ったことがあります。
[呼] 弊社には基本教育があって、需要がなくても日本語や技術などを自主的に定期的に勉強させているのですが、それ以外に潜在的なお客様のニーズを捉えて、UML をこれから使おうというプロジェクトなど、必要だと考えた場合は集中的に特定のトレーニングをすることもあります。
不定期に行っている研修は、大体どのような形態でしていらっしゃるのですか?

5

[呼] それは、我々とは直接かかわりのない中国側の別の部署でやっていることなので、管理していませんが。こちらからは、たとえば"これから Android をやるから Android の教育を受けてください"だとか"UML をやってください"という要望は出しますが、それをどこまでやるかは干渉できません。
研修部門が提供するものをみなさんが受けていらっしゃるのですね。
[呼] はい。Neusoft は大学を基にした企業なのですが、企業になってから Neusoft 本社が大学
を 3 つくらい作っていて、学生が 2 万人くらいいます。主に IT 関係のトレーニングや教育をしたり、実際にやらせたりしているので、リソースは豊富です。教育や特別の技術などが必要な場
合には、自分の大学でもやっていますし、外部から講師を招くこともできます。
すると必要に応じて研修ができて、お客様のニーズに合うように備えていらっしゃるのですね。
[呼] はい、そういうやり方で進めています。
費さんもお客様と対応するときにそういう集中的な研修を受けられたのですか。
私がこのプロジェクトに入ったときは、プロジェクトが既に始まっていたので、仕事をしながら勉強をしているのですけれど、2、3 週間の研修は受けました。
UML を使ってうまくいった点
では、UML を使ってうまくいった点はどのようなものがありますか?
[費] オフショアでは設計部隊と実装部隊が別々になっています。日本側と中国側で理解が異なることがいないよう、設計側の仕様を実装側にきちんと伝えるように UML を使いました。UML
は標準なので、みんなが同じように理解できます。UML を使ってお客様の特別な設計の意図やロジックがきちんと伝わりました。
日本語の文書を使った場合、本社の方は一応日本語が読めるのですが、間違いなどもあります。
その点、UML という標準のツールを使うと、言葉が違っても意味の理解しづらい部分が少なくなると思います。基本的に UML はコミュニケーションツールだと考えています。
[呼] オフショアで一番問題になるのは、お客様と実際の実装担当者との意識のギャップです。
それをいかにうまく埋めるかで、オフショアの成功/失敗が左右されます。たとえば、日本語をベースとした他のプロジェクトでは、たくさんの説明や文書で日本語のニュアンスや背景が違ってきます。でも、お客さんも Neusoft も UML を使っていれば、"クラスはこのように実装する"だとか"こういう関係がある"とかを表現でき、技術者間での言語の違いによる伝達障害がなくなります。そこは確かに助かっていて、一番評価すべき点だと考えています。
お客様とこちらの要望や意図するものの意識のギャップが、UML を使うことで未然に防げるということですね。
[呼] UML がないと、お客様から分厚い文書を貰って、BSE がどこまで消化できるかが問題になります。UML を使うと効率もいいし、お互いの認識の間違いも少なくなります。
UML を使う上で工夫/改善した点
UML を実際に使っていく上で、工夫あるいは改善した点にはどういうものがありますか? さきほど追加や修正とおっしゃいましたが、具体的にどういうことでしょうか?
基本的にお客様で設計したロジックをそのまま実装するのですが、テストの時にエラーや不具合が出ることがあります。そのときには UML を修正しなければなりません。実装側ではテストの不具合に含めて UML の内容を整理して修正や追加をします。修正したものはお客様に出して、

6

UML のどのあたりを修正したかを伝えます。実装と設計は並行してやっているので、修正部分をお客様の次の設計に反映してもらいます。
修正/追加したものをお客様と情報共有して、次のステップに移っていくということですね。
UML の活用についての今後の基本方針
では、オフショア開発での UML の活用は、今後どのような基本で進められる予定ですか? 「条件により UML を使用する」という回答を頂いていますが、これは顧客のニーズにより、ということですか?
[呼] はい。弊社は基本的に UML を使いたいのですが、お客様にはお客様のやり方があり、何十年も同じことをやってきたお客様が多いです。それぞれに自分のプロセスなどがあって、UMLを導入する/しないについてはお客様の自己主張がありますから、弊社がお客様に合わせるスタ
イルを取っています。もちろん、できるだけコミュニケーションを図りやすくするために提案はしますが、無理強いはできないのが困っているところです。ですから、この「条件」というのはお客様次第ということです。
中国側とのコミュニケーションについて
日本側と中国側のコミュニケーションは、どのような方法で行いましたか?
[呼] コミュニケーションのツールとして、テレビ会議や電話会議を行ったり、メールのやり取りは毎日しています。費用削減のために Skype も使っています。出張したり、向こうのメンバーをこちらに呼び寄せて常駐させたり、いろいろなパターンがあります。
2 年間のこのプロジェクトで、出張はどの程度の頻度でありましたか?
私ではなく上司が一度、Neusoft 本社に行きました。あちらから来たことはありません。
[藤野] お客様は行かれたのですか?
[呼] オフショア展開にあたって、技術のノウハウの共有ではなく、視察を目的として一度だけ行かれました。
[藤野] それは、お客様側で実際にプロジェクトを担当された 10 名の中の誰かですか? それとももっと偉い人ですか?
[呼] 両方です。チームが既に決まっていたので、プロジェクトマネージャやチームリーダーと、
ビジネス面から営業の立場で上の人も行きました。BSE もフォローのために行くのが通常です。
[藤野] それは毎回やっていらっしゃるのですか?
[呼] プロジェクトとしては我々は推奨していますが、行きたがらないお客様もいらっしゃいます。最近は予算が厳しくて出張もなかなか行けないこともあるようです。これもコミュニケーシ
ョンを目的としているのですが。
[鴨下] 数億円規模のプロジェクトで出張が 1 回というのは、少ないですね。進め方によってはもっと頻繁に face to face で行き来しなければならないケースが一般かと思います。非常に効率的ですね。
[呼] 別のプロジェクトですが、トラブルが発生したりうまく伝えきれない場合には出張が多くなるので、そういう意味では 2 年間で 1 回の視察だけですから、現場の技術者間のコミュニケーションはうまく取れたと思っています。

7

質疑応答
質問者：中原俊政、藤野博之、竹政昭利、鴨下明、サザーランド真理亜
回答者：Neusoft Japan 呼輝、費如良

ファイルの共有[竹政] ファイルの共有環境はどのようにされているのですか?
[費] 本社に FTP サーバーがあり、そこをお客様と Neusoft Japan から本社が見られるようにしていました。ファイルは本社から FTP に上げて、メールで知らせ、それを受けてこちらでダウ
ンロードするという形です。
[鴨下] 実装プログラムや設計ドキュメントを含めたファイル類は、本社の FTP サーバに置かれたとのことですが、それらはお客様も直接参照できるわけですか。
[費] はい。お客様用、Neusoft Japan 用、本社用のフォルダを分け、それぞれにアクセス権限を設定しています。基本的に見るのは全部見られます。
[竹政] セキュリティはパスワードでかけているのですか? ネットワークで VPN を使ったりはしていますか?
[呼] Neusoft Japan と本社の間は VPN でやっているケースが多いです。お客様はそこまでは入らないですね。プロジェクトごとに異なりますが、添付ができるかどうか、FTP ができるかど
うか、暗号化するかどうか、専用サーバーを構築するかどうかなど、いろいろなケースがあります。それもお客様の要望に合わせてやっています。日本側でサーバーを提供することもあります
し、お客様サイドから ID とパスワードを発行して貰うこともあります。ただ、今回のプロジェ
クトの場合は、本社側に FTP サーバーを用意して運用したわけです。
[費] この FTP は暗号化しています。
先端的/機密的システムに特有の注意点[鴨下] このプロジェクトの対象業務についてですが、生化学検査機器のソフトウェアということで、比較的先端的なものだと想像しています。産業機密にあたる部分も多数あるのではない
かと思うのですが、特に留意した点は何かありましたか?
[費] このプロジェクトではこちらには実機はないのですが、お客様から専用の基盤を差し込んだシミュレータがテスト用に提供されていて、そのシミュレータを瀋陽側でも持っています。センサは付いていないのですが、シミュレータのプログラムがあり、それと PC がつながって、
PC 側で値などを変えることができます。特別の仕様などはお客様から提供されています。
[鴨下] 今回のプロジェクトでは、ロジック細部の設計が正しいかどうかはお客様の責任であって、あくまでも実装モシュールが仕様書の通りになっているか否かが重要なポイントになるの
ですね。
使用した図
[鴨下] UML をお使いになったものの中で、クラス図とシーケンス図をメインに使われたということですが、ここまでのお話を伺って私が考えた場合、ステートマシン図が活用対象になりそ
うに思います。これがはずれているのはお客様のご意向ですか?
[費] 我々実装側は、お客様のクラス図で実装して、クラス図の中のメソッドはシーケンス図で実装します。

8

[鴨下] きわめて実践的な部分だけ UML を使っているわけですね。ステートマシン図で処理の概要イメージをつかんだりする必要はなく、クラス図とシーケンス図だけで実装は十分できるということですね。
[費] そうです。お客様側ではステートマシン図を使われていますが、我々の実装に関しては使っていません。
修正時の差分管理[鴨下] Neusoft 本社の実装部隊に作業依頼をして、修正があったということですが、UML の図に修正があった場合の差分はどのように管理されているのですか? この規模だと、元のクラス図
はとても大きなものになるかと思うのですが、それを修正が発生する都度書き換えるのはできないと思います。どのような形で差分を管理されていたか、お教えいただけますか?
[呼] クラス図に修正を加えることはそれほど多くはないので、ある場合だけ修正箇所をお客様に連絡して、レビューしていただきます。問題がなくて承認されたら、それ以降は新しいファイ
ルで運用するような形です。
[藤野] UML を管理するためのツールは何か使ってらっしゃいますか?
[費] 使っていません。
対日のオフショア[竹政] Neusoft Japan の場合は日本のお客様ですが、Neusoft 本社は必ずしも日本向けとは限らないのですよね。その場合、UML を使用しているのはどこ向けが多いとか、どことならやりやすいということはありますか?
[呼] Neusoft グループはいくつかの事業部や子会社に分かれています、その中に対日オフショアの事業部もいくつかあります。私の担当業務としては、対日オフショアの関連部署以外は、あまり業務的なやり取りがないため、申し訳ございませんが UML の使用状況について申し上げることができません。
[竹政] では、日本向けでは UML は有用だと考えられているわけですね。
[呼] それは分かっているのですが、他の現場で使っているかなどの情報は入ってきません。
プロジェクトで UML を使用する比率[竹政] お客様によって UML を利用されたり反発があったりするということですが、積極的に使うところ、ある程度やってくれるところ、全然やってくれないところの比率はどの程度でしょうか?
[呼] 私が見てきた 10 個弱の現場の中では、費のプロジェクトは積極的に使っている以外に、UML が必須になっている現場はまだ出てきていません。ただ、10 社あれば 1 社は使っていて、5〜6 社はシーケンス図だけなど部分的に使っています。それはお客様に強制しているのではな
く、あくまで弊社の開発設計で使っているというケースです。
[竹政] どちらかといえば、Neusoft Japan から使いたいと提案する感じですか?
[呼] もちろん、お客様側で使っているケースもあります。でも UML が必須だというところま
ではいきません。コミュニケーションのために使ってみようという程度です。お客様の技術者でUML を知らない人にはちょっと勉強してもらうなど、こちらから勧めたりしています。残りの2 社くらいは、全然 UML は使っていなくて、お客様からフォーマットや場合によってはフォン
トまで指定されています。その場合にはお客様が望んでいることを弊社が提供するような形で進めています。
9

ブリッジ SE の役割[藤野] 費さんのブリッジとしての役割についてお伺いします。お客様のところに常駐されているのですか?
[費] 基本的には弊社内で作業しています。定期的に仕様の説明会などをしていて、仕様を受け取るために一度会い、途中で質問や状況の説明のための会議をしますが、作業自体は弊社内です。
[藤野] お客様が UML で設計されて、それを中国側に送られるわけですよね。そのときの費さんの役割は、打ち合わせ時に通訳をするだけなのですか。それとも仕様の中身についても関与されますか?
[費] 打ち合わせは基本的にお客様と Neusoft Japan サイドで行います。日本で仕様を受け取り、私が瀋陽側と会議をして、内容を説明します。瀋陽側でその仕様を受けて分析するときに質問や問題が出てきます。それを私が受けてお客様と打ち合わせして回答を頂き、それを瀋陽に展開します。
[藤野] お客様と瀋陽とは直接の打ち合わせはしないのですか?
[費] ほとんどしません。お客様の書かれた UML を私が全部理解し、重要なところ、問題がありそうなところ、複雑な部分を重点的に理解して、両方とコミュニケーションします。
[呼] 今回は常駐しなかったのですが、基本的にブリッジ SE はお客様のところに常駐します。費のプロジェクトは稀なケースです。お客様とのコミュニケーションは定例的に週に一度や 2 週間、1 ヶ月に一度などあるのですが、その他に納品するときなどに現場に行っています。ただ、他の案件はみんなオンサイトに常駐しています。
[藤野] UML を使っていればオンサイトに常駐しなくても済むのでしょうか?
[呼] オンサイト常駐で、今回のプロジェクトのように積極的に使っているケースがないので、断言はできませんが、現実として仕様の理解はオンサイトに常駐していなくてもそれほど問題がなかったといえます。
[藤野] オンサイトで常駐していなくて UML を使っていないケースはありますか?
[呼] あります。そこでは基本的に週に一度以上、お客様との定例のミーティングを開催しています。
[藤野] どちらにせよ、お客様の仕様がきっちりと書かれていれば常駐しなくてもよいということですか。
[呼] それもありますが、今回常駐しなかったのは、お客様のセキュリティなどの都合です。弊社のスタンスとしては、常駐するとお客様とのコミュニケーションがもちろんよくなりますし、できれば常駐して作業を進めたいです。常駐すると人間関係もよくなりますし、本来は常駐した
いと思っています。
[中原] 今回、常駐しなくて特にトラブルなどはなかったのですか?
[呼] 特になかったですね。しかも、定例の打ち合わせもそれほど多くはなかったです。他の現場では基本的に週 1 回以上やらないといけませんので。
[藤野] UML で仕様の大部分は明確になって、お客様に伝わっているからですか。
[呼] はい、そうです。

10

[鴨下] 今回のケースは再構築なので、UML のダイアグラム自体が枯れている、という状況も特徴的かも知れませんが、それでも実装担当の方はその UML の図を初めてご覧になると思います。この点に対するブリッジ SE の役割をもう少しお教えください。
[呼] BSE の役割は通訳だけじゃありません。むしろ通訳や翻訳はほとんどなく、翻訳はオフシ
ョア側の外国語に精通している人にお願いしています。BSE は技術の方がメインで、現場に常駐しているかどうかに関係なく仕様を全部把握している、というのが我々のスタンスです。細かいところまでは見きれませんが、全体的な仕様やスケジュール管理は Neusoft Japan で管理しています。詳細部分は問題が発生したら細かく深掘りするという形です。
[藤野] 受け入れチェックをされているということですが、実際に納品されたものについての内容までチェックするのですか? それとも、どういうテストをされたかや、成果物が揃っているか
どうかのチェックなのですか?
[呼] 今回のプロジェクトでは、PC のエミュレータなどを使っているため、実機で動作しないことが稀にあります。その意味で、実機環境のあるお客様のところでお客様と一緒にオンサイトでチェックしたりはしています。実機環境がないと、オフショア側だけでは成果物の 100%保証はできないからです。その点はお客様にも十分承知していただいています。
[藤野] 実際にどういうところに不具合があったかが分かるので、費さんから直接瀋陽に伝えられるのですね。
[費] 現場の不具合の確認が結構多いです。お客様側で受け入れテストで不具合があると、その確認のために現場に行って、どのケースで不具合が発生するかを私が詳しく理解し、本社に連絡
して、本社が修正した後で、またお客様に引き渡すということを繰り返します。
[呼] 時間の関係などで、場合によっては費が直接修正することもありました。
日本語スキル[竹政] お客様のクラス図やシーケンス図は、日本語で書かれているのでしょうか? それをそのまま見て実装されるのですか? それとも翻訳が入るのでしょうか?
[費] 基本的に実装のメンバーは、それほどレベルは高くありませんが日本語が読めます。ですから、メッセージなどを見て、そのまま分かれば自分で実装します。特別日本語が多かったり難しい部分については、中国側で翻訳をしてから実装しています。
[呼] 向こうのメンバーは基本的に日本語が読めることを前提として作業に投入しています。喋れる必要はありませんが、基礎教育として日本語を勉強しています。
[竹政] 日本語の長い文章なら翻訳が必要だけれども、クラス図やシーケンス図くらいの短いものならそのままやりやすいということですね。
[鴨下] Neusoft 本社の設計担当には比較的日本語ができる方がいらっしゃって、実装担当の方は日本語のスキルが少し落ちる方もいらっしゃるとのことでしたが、それでもソース上にコメン
トを入れる必要はあるのではないですか?
[呼] たとえば、リーダーが特別に日本語能力が高いとかではなく、開発だけじゃなくて日本語の勉強歴も含めて経験年数が長い人がリーダーになっています。入社時だけではなく日常的にずっと勉強していますので、長ければ長いほど日本語が上達します。
[藤野] では中国にいる 10 名のメンバーは、全員が UML を読んでそのまま実装されていて、仕様を理解する人とそれをコードに落とす人に分かれているのではない、ということですか?
[費] はい。

11

システム全体像の把握[竹政] そもそもシステムの全体像の理解は必要ないのですか? いきなりシーケンス図の詳細レベルでいいのですか?
[呼] 全体像の理解は必要です。それを理解しているのは BSE です。BSE が大枠を理解して、それをどう中国に説明するかはまた別の話です。
[藤野] 当初のアーキテクチャ設計はどなたがされているのですか?
[費] アーキテクチャの設計は基本的にお客様です。その設計を文書を貰って、理解してサンプルなどを作成し、それに従って実装するという形です。
詳細図の作成[中原] 客様からクラス図とシーケンス図を受け取るとのことですが、御社ではそれを受けて詳細クラス図や詳細シーケンス図などを作るのですか? それとも特に作らずに直接実装するのですか?
[費] 基本的に作りません。
[中原] そうすると、シーケンス図で複雑な制御ロジックを書くなど、発注側が大変だと思います。すべてのシーケンス図を書くのではなく、ポイントを絞って作成するようなことはされていたのですか?
[費] 今回のお客様は技術レベルが高かったので、基本的にシーケンス図は詳細まで書いたものを頂きました。すべてではなく、こういったケースはこのシーケンス図で、のような感じで指定
されて、それをこちらで応用するような感じでした。
[竹政] 中国側でシーケンス図を書くことはないのですか?
[費] 基本的にはないです。
[中原] ちゃんと実装できるレベルまでロジックを書いて渡すというのは、私の経験では非常にスキルが必要だと思います。
[呼] 工数もかかりますね。それが他のお客様であまり UML を使っていない 1 つの理由かと思います。
[中原] 大枠はアーキテクチャ設計の能力があればできますが、細かいところまで書くのは自分で実装などしてみないと完全なものはできませんね。それができて、質問もあまりないというのはすごいですね。
[費] ベースのシステムがあるので、基本的にベースのソースを分析し、そのロジックを元にシーケンス図を書いています。
[藤野] 古い C のソースは中国側に出したのですか?
[費] 出していません。お客様が持っているだけで私も見ていません。
UML 作成のガイドライン[サザーランド] お客様側で UML を作る際のガイドラインなどはあったのですか?
[費] そのクラス図はどうコードで実装するか、といったレベルの独自の簡単なガイドラインがありました。それを最初に頂いて、瀋陽ではそのガイドラインに従って実装します。

12

UML の効果[中原] お客様が UML を使わない場合には、UML を知らないケースと自社の開発ガイドラインに合わないケースがあるとのことでしたが、UML を使ってみたけれど使いものにならなかった
ので使わないというケースはありましたか?
[呼] 使ってみて評判が悪いというのは聞いていないです。確かに実際に UML に従ってやるのは工数的に難しいというのはありますが…。
[中原] 工数も含めて、使ってみてあまり効果がないから使えないという人はいませんか。
[呼] 私が知っている限りではいません。
オフショア先との対応の工数[鴨下] 弊社の中国オフショア発注事例では、質問のメールが一日に 20 件くらい来て、担当リー
ダーがその回答に丸一日かかっていました。これは失敗の事例ですが、Neusoft 様の場合、開発が最も佳境に入った際の質疑応答の件数は一日にどれくらいありましたか?
[費] 質問が一番多いのは仕様を出したとき、実装前の分析の段階です。実装とテスト段階では少ないです。連絡は直接のメールではなく、QA のファイルに内容が書かれてきます。それを私が直接回答するか、お客様から回答を貰います。数としては、一日に 20 件もないですね。多くて 10 件くらいです。
[藤野] それは製造工程の、UML の仕様を出した直後ですか。全体がたとえば 3 ヶ月としたら、そのうちの最初の 1 ヶ月とか 1 週間とか、どれくらいの期間ですか?
[費] 1 ヶ月くらいです。
オフショア先での UML の作成[中原] 御社で今回実装をされたとのことですが、基本的な UML を貰って、詳細レベルのクラス図やシーケンス図を自分で作成したプロジェクトの経験は過去にありますか?
[呼] それほど多くはないですが、あります。
[中原] そのプロジェクトはうまく行きましたか?
[呼] 私が直接に関与したわけではありませんが、失敗した例はないです。どのプロジェクトもだいたいスムーズにできていると思います。全社的に他のプロジェクトの情報を展開するのは、主に失敗したプロジェクトの振り返りであって、成功した例は特に展開していないのですが、UML を使ったプロジェクトでうまく行かなかったプロジェクトはないと思います。
デザインパターン[藤野] 先ほど話に出たデザインパターンの理解が必要なのは、上流の製造をする人ですか? それともプログラムを組む下流の方ですか?
[費] 上流の設計の方でいろいろなデザインパターンを使っているのですが、そのデザインパタ
ーンの書き方や図が人により違います。その場合に、標準の記述例などがあれば、設計段階も統一できます。また、実装側でその図を見てソースを書くときも、デザインパターンとしてガイド
ラインに標準の例があれば、統一されたソースができます。
[藤野] つまり、上流の設計の人も分かっていなければならないし、下流の人も両方が分かっていないとうまく伝わらないということですね。
[費] はい。

13

[竹政] デザインパターンとおっしゃっているのは、"こういうパターンのときはこう設計する"という、今回のプロジェクトのデザインパターンという意味合いですか。
[費] はい。
[サザーランド] お客様の方で独自のデザインがあって、それの簡単なガイドラインが最初の時
点であればよかったということですか。
[費] 簡単なものはあるのですが、もっと詳しく記述すればよかったのではなかったかと思います。
[呼] お客様の方は十数名いらっしゃるので、人によって統一感がないのはどうしても避けて通れないところかと思います。ある意味、ガイドラインをきっちり作っておけば、ある程度統一感が出ると思います。
[鴨下] 組み込み系の先端技術ですと、処理速度なども含めてそのデザインパターンが正解かどうかなど、パターン自体にもノウハウがあるものかと思います。たとえば事務系などで"Struts
フレームワークの基本パターンで進めます"といった形で基本方針を決めれば、比較的デザイン
パターンは作りやすいと思いますが、技術系はそういう世界ではないので難しいですね。
ミドルウェアおよび OS[鴨下] このプロジェクトでは、ミドルウェアや OS は使っているのですか?
[費] はい。
[鴨下] MPU 直書きで、マイクロプロセッサに固有の文法で直接書き込むようなものではないのですか?
[費] 直書きではないですが、OS とアプリケーションがひとつのバイナリファイルにコンバイル
されて基盤の Flash メモリに書き込みます。
[藤野] OS は何を使われたのですか。
[費] VxWorks です。組み込み系でよく使われているものです。精密機器なのでリアルタイム性が高くないといけませんので。
UMTP の UML モデリング技能認定試験[藤野] UMTP が提供している試験は受けていらっしゃいますか?
[呼] 会社としては色々な資格試験を受けることは推奨していますが、強制ではないです。個人
的に時間があれば、あるいは業務で必要であれば、積極的に取るようにと奨励金なども出しています。
[藤野] 日本では何人くらい持っていらっしゃいますか?
[呼] 私の業務範囲では把握していません。UML 以外も含めて推奨はしています。
Neusoft Japan の構成[藤野] 日本にいらっしゃる 250 名のうち 100 名は中国から来ていらっしゃるとのことですが、残りの 150 名は日本にいらっしゃる中国の方ですか、それとも日本人ですか?
[呼] 我々が言う正社員が 150 名弱で、その中で、2009 年度は 8:2 くらいで中国人が多かったのですが、最近は徐々に日本人の採用に力を入れています。7:3 になりつつあるという話を聞いて
います。

14

[サザーランド] 中国側の方というのは、東北大学を卒業された方なのですか?
[呼] 多いのですが、そうとは限らないですね。
[サザーランド] でも何らかの形で日本語などの研修を受けたりはされているのですか?
[呼] 人によりますね。日本に留学している人もいますし、日本の大学院に入ったりとか、向こうで日本語を勉強し始めてこちらで仕事をするなど、色々なケースがあります。
[サザーランド] 必ずしも東北大学の卒業生だけではないのですね。
[呼] そうですね、特に出身大学に拘ることはありません。
UML と組み込みシステム[竹政] 組み込みシステムとそれ以外のシステムとを比較したときに、UML でやる場合に組み込みシステムが適しているというのはありますか? それともあまり関係ないでしょうか?
[費] 組み込み系ではロジックを特定しています。その場合は UML で設計ができると便利です。
ユーザーインターフェイスでは、そんなに精密なロジックはないので、それほど細かくないクラ
ス図で全体の構造が分かればいいかと思います。業務系や UI ではクラス図まででいいかと思います。
[竹政] シーケンス図まではいらなくて、クラス図まで理解できれば十分ということですね。
[費] 個人的には UML はコミュニケーションツールだと思うので、設計や意図がきちんと伝わればいいと思います。細かいロジックがあるところは細かく書かなければいけないし、実装側で機能を実現できさえすればいい場合には細かいシーケンス図は不要ですね。

成功へのポイント仕様の提示、ロジックの追加/修正確認を、UML で行うことにより、お互いに確実に伝えることができ、仕様確認の回数を削減できる。
ブリッジ SE は、通訳や翻訳よりも、全体の仕様の把握・チェックやスケジュール管理が重要である。

15