メインコンテンツにスキップ

Linnoedge

Linnoedge
システム開発 — ラボ型・受託 · ベトナム ホーチミン

AIで生産性が変わった、
ベトナムの開発チーム。

AIで、開発の速さとコストの前提は変わりました。僕たちはホーチミンの開発チームごと、その前提に組み替えています。何をAIに任せ、何を人が握っているか——工程別の実測を、このページでそのまま公開しています。

ただ、オフショア開発がうまくいかない理由は、昔から変わっていません。ブリッジSEを置いた。日本語の窓口もいた。それでも動かなかった——問題は翻訳ではなく、PMの不在です。誰かが全体の責任を持って動かないと、「正しく作った」と「使えるものができた」が一致しない。リノエッジのITディレクターは、その役を担います。

関わり方は2つ。御社専属チームを持つラボ型と、プロジェクト単位で完結させる受託。どちらもPMをAIで拡張する同じ体制で、チーム組成は最短2週間、人月40万円からです。仕様が固まっていない段階からで構いません。

原田祥吾 リノエッジ代表取締役
原田祥吾 — 代表取締役・ホーチミン在住 在籍エンジニア25名 / クライアント継続率95%(直近12ヶ月)

こんなお悩みありませんか

オフショア開発でよく聞く話

日本側の担当者が、画面遷移図も作り、備考欄に注意点も書き、ミーティングで口頭でも補足した。ブリッジSEは「わかりました」と言っている。議事録も上がってきた。

でも、本当に伝わっているか、確信が持てない。

実装が上がってくると、並び順が違う。ステータスの表示が違う。エラーメッセージが違う。一つひとつは小さい。でも積み重なると、1ヶ月のスケジュール遅延になる。

この話、オフショア開発を経験した人のほぼ全員がしてくれます。パターンは大体3つです。

01 / 仕様と品質

できあがったものを見たら、動いてはいる。でも「なんか違う」

ITディレクターがPMとして入るので、認識のずれを設計段階から潰せます。通訳係を挟まないから、技術的な議論が表面的にならない。「聞けなかった」が起きにくい構造です。

02 / チームの継続性

案件ごとにチームが変わって、毎回ゼロから説明する

受託開発の構造上の問題です。ラボ型は専属チームが固定されるので、文脈が途切れません。「また一から」がなくなります。

03 / コミュニケーション

海外チームに指示を出すのが不安で、結局うまくいかなかった

どこで認識がずれるかを知っているかどうかの差です。ホーチミンで開発を回し続けながら、ずれやすいポイントを先回りして設計に入れています。

AI-Driven Development

AIで、開発のやり方は毎週のように変わっています。
だから僕たちは、決めていることが一つだけあります。

AIの世界では、大前提が一週間でひっくり返ることが、たびたび起きます。だから僕たちは、「最新のやり方」を売り物にするのをやめました。どんな手法も、すぐに古くなるからです。代わりに決めているのは、変わり続ける前提で、チームと工程を組むこと。下の表は、いま何をAIに任せ、何を人が握っているかの、今日時点の答えです。前提が変われば、書き直します。

AIドリブン開発の工程別実測——何を任せ、何が変わったか

工程AIに任せていること人が握っていること実測の変化(自社・直近の案件)
要件定義ヒアリング内容の構造化・仕様書ドラフト・見落とし観点の列挙「何を作らないか」の判断・優先順位仕様書の初稿が3日 → その日のうち
設計・プロトタイプ動く画面の先行生成・技術選定の比較材料アーキテクチャの最終判断初回ヒアリングから約1週間で動くデモが標準に
実装コーディングの大部分(全エンジニアがClaude Code / Cursorを常用)仕様との一致確認・エッジケーススプリント消化量は実質 約3倍(下記※)
レビュー・テスト静的検査・テスト観点の網羅チェックテスト仕様書の設計・受け入れ判断管理工数はむしろ増加(それでも差し引きで上の数字)
ドキュメント議事録・仕様書・引き継ぎ資料の生成と更新「何を残すか」の基準属人化リスクの低減(FAQ「退職時」参照)

