仕様変更を丸く収めたい 初めての中国オフショア開発ですが、当初の想定よりも仕様変更が増えました。明日、追加請求の件で、先方の総経理と直接対談します。どんな点に気をつけたらよいでしょうか？ （日本企業／プロジェクトマネージャ）
「仕様変更が収束しない」など一方的に発注側に非があったとしても、単純に追加請求を受け付けるほど予算的な余裕はない。さて、あなたが日本側のプロマネなら、どう対処すべきか。
残念ながら、中国企業との交渉に万能薬はない。そのため、原理原則でお茶を濁すしかないが、以下の４項目はすぐにでも応用が利くだろう。
・十分に時間をかけて交渉を進める 勢いに押されてその場で意志決定しないこと。 交渉場所が（ ）なら、なおさら焦らずじっくり対話すること。
・相手方の憤りや怒りなどの感情を素直に受け止める 責任論などの理屈はいったん脇に置いて、相手の感情に配慮する。 目的を見失わず、当事者と（ ）を切り分けて議論すること。
・総論より各論を意識して、的確なフィードバックを与える 一般論ではなく個別具体論で対応する。フィードバックを与える際には、「その場で」「 」「具体的に」の三原則を遵守すること。
・全ての言葉遣いや数字・データを丁寧に正確に扱う 勢いに押されて、何でも「はいはい」と流さないこと。日本語で交渉する際には、主語や指示語の曖昧さに留意すること。文脈に依存する表現(high context)が出てきたら、その都度確認する。
■成功の勘所
どんなに厳しい交渉の場面でも、根底にあるのは効果的なコミュニケーションを支える原理原則である。
・十分に時間をかけて交渉を進める ・相手方の憤りや怒りなどの感情を素直に受け止める ・総論より各論を意識して、的確なフィードバックを与える ・全ての言葉遣いや数字・データを丁寧に正確に扱う
ＵＭＬ普及 オフショア開発でもＵＭＬは使えますか？ （よくある質問）
中国向けオフショア開発においては、残念ながらＵＭＬが持つ真の力を十分に発揮し切れていない。オフショア大學にも参画する、日本におけるオブジェクト指向開発の権威である長瀬嘉秀氏は、日本と中国それぞれに原因があると指摘する。
日本側の原因
欧米でのＵＭＬの普及率は７割を超えているのに対して、日本ではまだ１割程度しか普及していない。そもそも実力不足。
中国側の原因
大学などの教育機関で、未だに平然と古いバージョンのＵＭＬを教えている。ＵＭＬ用語の中国語訳が統一しないなど、本格的な普及に向けては課題が山積する状態。
日本側ではシステム分析者、設計者、プロジェクト管理者を配置して、さらにオフショア側からブリッジＳＥに参加してもらう。オフショア側では、製造と詳細設計を行えるメンバーを揃えて、開発だけに専念する。当面は、この役割分担でＵＭＬによる中国オフショア開発は進められる。
■ 良い文章作法 語順を乱すべからず （オフショア開発PRESS特集1-3より）
中国語には「にておは」がなく、日本語と比べて語順の自由度は小さい。さらに「てにをは」を自由に使える中国人材はほとんどいないことを考慮して、語順をＳＯＶに統一すべきである。
オフショア開発ではカタカナ外来語の弊害が有名だが、表面的な問題分析については、ほぼ議論し尽くされたと思う。オフショア開発では、仕様書や設計書からカタカナ外来語を減らす責任を発注者(日本人)が負うべきだとの見解が示された。
○アンケート最終結果を見る
アンケートに回答した中国人読者から「～しなければいけない」を「～するべき」に書いて欲しいと、追加でご意見が寄せられた。英語の"must"と"have to"の意味が違うように、「～しなければいけない」と「～するべき」の意味も微妙に異なるはずだが、我々はどう対応すべきだろうか。
ソフトウェア仕様書は文学作品ではないので、「～しなければいけない」は「～するべき」に統一すべきである。発注者が文書作法の遵守に責任を持つべきである。
いや、こんなことを言い出したらきりがない。オフショア側の外国人技術者が努力して日本語の読解力を向上させるべきである。
あなたのご意見は？
◆発注者(日本人)が文書作法を遵守すべき ◆受注者(外国人)が日本語読解力を向上させるべき ◆その他
○結果を見る ○コメントボード
締切：2008年04月09日23時00分 協力：クリックアンケート
「カタカナ英語」を減らして、漢字もしくは英語で書くべき？ 発注者(日本人)が「カタカナ」を減らす努力をすべき (33票)77％ ○アンケート途中結果を見る
○アンケート途中結果を見る
オフショア開発PRESS創刊記念セミナー講師より
――中国では、すでにＵＭＬがフル活用されているのでしょうか？
・私の感覚では、中国でのＵＭＬによるシステム設計の教育はほとんど行われていません。ＵＭＬについては、大学の授業で少し見たことがある程度です。中国側での教育の問題もあります。
中国のエンジニアは、スキルと給料が強く関連しているため、日本よりかなり強い学習意欲を持っています。受講生の学習への取り組みは、日本よりも真剣です。また、過去の非オブジェクト指向の考えを持っていないため、素直に頭の中に入っていきます。日本では古い考え方が壁となって、新しい考え方を受け入れない人が多いのですが、中国ではこのようなことはありません。
ただし、中国で実施されるＵＭＬ資格試験問題をみると、ＵＭＬ関連の中国語訳がまだ統一されていないようです。したがって、ＵＭＬに関しては、下手に漢字で書くくらいなら、英語表記のままの方がよいでしょう。
欧米でのＵＭＬの普及率は７割を超えている。日本ではまだ１割程度。中国にいたっては、用語統一に課題が残る状態。
この表現の問題点を指摘できますか？ 直接アプリケーションがこのオブジェクトを操作することはない。 （日本人が書いた詳細設計書より）
以下はシステム開発の設計書で用いられた文章である。これらを中国オフショア開発で使ったとき、どんな問題が発生するかを指摘しなさい。
1．直接アプリケーションがこのオブジェクトを操作することはない
2．テンポラリファイルにログをアペンドする
3．例外扱いとしてプログラムの自動アボートを行う
【ヒント】
・カタカナ用語 ・サ変動詞 ・日本語を読めない中国人プログラマに向けた文章だとしたら？ ・自動英訳できるか？
以下の３つの例文のうち、中国オフショア開発で用いるとしたら、どれが最も相応しいか。あるいは、他にもっとよい言い回しが存在するだろうか。理由をつけて答えなさい。
「直接アプリケーションがこのオブジェクトを操作することはない」
「アプリケーションは、直接このオブジェクトを操作できない」
「このobjectは、Applicationによって直接には操作不可能である」
※上の３文章ですが、それぞれ微妙に意味が異なります。実践では、 前後の文脈に応じて、単語や言い回しを上手に使い分けましょう。
自己反省、プログラマまで遠い 通訳兼ブリッジSEを通して日本語で書いた仕様書を説明しました。同じテーブルを囲んでいるのに、ブリッジSEを通してしかコミュニケーションができず、私もブリッジSEの顔しか見ませんでした。 （日本人）
かつて、オフショア開発を経験した者なら、ブリッジSEを介した仕様説明で何度も失敗を重ねたことだろう。「失敗」と書いたが、特に恥じることはない。小さな失敗の積み重ねは、オフショア開発の成功に向けた正常なプロセスの一部である。
オフショア大學を受講したある日本人SEは、中国への仕様伝達を効率化するために、Ｑ＆Ａなどの短い文書は片っ端から英語化していったという。実に興味深い改善事例である。
・日本語と英語の両方で文書作成した
・できるところから着手して、徐々に仕様書全体にまで英語化の範囲を広げた
・その結果、仕様理解不足のバグが激減した
・日本側の文書作成工数は大幅に増大したが、プロジェクト全体の工数削減に寄与したので満足
前述の改善活動をはじめたきっかけは、中国人プログラマとの距離を縮めたいという、極めて個人的な動機が出発点である。だからこそ、決して英語が得意とはいえない平凡な日本人SEが、Ｑ＆Ａ文書の英語化に踏み切れた。短絡的な効率性だけを求めていたら、面倒な英語化なんてきっと長続きしなかっただろう。
あっぱれ×５！
納品されたプログラムが異常終了する 中国で真面目に動作確認を行ったのか、はなはだ疑問である。 （東京／元請けベンダ担当者）
オフショア開発では仕様に関連するバグが圧倒的に多い。次いで、動作環境に違いに起因する性能問題も目立つ。最近では、いわゆる「初歩的なバグ」は減った。
・プログラム異常終了 ・コンパイルエラー ・環境依存資源をハードコーディングしたため互換性ゼロ
ところが、実際には「初歩的なバグ」は一向に減っていないとの声もある。単に上層部に報告されないだけで、日本側の受け入れ現場で必死にバグを潰す姿が確認されている。
しかしながら、受け入れ工程の実態をよく観察すると、受託側の言い分も理解できないわけではない（二重否定）。
「計画では、日本から単体試験データを提供して頂く予定だったのに、実際に頂いた試験データは品質を保証するには不十分であった。」
「君達はそういうが、もし試験データが不完全なら、最初に報告してもらわないと困る。我々は高い単金で素人を雇っているわけではない。これだと、無責任な派遣業者と同じじゃないか。」
「そもそも、オフショア側には不十分な設計書しか渡されていないのに、頂いた試験データの妥当性を判断できるはずがありません」
その後も、話し合いは平行線をたどる。
オフショアベンダからの提案書には、「日本から試験データを提供して頂き、その内容を査定し不十分な場合、再提出して頂く」と明記されていた。ところが、問題は発生してしまった。いったい、どこに問題があったのか。
どうせ仕様は固まらない。納期だけが迫ってくる。 仮に仕様を細かく詰めたって、顧客はなんだかんだと合意を留保する。そうして矢継ぎ早の仕様変更。その度に仕様書を書き直すなんて、工数的にやってられない。 （小規模オフショアベンダ／日本人役員）
あなたは、仕様書丸投げに賛成か反対か。いつの間にか読者アンケートの結果は互角の争いになってきた。日本側で小規模オフショアベンダを切り盛りするある日本人役員は、受託側の苦しい胸のうちをこう明かしてくれた。
・どうぜ日本の顧客には仕様を決める権限もなければ、文書化する暇も能力もない。それなら粗い仕様で粗いままさっさと作って、顧客に見せて触ってもらい、ダメ出しされながら現物を手直ししていく方が効率的だ。もちろん、手直し期間の工数は請求できるはずもない。
効率化の手段と信じて仕様書作成の工数を省くプロジェクトがある。「仕様書＝ソースコード」が日常化してしまい、終わりの見えない客先常駐（監禁）に放り込まれる。第三者への引継ぎも困難。
まともなシステム会社なら、あえて火中の栗を拾う必要もないので、引継ぎ依頼は断固拒否。こんなときの救世主は、恐れを知らない中国やインドのオフショアベンダ。リバースエンジニアリングと称して、技術者が必死でソースコードを洗いなおす。
件名：至急！書類の郵送依頼について（２） 件名：重要連絡 会議開始の時間について 件名：変更してください （実際にあった日本人が書いたメールの件名）
件名：至急！書類の郵送依頼について（２） 件名：重要連絡 会議開始の時間について 件名：変更してください
（実際にあった日本人が書いたメールの件名）
ある種の人は、紙文書の通達を電子メールで再現しようとする。しかも、丁寧に書こうとすればするほど読みづらくなる。知人にも、本当にへたくそなメールばかり書く人がいるが、いつもトラブルを抱えている。
最近のビジネスパーソンは、毎日100通以上のメールを処理する。忙しいとき、Cc:に大勢ぶら下がっているときにメールを見過ごすことも多いが、そのときに限って重要な連絡事項を見過ごしてしまう。
【問いかけ】
・上記メール件名の問題点を指摘せよ。 ・可能なら、改善案を提示せよ。
オフショア開発発注者は、全ての仕様を明記すべきと思いますか。
以前、ある中国人読者がこう言った。
「オフショア開発発注者は、全ての仕様を明記すべきである」
私は条件反射的に反論した。
「それは非現実的である」
しばらく経って、またその議論が蒸し返された時、私は重要な問題に気づいた。前出の中国人読者と私の間で、おそらく「全て」の意味が共有されていない。
・最終的な仕様を明記する ・その時点で確定した仕様と未確定の仕様を明記すればよい ・製造者にとって必要十分な仕様が明記されること
「全て」の意味を厳密に定義すれば、オフショア開発の発注者は全ての仕様を明記すべきであると公言してもよいと思う。日本社会やソフト業界だけの枠組みで思考していたら、このような心境の変化は起こらなかっただろう。
多国籍企業のジョンソン・エンド・ジョンソンは、我が信条と呼ばれる絶対的な行動指針を持っている。我が信条は、日本国憲法よりも厳密に守られている。その秘訣を研究すると、基本原則を愚直に守り続けることが、長期的な好業績に直結することがわかる。
あなたが本気でYesと答えるなら、「全て」を具体的に定義しなさい。すべてを明記するための条件をガイドライン化しなさい。具体的な数値で条件を設定しなさい。現場の裁量で、お茶を濁されないための仕組みを作りなさい。そして、違反した者に対する処罰についても検討しなさい。
・中国からの質問に答えない ・すぐに謝る、不必要に謝る ・件名を読んでも内容が把握できない ・Cc: に大勢ぶら下がりすぎ ・１通のメールに複数の用件が混在 ・社外の人にも社内用語で話しかける ・宛先不明 ・改行されず読みづらい ・用件がないのでストレス蓄積 ・結論が遅い、背景説明がダラダラ続く ・中身のない言葉の羅列 （本誌発行人）
・中国からの質問に答えない ・すぐに謝る、不必要に謝る ・件名を読んでも内容が把握できない ・Cc: に大勢ぶら下がりすぎ ・１通のメールに複数の用件が混在 ・社外の人にも社内用語で話しかける ・宛先不明 ・改行されず読みづらい ・用件がないのでストレス蓄積 ・結論が遅い、背景説明がダラダラ続く ・中身のない言葉の羅列
（本誌発行人）
日本人のメールは本当に読みにくいか？このような自虐的な問いかけに対しては、つい反論したくなるのが人情である。一部の人は、メールや仕様書の文章が読みづらいのは、日本だけの課題ではなく万国共通である、と主張する。
確かに正論だが、問題を過度に一般化すると、解決への道が遠のいてしまう。やはり、日本人が犯しやすい誤りや、日本語固有の問題が山ほどあるはずだ。
これまで、多様性に乏しかった日本企業では、文書で意思疎通するための基礎的能力が十分に開発されなかったのではないか。世界中を飛び回る商社マンによると、文書で手短に、効率よく、正確に内容を伝えられる技術が欠かせないという。
特にテレックス時代（１文字○○銭）を生きた人は、先輩指導員から文書作成法を徹底的に赤ペン指導を受けたそうだ。ところが、ソフト業界では、マシン語を解読する特殊能力は磨かれたが、ビジネス文書力が鍛えられる機会がほとんどなかった。
日本人（特に技術者）の文章が読みにくい原因の１つは、多様性の欠如による。「あうんの呼吸」が通じる特殊な環境のせいで、誰もメール作成に関する特殊訓練を受ける機会がなかった。商社マンが、テレックス時代から徹底的に文章力を鍛えられたのとは対照的である。
日本人技術者が書く技術文書はとってもわかりにくい。日本人が読んでも意味不明で、突っ込みどころが満載です。特にメールは酷いと思います。 （オフショア大學）
（オフショア大學）
中国に仕様書を提供する前には必ず精査しているだろう。ところが、メールの文言まで逐一確認されることは少ないのではないか。メールに添付された仕様書(Excel,Word)は完璧なのに、メールにべた打ちされた作業指示が曖昧だったため、正確に意思疎通できないことがある。
よくある悪いメールの例。
・中国からの質問に答えない ・すぐに謝る、不必要に謝る ・件名を読んでも内容が把握できない ・Cc: に大勢ぶら下がりすぎ ・１通のメールに複数の用件が混在 ・社外の人にも社内用語で話しかける
他にも続々とネタが寄せられた。
・宛先不明 ・改行されず読みづらい ・用件がないのでストレス蓄積 ・結論が遅い、背景説明がダラダラ続く ・中身のない言葉の羅列
オフショア開発では、文書によるコミュニケーションが中心となる。特にQ＆Aなど即時性が求められる場合は、テキスト形式による会話が中心である。普段は仕様書(MS-office文書)ばかりが悪者にされるが、こうして改めて見直すと日々とんでもないメールがやり取りされていることが分かる。
過去にあなたが読み書きした最低のメールを思い出してみよう。そして、最低だった理由をすべて挙げなさい。
中国人の技術者の悪い面ですが、技術＝設計・コードだと思いがちで、業務フローの説明に対しては軽く受け取る分が多いです。この点も考慮した上で、テストを行ないます。 （オフショア大學／中国人）
（オフショア大學／中国人）
最近、やたらと中国人留学生の就職相談に乗ることが多い。やることといえば、日本企業から提示されたエントリーシートの添削。ただし、日本語の添削というよりも、設問に対して何を答えるべきかを考える戦略の指導の方が多かった。学生相手なので、コーチングだけでは全く足りない。私にとって基本的な常識であっても、相手が知らないことは、しっかり教えてあげないといけないことに気が付いた。一通り説明して「分かりましたか」と聞くと、元気よく「分かりました」と返事する。だが、案の定、半分しか分かっていない。国籍は関係ないかもしれないが、若い学生は就職を技術(テクニック）で対処しようとする傾向が見られる。
学生を指導する間に、オフショア大學の掲示板を読んで、思わず１人で笑ってしまった。
中国人の「分かりました」は、「あなたが今言っていることを理解できましたが、後で資料に照らし合わせて、本当の意味を理解できると思います。」
実務経験の浅い中国人プログラマーの発想。
技術＝設計・コード 分かりました＝あなたが今言っていることを理解できました
日本語はビジネス文書に不向きだと思いますか？ （オフショアリング分野に限定してお答えください） ◆不向きである ◆向いている ◆分からない ◆その他 ○結果を見る ○コメントボード 締切：2007年04月07日23時00分 協力：クリックアンケート
日本語はビジネス文書に不向きだと思いますか？ （オフショアリング分野に限定してお答えください）
◆不向きである ◆向いている ◆分からない ◆その他
締切：2007年04月07日23時00分 協力：クリックアンケート
日本語の仕様書には曖昧な部分が多い、というのがもっぱらの噂である。「我愛ni(I love you)」を日本語に訳すと、「私はあなたを愛している」以外にもたくさんの表現があり、しかも長い。逆に、「愛している」と主語が省略されることもある。倒置法も気軽に用いられる。さらに、日本語の漢字には複数の読み方が存在する。オフショア大學の中国人受講生は、そのせいで日本語による日常会話で苦労することがあると明かしてくれた。
オフショア大學では、日本人と外国人と日本語でコミュニケーションする際に注意すべき事項が続々とリストアップされている。例えば、「カタカナ用語」の乱用による被害も後を絶たない。先日も、仕様書に 「～をフオルスにする」と書いてきた人がいて苦笑したとの笑い話が報告された。
ところで、フオルスってどいう意味？
フオルス(?)
⇒ フォルス、フォールス(!)
⇒ false（真偽値）のことだ！ 仕様書には、日本人をも惑わす摩訶不思議な表現が満載!
ここが一番大事なポイントだが、ビジネスでは「結論を先に書くべきだ」と考える人にとって、日本語はビジネス文書の記述言語としては相応しくないかもしれない。文章を最後まで読まないと、Yes/Noの判断が難しいのが日本語の特徴なので。
自分で書いた日本語文章を英語に書き直したら論理構造すっきりした、という話をたまに聞く。実は、私も過去に何度も経験がある。
オフショア開発を正式に契約する前に発生する仕様把握の工数を誰が負担しているのだろうか。 ◆発注側 ◆受注側 ◆双方で折半 ◆その他 ○結果を見る ○コメントボード 締切：2007年03月23日23時00分 協力：クリックアンケート ⇒個人情報が漏れることはありませんので（入力不要）、 お気軽にクリックしてください。ご協力お願いします。（幸地）
◆発注側 ◆受注側 ◆双方で折半 ◆その他
締切：2007年03月23日23時00分 協力：クリックアンケート
⇒個人情報が漏れることはありませんので（入力不要）、 お気軽にクリックしてください。ご協力お願いします。（幸地）
日本から中国への仕様説明が終わると、次はQ&Aがはじまる。日本が不完全な仕様書を提供すると、相手からレベルの低い質問が飛んでくる。
ところが、最初から十分に準備された仕様書を提供しても、質問の数はあまり減らない。とはいえ、質問内容は格段にレベルアップする。したがって、開発期間の全体を通して評価すると、Q&Aの負荷は確実に減っている事が分かる。
オフショア開発では、仕様確認のQ＆Aに要する作業時間は国内開発と比べて２倍以上かかると思う。そこで、中国から日本に質問を投げかけるときのガイドラインを用意する会社が増えている。
・クローズド・クエスチョン(closed question)を推奨する
×「□□は何ですか？」 ◎「□□は、こうだと考えていますが、正しいですか？」
質疑応答の手間を省き、正確さを追求するにはクローズド・クエスチョン(closed question)が向いている。特に、回答者にとっては、Yes/Noで簡単に返事できるのでとっても楽。
一方、質問者は丸投げ質問が許されないので、予め想定される回答案を自ら考えて文章化しないといけない。クローズド・クエスチョン(closed question)で書かれた中国の質問を読めば、仕様の理解度が一発で分かる。
入出力を中心とした詳細な実装用仕様書をいただいたが、よくみると業務知識があることを前提に書かれていたので、多数の仕様誤解を誘発した。 （第16回オフショア開発勉強会／ゲスト講師）
（第16回オフショア開発勉強会／ゲスト講師）
第16回オフショア開発勉強会で聞いた失敗事例より。
入出力を中心とした詳細な実装用仕様書をいただいたが、よくみると業務知識があることを前提に書かれていたので、多数の仕様誤解を誘発した。
この会社は、東京本社で請けた仕事を中国蘇州の開発子会社に委託する典型的なオフショア活用型のSIer。オフショア開発に着手する前には、必ず中国側で仕様書の品質チェックを行っている。中国側の事前チェックは評判が良かった。実際、このおかげで、過去に何度も事故を未然に防ぐ事ができた。ところが、前出のプロジェクトでは、暗黙のうちに中国に過度な業務知識が要求されていたため、受注可否判定プロセスが十分に機能しなかった。
中国側でレビューしたものの、業務知識が不足しているため仕様書の品質を評価できず、事前にリスクを洗い出す事ができなかった。この問題の対策は難しい。なぜなら、肝心な業務知識が欠落していると、関連するリスク分析の甘さを自覚することはできないから。適切な時期に、適切な人が集まって、適切な手順でレビューしたが、失敗を防げなかった残念ながら事例である。
お客様（元請け）から仕様変更の依頼を受けた時、その都度中国に伝達したら、現地は絶対に混乱してしまうだろう。実際、仕様変更が二転三転して、結局は元に戻った！、何てことも日常茶飯事。 （日本人読者） ・本誌第564号より
（日本人読者）
・本誌第564号より
（昨日の続き）
多発する「仕様変更」を上手に伝える方法に関して、たくさんのコメントをいただいた。その一部を紹介する。
1 どちらかといえば、調整後の結果を伝えるべきです。但し、スピードと確実性が重要です。いつも間際になって大きな変更 を要求したり、二転三転してしまっては受ける側が混乱します。 １．仕様変更を予測した開発期間を確保すること ２．影響度合いを把握しておくこと ３．顧客の奴隷にならない （日本人読者） 2 私のアパレル製品という物理的な加工商品においては、日本側も中国側も生産工程を殆どが同じレベルで理解している、またほぼ生産工程が同一であることから生産者・購買者双方の会話が進む一つの理由であり、ソフト開発でそこまでプロセス管理・プロセス分析が出来ているのかが、鍵になると思います。 （日本人読者） 3 「即座にそのままの内容を伝えるべき」と回答しましたが、これは「この仕様でやれ！」ではなく、あくまでも仕様変更に対する相談を持ちかけ、中国側の合意を取った上で行えば、中国側の担当者も残業・休出もモチベーションを上げて対応してくれると思います。 （日本人読者） 4 私が勤務する自動車部品会社でも、出荷・発送の締め時間をとっくに過ぎているのに、受付の人間が「これ頼まれちゃったから送ってくれ」と言って来る。現場はその度に不快感を覚える。本来は追加発送を受けた者が、翌日にしてほしいときちんと言うべきだが、既出のコメントにあるように「客の奴隷」になって対応できない。 （日本人読者）
2 私のアパレル製品という物理的な加工商品においては、日本側も中国側も生産工程を殆どが同じレベルで理解している、またほぼ生産工程が同一であることから生産者・購買者双方の会話が進む一つの理由であり、ソフト開発でそこまでプロセス管理・プロセス分析が出来ているのかが、鍵になると思います。
3 「即座にそのままの内容を伝えるべき」と回答しましたが、これは「この仕様でやれ！」ではなく、あくまでも仕様変更に対する相談を持ちかけ、中国側の合意を取った上で行えば、中国側の担当者も残業・休出もモチベーションを上げて対応してくれると思います。
4 私が勤務する自動車部品会社でも、出荷・発送の締め時間をとっくに過ぎているのに、受付の人間が「これ頼まれちゃったから送ってくれ」と言って来る。現場はその度に不快感を覚える。本来は追加発送を受けた者が、翌日にしてほしいときちんと言うべきだが、既出のコメントにあるように「客の奴隷」になって対応できない。
↑ご意見ありがとうございます。コメントしてくれた４名は 全て日本人でした。珍しいなぁ。（幸地）
「これくらいの仕様変更は対応して当然だ」
このような考えは中国側の反発を買いやすい。感情を伴うコミュニケーションが極端に少ないオフショア開発プロジェクトは、例外なく失敗するだろう。中国ベンダーが仕様変更に対応してくれたら、どんな小さなことでもよいから、即座に感謝の意を表し、賞賛を与えるべきである。
中国は「休日返上はご勘弁」といいますが、日本側なんてここ３ヶ月間全く休みを取っていません。 （日本人読者）
日本本社と中国子会社との間で交わされる会話より。
「仕様変更の通達が遅すぎる！」と憤慨するのは中国子会社のプロジェクトリーダーＣさん。日本から提示された最終工程表は、まるで中国は土日を返上して作業するのが当然だと言わんばかり。なぜ、仕様変更の通達はいつも遅れてしまうのか。日本側の窓口担当者の悲痛な叫びに耳を傾けてみる。
こちらだって、中国に申し訳ないと思っています。それでも、仕様変更の通達が遅れてしまうのです。
お客様（元請け）から仕様変更の依頼を受けた時、その都度中国に伝達したら、現地は絶対に混乱してしまうだろう。実際、仕様変更が二転三転して、結局は元に戻った！、何てことも日常茶飯事。我々がお客様と中国の間に入って、仕様変更の優先度を見極めて、最も作業効率が上がるよう調整するから、このプロジェクトは何とか回っているのだ。
中国は「休日返上はご勘弁」といいますが、 日本側なんてここ３ヶ月間全く休みを取っていません。
残念ながら、日本側窓口担当者の苦悩は、中国子会社には全く理解されていない。日本側は、プロジェクト終盤の遅れを取り戻すため、中国側の休日出勤は当然だと思っている。会社トップは、最終的にお客様に迷惑をかけなければ、何をやってもいいという考え。
☆多発する「仕様変更」を上手に伝えるタイミングは？
◆即座にそのままの内容を伝えるべき ◆日本で調整してから間をおいて伝えるべき ◆その他（コメントボードにご意見を）
締切：2007年01月03日23時00分 協力：クリックアンケート
先に作り込んでお客さんにこちらから逆提案します。 （上海／中国ベンダー総経理）
（上海／中国ベンダー総経理）
上海出張中、設立間もないオフショアベンダーから聞いた面白い話。
対日オフショア開発をする以上、中国側は、頻繁な仕様変更に対応する能力を持たなくてはいけない。納期遅延や品質問題の原因の多くは、中国人技術者の「待機」に起因する。つまり、多くの中国人技術者は、日本で仕様が確定して、文書で正しく提示されるまで待機する癖があると指摘する。
【典型的な失敗パターン】
◆日本からの仕様が曖昧、頻繁な仕様変更 →中国側の手戻り多発、工数超過
◆日本から仕様提示の遅れ →中国側の待機で時間浪費、スケジュール圧迫
◆日本の都合で「納期厳守」 →土壇場で仕様確定するも、時間足りず連日の残業 →テスト不足のまま不完全な納品。あるいは納期遅延。
◆日本は「品質が悪い！」と中国を一方的に批判 →中国も「日本は自分勝手。中国を対等なパートナーとみなさない」 と応戦。泥沼化へ。
前出の中国ベンダーでは、見積もり時（作業着手前）に、作業スケジュールを最長２日間のタスクまで細かく落とし込む。総経理（兼最高技術責任者）は、「うちは絶対に納期遅延しない」と豪語する。
中国では、氏名が変わることは絶対にありえないという前提で、氏名データが画面上で書き換え不能になることがあるのでしょうか。氏名データ修正するには、DBを直接書き換えないといけない？ （本誌発行人）
先日紹介した「氏名」に関する日本と中国の常識の違いについて、複数の読者からご意見が届いた。
・画面上で（姓が）書き換え不能になることがあるのでしょうか、 ということが、絶対にないじゃないか？ （ブログ閲覧者）
・業務システムで結婚イベントが発生したら、結婚した女性の姓を すぐ夫の姓に変更する処理を行うバッチ或いは画面処理が必要で 日本では常識だと想定しましょう。だったら中国側の常識を超え ることになるので、明記しないと必ず実装しません。
（ブログ閲覧者）
・第546号「仕様書に「常識」は書かれない」
常識は仕様書に書かれない。これは常識である。オフショア開発で実際に起こった常識に関するトラブル集を作ってみたら面白そう。
【例】金額データの常識が違う
日本では円が単位であるため、少数は不要ですが、中国での常識は元が単位であるため、小数点は2桁まで必要。 DB設計で価格を Number(9,2) → Number(9,0)に変更
本誌では、業務系アプリケーション分野の話題が多いが、組み込み系ソフト開発やBPOの話題も大歓迎である。
一人くらいは、英語力のあるＳＥを配置したい
すべての日本人ＳＥが英語を流暢に操る必要はないが、プロジェクトに１人くらい英語が得意な者を用意できないだろうか。（本誌発行人 幸地司）
先日のアンケートでも、オフショア開発の新規パートナー開拓時、最も重視する判断基準は「日本語コミュニケーション」だと回答した数は全体第2位の14%。
これまでに本誌で掲載してきた主張はこうだ。
・どちらかにネイティブスピーカーがいる言語を使うべき・文書は日本語、会話では英語を補助的に用いるとよい
●コミュニケーションの方法については、読者からも多様な意見が寄せられてくる。
＜タイ在住の日本人ＳＥ＞ 中国オフショアと決定的に違うのは、日本語が通じないと言うことです。日本語を話せるエンジニアはほぼ皆無です。 仕事では会話はタイ語、ドキュメントは英語です。 幸地さんの持論である、 「どちらかにネイティブスピーカーがいる言語を使うべき」 に私も賛成です。
＜中国オフショア開発を推進する日本人ＳＥ＞ 今後のオフショアのやりとりは日本語ではなく英語も視野に入れる必要があるような事が書かれていました。
でも、私自身、英語は駄目ですし、勿論、中国語もまだまだです。私は中国オフショアのメリットは中国人が日本語でコミュニケーションが取れることも重要な要素だと思っております。
インドが日本へのオフショアに失敗した典型が英語と日本語のやりとりが原因でもあったと聞きます。そういった意味で、本当に英語でのコミュニケーションでいいのか？と思っているのは私だけでしょうか。 ※
●本誌読者の皆さまにお聞きしたい。あなたの会社のオフショア開発で使用する言語は何ですか。国によって異なるし、現場で工夫する点も山のようにあるだろう。ぜひコメント欄にお書きください。
◆ドキュメント、会話も含めすべて日本語 ◆原則として日本語だが、ときどき英語も使う ◆ドキュメントは日本語、会話では英語をよく使う ◆ドキュメント、会話も含めすべて英語 ◆その他（コメント欄に詳細をお書きください） ○結果を見る ○コメントボード
締切：2005年06月09日23時
Copyright(C) 中国オフショア開発の無料レポート／セミナー Allrights reserved.
