実用

【オガティ外伝】オフショア開発の巻 in ベトナム(オフショアの課題編)

今回が本当に最後になります。ベトナムオフショア開発の最後のお話です。
はりきっていきましょう!
永遠の輝き、リモートワーカーのコウダインテだよ!シンチャオ!

12月ですね。諸説ありますが、師走というのは「師匠が走り回るくらい忙しい時期」と言われています。
あなたは師匠といい関係を築いていますか?
余計なお世話ですね。
では、クリスマスのご予定は?
余計なお世話ですね。

そんなことは置いといて、前後編に分けて「オフショア開発をするにあたって」「ベトナムでの生活」など、開発とプライベートについて記事にしてきましたが、2回に分けても書ききれなかった「オフショア開発の効果」について紹介します。
あまり芳しい結果を得られなかった今回のオフショア開発でしたが、その原因とそもそもの「オフショア開発」についてスポットを当てて紹介するナムよ。


オフショア開発を振り返って


前編に書きましたが、もう一度「オフショア開発とは?」をおさらいしましょう。
「システムやソフトウェア開発、または保守運用業務を海外の開発会社、海外の子会社に発注し、開発コストを抑えることです」

日本より人件費の安い海外に仕事をアウトソーシングすること、です。

カタリストではベトナムでのオフショア開発を2015年1月から9月の約9ヶ月間で実施しました。
【オガティ外伝】オフショア開発の巻 in ベトナム(前編)
実際にやってみたオフショア開発の結果を振り返りましょう。

現地でオフショア開発に携わったオガティにまたもやいろいろ聞いてみました。
オガティの感想は「日本でやった方が早かったかもしれない」でした。
オフショア開発は難しく、思ったほどの効果が出ないとよく耳にします。
今回カタリストが実施したオフショア開発はすべてが失敗というわけではなく、よかった部分と悪かった部分の両方があります。
まずは悪かった部分を紹介します。

  • 最初にコミュニケーションの壁があり、現地作業に慣れるまで時間がかかるので短期だと日本人にかかる人件費や滞在費などのコストを現地の安価な人件費でカバーできない
  • 開発規模が割りに合わなかった。
  • 仕事の割り振りが大変
  • 慣れない仕様書、設計書の作成に時間がかかった
  • 現地での生活費もかかる

ここにはカタリスト独自の原因も存在しますが、1つずつ紹介します。

コミュニケーションの壁


これは最大の難関です。最初から英語かベトナム語が話せる人材が揃っていれば問題ないのですが、いない場合は何をするにも通訳を介さないといけない、自分の言いたいことが上手く伝わらない、現地スタッフもコミュニケーション不足でこちらの言いたいことを汲み取れない、といった問題が散在しています。
例えば現地での打ち合わせひとつ取っても、

  1. オガティが日本語でコミュニケーターに伝える
  2. コミュニケーターがベトナム語でそれをエンジニアに伝える
  3. エンジニアからベトナム語で質問される
  4. コミュニケーターがそれを日本語でオガティに伝える
  5. オガティがその回答を日本語でコミュニケーターに・・・・

とすべてのやり取りをコミュニケーター経由で行なうために手間が通常の倍かかることになります。喧嘩してるカップルの仲介をする友人みたいですね。

仲裁するオガティ

しかし長期のプロジェクトであれば、コミュニケーターやエンジニアも慣れていきます。慣れたコミュニケーターはオガティの言いたいことを汲み取って、すべてオガティに質問せずとも自分で回答してくれるようになります。長い付き合いがあれば、お互いの言語の端々から理解できる単語を拾って意味を解釈できるかもしれません。エンジニアそれぞれの性格を把握すれば、投げかける質問の仕方を変えて分かりやすくできるかもしれません。
そうすれば作業効率も上がるのでコミュニケーションにかかるコストが時間とともに回収できます。

開発規模が割りに合わなかった


今回カタリストで採用した現地エンジニアは3名(+通訳1名)で日本でのエンジニアは7名と、全体で10名程度の開発規模での体制となっていましたが、現地エンジニアのコストに対して日本人のコスト(初期設備、渡航費、滞在費などを含む)が上回ってしまうため、オフショアの初期コストを回収できませんでした。
もっと現地エンジニアを雇用していないと効果が上がらないとオガティは考えており、現地にいた他社の日本人スタッフも同じ考えだったそうです。
開発規模的に現地エンジニアを数年単位で長期的にたくさん雇用できる体制にないと損益分岐点を超える効率が生み出せないので、大規模開発なら向いているとオガティは言います。

