« September 2014 | Main | November 2014 »

インドオフショア開発まとめ

今日は、自分用の備忘録としたまとめた参考情報一覧を紹介します。

●インド

毎年この時期、多くのインド企業は、ヒンドゥー教の新年のお祝いであるDiwali(ディワリ)で小休止します。インドでは、年間で唯一ともいえる長期休暇です。インド暦による休暇のため、太陽暦では毎年 Diwali の休暇期間が変化します。

オフショア大學に寄せられた事例を1つ紹介します。

インドが Diwali休暇に入ると、遠地から都市部に来ているエンジニアが故郷に帰省します。休暇中の緊急対応は極めて困難です。本日、緊急のQ&Aが発生しました。そこで、日本側担当の私は、インドのプロジェクトリーダーに携帯で連絡を取りました。ところが、彼は、既にオフィスから 1,500 km も離れた実家に帰省していました。36時間以上もかけバス移動したとのこと。結局、緊急対応は、休暇明けにずれ込んでしまいました。

オフショア大學には、昨年あたりから中国プラスワン戦略に関する問い合わせが増えています。そして、今年は、オフショア大學でも、インドオフショア開発研修や英語交流指導が始まりました。

以下、参考までに、インドに関する過去記事を紹介します。


紙出力の習慣がないインドでは、エクセル印刷時の考慮なし
インド開発現場には、電子データに印刷設定をするという習慣もない。またエクセル等を印刷した際のことを考慮し、罫線を引くということもあまりしない。


印刷設定への配慮は過剰サービスか?
あなたの周囲を見回して、紙資料を確認してください。無駄に印刷されたMS-Office などの資料はありませんか。たまに、電子データの印刷設定を無駄と思うことはありませんか。ペーパーレス化について、日本はオフショア拠点に学ぶべきだと思いますか?
(アンケート結果あり)


インドオフショア開発、日本側のみ稼動する時間帯の使い方(1)
インドオフショア開発、日本側のみ稼動する時間帯の使い方(2)
インドと日本の間には3時間半の時差があります。日本時間13時頃にインド側の始業時刻となり、日本時間22時頃にインド側は終業時刻を迎えます。インドオフショア開発では、一日の稼働時間を大きく3つに分類します。
(1) 日本側のみ稼動する時間帯
(2) 日本側/インド側、両拠点が稼動する時間帯
(3) インド側のみ稼動する時間帯


これはバグですか? いいえ、仕様変更です
日本人技術者は、担当外のモジュールで不具合が発生すると、「担当者の責任追及」よりも即対応を優先します。一方、インド人技術者は、常に仕様書と乖離がないか調べます。日本人技術者同士でありがちな「そういった意味にもとれますね」と言った会話もなし。


インド「お客様は神様ではない」
発注者側の曖昧な設計書が原因で問題が発生すれば、急な無理な対応を強いるのは困難を極めます。日本企業(受注先)であれば、お客様の為にと無理な徹夜対応等に応じる技術者もいるでしょう。しかし、インドでは違います。なぜならば、契約に沿っていないからです。(読者コメント欄が面白い)


インドTips、チームメンバーの誕生日覚えていますか?
インド開発現場では、エンジニアは少なくともチームメンバーの誕生日は覚えています。インドIT企業では社員誕生日をリストとして掲示している企業も多いです。誕生日にはチームメンバー全員で祝いあいます。また、誕生日には自分からレストランで誕生日食事会を企画して、費用も自分で払うのが一般的です。


インド時間帯にあわせた挨拶で高感度アップ
インドと日本には3時間半の時差があるため、例えば日本時間午後1時から始まる会議は、インド時間午前9時半に相当します。そこで「こんにちは」の代わりに「おはようございます」もしくは「Good morning. How are you?」と声をかけます。ヒンディー語で「Namaste」とすると好印象です。「Namaste」は朝昼晩いつでも使えるのでとっても便利です。


Something to drink? → No need は間違いか?
インド英語の特徴は以下の通りです。
英米人向け教科書的な英文法の正確性を気にしない、インド人独特の発音やイントネーション、現地文化や母語の影響を受けてカスタマイズされた英語表現など。
・冠詞を厳密に使い分けない(a/an, theの使い方)
・3単現のsを気にせず省略/蛇足的に付与
・/r/の発音
・/p/の発音
・/th/の発音
・today morning / What is [your] good name?(ヒンディー影響)