※ コードが出てくる速さだけなら、3倍どころではありません。ただ、テスト・セキュリティ確認・レビューの工数は逆に増えます。それを差し引いて「実質3倍」。速くなった分の一部を、確認の密度に払い戻しています。数字より大きいのは、仕事の質が「書く」から「確かめて判断する」に変わったことだと考えています。

Field note — AI-driven delivery / 直近の実測
仕様書の初稿3日 → 当日
初回の動くデモ約1週間
スプリント消化量実質 約3倍
テスト・確認の工数増加 ⚠
速くなった分を確認の密度に払い戻した、差し引き後の数字。

なぜ、全部AIに任せないのか

僕たちも最初から線引きができていたわけではありません。実際に、事故を起こしています。

AIエージェントに任せていた作業で、ステージング環境のデータベースが丸ごと消えたことがあります。幸い本番ではなくステージングでしたが、画面が真っ白になったときの感覚は忘れられません。原因をたどると、AIの性能の問題ではなく、「AIが触ってはいけない領域」を人の注意力だけで守ろうとしていた僕たちの設計の問題でした。以来、AIが触ってはいけない領域は権限の仕組みで物理的に守り、その上で人の側の最終責任を明確にしています。ルールを増やすのではなく、事故が構造的に起きない形にする——このやり方は、僕たちの他の品質の仕組みと同じです。

線引きの根拠は、体験だけでなく2026年時点の数字とも一致しています。

  • AIが生成したコードの45%に、セキュリティ上の既知の脆弱性パターンが含まれていた——という検証結果があります(Veracode・100以上のLLMを対象にした2025年の調査)。だからレビューとテスト仕様書は人間の仕組みで握ります。
  • Googleの開発者調査(DORA 2025)は、AIを「増幅器」と呼びました。整ったプロセスはより速く、壊れたプロセスは壊れ方が加速する。だから僕たちはAIを入れる前に、テスト仕様書ファーストや週次デモといったプロセスの側を先に設計しています。
  • 開発者は業務の約6割でAIを使う一方、人の確認なしに完全に任せられるタスクは0〜2割(Anthropic調査・2026年)。僕たちの現場の実感とも、ほぼ同じ比率です。

「AIで人を減らす」ではなく、
「AIで、PMと品質の密度を上げる。」

AI導入・活用そのものの支援はAI内製化支援で。このページは「AIで開発チームがどう動くか」の話です。

他社との
構造的な違い

よくある失敗の構造
あなた ブリッジSE(通訳・連絡役) 海外チーム

「PMがいない」ことが、ここでの最大の問題です。

リノエッジのラボ型の構造
あなた ITディレクター(PMとして動く) 海外チーム
↑ AIでPMを担保する

翻訳者ではなく、ITディレクターがPMとして直接動きます。仕様の決定から、チームへの指示、品質管理まで一本化。さらにAIツールでPMの質を担保することで、人依存のリスクを減らします。

Why Linnoedge

リノエッジのITディレクターは、PMです

ベトナムのオフショア開発会社は、本当にたくさんあります。どこも「高品質」「低コスト」「日本語対応」と書いてある。違いが分かりにくいと思います。リノエッジが違うのは、以下の3つの構造です。

01

ITディレクターが「PMとして」動く

多くのオフショア会社では、日本側と開発チームの間にブリッジSE(通訳係)を挟みます。リノエッジのITディレクターは違います。スケジュール管理・要件整理・チームコントロール——プロジェクト全体の責任者として動きます。

「間に通訳がいます」ではなく、「PMがいます」という体制です。

02

そのPMを、AIで拡張する

ITディレクターがプロジェクトを管理するとき、AIドリブンのPMツールが並走しています。担当は開発ではなく、管理のほうです。お客様の要望の一つひとつが、いま調査中なのか、実装中なのか、受け入れ確認待ちなのか——ステータスを漏れなく追跡し、止まっているものを人より先に検知します。

