オフショア開発はBrSEに応じて日本側PjMの業務を変えた方が良さそうな話と対策

こんにちは、りゅうじです。

オフショア開発として複数の海外企業とプロジェクト協業してきて少しずつですが知見が貯まってきました。規模感としては今年はモバイルアプリ率が多めなので中規模くらいの案件対応のPjM、場合によってはPdM対応やBizDevのようなことも柔軟にしています。受託でオフショア開発を行う体制図としてはおおよそ以下のような形態が多いです。今回はここのお話をしていきます。

この体制図の前提について少し説明しておきます。

受注組織は1企業として契約をとります。その際の契約窓口を発注元が対応する形で、契約スタートしてからのプロジェクトのマネジメントは弊社が一括して発注元パートナーのオフショアチームとやりとりして進めていきますので、発注元は基本的にプロジェクト内部への干渉はしない形です。オフショアチームとのやりとりは私とBrSEのみのやりとりが進んでいく形になります。決裁のかかる内容や個々の契約にかかる質疑については発注元と個々がChatWorkなどで話をするようにしています。

運用自体は先日説明していた記事（ https://dev-pm.io/ryuji/items/990/ ）中で紹介していましたJiraを活用しているのですが、ビデオ会議はなくて全てJira基準で話し合いやタスクのスケジュール、品質などの管理全般を弊社が対応していきます。図解や表計算が必要な場合はfigmaやスプレッドシートを適時使う形です。スプレッドシートは成果物としてドキュメントやAPI、DB設計をシートで作る程度の運用です。

これを踏まえてケースごとにプロジェクトを分けてオフショアチームとの関係性はどういう対応が良かったのか振り返りをしながら考察をしていきます。

ケース1：オフショアBrSEは日本側PjMからの指示通りに開発チームへ伝え、実装する

BrSE=翻訳者 のケースであると言えます。

BrSEは基本的に技術的なことは理解しておらず開発チームに直接連絡をする形なので日本側PjMがビジネスロジックの設計（ユースケース、状態遷移図など）はもちろん、アーキテクチャ設計などの技術要件まで精微な指定をしておかないと開発スタート直後から齟齬を連発して泣きを見ます。

この場合は日本側が相当な負荷を引き受けないといけなくなりがちなので、上流工程だけ対応しますだけだと失敗しやすいです。設計などはもちろんですが日本側でもシステム開発に知見のある人が舵取りをすることでようやくバランスをとることができます。

予算の動きとして見ると要件定義から設計までのコストが高騰しがちなのでモバイルアプリなどの開発規模ですと赤字になりやすいかもしれません。活用シーンとしては小規模のWebサイトだったり既存サービスのリプレイス案件で請負契約だと円滑に進みやすい編成でした。

ケース2：オフショアBrSEは日本側の要件定義を元にシステム設計から対応できる

BrSE=設計者 のケースであると言えます。

BrSEはシステム設計領域までは理解しているのでエンジニアリングにかかる内容である程度は技術的な話が対応できます。この場合はケース1との違いとして、ユースケース説明をするときに箇条書きで機能の挙動を説明すると開発チームに理解した上で伝達してくれます。

この場合は日本側では主にビジネスモデルの概念検証、矛盾の精査などを対応することが多かったように思います。オフショアから上がってきた内容について整合性を確認するところから日本側は対応すれば良くて、ケース１よりはだいぶ日本側の負担が軽減されている状態です。

予算の動きとして考えるとオフショアとの契約のうち月の固定額で柔軟に対応してもらえる「ラボ型」契約になるのがこの辺りの編成であることが多いです。オフショアチーム内で設計、実装、テストを自走できる環境のためシステム開発は完結しやすくなりますのでクライアントの要求に答える点に日本側が集中できます。

しかし、オフショア活用では「日本の良いようにお任せで文化は通用しない」問題がコミュニケーション全般に起こります。特に要件定義については日本独特の商習慣などへの対応がオフショア側では難しいため、日本側でユースケース図や機能リストアップはしっかり精査、伝達するようにしなければなりませんでした。

そしてテスターが存在しない体制が多かったのもこのケースの特徴で多かったです。実際に操作して問題なければタスク解決。といったものですのでプロトタイプ開発には良いかもしれませんが、リリース版に作り込む段階でテコ入れしようものなら普通に作るより苦労しました。

