はじめに
僕の勤めている会社では、ベトナムの会社と連携してオフショア開発を行っています。
オフショア開発を経験されたことがある方は、一度は感じたことがあるかと思いますが、この開発体制は、うまいこと機能させることが本当に難しいです。
今回、オフショア開発で1つのプロジェクトが終了し、次のプロジェクトでより円滑に進めるために「やっててよかったなぁ」、「こうやったらもっと開発がうまくできそう！」って考えたことをまとめてみました。
開発に関わったメンバー
まず、今回オフショア開発で関わったメンバー構成に関してまとめます。
プロジェクトにアサインされているメンバーの役割と人数（例：システムエンジニア✕1）、それぞれの対応タスクを記載してます。
オフショア開発では、国の違いが大きく関係してくるので、カッコ書きで各メンバーの国籍も記載しておきます。
・システムエンジニア✕1 （日本）
仕様決め・システム設計を行い、ドキュメント化。結合テスト
ブリッジエンジニアとの仕様認識すり合わせ。クライアントとの要件定義、コードレビュー
・ブリッジエンジニア✕1 （ベトナム）
システムエンジニアの作成したドキュメントの翻訳。各質問（期日どうすか？や、機能一部修正などの簡単なやり取り）への応答。システムエンジニアとの仕様認識すり合わせ。各開発エンジニアとの仕様認識すり合わせ。
・iOSプログラマー✕3 (ベトナム)
ブリッジエンジニアと仕様認識すり合わせ。iOSアプリの開発。単体テスト、結合テスト。
・Androidプログラマー✕3 （ベトナム）
ブリッジエンジニアと仕様認識すり合わせ。Androidアプリの開発。単体テスト、結合テスト。
そもそもオフショア開発は何が問題になるのか
僕の考えるオフショア開発を進める上で起こる問題点を以下に記載します
・言語の壁。システムエンジニアと、プログラマーの母国語が異なること
システムエンジニアと、プログラマーの直接のやり取りが難しいです。
・ブリッジエンジニアに頼らないと、進まないタスクが多い
共通言語を話せる人に頼りがちになる傾向があります
・仕様がプログラマーに伝わるまでのフローが多くなる
ブリッジエンジニアを通すので、これはマストです
・文化の違い
そんなに問題になったことがないのですが、webとかではよく書かれている問題点ですね
これらの問題点をいかに改善していくかが、オフショア開発のポイントになります。
上記の問題点を基に、僕が改善するために行った内容を以下にまとめます。
その1：システムエンジニア（日本人）から直接プログラマーに指示が通らない様にする
オフショア開発で問題になリがちなものは、言語だと僕は考えています。
基本的に共通言語を用いて、ビジネスレベルで会話が成立しずらいメンバー同士は、コミュニケーションを取らないように徹底しました。
徹底させた理由としては、システムエンジニアとプログラマーの仕様に関する認識のずれを確実になくすためです。
これは本当に大事だと思っていて、しっかりとやっておかないと、大変な目にあいます。
一度経験したのが、システムエンジニアとプログラマーで直接英語でやり取りをして、お互い英語がそんなにできるわけではなかったので、英語の書き方・読み取り方にずれが生じ、結果的に機能に仕様漏れが発生し、結局ブリッジエンジニアに話をつけて、対応をやり直してもらったことがあります。ほんとうに今思えば無駄作業でした。。。（泣）
こういったことをなくすためにも、基本的にすべてのやり取りは、ブリッジエンジニアを通して行います。
ただ、もちろん弊害もある
このやり取りを徹底すると、毎回ブリッジエンジニアに翻訳してもらう作業が発生するので、コミュニケーションコストがどうしても嵩んでしまいます。
また、僕の抱えているプロジェクトの場合だと、プログラマーが総勢6名に対して、ブリッジエンジニアが1名だったので、ブリッジエンジニアの作業が膨大になりすぎるという問題が発生しました。
図にするとこんな感じです。
図の中心にいるブリッジエンジニアがすべての窓口になるので、大変になるのは火を見るより明らかですね。
それぞれのメンバーが、ブリッジエンジニアの翻訳待ちといった状況が発生し、対応に遅れがで始めたので、一部のやり取りだけ、システムエンジニア（日本人）とプログラマー（ベトナム人）で直接やり取りをしてもいいというルール緩和を行いました。
ルールの緩和と言っても、仕様共有などのレベルまでは行いません。
やったことは以下のような簡単なやり取りだけです。
・「プルリク投げたから確認して！」
・「最新バージョンをリリースしたので、開発環境のdevelopブランチも最新版にマージしといてね」
・「コードレビューしたよー。確認してね！」
例文を用意しておけば、誰でも使い回せるような内容だけに絞りました。
これくらい簡単なやり取りであれば、認識のズレが起きにくいし、少しですが、ブリッジエンジニアの負担を減らすことができます。
余談ですが、ブリッジエンジニアは、インフラエンジニアみたいに、いろんなプロジェクトに掛け持ちでアサインされがちなので、基本的に負荷が軽くなるように考えてあげることが重要になります。
その2：関わるプログラマーのスキルレベルをできるだけ把握しておく
まず、オフショア開発を実際にしている人達に質問をしたいです。
アサインしているプログラマーの名前を全員言えますか？
この質問に対して結構「知らない」と回答する方が多いのではないかなと僕は思っています。（僕も最初そうでした）
実は、オフショア開発を行うと、システムエンジニア（日本人）はプログラマーたちとやり取りを一切行わずして、開発ができてしまいます。
なので、システムエンジニアは、プログラマーのことを一切把握せずに（もしかしたら、何名アサインしていたかも知らないかもしれません）プロジェクトを終えることができるのです。
別にプログラマーのことを知る必要はないじゃんって思うかもしれませんが、僕は以下の理由からプログラマーのことを把握しておくことは、結構大事だと思っています。
プログラマーごとにスキルレベルが異なる
当たり前ですが、プログラマーごとに、スキルレベルは必ず異なります。
1つの機能対して、あるプログラマーが1日で実装できても、別のプログラマーが実装すれば3日かかることだってもちろんあります。（※語弊を招きたくないので説明しておくと、基本的にオフショアで開発しているプログラマーのスキルレベルは、皆高いです！）
スキルレベルの違いは、実装工数に影響が出るので、きちんと日本側でも誰がどのタスクにアサインしているか把握して人員調整をすべきだと思います。（多くの場合、そういった調整は、全てブリッジエンジニアが密かに処理してくれていることが多いです。しかし、前述したようにブリッジエンジニアの工数をむやみに増やすのは、結果的に開発に影響がでるので良くないはず）
また、プログラマーのスキルレベルを把握しておくと、実装が重い機能に対して、特定のプログラマーに実装を依頼することもできるようになるので、システムエンジニアとしてもありがたいはずですよね。
まぁ、どちらにせよ、一緒に開発を進めているメンバーに変わりないので、名前くらいは知っておきたいですね。。。
スキルレベルなんてどうやって把握するの？？
って思っている方も多いと思いますが、そこはブリッジエンジニアにいろいろ聞きましょう。
「このタスクを〇〇さんと〇〇さんだったら、どっちが実装早くおわりそうかな？」
とか
「〇〇さんってこれ使った実装に慣れてる？？」
とか、いろんなことに対して、この人アサインしたらどうなるのかを聞きまくりましょう。
ブリッジエンジニアは、プログラマーのスキルレベルを把握していて、ブリッジエンジニア判断で、アサインするメンバーを選んでることがあります。プログラマーの実装スキルに関しても、こちらからいろんなことを質問すれば、日本側もスキルレベルに関してなんとなく把握できるようになります。
その3：プログラマーの開発スケジュールを把握しておく
基本的にオフショア開発は、リモート開発と同じなので、当たり前ですが、プログラマーの作業している姿は見えません。
プログラマーが現在どの機能を実装しているか把握できない（もしくは、しない）まま開発を進めると、気づいたら、一人が何もやってないという状況が発生します。（ラボ開発のスタイルをとっていると、この状況はクライアントに怒られるので、良くないはずです）
開発メンバーが多いと、このような状況は発生しがちなので、リアルタイムでプログラマーが何を実装しているか分かる状況にしましょう。
僕のプロジェクトでは、trello(https://trello.com/) を使ってどのプログラマーがどの機能を実装しているのかわかるようにしておきました
具体的には、こんな感じです
「in Progress(進行中)」「Waiting(対応まち)」「Complete(完了)」というステータスを作成して、各エンジニアに、対応チケットを「in progress」に貼ってもらうようにしました（※チケットが日本語で記載されているので、実際にはブリッジエンジニアにステータスを変更してもらっていました）
看板形式で、可視化しておくことで、プログラマーの状況を日本側でも確認できるようになり、プログラマーの待ち状況をなくすことができました。
まとめ
・仕様などの重要なやり取りは、できるだけブリッジエンジニアを通す
・ブリッジエンジニアの負担が大きくなりがちなので、極力負担を減らす試みを導入するべき
・プログラマーのスキルレベルまで把握しておく
・看板形式にして各プログラマーのタスクを把握しておく
オフショア開発を行っているエンジニアさんにとって、少しでもアドバイスになれたら幸いです。
開発方法に正解はありません。僕も今後いろいろ試して、お互いが、よりやりやすい進め方を選んでいけたらと思います。