効果が一番はっきり出るのは、複雑なプロジェクトです。上の「AIドリブン開発」がコードを書く速さの話だとすれば、こちらは「PMの見落とし」をなくすための仕組みです。

03

品質は仕組みで守る

「この人が頑張るから品質が出る」は再現性がありません。担当者が変わったとき、チームが拡張したとき、同じ品質が出るかどうかが問題です。

リノエッジでは、要件整理の段階からテスト観点を設計し、テスト仕様書を作成したうえで開発を進めます。品質の判断基準を先に見える化することで、「人が変わったら品質が落ちた」を構造的に防ぎます。

↳ 現場メモ — 代表一番変わったのは速さじゃなくて、複雑な案件ほど要望の抜け漏れが減ったこと。どの要望がいま調査中か、実装中か、受け入れテスト中か——漏れなく追える。

構造の違い

一般的なオフショア会社

お客様
営業担当
ブリッジSE通訳係
開発チーム

要件が層を経るたびに薄まる

VS

リノエッジ

お客様
ITディレクター
(プロジェクトPM)
AI
開発チーム

PMが全体責任を一本化する

25名 在籍エンジニア ベトナム・ホーチミン
95% クライアント継続率 直近12ヶ月
50件以上 累計プロジェクト  
7年以上 チーム平均経験  

規模は大きくありません。だから、PMが直接動けます。

Service

ラボ型と受託、
どちらの形でも受けています

ラボ型は、御社専属のチームを海外に持つ形。チームが固定されるので文脈が積み上がり、開発力が資産になっていく——ストック型の関わり方です。受託は、決まった仕様をプロジェクト単位で完成させて納品する、フロー型の関わり方。どちらが上ということはなく、御社の案件がいまどの段階にあるかで決まります。

項目受託開発ラボ型開発
契約形態成果物に対する契約人材 × 期間に対する契約
仕様変更追加費用が発生しやすい契約期間内は柔軟に対応
チーム案件ごとに編成・解散専属メンバーが継続
ノウハウ蓄積プロジェクト終了で失われやすいチームに蓄積していく
コスト予測見積もりベース(変動あり)月額固定
向いているケース仕様が確定した短期案件継続的な開発・改善が必要な案件

迷ったときの目安。仕様が固まっていて、作るものと期限が明確——受託が向いています。作りながら育てたい、リリース後も保守・改善が続く——ラボ型が向いています。境目の案件も多いので、最初の相談で「どちらが現実的か」から一緒に整理します。

受託の場合も、進め方の骨格はラボ型と同じです。要件整理の段階からテスト観点を設計し、テスト仕様書を作ってから開発に入る。週次デモで途中経過を見てもらう。下の事例にあるクリニクイック(体制4名・6ヶ月で企画から導入まで)のように、期間を区切って一気通貫で完結させたプロジェクトは、この形で進めてきました。

ラボ型の体制は、3種類から選べます。

Type 01

通常ラボ

御社のPMが、ベトナム側のITディレクターに直接指示を出す体制です。オフショアの経験がある方には、これが一番シンプルです。

Type 02

ITディレクター
日本常駐ラボ

ベトナム人ITディレクターが日本に常駐します。御社PMとのやりとりは日本語です。海外チームとの仕事が初めてでも、進めやすい体制です。

Type 03

当社PM参画ラボ

リノエッジの日本人PMが、御社PMと連携して動きます。上流の要件定義・設計から入るので、「何を作るべきかの整理から手伝ってほしい」というケースに向いています。

Process

プロジェクトの始め方

最初のミーティングは、契約の場じゃありません。御社が今何に困っていて、何をやりたいのかを聞かせてもらう場です。

1

Discovery ── 契約前に「何をどう進めるか」を整理する

「要件がまだ固まっていない」「何から始めればいいか分からない」という段階でも構いません。むしろ、見えていないものに優先順位はつけられない。何が課題で、何から手をつけるべきか——それが整理できていない状態でコードを書き始めても、あとから「そもそも」が出てきます。