インド人の会話が白熱すると英語から母語に切り替わる
私の経験では、インド開発拠点の内部関係者だけで閉じられた空間では、さほど英語は使用されません。基本的に、母語で会話するようです。インド人技術者にとって、英語は仕事の言葉なのです。英語は、決して彼らの母語ではありません。


インドの長期休暇“Diwali”のリスク対策
インド側では年間休日が少ない為、実働日数が日本より多い。日本側がゴールデンウィーク、年末年始、盆休暇等長期休暇の際にも、インド側は稼動している。


お祭り期間中は散髪しないインド人技術者への対応
3ヵ月間の予定で初来日したインド人技術者と一緒に開発を進めています。7月下旬から8月下旬にかけて、ヒンズー教のお祭り Shravan Month がやってきます。この期間、一部のインド人は散髪を避けるそうです。私は、お祭り期間に入る直前の休日に、慌ててインド人技術者の仲間を理容店へ案内しました。


インド・カースト身分制がトラブル再発防止の妨げとなる
サッカー日本代表とインド代表との試合中、突然ピッチに犬が乱入。ここまでは笑い話ですが、興味深かったのはその後。警備員が犬を追い払う様子がまるでなし(トラブル沈静化の意図なし?)。数分後に同じ犬が再びピッチに乱入(再発防止の意図なし?)。


事前に休暇申請してくれたらいいのに
「休暇をとる」ということに対する認識も大きく違いを感じ、日本であれば十分な時間を空けて前もって申請し、周囲に伝えておくことが普通ですが、インドでは1週間前に申請していればいいほうで、当日にいきなり「消えている」こともたまにあるほどです。


インドITは技術力をアピールするも顧客の心に届かず
インドIT企業は、技術力のアピールは得意ですが、プロジェクト管理やセキュリティ対策、運用については殆ど言及しません。出来て当然だと思っているからです。――中国ベンダとは対照的な営業スタイルですね。


インドIT技術者は日本語を学ぶ意欲に欠けるか?
2006年、インドの日本語能力検定試験の受験者数は5,368人。人口が10分の1以下のベトナムよりも、受験者数は少ない。インド人技術者に難しい日本語をきちんと理解させる努力よりも、日本人が英語でコミュニケーションするように努力する方が効率的ではないでしょうか。それは、意識の問題ではなく、語学学習の費用対効果で判断すべきです。


インド人相手に必要な英語力
2年以上日本で日本語を使い仕事をしたインド人エンジニアとも、日本語で話すより、英語で会話するほうがお互いしっくり来る。英語はお互いネイティブ言語ではないと言う所がポイントではないか。


概算予算確保のための「どんぶり勘定」
――要件定義は今実施しているのですが、スケジュールが決定しており、至急体制を組みたいので先ずは概算予算確保の為、ざっくり見積ってください。
インド:リスクが大きい為、現時点では見積もりはできません。
――日本IT開発ベンダーなら1週間で見積るよ。そんなことではオフショアは検討できません。
インド:・・・・・・(沈黙)

※情報提供:向井永浩(2008)


■ 問いかけ

<問1>紙出力の習慣がないインドでは、日本側に提出するエクセルファイルに印刷設定する発想は乏しいと言われます。同様に、エクセスシートに罫線を引いて、表としてきれいに印刷される配慮もありません。

紙出力を考慮しないインド側の商習慣がもたらす困った事象の例を1つ挙げなさい。


<問2>インドと日本の休日の違いがもたらすメリットとデメリットをそれぞれ列挙しなさい。

| | Comments (0)

自分流コーディングのまとめ

今日は、自分用の備忘録としたまとめた参考情報一覧を紹介します。


●自分流コーディングへの強いこだわり

オフショア大學には、海外オフショア勢が日本の指示に従わず困っているとの相談が多数寄せられます。最も目立つのは、自分流コーディングへの強すぎるこだわりです。

逆に、品質保証や標準化などのマネジメント活動については、海外オフショア勢は意外なほど素直に日本側の指導に耳を傾けます。恐らく以下が原因でしょう。


・コーディング

担当は若手プログラマ。コーディングだけは日本人に負けない自負あり。ただし、日本的商習慣の理解に乏しく、自分のコーディングが対象ソフトウェア全体に与える影響までは分析できない。すなわち、無知に基づく無邪気さから、自分流コーディングへの強いこだわりを示す傾向がある。


