せっかく育てたベトナム側のSEがすぐに辞めてしまう

オフショア大學受講生との質疑応答より。
（Q. 受講生 A. オフショア大學講師）

Q.私はオフショアPMOのスタッフです。経営陣と現場の開発チームに挟まれて、中間管理職のようにきつい日々を送っています。当社は、かなり前から中国オフショア開発の実績があるものの、経営陣からは「本当に中国一辺倒でいいのか？」と疑問を投げかけられています。そこで、当社でも、遅ればせながら、ベトナム企業と取引をはじめました。
ところが、ベトナム側では、せっかく育てたSEがすぐに辞めてしまうリスクが早くも顕在化しています。経営陣からは「今さらベトナム企業を時間をかけて育てる気はない」と強い圧力をかけられます。よい対策についてご助言ください。

A.よい対策を生むには、まずはよい原因分析が欠かせません。そこで、せっかく育てたベトナム側のSEがすぐに辞めてしまう状況を可視化するために、具体的に要素分解してみるといいでしょう。

■ 問いかけ

＜問１＞オフショア開発プロジェクトで育てた現地の技術者がすぐに辞めるのは、ベトナム人気質なのでしょうか？

◆Yes
◆No
◆その他

○結果を見る

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

＜問２＞せっかく育てたベトナム側のSEがすぐに辞めてしまう状況を可視化しなさい。例えば、レベル２から３の木構造に要素分解するとよいでしょう。

ベトナム最新文化事情：「お金持ち」考察

ベトナム人若者の心理状態を分析する興味深いデータが届いたので紹介します。

●ベトナム人が「お金持ち」と聞いて思い浮かべること＝車

「車」がベトナム人のお金持ちを象徴するキーワードです。一方、日本人が「お金持ち」と聞いて真っ先に思い浮かべるのは「家」。特に、大きな家に住んでいることがお金持ちの証だと考えられます。

●女性が結婚相手に求める条件として「お金」はどれくらい重要か

日本とベトナムを比べた時、実は日本人女性の方が結婚相手の経済状況を重視する傾向があることがわかりました。

一方で、ベトナムには「お金持ちは幸せになれない」との考え方が存在します。日本にも清廉潔白や「宵越しの銭は持たない」の言葉があるように、必ずしもお金が幸せに直結しない発想には共感できます。大陸中国人には全く理解されないと思いますが。

＜調査方法＞
日越それぞれのソーシャルメディアから「お金持ち」について書かれた記事を抽出して単語ランキングを作成。上位にリストされる単語には、ネットをよく使う若者の心理や思考パターンが示唆されるとの前提で分析しました。

検索ワード：nguoi giau, nha giau, giau co, giau sang （越語）

＜調査元＞
Datasection Vietnam Co., Ltd.
http://datasection.com.vn/

■ 問いかけ

＜問１＞ベトナム人の金持ちが持つ車のランキングを予想しなさい。ただし、あくまでもソーシャルメディア上で「お金持ち」と一緒によく用いられる単語から類推した仮説です。

　Mercedes, Audi, BMW, LEXUS, VOLVO, Ferrari, Porsche ...他

＜問２＞ベトナム人女性が結婚相手に求める重要な条件を挙げなさい。当然ながら「お金持ち」はベスト３にランクインします。

◆高学歴
◆顔がいい
◆やさしい
◆高身長
◆趣味があう
◆健康である
◆粋である・いなせ
◆オシャレ
◆その他

○結果を見る

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

＜問３＞ベトナム人のお金持ちは、なぜ「お金持ち」なのでしょうか？　典型的な答えを予想しなさい。

＜問４＞この調査は、ベトナムオフショア開発推進にどう役立つでしょうか。

ベトナムのQA人材が定着しない

オフショア大學受講生との質疑応答より。
（Q. 受講生 A. オフショア大學講師）

A.当社は、ベトナムに製品開発が主体のオフショア開発を出しています。そのため、現地での品質保証にはかなり力を注いでいます。現地では、少数のテストエンジニアを品質保証スタッフとして採用して、ホワイトボックステストを念入りに繰り返しています。ところが、現地のQA人材が定着せずに困っています。

Q.現地のソフトウェア技術者にとって、品質保証部門は負け組が追いやられる閑職だと認知されている恐れがあります。

質問者によると、ベトナム側の品質保証スタッフは、ホワイトボックスQAのためのテストプログラムを書いています。日本人の感覚だと、品質保証スタッフとはいえ厳密には「エンジニア」に相当します。

ところが、開発からQAに配置転換されるベトナム人技術者にとっては、キャリアの断絶につながる大問題です。会社への帰属意識が薄い多くのベトナム人技術者にとって、いつまでも「QA人材」として働かされるくらいなら、さっさと会社に見切りをつけて転職するのが良策なのではないでしょうか。