仕事の割り振りが大変


コミュニケーションの壁にも関連しますが、何から何まで通訳を介するため、自分が伝えたいことが上手く伝わらないことも多く、「何のためにその仕事を与えるのか」を説明し、納得させるのに難儀しました。委託側でも、各スタッフの技術レベルや性格を把握できていないとうまく采配できないので、短期の案件だとマネージメントには苦労しそうです。

仕様書、設計書の作成


これはカタリスト独自の問題なのですが、カタリストでは基本的に「仕様書」は存在しません。その理由としては、「少人数で開発」「変化する要求に柔軟に対応するため」が挙げられます。各担当者が一人または少人数で要件定義からリリースまで一貫して担当するため、スピーディな対応ができることが強みですが、反面このやり方だと大人数での開発の場合に情報共有が難しくなるデメリットはあります。
この手法の弱みが顕著に出たようで、初めてのスタッフと初めての案件であるために、プロジェクトの目的やプロダクトの内容についての情報共有が必須であり、しかも言語の違う国での作業になるため「阿吽の呼吸」なんてものは存在しません。
そのためイチからすべてを説明し、何をどうするか一つひとつ理解させる必要があります。
しかもそれを通訳を介して行なうのです。どうですか、吐き気がするでしょう?
さらに普段なかなかやることのない仕様書の作成という作業ですから、ここに労力が割かれるのは想像に難くないはずです。
(ただオガティは前職で上流工程については豊富な経験があるので、本人は辛かったと言ってますが、他のメンバーだったらもっと辛かったと思いますし、泣きながら帰国してた可能性もあります)

現地での生活費


意外とここが見落とされがちですが、ベトナムで生きてくのもお金がかかるんですよ。
日本ほどではないにしても、ホテル代、食費、交通費、夜の交際費など出費はいろいろありますし、人によってピンきりではあります。
一般的にベトナムでのひと月の生活費は5~10万円と言われています。
10万だと結構豪遊しているみたいです。
移動は電車やバスがないので基本的にタクシー移動で、ホテルの前にタクシーが待ってたそうです。(これはホテルによるかもしれません)
歩いて30分くらいの距離でタクシーだと500円くらい。安くはないですね。日本と変わらないかもしれません。
どこまで補填してくれるのかは会社で違うでしょうが、コストにはなりますね。

このようにさまざまな要因があり、今回のオフショア案件については思っていた以上の効果は挙げられませんでした。試験的にオフショア開発を経験してみた側面もありましたが、ではどうすればよかったのか?

オフショア開発するならここを注意しろ!


問題点を羅列してきましたが、「ではどうすれば改善できるのか?」をオガティに聞いてみました。

開発にかける人数と期間


失敗の理由にも書きましたが、今回の現地エンジニア3名という人数では「人件費の安さ」というメリットを活かしきれませんでした。さらに9ヶ月という中途半端な短さも原因と考えられます。
これでは日本側スタッフにかかる費用+現地でオガティにかかるコストを相殺できません。
現地エンジニアが日本の1/3で雇えるということは単純に考えても3人で日本人一人分以上の効果が出ないと意味がありません。
しかしその効果を求めるには時間がかかります。たとえ、どれだけ優秀な現地エンジニアだとしても、コミュニケーションの壁は絶対に存在します。
このコミュニケーションの壁を突破しつつコストを超える効果をあげるためには「長期の雇用」がどうしても必要になります。さらに雇用するスタッフ数は、関わる日本人スタッフ以上の人数が必要です。
そのため一般的に「10名以上で1年以上の雇用」と言われており、オガティもそれを肌で感じました。

コミュニケーターは絶対妥協するな!


現地エンジニアとの日常業務では基本的にコミュニケーターを介して連絡をとります。そのためコミュニケーターの重要性は無視できません。
コミュニケーターがオフショア成功の8割を握ると言っても過言ではありません。(現地語を話せる人材がいない場合ですが。)
ですのでコミュニケーターの採用には妥協は許されません。
カタリストでコミュニケーターを採用するにあたって決めた基準を参考に紹介します。
日本語のレベル
日常会話程度の日本語が話せるか、こちらの日本語を正しく理解できるか。

日本語能力試験の有無
外国人の日本語能力を測る試験です。N1~N5まであり、N3以上あれば日常会話はできますが、業務的にはN2以上が欲しいところです。

日本への留学経験
日本語が話せるだけなく、実際に日本の文化に触れたことがあるか。日本での就労経験もあれば、日本人と働く感覚を持っているのでなおよいです。

