PR
図3 中国ベンダーが日本企業に対して抱いている主な不満<BR>オフショア開発のトラブルの原因は,日本側にあるケースも少なくない。中国ベンダーの不満の声を聞き,自らの非を改める姿勢も必要だ
図3 中国ベンダーが日本企業に対して抱いている主な不満<BR>オフショア開発のトラブルの原因は,日本側にあるケースも少なくない。中国ベンダーの不満の声を聞き,自らの非を改める姿勢も必要だ
[画像のクリックで拡大表示]
図4 中国オフショア開発を成功させる2つの条件&lt;BR&gt;これらは中国オフショア開発を成功させるための最も基本的な条件である。仕様伝達に気を配ると同時に,中国のエンジニアたちはビジネスのやり方や価値観が異なるということを肝に銘じておかなければならない
図4 中国オフショア開発を成功させる2つの条件<BR>これらは中国オフショア開発を成功させるための最も基本的な条件である。仕様伝達に気を配ると同時に,中国のエンジニアたちはビジネスのやり方や価値観が異なるということを肝に銘じておかなければならない
[画像のクリックで拡大表示]
図5 正確に伝わる仕様書を作成する際のポイント&lt;BR&gt;オフショア開発では「仕様」に関するトラブルが多い。中国人は「行間を読んでくれない」ことを意識しながら,正確に伝わる仕様書を作成しなければならない
図5 正確に伝わる仕様書を作成する際のポイント<BR>オフショア開発では「仕様」に関するトラブルが多い。中国人は「行間を読んでくれない」ことを意識しながら,正確に伝わる仕様書を作成しなければならない
[画像のクリックで拡大表示]

中国企業の期待と本音

 中国オフショア開発は,日本の発注企業と中国ベンダーとの共同プロジェクトである。筆者が見るところ,オフショア開発が失敗する原因の多くは,実は日本企業の側にある。中国の非を責める前に,国内で解消すべき問題があるのだ。

 ここでは,4つの代表的な問題を紹介する。それは,(1)「仕様書をまとめる能力が不足している」,(2)「仕様変更の段取りが悪い」,(3)「担当者の能力が不足している」,(4)「理不尽な条件や要求を押し付ける」といったことだ。いずれも中国ベンダーが日本企業への不満として挙げるものである(図3[拡大表示])。

(1)仕様書をまとめられない

 中国企業から最もよく聞くのは,「仕様書」に関する不満だ。国内開発においては,走りながら徐々に暫定仕様を確定させるケースが少なくない。そうした「日本型開発アプローチ」では,発注側の業務分析が足りない場合に,受注側のシステム開発会社や下請け業者が努力して仕様書の行間を埋めることが当たり前のように行われている。

 ところが,日本語で書かれた仕様書の行間を読むことを,中国ベンダーに期待するのは無理である。そのため,仕様をめぐって様々なトラブルが発生することになる。

 最初から100%完璧な仕様書を提出せよ,と言っているわけではない。実際には,最初は仕様未確定やあいまいな部分があってもかまわない。ただし,日本側が仕様の未確定部分を正確に把握し,いつまでに中国ベンダーに提示できるかをきちんと示すことが必要だ。

 仕様書の書き方に問題があるケースも多い。中国から見ると,機能単位の細かい仕様に目が行き過ぎている。その半面,漏れやダブリが多く,論理的思考に欠ける仕様書が目立つという。

 ある中国企業の担当者は,日本企業が提供する仕様書のほとんどが「木を見て森を見ず」だと指摘する。具体的には「全体構成と個別説明の対応が不明瞭」,「要件の網羅性が悪く,論理的にすっきりまとまった資料が少ない」という指摘だ。中には,日本企業が提供した仕様書がまったく役立たなかったため,わざわざ中国で作り直したところすらある。UMLで記述されたユースケースの粒度がばらついていたため,ほとんど使えないと判断されたのだ。こういった無駄の積み重ねが,オフショア開発のコストを押し上げる要因の1つとなってしまっている。

(2)仕様変更をめぐる不満

 仕様変更の管理は,中国オフショア開発における最大の難関の1つである。実は,仕様変更自体が中国ベンダーにとって問題になることはさほど多くない。ほとんどの中国ベンダーは,「走りながら徐々に要求仕様を決めていく」日本型の開発アプローチに十分な理解を示しているからだ。

 それよりも問題になるのは,自分たちの開発方法に何の疑問も持たない日本企業が現れたときだ。例えば,自分たちの段取りの悪さを棚に上げて,「これくらいの仕様変更は無償で対応して当然だ」などと高圧的な態度に出る日本企業がある。これは,従来の国内開発では通用したかもしれないが,オフショア開発では改めるべきだ。信頼関係が損なわれ,ソフトウエアの品質が低下するのを防ぐためにも,ある程度の追加費用は覚悟すべきである。

 仕様変更は日中間で感情的なあつれきを生み出しやすい。仕様変更が発生した場合は,特に人間の感情マネジメントに気を配らなければならない。例えば,中国ベンダーから「仕様変更に誠実に対応したのに,まったく感謝されなかった」という不満の声をよく聞く。仕様変更に対応してもらったら,どんな小さなことでも良いから感謝と称賛を表現しよう。仕様変更を穏便に取りまとめる秘訣は,日本側の「責任の自覚」と「感謝の表明」にある。

 感謝と同時に「謝罪」の言葉も忘れてはならない。筆者は,これまで多くのオフショア開発を経験してきたが,双方が素直に「申し訳ありません」と口に出せるプロジェクトでは,トラブルが少なかったように思う。仕様変更が発生したら日本側は潔く責任を認めよう。両国の信頼関係があれば,多少のもめごとは担当者間で解決できるものだ。