・品質保証や標準化などのマネジメント

担当は経験豊富なリーダー以上がほとんど。日本語は達者で、かつ、付き合う顧客毎に異なる固有の商習慣も理解していることが多い。普段から、日本品質に一定の敬意を払っているため、顧客からの要望に対しては可能な限り応えたいサービス精神をのぞかせる。ただし、日本品質が必ずしも「好き」というわけではない。面倒だけど、「やるべき」との義務感で動く職業人としてのプライドが光る。


for文の繰り返し制限数を明記すべきか
日本から中国子会社に提出したコーディング規約の中に「for文を繰り返さない」という禁止令がありました。ところが、中国側から、「何回か指定して頂けないと対応できません」と言われました。(アンケート結果あり)


レビュー時に指摘されなかったので今さら修正できません
オフショア開発でコーディング規約が守られません。もっともらしい言い訳をして修正依頼にも応じません。なぜ、中国では明確な規約すら守らないのでしょうか。(アンケート結果あり)


ソースコードのコメントに間違った日本語を見つけたら
あなたが日本側の受け入れ担当者なら、中国から納品されたソースコードのコメントに見つかった日本語の間違いを修正しますか。(アンケート結果あり)


怒っても効果なし、謝罪するが改善なし
コーディング規約を守らない中国子会社にご立腹・・・効果なし。開発連絡用の掲示板上で、規約を守らないのはルール違反だ、と怒りを示しました。リーダは謝りますが、次も同じことを繰り返します。怒っても効果はないな、と感じました。


ソースコードのコピペ爆弾
日系メーカーの中国現地法人で働くある日本人上司は、中国人社員がバグを「直す」のではなく「隠す」ことに苛立ちを覚えるという。例外処理を無視するだけならまだしも、バグ発生確率を抑えるお化粧プログラミング技法には、開いた口がふさがらない。


中間納品はお化粧されたプログラム
中国から完成したプログラムが納品されたので、日本で動作確認したところ、単純なバグがいくつも見つかりました。直ちにQ&A票で不具合を指摘しましたが、中国側の試験では問題なかったと一蹴されてしまいました。・・・
納期が迫っていることもあり、中国での修正をあきらめて、全て日本側で対応することになりました。普段からお世話になっている日本の協力会社に急遽プログラマを増員してもらい、他人のソースコードのデバッグに明け暮れました。


日本でわざわざソースコード再検査
中国でコードレビューを実施済みなのに、その後に日本でもソースコード再検査を義務づける会社があります。現場では、やはり不評とのこと。あなたは、日本でのソースコード再検査に賛成ですか?(アンケート結果あり)


メソッドや変数を英語で適切に命名
データを取得するメソッド名称を決める際、英語の可読性がよい方の名称を選びなさい。
(a) getData()
(b) takeData()


誤った指示だと分かっていても、言われたとおりに製造する
ある中国人プログラマは、責任分担を意識するあまり、次のような行動に出た。仕様書が間違っていると確信を持った時でも、言われたとおりに製造する。もし、後から問題になっても、それは自分の責任ではないと、堂々と主張する。


──────────────────────────────
■ 問いかけ ■
──────────────────────────────

<問1>次の事例を読んで、後の設問に答えなさい。

中国にオフショア子会社を持つある製造メーカーでの話。

この会社では、1万分の1の確率で不具合が発生する恐れあるなら、絶対に潰さないと気がすまない社風が現場を支配します。例えば、保守運用時に「ソースコードを誤読」する恐れがある場合も同様です。

不具合ではないものの、奇抜なコーディングも修正すべき対象です。例えば、いかにも玄人が好みそうな論理演算子を3以上、並べるコーディングスタイルも、現場で保守運用しにくいと判断すれば、即座に修正しないといけません。

ところが、論理演算子を3以上、並べた玄人好みのコードを書いた中国人プログラマは、「自分はこの方法理解しやすい」といって日本側の修正要求を突っぱねました。

まさかの修正拒否に戸惑う日本人担当者。この会社は、品質第一を忠実に守る社風であり、中国子会社にもずっとそのように社内教育してきたつもりでした。

これまで中国子会社で何度も繰り返し実施してきた品質教育ですが、一体どこに問題があるのでしょうか。また、今後、どう品質教育を再強化すればよいでしょうか。