どのくらい現状が整理されているかによって、3つのレベルから選べます。いずれのレベルも最大4週間・費用ゼロで行います。「どれにするか」は最初の相談で一緒に決めます。

Level 1

初期適合性確認

  • 適合判断
  • 概算の体制・予算
  • 推奨ステップ

Level 2

Rapid Discovery

  • チーム構成案 3案
  • ROM見積
  • 3ヶ月ロードマップ

Level 3

Strategic Discovery

  • 現状分析
  • バックログ作成
  • 90日計画
2

動くイメージを先に作る

話を聞いたら、AIを使って動くイメージを先に作ります。文字で100回やりとりするより、画面を1枚見るほうが早い。本格的にコードを書き始める前に「これでいいのか」を確認できるので、あとからの手戻りが大幅に減ります。

3

専属チームを組成し、開発を始める(最短2週間)

チーム構成が決まれば、最短2週間で動き出せます。開発中は週次で進捗を共有します。仕様変更やフィードバックには都度対応する。作って終わりではなく、一緒に育てていく形です。

コミュニケーションは、Slack・Teams・Chatwork・Google Chat、御社が普段使っているツールに合わせます。

4

リリースして終わりじゃない

実際にユーザーが使い始めてから見えることのほうが多い。ラボ型の一番の良さは、この改善サイクルを専属チームで回せることです。チームが変わらないから、文脈が途切れない。同じコードベースを同じメンバーが継続的に改善していくので、回すたびに理解が深くなり、スピードが上がります。

プロジェクトを「完了させる」だけなら、受託でもできます。でもリリース後にどれだけ速く改善できるか。そこが、事業の成果に直結するところです。

Cost

費用の目安

まず小さく始めて、進行に応じて体制を拡張することもできます。

人月 40万円 から

PM + 開発者1名の最小体制から対応。体制規模・スキルセット・日本語支援の有無で変動します。

一般的な体制はPM + ディレクター + シニアエンジニア + 開発者3名くらいの構成が多いです。新規開発か保守改善か、必要なスキルで実際の費用は変わります。

初回ヒアリングで、目的に合った現実的な体制と概算をお出しします。最初の相談に費用はかかりません。

コストについて、会社としての基準を先に書いておきます。

単価:リノエッジのエンジニア単価は人月40〜60万円。日本の国内受託相場(80〜120万円)のおおむね半分です。

総コスト:立ち上げ・コミュニケーション工数を含めた総コストでは、約35%の削減が実感値です。単価差ほどには縮まりません——それを含めてご判断ください。

雇用・調達形態月額目安費用の性質採用コスト
自社採用(国内)約70万円〜固定費約100〜150万円
派遣約80万円〜変動費0円
ラボ型開発(リノエッジ)40万円〜変動費0円
自社海外拠点設立状況により変動固定費数百万〜

※ 月額は目安。スキルセット・体制規模により変動します。

体制別の目安

体制構成月額目安向くケース
スモールスタートITディレクター + エンジニア1名70〜90万円PoC・MVP・まず試す
標準体制PM + ITディレクター + エンジニア3名160〜200万円継続開発・機能拡張
中規模PM + ITディレクター + エンジニア5名250〜300万円並行開発・大規模改修

※月額は目安。スキルセット・日本語支援の範囲で変動します。初回ヒアリングで現実的な体制と概算をお出しします。

「AIで工数が減るなら、見積も下がるんですか?」

営業の場で必ず出る質問なので、先に書いておきます。

下がる部分と、下がらない部分があります。実装のスピードが上がった分は、同じ予算でより多く作れる方向に効きます。一方で、AIが速くなるほど「何を作るべきか」「できたものが本当に正しいか」を判断する人間の仕事は増えます。僕たちはそこ(PM・レビュー・テスト設計)に人の時間を寄せ直しています。

つまり「同じものを安く」より、「同じ予算で、より多く・より確かに」の方向です。時間を売るラボではなく、成功させるためのラボを選んだので、この配分を基本にしています。

Compare

