gTVと実現するソリューション開発の在り方

こんにちは

トライアスロンがシーズンインの季節に関わらずスイムを避けてひたすらビールを飲むためにランばかりしているVPoEの大曽根です。

gTVでプロダクト開発が本格化してきました

ギフティでは開発ケイパビリティ強化を目的に、ベトナムホーチミンに開発拠点（gTV: giftee Tech Vietnam）を2023年に立ち上げました。

gTVの設立背景や目的に関してはこちらの記事を御覧ください。

tech.giftee.co.jp

そんなgTVですが、現地ベトナムのエンジニア採用を積極的に進めており、2025年4月時点で7人のエンジニアが在籍しています。

単なるオフショア開発ではなく、各事業部のプロダクトの開発を徐々に担い、事業推進の一翼を担いつつあります。

今回は、全社でみても中長期見据えた大きめな協業のプロダクト開発をgTVが担った案件の裏側をご紹介したいと思います。

※なぜVPoEである大曽根がこの内容を書いているのかというと、大曽根がVPoEの役割以外に全社特命案件のPdMも担っており、今回ご紹介する案件のPdMも担当していたので、というのが背景になります。

どんな案件？

すでにリリースも出しているこちらの案件のプロダクトの開発をgTVが担いました。

本案件はメルカリさんとの協業案件で、両社のアセットを活かしたユニークなサービス（メルカリギフト）を実現しています。メルカリをご利用の方はぜひメルカリギフトを利用してみてください（宣伝）

giftee.co.jp

この協業案件のサービス、メルカリギフトのプロダクトの開発をgTVが担いました。

スケジュールやエンジニアリソース観点で消去法的にgTVで開発を担う判断をしたわけではなく、今回のような特定の領域にフォーカスしたソリューション開発はgTVを積極的に活用していくという全体の方針に照らし合わせて、gTVが担うに資するという判断でgTVを採用しました。

逆に国内のプロダクト開発チームは特定領域に閉じない汎用性のあるプロダクト開発にフォーカスしていく方針を取っています。

体制や案件特徴とか

社内体制はざっくりこんな感じです。

日本側

Biz
- メルカリ側と相対し本協業のビジネスを主導する
PdM
- メルカリギフトプロダクトのプロダクトマネジメントとリリースまでのプロジェクトマネジメントを担う（※ここが筆者が担当しています）

gTV

Tech Lead
- PdMと連携したプロダクト全体のアーキテクチャ・仕様設計、gTV側エンジニアのマネジメントなどプロダクトのエンジニア側のリーディングを担う
- 日本でコアプロダクトのエンジニアを担っていた日本人エンジニアがgTV立ち上げでベトナムに赴任して今回のプロダクト開発のTech Leadも担ってくれました
Dev
- 本プロダクトの詳細設計・開発・QAを担う

今回の案件、従前の通り協業案件のため、協業先であるメルカリさんからの受託開発という立場ではありません。

あくまでギフティとしてはeギフトを販売できるソリューションをSaaS的に提供し、その提供先がメルカリさんという位置づけになります。

なので、このプロダクトの開発では、ギフティのプロダクトとしてのあるべき像と、協業にあたっての個別要件との間でバランスをとることが非常に重要でした。

プロダクト開発の進め方と意思統一

状況が流動的な中でプロダクト開発を進めなければいけないという背景があったため、変更可能性がある部分と要件を確定する部分をPdMとTech Leadですり合わせ上で、要件が確定している部分を先行して開発を進めました。

通常のオフショア開発の場合は、委託元のPdM（もしくはPjM）が要件を綺麗に定義し、オフショア先のBSEがその要件をキャッチアップしてTech Leadと会話して仕様を設計して、というような明確な役割分担をすることになると思いますが、口頭ベースでの要件伝達であっても、Tech leadのみならず現場のDevメンバーが能動的にキャッチアップし自律的に設計・開発をするというスピード感をもった開発が実現できていました。

ギフティの技術組織で志向している「ギークスーツ」がgTVでも体現されていることに国内を軸足にしている自分も驚きました。

と同時に、組織として中長期の目指す姿のアラインを取ることや自分たちが大事にしている行動指針を共有することがプロダクト開発に大事ということを改めて認識しました。

開発観点での日本と海外の共通点と違い

※以下については現地でgTVのエンジニアとコミュニケーションをとって開発を主導してくれたTech Leadの市橋さんがまとめてくれた内容になります。