オフショア開発で日本の仕事をしたことがある 
過去にオフショア開発を経験したことがある」のはかなり大きいメリットです。日本人の仕事の慣習や文化を既にある程度理解しているので、コミュニケーションの壁が最初から低くなっています。

今回のカタリストのオフショア開発では、最初の2ヶ月程度は暫定のコミュニケーターをオフショア提供元からお借りする形で、しかも定期的に人が入れ替わってしまうため、イチからコミュニケーターとの関係を築く必要がありました。そのため最初の頃はなかなかスムーズなやり取りができなかったそうです。
しかし後期には正式なコミュニケーターを採用できました。しかもこちらの求める条件を達成しており、非常に優秀なコミュニケーターでした。
コミュニケーターが変われば業務の速度も格段に上がります。実際、正式なコミュニケーターを採用してからは、日に日にお互いの気持ちを汲み取れるようになり、オガティが言いたいことをコミュニケーターが代弁してくれるようになったそうで、オガティの負担は徐々に減っていきました。
コミュニケーターを妥協することは、その後の業務に障害を残すことになります。
妥協せず、時間がかかっても優秀なコミュニケーターを探すことを諦めなかったおかげで、日々の打ち合わせ、業務内容の相談、指示などにかかるストレスも軽減され、精神的にも健全な生活を送ることができます。
コミュニケーターを笑うものは、コミュニケーターに泣く。

しばらくはマネージメントに徹する


当初の想定では、最初こそ現場への指示や設計の説明などに時間はかかるものの、すぐに自分のコーディング作業にかかれるとオガティは思っていました。
しかしそうはいかないのがオフショアの怖いところ。
設計書の作成、コードレビュー、日本とのやり取りなどに追われ、オガティがコーディングできる時間は非常に限られていました。

これは当初の見積もりが甘かったこともありますが、想定以上に現地でのマネージメントには時間を取られるということです。
日本でのプロジェクトと違い、言葉の違いというのは思った以上の障害となります。
そして文化の違い、エンジニアがテストをしないという想定外の出来事も重なり、オガティはそれらのカバーにほとんどの時間を割きました。(テストの項目書まで全部オガティが作ってました)
最初の頃はソースレビューも一つ一つオガティが行ない、すべてのチェック作業に時間を取られました。何をするにも最初はチェックが必要です。現地エンジニアがこちらの求める品質を提供できるまで続きます。
なので、「空いた時間にコード書くからなんとかなるだろう」はやめたほうがいいです。
作業を見積もるなら「自分はコーディングしない前提」で考えましょう。
それでも長期間やっていれば徐々にチェックする箇所も減りますし、現地エンジニアのレベルも上がってきますのでマネージャーの負担は減っていきます。
今回9ヶ月ほどのオフショアでしたが、1年以上の期間であれば自分の時間を作れるようになっていたかもしれません。

委託する内容を考える


言語の壁は厚いですが、やってもらう業務内容によっては壁を無視することもできます。
なぜ言語の違いが障害になるのか。それは「細かな仕様、ニュアンスを伝える必要」があるからです。逆に言うと、伝えることが少なければ言語の違いはあまり壁になりません。
あまり考えずにできるような簡単な作業、例えばサービス運用に必要なマスタデータの入力のような「既に用意されたものを打ち込むだけ」の作業であれば、日本人を雇うよりかなりコスパがよくなります。
日本でもよくあるような「データを入れるだけの簡単なお仕事です」っていうやつですね。

開発に精通した人間が現地駐在する


業務で使用する環境ではどうしても想定外の不具合が出るものです。使っていたVM(仮想マシン)が急に動かなくなった、ブラウザの挙動がおかしい、パソコンが固まるなどありますよね。ないですか?
そんなとき、経験の長いエンジニアなら「ここをこうすれば直る」ということを経験で知っているものです。現在使用している環境に精通しているエンジニアであれば、現地エンジニアにすぐ救いの手を差し伸べることができます。
できるだけ開発経験のある人材を現地に送ることをオススメします。
実際オガティはオフショア開発の後半は日本からのリモートで作業していましたが、現地エンジニアからヘルプが出ても状況がわからず復旧に手間取ったこともあるようです。
現地にいればすぐに対応できますが、離れているとわからないことも多いです。
ただ、経験の浅いエンジニアだとしても現地で成長しますので、これは絶対的な条件ではないかもしれません。でも時間は惜しいものです。なるべく業務に精通した人が現地に駐在した方が効率的ですね。

