効果的なコミュニケーションを支える４つの原理原則

仕様変更を丸く収めたい
初めての中国オフショア開発ですが、当初の想定よりも仕様変更が増えました。明日、追加請求の件で、先方の総経理と直接対談します。どんな点に気をつけたらよいでしょうか？
（日本企業／プロジェクトマネージャ）

「仕様変更が収束しない」など一方的に発注側に非があったとしても、単純に追加請求を受け付けるほど予算的な余裕はない。さて、あなたが日本側のプロマネなら、どう対処すべきか。

残念ながら、中国企業との交渉に万能薬はない。そのため、原理原則でお茶を濁すしかないが、以下の４項目はすぐにでも応用が利くだろう。

・十分に時間をかけて交渉を進める
勢いに押されてその場で意志決定しないこと。
交渉場所が（　　）なら、なおさら焦らずじっくり対話すること。

・相手方の憤りや怒りなどの感情を素直に受け止める
責任論などの理屈はいったん脇に置いて、相手の感情に配慮する。
目的を見失わず、当事者と（　　　）を切り分けて議論すること。

・総論より各論を意識して、的確なフィードバックを与える
一般論ではなく個別具体論で対応する。フィードバックを与える際には、「その場で」「　　　」「具体的に」の三原則を遵守すること。