| | Comments (0)

人材流動のまとめ

今日は、自分用の備忘録としたまとめた参考情報一覧を紹介します。


●人材流動

オフショア大學には、海外オフショア委託先の人材流動に関する問い合わせが多数、寄せられます。社内研修後の質疑応答でも、必ずと「転職率の高さに悩む」や「人材流動でノウハウ流出」の声があがります。

しかも、ビジネス誌に載るような経営・戦略論ではなく、具体的な知識や事例、方法論が要求されます。現場で活躍する実務者を満足させないといけないので、質疑応答で一発勝負させられるオフショア大學講師陣は、いつも緊張の連続です。

この秋から来年3月末までに、オフショア大學には、複数の会社からオフショア社内研修の依頼が舞い込んでいます。社会人だけではなく、学生向けのブリッジSE養成講座も予定されています。誠にありがとうございます。

参考までに、過去記事の中から、人材流動に関する話題を無作為に抽出します。


人材流動の激しい中国メンバーと信頼関係を築く法
「信頼関係」の意味は、国や文化によって異なります。全く違う意味になることはありませんが、信頼の拠り所は歴史・宗教観、社会情勢に左右されます。


人材流動が激しい中国でITリテラシ教育は有効か?
被害にあった独立系ベンダーの現場をのぞいてみると、日本人はウイルスを警戒して怪しいメッセージを全て無視したそうですが、一部の中国人従業員が無防備に汚染されたファイルをクリックします。
なにせ、彼らは20代前半の就業経験の乏しい人たちです。知人から届いたメッセージには律儀に反応するそうです。


「お金」が最大の理由で転職
2010年11月現在、中国沿岸部の主要都市では、中堅SEの人材流動が高まっています。理由の1つは「オフショア開発量が増加」したために競合各社で人材争奪が激化するようになったから。ですが、これは、数ある要因の中の1つに過ぎません。


「キャリア機会の追求」に隠された本音
多くの中国人従業員は、学生の頃から勉強熱心で、職場でも技術力向上に対する強い執着心を持ちます。
必ずしも、守銭奴のような「先に金ありき」の精神ばかりではなく、「大学で学んだ技術を即戦力として活かしたい」「寄り道せず一直線に上を目指したい」という内発的な動機要因も見逃せません。


転職する外国人よりも日本人の方がBSEに向いている?
短期の単発プロジェクトなら経験豊富な外国人バイリンガルSEを、長期継続が前提のオフショア開発なら国籍よりもコンピテンシー重視でブリッジSEを選定するとよいでしょう。語学力よりも将来性に着目した能力鑑定が成功の鍵です。


春節明けの人材流出リスク
2013年冬、某人気商品の重要部品を製造するある日系下請け工場では、春節休みを最低限の三日間だけにして製造ラインの稼働率を高めようとしました。工場労働者を田舎に帰省させない・・・との目論見もあったそうです。(アンケートあり)


3月チーム再構築の法則
毎年この時期は、日本の年度末納品にあわせた追い込みに追われます。一方で、年度末は、大量転職によるチーム力低下リスクが顕在化する時期とも重なるため、チームに残留した優秀なリーダーに対しては周囲の想像以上に負荷が集中します。


品質保証室は不人気
監査の形骸化を指摘する声は少なくない。また、中国では品質保証室が不人気だという指摘もある。理由を聞いてみたら、
・キャリアとして確立されていない
・仕事ができない人が配属されるイメージが背景にある
ということだ。


離職面接
さらに調査を進めてみると、他にもこんな面白い要因がある。
・食事の質(社員食堂がまずいせいで暴動が起きた工場もある)
・社員旅行の有無、行き先(海南島に行きたいので転職をとどまる)


ミャンマー訪問記「転職しやすさの国別比較」
ヤンゴン市内の飲食店やサービス業で働く低賃金労働者は、頻繁に転職を繰り返すそうです。さらに、低賃金労働者だけではなく、マネージャー層も子飼いの部下を引き連れて、集団離職する事例が相次いでいます。


ミャンマー訪問記「現地企業のSEは頻繁に転職する」
元気一杯のミャンマー人技術者(ソフトウェア以外も含む)は、祖国で2-3年働くとすぐに海外に出稼ぎに行きます。なぜなら、海外では10倍以上の給与が簡単に手に入るからです。


