オフショア開発は速かった。だからこそ詰まった：3つの良さ・工夫・苦労・次に活かすポイント

法人ディベロップメント課のS.Sです。
マイナビBiz / LIVING の新規開発・保守運用を行なっております。

この記事では、現在、私が関わっている、とあるPJ で、Techtus さまとの協業（オフショア開発）により、PJ を進める中での経験や気づきについて、ご共有できればと思います。（※ PJ は、現在進行中です）

• オフショア開発事情について気になる
• オフショア開発の難しい点や良い点について知りたい
• 経験を踏まえて、次回オフショア開発を進めるならどうしたいか

という方には、お力添えになれる記事かと思います。

参照: Techtus とは

オフショア開発の3つの良さ

１、開発速度が本当に早い！

協業で開発を進めて頂いた Techtus さまの開発チームの開発速度は非常に早く、こちら側で元々想定していたスケジュールから、1ヶ月以上巻きで進めてもらうことができました。

今回、実装して頂いた開発者は、2名体制でしたが、2画面/日ペースでPR レビュー依頼が届き、レビューコメントへの対応も基本的に即時返信・対応で、滞りなくスムーズに進んだ印象でした。

２、にも書いていますが、技術的なレベルも高く、技術的な詰まりなども、ほぼなく進めて頂けたのも開発速度が早い理由なのかなと思っております。

２、開発チームの技術力が高い！

本PJでは、Next.js（v15） による開発を進めているのですが、新しい機能活用、技術/SEO提案などが、頻繁に飛び交いながら、PJ が進んでおります。

迅速に、依頼画面を作って頂くだけに止まらずに、積極的に技術的な付加価値を提供頂き、ともにブラッシュアップして開発を進めていけたのも非常に感謝でした。

３、言語の壁なく、素早く問題解決が進められるスムーズな連携！

オフショア開発をする、となった時に最初に思い浮かんだのが言語の壁でした。

しかし、Techtus さまでは、コミュニケーター（マイナビと Techtus エンジニア間で日本語 / ベトナム語 でやり取りしてくださる人）がいるため、言葉の壁を感じず、いつもの開発のように進めることができました。

また、コードレビュー時には、お互いに英語でのやり取りが可能でしたので、ここも言葉で悩むことなくスムーズに進められた印象でした。

私自身、英語力に関しては簡単な英語の読解ができるくらいのレベルで伝えることには不安がありましたが、今は Google 翻訳があるので、そんなツールも活用しつつ、特にストレスなく対応できました。

やり取りを進めていく内に自然と、Google 翻訳に頼る頻度は減っていくので、さらにスムーズになった印象でした。

（副次的なものですが、初見PRレビュータイミングでは、訳さずに読解することで、英語力が少し上がるのもよかったです。（次は、ベトナム語にもチャレンジしてみたいな。））

オフショア開発で工夫した3つの点

１、ファーストレスポンスを最速で行う

オフショア開発では、開発している場所・時間が物理的に違います。

そのため、お互いに相手方の状況が見えません。

したがって、分からない状態での「待ち」が相当なストレスを生み、開発パフォーマンスに悪影響を与えてしまいます。

なので、普段の開発よりも増して、ファーストレスポンス速度を早めるように意識しました。

これによって、お互いに、分からない状態での「待ち」を作らないことで、互いにノンストレスかつ、滞り少なくトントンと開発を進めることができたのかなと思います。

２、前提を含めた丁寧な説明

オフショア開発では、相手方は、初めて向き合うサービスであることがほとんどです。

自分たちが思っている当たり前や前提がほぼ 0 のため、なるべく丁寧に、前提説明をするように努めました。

開発を進める中での質問やレビュー時には、
「こうこう、こういう理由で、こんな実装してほしい」
などを具体的かつ論理的に伝えることで、納得感を持って開発を進めてもらえたのかなと思います。

※ ここは、工夫した点でも、あり改善余地ありの点でもあるので、そちらに記載します

３、視覚的情報（+数値）を用いた意思共有

言葉の壁はありませんでしたが、開発文化やニュアンス、表現、受け止め方の違いは、あったかなと感じました。

そんな違いを問題にしないために、視覚的情報を用いるように工夫しました。

この手法を用いることで、見たそのもの、そのままは、どこの誰が見ても基本的には同じように捉えることができます。

数字についても同様です。

なので、視覚的情報と、数値を用いることで、認識ズレを減らせたのかなと思います。

言葉のみの場合：

視覚的情報を用いた場合：

圧倒的に、後者の方がズレなく伝わることが体感できます。

オフショア開発で苦労した3つの点

１、仕様を認識ズレなく理解してもらうこと