一般的にはケース２のオフショア体制が多いように思いますが、コストを安くしたいのが選定優先の高めにきているとトラブルになりがちです。日本側でしっかりビジネスとシステム開発の両方知見がある人をマネージャーとしておくのが成功のポイントかなと感じました。←今私が担当することが多いのはこのラインです。

ケース3：オフショアがPM業務やってくれる

BrSE=プロジェクトマネージャー のケースであると言えます。

ここまでくると日本側での役割はビジネス寄りの検証にリソースを集約できるのでオフショア本来のコストと規模感のバランスがとりやすくなってくると考えます。ただ、肌感覚でいうとBrSEができます！と言っているケースでも蓋を開くとできていないことの方が多かったです。

対策としてはバージョンアップの管理を日本側で徹底させた方がいいのかなと感じます。コードならGit、インフラならTerraform導入、DB設計はスプレッドシートで編集履歴が残るようにするなどの体制づくりをオフショア側で対応できたケースはトラブル軽減できていたように思います。コードレビューもBrSE側で対応してくれるといっても日本側で品質管理する際にコードを見に行ったりはするので、その際にGitflowの作法でバージョン管理されていると問題の抽出も格段に向上したことがあります。

デメリットとしてここまでやっても予算バランス面で考えると国内でリソース調達した方が同額でクオリティ高くまとまる結果になりやすい編成になりがちでした。

ケース4：オフショアがビジネスロジックを理解してくれる本当の丸投げ感

BrSE=SIer のケースであると言えます。

BrSE側に日本人のPdMがいる場合に成立するパターンかと思いますが、オフショア開発との仕事をしていてこのケースに当たったことは実はまだありません。

理由を考えてみたのですが、これをやるということは自社は営業のみになってしまうので開発経験が全く積み上がりません。純粋なエージェントとかであれば良いのかもしれませんが、そもそもこの構成をやるのであればプロジェクトのマネジメント業務は会社の看板から下ろした方が良さそうです。

オフショアに開発の全てを移譲したいというのであれば現地マネージャーに日本人をおいて取りまとめてくれている企業を探す。という流れになるのですが、予算バランスで考えるとどうしても高額になりやすいです。結果としてオフショアのメリットをクライアントが感じにくくなっている現状を多くみてきました。

まとめ：オフショア開発における体制改善をするには

実際の相談で相場感としては300万以内でリリースに最低限耐えうるプロトタイプ開発をオフショアで。案件は多いです。その代わり上手くいかなかったから修正してほしいという要件までがセットでご相談いただくことも増えてきました。

お話を聞いているとオフショアとクライアントの間にいる企業や個人がシステム or ビジネスのどちらからに偏りすぎているパターンが上手くいっていないような状況が多かったです。一般的なキャリアとしてはエンジニア→プロジェクトマネージャーと進みますのでシステム開発に寄るのは仕方ない側面はあります。しかしクライアントが実現したい内容に対してのリサーチだったり経験があった方がより実現への精度は高まります。また逆も同様にあります。

っとここまでオフショア開発との関係性について書いてきましたが、継続成長させるために推奨できる体制図の要になるのは「日本側のPdMとPjMスリム化」だと感じることが増えてきました。営業がPdMを担当して開発体制の管理をPjMに一任する2名体制になるとクライアントとの交渉だったり意思疎通に齟齬が生まれやすく契約も窮屈なものになりがちです。

これまではPdMとPjMは自社開発でない限り分けないと利益相反になるから無意味だ。と方々で前提条件にされてきました。私は今後の開発様式においてはそうは思っていなくて、先ほどの事例のようにクライアント側のコスト圧縮とクオリティの両立を求められる傾向がどんどん増えると思います。

弊社の取り組みとしてはいつも言ってる感がありますが「子育て世代のパパままさん向けマネジメント教育」を重点的に進めています。子育てと開発マネジメントはとても似ていて適応もしやすいためスッと経験が積みやすい構造になっています。

技術的なことが理解できないとプロジェクトのマネジメントなんてできない。という声が多いのですが実際はそうでもなくて適切なフローを積んでいけばマネジメントの概要は経験の有無が影響せずとも習得可能です。教育素材としてはまだまだ作っている最中ですが実地成果など公開できることが増えてきたらここでも共有していければなと思います。