【オフショア開発】は良いか悪いか、末端エンジニア視点で考察する

2021年9月現在、弊社ではインドのシステム開発会社に対し業務委託をしている。
現在私はエンジニアリングマネージャーでもなく、プロダクトオーナーでもなく、単なる1プレイヤーなのだが、
弊社（自分の所属してきたグループや部）のオフショア開発の体制などに対していろいろ思うことがあるので、
私の完全個人的考えをもとに記事にすることにした。

チームメンバーや後輩、部下には「そういう考えを持っているのね」と理解してもらえるように、
それ以外の方には「興味深い」「そういうやり方いいね」「それだめだね」など、
いろいろな感想を持ってもらえるように意識したつもりである。

※注意
あくまでここに書くことはプレイヤーとしての私の個人的意見であり、
マネジメント視点では異なるかもしれないし、
押しつけや、べき論を強要するものではありません。


#オフショア開発とは

オフショア開発とは、主に開発業務を海外事業者や海外子会社に業務委託、発注することを言う。
弊社のプロダクト開発であれば、
「XXXXサブシステムの〇〇の部分は依頼しよう」
「YYYYサブシステムの▲▲▲のバグは依頼しよう」
のような感じになる。

参考

https://e-words.jp/w/%E3%82%AA%E3%83%95%E3%82%B7%E3%83%A7%E3%82%A2%E9%96%8B%E7%99%BA.html


#一般的なオフショア開発のメリット（経営、ビジネス的側面から）

オフショア開発をする上でのメリットはやはり以下の３つだろうと考えている。

- 国内のエンジニアのリソース不足を補える
- 海外の優秀なエンジニアを安価に利用できる
- フリーランスに委託するより統率が取りやすい（はず）


####国内のエンジニアのリソース不足を補える
1つ目については言うまでもなく、
WantedlyやLinkedIn、cloudworksのような求人系のサイトでもITエンジニアの募集が多く、
日本国内のITエンジニア需要が高いことは容易に理解できる。
例に漏れず、弊社も国内エンジニアリソースはプロダクト、ユーザー数の規模からすると、
圧倒的に足りていないと認識している。

ここで「未経験採用」「新卒採用」をやろうとしても
教育コストが膨大にかかり、タイムラグも発生する。
「経験者の中途採用」はそもそもリソース不足を劇的に解消する手段にはなりにくい。

このような人的リソースの穴埋めの目的でやっている場合も多いと思う。

####海外の優秀なエンジニアを安価に利用できる

最近だとインドや東南アジアなどでは、
大学でコンピューターサイエンスを学んだ技術力の高いエンジニアが多い（といわれている）。
彼らは日本国内よりも単価が低いにもかかわらず、
技術力は高い（といわれている）。
※正確には「単価のわりに能力が高い」が正確かも。

未経験者や新卒を自社の中程度レベルのエンジニアと同等まで育てるのにかかるコストを鑑みたら、
すでに能力を持っているエンジニア集団に、お作法（開発手法、出荷プロセス、etc）を教えるだけで済むので、
教育コストの観点では結構抑えられる。


####フリーランスに委託するより統率が取りやすい（はず）

個人事業主に対して、業務委託する場合は足りない人数を確保するためそもそもコストが高い。
個別にアプローチしたり、リファラルでやったりetc

海外のシステムインテグレーション系の法人に対し「お宅の開発集団うちに貸してください」のようにやると、
契約さえできれば数10～数100名規模のエンジニアが一気に確保できる。

そのうえ、一度確保したら、組織としての指揮命令系統がすでに存在しているので
マネジメント層を動かせば、全体が動くという感じで、
フリーランスいっぱい確保に比べ統率は取りやすいだろうと考えられる。



#プレイヤーから見たオフショア開発

ここまで経営的、ビジネス的に考えられるメリットを記載してきたが、
私が一番言いたいことはここからである。

オフショア開発は、
エンジニアとしての**成長**という観点では
デメリットを被ることが大きいと考えている。

その理由は**機会損失**になっている場合が多いという点である。

####弊社のオフショア開発

弊社では前出のとおり、インドの法人に対して、開発業務の一部を委託している。
形式としては以下のとおり。

