ホーム アンド アウェイ ネイティブ言語を使う場合は、ネイティブ側が会話に責任を負うべきであると思う。 （インド開発現場／日本人SE）
日本向けインドオフショア開発の現場から、日本人ブリッジSEが体験した小ネタ＆TIPSをお届けします。
～インド現場便り vol.4～
日本人エンジニアの英語力が低いといわれている根拠にTOEIC スコアがあるが、TOEIC 受験者数の過半数が日本人であるというのも事実である "※TOEIC Newsletter 89号(2005年1月)" 。
※TOEICテスト公式データ http://www.toeic.or.jp/sys/letter/News89_7111.pdf。
インド人のエンジニアにTOEICテストは知っているか？ と聞いても存在すら知らない事が多い。筆者がインドオフショア開発に携わる以前のTOEICスコアは230点であった。
一般的な日本で英語教育を受け(日本の英語教育がどうであるかという議論はあるが・・・）、その後場慣れする場があり、場慣れしただけなのである。
また追記しておくべき事として、英語には大なり小なり母国語のアクセントが影響してくるが、筆者はインドの英語アクセンスに場慣れしてきたので、その他の国の英語のアクセントは慣れていない。
情報提供：向井永浩 Softbridge Solutions (Japan) Co Ltd http://www.softbridge.jp
■問いかけ
あなたは、オフショア開発の成功に必要な英語力を持っていますか。この問いかけのキモは、ある”能力”をどのように定義するかにかかっています。能力を２つに大別して、考察するとよいでしょう。
１．現在持っている知識、技能 ２．将来に渡り成果を発揮しつづけるだろう能力
例えば、英語が流暢にしゃべれるからといって、誰もが国際ビジネスで活躍できるわけではありません。能力１があっても、能力２が不足しているからです。
信頼関係が大事というが オフショア開発者は、念仏のように「信頼関係」を唱えますが、そもそも「信頼」の定義が曖昧なので、議論に一貫性を欠きます。 （幸地司／オフショア大學）
オフショア大學の今週のテーマは「コーチング」と「信頼関係」。メイン講師はオフショア開発PRESS を執筆した根本隆吉氏(*)。私は、裏方にまわって受講生の理解を深めるアシスタントに徹します。
*オフショア開発PRESS「中国工場に学ぶオフショア開発の極意」 http://press.1offshoring.com/
コーチング講座では、ラポールという信頼の架け橋が重要だと教えられます。ところが、泥沼化したオフショア開発の現場で「信頼関係」と叫んだところで、問題解決には全く寄与しません。
私たちは、可視化された操作可能な変数にこそ注意を払わないといけません。オフショア開発で「信頼関係」を口にする者がいれば、あなたは条件反射的に警戒しましょう。相手は、信頼関係を測る可視化された変数（基準値）など持ちあわせていないから。
オフショア大學「コーディネート概論」で出題された問いかけより。
問１ 信頼関係を定義しなさい 問２ オフショア開発で信頼関係が重視される理由を述べなさい 問３ 信頼関係を強化する方法を論じなさい
【前提条件】 あなたの部下、もしくはあなたの後輩に向けて説明する場面を想定。
【制約条件】 マネジメント経験がほとんどない20代の若手技術者に説明するつもりで、分かりやすく、具体的に回答すること。
印刷設定への配慮は過剰サービスか？ 詳細設計書をエンドユーザ様が読まないのであれば、電子媒体のみで良いし目を通してくれるのであれば、印刷を前提にするということであると思う。 （読者アンケート掲示板より）
ある中国オフショア拠点で、印刷設定への配慮不足が問題となりました。日本人駐在員が「MS-Excel設計書は危険なので、印刷プレビューして、ページ割り付けを確認してから日本に送付すること」と何度も指導したのに、確認怠りが３度も続きました。
この状況を目の当たりにして、日本人駐在員は激怒しました。ところが、当の本人は「そんなことは初耳」と言わんばかりに、ケロッとした顔でこちらを見つめます。
なぜ、この中国オフショア拠点では、「印刷プレビュー」を怠るという同じ問題が３度も続いたのでしょうか。あなたの仮説を立てなさい。必要なら、自社の状況に応じて前提条件＆制約条件を設置すること。
第27回オフショア開発勉強会の日程決まりました
次回のオフショア開発勉強会の日程が決まりました。
第27回目の東京場所は、7/25(金)夕方です。 しかも、ゲスト講師のご厚意により、特別３時間コースとなります。 演習をたっぷり、事例も満載なお得な勉強会です。
人数限定なので、スケジュールを空けておいてくださいね。
テーマは「CCPM（Critical Chain Project Management：クリティカルチェーンプロジェクト管理）と分散開発」。
申込み方法は後日案内します。
新興国ならでは インド開発現場には、電子データに印刷設定をするという習慣もない。またエクセル等を印刷した際のことを考慮し、罫線を引くということもあまりしない。 （インド開発現場／日本人SE）
～インド現場便り vol.2～
多くの日本人エンジニアは印刷設定のことを考慮せずに、ユーザに送付するのは失礼と感じている人も多いだろう。しかしプリントアウト前提の考え方は問題あるのではないか？
われわれ日本人エンジニアはインド開発現場を見習うべきではないと感じる。ペーパレス化はインド開発現場の方が浸透しているのではないかと感じる。
読者からのご意見
・仕様書作成でも「印刷」を考慮したデザインは重要ですね。赤・青・黄等の色を駆使して、「カッコいい＆分かりやすい」仕様書を作って出張しても、仕様書説明ではモノクロ印刷のものを持っているPG君達。「赤い線が指す部分は」「青いエリアは」なんて説明しても、自分以外はみんなグレーだったり（笑
・弊社では、新人の時からプレビューの確認を徹底するよう指導しています。それは会議やレビュー作業の際、紙を配布、紙で確認する文化だからです。膨大なドキュメント量を画面で確認していくのが辛く、紙に出して確認する方が楽だからです。私自身も変える見込みが立ちません。
あなたの周囲を見回して、紙資料を確認してください。無駄に印刷されたMS-Office などの資料はありませんか。たまに、電子データの印刷設定を無駄と思うことはありませんか。ペーパーレス化について、日本はオフショア拠点に学ぶべきだと思いますか？
◆そう思う ◆そう思わない ◆その他
○結果を見る ○コメントボード
締切：2008年06月26日23時00分 協力：クリックアンケート
～インド現場便り vol.1～
現在、私は日本の開発現場で勤務している。周りの多くの日本人エンジニアは設計書をプリントアウトして開発をしている。これはすなわちプリントアウト版と電子データ版との文章２重管理である。ここで問題なのが、変更が入った場合である（開発フェーズに入ったら原則設計書に変更すべきではないのだが・・・）。
変更が入ったら再度プリントアウトするのである。しかしプロジェクトも忙しくなってくると、この２重管理でギャップが生じる場合も度々ある。
一方、インド開発現場では設計書等をプリントアウトするという習慣が殆んどない。開発者は全てパソコン上で確認する。従って上記のような問題は生じない。
しかし電子データに印刷設定をするという習慣もない。またエクセル等を印刷した際のことを考慮し、罫線を引くということもあまりしない。そもそも特定のＰＣ以外はプリンタがインストールされていないので、ワード＆エクセル等の印刷プレビューボタンがグレーアウトしているのである。
あなたの会社で、MS-Office などの電子文書が印刷配布されることを考慮しながら作成される工数と効果の関係を洗い出しなさい。無意味な作業はなくすべき。有意義な作業なら継続・改善すればよい。
文責：幸地司（オフショア大學）
●米国人にとってやっかいな中国式交渉の特徴をなす８つの要素。
1. Guanxi (Personal Connections) 2. Zhongjian Ren (The Intermediary) 3. Shehui Dengji (Social Status) 4. Renji Hexie (Interpersonal Harmony) 5. Zhengti Guannian (Holistic Thinking) 6. Jiejian (Thrift) 7. Mianzi ("Face" or Social Capital) 8. Chiku Nailao (Endurance, Relentlessness, or Eating Bitterness and Enduring Labor)
出典:“The Chinese Negotiation,” Harvard Business Review, Vol. 81, No. 10, October 2003. John L. Graham and N. Mark Lam
和諧 整体観念 関係 中間人 吃苦耐労 節約 社会等級 面子
上記１～８の特徴とＡ～Ｈの単語を結びつけなさい。次に、なぜ米国人は、前出の８つの特徴にとまどうのかを答えなさい。
さらに余力があれば、次の問いにもこたえなさい。
・日本人なら素直に受け入れられる中国式交渉の特徴はどれか？ ・米国人と同様に日本人もまごつく中国式交渉の特徴はどれか？
上記問いかけに対する私の見解は、今夜のオフショア開発勉強会で発表します。今月のテーマは「文化的相違を考慮した交渉術」。
詳細→ http://www.ai-coach.com/seminar/workshop.html
国内向けプロジェクト計画書を流用しましたが 中国ベンダ向きに書き換えて内容を説明し、承認印をもらい、現地へ行って通訳を交えてメンバーへ説明もしましたが、あまり効果はあがりませんでした。 （日本人プロジェクトマネジャー）
初めての相手とオフショア開発する際には、マネジメント業務で要求される管理帳票や各種ツールの説明だけで軽く一日を要する。管理ツール一式を電子媒体で送りつけるだけで対面による説明のプロセスを省略してしまうと、後で痛い目に遭う。
ところが、進捗報告やバグ票のテンプレートを用意して、記入法を丁寧に説明しても失敗を防げなかったとの報告があります。
・ブリッジSEが消化不良を起こした ・現場レベルで記入法や運用規約が守られなかった
■成功の勘所
ほとんどの組織では、上記の対策として管理項目が具体的に可視化された分かりやすいチェックリストを用意する。その結果、次回のプロジェクトでは首尾よく成功を収める。ところが、次の次の機会に再び悪夢が襲ってくる。また同じ失敗を繰り返す。
いったいなぜ？ あなたの考えを送る → mailmag@ai-coach.com
原因不明のエラーが発生したとき 日本側は自分に問題があることを前提に調査しますが、オフショア側は「自分達の処理は問題ない」という前提で調査を行っているように感じました。 （オフショア大學）
次の見解の相違は、文化的相違が原因だろうか？
・中国では作る人とチェックする人の役割分担が明確なので、一通り動作する時点でプログラマの製造責任は果たされた。その後の詳細確認は、プログラミングとは別工程であり、仕事の依頼者（プログラマの上司、または発注者）が品質保証に責任を持つべきである。
日本的風習→プログラマが最終の品質保証にまで責任を負う
・中国ベンダ内の試験に合格した納品物を本番環境に配備したら、原因不明の不具合が発生した。もしも、中国側の責任なら無償修正に応じるつもりだが、単体試験は合格しているので不具合分析は日本側の責任である。
日本的風習→問題発生時、作った本人が現場に急行して不具合分析
オフショア開発者が異文化コミュニケーション論を学ぶ意義は、人と問題を分離して不具合原因を個人的資質に求めすぎないようにするためである。
【×】また問題が発生した。これは担当者Ａさんが悪い。プロジェクトからＡを外せ。
【◎】また問題が発生した。これはＡさんの個人的資質ではなく、文化的相違に起因する。だから、Ａさんへの個人攻撃を避けて、組織全体で対処すべきである
外国語が聴き取れない 「外国語が聴き取れない」ことを認めるのはプライドを傷つけることだと思っているようです。 （オフショア大學）
●オフショア大學の発言より。
・中国人プログラマは、他業種の人と比べて言葉の表現に乏しい。簡単に「やりません」「できません」というが、よく状況を確認すると、諸問題があって実現が難しいこともある。だが、報告を受ける側としては、やる気のない消極的な態度にも感じられる。
・日頃の雑談では、聞き取れなくて確認をするのは恥ではなく、確認を疎かにしてトラブルを起こすことこそ恥ずかしいことだと話している。「分かったふり」が原因でトラブル発生するリスクに無頓着なことが問題である。
・中国人プログラマは、中国語であっても”報告・連絡・相談”の表現力に乏しい
・中国人の中級プログラマにとって「日本語を聴き取れない」とは面子がつぶれると同義
「あうんの呼吸」をやめて組織を強くする アンケートの結果、回答者のうち85％が職場で外国人と一緒に働いたことがあると答えた。このうち、意思の疎通に問題があったかどうか聞いてみたところ、「ある」と答えたのは71％に上った。 （日経ビジネスオンライン）
オフショア大學コーディネート概論第２週目の課題は、異文化コミュニケーション・マネジメントについて。「待ってました」とばかりに白熱した議論が繰り広げられるかと思いきや、意外にも慎重な発言が目立ちました。
文化の壁によって生じる業務上の問題を列挙せよ、というのが課題ですが、オフショア開発で発生する諸問題を何でもかんでも「文化の壁」と帰着する事に抵抗を感じたのかもしれません。また、商習慣や価値観の違いを「文化の壁」と言っていいのか迷ったのかも しれません。
日経ビジネスオンラインが調べた外国人と一緒に働くうえで感じた問題点や課題によると、職場で意思疎通を妨げた要因の第一位は価値観の違い(54%)、次いで言語の違いが30%でした。
第一位 価値観の違い(54%) 第二位 言語の違い(30%) 第三位 文化や宗教などの違い(12%) 第四位 特に影響を受けていない(4%)
「あうんの呼吸」をやめて組織を強くする http://business.nikkeibp.co.jp/article/manage/20080606/
異文化コミュニケーション・マネジメントの出発点は、互いの「違い」を認めること。あらゆる現象を”文化の壁”と称する態度は慎むべきだが、同様に「何でも話し合えばわかる」と考えるのも早計。真面目な人ほど自社や自国の欠点を並べるが、文化論においては批判や博愛主義はどちらも思考停止と同じである。
中国から納品されたソースコードを眺めていたら オープンソースの無料ソフトからソースコードが勝手に流用されているようです。どう対処すべきでしょうか？ （日本人SE）
●次のケースを読んで、後述する問いに答えなさい。
中国から納品されたモジュール一式の受け入れ検査が急ピッチで進みます。機能要件の確認が済み、必要書類も揃っていることから、まもなく検収です。
今後の保守・改修を見据えて、今のうちから少しずつソースコードに目を通しておこうと思います。すると、モジュールの一部から、これまでと雰囲気が異なる箇所が見つかりました。
コメントのスタイルが違います。 コーディングスタイルが違います。 よく見たら、全く知らない copyright (c) が含まれています。
どうやら、勝手に第三者が作成したオープンソースの無料ソフトのソースコードが流用されているようです。現在、日本側で気づいているのは、私だけ。
納期遅延は絶対に避けたいところですが、検収後は完全に日本側で保守メンテする約束になっています。いったい、どうすれば良いでしょうか。
●問い
もしあなたが保守・改修作業を引き継ぐ担当者だとしたら、問題視される外部ソースコードの流用部分をどうするか？
中国から納品されたソースコードを眺めていたら 発注者への相談もないまま勝手にオープンソースの無料ソフトが使われているようです。どう対処すべきでしょうか？ （日本人SE）
今後の保守・改修を見据えて、今のうちから少しずつソースコードに目を通しておこうと思います。すると、モジュールの一部が、私の知らない外部ソフトを呼び出していることに気づきました。
どうやら、発注者への相談もないまま勝手にオープンソースの無料ソフトが使われているようです。現在、日本側で気づいているのは、私だけ。
もしあなたが保守・改修作業を引き継ぐ担当者だとしたら、問題視される外部ソフトの呼び出し部分をどうするか？
[PR] 2008年6月16日オフショア開発勉強会（東京） 「文化的相違を考慮した交渉術」にて、このような交渉の勘所を扱います。 http://www.ai-coach.com/seminar/workshop.html
オフショア側の方が効率がよい領域 あまり「効率がよい領域」が思い当たりません。 （日本人）
オフショア大學「コーディネート概論」は、今週から第２週目に突入。先週は、管理姿勢の強弱やオフショア拠点に委託可能なマネジメント領域について議論した。初回の課題には、81件の書き込みが寄せられた。
* オフショア大學「コーディネート概論」の授業は100%サイバー空間で行われます。 http://www.offshoringleaders.com/
先週は、オフショア開発をいくつかの観点で分割して、厳しい管理で臨む場面と、自主性を重んじる支援型の管理で臨む場面とに分けて議論を進めた。
例えば、中国側の力量を正確に見極めた結果、下記方針で成功を収める日本企業が報告された。
・アーキテクチャ設計は日本側がソースコードレベルで担当 ・いざとなれば日本側でソースを修正できる体制を維持
日本側が自社で対応すべき活動領域を中核活動といい、アウトソース可能な活動領域を代替可能活動という。この両者の見極めは、オフショア開発の成功に直結する。
オフショア開発の管理方針 オフショア開発プロジェクトでは、カリスマ的なリーダーシップを発揮した厳しい管理が有効だと思いますか？ それとも、支援型の目立たないリーダーシップによる自律性を尊重する管理が有効だと思いますか？ （オフショア大學／今週の討論テーマ）
先週末から始まったオフショア大學「開発コーディネート概論」では、毎週替わる討論テーマに沿って、クラスで各自の体験を共有する。
今週の討論テーマは「厳しい管理、支援型の管理」。管理方針について「厳格型か支援型か」と二元論的に質問されると、私たちは、つい「自律を重んじる支援型の管理を・・・」と答えてしまいがちだ。ところが、よく考えると、これは意地悪な問いかけである。
管理方針には、原則として善悪はなく、組織によって向き不向きがあるだけである。つまり、厳しい管理が相応しい工程もあれば、支援的な管理が相応しいチーム構成もある。
厳格な管理方針で知られるＡ社は、委託契約にも関わらず、受託企業Ｂ社のメンバの出退勤にまで口を出すという。
「ある日、Ｂ社のＰＬが私用のため事前に休暇申請を出したら、お客様であるＡ社から拒否された」
休暇申請の却下理由を確認すると、仕事が未完成のうちは「社会人として休む資格はない」とのこと。これは、国内オンサイト開発での出来事だが、話題を提供してくれた中国人オンサイト技術者のモチベーションは一気に低下したという。
[PR]”社会人だから・・・”という言い訳が日本で通用する理由を知りたい方へ オフショア開発PRESS特集３をご覧あれ！ http://press.1offshoring.com/index.html
多国籍チームでは、「社会人だから・・・すべき」の理屈は通用しないことが多い。その理由を合理的に説明しよう。
・なぜ日本では「社会人だから・・・」が通用するか？ ・なぜ多国籍チームでは「社会人だから・・・」が通用しないか？
次に、多国籍チームを率いる際に「社会人だから・・・」の代わりに使える理屈や言い回しをそれぞれ１つ以上挙げなさい。
オフショア拠点との共通リポジトリを用意したところ CSV では日本語名のファイルが作りにくい事、ディレクトリ構成を後から変更できない事があり、最初に見通せなかった日本スタッフが途中で CSV を使うのを止めてしまいました。 （オフショア大學受講生の体験談より）
Ｑ＆Ａ管理、バグ管理そして構成管理は、オフショア開発で必須とされる三大管理業務である（と勝手に定義）。ツール導入の投資効果が大きいため、小規模プロジェクトでも早い時期から環境整備が進んだ。
ところが現実には、オフショア開発で”何とか管理”の仕組みを導入したところ、日本側が対応できずに管理が形骸化してしまう。よくある話である。
新しいことに挑戦して、失敗から学ぼうとする姿勢は立派だが、現実には忙しすぎて日本側には内省する暇などない。若手主体の中国企業には、内省の習慣すらない。だから、現場は疲弊する一方である。
だが成長する組織は、失敗から学ぶ。日本側がCSV 運用を辞めてしまった前出の会社では、日本語のファイル名を扱えるツールに切り替えて、さらに、ソースコードだけではなく仕様書も同時に構成管理の対象とした。
共通リポジトリによるツールを使ったコードの共同所有によって、日本側で修正して例示したソースコードが中国側にも伝わるようになったと報告された。構成管理はfool proofとして絶大な威力を発揮する。
その一方で、責任分担の切り分けという重大な課題が残る。日本側がソースを修正した影響範囲の検査や納品後の瑕疵担保責任など。
あえて技術力よりも日本語能力を優先する風潮 現在の中国オフショア開発では、残念ながら高い技術力は求められない。そこで、我が社では、中国人IT技術者を採用する際には、設計やプログラミングの能力よりも、日本語力を優先する。 （中国でよくある発言）
上海では、優秀な中国人IT技術者がなかなか採用できず、各社とも苦労している。上海で約100名の技術者を抱える日系現地法人のマネージャに、「優秀さ」とは何かを問うてみた。
優秀さ１：今、～ができること 優秀さ２：将来性を秘めていること
前者を職能という。職能給制度では、従業員がどんな技能を有しているか、どんな資格を有しているかで評価される。職能とは、業務遂行に必要な知識やスキルを指す。
一方、後者をコンピテンシーという。たまに、コンピテンシーを行動特性と訳す人がいるが、避けたほうが無難である。なぜなら、この日本語訳では、本来の意味の一部しか表現できていないから。コンピテンシーとは、将来の成果につながるあらゆる能力である。
問いかけ
・現在の中国オフショア開発では、残念ながら高い技術力は求められない。そこで、我が社では、中国人IT技術者を採用する際には、設計やプログラミングの能力よりも、日本語力を優先する。
これは、職能ではなく、コンピテンシーを優先した採用基準といえるだろうか？
答え → mailmag@ai-coach.com
[PR] 正解はオフショア大學で詳しく扱います http://www.offshoringleaders.com/02curriculum/02.htm
問いかけのヒント
日本語能力を優先する理由によって、答えは変わる。
もし、あなたが外国人技術者を採用する立場なら、下記２つの優秀さのうち、どちらを優先するだろうか。明確な根拠とともに答えを１つ選びなさい。
上海市ITアウトソーシング推進当局の現状分析 上海市ITアウトソーシング推進当局では、発展途上の中国ソフト企業はPMBOKやCMMIを十分に活かしていないと現状分析する。最下層の初級プログラマを大量に輩出する仕組みは整ったが、対日オフショア開発に対応できる高級人材は圧倒的に不足したまま。 （上海市信息服務外包発展中心(iISO)主任）
2008/5/12、上海にてオフショア開発PRESS創刊記念セミナーが開催された。セミナー前後の雑談中に、最も盛り上がった中国IT人材に関する話題を１つ紹介する。
写真付き簡易報告はこちらから。 http://aicoach.tea-nifty.com/offshore/2008/05/press_fe19.html
「中国には優秀な人材が豊富にいる」という発想は無意味である。国土が広く、言葉や習慣も異なり、個人のバラツキも大きな人々をひとくくりに分類してはいけない。
上海市ITアウトソーシング推進当局は、高級人材の育成に力を注ぎたいというが、「高級」の定義が日本企業の感覚とは大きくズレている。そこで、我々は独自に中国IT人材を６つの水準に分類した。
A層：安心して全てを任せられるプロジェクトマネージャー層 B層：日本語が堪能なリーダー層 C層：日本語を多少なりとも理解するサブリーダー層 D層：一人でコーディングできるプログラマ
ここまでは、対日オフショア開発で戦力となる人々。ところが、実際には、戦力外ともいえるプロジェクトの足を引っ張る二階層が存在する。
E層：他人の指導を受けながらコピペで製造するコーダー層 F層：MS-Office文書を使えるだけのテスタ層
上海市ITアウトソーシング推進当局がオフショア大學に期待を寄せる「上級人材の育成」とは、上記Ａ～Ｆ層のうち、どこを対象とした取り組みでしょうか？
答え → mailmag@ai-coach.com （あくまでも雑談ネタです）
[PR] オフショア大學「オフショア開発コーディネート概論」 http://www.offshoringleaders.com/02curriculum/02.html
あなたも独自の基準で、自社に必要なオフショア開発技術者を分類してみよう。例えば、上記のＡ～Ｆ層を一覧表にして、それぞれの保有技術、要求されるコンピテンシー、給与水準を書き込んでみよう。
上海市ITアウトソーシング推進当局の現状分析 ・世界標準のマネジメント体系は中国でうまく適用されない ・対日オフショアリング向け上級人材が足りない （上海市信息服務外包発展中心(iISO)主任）
・世界標準のマネジメント体系は中国でうまく適用されない ・対日オフショアリング向け上級人材が足りない （上海市信息服務外包発展中心(iISO)主任）
2008/5/12、上海にてオフショア開発PRESS創刊記念セミナーが開催された。オフショア開発PRESS特集1を執筆された上海オフショア開発フォーラム事務局様を中心とするボランティアスタッフの活躍により、盛大なイベントとなった。
セミナーに先立ち、当日の午前中にオフショア大學と上海市ITアウトソーシング推進当局（iISO）は、90分近く事業化を前提とした交渉を行った。午後のセミナーでiISO主任様が概要について言及したので、私からも核心部分をぼかしつつ補足説明したい。
上海市ITアウトソーシング推進当局では、発展途上の中国ソフト企業はPMBOKやCMMIを十分に活かしていないと現状分析する。最下層の初級プログラマを大量に輩出する仕組みは整ったが、対日オフショア開発に対応できる高級人材は圧倒的に不足したまま。
そこで、オフショア開発コーディネータ人材育成に定評がある私のところに白羽の矢が立ったというわけだ。続く・・・
中国人はいきなり交渉から入るので疲れる 中国人と日本人と対峙するとき、それぞれ話し方のモードを切り替える。中国人とは最初から単刀直入に、日本人とは１回目の話ではさわりだけ。きっと２回目に確信部分が出てくるので、そこである程度切り込む。 （日本人マネージャー／本誌 2006/11/17 号より）
国民文化の違いは、交渉のスタイルに影響を及ぼす。例えば、交渉を敵と味方に分かれた”勝ち負け”を決める手段とみなすか、それとも互いに情報を共有し、長期的に価値を分かち合うための手段とみなすかは、国民文化によって大別される。
・米国式＝（勝ち負け／短期／契約ベース） ・日本式＝（ ） ・中国式＝（ ）
異文化マネジメントの研究が発達した米国では、文化の構成要素を取り出して、業績に与える影響を様々な角度から検証してきた。その知恵を、中国オフショア開発の問題解決にも役立てたい。
【交渉に影響を与える文化の構成要素】
・交渉で得られるモノ（勝ち負けで一方が総取り／仲良く山分け） ・交渉で大事なこと（契約／人間関係） ・意思伝達の方法（直接的／間接的） ・リスク耐性（許容／回避） ・時間軸（敏感／鈍感） ・時間軸（短い／長い）
中国オフショア開発では、品質に関する見解の違いから頻繁に衝突が発生する。「交渉」の観点から、品質問題を解決する糸口を探ってみると面白い。
・問題 なぜ、日本と中国は品質問題で対立するのか？
・ヒント 交渉に影響を与える文化の構成要素を10項目以上挙げて、対立しそうな要素を重要順に並べる。
仕様変更を丸く収めたい 初めての中国オフショア開発ですが、当初の想定よりも仕様変更が増えました。明日、追加請求の件で、先方の総経理と直接対談します。どんな点に気をつけたらよいでしょうか？ （日本企業／プロジェクトマネージャ）
「仕様変更が収束しない」など一方的に発注側に非があったとしても、単純に追加請求を受け付けるほど予算的な余裕はない。さて、あなたが日本側のプロマネなら、どう対処すべきか。
残念ながら、中国企業との交渉に万能薬はない。そのため、原理原則でお茶を濁すしかないが、以下の４項目はすぐにでも応用が利くだろう。
・十分に時間をかけて交渉を進める 勢いに押されてその場で意志決定しないこと。 交渉場所が（ ）なら、なおさら焦らずじっくり対話すること。
・相手方の憤りや怒りなどの感情を素直に受け止める 責任論などの理屈はいったん脇に置いて、相手の感情に配慮する。 目的を見失わず、当事者と（ ）を切り分けて議論すること。
・総論より各論を意識して、的確なフィードバックを与える 一般論ではなく個別具体論で対応する。フィードバックを与える際には、「その場で」「 」「具体的に」の三原則を遵守すること。
・全ての言葉遣いや数字・データを丁寧に正確に扱う 勢いに押されて、何でも「はいはい」と流さないこと。日本語で交渉する際には、主語や指示語の曖昧さに留意すること。文脈に依存する表現(high context)が出てきたら、その都度確認する。
どんなに厳しい交渉の場面でも、根底にあるのは効果的なコミュニケーションを支える原理原則である。
・十分に時間をかけて交渉を進める ・相手方の憤りや怒りなどの感情を素直に受け止める ・総論より各論を意識して、的確なフィードバックを与える ・全ての言葉遣いや数字・データを丁寧に正確に扱う
査証申請などの諸手続について 中国人技術者を日本に呼ぶときに面倒な手続きは必要ですか？ （よくある質問）
あなたが勤める会社で、中国から技術者を日本に呼び寄せたいと思ったら、査証(visa)に関する一連の申請手続きが必要である。加えて、設計情報などの役務が海外に流れてしまうので、外為法に基づく一連の輸出手続きも必要である。
目に見える法的な手続き以外にも、面倒な作業は山ほどある。連絡先を確保するために携帯電話を持たせたいが、個人で支払うためには銀行口座の開設が先決だったりなど、素人が自力でやるには手間が多すぎる。
リーダ候補の中国人技術者を日本に呼び寄せて、半年後に中国に戻して現地で活躍してもらいたい。こんな思いで、中国との人的交流を図る会社は多い。
でも、せっかく日本で研修したのに、すぐに他社に転職されないかどうかも気になる。中国の労働法改正によって、約束違反に対するペナルティの与え方が大きく変わった。
査証申請などの諸手続について、一般には専門業者や海外技術者の派遣を得意とする人材サービス業者の支援を仰ぐことが多いだろう。システム開発専門の日本人が、こうした申請実務に介入することは少ないが、知識としては知っておいても損はない。
ベトナム人の日本語力 ベトナム人技術者も頑張れば日本語を話せるようになりますか？ （よくある質問）
中国との比較において、ベトナム人技術者の日本語力は格段に劣る。一般に、ベトナムとのオフショア開発では、”コミュニケータ”と呼ばれる通訳を介して意思疎通が図られる。
一般のコミュニケータは、日本語を専門に学ぶ文系出身の若者であり、女性の比率が高い。オフショア開発PRESS特集1でも指摘するが、中国と同様に英語を交えて会話する方が日本語だけの会話よりも断然に効果が高い。
オフショア開発PRESS 特集２「ベトナム最新事情」を執筆した霜田氏によると、日本語学習にかかる時間は一般的に中国人の2～2.5倍を要する。霜田氏は、続けてこう力説する。
「文系出身の通訳でも、日本語堪能なブリッジSEでも、日本側が相手に分かりやすく伝える努力は同じである」
笛吹けども踊らない組織 我が社ではトップからオフショア活用の方針が明確に打ち出されています。私自身もオフショア開発には期待しています。ところが、周りの雰囲気は違います。公言しませんが、オフショア開発への反発は相当根強いと感じています。沈滞化した組織の雰囲気をどうすれば改善できるでしょうか？ （よくある質問）
オフショア開発に反対する者、口には出さないがオフショア開発に対して不信感を持つ者を総称して”オフショア開発抵抗勢力”と呼ぶ。
ただし、オフショア開発抵抗勢力＝悪だと単純に決めつける構図ではない。むしろ、オフショア開発への抵抗は、現場力が強い良い意味での日本的な特徴だと受け止める方が自然な発想である。
※今後、負の印象を与える”オフショア開発抵抗勢力”という呼び方は避けるべき？
さて、相談された「笛吹けども踊らない組織」への処方箋について。私なら、社内にオフショア開発研究会なる非公式コミュニティを立ち上げる。
情報を共有し、社内外に点在するオフショア開発に関する有益な知見を一ヶ所に集積させるのが狙いである。この際、社内掲示板などITの活用は言うまでもないが、あえてアナログな手段の活用を提案したい。
オフショア開発に反対する沈滞化した雰囲気を改善する方法を思いつくまま列挙する。
・オフショア開発研究会なる非公式コミュニティを立ち上げる ・立ち上げ当初は、コミュニケーションの質よりも量を優先する ・「会話」から始めて、徐々に「対話」の雰囲気に移行する ・紙媒体の社内報（○×社オフショア開発通信）を発行する ・相手国とＴＶ会議するなら、相手を大きな画面に映し出す
疑念ぬぐえぬ中国の日本語ドキュメント 中国ベンダは、日本語の納品物を作れますか？ （よくある質問）
中国ベンダの日本語ドキュメント作成能力に関する質問は多い。中国オフショア開発では、メールやＱ＆Ａ連絡などほとんどの意思疎通は日本語で行われる。
だが、最終顧客に納品する報告書の類については、常に心配がつきまとう。もし、あなたが日本人と同等な文章力を望むなら、最終校正を担う日本人を雇った方が手っ取り早い。
例えば、システム管理者向け保守マニュアルは中国ベンダが作成するが、システム利用者向けのユーザガイドは編集能力に長けた日本人が担当する。
あなたが、言葉や文化の壁でお茶を濁さないプロフェッショナルを目指すなら、次の４ステップを参考にして欲しい。
Step１．混沌 Step２．同化 Step３．融合 Step４．統合
中国ベンダに「日本人と全く同じ」を求める姿勢は、第二ステップの「同化」の特徴である。同化とは、どんな料理が出されても、味見する前に無意識のうちに醤油をかける行為に喩えられる。早死にする原因にもなるので、心当たりのある方は要注意。
「同化」は進化の過程に欠かせないプロセスだが、決して最終地点ではない。詳しくは、オフショア開発PRESS特集３参照のこと。 『オフショア開発PRESS』公式サイト
大事なポイントは日本も中国も同じ オフショア開発 PRESSを読みました。結局のところ、マネジメントの要諦は業種や国籍に関係なく共通すると思いました。この考えは正しいでしょうか？ ※参考「オフショア開発PRESS」目次＋記事概要 （よくある質問）
※参考「オフショア開発PRESS」目次＋記事概要 （よくある質問）
オフショア開発の議論を進めると、必ずと言っていいほど「大事なポイントは日本も中国も同じ」といった趣旨の発言が飛び出す。果たして、その考えは正しいだろうか？
正解は「抽象化のレベル」によって変わる。ＰＭＢＯＫのような高度に抽象化された知識体系を念頭に置くなら、大事なポイントは日本も中国も同じ。居酒屋のトイレの壁に貼られた「原理原則」も、基本的には業種や国籍に依存しない。
一方で、文章の書き方、面子への配慮、メールや国際電話の作法、食事や挨拶、宗教、休憩時間の過ごし方といった個別具体論については、業種や地域性がくっきり分かれることは言うまでもない。
オフショア開発を成功させるという共通目標があるにも関わらず、一部の中国開発者は、レビューや品質保証に過度に介入する日本人リーダの言動に対して、次のような疑問を投げかける。
日本人リーダ 「自分が修正した不具合を整理してください。そして，なぜそのような修正を行ったか，つまり不具合修正の理由をまとめておいてください。あとでそれに関する質問を行いますので，しっかり準備しておいてください」
中国開発者 「そもそも，修正理由や関連知識に対する質問をする必要があるのですか？私は，修士号を取得しましたし，これまでも実力で評価を得てきました。一つの不具合を修正するため様々な調査をしました。それは，結果と修正コードを見てもらえれば，わかるはずなのに。明らかに日本人は私を信頼していません。屈辱です」。
中国開発者 「信用していないのなら，なぜ仕事をくれますか？」
第1回 中国開発者から見た変な日本人リーダー
オフショア開発の評価の場で、あなたの部下（あるいは上司）から「大事なポイントは日本も中国も同じ」との発言があった。あなたは、どんな反応をすればよいだろうか。特定の場面を想定して、代表的な問答集を予め準備しよう。
中国でシステム開発を行なう際にも輸出手続が必要ですか？ （よくある質問）
日本から外国にモノや情報を持ち出す場合には、基本的に全て輸出手続が必要となる。全てというのは、日本から中国に送る提案依頼書や仕様書をはじめ、無償・有償で貸与するソフトウェアも全て含む。
輸出管理は世界中の法律で定められており、ルール違反すると色々問題になる。
※参考情報 ・ヘリ不正輸出、ヤマハ発動機 ・対共産圏輸出統制委員会 - COCOM（ココム）
（興味ある方はネットで検索してください）
あなたの会社で提供物の履歴を取るのはもちろんのこと、相手先でどのような管理体制にあるのかを事前に知っておくべきである。
基本契約書では「輸出管理手続きをキチンとやる事」と定めることが多いと聞いている。あなたは取引先がどのような仕組みで情報管理しているかを本当に知っているだろうか？
オフショア開発で納期短縮 短納期ですが、それでもオフショア開発できますか？ （よくある質問）
これまでの中国オフショア開発のやり方では、納期短縮は極めて難しい。これが私の意見である。
オフショア開発の最大の利点は開発費の低減である。最近は、開発要員の確保を目的と公言する者も少なくないが、理想と現実のギャップは大きい。
米国とインド間のオフショアリングでは、コスト削減だけではなく納期短縮も実現されているという。だが、彼らは「これまでの中国オフショア開発」とは全く異なる仕組みで動いているため、単純な比較は意味がない。
インドで開発期間を短縮したという噂話。
・米国とインドの時差を利用した開発（よく聞く噂だが・・・） ・米国では不可能な世の中にない新製品をインドで開発 ・２交代制による２４時間体制で開発 （好待遇の夜間勤務はインド人に歓迎されたという）
あなたは、実際にオフショア開発で期間短縮に成功したことはありますか? 製造工程が短縮されても、前後の工程が長引けば期間短縮とは認めません。
◆期間短縮に成功したことがある ◆国内開発と同期間を実現した ◆国内開発よりも長引いたことしかない ◆その他
締切：2008年04月22日23時00分 協力：クリックアンケート
品質評価が難しいオフショア開発 定量的な品質評価が難しいソフトを扱っています。それでもオフショア発注できますか？ （よくある質問）
定量的な品質評価が難しいソフトであっても、オフショア開発は可能である。ただし、次のような失敗例があるので、該当する方は参考にして欲しい。
かつて、私は定量的な品質評価が難しいソフトウェアと５年間つきあってきた。ＯＣＲと呼ばれる画像認識技術である。一般に、検索や画像認識といった技術には正解があってないようなモノ。すなわち、定量評価がとても難しい(※)。
※人の笑顔を自動認識する技術に絶対的な正解はない ※文字認識技術で"ー","－","―"を区別する正解algorismはない
中国オフショア開発では、特定の状況下でのみ正しく動作する、いわゆる「お化粧プログラミング」の弊害が多数報告されている。オフショア開発PRESS でも、「直すのではなく隠す」と「テストの地獄スパイラル」といった事例を紹介している。
参考１：オフショア開発PRESS p31「直すのではなく隠す」 参考２：オフショア開発PRESS p105「テストの地獄スパイラル」 http://amazon.co.jp/exec/obidos/ASIN/4774134430/aicoach-22/ref=nosim
以下、余談。
長い目で見たとき、オフショア開発を失敗させる最大の要因は、無計画で継続性のない発注形態だと思う。
例えば、お試し発注と称して３ヶ月間のオフショア開発を実施する。その後、評価に２ヶ月間を要する。さらに１ヶ月の準備期間を経て、再び製造＆単体試験を依頼する。これは、失敗するオフショア開発の典型例である。
中国オフショア開発では、特定の状況下でのみ正しく動作する、いわゆる「お化粧プログラミング」の弊害が多数報告されている。「納期遵守」絶対主義が招いた弊害だと指摘する声もある。
間接オフショア開発では、安全のために納期の前倒しが要求されるため、品質を犠牲にした”仮納品”が後を絶たないという。
要求仕様が曖昧だとオフショア開発は無理か？ 着手時点で正確な要求仕様が固まっていません。それでもオフショア発注できますか？ （よくある質問）
着手時点で要求仕様が固まっているオフショア開発案件など、私はお目にかかったことがない。ということは、いくつかの前提条件を満たせば、オフショア開発でも要求仕様の段階的詳細化は成功すると予想される。
オフショア開発PRESS特集1では、「仕様未記載」と「仕様不備」の違いに触れて、不具合管理の観点からオフショア開発を成功に導くコミュニケーション技法を紹介する。
参考：オフショア開発PRESS p26～29
私が主催するオフショア開発実践セミナーでは、中国と日本が協力して「一緒に要求仕様の穴を埋めよう」という美しい姿勢を真っ向から否定する。
オフショア開発で要求仕様の段階的詳細化を成功させる大切な条件を３つ挙げなさい。
条件１ 要求仕様は100%オンサイト側の責任で固める 条件２ 「仕様未記載」と「仕様不備」の違いを公式に認める 条件３ ・・・（あなたの答えは？）
日本語が堪能な中国人ＳＥに聞きました 「～するべき」と「～しなければいけない」は同じ意味だと思います。 （対日業務７年目の中国人ＳＥ）
対日業務７年目を迎える熱心なメルマガ読者の中国人ＳＥに聞いてみた。
――「～するべき」と「～しなければいけない」の違いは？
◆私は同じ意味だと思います。
――Q＆A連絡では、「～するべき」と「～しなければいけない」のどちらを好みますか？
◆私は「～するべき」の方がいいと思います。なぜなら、「～しなければいけない」は二重否定のように聞こえるため、日本語に不慣れな外国人はすぐに理解できないと思います。
――文脈によって、「～するべき」の強制力は弱まります。もうすぐ桜が散ってしまうので、明日までにお花見すべきよ。
◆確かにそうですね。具体例を挙げて説明してもらったので、その違いが分かりました。中国語でも、應該(ying gai) 一定(yi ding)必須(bi xu) などが使い分けられます。「我一定去」というべき場面で「我應該去」と言ったら、相手に失礼です。
日本語に不慣れな外国人は、「～しなければいけない」を二重否定だと思って、意味を理解するまでに時間を要することがある。
年度が替わり心機一転といきたいところですが ４月は仕事が埋まらず、困っています。 （小規模ソフトハウス経営者／日本人）
オフショア開発専門の技術集団を目指す弱小ソフトハウスから相談を受けた。規模は小さいものの、特定企業からの請負業務でこれまで安定稼働を続けてきた。ところが、景気後退のあおりで仕事を打ち切られてしまった。
「半年後に忙しくなるから、その時には、またお願いします」
下請け家業の悲しい性かな。この一言で、主力事業を失う現実。10人月以下の請負案件で食いつなぐオフショア専門会社は多い。
後発組のオフショア専門企業に対して、日本中の地域に根ざした地元企業との競争激化について問うたら、「厳しい」とぽつり。私は１つだけ助言を与えた。
「□□すればするほど体力が衰える。□□の代わりに□□をせよ」
日本語があっという間に上達する人 うちの技術者はみんな日本のアニメファンです。 （上海オフショア開発交流会より）
以前、中国人の初級プログラマに日本式ビジネスマナーを教える講師に出会ったことがある。驚いたことに、この講師は一度も日本に行ったことがないという。
では、日本式マナー講座で何を教えているのかを聞いたところ、お辞儀や挨拶といった基本中の基本に特化しているとのこと。失礼ながら、その場は失笑しそうになったが、後から冷静に考えるとあながち悪い試みではないような気がしてきた。
オフショア開発PRESS「成功する日本語研修(p142)」では、初心者を相手にする授業なら、必ずしも日本講師にこだわらない方がよいと具体例を挙げて指摘する。
※ちなみに、昼食後の研修は最悪である。特に北方では要注意。 理由は当該記事をご覧ください。
すべての外国人プログラマに通用する万能な日本語学習法はない。ところが、日本好きな若手IT技術者に対しては、効率よくにカタカナを教える手段がある。日本のドラマやゲーム、アニメを活用する手法だが、さらに一手間加えることで効果倍増とのこと。それ以上は営業秘密ということで。
「カタカナ英語」を減らして、漢字もしくは英語で書くべき？ どちらが理解すべきか、という観点で言うなら、受注者側で理解してもらいたいなぁと思います。当然、発注側も、辞書的なものを整備する必要があると思います。用語集というのでしょうか。 （読者アンケート掲示板より） ○アンケート途中結果を見る
○アンケート途中結果を見る
日本の仕様書から「カタカナ外国語」がなくなることはない。恐らく、激減することもないだろう。そこで、カタカナを許容する前提で用語集の必要性がうたわれる。
先日の上海オフショア開発勉強会でも、用語集の必要性を議論した。実際に、多くの開発現場で用語集を準備しているが、いくつかの問題がすぐに思い浮かぶ。
・用語集作成の費用を誰が負担すべきか？ ・用語集を更新する適切な頻度は？ ・用語集を更新することで得られる個人的な報酬は？
用語集を作成するにせよ、結局のところ同じ悩みに行き着く。どこまで用語集に登録すべきか、その判断が難しい。あなたは、下記のカタカナ外来語を用語集に登録するだろうか。
「パフォーマンス」「エンハンス」「タイミング」「アプリ」
もし用語集に登録するつもりなら、それぞれどのように翻訳するか。
日本から「ブリッジSEを投入したい」と言われたら 受け側から見た場合には、逃げの言い訳を最初につくるものでしかありません。顧客の要求仕様を理解し、文化の違いを前提としてコミュニケーションすれば、ブリッジSEなんて必要ありません。 （中国人総裁）
日本企業では、新人は１５年ほどかけて１人前の技術者やマネージャーに育つ。一方、中国では、オフショア開発にあたる従業員は一人前ではないし、会社もどんどん伸びて組織形態も激変する。したがって、最初からブリッジSEの個人技に頼る組織は甘えている。 これが、前出の中国人総裁の基本姿勢である。
果たして、中国ベンダに日本のソフトウェア開発業界に特有の暗黙知を移転できるのだろうか。「あうんの呼吸」が通じるとか、通じないとかの話ではなく、中国は組織学習するだろうか。
この種の議論をする際、日本人の団塊世代が持つ”暗黙知”と、オフショア拠点のＳＥが持つ”ノウハウ”は次元が違うことに気をつけたい。このままの状態で、「中国にノウハウは溜まらない」と一方的に相手を非難しても、何の解決にも結びつかないだろう。
○読者アンケートの途中結果を見る
先週の上海オフショア開発勉強会講師からのアドバイス。
中国人技術者と会話する際には、単なる仮説や想像と事実を切り分ける工夫が必要である。もし、「報告の際には、結論を先に述べよ」と指導したいなら、大事なポイントを行動レベルで書き出し、社内の目立つところに掲示して何度も何度もしつこく指導し続ける こと。
言葉だけではなく、紙に書いて見せれば、組織は変わり始める。
☆オフショア開発では、「カタカナ英語」を減らして、極力漢字も しくは英語で書くべきだといわれます。ところが、忙しい発注者へ の負担増は避けたい。さて、どうすべき？
◆発注者(日本人)が「カタカナ」を減らす努力をすべき ◆受注者(外国人)が「カタカナ」を理解すべき ◆その他
締切：2008年04月01日23時00分 協力：クリックアンケート
手詰まり感の漂う中国オフショア開発の打開策 ・Q&A遅延の責任所在 ・Q&A遅延防止の一般的対策 ・Q&A成熟度モデル ・日本語と日本人の曖昧さ （第７回上海オフショア開発勉強会／ゲスト講師より）
・Q&A遅延の責任所在 ・Q&A遅延防止の一般的対策 ・Q&A成熟度モデル ・日本語と日本人の曖昧さ （第７回上海オフショア開発勉強会／ゲスト講師より）
第７回上海オフショア開発勉強会のゲスト講師より。
中国オフショア開発で語られる問題点の数々。
・業務知識不足 ・日本語能力不足 ・日本の慣習の理解不足 ・離職率が高い
対策として「各種教育」「標準化」「日本出向」等を推進。効果はあるが、期待ほどではない。
読者アンケートの中間結果（33票）
知識不足は研修で補える。経験不足は時間を要するため、特効薬はない。文化や常識の違いを克服するには、相互理解に加えて共通の測定基準が必要だ。
例えば、中国の現場から次の報告が上がってきたとき、上長はどのように対処すればよいだろうか。
「製造完了しました」 「明日、完了します」 「納期は守れます」
・2008/3/20 - 上海 上海オフショア開発勉強会（申込数 11名） 上海周辺の方には強くお勧めします。出張でたまたま上海を訪れた方にも、この勉強会の案内を転送してあげましょう。
現場からの報告とよくある実態の例を示す。常識の相違があることを認識して、掘り下げた質問、現物確認が必要である。一部の優良企業を除いて、現状の中国オフショアの現場には、日本語と技術を兼ね備えた人材は皆無であることを前提に対策すべきである。
「製造完了しました」→「単体テストをしていない」 「明日、完了します」→「一週間やっても完了しない 」 「納期は守れます」→「品質は考慮されない」
リーン製品開発でムダな工数を30％削減する 設計自体の造詣がないために、結局莫大なコストの掛かる手戻りが発生することも否めません。エース級の日本人設計者が、現地技術者より10倍以上高いコストを掛けて、火消しに回るということもあります。非常に残念ですが、結果として、海外人材は使えないという印象がトラウマとなります。 ＠IT MONOist「日常業務に隠されたムダをとことん洗い出す」
＠IT MONOist「日常業務に隠されたムダをとことん洗い出す」
果たして、中国企業にノウハウは蓄積されるのか。今日は、この問いかけへのヒントを得るべく、国際分業体制にいち早く移行した製造業の声に耳を傾けてみる。
優秀なエンジニアはあっという間に設計を終えます。初心者は試行錯誤します。同じテーマを与えても、作業工数に5倍も10倍もの格差が出るのはよくあることです。
これからは、設計者もグローバル規模で最適調達すべきという認識を、皆さんのような現場の技術者自身は認識しておく必要があります。
ところが、行き過ぎたコスト低減の反動で、設計者同士の関係はばらばらになってしまいました。これでは、プロセス同士が分断され、人の付き合いも希薄となります。
結果として、ものづくりの全体の情報を把握するために、過剰な調整業務が莫大な設計工数として加算されてきます。これは明らかにムダな工数です。
そこで、設計業務の短納期化に成功した会社にプロセスのムダを取る秘訣を尋ねたところ、こんな答えが返ってきました。
・業務に関する「現状と目標」を明らかにする ・標準化に尽きる（テンプレート化） ・標準テンプレートを毎週カイゼンする
しかし、それは人材育成に相当の力を入れていることが前提。人材の流動性が極めて低く、一度入社したら事実上の終身雇用となる制度の中で、設計者たちが手厚く雇用されている場合に通用することです。
＠IT MONOist「日常業務に隠されたムダをとことん洗い出す」 （本誌発行人のお友達の記事です）
製造業から夢のような特効薬が得られるかと思いきや、現実は厳しい。製造業で活躍する業務改革のプロは、長期雇用を前提とした”純和風”な組織では、昔ながらの”優れた”カイゼン手法を採っても、劇的な生産性向上は難しいと指摘する。
今週の読者アンケートのテーマは「個人に蓄積されるノウハウ、組織に蓄積されるノウハウ」である。途中結果では、中国ベンダには、「個人にはノウハウ蓄積されるが、組織には根付かない」と答えた人が６５％を占める。
中国ベンダに「ノウハウが蓄積されるか？」を議論する前に、前提条件をよく確認しよう。純和風な意味での「ノウハウ蓄積」なら、中国の組織には「ノウハウは根付かない」が事実であっても、落胆する必要はない。
もし、オフショア開発業務の大半がルーチンワークだとしたら(仮に80％)、ノウハウ蓄積よりも先にやる事が他にあるはずだ。それは標準化＋αである。
この仮説が正しいなら、あなたが考えるプラスαの要素とは何？
★ご意見はこちらまでお寄せください
中国企業の個人にはノウハウは溜まらないが、組織には溜まる？ 私の感覚だと逆ですね。もちろん私の感覚は製造業での感覚なので事情が違うのかもしれません。私が現場で感じるのは、個人にはノウハウがたまるが，会社にはノウハウが残らない。優秀な人間がやめてゆくと，会社ががたがたになる。優秀な人間でも部下や仲間にノウハウを教えるのはへたくそ。 （オフショア開発PRESS 執筆者）
伸びる中国企業では、幹部社員は会社を辞めない。定着率はほぼ100%である。ダメな会社は、いつまで経っても幹部社員が定着しない。これは、オフショア関係者の間で静かに語られる定説である。
では、幹部が辞めない中国企業では、個人にノウハウが蓄積されて生産性が理想的に改善されるのかというと、一概にそうとも言い切れないという。
先日、私と一緒に横浜市経済観光局の講演会で質疑応答の場に立った中国人経営者は、その理由を次のように述べた。
・一つの会社で長く働く優秀な中国人幹部社員は、瞬く間に出世して開発現場から離れてしまう。場合によっては、20代後半で百名以上のプログラマ集団を統率する副総経理クラスに昇進することがある。
一つの会社で長く働く有能な中国人エンジニアは出世魚である。時間をかけて特定の個人に貴重なノウハウを移転しても、出世とともに現場から離れてしまう。
※
☆中国オフショア開発企業にはノウハウが蓄積されないと噂されま すが、真実はいかに？ あなたの過去の経験をもとにお答えください。
◆個人にはノウハウ蓄積されるが、組織には根付かない ◆組織にはノウハウが根付くが、個人には蓄積されない ◆個人にも、組織にもノウハウは蓄積される ◆個人にも、組織にもノウハウなんて蓄積されない ◆その他
締切：2008年03月26日23時00分 協力：クリックアンケート
まるで耳が遠くなったお年より同士の会話 日常会話なら問題無いですが、間違ってはいけない場面でのコミュニケーションでは中途半端な言語能力が危険です。お互い通じていると思っていても実は通じていないことがあります。 （アンケート掲示板より）
今日から私は4泊5日の中国出張。杭州と上海で、それぞれオフショア開発イベントを主催する。オフショア開発フォーラム in 杭州と上海オフショア開発勉強会。
最近の私は、取材と称して外国人へのインタビューを頻繁に行う。使用言語は日本語だ。大多数は中国人だが、最近はインド人も増えてきた。
インタビュー中、互いにテンポよく会話が弾む。ところが、文章におこして取材相手に確認を促すと、互いの意図が全く伝わっていないことにしばしば気がつく。
さらに、会話中で多くの矛盾を発見する。すなわち、相手の言い分を適当に解釈して「はい」「そうです」と気軽に返事するものの、後から平気で正反対の意見を述べる場面に出くわすのだ。
例えば、先日、横浜市経済環境局が主催したオフショア講演会の質疑応答でこんな会話があった。
中国人「中国企業にはノウハウが蓄積されない。・・・・」
日本人「先ほど、中国にはノウハウが溜まらな