どこに頼むか迷っている方へ——
4つの選択肢の比較表

選択肢は、僕たちを入れて4つあります。どれが向くかは、御社がいまどの段階にいるかで決まります。だから、リノエッジに不利なことも含めて、そのまま表にしました。

国内SIer大手オフショア社内でAIツール内製リノエッジ(ラボ型・受託)
得意日本語で全部おまかせ大人数の確保小さく速く試す仕様が固まる前からの伴走
コスト構造高単価・固定中〜低単価・層が厚い分の間接費ツール代のみ・ただし人の時間人月40万円〜・変動費
難しいところ費用と小回り担当が遠い・要件が層を経るたびに薄まる動くものはできるが、保守・品質・セキュリティを誰が握るか50名規模の大量確保・「技術に一切関わりたくない」案件
向くケース全部委任したい大規模・長期PoCを今週中に見たい継続開発・改善を回したい

3列目は、実際に増えている選択肢です。AIコーディングツールで動くものは作れます。ただ、動いた後——保守・品質・セキュリティの責任を誰が持つかは、ツールでは解決しません。そこで詰まった段階でご相談いただくケースが増えています。

なお、この4類型の中間もよくある形です。受託契約での単発開発も、御社の内製チームとの併走も、実際にお受けしています。表は「どれか一つを選ぶ」ためではなく、話を始める前の地図として置いています。

Cases

これまでの仕事

詳細を公開できるものだけ掲載しています。

医療 / Webシステム

クリニクイック(CliniQuick)医療施設のウェブ受付システム

企画から設計・インフラ構築・導入サポートまで一気通貫(体制4名・6ヶ月)

ある医療施設では、ネット予約と来院予約が別々の仕組みで動いていました。現場のスタッフがそれを手作業で突き合わせていて、患者さんの待ち時間が長くなる。問い合わせの電話も鳴り止まない。

やったことは、ネット予約と来院予約を一つにまとめ、待ち状況をリアルタイムで患者さんに通知する仕組みを作ること。企画から設計、AWSのインフラ構築、導入のサポートまで担当しました。

PHP (Laravel) / MySQL / AWS

マッチング / モバイルアプリ

経営者専用マッチングアプリ

3年で40万組のマッチングが成立

経営者同士のビジネスマッチングは、それまで紹介ベースが中心でした。「会いたい人に会えるかどうか」が人脈の広さで決まってしまう。その構造を変えたいという相談から始まったプロジェクトです。

企画・UI設計からシステム全体の構築、運用保守まで担当しました。AIのマッチングアルゴリズムを作り、毎日5人の経営者を自動で紹介する仕組みにしています。3年で40万組のマッチングが成立しました。

Flutter / PHP / NoSQL / Firebase Auth / WebSocket

EdTech / AI活用

リンガリンク(LingaLink)AI活用のオンライン学習プラットフォーム

AI機能の実装から運用まで専属チームで対応(体制2名・8ヶ月)

オンライン教育って、コンテンツを並べるだけでは成り立たないんです。学習者一人ひとりの理解度に合わせて、次に何を学ぶべきかを提示できるかどうかが鍵になる。

AIを使って学習体験をパーソナライズする仕組みの開発を支援しました。EdTech領域で、新しい学びの形を技術面から作ったプロジェクトです。

Honest Note

リノエッジが向いていないケース

合わない仕事を受けても、お互いの時間がもったいない。はっきり書きます。

01

「50名以上のエンジニアを一度に確保したい」

僕自身、前の会社で150人の開発組織をゼロから作った経験があります。大きくすることはできます。ただ、規模を追うと一人ひとりのプロジェクトへの関与がどうしても薄くなる。それが嫌で、リノエッジを作りました。大規模な人員が必要な場合は、大手のオフショア開発会社のほうが向いています。

02

「相見積もりで、一番安いところに決めたい」

仕様が固まっている案件は、受託でお受けしています。ただ、最安値の入札競争には参加しません。テスト仕様書を先に作る・週次デモで確認するといった品質の構造は、受託でも外さないからです。価格だけで選ぶなら、もっと安い会社はあると思います。

