初めてのオフショア開発でびっくりしたこと

公開日： 2016年10月4日火曜日 仕事

ベトナムの会社にオフショア開発頼んでみました

都会にいても田舎にいてもコーディングの仕事するのは変わらないぜ！ということで、さらに発展させてオフショア開発とやらを初めて頼んでみました。

文化の違いなのか何なのか、色々戸惑ったこともあるのでメモ。

オフショアを頼んだきっかけは

頼んだ理由はやはり単価。今回頼んだ会社では、
　　　　　日本語のできるブリッジSE:36万円/月
　　　　　一般エンジニア:25万円/月
と言う値段設定。日本国内の3分の1から4分の1くらいの単価です。

そんなこんなで、お客さん（東京）にもオフショア開発を使うことを伝えた上で、離島の私がディレクションして、ベトナムで開発をすることになりました。

オフショア開発での仕事の進め方

初めてのオフショア開発で、こちら側があまり勝手が分かっていないこともあり、仕事の進め方は依頼したオフショア会社にお任せしました。

Backlogでタスク管理をしつつ、毎朝11時～12時（日本時間で。ベトナム時間だと9時～10時）にappear.inで進捗報告を受ける形。

ベトナム側は日本で働いたこともあり、日本語の分かるブリッジSEとやり取りをしました（最初は）

その他にも必要に応じてオンライン打ち合わせを行いました。

初めてのオフショア開発で困ったこと

初めてのオフショア開発は、文化の違いというかなんというか、色々な戸惑いもありました。

言葉の壁

やはり大きいのが言葉の壁。

日本で働いたことがあり、日本語検定2級を持つというブリッジSEさんだったのですが、細かいニュアンスを伝えるのが難しかったです。

途中からはテキストだけでなく絵（ワイヤーフレーム等）もこちらで書くようにして、さらに日本語ではなく英語でコミュニケーションをとるようにしたら大分スムーズになりました。

作業範囲の壁

言葉以上に驚いたのが、作業範囲の認識です。

作業を進める中で仕様の変更が入って（作成するプログラムに変更が発生して）、変更箇所が分かりやすいようにと気を利かせたつもりで変更範囲だけを指示し直しました。

すると、なんと、出てきたのが変更範囲部分のみ。その他の部分は破棄したとのこと。

こちらの指示の仕方も悪かったのかもしれませんが、今回作ろうとしているプログラムの全体像を考えれば変更部分だけ作っても意味の無いことは分かると思うのですが．．．カルチャーギャップを感じ、それいこうは変更箇所だけを指示することは止めることにしました。

「サービスリリース」に対する認識の壁

中間チェックポイントを置いていたので最終的には何とかなったのですが、もし、これを見落としていたら致命的だったのが「サービスリリース」に関する認識の違いです。

「10月1日にサービスリリースです」というと、これまで一緒に仕事をした大半の会社や人は不具合が出ないようにテストも終えた上でサービスリリースとしてくれました。

ところが、この会社なのかベトナム人なのか日本人以外全てなのか、「サービスリリース」といった日にテストも何も済ませていない作ったばかりで不具合がまぎれたプログラムを提出してくるつもりでした。

「不具合あるかもしれないけど、その日に動くんだから良いじゃない」というつもりだった模様。

これは本当に肝を冷やしました。こちらで切ったタスクには「テスト期間」も入れて合ったのですが、「リリースがこの日だから大丈夫」と勝手に脳内保管した上に、日々の進捗確認での進捗率報告をごまかしていた模様。

途中から英語コミュニケーションに変えて、細かいところまで突っ込まなくなった私にも責任があるのですが。

オフショア開発、疲れました

そんなこんなで最終的には何とかつじつまを合わせたオフショア開発ですが、文化の違いをあちこちで感じ、とても疲れました。

正直、出来上がってきたプログラムの質もイマイチでしたし、お客さん側からよほど強いコストダウン要望が無い限りは使いにくいというのが正直な印象です。

まぁ、次があれば、今回の教訓を活かしてもっと上手くまわせるとは思いますが。