3年前、こう言われました——
『このアプリ、誰も直せないんです』
あるスタートアップでのことです。アプリはスケジュール通りに出た。React Native、コードもそこそこ整っていた。App StoreもGoogle Playも承認された。でも6ヶ月後、ベンダーは次の案件に移っていて、OSのマイナーアップデートでプッシュ通知が壊れた。直せる人間が、もう誰もいなかった。
ただ、これは1社だけの話じゃないんですよね。ほとんどのモバイル開発契約は「納品」を中心に書かれている。App Store承認がゴールライン。リリース後に何が起きるかは、スコープに入っていない。
だから、ラボモデルを作ることにしました。iOS・Android・React Native——専任チームが、リリース6ヶ月後もコードベースを知っている状態を保ち続ける。サポート契約じゃない。作ったチームが、そのまま残る。
開発コスト
同じチームが残る
標準期間
「うちもこれだ」が出る 3つの場面
プラットフォームも業界も違う。でも問題の根っこは、だいたい同じなんですよね。
プロダクトのイメージは固まっています。iOS優先かクロスプラットフォームかも決まっている。コアとなる画面遷移もわかっている。足りないのは、それを実際に作れるチームです。ビルドフェーズが終わったら忙しくなくなるエンジニアを正社員で雇うのも、フリーランスを個別にまとめるのも、どちらも現実的じゃない。
2年プロジェクトのために採用するのはコストが高い。フリーランスは動き始めは早いけど、連携が難しい。このフェーズのほとんどの方が本当に必要としているのは、仕様書からApp Storeまで、タスクレベルで管理しなくても動ける小さな専任チームです。
v1はリリースされています。作ったベンダーはいなくなった。機能追加したい、あるいはユーザーから報告されたバグを直したい。でもコードベースを知っている人間がいない。新しいチームに頼むと、「他の人が書いたコードを読む時間」が見積もりに乗ってきて、何が含まれているかわからないリスクを価格に織り込んでいる感じがする。
最初のビルドが失敗するより、この「v2で壊れる」パターンの方が多いと思っています。v1が成功したのは、スコープを絞ったからでもあります。v2になって初めて、継続性のために何も設計されていなかったことがわかる——ドキュメントなし、アーキテクチャのメモなし、次のチームが「壊してはいけない動作」を知るためのテストカバレッジもない。
App StoreにもGoogle Playにもある。ユーザーは使っている。OSアップデートは年2回来て、毎回何かが壊れる。新機能も出したいけど、ベンダーとの契約はプロジェクト型で、リリース時点で終わっていた。都度スポット対応で頼むか、コードベースをゼロから説明し直して新しいベンダーを探すか。
現実的な選択肢は、社内再採用するか、新しいベンダーにコンテキストを一から説明し直すか、最初から「残る」ことを設計したチームと関係を作るか。ほとんどの保守契約は、説明責任を避けるように書かれているんですよね。だから、契約書をこう書くことにしました——月額レートはビルドフェーズと同じ・チームメンバーは入れ替えない・OSアップデートの初動は契約上の義務。プロジェクト型と本質的に違うのは、ここです。
プロジェクト型と、ラボ型は何が違うのか
ほとんどのモバイル開発契約って、App Store承認という納品マイルストーンを中心に書かれているんですよね。ラボモデルが設計されているのは、その後です。
- プロジェクトのためにチームが集まる——App Store承認で解散
- 知識はエンジニアの頭の中に残る。アーキテクチャは文書化されない
- スコープ変更のたびに契約交渉が必要
- リリース後のサポートは別契約、別チーム
- OSアップデートで既存動作が壊れても、対応できる人がいない
- 最初のスプリントから保守まで、同じチームが担当
- アーキテクチャをスプリントごとに文書化——メンバーが変わっても継続可能
- スコープ変更はスプリントレビューで対応。契約修正なし
- リリース月1から対応可能——ハンドオフ待ちなし
- OSアップデートの対応は、そのコードを書いたチームが担当
他のチームと違う、3つの理由
プラットフォームの選択は、チームアサインの前に決める。 すべてのモバイルプロジェクトは、同じ問いから始まるんですよね——React Nativeかネイティブか。ほとんどのベンダーは、最初の営業電話でこれを決めてしまう。自分たちのチームが得意な技術で。でも、それっておかしくないですか。プロダクトの要件は、ベンダーの得意領域より先にあるはずです。だからDiscoveryフェーズで決めるようにしているんです——想定デバイス幅、オフライン動作の有無、アニメーションの複雑さ、既存コードベースとの依存関係。ある案件で、クライアントは「iOSネイティブ一択」と思っていた。Discoveryの終わりには、React Nativeが正解でした——そのデータを示した上で。
実際のユーザー分布はAndroid 60%だった。
Discovery 1週目に判明。アーキテクチャが確定する前に。
React Nativeへの変更で、並行ネイティブビルドの4ヶ月を節約した。
App Store申請は、スコープに含まれている。 「サポートします」じゃなく、スプリントプランに載っていて、他のフィーチャーと同じQAゲートを通る。App Storeで申請が止まるのは、モバイルプロジェクトで一番よくある失速ポイントなんですよね——プロビジョニングプロファイル、プライバシーの説明文、アプリ内課金の設定、スクリーンショットのスペック。両ストアへの申請は、これまで何度もやってきました。プロセスはドキュメント化されている。
作ったチームが、そのまま残る。 今、2本のモバイルプロジェクトが2年目の保守フェーズに入っています——同じチーム、同じコードベース、「なぜプッシュ通知のアーキテクチャがこの設計になったか」を覚えているITディレクターがいる。iOSのメジャーリリースで何かが壊れても、そのコードを書いたエンジニアが「どこを見ればいいか」を知っているんです。文化の話ではなく、ラボモデルの構造から自然に出てくる結果です。
ベトナム オフショア モバイル開発——ただ「オフショア」の部分は、コストの話だけじゃないんですよね。アプリをリリースした半年後、OSのアップデートで何かが壊れたとき、まだ同じチームが部屋にいる構造のためにラボモデルを作っています。東京の同等チームと比較すると概ね2.5〜3倍のコスト差になりますが、それは副産物であって、見出しじゃない。
ほとんどのベンダーは
App Storeを通してくれる。
iOS 20が何かを壊したとき
まだいるのは、
ほとんどいない。
契約前に、ほぼ全員から
出てくる3つの質問
モバイルアプリの開発経験があってもなくても、出てくる不安はだいたい同じなんですよね。
イメージ通りのアプリができるか、不安です
担当エンジニアが途中で退職したら？
稟議を通した後、進捗が追えなくなるのが怖い
社内にプロダクトオーナーが いるか、いないか
どちらのモデルも、同じチームが担当します。違いは、調整機能をどっちが持つか——それだけです。
御社のプロダクト担当者が、リノエッジのITディレクターと直接コミュニケーションします。間に調整役は入りません。ITディレクターがモバイルテックリードとして機能して、プロダクトの方向性を受け取ってエンジニアチームに落とし込み、遅延になる前にブロッカーを上げる。
スプリントボードにアクセスできます。2週間に1度のレビューコールでは、動くソフトウェアを実機で触っていただきます。チームとの距離感は、ご希望に応じて調整できます。
日本人PM体制で、プロダクト定義からApp Store申請まで参加します。ビジネス文脈（日本語）とベトナム開発チーム（英語）の間に、通訳をはさまずに立つ役割です。UXワイヤーフレーム、仕様設計、スプリント計画、ステークホルダー調整、ストア申請まで担当する——両方向にネイティブで動けるPMが、ハンドオフのロスを構造的になくします。御社はビジネスのコンテキストとレビューのタイミングを提供するだけでいい。あとはこちらで進めます。
PMは最初に、ユーザーが実際に行うアクションの流れをマッピングします——画面デザインの前に。モバイルの失敗のほとんどは、このステップを飛ばしたところから始まります。
最初の連絡から、App Storeの先まで
ラボモデルは、最初のコードより前から始まるんです。ストア承認で、終わらない。
モバイル案件3件、実際に何が起きたか
「できます」の説明じゃなく、特定の案件で何が起きたかです。詳細は実績ページで。
React Nativeという選択はDiscoveryから来ました。仮定ではなく。両ストアへの申請を同週に承認されました——申請プロセスを事前に計画していないと、これはあまりないことです。
v1を作ったチームが、保守案件をそのまま継続しています。iOSとAndroidのすべてのメジャーバージョン移行を、元のコードを書いたエンジニアが担当してきました。26ヶ月間、OSアップデートによる本番リグレッションはゼロです。
案件はPoCから始まりました——4週間で動くプロトタイプを作り、フルビルドにコミットする前にコアな仮定を検証する。プロトタイプの仕様がそのままv1プランになりました。
Discoveryの結論はFlutter——1コードベース、1つのデザインシステム、1チーム。同様の構造でビジネスマッチングアプリ、店舗プロモーション支援アプリなど、Flutter案件を多数納品してきました。「ワンソースでマルチプラットフォーム」がプロダクトの現実に合うとき、Flutterが正解です。
正直に言うと
向いていない場合
- ×タスクを指示して成果物を確認してまた指示する、という管理スタイルで進めたい場合。ラボモデルは、御社側に「成果を定義できる人」が必要です。その人がまだいない段階なら、今はラボモデルより合う選択肢があるかもしれません
- ×仕様が完全に固まっていて、質問なしで最安値を出してほしい——Discoveryは不要、という場合
- ×App Store承認がゴールで、リリース後のことは別の話、という場合
向いている場合
リリース後もいるチームを探している
- ✓アプリがコアプロダクトであり、一度作って終わりではなく、月・年単位で育てていく必要がある
- ✓以前オフショア開発を経験して、継続性の部分でうまくいかなかったことがある
- ✓ハンドオフのタイミングだけでなく、2年後にも電話できるベンダーが欲しい
まず測ってみる
オフショア開発の準備度・コストを、その場で測る
いきなり相談するのは気が重い、という方へ。御社がオフショア開発に向いているか、費用がどう変わるか。その場で測れる無料ツールを2つ用意しています。結果を持って壁打ちに来ていただくと、話が早く進みます。
30分で、この構造が
あなたのプロダクトに合うか話しましょう。
アプリのアイデアがある、あるいは稼働中のアプリを任せられるチームを探している。どちらでも構いません。最初の問いは「React Nativeかネイティブか」ではないんです。この構造——専任チーム・スプリントベースの説明責任・go-live後も継続——が、あなたのプロジェクトの現実に合うかどうか、です。
このページを読んで、「自分のことだ」と思う部分があったなら、それだけで話す理由になります。30分、声に出して話してみてください。合わないなら、そう直接伝えます。
ベトナムで10年以上、開発チームを運営してきました。失敗のパターンは一貫しています——アプリが出る、ベンダーが次の案件に移る、何かが壊れる、コードベースを知っている人間がいない。十分な回数見てきたので、ラボモデルは「プロダクトの意思決定」ではなかった。明らかな構造的な答えでした。
メンバーが抜けても機能するチームは、抜けたら崩壊するチームより強い。逆説的に聞こえるかもしれませんが——コードベースを書いた人間だけが理解できる状態なら、ソフトウェアプロダクトじゃなく「依存関係」を作ったことになる。ドキュメント、スプリントごとのアーキテクチャノート、ラボの構造。これはオーバーヘッドじゃない。go-live後の説明責任が実際に要求するものです。
ベトナムのチームへの
モバイルアプリ開発委託——よくある質問
2026年時点で、それぞれ重心が違うんです。Flutterはクロスプラットフォーム市場の約46%を占めていて、Google Pay・BMW・Toyota が「画面の細部まで揃った見た目」と「機種間の安定したパフォーマンス」のために採用しています。私たち自身もFlutterで案件を多数納品してきました——就活生向けES添削サービスアプリ（AIによるESの自動生成・添削、先輩ESの閲覧）、ビジネスマッチングサービスアプリ、店舗プロモーション支援アプリなど、「ワンソースでマルチプラットフォーム」がプロダクトの現実に合うケースで。React Nativeは35〜38%。Meta のアプリ群・Discord・Pinterest・Microsoft Teams が動いていて、React Web側とコードを共有でき、JavaScriptエンジニアの母集団も大きい。iOS Swift・Android Kotlin は、OS深部との連携、ネイティブAPIへの依存、複雑なアニメーションが要件になる場合に正解です。
プラットフォームの選択はDiscoveryフェーズで決めます——プロダクトの実際の要件から。チームが得意な技術から逆算しません。
正直に言うと、申請した後ではなく、申請する前にリジェクション対応の文書を準備します。 決済・UGC・B2Bマッチング——フラグが立ちやすいシナリオについては、該当ガイドラインに基づいてリバタル文書を事前に準備します。審査落ちが来たときの対応時間が、「ガイドラインを初めて読む」チームとは桁違いに違います。
日本最大のB2B経営者マッチングアプリで4つのガイドライン違反フラグが重なった申請も対応してきました。プロセスはドキュメント化されています。最初の申請は賭けじゃない。
必要に応じて、東京の同等チームとのコスト比較、過去の案件実績（匿名化）、リスク管理の観点（ラボモデルによるベンダーロックイン回避、アーキテクチャドキュメントの引き渡し条件等）を追加することもできます。「この発注に社内で説明できるか」という視点で資料を作ります。