- 部に対しリソースが割り当てられている
- （私の所属では）部以下のグループに対し数人の開発者リソースが割り当てられており使い方もグループに裁量がある
- 委託できる業務は、開発、各所からの問い合わせ調査、などプロダクト開発が担っている業務ほぼすべて

※プロダクト全体として対応しなければならない、人海戦術的なプロジェクトの場合はこの限りではない

もう少し具体化します。

####例1）開発案件（不具合修正）

- 担当マネージャー（または担当エンジニア）はバッグログから、依頼案件を決め、グループのカウンターパートのリーダーに共有
- インド側で担当者をアサインし、開発を開始
- 開発が終わると、プルリクとドキュメントが来る（原因、影響範囲調査結果、テストケースetc）※Webミーティングしているチームもある
- 担当マネージャー（または担当エンジニア）は内容を確認し、問題なければAccept
- インド側の担当者（評価者含む）は評価環境にDeployされたモジュールを評価
- Testedのステータスになったら、担当マネージャー（または担当エンジニア）はバッグログのチケットをクローズ

####例2）問い合わせ（製品に関するトラブルや疑問がプロダクト開発まで上がってくる）

- 担当マネージャー（または担当エンジニア）は問い合わせ内容を、カウンターパートのリーダーに共有
- インド側で担当者をアサインし、調査を開始
- 調査が終わると、調査結果のドキュメントが来る
- 担当エンジニアは内容を確認し、適切な内容を返答

####私が考える問題点

前出の通り、かなりの範囲の業務をグループ（または末端の担当エンジニア）の裁量で委託できる仕組みとなっている。
また、人件費は日本人エンジニアの2分の1とか3分の1とか言われている（事実は知らない）。

しかしよく見てもらえればわかるが、
インドに委託した場合、原則担当のエンジニアは、

- コードを書かない
- 自力でコードリーディングしない※
- デバッグしない

のである。

※プルリクはチェックするが大体レビューできるマネージャーやシニアエンジニアがチェックしている。

ここに**エンジニアの成長**の観点において最も重要な

- コードを読む
- コードを書く
- デバッグする

という要素が、仕事の中から消えているという点に、個人的に問題があると考えている。

シニアエンジニアが、
「こんなの俺がやっても経験値上がらないし」ってやつを依頼して、
プルリクもレビューして、とかやるなら、非常に有効な場合もある。
実際自分でやったら20時間～30時間かかるようなものが、1～2時間で済むようなことも経験上ある。


しかし、成長過程で、知識も増やしていかないといけない段階のジュニアエンジニアがこれをやってしまっては、成長機会を完全に損失している。

私は、「実力は実践でのみ身につく」と考えていて、
インドにリソースがあるからといって、
**「とりあえずめんどくさそうだから」**
とか
**「今忙しいから」**
という理由だけで、すぐさま外注してしまうのは、
教育の放棄、成長機会の放棄、役割の放棄ではないかと考えている。

そして何より自分（担当エンジニア）のためにならない。


#問題解決

我々のミッションは「問題解決」である。
しかし自力で問題解決できないエンジニアが、永遠にこんなことやっていたら、ステップアップはできない。
少なくともエンジニアとしてキャリア形成を考えてるのであれば絶対やってはいけない。

そこで、私が考えるエンジニアの成長観点から考える適切なオフショア開発のあるべき姿は以下である。

- 裁量はグループにあっていいが、マネージャーにとどめる（各開発担当には与えない）
- 各プレイヤーに対しては、担当領域の依頼案件については、自分がやったものと同等の理解を要求する※
- できれば使わない。（またはエンジニアリングに明るいマネージャーが適切に判断する）

※「自分がやったものと同等の理解を要求する」とは、
自分が実際にコーディングした案件と同じ基準でレビューミーティングや説明を必須にするという意味である。

#最後に

私はマネージャーではないが、後輩が↑のような感じだと、結構危機感を覚えるので、
少なくとも近場では上のような使い方を禁止したほうがよいと考えている。

自分の担当領域の説明もできない、コードもろくに書けないとか、
もはやエンジニアではないし、
私がよく罵っている「伝書鳩コンサル」と同じである。

製品知識に明るく、コードもまともに書ける、エンジニアリングマネージャーが、
メンバーの成長機会を殺さない範囲で、適切に運用できるときのみ使えばいいし、
それができないのであれば、日本の未来のためにも、そのメンバーのためにも、極力使わないほうがいいはずである。