NativeScriptのシステム開発を外部へ発注するには、業務範囲の整理、要件と契約の明確化、委託先の比較の順に進めます。この順で進めると、追加費用や手戻りを抑えやすくなります。全体像は、NativeScriptのシステム開発の完全ガイドでも確認できます。
▼全体ガイドの記事
・NativeScriptのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
NativeScriptのシステム発注で最初に決める全体像
NativeScriptの発注では、アプリの画面だけでなく、利用者が業務を完了するまでの仕組みを対象にします。現場担当者がスマートフォンで写真やQRコードを読み取り、API経由で既存システムへ登録する連携も含みます。また、管理者の承認や監査まで含めて、業務のゴールと責任範囲を先に決めておくと、会社ごとの見積もりの差を読みやすくなります。
業務上の目的と利用者の整理
業務上の目的は、誰のどの作業を、どう改善するのかを具体的に書きます。ゴールとなる到達状態も、あわせて明確にします。
- 営業：訪問後の報告入力を、当日中に終わらせる。
- 点検：写真と位置情報を、案件に紐づける。
- 配送：完了を、事務所へ即時に通知する。
- 利用者：現場担当者、承認者、管理者、顧客を区別し、権限と操作を整理する。
利用者ごとの操作を整理すると、画面数だけで見積もるより、過不足を抑えられます。
アプリ・サーバー・既存システムの境界
委託範囲は、アプリ、API、DBに分けて考えます。管理画面や認証基盤、監視、端末管理も、どこまでを委託するかを決めます。既存基幹を変えなくても、接続用APIの新設やデータ変換が必要になる場合があります。
アプリだけを頼むか、クラウド基盤まで含めるかで、費用と、どこから誰が責任を持つかが変わります。特に障害時に、アプリ会社と基幹システム会社のどちらへ連絡するかが曖昧だと、復旧が遅れます。
NativeScriptのシステムに適した発注形態
初めての発注では、NativeScriptの実績があり、API・認証・プラグインも扱える会社へ一括で委託すると進めやすいです。一方で、社内に業務知識がある場合や既存ベンダーがいれば、内製分担やラボ型も候補になります。
発注形態は、要件がどれだけ固まっているか、社内に技術者がどれだけいるか、リリース後の保守体制を見て選びます。
責任分界をまとめたい場合に向く一括請負
一括請負が合うかどうかは、任せる工程と、要件がどこまで固まっているかで判断します。
- 委託範囲：設計から納品まで、受託会社が担います。
- 一社管理：共通画面、API、管理画面を一社で扱い、Swift・Kotlinの端末処理やストア申請まで任せられます。
- 向く状況：社内にモバイル開発の経験が少なく、進行管理も任せたい場合。
- 契約条件：業務フローが未整理のまま固定価格を求めると、前提外の変更が追加費用になりがちです。
要件定義と小さな実機PoCを別々に契約し、その結果を見てから本開発を請負にする方法もあります。
変更が多い案件に向くラボ型・準委任
ラボ型・準委任は、稼働時間を確保したうえで、優先順位を変えながら進める契約です。
- 向く案件：現場の意見で画面や入力項目を改善する場合や、PoC後に段階的に機能を増やす場合です。
- 調査案件：NativeScript 9系への移行やプラグイン調査など、工数を読みづらい案件にも適します。
- 発注側の役割：プロダクトオーナーや業務責任者を置き、意思決定を早く行います。
- 契約で定める項目：毎月の成果物、稼働時間、優先順位、コードレビュー、知的財産の帰属。
契約内容が曖昧だと、作業時間だけが積み上がります。社内で意思決定を早く行える会社ほど、ラボ型の利点を生かせます。
知識を社内に残したい場合に有効な内製と外注のハイブリッド
社内が業務要件とデータを管理し、外部会社がNativeScriptの設計、実装、レビューを担う分担もできます。この分担は、発注費だけでなく、契約終了後に自社で保守できる状態を目指す手段にもなります。
- 社内：業務フロー、マスタ、受入テスト、ユーザー教育を担当する。
- 外部会社：アプリ基盤、ネイティブプラグイン、CI/CD、セキュリティテストを受け持ちます。
会社を選ぶ際は、設計書や環境構築の手順を確かめます。さらに、ビルド証明書の管理方法やプラグインの更新方針も見ておきます。
外注先のコードを社内で再ビルドできないと、将来のベンダーロックインにつながるため、障害対応の引き継ぎ計画も確かめておきます。
RFPと要件整理でNativeScriptの発注範囲を固める方法
RFPは、提案依頼先に同じ条件で提案してもらうための資料です。長い仕様書を最初から作る必要はありません。
まず、目的、対象業務、利用者をそろえます。さらに、連携先や希望時期、予算の考え方、委託範囲も書いておきます。前提が会社ごとに違うと、安く見えた見積もりが対象範囲の狭いものだった、ということが起こります。
現場の一日の流れで書く業務要件
現場アプリの操作要件は、通信や端末の状態も含めて、一日の業務順に整理します。
- ログイン後に担当案件を検索します。
- 現地で写真を撮り、QRコードを読み取ります。
- 通信が途切れたら一時保存し、復旧後に再送します。
- 上長による内容の承認。
正常時の流れだけでなく、異常時の動きも書きます。たとえば、端末の電池切れや重複送信、入力途中の離脱、権限のない案件へのアクセスといった場面です。
カメラやGPS、Bluetooth、プッシュ通知の利用有無を明記します。さらに、ファイルや端末ストレージ、バックグラウンド処理も書いておきます。
照会や申請が中心であれば、PWAやWebView系も候補になります。一方で、オフラインや端末APIを重視するなら、NativeScriptとReact Native、Flutter、Swift・Kotlinを同じ条件で比べます。
数値と運用条件に落とし込む非機能要件
現場の通信や端末環境に合わせて、見積もりの前に数値と運用条件を決めておきます。
- 基本条件：対応OS・端末、同時利用者数、通信断の許容時間、同期方式を定める。
- 運用条件：目標復旧時間、ログ保持期間、認証方式、保守時間帯を決める。
- 性能目標：「快適」のような曖昧な言葉を避け、一覧表示の秒数、写真一件の上限MB数、復旧後の再送時間を数値で示す。
- 端末管理：会社支給か私物か、MDMの利用、紛失時の遠隔消去を見積もりの条件にする。
セキュリティは、要件の段階で決めておく項目であり、後付けの検査項目ではありません。NativeScriptの公式ドキュメントでは、本番ビルドのリモートESモジュール読み込みは既定で無効になっています。ただし、リモート読み込みが必要な場合は、狭いHTTPS許可リストとバージョン固定が推奨されています。
トークンは、iOSのKeychainやAndroidのKeystoreのような安全な保管先に置きます。さらに、個人情報をログや平文のDBに残さないことと、通信をTLSで保護することも、要件に含めます。
先に決める成果物と受入条件
RFPでは、成果物の範囲と受入条件を具体的に書きます。成果物には次のものがあります。
- 開発資料：アプリのソースコード、API仕様書、画面・権限一覧、データモデル。
- 品質資料：テスト仕様書、脆弱性診断結果、CI/CD設定。
- 運用資料：ストア申請資料、運用手順書、教育資料。
- 納品条件：形式と保管場所、リポジトリ、第三者ライブラリのライセンス一覧、秘密情報の受け渡し方法。
受入条件は、画面が表示されるかだけでなく、業務シナリオに沿って確かめられる形で書きます。たとえば、対応端末でのログインや登録、同期を確かめます。さらに、権限外の情報が見えないことや、通信断からの復旧時に二重登録しないこと、障害ログを追えることも確かめます。
IPAが2025年に公開したシステム開発資料でも、多段階の見積もりや変更管理の重要性が示されています。
RFPには、要件をいつ確定するかと、変更の手続きも書いておきます。
NativeScript案件での契約形態と責任分担の決め方
契約では、開発会社の提案の良し悪しだけでなく、変更や障害のときに誰が何をするかを決めます。
アプリとAPIの責任境界、ネイティブプラグインの保守、OS更新への対応は、文書ではっきり書いておきます。また、ストア審査で差し戻された場合の修正担当も、契約で決めておきます。
要件・検収・変更管理を細かく定める請負契約
請負契約では、成果物と納期、検収方法を定めます。さらに、瑕疵や不具合の扱い、追加変更の単価も決めます。NativeScriptの画面開発だけを対象にするのか、iOS・Androidのリリース版まで含めるのかで、受入基準は変わります。
実機テスト端末や対応OS、App StoreやGoogle Playの審査日数は、契約書か仕様書に残します。
要件定義の後に追加された機能を無償にするか、変更見積もりにするかも決めておきます。すべてを初期契約に入れるより、MVP、追加開発、将来候補に分けたほうが、予算と納期を管理しやすいです。
作業範囲と成果の確認を毎月行う準委任契約
準委任契約では、専門家の知識や作業時間を確保し、相談しながら開発内容を変更できます。そのため、完成機能を固定価格で保証する契約とは性質が異なります。
月次の計画と実績を、定例会議で確認します。残課題やリスク、翌月の優先順位も、あわせて話し合います。NativeScript 8系から9系への移行やプラグイン調査など、先に技術検証が必要な場合に使いやすい契約です。
成果の確認には、リポジトリへのコミットやレビュー記録、テスト結果を使います。文書の更新も、成果の確認材料にします。また、発注側の承認者と技術責任者を決め、作業が見えないまま契約期間が延びることを防ぎます。
契約に含める知的財産・保守・引き継ぎ
契約では、権利関係と保守・引き継ぎの条件をはっきりさせます。
- 権利と環境：ソースコードと設計書の権利、既存プラグインのライセンスを確認し、第三者ライブラリの条件やCI/CD環境の所有者も確かめる。
- 保守範囲：窓口と受付時間、障害の重要度、一次回答と復旧目標のほか、OS更新、脆弱性修正、証明書更新、ストア再申請まで定める。
- 引き継ぎ：月次のバックアップ確認と、年一回以上の引き継ぎ訓練を、提案段階で確認しておく。
NativeScriptはオープンソースのため、フレームワーク自体のライセンス費用を抑えやすいです。一方で、プラグインやクラウド、監視には、別の費用と管理責任が発生します。さらに、端末管理やストアアカウントも、同じように別費用と管理責任を伴います。
保守内容を決めておくと、担当者が退職した後も、運用を続けやすいです。
NativeScriptのシステム外注費用相場と見積もりの見方
NativeScriptだけの日本向けの公開価格表はありません。費用は、機能やAPI・管理画面、既存連携の範囲で変わります。さらに、実機テストやセキュリティ、データ移行、保守範囲も影響します。
次の推定レンジは、リサーチノートの業務システム相場と、2026年公開の国内アプリ開発費用をもとにしています。NativeScript固有の確定料金ではなく、あくまで目安です。
規模別の推定レンジと費用の幅（150万円から1億円超）
費用と期間は、機能や連携の規模によって、次のように幅があります。
- 小規模PoC：ログイン、数画面の照会、簡易API、通知に絞る場合で、150万〜300万円程度。期間は1〜3か月が目安です。
- 標準業務アプリ：iOS・Android、認証、一覧・登録、写真やQRコード、API、管理画面を含み、500万〜1,500万円程度。期間は3〜6か月程度です。
- 高機能な現場アプリ：オフライン同期、GPS、SSO、複雑な権限、監査ログ、基幹連携、端末管理を含み、1,500万〜3,000万円程度。期間は6〜12か月程度。
- 全社展開：複数部門、大量データ移行、複数システム連携、冗長化、運用設計まで含むと、3,000万円〜1億円超の可能性があります。
なお、2026年公開の国内情報では、中規模アプリは500万〜1,500万円、大規模アプリは1,500万円以上とする目安が、複数示されています（出典: 2026年版アプリ開発費用公開資料、モカモコ株式会社・アイリッジ等）。
工程別・機能別・含有範囲別に読む見積もり
工程費の配分は案件ごとに異なりますが、初期検討では次の割合を比較の目安にできます。
- 要件定義・設計：要件定義10〜15%、設計15〜35%。
- 実装・テスト：実装30〜40%、結合・総合テスト15〜20%。
- 移行・導入：5〜10%が目安です。
この割合は、業務システム開発を工程ごとに分けて比べるための仮置きで、NativeScriptの公式料金ではありません。ただし、要件定義やテストを極端に削ると、後から追加費用が増えることもあります。
費用の抜けを防ぐため、見積書に書かれた機能と周辺作業の範囲を照らし合わせます。
- 開発範囲：画面、API、管理画面、認証、端末機能、オフライン同期。
- 周辺作業：テスト端末、ストア申請、クラウド、移行、教育、保守。
「クロスプラットフォーム対応一式」という書き方では、iOS・Androidの実機検証やネイティブプラグインが含まれるか分かりません。そこで、各社に同じRFPを渡し、含むものと含まないもの、前提条件を並べて比べます。
保守・クラウド・端末のランニング費用
初期費用とは別に、運用の段階で発生する費用と保守条件を分けて見積もります。
- 利用・管理費：クラウド、監視、ログ保管、プッシュ通知、MDM、端末購入、Apple・Googleの開発者アカウント。
- 対応費：脆弱性対応、OS更新、問い合わせ対応。
- 保守費の仮置き：初期開発費の年15〜20%程度とする場合があります。
保守費用は、サポート時間やSLA、改修を含むかどうかで変わります。そのため、固定の相場とは言い切れません。
特に、NativeScriptのプラグインは、iOSやAndroidの仕様変更に合わせた更新が必要になります。提案書には、OS更新方針やプラグインの最終更新日を書いてもらいます。さらに、代替策や脆弱性発見時の対応期限も記載してもらいます。
初期見積もりが安くても、保守がサーバーの稼働確認だけであれば、アプリのOS対応は別料金になる可能性があります。
委託先の選定とNativeScriptの見積比較で見るポイント
知名度や提案書の見栄えだけでなく、NativeScriptを使って今の案件を運用できる体制があるかを確かめます。
公式のPreferred Partnersには、nStudio、Valor Software、Karakun AGが掲載されています。また、Pace IT Systems、GFT Technologies SE、Imaginetなども掲載されています。
公式掲載は過去の関与を知る手掛かりです。ただし、現在の受託可否や日本語支援、料金、NativeScript 9系の実績までは保証するものではありません。
NativeScript 8.9・9系とネイティブ実装の実績
NativeScriptのバージョン別の発表内容と、委託先に確認する実装範囲を整理します。
- NativeScript 9.0：2025年11月に公開されました。
- NativeScript 8.9：2025年2月にNode-APIエンジンのプレビューが発表されました。
- バージョン確認：CLIやNode.js、@nativescript/core、iOS・Androidランタイムと、移行・ビルド実績を確かめる。
- ネイティブ実装：Bluetooth機器、特殊なバーコードリーダー、バックグラウンド処理、MDM、独自認証ではSwift・Kotlinが必要な場合があります。
9.0では、ネイティブES ModulesやVite対応の方向性が示されました。また、iOSのマルチウィンドウとListViewの拡張、Androidのエッジ・ツー・エッジ対応なども示されています。
カメラやGPSは既存プラグインで足りる場合があります。そのうえで、共通コードとプラットフォーム固有コードの境界を、提案会社に説明してもらいます。
安さより前提条件と抜け漏れを見る見積比較
合計額だけではなく、各社の見積もりの前提と対象範囲をそろえて比較します。
- 前提条件：対応端末数、OS下限、画面数の数え方、API本数、外部サービス、テスト種類。
- 含有範囲：管理画面、データ移行、ユーザー教育、ストア申請、保守期間。
- 抜け漏れ：安い提案では、要件定義や品質保証、障害対応、ネイティブプラグイン開発が含まれないことがあります。
- 提案の確認：同じRFPを3社程度へ渡し、採用理由や共通化・個別実装の範囲を質問します。
提案説明の場で不明点を質問し、実機検証の方法や将来のOS更新費用まで示されるかを確かめます。説明が具体的であれば、発注後の見通しを立てやすいです。
技術名だけでなく、業務・規模・保守まで聞く事例の確認
NativeScript公式ブログの2025年Community Spotlightでは、ポーランドのNetkonceptの事例が紹介されています。この事例は、自治体向けのObywatel.mobiをNativeScriptで開発したものです。
記事では、2,000以上のシステムと約80のモバイルアプリが説明されています。機能には、住民カードや通知、地図があります。さらに、ごみ収集や空気品質、検針などもあります。
- 事例の見方：画面数に加えて、複数組織への展開や通知、データ管理、セキュリティ、更新の仕組みを見る。
- 候補会社への質問：利用者数、対応OS、オフライン、連携API、ネイティブプラグイン、運用年数、障害対応体制。
- 匿名事例：社名を出せなくても、業種や課題、機能、期間、体制、成果、保守範囲を聞く。
匿名でも必要な情報を説明できる会社であれば、提案の再現性を判断しやすくなります。
提案段階で評価するセキュリティと運用設計
セキュリティの提案では、リスクの確認軸と、それに対する設計・テストの対応を見ます。
- 評価軸：端末内保存、暗号、認証、通信、プラットフォーム連携、コード、改ざん耐性、プライバシー。
- 提案内容：リスクを扱う設計・テスト、脆弱性診断、第三者レビューの有無。
- 個人情報・位置情報：アクセス制御、認証、不正アクセス防止、委託先管理、漏えい時の報告と復旧。
- 確認時期：要件定義から運用まで、各段階で確かめる。
OWASP MASVSは、この8つの管理グループを標準的な確認軸として整理しています。個人情報や位置情報を扱う場合は、個人情報保護委員会の安全管理措置も参考にします。
納品前の診断だけで終わらせず、開発から運用まで確かめられる会社を選びます。
NativeScriptのシステム発注でよくある質問
発注では、見積もりに含める範囲と運用担当がよく問題になります。そこで、発注前に質問されやすい内容をまとめます。
NativeScriptのシステム開発はすべて外注できますか？
外注できます。アプリ、API、管理画面、認証の開発を一括で依頼できます。さらに、クラウド、テスト、ストア申請、保守も、同じ会社に任せられます。
業務要件や受入テストを社内で担当し、技術実装だけを外注する方法もあります。その場合は、RFPで委託範囲と社内の責任を分けて書きます。
NativeScriptなら開発費を必ず安くできますか？
必ず安くなるとは限りません。共通コードを使えば、iOSとAndroidを別々に作るより効率化できる可能性があります。
一方で、ネイティブプラグインやAPI連携、オフライン同期には、費用が必要です。実機テストやセキュリティ、保守にも費用がかかります。比較の際は、2OSで共通化できる範囲と業務機能の複雑さを含めて考えます。
発注前にNativeScript 9系の確認は必要ですか？
必要です。2026年時点の新規開発では、NativeScript 9系とNode.js要件を確認しておきます。加えて、iOS・Androidの対応範囲やプラグインの更新状況、移行手順も確かめます。
既存の8系を保守する場合も、将来のOS更新やプラグイン終了時の代替策を提案できる会社を選ぶと、長期運用のリスクを抑えられます。
見積もりは何社から取ると比較しやすいですか？
同じRFPを3社程度へ渡すと、価格と提案を比べやすいです。
社数を増やしすぎると、説明や質疑の負担が増えます。そのため、NativeScriptの実績や業務システム連携、ネイティブ対応を見て候補を絞り、保守体制も確かめます。
金額だけでなく、前提条件や除外項目を比べてください。さらに、担当者や成果物、変更時の単価も確かめてください。
まとめ
まず、業務上の目的と利用者を定めます。そのうえで、アプリとAPI、認証、データの範囲を決めます。さらに、端末管理や監視、保守の範囲も決めます。
RFPには、現場の業務シナリオや対応端末、オフラインの扱いを整理します。さらに、権限や監査、セキュリティも盛り込みます。成果物と受入条件も、あわせて書いておきます。
発注前に確認する項目の一覧
一枚の資料には、目的、対象利用者、主要な業務シナリオを書きます。加えて、NativeScriptと他技術の比較理由や対応OS・端末を入れます。さらに、API・既存システム、認証、オフライン同期も並べておきます。
セキュリティや成果物、受入条件に加えて、予算と希望時期も入れます。同じ資料を委託先へ渡すと、提案の前提と見積もりの抜け漏れを比べやすくなります。
技術・契約・運用を一つの計画として比べる方法
外注先を比べるときは、技術・契約・運用を合わせて確かめます。
- 技術：NativeScript 9系、Swift・Kotlin、API・SSO・MDM・監査ログ、テストとセキュリティの実績。
- 契約と運用：変更管理、保守、OS更新、プラグイン継続性、ソースコードとプラグインの権利。
- 進め方：PoC、MVP、段階展開を使い分け、発注側の業務知識と委託先の技術力を組み合わせます。
- 費用判断：初期費用だけでなく、要件規模に応じた推定レンジと運用後の責任体制を比べます。
要件が固まった部分を請負にし、調査や改善が多い部分を準委任・ラボ型に分ける方法もあります。
費用は、小規模PoCの150万〜300万円程度、標準業務アプリの500万〜1,500万円程度、高機能な現場アプリの1,500万〜3,000万円程度が目安です。
全社展開は3,000万円〜1億円超まで幅があります。これらは、2026年時点の周辺市場と要件をもとにした推定で、NativeScript公式価格ではありません。
同じ条件で複数社を比べると、追加費用や手戻りを減らせます。
▼全体ガイドの記事
・NativeScriptのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。