採用の際にはテストスキルも確認する


これはベトナム以外の国もそうかもしれませんが、本記事の前編にも書いたようにベトナムではエンジニアが自分でテストをする風習がありませんでした。
そのため採用段階で「テストをしたことがあるか」くらいは聞いておいた方がいいです。
テスト経験があればしめたものです。なければエンジニアのスキルと天秤にかけましょう。
テスト項目書も作れるなら相当な人材です。逃さないようにしましょう。

ホーチミンの風景

現地の人とは仲良くしましょう


私自身、オフショア開発の経験がないのでオガティにインタビューしながら記事を書いていますが、すべて聞いた話なのはどうかと思い、自分なりにオフショアに関するさまざまな記事を読んで考察しました。
ほとんどの記事で書いてあることは「結局はコミュニケーションにつきる」ということでした。コミュニケーションを深められるかどうかが成功の可否を決めると。
これはオフショアでなくて、国内の案件でもそうですよね。日本人だけのチームでもコミュニケーションが不足していれば意思の疎通ができず、目標が共有できずに違う方向に進んでしまう、なんてことはよく聞くことです。
オフショア開発で特にコミュニケーションの大事さが語られる原因としては「新興国をどこか下に見てしまう」部分があるからではないでしょうか。
どうせ言っても伝わらない、めんどくさいから丸投げしよう、なんとなく伝わるだろうなんて気持ちでオフショア開発するのは絶対にやめるべきです。

日本人同士ですら難しいコミュニケーション。言葉が違う外国ならより一層難しいでしょう。
しかし難しく考えることはありません。
相手の言うことを真摯な姿勢で聞き、意思を丁寧に伝える、うまくできれば褒め、失敗すれば何が原因なのか一緒に考える。
日本人のチームと何が違うでしょう?違うのは言葉だけです。同じ人間なんです。
あなたが真剣に思いを伝えたいと思うなら、相手はきっと受け取ってくれるはずです。

オガティの場合は、現地のエンジニアとできる限り同じ時間を過ごすようにしました。
ランチを一緒に取ったり、夜は飲みに行ったり、直接エンジニアと話すのです。もちろんベトナム語はほとんど話せないのでカタコトの英語です。

今回のベトナム人エンジニアはみんな英語が話せました。共通言語である英語であれば、ある程度の日常会話ができたそうです。そして今ではフェイスブックで連絡を取り合うような関係になっています。
もちろんベトナム語も多少覚えました。
ヒューローイ → わかった、了解
サムローイ → 既に完了してます

これは打ち合わせ中によく飛び交っていたので覚えてしまったそうです。

最初からすべてを理解することはできません。でも少しずつ積み上げることはできます。
言葉の理解も信頼も少しずつ積み上げて、いい関係を築くことが一番大事なのではないでしょうか。
片方の考え方、やり方、文化を押し付けるのではなく、お互いに尊重しあい、いい部分を取り入れ、悪い部分を切り捨て、よりよい文化を作れるといいですね。

あとがき


今回のベトナム編はこれで最後になります。
3部になりましたが、最後まで読んで頂いた方がいれば心から感謝致します。
途中からでも読んで頂いていればそれはそれで感謝致します。

オフショア開発というものをこの記事を通して多少理解できたような気がしますが、やはり実際に現地で得られる経験にはかなわないですよね。
またカタリストでオフショア開発があれば記事にしたいと思いますが、それはいつになるやら。

これからオフショア開発を考えている企業の方、またはベトナム人エンジニアの採用を考えている方たちの参考になればと思い、今回の記事を書きました。
「カタリストが経験したベトナムのオフショア開発」ですので、目線が偏ってしまっているかもしれませんが、これも一つの意見として捉えて頂ければ幸いです。

次週はシンタニのゼロから入門!マイコン開発!~回路を作ってみようをお届けします。
ワクワクするタイトルですね。理系男子の心をくすぐります。

ではみなさん、最後までお付き合い頂きありがとうございました。また会いましょう。
ヘンガップライ!!

引用元・出典
オフショア開発とは
N1~N5:認定の目安 | 日本語能力試験 JLPT

LINEで送る
Pocket

この記事を書いた人・プロフィール
コウダインテ
ニックネーム: コウダインテ

北海道で一人リモートワーク。
主にPHP、PostgreSQLを使用。
ピアノはあるけど10年くらい弾いてない。
最近ゴルフを始めましたが、パターがダメで諦めそう。
車は5MTの軽自動車。無駄に変速できる。