オフショアの開発リソース管理を半年間やってみて分かったオフショア開発のアンチパターンとその対処法

私が今所属している新規事業の部署で、日本の開発会社経由でベトナム人メンバー（開発エンジニア2名、QAエンジニア1名）に働いてもらっているのだけれど、私が転職してジョインした頃は随分といい加減な管理をしていて、成果物のクオリティも非常に残念な感じになっていたので、昨年の12月頃から私がチケット起票からコードレビューまでほぼ一人で担当する体制でテコ入れをすることになった。色々と苦労しつつ、今では一定以上のクオリティで効率良く開発できるところまで改善することができたので、オフショア開発の典型的なアンチパターンと思われる例や、オフショア開発の向き不向きについて感じたことを書きたい。

オフショア開発のアンチパターン

最低限の働きができないメンバーを放置してしまう

オフショアの開発会社は、中堅レベルのエンジニアから、明らかにド素人なエンジニアまで、多様なスキル感のメンバーを抱えていて、各現場の温度感に合わせてメンバーのやりくりをしているようだ。そのため、機能していないメンバーがいる場合に開発会社にフィードバックを上げずに放置してしまうと、「この現場はエンジニアのスキルレベルを判断できない」とみなされて、メンバー交代でレベルの低いエンジニアで固められてしまうことになりかねない。明らかに働きが悪いメンバーがいる場合は、開発会社にフィードバックしてメンバー交代してもらう必要があるだろう。

では、具体的にどのような基準で判断するかと言うと、下記の基準はすべて満たしていることが望ましいと感じている。

• 開発要件の不明点について自発的に質問ができる
• テストコードが書ける
• 開発環境で動作確認ができる
• 既存処理への影響について自発的に調査して対応できる
• 露骨にサボったりしない程度には勤勉な性格をしている

以下、各観点の詳細について書く。

開発要件の不明点について自発的に質問ができる

これは「報・連・相」ができるということで、オフショア開発に限らない社会人の基本スキルだ。これがどの程度適切にできるかで、仕事の精度と効率が大きく変わってくる。逆に言うと、一切自発的なコミュニケーションを行わないタイプのメンバーとまともに仕事をするのは難しい。

テストコードが書ける

日本語プロダクトのビジネス上の性質を共有しづらいオフショア開発では、テストコードをちゃんと書くことの重要性がより高まる。テストコードを書く開発が習慣化していて、特に指示しなくてもテストコードを書いてくれるメンバーが望ましい。逆に言うと、テストコードを書きやすい開発環境が準備されていたり、既存テストコードが充実しているかどうか、というのは受け容れ側のメンバーがちゃんとやっておくべきことになるだろう。

開発環境で動作確認ができる

開発環境でアプリを動かして動作確認するのはやはりやってもらいたい。私の場合は、GitHubのPRのテンプレートに動作確認用のセクションを設けてそこに書いてもらうようにした。当初やってくれない場合でも、何度かお願いすると自発的にやってくれるようになることもあった。

既存処理への影響について自発的に調査して対応できる

例えばあるメソッドを削除した場合の既存の影響範囲などを、チケット起票とコードレビューですべてカバーするには工数がかかるので、そういった部分については自発的に調査して対応してくれると助かる。

露骨にサボったりしない程度には勤勉な性格をしている

明らかにテキトーに遊んでいるとしか思えないアウトプット量で稼働するメンバーが割とよくいたりするので、勤勉な性格かどうかも重要な気がする。

チケット起票、コードレビューの精度が悪い

上に述べた観点でちゃんと働いてくれるメンバーが揃った上で、チケット起票、コードレビューは実装の知識があるメンバーが精度高く行う必要がある。機能要件レベルでフワッと渡していい感じに開発するには、プログラムの設計能力とプロダクトへの高度な理解が両方必要で、日本語のプロダクトについてオフショアのメンバーにそれを求めるのは難しい。設計、コードレビューがいい加減な状態でオフショア開発すると、コードの信頼性と可読性とメンテナンス性が恐ろしいスピードで悪化し、目もあてられない悲惨な状態のプロダクトがあっという間に出来上がってしまう。

精度の高いチケット起票、コードレビューについて具体的に言うと、チケット起票では、実装方針がクリアに理解でき、判断に迷うような設定値や命名について具体的に記載されているような内容になっていると、手戻りが少なくなる。コードレビューでは一行ずつ見落としなく読み、自分が書いた場合と同程度の品質になるまで、細かく指摘して変更してもらう必要がある。

コミュニケーションをサポートするメンバーの契約をしない場合は、これらのことを直接英語でやりとりする必要がある点にも注意が必要だ。

経営的な観点で言うと、設計やコードレビューができるメンバーの工数を大きくオフショア開発リソースの管理に割くということになるので、全体のバランスを考えたときに本当にオフショア開発の費用対効果が優れているのかは良く考えるべきだろう。

オフショア開発に向いていること、向いていないこと

以上のような観点もあり、オフショア開発に向いている開発とそうでない開発は明確に分かれると感じている。向いている開発としては、仕様が明確な機能開発や、コードの各種リファクタリング、ライブラリのアップデートなどがあり、向いていない開発としては、プロダクトに関する高度な理解が求められる開発や、機能要件だけ渡して設計からやって貰うような開発だ。なので、一人いると助かるけれど、大規模に活用する場合はデメリットも色々と大きくなると感じている。