■ 問いかけ

＜問１＞「品質保証スタッフは負け組」との認識は、日本とベトナムの国民文化の違いが主な原因である。（Y/N）

◆Yes
◆No
◆その他

○結果を見る

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

＜問２＞「品質保証スタッフは負け組」との認識の強さは国毎に異なると仮定します。「ベトナム／中国／インド／日本」の四カ国を認識の強さ順で並べ替えなさい。

例：ベトナム＞中国＞インド＞日本
　（ベトナムでは最も品質保証スタッフは嫌われる）

＜問３＞もし、上記のベトナム現地で、日本語学科出身のコミュニケーターを品質保証スタッフとして育成しようと試みたら、成功すると思いますか？　成功率を数値で示しなさい（0-100）。

＜問４＞上記事例のベトナムのQA人材が定着しない問題について、有効な対策を考案しなさい。

進捗報告で誤解を招くインド英語の時制・態・相

オフショア大學受講生との質疑応答より。
（Q. 受講生 A. オフショア大學講師）

Q.当社は、半年前からインドオフショア開発に取り組んでいます。定例の進捗会議で、オフショア側がこちらの質問には直接回答してくれません。会議で、オフショア側が作業を「やった」と言ったのに、実際には「着手済だけど未完了」であったり、逆に、いつまでも進捗 100％にならず心配していたら、実はとっくに作業完了していた！　なんてこともしばしば。どうすれば、オフショア側から正確な進捗報告があがってくるようになりますか？

A.オフショア開発でよくある進捗確認の齟齬にはいくつか典型的な原因があります。よくあるのは、単純な言葉の壁、オフショア側の経験不足による誤判断、など。

さらに、稀に、以下の原因によってコミュニケーション齟齬が発生することがあります。

・インド英語と標準英語では、時制・態・相の表現が異なるから

　インド： I have read the specification yesterday.
　標準英： I read the specification yesterday.

恐らく、ヒンディー語やベンガル語の文法がインド英語に影響を与えていると推測されます。

※参考：榎木薗鉄也（2012）、インド英語のリスニング、研究社

ついでに、中国オフショア開発でありがちなコミュニケーション齟齬についても考察します。中国語と日本語も時制・態・相の表現が異なるため、進捗報告の場面で想定外のトラブルが発生することがあります。詳細は、以下の過去記事をご覧ください。

- いきなり「データを更新しませんでした」の理由
- 「今日終わります」は既に完了済み

■ 問いかけ

＜問１＞受験英語でよくある単純な文法問題です。英語の時制・態・相の表現を考慮して、以下のインド英語が誤解される理由を簡潔に述べなさい。

インド： I have read the specification yesterday.
標準英： I read the specification yesterday.

＜問２＞インド英語の特徴を以下の選択肢から１つ選びなさい。

◆「ホテル」の意味で、"restaurant" を用いる
◆「すいません（excuse me）」の意味で、"hello" を用いる
◆上位者への呼びかけで、"-sama"を用いる（例：boss-sama）
◆出身地を聞く際に、"What is your good place?" を用いる

○結果を見る

締切：2014年12月24日18時
協力：クリックアンケート http://clickenquete.com/

【事例】炎上プロジェクト現場聞き取り調査の留意点

親会社の強い意向により、去年から我が社でも中国オフショア開発を始めました。我が社の業務は、ほとんど親会社から委託されたシステム開発と保守運用です。

これまで、我が社は、国内協力会社への「持ち帰り」発注ですらほとんど経験したことがありません。いわゆる、親会社に依存する典型的なシステム子会社です。よって、現場はかなり混乱しています。

言葉の壁を克服するために、最近、親会社からの紹介で中国人ブリッジSE（34歳・男性）を１名、派遣してもらいました。現在、彼は当社の日本人に混じって、働いています。

ところが、派遣された中国人ブリッジSEのエリート意識の高さが災いして、オフショア委託先の中国人技術者らと仲間割れを起こしました。

オフショア開発に不慣れな日本側は、自社に常駐する日本語が堪能なブリッジSEの意見にのみ耳を傾けたため、現場はさらに混乱しました。

■ 問いかけ

＜問１＞あなたは、当プロジェクトにリカバリ応援要員として緊急投入されることになりました。期間限定で、できるだけ工数をかけずに、混乱するプロジェクトを沈静化させる役目が期待されます。

あなたは、最初の現場聞き取り調査に挑むにあたり、どのような点に注意しますか。以下の選択肢から、あなたの考えに近い意見を１つ選びなさい。

◆開発プロセスや各種規約の不十分さを疑う
◆日本常駐するブリッジSEの力量不足を疑う
◆中国側リーダー／マネジメントの力量不足を疑う
◆親会社と子会社の関係不備、ガバナンス欠如を疑う