03

「日本語だけで、技術的な話には一切関わりたくない」

リノエッジは、御社の担当者にも技術的な判断にある程度関わってもらうスタイルです。「全部おまかせ」がいいなら、国内のSIerのほうが期待に合うかもしれません。

04

「AIが出した答えの、検証だけをしてほしい」

AIで調べて、仮説を持って来ていただくのは歓迎です。話が早くなります。ただ僕たちは、AIの答えをそのまま検証するだけの仕事は受けないと決めています。中身を理解して答えるから、結果に責任が持てる——その分、時間はかかります。答え合わせの速さを最優先する場合は、合わないと思います。

AI & Offshore

「AIがあれば、
オフショアはもう要らないのでは?」

最近、本当によく聞かれます。当事者として答えます。

半分はその通りです。「仕様書を渡してコードが返ってくるだけ」の開発は、AIで置き換わっていきます。指示待ちの人月商売は、たぶん要らなくなります。これは僕たち自身も例外ではありません。

でも実際に起きているのは、開発の外注が減ることではなく、外注に求められるものが変わることです。僕たちに来る相談も、AIが広がってから減ったのではなく、中身が変わりました。減ったのは「作業の切り売り」で、増えたのは「何を作るべきかから一緒に考え、AIを織り込んだ体制ごと提供するパートナー」への相談です。

もう一つ、現場で起きている変化があります。発注する側も、AIで動くものを作れるようになりました。前提が一つ変わったのだと思います。ただ、AIで「できそう」に見えるものと、事故なく運用し続けられるものの間には、まだ大きな距離があります。ちょっとしたミスが、AIのスピードのせいで、より大きな事故につながりやすくもなっている。だから僕たちは、お客様ができることが増えるスピード以上に、セキュアに運用する仕組みの側を先回りして作り続ける必要があると考えています。

デモまでなら、AIはほとんど何でもできます。事故なく運用し続ける段になると、何でもはできない。この距離を測った上で体制を組むのが、いまのオフショア開発の仕事だと考えています。

僕たちがこのページで工程やコストの中身まで見せているのは、その変化に賭けているからです。途中経過まで見てもらったほうが、判断が早いと考えています。

Start Here

ラボ型か、受託か。
どちらが合うかは、話してみないと分かりません。

御社に専属チームを置く——それが合う会社もあれば、まず要件整理から、という会社もあります。30分の壁打ちで「今どこが詰まっているか」を聞いて、どの進め方が現実的かを一緒に考えます。提案書より先に話します。

「合わないと思ったら、
正直にそう言います。」
1
30分の壁打ちを予約する。事前準備はいりません。今どこで詰まっているかを話してもらうだけで十分です。
2
状況を聞いて、出発点を一緒に整理する。ラボ型がそのまま合うこともあれば、まず要件整理から、ということもあります。
3
フィットすれば、次のステップを具体化する。合わないと思ったら、そのまま伝えます。より合うやり方を一緒に考えます。
原田祥吾 リノエッジ代表取締役
話す相手
原田 祥吾
代表取締役 — 株式会社リノエッジ・ホーチミン市

今、自分の会社をAI実装の実験台にしています。経営のほぼ全部をAIと組んで回す試みを始めて数ヶ月。一日の仕事でAIを使わない時間の方が少なくなっています。

何が動いて、何が動かないか——自分たちで先に試して、先に失敗してから御社に持っていく。それが原則です。

FAQ

よくあるご質問

比較検討の初期段階でよく聞かれる順に並べました。