先ほどの工夫の箇所でも書きましたが、前提や背景知識が違うので、こちら側の当たり前は、相手方の当たり前ではなかったです。

特に、開発初期は、レビュータイミングで、認識がズレていたり、こちら側で当たり前としてしまっていたことが、相手方の当たり前ではないことでやり直しが発生してしまうこともありました。

早めに気づいて改善することで軌道修正はできましたが、当初は苦労しました。

２、開発環境の共有

完全な自チームの場合であれば、AWSを含む各種アカウントの共有がなされている、かつ物理的に近い距離で開発ができ、環境共有に困ることは、ほぼありません。

しかし、オフショア開発の場合は、各種アカウントの全てではなく、必要なものかつ、共有できるものが限られる中で対応を進めていく必要がありました。

そのため、開発の進め始めに、あちらの local では動いているが、こちらの local では動かない、というようなタイミングがありました。（Github, Docker 利用をしていたのでベースの共有化はできてはいるものの。。）

３、開発手法や進め方の足並みを揃えること

当初、開発文化が異なるチーム同士で開発を進める中で、

• どんな手法を用いて
• どんな粒度で
• どんなルールでやっていくか

という所の認識合わせが困難でした。

事前に、キックオフ会の実施や、ドキュメントを作成して、足並みが揃うよう努めましたが、やはり、前提や背景、文化が違うもの同士で協業をするというのもあり、
「あ、この観点や考え方もドキュメントに追加しないとな」
というものがボロボロと出てきた印象がありました。

PJ を進める業務を行いつつ、こういった基礎の部分を同時修正していくことに苦労しました。（もっと早めの段階の問題出しが重要だなと）

ただし、ここを軌道修正したことで、様子見やすれ違い頻度も減り、スムーズにPJ が進むようになった印象がありました。

次回、オフショア開発をする時に、気をつけたい3つのポイント

最後に、ここまでの経験を踏まえて、次回、オフショア開発を進める際に、気をつけたいポイントをまとめたいと思います。

１、最初に、開発手法や進め方・ドメイン知識の共有の時間をしっかり取る

今回は、キックオフ（全体のスケジュール感や対応範囲の認識合わせ）に加えて、開発者向けドキュメントを作成し、共有することで、最初の認識合わせを終えました。

しかし、これでは、軌道修正タイミングが遅れてしまうなと反省しています。

最初に、開発者の認識合わせの時間をしっかりと確保し、その中でこちら側、あちら側のそれぞれの認識を理解しあって、足りないものに気づき補うことで、開発スタートとともに素早くスタートダッシュを切れるようになると思いました。

早めに問題を浮き彫りにした方が、全体として効率・改善速度は早められますからね。

２、スプリント単位での依頼チケットの丁寧な概要説明と時間の確保

スプリント単位ごとに、チケット依頼タイミングに、概要説明の時間をしっかりと確保し、認識合わせを密にしていきたいです。

このようなやり方は、一見、工数がかかってしまうように感じてしまいますが、これにより、手戻りやスムーズなレビュー・マージができるようになるかと思いました。

チケット内容に、概要記載が前提なので、ある程度打ち合わせを繰り返す中で、OKなものはサクサク進めていけます。

そのため、最初の最初は、工数かかる体感はあるかもしれないですが、段々とその負荷は減り、認識ズレもなくなるので、全体で見たら、最適な進め方なのかなと思います。

このようなイメージです。

３、検証環境の対応順序を早めにする

上記の通りですが、次回以降は、local でベースの環境構築ができたら、すぐに、検証環境の準備を進めていくようにしたいです。

デジ戦側・Techtus 側・事業部側が、共通して同じ環境で確認ができる検証環境を先んじて作っておくことで、同じ目線で動作確認や修正を前倒しで進めていくことができるためです。

検証環境の構築は、インフラメンバーへ構築依頼が必要になるため、始めにそう決めておかないといけない部分だと思っており（いきなり依頼は物理的に難しい）、次回、スケジューリングを立てるタイミングで必須で早めの設定と依頼を進めていきたいと思いました。

最後に

ここまで、振り返ってみて感じたことの一言でまとめると、

• 共通認識を早めに、丁寧に、細かくアクションを取ることが重要

ということかなと思いました。

オフショア開発に限らずですが、より文化や背景、物理的な距離、ドメイン知識の違いなどがどうしてもある中で、早め早めに、「共通認識」を持つ機会を能動的に作っていくことで、そのズレを無くし、スムーズなPJ 進行ができるのかなと思います。

こうして、文章で書いているとすごく当たり前ではあると思うのですが、当たり前だからこそ、いざやるタイミングで抜けてしまいがちなので、未来の自分が新PJ スタートタイミングでこの記事を見て、戒めようと思います。