○結果を見る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■ 問いかけ

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

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

○結果を見る

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

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

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

社長肝いりのベンダー選定だがブリッジSEが使えない

以下の事例を読んで、後の設問に答えなさい。

●ユーザー企業情報システム部門担当者からの相談より

今年の年明け、うちの社長が幹部会議にいきなり中国系の会社社長（本社＝東京）を連れてきました。簡単に挨拶を交わした後、オフショア開発に関する一般的な注意点について講演してもらいました。講演最後には、自社のオフショア開発受託に関する実績紹介もありました。

あれから半年後、当社でも、初めて中国オフショア開発に挑戦することになりました。委託先は、半年前に突然現れた例の中国系企業です。

当社の中国オフショア開発の実施体制は以下の通りです。

・システム利用者＝当社事業部

・要件定義と設計＝当社情報システム部門

・製造とテスト＝中国大陸、沿岸部主要都市から飛行機で２時間以上も離れた中堅都市の独立系ソフトウェア企業

・窓口＝東京の中国系会社を経由

ところが、最近、この体制に疑問を感じています。

社長の肝いりでオフショア開発を始めたまではよかったのですが、いざ現地とのQ＆A連絡がはじまると、在京の窓口企業から派遣されたオンサイトのブリッジSEがまるで機能しません。

私は、すぐに担当交替を要求したいのですが、現実にはなかなかそうもいきません。担当の即時入れ替えが難しいとなると、他にどのようなリカバリ策が考えられますか。

後から聞いた話ですが、うちの社長と在京の窓口中国系企業は、社外の交換会でたまたま知り合ったそうです。窓口企業と言いながら、実際には社内にオフショア開発の知見はほとんどなさそう。

■ 問いかけ

間接オフショア開発でブリッジSEが役立たず。実務担当者は現地と直接交流したいが、社長肝いりのベンダー選定。さて、どうする？

◆ブリッジSEを即時交替させる強行手段
◆ブリッジSEは継続、日本人を緊急投入し現地に派遣
◆窓口企業を経由せず中国側と直接やり取りする
◆全てリセットして他の発注先を探す
◆現状維持

○結果を見る

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

手続き型プログラミングっぽいメソッド名

先日出題したクイズを補足説明します。

＜問１＞Javaプログラミングで「顧客情報のステータスをアクティブにする」メソッドメソッド名称を決める際、英語としての可読性がよい選択肢を１つ選びなさい。

(a) doActive()
(b) setActive()
(c) changeActive()
(d) activate()

○結果を見る

クリック得票数は少ないものの、答えはほぼ均等に分散しています。

以下、答えのヒントを解説します。

票を伸ばした選択肢(c) changeActive()　について。

学校英語の常識だと「顧客情報のステータスをアクティブにする」の日本人的な英訳は以下のような感じでしょう。

- to change status to active.（冠詞などは無視）

すると、あえて動詞 change を使うなら、changeStatus() がより適切なような気がします。この場合は引数に「アクティブ」を指定する仕様となるので、さらに英語らしさを重視するなら、前置詞 to を付与するとよいでしょう。

changeStatusTo( ACTIVE ); # こんな感じで

選択肢(b) setActive() についても考え方は同様です。

念のため、ここから、オフショア開発に関連する話題にも一応触れておきます。さもないと、本誌は単なる英語学習のメルマガだと誤解されそうなので。

選択肢(d) activate() の主語は、「顧客情報」だとみなせます。すると、いわゆる無生物主語構文（S+V型）であり、如何にも英語的な表現だと言えます。

この発想は典型的な「オブジェクト指向」です。

一方、選択肢(b)や(c)は、英語としては特に問題ありませんが、何となく日本人が発想しがちな表現です。

選択肢(b)や(c)の発想は、前後の文脈にも強く依存しますが、いわゆる「手続き型」プログラミングでありがちな関数のI/F仕様です。

ここでオフショア開発プロジェクトでありがちな場面を想定します。

・海外オフショア委託先の技術者
＝ 学生時代から Java言語＆オブジェクト指向しか知らない

・日本で設計しオフショア委託先にコーディング依頼する技術者
＝ 入社後にＣやＶＢでプログラミングを学んだ。Javaが主流となった現在も、いまだに手続き型の発想で設計しがち

もし、過去の習慣が身体に染み付いた日本人が changeStatusTo( ACTIVE ) を手続き型プログラミングの発想で設計したなら・・・。

このような設計に不本意ながら従わされるオフショア開発委託先の外国人SEは「また Javaで不自然な設計が強要された。これだから日本人は・・・」と陰口を叩いているかもしれません。

こんな話は、まず表沙汰になりませんが、念のため、以下の事情を知っておくとよいでしょう。

・中国オフショア委託先の若い外SEは「日本人の技術力は低い」と心底、信じている（他国の事情については断言できませんが、恐らく、似た感覚だと思います）