Q01 仕様書がない場合でも対応できますか?
「仕様書バッチリ、あとはコード書くだけ」という案件よりも、「やりたいことはあるけど、どう作ればいいか一緒に考えてほしい」という相談のほうが得意です。現場でやってきて、最初から完璧な仕様書が出てくる案件はほとんどありません。新規サービスの立ち上げ、既存システムの作り直し、まずPoCだけ回したい——そういう「走りながら考える」タイプの開発で、一番力を発揮します。
Q02 費用はどのくらいですか?
人月40万円からです。PM + 開発者1名の最小体制から始められます。実際の費用は、必要なスキル・体制規模・日本語支援の範囲・新規開発か保守改善かで変動します。初回ヒアリングで、目的に合った現実的な体制と概算をお出しします。
Q03 要件定義から支援してもらえますか?
もちろんです。要件定義や設計の段階から伴走し、必要な機能や優先順位を整理しながら進めます。完成仕様を前提にするのではなく、相談しながら具体化していくのがリノエッジの得意とするやり方のひとつです。
Q04 対応している開発の範囲を教えてください
Webシステム、モバイルアプリ(iOS / Android)、AI機能の実装、PoC・MVP開発、保守運用・機能改善まで対応しています。「これって頼めるの?」という段階で構いませんので、まず相談してください。
Q05 言語や文化の壁は大丈夫ですか?
代表自身がホーチミン在住で、日本とベトナムの現場を長年行き来してきました。「どこで認識がずれやすいか」を体感として知っています。社内公用語は英語ですが、日本側とのやり取りは日本語で対応します。ブリッジSEを挟まずITディレクターが直接つながる構造なので、技術的な議論が表面的になりません。「海外チームへの指示の出し方が不安」という声が一番多いですが、その不安がどこから来るかも含めて、最初に一緒に確認します。
Q06 品質はどう保証していますか?
3層で品質を担保しています。①日本語対応のITディレクターが仕様を詳細化し、曖昧な依頼を防ぎます。②週次デモで進捗を可視化(「作ってから見せる」ではなく「作りながら確認」)。③Le-sanが率いるITDチームが自動テストと品質管理を担います。あわせて、要件整理の段階からテスト観点を設計し、テスト仕様書を作成・提出することで、担当者が変わっても品質の判断基準がぶれません。最初は1〜2名のパイロットから始め、品質を確認してから規模を拡張します。
Q07 AIで作ると品質が心配です。大丈夫ですか?
もっともな心配だと思います。AIが生成したコードの45%に既知の脆弱性パターンが含まれるという調査(Veracode・2025年)もあり、「AIが書いたから速くて安心」は成立しません。僕たちはAIの出力を無条件に信用しない前提で、テスト仕様書を先に作る・週次デモで動くものを確認する・ITDチームが品質管理を担う、という人間側の仕組みとセットで運用しています。詳しくは本ページ「AIドリブン開発」の工程表をご覧ください。
Q08 体制はどのように組成しますか?
案件の規模や目的に応じて設計します。最小ではPM + 開発者1名から始められますし、一般的にはPM + ディレクター + シニアエンジニア + 開発者3名くらいの構成が多いです。拠点はベトナム・ホーチミンです。案件に合わせて、合う体制を提案します。
Q09 契約形態にはどのような種類がありますか?
主にラボ契約を中心にしていますが、受託契約にも対応しています。ラボ契約は3種類(通常ラボ / ITディレクター常駐ラボ / 当社PM参画ラボ)から選べます。「海外チームへの指示の出し方が不安」という声がいちばん多いので、案件の性質とお客様の体制に合わせて、どのモデルが現実的かを一緒に相談して決めます。
Q10 リリース後の保守対応はしてもらえますか?
もちろん対応しています。初期開発だけでなく、リリース後の運用・保守・機能改善まで継続して支援できます。ラボ型の最大の良さは、同じチームが継続して関わり続けることです。単発の納品で終わるのではなく、必要に応じて改善を重ねながら育てていく進め方に対応しています。
Q11 ベトナムへのオフショア開発で、日本企業はどのくらいコストを削減できますか?
日本でシニアエンジニア1名を採用した場合のフル換算コスト(給与・社保・採用費・オフィスコスト含む)は月額100万〜150万円程度です。リノエッジのラボ型開発は人月40万円から(管理費込み)。3名チームで比較すると、年間約2,100万〜3,900万円の差が生まれます。なお、これは国内採用と比べた場合の数字です。国内の受託相場(人月80〜120万円)との比較では、単価はおおむね半分、立ち上げ・コミュニケーション工数を含めた総コストでは約35%の削減が実感値です。
Q12 AIを活用すると、開発費は安くなりますか?
実装部分は確実に速くなっています。その分を「同じものを安く」に使うか「同じ予算でより多く・より確かに」に使うかは、プロジェクトの目的次第です。僕たちは後者を基本にしていますが、初回ヒアリングで目的に合わせた配分をご提案します(本ページ「費用の目安」参照)。
Q13 ラボ型開発とプロジェクト型の違いは何ですか?
ラボ型は「御社専属チームを海外に持つ」形態です。月単位で継続し、スプリントを回します。プロジェクト型は「この機能を〇月までに」という一括発注です。保守・改善が続く開発にはラボ型が向いており、単発のシステム構築はプロジェクト型が合います。リノエッジはラボ型を主体としています。
Q14 どのくらいの期間で開発チームを立ち上げられますか?
通常2〜4週間です。日本での採用(平均3〜6ヶ月)と比較すると大幅に短くなります。ただし、仕様が固まっている・開発環境の準備ができている、という前提があります。仕様が不明確な場合は着手前に整理する時間が必要です。
Q15 日本語が話せるエンジニアはいますか?
開発エンジニアは主にベトナム語・英語で業務します。日本語対応はITディレクター(ブリッジ役)が担当します。エンジニアが直接日本語でやり取りする形態ではありませんが、ITディレクターが間に入り、ニュアンスまで伝わる体制を作っています。
Q16 エンジニアが途中で退職した場合、プロジェクトはどうなりますか?
ラボ型開発の設計上、1名の退職がプロジェクト停止につながらないようになっています。スプリントごとのドキュメント更新で情報の属人化を防ぎ、ITディレクターがコードベース・仕様・経緯を常に把握。引き継ぎ期間を設けた上での交代を原則としています。直近12ヶ月のクライアント継続率95%は、こうした継続性の仕組みが機能している結果です。
Q17 まず1〜2ヶ月だけ試してみることはできますか?
できます。「Discoveryフェーズ」という入口を用意しています。最大4週間・費用ゼロで、課題の整理・技術検証・MVPスコープ決定・チーム顔合わせ・精度の高い見積もりを行います。「合わない」と感じた場合、費用はかかりません。
Q18 対応している技術スタックを教えてください
バックエンド: Ruby on Rails(最も得意)/ Laravel(PHP)/ Node.js / Django(Python)。フロントエンド: React / Next.js。モバイル: Flutter / React Native(iOS・Android)。インフラ: AWS / Firebase / GCP。AI開発: LLMアプリケーション開発 / AIエージェント構築 / RAG / 既存システムへのAI機能組み込み。開発チーム自体も、Claude CodeとCursorを全エンジニアが常用しています。「この技術でできるか?」の確認はDiscoveryフェーズで一緒に行います。
Q19 御社自身の失敗事例を教えてもらえますか?
あります。タイムゾーンの問題では、ベトナムは日本より2時間遅く「朝イチで直してほしい」が相手の深夜に当たることがありました。対策として非同期コミュニケーションを前提にしたスプリント設計と、テキストで完結する依頼フォーマットを標準化しました。コードコメントの属人化(母国語混在問題)も経験しており、現在は英語統一で運用しています。失敗を隠すより仕組みに変えることが私たちのやり方です。

AI活用でも失敗しています。AIエージェントに任せた作業でステージング環境のデータベースが消えたことがありました(本番への影響はありません)。この事故を機に、「AIが触ってはいけない領域」を人の注意ではなく権限の仕組みで守る設計に変えています。失敗を隠すより仕組みに変える、はAIについても同じです。

このサービスは「作って納品して終わり」にも、「御社チームだけで回せる状態まで伴走する」形にもできます。内製化まで持っていきたい場合 → AI内製化支援