・全ての言葉遣いや数字・データを丁寧に正確に扱う
勢いに押されて、何でも「はいはい」と流さないこと。日本語で交渉する際には、主語や指示語の曖昧さに留意すること。文脈に依存する表現(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: に大勢ぶら下がりすぎ
・１通のメールに複数の用件が混在
・社外の人にも社内用語で話しかける
・宛先不明
・改行されず読みづらい
・用件がないのでストレス蓄積
・結論が遅い、背景説明がダラダラ続く
・中身のない言葉の羅列

（本誌発行人）

日本人のメールは本当に読みにくいか？このような自虐的な問いかけに対しては、つい反論したくなるのが人情である。一部の人は、メールや仕様書の文章が読みづらいのは、日本だけの課題ではなく万国共通である、と主張する。

確かに正論だが、問題を過度に一般化すると、解決への道が遠のいてしまう。やはり、日本人が犯しやすい誤りや、日本語固有の問題が山ほどあるはずだ。

これまで、多様性に乏しかった日本企業では、文書で意思疎通するための基礎的能力が十分に開発されなかったのではないか。世界中を飛び回る商社マンによると、文書で手短に、効率よく、正確に内容を伝えられる技術が欠かせないという。

特にテレックス時代（１文字○○銭）を生きた人は、先輩指導員から文書作成法を徹底的に赤ペン指導を受けたそうだ。ところが、ソフト業界では、マシン語を解読する特殊能力は磨かれたが、ビジネス文書力が鍛えられる機会がほとんどなかった。

■成功の勘所

日本人（特に技術者）の文章が読みにくい原因の１つは、多様性の欠如による。「あうんの呼吸」が通じる特殊な環境のせいで、誰もメール作成に関する特殊訓練を受ける機会がなかった。商社マンが、テレックス時代から徹底的に文章力を鍛えられたのとは対照的である。

よくある悪いメールの例

日本人はもっと日本語を勉強すべき

日本人技術者が書く技術文書はとってもわかりにくい。日本人が読んでも意味不明で、突っ込みどころが満載です。特にメールは酷いと思います。

（オフショア大學）

中国に仕様書を提供する前には必ず精査しているだろう。ところが、メールの文言まで逐一確認されることは少ないのではないか。メールに添付された仕様書(Excel,Word)は完璧なのに、メールにべた打ちされた作業指示が曖昧だったため、正確に意思疎通できないことがある。

よくある悪いメールの例。

・中国からの質問に答えない
・すぐに謝る、不必要に謝る
・件名を読んでも内容が把握できない
・Cc: に大勢ぶら下がりすぎ
・１通のメールに複数の用件が混在
・社外の人にも社内用語で話しかける

他にも続々とネタが寄せられた。

・宛先不明
・改行されず読みづらい
・用件がないのでストレス蓄積
・結論が遅い、背景説明がダラダラ続く
・中身のない言葉の羅列

■成功の勘所

オフショア開発では、文書によるコミュニケーションが中心となる。特にQ＆Aなど即時性が求められる場合は、テキスト形式による会話が中心である。普段は仕様書(MS-office文書)ばかりが悪者にされるが、こうして改めて見直すと日々とんでもないメールがやり取りされていることが分かる。

過去にあなたが読み書きした最低のメールを思い出してみよう。そして、最低だった理由をすべて挙げなさい。

中国人の技術とは・・・、中国人の分かりましたとは・・・

仕様誤解を減らす工夫

中国人の技術者の悪い面ですが、技術＝設計・コードだと思いがちで、業務フローの説明に対しては軽く受け取る分が多いです。この点も考慮した上で、テストを行ないます。

（オフショア大學／中国人）

最近、やたらと中国人留学生の就職相談に乗ることが多い。やることといえば、日本企業から提示されたエントリーシートの添削。ただし、日本語の添削というよりも、設問に対して何を答えるべきかを考える戦略の指導の方が多かった。学生相手なので、コーチングだけでは全く足りない。私にとって基本的な常識であっても、相手が知らないことは、しっかり教えてあげないといけないことに気が付いた。一通り説明して「分かりましたか」と聞くと、元気よく「分かりました」と返事する。だが、案の定、半分しか分かっていない。国籍は関係ないかもしれないが、若い学生は就職を技術(テクニック）で対処しようとする傾向が見られる。

学生を指導する間に、オフショア大學の掲示板を読んで、思わず１人で笑ってしまった。

中国人の「分かりました」は、「あなたが今言っていることを理解できましたが、後で資料に照らし合わせて、本当の意味を理解できると思います。」

■成功の勘所

実務経験の浅い中国人プログラマーの発想。

技術＝設計・コード
分かりました＝あなたが今言っていることを理解できました

日本語は仕様記述言語として不適切か？

日本語はビジネス文書に不向きか

日本語はビジネス文書に不向きだと思いますか？
（オフショアリング分野に限定してお答えください）

◆不向きである
◆向いている
◆分からない
◆その他

○結果を見る
○コメントボード

締切：2007年04月07日23時00分
協力：クリックアンケート

日本語の仕様書には曖昧な部分が多い、というのがもっぱらの噂である。「我愛ni(I love you)」を日本語に訳すと、「私はあなたを愛している」以外にもたくさんの表現があり、しかも長い。逆に、「愛している」と主語が省略されることもある。倒置法も気軽に用いられる。さらに、日本語の漢字には複数の読み方が存在する。オフショア大學の中国人受講生は、そのせいで日本語による日常会話で苦労することがあると明かしてくれた。

オフショア大學では、日本人と外国人と日本語でコミュニケーションする際に注意すべき事項が続々とリストアップされている。例えば、「カタカナ用語」の乱用による被害も後を絶たない。先日も、仕様書に 「～をフオルスにする」と書いてきた人がいて苦笑したとの笑い話が報告された。

ところで、フオルスってどいう意味？

■成功の勘所

フオルス(?)

⇒ フォルス、フォールス(!)

⇒ false（真偽値）のことだ！
仕様書には、日本人をも惑わす摩訶不思議な表現が満載!

ここが一番大事なポイントだが、ビジネスでは「結論を先に書くべきだ」と考える人にとって、日本語はビジネス文書の記述言語としては相応しくないかもしれない。文章を最後まで読まないと、Yes/Noの判断が難しいのが日本語の特徴なので。

自分で書いた日本語文章を英語に書き直したら論理構造すっきりした、という話をたまに聞く。実は、私も過去に何度も経験がある。

クローズド・クエスチョン(closed question)を推奨する

正式契約前の作業工数を誰が負担すべきか？

オフショア開発を正式に契約する前に発生する仕様把握の工数を誰が負担しているのだろうか。

◆発注側
◆受注側
◆双方で折半
◆その他

○結果を見る
○コメントボード

締切：2007年03月23日23時00分
協力：クリックアンケート

⇒個人情報が漏れることはありませんので （入力不要）、
お気軽にクリックしてください。ご協力お願いします。（幸地）

日本から中国への仕様説明が終わると、次はQ&Aがはじまる。日本が不完全な仕様書を提供すると、相手からレベルの低い質問が飛んでくる。

ところが、最初から十分に準備された仕様書を提供しても、質問の数はあまり減らない。とはいえ、質問内容は格段にレベルアップする。したがって、開発期間の全体を通して評価すると、Q&Aの負荷は確実に減っている事が分かる。

オフショア開発では、仕様確認のQ＆Aに要する作業時間は国内開発と比べて２倍以上かかると思う。そこで、中国から日本に質問を投げかけるときのガイドラインを用意する会社が増えている。

・クローズド・クエスチョン(closed question)を推奨する

　×「□□は何ですか？」
　◎「□□は、こうだと考えていますが、正しいですか？」

■成功の勘所

質疑応答の手間を省き、正確さを追求するにはクローズド・クエスチョン(closed question)が向いている。特に、回答者にとっては、Yes/Noで簡単に返事できるのでとっても楽。

一方、質問者は丸投げ質問が許されないので、予め想定される回答案を自ら考えて文章化しないといけない。クローズド・クエスチョン(closed question)で書かれた中国の質問を読めば、仕様の理解度が一発で分かる。

業務知識を前提とした実装用仕様書

やっぱり、仕様書に常識はかかれない

入出力を中心とした詳細な実装用仕様書をいただいたが、よくみると業務知識があることを前提に書かれていたので、多数の仕様誤解を誘発した。

（第16回オフショア開発勉強会／ゲスト講師）

第16回オフショア開発勉強会で聞いた失敗事例より。

入出力を中心とした詳細な実装用仕様書をいただいたが、よくみると業務知識があることを前提に書かれていたので、多数の仕様誤解を誘発した。

この会社は、東京本社で請けた仕事を中国蘇州の開発子会社に委託する典型的なオフショア活用型のSIer。オフショア開発に着手する前には、必ず中国側で仕様書の品質チェックを行っている。中国側の事前チェックは評判が良かった。実際、このおかげで、過去に何度も事故を未然に防ぐ事ができた。ところが、前出のプロジェクトでは、暗黙のうちに中国に過度な業務知識が要求されていたため、受注可否判定プロセスが十分に機能しなかった。

■成功の勘所

中国側でレビューしたものの、業務知識が不足しているため仕様書の品質を評価できず、事前にリスクを洗い出す事ができなかった。この問題の対策は難しい。なぜなら、肝心な業務知識が欠落していると、関連するリスク分析の甘さを自覚することはできないから。適切な時期に、適切な人が集まって、適切な手順でレビューしたが、失敗を防げなかった残念ながら事例である。

仕様変更を伝えるタイミング

残業前提のスケジュール

中国は「休日返上はご勘弁」といいますが、日本側なんてここ３ヶ月間全く休みを取っていません。
（日本人読者）

日本本社と中国子会社との間で交わされる会話より。

「仕様変更の通達が遅すぎる！」と憤慨するのは中国子会社のプロジェクトリーダーＣさん。日本から提示された最終工程表は、まるで中国は土日を返上して作業するのが当然だと言わんばかり。なぜ、仕様変更の通達はいつも遅れてしまうのか。日本側の窓口担当者の悲痛な叫びに耳を傾けてみる。

こちらだって、中国に申し訳ないと思っています。それでも、仕様変更の通達が遅れてしまうのです。

お客様（元請け）から仕様変更の依頼を受けた時、その都度中国に伝達したら、現地は絶対に混乱してしまうだろう。実際、仕様変更が二転三転して、結局は元に戻った！、何てことも日常茶飯事。我々がお客様と中国の間に入って、仕様変更の優先度を見極めて、最も作業効率が上がるよう調整するから、このプロジェクトは何とか回っているのだ。

■成功の勘所

中国は「休日返上はご勘弁」といいますが、
日本側なんてここ３ヶ月間全く休みを取っていません。

残念ながら、日本側窓口担当者の苦悩は、中国子会社には全く理解されていない。日本側は、プロジェクト終盤の遅れを取り戻すため、中国側の休日出勤は当然だと思っている。会社トップは、最終的にお客様に迷惑をかけなければ、何をやってもいいという考え。

☆多発する「仕様変更」を上手に伝えるタイミングは？

◆即座にそのままの内容を伝えるべき
◆日本で調整してから間をおいて伝えるべき
◆その他（コメントボードにご意見を）

○結果を見る
○コメントボード

締切：2007年01月03日23時00分
協力：クリックアンケート

仕様書に「常識」は書かれない

だから仕様書は分かり難い

日本のSEが常識と思うことがあんまり詳しく書きません。でも、それが、ときどき中国の開発者にとって常識ではありません。

（中国人読者）

ある時は「常識」が我々を助け、ある時は「常識」が仕事の邪魔をする。例えば、歴史研究では「過去の常識」が研究者を悩ませる。実は、第一級の史料には、当時の常識があまり記載されていないため、現代の研究者ですら認識を誤ることがあるらしい。実際、私も自分で常識と思うことは、本誌で詳しく書いていない。つまり、無意識のうちに常識の部分を軽く扱ってしまうのだ。日本人SEにとって常識だけど、外国人IT技術者にとって常識でないことには、例えばどんなものがあるだろうか。

「常識」の例ですが、一番代表的なのが、「氏名」と思います。日本の女性が結婚後、自分の姓を夫の姓に従うのが、常識と思われますが、中国の開発者にとって、「常識」ではありません。姓を変えるのが、ありえないことだと思っているからです。

（中国人読者）

↑目からウロコが落ちました。ということは、中国では、氏名が
　変わることは絶対にありえないという前提で、氏名データが
　画面上で書き換え不能になることがあるのでしょうか。
　氏名データ修正するには、DBを直接書き換えないといけない？（幸地）

■成功の勘所

オフショア開発の仕様を説明する際、初めてのメンバーに対しては、いきなり仕様書を開く前に、対象となる業務や環境の背景についてたっぷり時間を割いてレクチャーしよう。余裕を持ったスケジュールが望ましい。

短納期の仕事では詳細仕様の理解は到底無理

中国人は技術偏重

中国人開発者は自分が詳細設計とコーディングの仕事だけできればいいと思いがちです。技術的なことだけ興味があるが、顧客業務の理解が大切だとは思わない。 （中国人読者）

小規模・短納期のオフショア開発は難しい。あるプロジェクトでは、プロジェクト終盤になっても詳細設計が決まらない。そのため、単体テストで本来やるべき試験の半分も実施できていなかった。

当初から、オフショア側の担当者も「危ない」という認識を持っていたが、発注側にせかされるまま、なんとか形を整えて納品した。その結果、客先での結合テストで不具合が続出した。発注者は、オフショアベンダーへの怒りを隠さない。詳細設計の遅れは認めるが、オフショア側に「危ない」という自覚があるのなら、納品後も何らかのフォローがあってしかるべきだと。

■成功の勘所

あなたのプロジェクトでは、オフショア側は「作る人」、日本側は「チェックする人」という暗黙の役割分担ができていないだろうか。短納期の仕事ではよくある話だ。原因をきちんと解明して、有効な再発防止策を立てよう。「以後、レビューを強化します！」と反省しただけでは、同じ失敗を繰り返すだけだ。

カタカナIT用語の乱用

カタカナIT用語

最近、日経システムを読む時、記事には普段よく使わないカタカナITの専門用語が出てきて、意味が分かりませんでした。英語でもあれば、助かると思いました。

（オフショア開発サポーターズ／中国人）

●今日は、オフショア開発サポーターズで議論が盛り上がっている「絶対にやってはいけない！ オフショア開発"AntiPattern"」から話題を紹介する。

　≪カタカナIT用語の乱用≫

日本のIT専門用語にはカタカナの外来語が多い。（Database→データベース、Server→サーバ）ところが、カタカナの外来語を読んでも外国人技術者には理解できないことがある。
英語の発音と近いときにはコンテキストから推測できるが、辞書を調べても分からない言葉もある。カタカナIT用語が氾濫する仕様書は危険だ。

■成功の勘所

有効な解決策（★★★☆☆）

・カタカナIT用語を使う時、英語の原文も明記する（日本）
・カタカナと英語の対照表を作成する（日本、中国）

TV会議で相手の顔を見るのは初回のみ？

中国(海外)とのコミュニケーションツール

皆様は、どのようなものを使用されていますか？ コミュニケーションにおいては、

1) 映像と音声
2) 音声
3) 文字

