ベトナムでオフショアチーム立ち上げに携わった話
Tweet
こんにちは、サービス開発部の村山です。
GMOメディア株式会社では会社概要にも記載されている通りオフショア開発を行っております。
https://www.gmo.media/company/
グループ会社であるGMO Z.com Run System社とラボ契約を結び連携しています。
アプリチームとしてiOSアプリ4名とAndroidアプリ4名のチームでコラボレーション開発をしておりました。
この度2016年の5月から好調のアプリチームに続き、サーバーサイドチームを立ち上げることになりました。 言語はRuby on Rails、Java、PHPの3言語です。
私はテクニカルマネージャーとして6ヶ月間現地に赴任してPHPチームの立ち上げを行ってきました。
前提
サーバーサイド開発は無くならない。
- ネイティブアプリであろうがブラウザアプリであろうが、データを扱うという点では変わらない
- サーバサイドがないとデータが扱えない
- サーバサイドの開発力強化は必須
目的
2016年の会社としてのエンジニアリング指針(技術立国を目指すために)
- 技術的負債の解消
- エンジニアの成長
- 新規事業創出+成長の仕組み作り
エンジニアにとって魅力的な職場に(既存社員エンジニアの技術を伸ばすことのできる環境と機会の創出)
- エンジニアを育成するために新しい技術に触れる機会を作る
- 既存の運用業務ばかりでチャレンジできる環境が作れていない
- 古い技術でなく先端の技術を追うことで大きく成長できる
ビジネスサイドの観点から
- コストメリットがある(新卒エンジニアよりも低いコストで確保できる)
- スケールメリットがある(採用難易度やチーム拡大の観点から)
- 事業の進捗に合わせて1ヶ月単位で担当プロジェクトを変更や人員調整が可能である(コスト調整も容易)
運用の部分をベトナムのチームでまかなうことで日本人エンジニアのジョブローテーションや新規サービスへのチャレンジなどを多くできる環境と機会を創出する。
間違えてはいけないこと
ラボで一緒に働くベトナム人エンジニアはGMOメディアの都合の良いリソースではない
- 協力してくれる仲間である
- 彼らにも彼らのキャリア、人生がある。
- 我々の負債を押し付けるだけではいけない。スキルアップの機会を作る
派遣メンバーの選定
今回の派遣は複数人であることが決まっていました。
- 何か問題があった時に相談して対処が可能
- 現地で各々が得た情報や経験を共有できる
- 精神的にも支え合える
そして下記の条件に合うメンバーを選定しました。
- 連携対象の媒体を熟知している
- メンタルとフィジカルが強い(冗談みたいですが重要です)
- 責任持って職務を行え、教育やチームビルドが可能
この条件まで絞るとだいぶ派遣できる人数が少なくなってきました。 今回、英語のスキルは問いませんでした。私としては英語を勉強する機会を作ってから飛ぶことでより初期の段階からコミュニケーションが取りやすくなる気がしました。
現地視察
私の中ではこの視察に行く前は、かなり不安でした。まず、言葉が通じないという部分と食の部分などで問題があるのではと思っていました。 また、ネット環境も良くないイメージがあって、暮らせていけるのかという気持ちでいました。
視察の目的
- アサインできそうなベトナム人エンジニアとの面談
- 不動産を回って予算にあった家を決める
- ベトナムを知る
面談
現地の候補エンジニアたちに今回のプロジェクトの概要と目的、今後のスケジュールについて英語で共有しました。 途中に通訳の方がベトナム語に訳してくださったので、現地のエンジニアたちは理解してくれていたと思います。
そのあと、英語で考えてきた質問を聞いてみました。結果、私の担当のPHPエンジニアは英語で会話が全くできずに終わってしまいました。 (後日、この二人のエンジニアはアサインできない旨を伝えて別のエンジニアと働くことになりました)
不動産回り
今回はハノイにある3つの日系の不動産会社に依頼をして幾つかの部屋を紹介していただきました。
- 2ベットルームを2部屋
- できる限り同じ建物内
- 会社からタクシーで15分以内
- 予算の範囲内であること
上記の条件で探してもらいました。 ベトナムの家は広さが関係なく部屋単位で料金が決まっている印象を受けました。(1ベットと2ベットで違うのに値段が一緒だった)
また、二人で住むというのは精神的な面も考慮して決めました。 (今では慣れているので1人部屋とかでも困らなくなりましたが、2人部屋でよかったと思うことがたくさんありました)
ベトナムを知る
私たちは視察の際はハノイの旧市街のエリアに泊まりました。ベトナムのイメージそのままで活気があるエリアでした。 日中や夜、バイクのクラクションに悩まされましたが、今ではもう慣れました。 (バイクが自由に走るのでこちらに気づいてもらうために普通にクラクション鳴らしまくってました)
ビールが100円だったり、もちろんスターアニス(八角)やパクチーなども経験して、最終日には日本人街でラーメンと居酒屋に行きました。 日本食が食べれたというのも一つ大きく安心できた点だと思います。
赴任(第1期)
オンラインで面接やらをしてエンジニアを確保できたところで赴任しました。 最初の赴任は5月から6月末までです。
最初の目的は「ワークフローを回せること」でした。
やったこと
- 環境構築
- 媒体説明
- リポジトリの構成説明
- ワークフローの説明
- タスクの依頼からコードレビューまでを繰り返す
できたこと
- 上記全部
できなかったこと
- JavaScript系のタスク
- Push通知系タスク(端末が少なくて検証できない)
- ブリッジエンジニアの負荷軽減
最初はかなり大変でした。説明することがたくさんあり、英語で話しかけれらるけど発音がお互い良くなくてわからなかったです。 また、依頼できるタスクが少なく、タスクを作ること、レビューをして返すというのがかなり大変でした。
タスク管理
生産性
itoyaで出国日に買ったホワイトボードが問題を解決してくれた
振り返り(第1期)
7月初週に日本に一時帰国しました。そして3ヶ月やってみての継続判断を各チームで行いました。
また次の赴任時の目標を設定し、中期計画の見直しも行いました。
赴任(第2期)
今回の目的は日本側の部署とワークフローを回すことでした。
タスクごとに日本側のサポートエンジニアをつけて、サポートやレビュー、リリースまでを行ってもらいました。
やったこと
- 新ワークフローの説明
- 日本側の部署と連携
- 連携のサポート
- 翻訳者に媒体の機能説明
- エンジニアへの教育カリキュラムの実施
できたこと
- ワークフローを回す
- 翻訳者の媒体理解度向上
- エンジニアの基礎知識、スキル向上
できなかったこと
- 運用負荷を削減したワークフローの構築
- タスクの準備と依頼
ベトナムのチームができる範囲が少ないということと、それを日本側がリモートの状態でどこまで広げていけるのかが課題でした。 その点関しては全くトライはできませんでした。
範囲が少ないので依頼できるタスクが限られてきます。難易度も簡単なものになるので、半日もたたずに終わってしまいました。 また、設計は日本側でやっていたので、日本で実装した方が早いということも起こりました。(日本の負荷 >>>> ベトナム側の実装スピード)
ベトナム側では現地でできることとして、社内で昔実施していたエンジニアの教育カリキュラムを英訳化して依頼したり、 自媒体にしかないコンポーネントやORマッパーに関する教育カリキュラムも同一フォーマットで作成しました。
Googleフォームで答えるテスト形式で作りましたが、これはチームがスケールした時に同一の教育ができやすい、リモートでも可能ではと考えて作成しました。
また、翻訳者に媒体の機能を教えることで翻訳のスピードと質が上がりました。 そしてわからない機能が出てきた時に、翻訳者がベトナム語でエンジニアに説明することがベトナムのチームだけでできるようになりました。(もちろん正常系だけですが)
新ワークフロー
教育カリキュラム(特にDBは鬼門でした)
振り返り(第2期)
PHPのチームでは継続を行わないことになりました。
日本側の運用負荷が大きいことが原因でした。
私としては教育の部分もワークフローも依頼タスクも負荷がかからない形をもっと試せただろうと思っています。 一言で言ってしまうと完全に準備不足だったと感じています。
Ruby on RailsとJavaのチームは第3期真っ只中です。(落ち着いたタイミングでブログを書いて書いてくれるはずです)
感じたこと
オフショアのコストメリット
せめて3人日かかるようなタスクから依頼すると良いと思います。 またはゴールがわかっているようなタスクです。
- フレームワークの切り替え
- API書き直し
- ユニットテスト作成
- WEBページリニューアル
一方、ブリッジを立てて現地のリードエンジニアと連携して仕事を進めていく形も良いと思っています。
どちらにしろ品質を担保しなければならないので、それがベトナムのチームだけで完結できるようにしなければなりません。
仕様や日本側の仕事の作法がわかったリードエンジニアを早期に育成する方法をを考えなければならないと思いました。そのエンジニアがチームを見る形にできれば日本側の負荷は軽減できるのではないかと思います。
リモートチームと日本チームの連携
目に見えている部分でないところで起こっている出来事なので、ベトナム組と日本組での認識の差が大きかったです。 それは要件認識の部分もそうですし、タスクで問題が起こった時などにも言えます。 日本側から意識してベトナム側で起きていることを見ない限りは、気づけないことが多くあると感じています。
日本ではMTGなどで離席することが多い環境であったりするので、サポートが遅れたりすることでベトナムチームはストレスを抱えていました。逆に日本側はコードの品質や要件理解の部分でストレスを抱えていました。
今までは画面を指差しながら私に説明してくれていたので、それができないと問題解決もスムーズにできません。
Skypeなどの画面共有などで問題を認識できる、言語の壁をうまく乗り越える工夫(通訳者など)をすると良いと思いました。
ベトナム人エンジニアとの信頼関係
ベトナム人エンジニアの離職率はとても高いです。
彼らにメリットを感じてもらいながらどのようにして長く働いてもらえるのかということを考えました。 現地に赴任して一緒に仕事をするというのは、この点においてかなり大きいようでした。
今回のプロジェクト停止の際にも、私と一緒に働いていたエンジニア2人がかなりの長文メールを送ってくれました。 半年で得られた一番大きなものはこの厚い信頼関係だったのかもしれないと思っています。
まとめ
現地に赴任して働ける機会は滅多にないことなので、とても良い経験になりました。 しかし、プロジェクトはうまくいかなかったので来年再開できた際には今回の反省を活かして取り組めればと思っています。
ベトナムのアプリチームとサーバーサイドチームと一緒に(第2期の終わりに)
おまけ
現地でのことはこちらにもちょっとだけ載っています
GMOメディアブログ http://gmomedia.tumblr.com/tagged/%E3%83%99%E3%83%88%E3%83%8A%E3%83%A0