全体的に共通しているのが、スタンスやスキルは各メンバー入社直後はバラバラではあるものの、チームで実現すべきことや提供価値、大切にしていることや文化を丁寧に共有していくことで、日本の開発チームで実現している目線でのプロダクト開発が実現しつつある点です。

実質の開発期間が3ヶ月弱という非常にタイトなスケジュール、かつ開発を進行しながら、リリース当初のマーケ施策や運用設計などを検討し、それらの検討結果がプロダクト要件の変更や追加につながるケースがあり、状況が錯綜する中でも物理的距離（東京 ✈️ ホーチミン）が無い位に感じるスピード感で開発を実現できました。

スタンス・コミュニケーション

一言で言えば、言語を除けば日本オフィスにベトナム人メンバーがいても違和感はなく、すでに“ギフティっぽさ”が根付いている

共通点
- チームで目標を共有し、議論を重ね、納得してから動くという進め方は、ベトナムでも日本と同じ
- 課題に対して自ら意見を出し、改善提案を行う姿勢も自然に見られ、指示通りに動くだけではなく、自分で考えてより良い形を模索する文化が根付いている
- ギフティのプロダクトやカルチャーに対しても理解があり、好意を持っているメンバーが多い
- ボトムアップな提案文化も浸透しており、懸念点の共有にとどまらず、システムの改善やエンハンスの提案まで出てくる場面もある
- 単なる受託ではなく、「自社プロダクトを開発している」という意識を持っており、日本市場・海外市場に向けたプロダクトを、ギフティの一員として開発している自覚がある
- 開発するだけでなく、ビジネスやその先にあるユーザーへの影響にも関心を持っている
- プロジェクトの完遂に向けてやりきる力、“One giftee”としての一体感、そしてチームメンバー同士の仲の良さも特徴的
違い
- ワークライフバランス
  - プライベートを大切にする文化が根付いている（ここは日本が特に仕事熱心なだけかもしれませんが）
  - とはいえ、必要なときには朝7時から出勤したり、夜遅く・週末の対応も厭わない柔軟さを持ち合わせている（ちなみにベトナムでは土日の勤務手当は300%）
- フロントローディングや“よしなに進める力”
  - まだ成長段階の部分もあるが着実に改善がみられる
- 言語の壁
  - 英語が共通言語だがお互いに第二言語同士のため、誤解が起きないよう伝え方には注意が必要
  - 大事なことは繰り返し伝え、明文化し、確認を怠らないことを意識すること
  - 敬語がない分、やりとりがシンプルに進むこともある
- “察する文化”の違い
  - 日本的な暗黙の了解や雰囲気の共有は通じにくく、あいまいな指示や“Yes”の返答には注意が必要
  - だからこそ、言語化と明確な指示が求めらる

設計・開発

共通点
- 開発プロセスやエンジニアとしてのマインドセットには、国を問わず共通する部分が多い
- CI/CDやコードレビュー、ユニットテスト、自動化・保守性の担保など、品質と効率のバランスを考える視点も同じ
- フルスタック志向も強く、インフラからバックエンド・フロントエンド、さらには運用・監視まで幅広く担当し、設計段階から実運用を見据えた開発ができている
- 入社当初は経験が浅くても、自分で技術をキャッチアップし、幅広く学んで短期間で力をつけるメンバーが多い
- 書籍より動画学習を好む傾向もある（これは翻訳環境など文化的背景も影響しているかも）
- プロダクトへの責任感や、ゼロイチの開発に対する挑戦意欲も共通している「自分たちで考えて作る」ことにやりがいを感じる文化が根付いており、その姿勢は非常に頼もしい
違い
- 日本語のUIや文言は、翻訳ツールを駆使して対応している
- ベトナムでは「自社プロダクト開発」の機会が少ない分、そうした開発に対する機会に対する意欲や成長欲求が非常に高い
- Ruby経験者は限られているが習得意欲が高く、実際に短期間で戦力化されている

テスト・運用・監視

共通点
- テストや監視、運用などもエンジニア自身が責任を持って担っており、品質や安定性の確保に対する意識も今では日本と大きく変わらない
違い
- ベトナムではQA（品質管理専任職）がチームにいるのが一般的なため、当初はエンジニア個人が品質も担うという文化が定着していなかった
- gTVでは、QA職がいない体制の中で「品質はエンジニア全員の責任である」という考え方を浸透させる必要があった
- 今では、エラーが起きた際の自発的な対応や、運用しやすさを意識した改善提案も自然に出てくるようになり、品質に対する意識は大きく変わってきた
- 運用や監視についても、以前は専任担当がいる文化が多く経験が浅いメンバーもいたが、今では自立して対応できるようになってきている