・中国オフショア委託先から、日本人による不適切な設計に対して、頻繁に改善提案がなされるものの、大人の事情により、的を射た提案であっても却下されることが多い（全体が手続き型プログラミングの発想で設計されているため、部分最適化しても意味なし。よって提案が却下される結果に）

こんな裏事情も含めて、四択問題の正解や詳細については、来週の第50回オフショア開発勉強会にて解説します。乞うご期待。

■ 問いかけ

＜問１＞選択肢(b) setActive() を英語らしさを重視して書き換えなさい。もちろん、仕様は「顧客情報のステータスをアクティブにする」である。

＜問２＞オブジェクト指向系のプログラミング言語なのに、いかにも手続き型っぽい設計やコーディングをしてくるのは？

◆日本＞オフショア委託先（日本が多い、という意味）
◆日本＜オフショア委託先
◆日本≒オフショア委託先（どちらもよくある）
◆日本≒オフショア委託先（どちらも少ない）
◆個人差が大きいので国や地域は関係ない

○結果を見る

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

getData()のコアイメージ

先日の出題を再掲します。

＜問１＞Javaプログラミングで、出力用データを生成するメソッド名称を決める際、英語としての可読性がよい選択肢を１つ選びなさ い。

(a) createOutputData()
(b) makeOutputData()
(c) どちらも可読性はよい、大差なし

○結果を見る

このアンケートに対して、読者からコメントが届きました。

↑の答えは(a)でしょうけど、ファイル等にはきだすのではなく、ただメモリ上に値をもらう場合は、 Get とかもシンプルで良いかと。結局は英語うんぬんよりも、「マイクロソフトとかGoogleとかはどうしているのか」に寄る事も多いですね。（日本人／オフショア経験豊富）

ご意見ありがとうございます。他にも、英語が苦手な日本人SEが犯しがちな英語報告の失敗例も紹介してもらいました。

ファイル等にはきだすのではなく、ただメモリ上に値をもらう場合のメソッド名称として getOutputData() でもいいのではないか、とのご意見について、英単語のコアイメージの観点から補足説明します。

まず、英単語 get のコアイメージについて。

get のコアイメージは「状態変化」です。
決して「取る（ゲットする）」ではありません。

すなわち、get を使う局面では、前提条件として「以前の状態」と「変化後の状態」の二つの要素が暗黙のうちに想定されます。

もし、出力用データを新規生成するメソッド名称を決める際、特に「新規性」に強調するなら get よりも create を使った方がよりイメージが伝わります。

- createOutputData() ... 普通に新規データ生成の印象

一方、重要なアルゴリズムによって「既存データが変換」されて出力用データが生成される際には、make を使うとそれっぽい印象が醸し出せます。

make のコアイメージより「ある原材料に人が手を加えてデータ生成した」印象が強調されます。

- makeOutputData() ... データがわざわざ「作られた」感アリ

一方、getOutputData() を使うと、空っぽの状態だったメモリ空間に、所定の出力用データが移されてメモリ空間が満たされた状態に変化した印象が強調されます。

- getOutputData() ... 何らかの変化？ → 普通は取得という！

だからこそ、getOutputData() は「データ生成」よりも「データ取得」の役割がピッタリ当てはまります。英単語 get のコアイメージは「取る（ゲットする）」ではなく「状態変化」だと覚えましょう。

■ 問いかけ

今日も、以下のクイズに挑戦！

【課題】あなたは、設計書の指示にしたがって Java 言語でプログラミングします。メソッドや変数を英語で適切に命名しなさい。

＜問１＞あるルーチン内で、一時的に利用された後すぐに破棄される儚い運命のデータを生成して作業用メモリに保管するメソッドに相応しい名称（例えば、並べ替えアルゴリズムで作業用データを一時的に取得したい場合）

(a) getData()
(b) holdData()
(c) openData()
(d) keepData()

あなたの直感を信じて「これだ！」と思う選択肢をクリックしまし
ょう。結果は後日集計されて、今後のオフショア大學講座に反映さ
れます。ご協力のほど、よろしくお願いいたします。

○結果を見る

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

インターネット接続料金を参照するメソッド

【課題】あなたは、設計書の指示にしたがって Java 言語でプログラミングします。メソッドや変数を英語で適切に命名しなさい。

＜問＞Javaプログラミングで、最新のインターネット接続料金を参照するメソッド名を決める際、英語としての可読性がよい選択肢を１つ選びなさい。

(a) fee()
(b) cost()
(c) price()
(d) charge()

あなたの直感を信じて「これだ！」と思う選択肢をクリックしましょう。結果は後日集計されて、今後のオフショア大學講座に反映されます。ご協力のほど、よろしくお願いいたします。

○結果を見る

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