LASSIC Media らしくメディア
iOSアプリ開発委託の進め方｜ネイティブ外注の実務ガイド
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- iOS（Swift）とAndroid（Kotlin）のネイティブアプリ開発を委託する際の、要件定義から引き渡しまでの5ステップフローを整理しています。
- 委託先を選ぶ際の3つの評価軸と、請負・準委任・SESの契約形態ごとの使い分けを説明しています。
- スコープクリープや知的財産権など、委託で起きやすい失敗パターンと、事前に対処するための具体的な方法を紹介しています。
目次
ネイティブアプリ開発委託とは何か
iOSアプリ・Androidアプリのネイティブ開発委託とは、Swift（iOS）またはKotlin（Android）を用いたアプリ開発を、社内リソースで完結させずに外部のベンダー・開発会社・フリーランスに委ねる発注形態を指します。
iOS（Swift）とAndroid（Kotlin）— ネイティブ開発の基本
iOSアプリはAppleが開発したSwiftで、AndroidアプリはGoogleが公式推奨するKotlinで構築するのが現在の標準です。どちらも各OSのAPIを直接呼び出せるため、カメラ・生体認証・プッシュ通知・ウィジェットといったOS固有機能をフルに活用できます。
Googleは2019年にKotlinをAndroidの第一言語として正式宣言しており、宣言的UIフレームワークのJetpack Composeが現場標準に移行しています。AppleもSwift UIを主軸に据え、Swift Concurrency（非同期処理の仕組み）がiOS 17以降の開発基盤となっています。
ネイティブ開発は各OSの最新APIをいち早く使えるメリットがある一方、iOSとAndroidで別々のコードベースを維持する必要があるため、委託コストと管理工数が2系統に発生します。この費用構造の詳細はクロスプラットフォームとの比較を含め別記事で扱っています。
クロスプラットフォームとの選択基準
Flutter（Google）やReact Native（Meta）などのクロスプラットフォームフレームワークは、1つのコードベースでiOS・Androidの両方に対応できます。ただしOS固有機能への深いアクセスや最新APIへの追従はネイティブに劣る場合があります。
「OS固有の機能（Face ID連携・ウィジェット・ARKit等）を多用するか」「将来的にOS新機能をいち早く取り込む必要があるか」という基準でネイティブを選択する判断が多くなります。どちらが適切かの選定基準は、要件定義の段階でベンダーとすり合わせることが大切です。
委託前の準備：ターゲットOS・機能スコープ・発注材料の確定
委託を成功させるうえで、発注前の準備品質が成否を大きく左右します。要件があいまいなまま発注すると、開発途中の仕様変更による追加費用や、受け入れ段階での手戻りが発生しやすくなります。
ターゲットOS・機能スコープ・リリーススケジュールの確定
まず「iOS専用・Android専用・両対応」を明確にします。両対応の場合は同一ベンダーへの一括委託か、iOS/Androidを別ベンダーに分けるかという体制の判断も必要です。次に「MVP（Minimum Viable Product）でリリースする機能」と「後続フェーズに持ち越す機能」を分離します。
リリーススケジュールは逆算して設定します。App Storeの審査には通常1〜3営業日かかりますが、初回リリース時はそれ以上かかる場合があります。Google Playの初回審査も1〜3営業日が目安とされていますが、審査状況により変動するため、ストア審査期間を含めたバッファをスケジュールに組み込むことが大切です。
自社で用意すべきもの（デザイン・API仕様・承認フロー）
発注前に自社側で準備しておくべき素材は主に3種類です。第一にワイヤーフレームまたはデザインカンプ（UIの方向性が分かる程度のもの）、第二にバックエンドAPIの仕様書またはモックアップ（データ連携がある場合）、第三に社内の承認・レビューフローです。
デザインについては「ブランドガイドライン」や「既存Webサイトのデザイントーン」をベンダーに共有するだけでも大きな手戻りを防げます。API仕様が未確定の場合は、モックAPIで開発を進める方法もありますが、その旨をベンダーと合意しておく必要があります。
委託先の選び方 — iOS/Android実績・体制・契約形態
委託先を選ぶ際は「技術実績」「プロジェクト管理体制」「コミュニケーション方式」の3軸で評価することが、発注後の摩擦を減らすうえで有効です。
評価の3軸：技術スタック実績・管理体制・コミュニケーション頻度
技術実績については、Swift/Kotlinの開発経験年数だけでなく「対象OS・バージョンとの適合」を確認します。例えばSwiftUI対応実績・Jetpack Compose対応実績があるかどうかは、現行のiOS/Android開発標準に追従できるかの目安となります。
プロジェクト管理体制では「進捗報告の頻度と形式」「課題管理ツール（Jira・Redmine等）の使用有無」「専任PMの有無」を確認します。週次定例がない体制は、仕様の認識齟齬が発覚するタイミングが遅れるリスクがあります。
コミュニケーション頻度については、スプリントレビューの設定、Slack等の非同期チャットの可否、ソースコードの共有方針（GitHubリポジトリの共同所有等）を事前に確認しておくことが大切です。
請負と準委任の使い分け
ネイティブアプリ開発の委託契約は、大きく「請負契約」と「準委任契約」に分かれます。
| 契約形態 | 特徴 | 向いているケース | 留意点 |
|---|---|---|---|
| 請負契約 | 成果物の完成・納品が義務。 費用は固定額になりやすい。 |
仕様が確定しており、完成責任をベンダーに持たせたい場合。 | 仕様変更が発生すると変更契約が必要。 仕様が固まっていないと追加費用が膨らみやすい。 |
| 準委任契約 | 業務遂行（作業）そのものへの対価。 成果物の完成保証はない。 |
要件が流動的でアジャイル的に進めたい場合、 または技術調査・PoC段階。 |
完成保証がないため、進捗管理を発注側も担う必要がある。 工数が膨らむと費用が増加する。 |
フリーランス・開発会社・SES（元請委託）の選択基準
フリーランス（個人）は単価が抑えられる反面、長期安定稼働・代替要員への対応が難しい場合があります。開発会社はチーム体制と品質管理の仕組みを持つため、一定規模以上のプロジェクトに向きます。SES（Systems Engineering Service、技術者を常駐派遣する形態）は自社のマネジメント下で技術者を動かせますが、指揮命令関係の整理が必要です。
元請（プライムベンダー）として一括受注するベンダーを選ぶ場合は、下請け構造の透明性（再委託先の開示）や、プロジェクト全体の進捗責任の所在を契約書で明確にすることが大切です。
ネイティブアプリ委託の5ステップフロー
ネイティブアプリ開発を委託する際の標準的なフローは、要件定義・選定契約・設計試作・開発テスト・リリース引き渡しの5段階です。各段階での発注側の関与度がプロジェクト品質を左右します。
Step1：要件定義・RFP（提案依頼書）の作成
RFP（Request for Proposal、提案依頼書）は、発注側がベンダーに対してプロジェクトの概要・要件・期待成果・評価基準を示す文書です。RFPの精度が低いと、複数ベンダーから届く提案の比較ができません。
最低限含めるべき項目は「対象OS（iOS/Android/両対応）」「主要機能一覧」「ターゲットユーザー」「非機能要件（レスポンス・セキュリティ・対応デバイス）」「希望納期」「予算感（目安）」「既存システム連携の有無」です。
Step2：ベンダー選定・契約
RFPをもとに2〜3社に絞り込み、提案書・見積もりを受け取ります。比較の際は金額だけでなく「開発体制図」「担当者のスキルセット」「過去の類似プロジェクト実績」を確認します。
契約締結の際は「知的財産権の帰属（ソースコードの権利が発注側に移転するか）」「瑕疵担保（契約不適合責任）期間」「再委託の可否と条件」「秘密保持契約（NDA）」を契約書に盛り込むことが大切です。
Step3：設計・プロトタイピング
詳細設計（画面設計・DB設計・API仕様）とプロトタイプ（動作するUIのモック）を作成する段階です。この段階で発注側が積極的にレビューに参加することで、開発後の大規模修正を防げます。
特にiOSはHuman Interface Guidelines（HIG）、AndroidはMaterial Designのガイドラインに準拠した設計を確認することが、App Store/Google Play審査のスムーズな通過につながります。
Step4：開発・テスト・ストア審査
実装・単体テスト・結合テスト・ユーザー受け入れテスト（UAT）の工程です。iOSはTestFlight（Appleのテスト配信プラットフォーム）、AndroidはGoogle Playの内部テストトラックを使ってベータ版を配布し、実機での動作確認を行います。
ストア審査では、プライバシーポリシーの掲載・権限取得の説明（カメラ・位置情報等）・コンテンツポリシーへの準拠が審査通過の前提条件となります。審査リジェクトが発生すると修正対応に数日〜数週間かかることもあるため、余裕あるスケジュールが必要です。
Step5：リリース・成果物の引き渡し
公開後はソースコードリポジトリ（GitHubなど）の権限移管、ビルド証明書・署名キーの引き渡し、運用手順書・テクニカルドキュメントの受領を行います。これらを受け取らずに契約を終えると、次の改修委託や内製化への移行が困難になります。
リリース後の継続保守（OS新バージョン対応・バグ修正・機能追加）を同一ベンダーに委託するかを、初期契約段階から検討しておくことが大切です。保守フェーズの費用体系については別途見積もりを取ることをお勧めします。
委託で起きやすい3つの失敗と事前対処法
ネイティブアプリの委託では、要件齟齬・仕様変更・知的財産の3点が典型的なトラブル要因です。いずれも契約前と要件定義段階での取り決めで大部分を防げます。
失敗1：要件の認識齟齬でスコープが拡大し、工期・費用がずれる
「検索機能を追加してほしい」という要件に対して、発注側は「キーワード検索だけ」をイメージし、ベンダーは「フィルタリング・並べ替え・履歴保存を含む」と解釈した場合、工数に大きな差が生じます。これがスコープクリープ（当初の範囲が膨らむ現象）の典型です。
対処法は「画面単位・機能単位の受け入れ基準をRFP段階で文書化する」ことです。各機能に「完了の定義（Definition of Done）」を明記し、追加・変更の際は変更管理票を発行するルールを契約に盛り込むことで、費用の明確化が期待できます。
失敗2：途中の仕様変更が口頭合意のままになり追加費用が不透明になる
開発中にユーザーテストの結果を受けてUI変更を行う場合、変更規模によっては設計・実装の大幅な修正が必要になります。口頭合意のまま変更を進めると、完成後に追加費用の金額で合意できないケースが生じます。
対処法として、変更要求は書面（チャットでも可）で記録し、影響範囲・工数・追加費用の見積もりを書面で確認してから承認するプロセスを確立しておくことが大切です。
失敗3：成果物のソースコードの権利が不明確なままになる
委託開発では、契約書に「著作権は発注者に帰属する」と明記しない限り、著作権法上の原則ではベンダー（創作者）に権利が残る解釈が成立し得ます。ソースコードの権利が移転していない場合、後から改修を別ベンダーに依頼する際に支障が生じる可能性があります。
契約書には「著作権（著作者人格権の行使制限を含む）・特許その他の知的財産権の発注者への譲渡」と「第三者の知的財産を侵害しないことの表明保証」を明記することが重要です。ソースコードのライセンス（OSSの利用有無・ライセンス条件）についても事前に確認しておくことをお勧めします。
内製と委託：必要なスキル・工数の比較
ネイティブアプリを内製で開発する場合に必要な専門知識は、iOSとAndroidで独立して存在します。内製可否の判断材料として整理します。
内製に必要な専門知識の全体像
iOSの内製開発には「Swift言語・SwiftUIの習熟」「Xcode環境の構築・管理」「App Store Connect（ストア申請ポータル）の操作」「TestFlightによるベータ配布」「Appleの審査ガイドラインの理解」が求められます。
Androidの内製開発には「Kotlin・Jetpack Composeの習熟」「Android Studio環境の管理」「Google Play Consoleの操作」「各Androidバージョン・デバイス断片化への対応」「Google Playポリシーの理解」が必要です。
さらに両者共通の知識として「REST APIの設計・連携」「プッシュ通知（APNs/FCM）」「セキュリティ実装（認証・暗号化）」「UI/UXデザイン」が挙げられます。両OS対応の場合、これらのスキルを持つ人材を2系統確保する必要があります。
内製リスクと外注で省力化できる領域
経済産業省の「IT人材需給に関する調査」（2019年）では、2030年には約79万人規模のIT人材が不足するとの推計が示されています（同調査の上位シナリオ）*1。Swift・Kotlinのエンジニアは採用市場での競争が激しく、即戦力を採用するには採用活動に半年以上かかる場合もあります。
委託（外注）することで「採用・育成コスト」「開発ツールのライセンス費用」「Appleデベロッパープログラム・Googleの開発者登録の管理工数」「ストア審査対応の専門知識習得」を省力化できます。一方で、委託先の管理・コミュニケーション工数は発注側に残ります。
プロジェクト規模の目安として、一般的なiOS/Androidアプリ（ログイン・一覧・詳細・プッシュ通知程度の機能構成）では、ベンダー側に3〜5名規模の開発チームが必要になるケースが多いとされています。ただし規模・機能複雑度によって大きく変わるため、出典のある数値ではなく参考情報として位置づけてください。
まとめ：委託を成功に導く3つの判断軸
本稿では、iOSアプリ（Swift）・Androidアプリ（Kotlin）のネイティブ開発を委託する際の実務を整理しました。要点を3点に集約します。
第一に「要件の精度がすべての起点」です。RFPと機能単位の完了定義を整備することが、スコープクリープと追加費用トラブルを防ぐ前提条件となります。第二に「契約書の3点確認（知的財産権・瑕疵担保・再委託条件）」です。これらを見落とすと、後続の改修委託や内製化移行の際に余分なコストが発生します。第三に「委託先の評価は技術実績・管理体制・コミュニケーション方式の3軸」です。単価だけで選ぶと、プロジェクト中盤以降の摩擦が大きくなりやすいため、体制面の確認が重要です。
費用感・コスト比較についてはiOS/Android両対応アプリの開発費用を扱った別記事を参照してください。
よくある質問
iOSとAndroid、どちらから先に委託するのが現実的ですか？
ターゲットユーザーのデバイス比率で判断するのが一般的です。日本国内ではiOSユーザーの比率が高い傾向がありますが、BtoB向けの社内アプリではAndroidデバイスの支給が多いケースもあります。先行してiOSでMVPをリリースしてユーザーフィードバックを得てからAndroidを開発するという進め方も選択肢の一つです。両OS同時リリースを目指す場合は、クロスプラットフォーム開発との比較検討もお勧めします。
委託費用の相場を教えていただけますか？
ネイティブアプリの委託費用は機能の複雑度・対応OSの数・デザイン品質・開発期間によって大きく異なります。費用の目安・構成要素についてはiOS/Android両対応アプリ開発の費用比較を扱った別記事で詳しく解説していますので、そちらを参照してください。費用の概算を得るためには複数ベンダーへのRFP発行と見積もり取得が現実的な方法です。
委託先に渡す仕様書はどの程度まで作り込む必要がありますか？
最低限「機能一覧（何ができるか）」「画面遷移の概要（ワイヤーフレームまたはスケッチ）」「非機能要件（対応OSバージョン・パフォーマンス目標）」「外部連携の有無（APIやバックエンドの概要）」があれば、ベンダーからの見積もり取得は可能です。設計書の詳細度が高いほど見積もりの精度と要件認識のブレが減りますが、詳細を詰める作業そのものをベンダーと共同で行う「要件定義フェーズ契約」を先行させる方法もあります。
開発途中で仕様変更が生じた場合はどうすればよいですか？
仕様変更が生じた場合は、まず変更内容と影響範囲を書面（メール・チャット記録）で共有し、ベンダーから追加工数・費用・スケジュール影響の見積もりを取得します。承認後に変更着手という変更管理プロセスを確立しておくことが大切です。請負契約の場合は変更契約書を締結します。準委任契約では月次精算型であれば変更工数を追加計上する形で対応できます。口頭のみの合意はトラブルの原因になるため、書面での記録を徹底することをお勧めします。
委託開発で作成したソースコードの権利はどちらに帰属しますか？
日本の著作権法では、契約に別段の定めがない限り著作権はベンダー（創作者）に帰属する解釈が成立し得ます。発注側がソースコードの著作権を取得するには「著作権（著作者人格権の行使制限を含む）を発注者に譲渡する」旨を契約書に明記することが必要です。契約締結前に法務担当者またはITに詳しい弁護士に確認することをお勧めします。OSSライブラリを使用している場合は、各ライセンス（MIT・Apache等）の条件が別途適用されます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：経済産業省「IT人材需給に関する調査」（2019年）