(3)担当者の能力が不足

 オフショア開発を始める際は,中国側の能力だけでなく,日本側の担当者の能力が十分かどうかもチェックしなければならない。

 中国ベンダーから,「日本の発注企業の担当者が詳細設計を理解していないので,会話が成り立たない」という声を聞いたことがある。そのプロジェクトにおいて,中国ベンダーに対する窓口を務めていたのは,技術的に未熟な若手社員だった。若手社員をコーディネータ役に配する場合は,必ず上司または先輩社員が若手社員を補佐する体制を取るようにするべきである。

 一方,技術力は高いが,管理能力やコミュニケーション能力に問題のある日本人がコーディネータに就くとどうなるか。筆者の経験では,まず間違いなく暗礁に乗り上げる。進ちょくが遅れるばかりか,優秀な中国人技術者は日本側の窓口の対応に愛想が尽きて,離職することにもなりかねない。

 例えば,「発注企業の担当者に相談を持ちかけても,真剣に聞いてくれない」と不満をもらす中国ベンダーがある。これは,「丸投げ体質」が染み付いた発注企業によく見られる。他のあるプロジェクトでは,中国ベンダーからの技術的な相談に対して,「私は忙しい。あなた方もプロならば,自力で解決してほしい」と,聞く耳を持たない担当者がいた。これは,コミュニケーションを放棄しているにも等しい。当然のことながら,納期,品質の面でプロジェクトは失敗した。

 筆者の考えでは,オフショア開発こそ,管理能力とコミュニケーション力に優れたプロジェクトマネジメントの専門家を使うべきだ。誤解を恐れずに言えば,中国ベンダーとの連絡窓口をするにあたって技術力や語学力は二の次である。何よりもマネジメントの実践経験とコミュニケーションの柔軟性を重視すべきだろう。

(4)理不尽な要求の押し付け

 中国ベンダーが抱く日本企業への不満として,「理不尽な条件や要求の押し付け」も見逃せない。中国オフショア開発では開発費用を抑えるため,日本企業が無理を承知で要求を押し通すケースが見られる。例えば,「予算内ではどう設計しても不可能な性能要求を強要する」,「明らかな仕様変更なのに,仕様の詳細化だと言って無償で受け入れさせる」といったことだ。

 中国ベンダーは,発注企業の一貫性がなかったり無責任な発言にも翻弄されている。例えば作業工数の増加について,日本側の設計者が何げなく発言した「了解しました」という言葉が,即座に追加請求に発展することがある。日本の営業サイドは「そんな話は聞いていない」と中国側の要求を突っぱねるが,後味の悪い印象だけが関係者の心に残る。

 また経験豊富なベテランになるほど,計画や目標にないことを,その場の思いつきで言う傾向にある。本人にとっては“適切な”状況判断かもしれない。だが,残念ながら外国人技術者には理解されない。中国企業の幹部や総経理(社長)を通じて十分に説明しないと,重大なトラブルに発展しかねない。

 国内でも大企業が協力会社に「理不尽な要求」を押し付けることが多い。これは日本的な甘えの構造と言えるだろう。発注者が「損をしない」から「共に得する」へと意識を変えない限り,こうした問題は解消されない。