ミャンマー訪問記「もしミャンマー人SEが離職するなら」
主力である25歳以下のSEは、学生時代に実機によるSoftware開発の訓練をまともに受けていません。よって、残念ながら、同世代の中国人SE(21歳~25歳)と比べて、基礎的な開発経験不足は否めません。


以上、11本を全て読破するとなると、1時間くらいかかるかもしれません。忙しい人は、気になる記事だけさっと目を通して、要点を絞って知識獲得するとよいでしょう。


■ 問いかけ

上記の過去記事を読んで、後の設問に答えなさい。


<問1>一般に、海外オフショア委託先の人材流動によって、どのような問題が発生しますか。本誌過去記事で紹介された失敗事例や悩み相談から、発生頻度の高い問題をいくつか挙げなさい。


<問2>国別の人材流動率を予測しなさい。

| | Comments (0)

単体テスト不具合発生の原因と対応

最近、オフショア大學に寄せられた質問より。


【問】単体テストで不備等が発生した際、円滑に対応してもらうためのオフショアならではの工夫はありますか?


【答】委託先が中国ならば、単体テストまでは全てオフショア先が責任を全うすべきです。もし、単体テストで不備が多発するなら、明らかな実力不足か、あるいは、前工程を疑います。

ご質問はオフショアならではの「工夫」についてですが、同時に、オフショアならではの「原因」に着目するとよいでしょう。

例1>言葉に不安がある現場であれば、画面やUIに関する箇所に不安が残ります。HTMLデザインや帳票出力システムでよくある「ミリ単位の罫線のズレ」は、国民文化の違いが原因です。この種の問題の原因を「品質意識不足」だと定義すると、途端に対策が難しくなります。


例2>入社1-2年目の若手プログラマが主体のオフショア委託先では、ときどき応答速度などの性能要件に関する不具合が発生します。OJT指導なき若手プログラマの人海戦術は、いかにもオフショアならではの問題を引き起こす原因となります。

性能要件の未達でよくあるのはコピペの多用。

for文を何重にも繰り返す、SQLでリソースを食う処理を大量にコピペ生産、莫大なメモリ空間を一時的に確保し処理した後にメモリ開放を繰り返す(C/C++)、ときどきメモリ解放忘れやセッションクローズ忘れのまま複数コピペ、など。

上記の症状がいくつか組み合わり、かつ、複製されて大量の場面で用いられると、皆さん予想通りの結末となります。

こうした症状があるにも関わらず、たまたま、オフショア委託先の極めて限定的な条件下で「うまく試験を通った!」ことが災いし、単体テスト合格と誤判断して、粗悪品が日本に納品されます。

いや、もしかしたら、オフショア委託先のモジュール単体テストですら、性能要件を満たしていない恐れがあります。

例えば、性能要件が「反応速度3秒以内」だったとしても、「8秒くらいなら許容範囲」と勝手に合格基準が捏造されているかもしれません。日本企業では、極めて悪質な倫理違反ですが、業務経験の浅い外国人若手プログラマの一部は、信じられないほど幼稚な言動をとることがあります。


繰り返しますが、オフショアならではの「工夫」よりも、オフショアならではの「原因」に着目してください。

最後に、「工夫」について。

あるオフショア大學講師は、自身の経験談として、次の障害管理プロセスを紹介してくれました。

障害発生から修正、フィードバック、確認完了までの手順をRedmineのチケットを使って、バグトラッカーのステータスで既定し、その手順どおり対応する。


・・・なるほど。上記は、極めてオーソドックスな障害管理のプロセスだと思います。いわゆるオフショアならではの工夫の跡は、どこにも感じられません。

ですが、前述したように、オフショア大學講師は、オフショアならではの「原因」を正確に把握できているからこそ、このような基本的なプロセスが有効に機能するのです。


■ 問いかけ

<問1>あなたのオフショア開発では、どのようなToolを使って障害管理していますか?

Excel
市販Tool
一般公開される無料Tool(Redmineなど)
社内で内製したTool(有償無償問わず)
その他

結果を見る

締切:2014年10月11日18時00分
協力:クリックアンケート http://clickenquete.com/


<問2>オフショア開発でよくある単体テストの不具合を挙げなさい。


<問3>オフショア開発の単体テストで発生する不具合の原因を頻度順に挙げなさい。

| | Comments (0)

« September 2014 | Main | November 2014 »