・・・の場合があると思います。
国内ベンダーさんの場合は気軽に電話で可能ですが、さすがに海外ですとお金の話が絡みますので・・・。

（日本人読者）

●ここ数年間のコミュニケーションツールの発達は、オフショア開発関係者に大きな恩恵をもたらした。かつてのＴＶ会議システムは、大企業の役員会議の経費削減に役立った（数千万円のコスト削減）。

最近では、個人のデスクトップでも、相手の顔を見ながら気軽に打ち合わせできるようになった。相手とファイル共有できるソフトもある。劇的な進化だ。

●ただし、オフショア開発の現場では、TV電話会議などの映像を主体とするコミュニケーションツールは思ったほど役立っていないという現場の声がある。

・Skypeを使っています。カメラを設置すれば使えますが、最初の一回ぐらいで、後は皆顔を見る興味がなくなって、音声だけにしています。しかし、重要な会議ではテレビ会議です。

　（中国人読者）

・TV電話会議をレビューや進捗会議で常時使っていますが、イメージの共有ができず時間がかかる(コストもかかる）という意見もでています。

（日本人読者）

■成功の勘所

TV会議(インターネット会議)システムを導入しても、相手の顔を見るのは初回だけで、現場ではファイル・画像の共有機能の方が重宝されるようだ。

読み手不在の仕様書

オフショア開発サポーターズの間で盛り上がっています

読み手が日本人でも、文書を書くとき、読み手のことを考えながら書く必要がある！！

（オフショア開発サポーターズ／中国人）

●今日は、オフショア開発サポーターズで議論が盛り上がっている「絶対にやってはいけない！ オフショア開発"AntiPattern"」から話題を紹介する。

≪読み手のことを考えないで仕様書を書き、中国側に渡す≫

読み手が日本人でも、文書を書くとき、読み手のことを考えながら書く必要がある。オフショア開ではその要求はもっと厳しい。
異文化と商習慣の違いが大きな壁だ。読み手が日本の人と想定して書いたドキュメントが、中国の開発者にとって、理解できないところがたくさんある。

もし、記述ミスやあいまいな言葉があれば、理解の難度がもっと高くなる。それにより、Q＆A（Question＆Answer）がよく出て（出ない場合があるが、それがもっと危ないことです）、仕様書作成の手戻りまでも発生する。

（オフショア開発サポーターズ／中国人）

■成功の勘所

有効な解決策

・背景知識（業務知識、法令、商習慣など）を中国側に伝える（日本）
・あいまいの言葉を使わない（日本）。
・中国人のBSEにレビューしてもらう（日本）
・簡単な図表とサンプルを盛り込む（日本）

英語や数式、業界用語で補足

勝手な理解でモノを作り始めます

中国人は、日本語を勉強していなくても日本語をある程度読んで、勝手に理解してしまうため、重要なことを文章だけで表現していると、大きな誤解をまねきかねません。 （日本人読者）

●ある日本人読者のご意見。

我々が英語の文章を理解するのと同様に重要な単語と、しっかりとした図式があるほうが、細かい説明より正確に伝わるということを理解すべきです。中国と日本は同じ漢字でも意味が違うことがあるため、共通語となる英語や数式業界用語で補足したり、説明を加えることも必要ですし、そういう違いを日本側のＳＥも理解していく必要があります。

そういう意味も踏まえて、日本人がどんどん現地を訪問すべきと思います。現地にいくコストより、手戻りコストの方が高いはずですから。
（日本人読者）

↑「オフショア開発新常識」の情報提供メールが30件超えました。感動です。ありがとうございます。　「中国と日本は同じ漢字でも意味が違うことがある」とのご指摘ですが、どのような事例がありますか。（幸地）

　(例) 空白、空色、「チーム結束して頑張ろう」

■成功の勘所

読者アンケートでは、59％(16票)の方がプロジェクト毎に用語集を作成していると回答してくれた。予想外の中間報告だが、意識の高い会社が増えたのだと実感した。特に３年以上継続して同じ中国ベンダーに発注する会社では、著しい成果が上がっているという報告を受けている。

用語集つくってますか

用語の統一は必要です

優秀なＢＳＥはここはかなり細かくチェックして質問してきます。例えば、社員コードと従業員コード等、DBは従業員コードで画面が社員コードというような矛盾は多い。

（情報システム部門／日本人）

●オフショア開発で「用語の統一」がどれほど大切かお分かりだろうか。興味ある方は、前出の「社員コードと従業員コード等の矛盾」が及ぼすコミュニケーション増加のコストを計算してもらいたい。

●他にも「見積もり」と「見積」。同じ仕様書内の送り仮名の違いがどのように影響すると思われるだろうか。中国オフショア開発実践セミナーでは、具体例を挙げて詳しく解説している。

●実際の現場では、詳細設計でどんな工夫を凝らしているだろうか。読者の声に耳を傾けてみよう。

基本は、こちらから要求仕様に対して、すぐに判断出来る人材が中国へ行き、関係者を集めて打ち合わせをやること。ポイントでのレビューは重要です。設計書は手抜きせずにしっかり書くこと。文章ではなく図解や数式が必要。

いいかげんな例示はあだになるので、例示する目的にあったものをしっかり作ること。
（情報システム部門／日本人）

↑○○様、お久しぶりです。「用語の統一」は地味ですが重要な作業ですね。ユーザー企業から中国に直接発注する場合、やっぱり用語集の効果は絶大ですか。（幸地）

■成功の勘所

従来から、オフショア開発では「用語集」の作成が欠かせないといわれてきた。だが、小規模・短納期プロジェクトが大半を占める現場では、真面目に「用語集」を作成する暇はないのではないか。

◆プロジェクト毎に用語集を作成します
◆たまに用語集を作成します
◆ほとんど用語集を作成しません
◆用語集は必要ありません
◆その他（コメント欄にお書きください）

○結果を見る
○コメントボード

締切：2006年10月10日23時00分
協力： クリックアンケート

できあがった物を見てから修正する

中国企業の顧客に関する意識

会社経営者にとっては「お客様」。

だが、一人一人の技術者にとっては、顔の見えない「ユーザー」。指示されれば当然やるが、頼まれもしないことをやろうという発想はない。
（第4回上海オフショア開発交流会 ゲスト講師 山中氏）

■できあがった物を見てから修正する・・・日本の設計は甘い!

●中国側でオフショア開発に携わる多くの技術者は、自分が作ったシステムが、どんな顔のユーザーがどうやって利用するのか、全く知らない。

プロジェクトチームの大半を占める経験の浅い若手技術者の場合、運用者、利用者の立場に立って考える、ということを期待できない。

●一方、オフショア開発を発注する日本企業にとって、顧客やサービスとは以下のようなイメージを持っている。

　「中国に仕事を出してあげている」
　「お客様は神様」
　「ソフトウェア産業はサービス業」

●「とにかくモノを見ないと分からない」といって、曖昧な仕様のままモノづくりに入るのが日本流（日常業務では私もそうしている）。

だから、出来上がったものをモノを見て、気に入らない箇所を修正する。良くも悪くも、こうしたやり方がまかり通るのが日本流である。

　・修正が入るのは当たり前、やむを得ない
　・顧客が直したいと望んでいるのだから、直すべき
　・修正要望に臨機応変に対応するのもソフト会社の力量の一つ

■成功の勘所

上海オフショア開発交流会 ゲスト講師 山中氏によると、「できあがった物を見てから修正する」というやり方に対して、多くの中国人技術者は否定的な見解を持つという。

・本来設計にかけるべき時間と労力を省いている
・想像力や検討する力が欠けている
・能力の低い技術者が設計している

ちなみに、「顧客が望めば、何でも修正してあげたい」というのも中国企業の本音である。ただし、追加料金を払ってくれれば。

「会話の土俵をあわせる」の真意

仕様書の記述法やコミュニケーションの留意点

大幅なコスト削減が見込めるとして盛んに行われている中国オフショア開発。しかし実際には、納期や品質などの面で様々なトラブルが発生している。先行した企業は一体どんなトラブルに見舞われたのか。（日経ITプロフェッショナル／幸地司）

■「会話の土俵をあわせる」の真意はいかに？

●今年4月に日経ITプロフェッショナルに寄稿した記事が同誌ホームページで公開された。全文を閲覧するには無料のユーザー登録が必要だが、興味ある方はぜひ一読していただきたい。

記事は、仕様書の記述法やコミュニケーションの留意点など、中国オフショア開発の成功率を高めるポイントを解説したものである。

●IT Pro登録ユーザーは、記事に対して誰でも気軽にコメントを書き込めるようになっている。今日は、コメントの一部を紹介しよう。

-----Original Message-----

オフショア開発に従事した事のある身として、興味深く読ませて頂きました。しかしこの記事では結論として「日本（発注側）が中国（受注側）に合わせろ」と言っています。

結局はコストの問題ですが、単発の開発ではまず間違いなく、中国に発注するよりも国内で開発した方が安く上がります。この点は認識されているようですが、問題は２回目・３回目の継続開発が中国では難しい点です。

一般的に中国人技術者は流動性が強く、次期開発では主要ＳＥがいない事は頻繁です。さらに権利意識が強いため、必ずや２回目以降は大幅な値上げを要求されます。

また業務システムとなると日本の商慣習を理解せず、理解しようとする姿勢も薄いため、チグハグなシステムを作りがちです。数年前から「今の損を恐れて中国に開発を出さないと数年後に乗り遅れる」という事でオフショア開発に手を出した企業も多いのですが、現在でその果実を手に出来た企業がどの位あるのでしょうか？

↑コメントありがとうございます。現場の貴重な生情報です（幸地）

●ただ残念なことに、上記コメントは記事の主張を誤解している。

> 「日本（発注側）が中国（受注側）に合わせろ」

この解釈は間違っている。私はいつも「会話の土俵をあわせよ」と主張しているが、一方的にどちらかの流儀にあわせるべきだとは思わない。

●現場を見れば、中国側が"日本型開発アプローチ"に歩み寄っているのが一目瞭然である。日本のIT業界では、受注側が発注側にあわせるのが通例なのだ。

●後半部分については、「間違いなく」や「必ずや」の部分に感情の高まり(憤り)を感じるが、中国オフショア開発の一面を見事に言い表していると思う。

全体的に中国側にとって厳しいコメントだが、私たちオフショア開発の推進者は、こうした現場の声を真摯に受け止めたい。

■成功の勘所

ここで、新しい発想を取り入れてみよう。

「日本流」の開発スタイルは存在する。同様に「欧米流」のそれも広く認知されている。

ところが、「中国流」の開発スタイルはいまだ確立されていない。（ご意見求む）

したがって、「日本が中国にあわせる」という発想はそもそも成り立たない。この考え方、いかがだろうか？

中国語、英語、ボディーランゲージ

日本と中国人の英語、現地ではこんな会話がされている

最近の中国オフショア開発の流れを見ると、沿岸部からより人件費の安い内陸部へのシフトが加速している。しかし、中国内陸部の地方都市では、日本語が堪能な人材が圧倒的に不足しているのが現状だ。

そのような場合、双方の母国語でない英語での会話を余儀なくされることもある。その際にはどのように対応すればよいのだろうか。

＠IT情報マネジメント：現地ではこんな会話がされている

■言葉が通じないなら、ボディランゲージを使え

●日本最大のIT情報サイト＠ITで連載を始めてから、あっという間に１年が経った。

詳しい数字は明かせないが、＠ITに掲載される多くの記事の中で常にトップクラスの閲覧数を誇っているという。

実にありがたい。感謝感謝。

本誌や＠IT連載の読者が増えるに従い、各方面から様々な声が寄せられるようになった。メルマガ発行人として、最も嬉しいことだ。

-----Original Message----- Sent: Thursday, September 29, 2005 11:59 AM

＠ITの記事をみました。
中国とオフショア開発をしておりますが、基本的に日本語を使っております。

しかし、おっしゃるとおり、日本語は表現が難しくわからない場合もあるようですので、その場合は片言の英語で補足します。

その方があいまいな部分を減らすことができます。プロジェクトの開始・終了時に中国へ訪問しますが、ご指摘の通りプログラマレベルでは日本語は話せません。　そうすると中国語での筆談を行います。（私は中国語が少しわかりますが・・）

もともと大学で中国語を勉強していたこともありオフショア開発の担当者になったようなものです。

言語として、ネイティブが使えればいいものの世界共通語としての英語も使うのは意義はありません。使えるものは使う。例えボディランゲージでもです。

↑コメントありがとうございます（幸地）

■成功の勘所

私は学生時代に点字のコンピュータ化を研究していた。また、社会人になってからは手話サークルに入って、言葉以外のコミュニケーション法を学んだ。

「使えるものは使う。例えボディランゲージでも」とは、異文化コミュニケーションに役立つ重要な発想であろう。中国ビジネスの現場では、実際かなり重宝するのでお試しあれ。

すべて日本語(67%)

あなたの会社のオフショア開発で使用する言語は何ですか。

国によって異なるし、現場で工夫する点も山のようにあるだろう。詳細な点は、ぜひコメント欄にお書きください。

◆ドキュメント、会話も含めすべて日本語
◆原則として日本語だが、ときどき英語も使う
◆ドキュメントは日本語、会話では英語をよく使う
◆ドキュメント、会話も含めすべて英語
◆その他（コメント欄に詳細をお書きください）
○結果を見る
○コメントボード

締切：2005年06月09日23時

ドキュメン