仕様は口頭でも伝える

 以上で,前もって対策を講じるべきリスクと,日本企業側が自ら解決すべき問題を解説した。オフショア開発を成功させるためのポイントを,さらに2つ付け加えたい。それは仕様書の記述方法と,コミュニケーションに関する注意である(図4[拡大表示])。

 中国オフショア開発では「仕様」に関するトラブルが最も多い。中国オフショア開発を成功させるためには初期段階から要求仕様を固めることに加えて,中国人は「行間を読んでくれない」ことを意識しながら,仕様書を作成しなければならない。

 要求仕様は「できるだけ具体的,かつ正確に文書化すること」が不可欠である。文章だけで細かいニュアンスを伝えるのではなく,図面やサンプルを多用し,できるだけ実データに近い資料やサンプルを補足資料として提供すると良い(図5[拡大表示])。

 また,無用な混乱を避けるため,仕様書で用いる用語は互いに意味を確認し,統一する。例えば「空白」は日本では「スペース」を意味するが,中国では「NULL」を意味することが多い。中国人エンジニアに「背景色を“空色”(スカイブルー)にしてください」と指示したら,背景が無色だったという事例もある。このように日中間で意味が異なる用語があるので,英語で意味を書き加えるなど,特に注意しなくてはいけない。

 日本人が使うカタカナ英語も危ない。「レジを閉める」,「アポを取る」などの省略形がその典型だ。また「クロスサイトスクリプティング対策」など文字数の多い用語も説明を加えるか,避ける方が無難である。

 処理の記述に関しては,あらゆる条件や場面を想定し,できるだけ網羅性を高める工夫が求められる。判定条件や条件分岐の処理に関しては,想定し得るすべての内容を記述する。例えば,ユーザーが「役員の場合」,「部長の場合」,「課長の場合」,「その他の場合」と処理を分岐させたい場合,「“その他”とは,社長,派遣社員,バイトを指す」というように具体的に説明すべきである。日本人なら常識的に理解できる内容であっても,外国人技術者が理解できるとは限らない。

 オフショア開発の経験者から,「中国ベンダーは異常系の実装処理に漏れが多い」という声をよく聞く。例えば,エンドユーザーが「戻る」ボタンを押したときや,処理を「キャンセル」した後などのデータ状態への配慮が足りないという。

 だが,そうなるのは仕様書の書き方が原因だとも言える。ある研究によれば,国内でのシステム開発における異常系処理の約7割は,プログラマが独断で決定するとされている。中国オフショア開発でもその傾向は変わらない。あなたがふだん国内の開発で仕様書に書いているような異常系処理の網羅性では,ほぼ間違いなく実装漏れが発生すると心すべきだ。

 もちろん,すべての異常系処理を仕様書に書くのは困難だ。せめて,「仕様書全体を通して異常系処理の記述粒度を統一する」,「1カ所だけ見本として異常系処理の完璧な仕様を記述し,後は中国側に水平展開させる」といったことは,忘れずに行いたい。

 運用で発生し得る障害パターンも,可能な限り日本で洗い出しておく。一般の中国人エンジニアはシステム運用保守の経験が乏しいからだ。特に,日本側がシステムの運用保守を担当する場合には,発注側が障害発生時の仕様について責任を持つことが重要である。

 こうした仕様の説明は念には念を入れて丁寧に行いたい。日本から一方通行的に文書で提示するのではなく,相手方の理解度を必ず口頭で確認しながら進めた方が安全だ。

「大丈夫」の意味の違い

 仕様の伝達はその最たる例だが,オフショア開発の成否は,コミュニケーションに負うところが極めて大きい。日本側の担当者は,異文化とコミュニケーションをすることの難しさを十分に認識し,中国側の担当者と意思の疎通を図るべきだ。

 例えば,日本語を話せる中国人が口にする「大丈夫です」や「問題ない」は,日本人が使う場合とは微妙に意味が異なる。日本企業のオフショア開発経験者たちにインタビューしたところ,中国側には失礼な言い方になるが,「中国人エンジニアの“分かりました”や“大丈夫です”はほとんど信用できない」という意見が非常に多かった。

 それらの言葉が実際にどのように使われていたかを調査したところ,言葉遣いの違いについて次のような傾向があることが分かった。まず,「大丈夫です」は,日本では「全体が100%完璧」であるときに使われる。一方,中国人は,全体の一部が大丈夫ならば「大丈夫です」と言ってしまう。また「(仕様を)理解しました」は,日本では「100%理解しました。これでオフショア開発に着手できます」という状況で使う。中国では「説明されたことは理解しました。抜けや漏れがあればまた説明してください」という意味になる。

 冒頭では,「(プログラムが)できました」という言葉をめぐる誤解の例を示した。「できました」は,日本では「あらゆる条件に合格する成果物が完成した」ことを意味する。だが中国人が口にする「できました」は,「自分で定めた基準に合格した」ことを意味しているのだ。この場合は,「コンパイルに通る」ことが,「プログラム完成」であった。

 解決の鍵は,会話の「土俵」を同じくすることだ。例えば,仕様の伝達時と同ように図表,サンプルを効果的に使う,文章ではなく数字で会話する,書面通知だけで終わらず必ず後から口頭でも確認する,さらに中国側に議事録を提出させて理解度をチェックする,といったことを心掛ければ,コミュニケーションは大きく改善されるはずだ。

幸地 司(こうち つかさ)/アイコーチ 代表取締役,オフショア開発コンサルタント

九州大学大学院修了後、リコー入社。中国系ITベンチャー企業の営業マネージャー職 を経て、オフショア開発のコンサルティングを行うアイコーチを2003年に設立。日本 唯一の開発コーディネーター養成講座を主宰する一方、オフショア開発に関する日刊 メールマガジン(http://www.ai-coach.com/)は、現在約5000人の読者を数える。