はじめに
この記事は、まだ社会人２年目のヒヨッコが半年程度の経験を基に書いた記事です。主観が多く含まれます。間違ったことも書いているかも知れませんが、ご了承の上でお読みください（明らかに間違ってるぞ的なのはどんどん教えてください！）。
こんにちは。Dockerが好きな２年目のWebエンジニア のとんとです。
僕は入社してからQAチームに所属し、システムのバージョンアップ対応の一環として、挙動の違いをキャッチアップするべくプロダクトのテストコードを実装してカバレッジの向上を図っています。実はウチのQAチームは、部内では珍しく海外の会社と提携をして一緒に業務を進めています。場所はベトナムで、６人ほどのベトナムエンジニア の皆さんと一緒にテストコードを書いています。ちょっとカッコよく言うと「社内で数少ないオフショアを経験できるチーム」です笑
１年目からオフショアが出来る！！っていうことで嬉々としてチームに所属したのですが、エンジニア としての技術や知識もままならない状態でのオフショア経験はなかなか大変です。オフショアなんて周りでやってる人はなかなか居ないし、「こう言う時はどうすれば良いんだ…」と悩んだ時にコレだと言える指標がありません。
約半年強経験してきたことの棚卸しも兼ねて、今後同じような経験をされる方に向けた指標を残したい。そういう想いでこの記事を書きたいと思います。
0. オフショア開発とは？
そもそもオフショア開発ってなんぞや？？？という部分を説明します。
オフショアとは、ざっくり一言で表すと自社で抱えている業務の一部を海外の企業に依頼することです。主にWebシステムやアプリ開発などに多い印象があります。現に、私の携わっているチームもWebアプリシステムなので、やはりこの手の分野は作業の切り分けがしやすいのでしょうか。
海外の企業に依頼をするメリットとしては、日本よりも１人あたりの人件費を抑えることが出来るからです。
また、ベトナムやタイなどの国ではエンジニア のスキルがここ最近で向上しており、日本国内のみで人材を探すよりも幅広い選択肢を確保することが出来るのもオフショアのメリットです。
オフショア先の国としては、中国・インド・タイ・ベトナムと様々な国に進出しています。オフショアとして業務を委託された海外エンジニア もスキルを磨いてWin-Winな関係になれるような気がしますね！
1. 仕事を円滑に進めるために心がけたこと
1-1. タスクの目的・ゴール・期日をはっきりと伝える
これはエンジニア とか社内社外に関わらず大切だと思いますが、オフショアでは特に大事になってきます。
普段社内の人と仕事をしている時は、（毎日在宅とかしていない限り）基本的にいつでも話せる距離にいるので「今いただいてるタスクについてなんですけど…」とか「早く終わったので他にタスクないですか？」とか「環境がうまく立ち上がらないんですけど見てもらえますか？」と、相手の進捗を容易に確認できます。
しかし、オフショアになると相手は海の向こう。気軽に"ねぇねぇ"と話しかけることが難しい状況です。普段のやり取りは基本チャットと、ビデオ通話を介した定例のMTGくらいで、ほぼ9割がチャットでのやり取りです。文字ベースのやり取りって結構疲れますし、何より相手の感情が読み取れません。ベトナムの方と仕事をしていますが、そんなベトナム語が喋れるわけではないので、拙い英語で一生懸命内部実装の話とかします。「ビデオチャットでええやん」と思われるかも知れませんが、頻繁にビデオ通話するのってすごく面倒だし、何より気を遣いますw そのため、向こうの進捗や躓いている箇所を常に把握することは難しいです。
その結果として、日本側で想定していた進捗率と海外チームの実際の進捗率に乖離が生まれることが多いです。また、オフショアでやってもらう業務は、こちら側が与えた業務をこなすことが9割です。そのため、タスクを与えられた側からすれば、「このタスクは何の役に立つのだろう」と考えることでしょう。その上、タスクの説明などが不十分だとどこまで一生懸命このタスクに打ち込めば良いかが分からなくなります。そうすると、タスクの品質にも進捗にも認識の乖離が生まれてしまします。
これを防ぐために、タスクの目的・ゴール・期日をはっきりと伝えてから海外チームに依頼をする必要があります。
例えば、「CIのメモリエラーについて調査する」というタスクがあった場合
こんにちは。現在XXブランチのCIが落ちています。どうやらメモリエラーが原因のようですが、CIのログを調査してメモリ使用量の推移を調査し、原因となっているテストケースを特定していただけますか？このエラーを解消しないと、今後CIでの検証が出来なくなってしまうので、来週の月曜日までで一度調査をしてもらえませんか？
タスクの目的はXXブランチでのCIが止まってしまうのを防ぐため、ゴールはログからメモリエラーの原因となっているテストケースを特定すること、期日は来週の月曜日まで、となります。
1-2. 国民性も考えたタスク依頼のタイミングと量
タスクの詳細を伝えるのが大事だという話でしたが、伝え方やタイミング、一度に与えるタスクの量などもオフショアでは大事になってきます。
これは国民性によるものだと考えています。超主観ですが、日本人は仕事を与えられた時、「最後までしっかりやらなければ…」「向こうが期待する以上の成果を出さなければ…」と、とても強い使命感を持って真面目に仕事に取り組む姿勢がよく見られます。しかし、他の国ではこの考えは全く異なってきます。僕が一緒に仕事をしているベトナムの方は、日本人に比べて気さくでのんびり、でも我慢強く真面目であるという一面を持っています。
他の国の方はどうかは分かりませんが、日本人と同じ国民性を持った国はそうありません。当然、仕事に対する姿勢も違ってくるので僕らと同じように仕事をこなしてくれるだろうと考えるとハマります。
タスクの期日を過ぎてしまうこともあります。タスクの本質をうまく伝えられないこともあります。そんな時でも、なるべく自我を出さずにうまくタスクの完了に持っていけるかがオフショアでは大事になってきます。
文化の違う人たちが、お互いを尊重することは仕事以外でも必要なことです。
1-3. 向こうのメンバーの能力を出来るだけ把握する
国民性もそうですが、全員が全員その国の国民性に当てはまるわけではありません。少数人のチームでもメンバーそれぞれの個性が光ります。
集中力がすごくある人、単調な作業になるとものすごく速い人、コードのロジックを考えるのが得意な人、リーダー気質でチームの指揮官にぴったりな人、モチベがあまり無いけどとりあえずコードを書く人、もう全部込み込みですごい人など様々です。メンバーの個性に合ったタスクを与えることで、与えられた側もモチベーションを保つことが出来ます。その人のレベル感に合わない仕事を与えると、モチベーションの低下から退職やチーム全体の士気の低下に繋がります。そうなると、せっかくお金をかけて海外にまで目を向けてメンバーを増やしているにも関わらず、生産性が向上しなかったりと結果に繋がらず、仕事を与える側も与えられる側も苦しい時間を過ごしてしまいます。
1-4. 一度だけでも良いから現地に行く
とは言うものの、画面の向こうにいる人たちの性格や能力を把握するのはかなり難しいです。
そこで僕らのチームは、年１回ほど現地に出張に行っています。最初はお互いの顔合わせなど、仕事をしに行くというよりもボードゲームや一緒に市内を廻ったりと、チームビルディングを通してお互いの心理的安全性を高めることを目的としていました。慣れてくると、現地で一緒にテストを書いてみたり、プチハッカソンをしてみたりと、一緒な空間で作業をすることで、お互いの能力や癖が分かるようになります。
その結果、メンバーそれぞれの能力に合った仕事を与えられるようになり、チームとしての力を最大限に発揮して業務に臨ことが出来るようになりました。
2. ゴールはお互いの自走
長期的なプロジェクトにもなると、1ヶ月や３ヶ月、あるいは半年かけるような大きなタスク（CIの並行実行を実現するとか、あるディレクトリ配下のファイルのテストカバレッジを80%以上にするとか）が並行して進みます。タスクを依頼する側としては、１つのまとまった大きなタスクをオフショア先にやってもらうのが効率が良いと思います。出来れば、もくもくと出来る大きなタスクが理想ですね。タスクを投げるに当たって、タスクの目的とゴールと期日を教えますが、タスクを遂行している数ヶ月間にもサポートが必要です。タスクをこなしていく上で分からないことや問題点が次々と浮かび上がります。（Docコメントとか多くは日本語で書かれていることが多いので、プロダクトコードの理解に苦しむ場面も多くみられます。）
大抵は依頼する側がコードのロジックや作業の流れを把握しているので随時海外チームから質問や確認が飛んできます。
問題なのは、質問の回数が多いほどこちら側の対応時間が増え、稼働率が下がってしまうことです。仕方ないとは言え、ロジックを持つ側としては極力稼働率を落とさずに作業を遂行する必要があります。
ここで、なるべく質問の対応を迅速に終わらせようとするだけではなく、質問の頻度を減らせるよう海外チームの自走力を高めることを試みます。
例えば、チームメンバーそれぞれが質問を飛ばすのではなく、オフショア先のチームに１人リーダー役を立て、一度リーダーに質問をして、答えられる範囲のものはリーダーで対処してもらい、どうしても日本チームに聞かないと難しい問題のみを投げかけてもらうように体制を整える。お互いのチームのパイプラインを１つに絞ることで、日本側の負担が減るだけでなく、オフショア先の組織力が上がります。「オフショア先のマネジメント事情まで日本側で考える必要はない」と考える方もいらっしゃると思いますが、私の経験上では３ヶ月程度の長期的なタスクを任せる時はこちら側で体制を整えてあげたほうが楽ですし、オフショア先に良しなにやってもらおうとする考えは業務を依頼する側として良くないです。
3. オフショアは楽しいぞ！
オフショア開発は、自身の技術力とマネジメント力の両方をバランスよく磨けるとても良い機会です。
海外の人と仕事をすることで、日本人にはない独特な感性に触れて視野を広げられますし、マイナスなことは無いと思います。もちろん、上手くいかずにマイナスになりかける時もありますが、オフショア先のことを一生懸命に考え、自ら歩み寄ろうとする意思があればプロジェクトの成功に大きな貢献をしてくれます。
まだまだオフショアの機会はそう多くはないかも知れませんが、もし機会が巡ってきたときは、一度やってみることをお勧めします。（何より、オフショアを経験していること自体に誇りを持てますw）
ではまたヾ(๑╹◡╹)ﾉ”