オフショア開発を日本サポート無しでやってみた話

こんにちは、またしても思い出話シリーズです。
下記の記事でも少しだけ触れていますが、オフショア開発でやりたい放題やっていた事案のひとつを紹介します。

ハイライト

・当時のオフショアスキームの課題感
・Tryしてみたこと
・Finding

当時のオフショアスキームでの課題感

諸々課題感はあったスキームでしたが、今回はリソース効率にフィーチャーした話になります。オフショア開発を活用した上でエンハンスサイクル（月に1回リリース）を回していくと、ある「ムダ」が発生します。

日本サイドが企画検討、基本設計している間のオフショア先のベトナムの待ちのムダです。一応ムダが最小限になるように設計するものの、1日・2日遅れるのは日常茶飯事でした。ベトナムサイドでは100人体制で張っている中、1日遅れると100人日開く！！

実際マネジメント観点で言うとこのリスクも含めてコストが安いからまあいっか、で済んじゃうんですが、現場リーダーとしては何だかとてももったいない！その枠で何かできそうじゃない！？

ということで、その「ムダ」とされているリソース枠でベトナムメンバーだけで企画、開発するというスキームをトライしてみました。

Tryしてみたこと

そんな複雑なことはしていないのですが、要件選定の際に優先順位の観点で漏れた要件を１つごそっとベトナムサイドに手渡しました。目的と最終的に実現したいことを伝えて、あとはリーダーとスケジュールと課題だけやりとりしていました。

事業要望（JP事業）→基本設計（VN）→開発（VN）→試験（VN）→受け入れ試験（JP事業）→追加要望起案（JP事業）→開発（VN）

イメージは上記のような感じでした。
要は、要望だけ伝えて、成果物までつくってもらい、その成果物を動かしてみてダメだったら追加要望をだす、を完成するまで繰り返す！
って感じです。これをベトナムの空いた枠の中で実施し、もともと予定していた開発総量は完成させたうえで追加で実現！結果、生産性もUpって寸法です。

Finding

何案件かで実施して、うまくいくもの・いかないものはある程度整理できました。

うまくいくもの

・他のFeatureとCode上の依存関係がないもの
・リリース日に制約がないもの
・類似機能がある、などイメージがすり合わせやすいもの

うまくいかないもの

・上記の逆（密結合、リリース日制約あり、イメージ伝えづらい）
・UI/UX、デザインにこだわりが必要なもの
・こちらの文化をある程度把握できるメンバがアサインできない体制

といった形でした。Agileに近いような考え方なのでリリース日制約はおけませんでした。それにひきづられ、デリバリマネジメントが難しくならないように独立したCodeであることが結構重要でした。あとはなんだかんだで人依存はあったので、このスキームを実施することを許可する認定制度みたいなものも取り入れてました。

なにより、この取り組みはベトナムメンバーが超乗り気でトライしてくれたのが印象的です。オフショア先としてはかなり安定してきた国家だと思うので新しいことに興味を持っているんだと思います。