ベトナムの開発チームとAIモデル開発をした話

とうとう、秋の花粉症も発症してしまい、目のムズムズと格闘している藤田です。 Data & Analysis部で、CADDi Drawer等のプロダクトに提供するAIモデルを開発しています。

さて今回は、私がベトナムの開発メンバーとAIモデル開発をした話を紹介しようと思います。 海外のメンバーと開発を進めることは、言語の壁をはじめいろんな壁があります。 どんな壁がありどうやって乗り越えたのかをご紹介したいと思います。

海外メンバーとの開発をやっている方や、海外メンバーとの協業に興味がある方の参考になればなーと思っています。

なお、この記事は、[https://adventar.org/calendars/12197:title] 13日目の記事です。

海外の開発メンバーとAIモデル開発を実施した背景

きっかけ

こちらにある通り、キャディは2024年7月に、部品調達プラットフォームCADDi Manufacturing と 図面データ活用クラウドCADDi Drawerの２つのサービスの事業を統合し、「製造業AIデータプラットフォームCADDi 」へと転進することを決めました。この事業統合前まで、ベトナムのAI開発チームは、ベトナム現地において、Manufacturing事業のソリューション開発を主にやっていました。しかし事業統合後、ベトナムのAI開発チームは徐々にCADDi Drawerの開発に携わるようになりました。CADDi Drawerは基本的に日本で開発されているので、その頃から私を含め、Data & Analysis部のメンバーがベトナムチームとプロジェクトをやるようになっていきました。

なぜ私が、ベトナムAI開発チームとのプロジェクト担当になったのか？

一言で言うと、「やりたいです！！」と手を挙げたからです。 実は、私は入社当初から海外との仕事に興味があり、機会があれば手をあげたいと思っていました（なんと入社エントリーにも書いています）。そんな矢先、「ベトナムと開発する話があるんだけど」と言われたので、思いっきり手を挙げました。

その結果、2025年1月頃から様々なプロジェクトをやらせてもらっています。 現在2025年12月なのではや1年程になりました！

3つの壁

海外チームとのプロジェクトの進め方と、日本チームとのプロジェクトの進め方とでは、色々と異なる点があります。 その違いから、私は色々な壁に当たりました。ここでは特に大変だった壁を3つ紹介します。

データの壁

まず1つ目は、データの壁です。我々が扱っている顧客データは、図面等の最重要機密データです。これらのデータは、法律で海外に送ることが禁止されています。AIモデル開発にとって、データはかなり重要なのですが、それが使えないとなるとできることが限られてしまいます。 そこで、データの制約がある状況でも、どんなタスクであればベトナムチームが取り組めるかを検討しました。

#	データ制約があってもできるタスク
1	Open dataを使ったモデル開発
2	Data augmentationやdata creationなどデータを作るようなタスク
3	機密情報ではないデータなど、海外利用が許容されているデータを使う
4	データを加工して復元できない状態でデータを送りモデル開発をする

上記4つのカテゴリーそれぞれで具体的に何ができそうかを検討した結果、現時点では、以下の2つを主に取り組んでいます。

• 「#1 Open dataを使ったモデル開発」
• 「#2 Data AugmentationやData Creationなどデータを作るようなタスク」

これらの2つのタスクを選択した理由は、事業的にやりたいタスクの中に、このタスク#1と#2に該当するものがあったためです。 逆に、タスク #3, 4については、現時点では事業的なニーズが小さく、取り組んではいません。

タスク #1, 2の具体例は、

• Open dataを使った3D系のモデル開発
• LLM評価データセット作成

です。上記2つの例について、無事プロジェクトを完了することができています。 このように、顧客データが使えない中でも、モデル開発やデータセット作成など取り組めるタスクを考え、その結果、成果を残せたのは良かったと思います。

受託文化の壁

ベトナムのソフトウェア業界は、海外からのオフショア開発拠点として成長してきたこともあり、受託開発をやってきたエンジニア多いです。まさにキャディの開発チームでも、受託開発をやってきた方は多い一方で、プロダクト開発を経験したエンジニアは少ないです。 キャディでは、CADDi Drawer等のプロダクト開発をやっているので、ベトナムのエンジニアが、キャディの開発プロセスに戸惑うこと多々あります。 この節では、受託開発とプロダクト開発の違いが原因で、特に苦労したことを紹介したいと思います。

ソフトウェアの継続的改善

ベトナムチームとのプロジェクトを開始した当初、ソフトウェアの継続的改善への意識の違いがありました。 以下は、一般的に言われている、受託開発とプロダクト開発との、ソフトウェアの継続的改善への意識の違いです。基本的に、プロダクト開発の方が、ソフトウェアの継続的改善への意識が高いと思います。

比較項目	受託開発	プロダクト開発
最終ゴール	「納品」すること 仕様書通りのものを作り、検収を終えることがゴール。	「事業成長」すること ユーザーに使われ、利益を生み続けることがゴール。
改善の動機	クライアントの指示・予算 「お金をもらえるならやる」が基本。指示なき改善はコスト増（赤字）になるため避ける傾向。	ユーザーの満足・離脱防止 改善しないと競合に負ける、ユーザーが離れるという危機感が原動力。
技術的負債	先送り・回避したい リファクタリングは機能が増えるわけではないため、顧客に予算承認をもらいにくい。「動いているなら触らない」が安全。	積極的に解消したい コードが汚いと将来の開発スピードが落ちるため、自分たちのために定期的に掃除（改善）する。
リリース後	保守フェーズ（守り） 障害が起きないよう監視することが主務。大きな変更は別プロジェクト扱い。	運用・成長フェーズ（攻め） リリースしてからが本番。A/Bテストやデータ分析を行い、日々改善を繰り返す。

上記の通り、受託開発とプロダクト開発のビジネス構造の違いから、ソフトウェアの継続的改善へのモチベーションは大きく異なります。 プロダクト開発における、ソフトウェアの継続的改善の意識を持ってもらうために、対策を色々考えたのですが、結果的に以下を実施しました。

継続的改善を担保するような、開発プロセスが日本チームに既に存在するので、そのプロセスに従ってもらう。

この対策は言うは易しなのですが、実際にやってみると、日本側のレビューがかなり大変ではありました。 ただ、一回このプロセスを実施してもらえば今後のプロジェクトにも活きるため、必死にレビューを実施し無事全てのプロセスを完了することができました。 （良かった！）

今後は、ベトナムチームの開発リーダーを中心にこの開発プロセスを浸透させ、さらには改善させていくことを考えています。

要件が不明確

ベトナムチームとのプロジェクトを開始した当初、プロジェクトの要件が不明瞭でやりづらいと、ベトナムメンバーからコメントがありました。 これも受託開発とプロダクト開発の違いで、プロジェクトの要件定義の仕方が、受託開発とプロダクト開発とで異なります。 以下は、一般的に言われている、受託開発とプロダクト開発との、プロジェクト要件定義の仕方の違いです。

比較項目	受託開発	プロダクト開発
最大の目的	クライアントの要求を満たすこと (契約の履行・納品)	ユーザーの課題解決・事業成長 (マーケットでの成功・PMF)
要件の決定権者	発注者（クライアント）	プロダクトマネージャー (PdM) / 事業責任者
要件の源泉	クライアントの要望、RFP、業務フロー	ユーザーヒアリング、データ分析、市場調査
定義のゴール	「仕様の確定」 見積もりとスケジュールの遵守のため、曖昧さを排除する。	「仮説の構築」 MVP（実用最小限の製品）を定義し、検証準備をする。
詳細度・粒度	高・網羅的 着手前にドキュメント（要件定義書）で細部まで固める。	中・可変的 コア機能以外はあえて決めすぎず、開発しながら調整する。
変更への対応	抑制的 (Change Control) コスト・納期への影響が大きいため、変更管理が必要。	推奨的 (Pivot/Iterate) ユーザーの反応を見て要件を変えることは「改善」とみなす。

受託開発では、最初になるべく明確に細かいところまで要件を決め切ります。それによって、プロジェクトの不確実性を落としコスト・納期の管理をしやすくします。

一方で、プロダクト開発でのプロジェクトは、仮説検証が主な目的です。例えば、「ユーザヒアリングの結果、Aという機能を作ればプロダクトの価値をあげられる」のような仮説をたて、それを検証するために機能開発をしユーザの反応を見ます。当然、仮説が最初から明確になっていることは少ないですし、途中で仮説を軌道修正することもあります。その都度、要件は変わりうります。 このように、受託開発とプロダクト開発では、要件定義の仕方が大きく異なります。このような違いもあり、メンバーのほとんどが最初、要求項目が曖昧で戸惑ったりしました。

この課題に対して、まずは、違いを明確に説明し、認識を統一しました。そして、最終的にはプロジェクトを継続して経験してもらうことで、習熟度を高めていくように働きかけました。

メンバーによっては、要件が決まらないことにストレスを感じる方もいましたが、その都度、「プロダクト開発では、プロジェクト初期から要件を明確に決めることはできない。」、「エンジニアも事業内容を理解した上で、積極的に要件を決めにいってほしい」と伝えました。 その甲斐もあってか、最近では「要求項目が曖昧で不確実性が高い状況を楽しめている」というコメントをメンバーからもらっています。 引き続きプロジェクトを重ねてもらい、プロダクト開発の要件の決め方に慣れていってもらいたいです。

言語の壁

言わずもがなですが、ベトナムチームとのコミュニケーションは、ベトナム語か英語になります。 ベトナム語で「こんにちは」は、「Xin chào」です。当然、英語を選択しました。

ただ、私自身、海外チームと仕事もしたことないし、海外の移住経験もありません。なので、最初は特に英語でのコミュニケーションに苦労しました。 ちょうど英語で悩んでいる時に、社内で英語サポートプログラムが始まったこともあり、それを利用させてもらいました。一日2時間英語勉強という、スパルタなプログラムでしたが、日々、ベトナムチームとのやりとりで英語力UPを感じていたので、それがモチベーションになり頑張ることができました。 プログラムが終わる頃には、英語を話す度胸がつき、綺麗な英語でなくとも勢いで話すことができるようになりました！

成果

そんなこんなでなんとかベトナム開発チームとプロジェクトをやってきていますが、特に成果を残せたなと思うのは、3D CAD関連の機能をアルファ版としてリリースできたことです。3D CAD関連プロジェクトは元々2年くらい前に、日本チームで精度検証を実施していたのですが、図面優先の方針もあり2年間ペンディングしてました。それをベトナム開発チームが引き継いで進めました。 モデルの精度改善をし、そのモデルをAIプラットフォームにのせ、APIとして使えるようにし、顧客にAIモデルの解析結果を届けることができました。 2年ペンディングしていたプロジェクトを、ベトナムメンバーと一緒にリリースまでやり切ったのは、個人的にも嬉しい成果でした。

今後

ベトナムチームと仕事を始めてから1年経ちますが、まだまだ組織としての改善点や、やり残した課題がたくさんあります。

• 日本の開発チームと比べ、アクセスできるデータが依然として少ない
• ソフトウェアの継続的改善をチームに浸透

それらを短期的に解決することは難しいが、定期的に目標を立てながら徐々に解決していき、ベトナムチームがより成果を出せるようにしていけたらと思っています。

まとめ

今回は、ベトナムの開発メンバーと共にAIモデル開発に挑戦した1年間の取り組みについて紹介しました。 振り返ると、以下の「3つの壁」といかに向き合うかがポイントでした。

• データの壁：機密データの制約がある中で、Open Data活用やデータ作成タスクなど「今できること」にフォーカスして成果を出した。
• 受託文化の壁：「仕様通りの納品」から「仮説検証と継続的改善」へ。粘り強くプロセスを適用し、対話を重ねることで、プロダクト開発のマインドセットを徐々に浸透させた。
• 言語の壁：英語学習プログラムの活用と、「伝えようとする度胸」でコミュニケーションのハードルを乗り越えた。

決して平坦な道のりではありませんでしたが、2年間ペンディングしていた「3D CAD関連機能」をベトナムチームと共にリリースまで持っていけたことは、ベトナムチームや私にとって大きな自信となりました。

受託開発文化からプロダクト開発文化への転換など、組織として解決すべき課題はまだ残っています。しかし、国境を超えて一つのプロダクトを作り上げ、事業価値を生み出すプロセスには、困難以上の面白さとやりがいがあります。

今後もベトナムチームと共に、キャディのAI開発をさらに加速させていきたいと思います！

ベトナムでの写真

定期的にベトナムに行き、開発メンバーと交流しています。その時の写真を共有します。

• 写真１：昼食後のカフェ（ベトナムでは昼食後にカフェに行く文化があるらしいです）

  

  昼食後のカフェ

• 写真２：芋虫の入ったオムレツ（興味本位で食べたら、ちゃんと美味しくなかった 笑）

  

  芋虫のオムレツ