モバイルエンジニアを外注する方法｜iOS/Android費用相場と選び方

「モバイルアプリで新規事業を立ち上げる」「既存Webサービスのスマホ版を出す」――経営会議でこうした方針が決まった直後、多くの発注担当者が最初に直面するのがモバイルエンジニアの外注戦略を1週間以内に組み立てる、というタスクです。Webサイトや業務システムの発注経験があっても、モバイル領域では勝手が大きく異なります。

モバイルアプリ開発が難しいのは、iOS と Android の両OSに対応する必要があり、App Store・Google Play の審査を通過しなければ公開できず、リリース後もOSアップデートやストア規約変更に追従し続けなければならないという、Web システムにはない構造的な特性を持つためです。発注先の選択肢も「フリーランス／中小開発会社／大手開発会社／オフショア」と幅広く、費用レンジも人月40万〜160万円と3〜4倍の開きがあります。

こうした前提を整理しないまま相見積もりを進めると、「同じ機能要件なのに提示金額が数倍違う」「安く発注できたが保守運用が回らない」「iOSは動くがAndroidが不安定」といった典型的な失敗パターンに陥りがちです。上申資料に貼れる費用レンジ表と、外注先タイプ別のフィット判断軸を先に整えておくことが、発注担当者としての最初の仕事になります。

本記事では、モバイルエンジニアの外注を検討する発注者向けに、モバイル特有の特殊性の言語化、外注先タイプ4分類の選び方、iOS/Android別・技術選定別の費用相場、RFPから契約までの発注フロー、そしてモバイル特有の失敗を避ける注意点までを一連の意思決定フローとして整理します。読み終えたときには、自社の条件に照らして外注先タイプの候補が2〜3に絞れ、上申資料の骨子と相見積もりで確認すべき項目リストが手元にある状態を目指します。

モバイルエンジニアの外注が難しい理由と発注前の前提整理

モバイルエンジニアの外注は、Web システムや業務システムの外注とは異なる構造的な難しさを抱えています。この特殊性を最初に言語化しておかないと、要件定義や見積比較の際に「何を確認すべきか」の判断軸が持てません。

Webシステム外注との3つの違い（両OS対応・審査・OSアップデート）

モバイルアプリ開発が Web システム開発と本質的に異なる点は、大きく次の3つに集約されます。

第1に、iOS と Android の2つのOSに対応する必要がある点です。Web ならブラウザ差異はある程度吸収できますが、モバイルではネイティブ開発の場合、Swift（iOS）と Kotlin（Android）で実質的に2つのアプリを作ることになります。仮にクロスプラットフォーム（Flutter・React Native）を選んでも、OS固有の機能（プッシュ通知の挙動、生体認証、決済等）はプラットフォーム別の実装が必要になります。

第2に、App Store および Google Play の審査プロセスを経ないと公開できない点です。Apple の App Store Review Guidelines は年に複数回更新され、プライバシー要件（App Tracking Transparency、プライバシーマニフェスト等）や機能要件が厳格化される傾向にあります（App Store Review Guidelines - Apple Developer）。Google Play も同様にポリシー改訂が頻繁で、対応漏れがあると公開停止になります。Web システムでは自社サーバーにデプロイすれば済むところが、モバイルでは「第三者の審査に合格する」というゲートを通過する必要があります。

第3に、OSのメジャーアップデートに毎年追従する必要がある点です。iOS は毎年秋、Android も年次でメジャーアップデートがあり、新API対応やUI変更、非推奨APIの置き換えが継続的に発生します。Web のように「動いているものをそのまま置いておく」ことができず、放置すると数年で起動しなくなる、あるいはストアから削除されるリスクがあります。

これらの特殊性を発注前に理解しておくことで、「初期開発費だけでなく継続運用の予算も見込む」「OSアップデート追従を契約に含める」といった判断ができるようになります。

発注前に決めておくべき4つの前提条件

外注先を探し始める前に、社内で以下の4項目を確定させておくことを推奨します。この情報がないまま複数社に問い合わせても、見積の粒度が揃わず比較検討が困難になります。

1. iOS/Android 両対応の要否: ターゲットユーザーのOSシェアを踏まえ、iOS のみ、Android のみ、両対応のいずれかを決めます。日本国内向け BtoC アプリは iOS シェアが高い傾向にありますが、業界・年齢層で大きく変わります。両対応の場合は開発費が単純に2倍近くなるため、リリース初期は片OS先行という選択肢も現実的です。
2. 機能規模の目安: 「認証・プロフィール表示・一覧・詳細」のみのMVPか、決済・地図・プッシュ通知・チャット・オフライン対応まで含む中〜大規模かで、費用レンジが1桁変わります。機能一覧を粗い粒度でよいので書き出しておきます。
3. 希望リリース時期: 3ヶ月以内か、6ヶ月か、1年以内かで採用可能な外注先タイプが変わります。フリーランス単独では大規模アプリを短納期で作るのは困難で、逆に大手開発会社は小規模案件を短納期で受注しない傾向があります。
4. リリース後の保守運用体制: 「開発会社に継続委託」「別会社に移管」「自社エンジニアで内製化」のいずれを目指すかで、契約時の成果物範囲・ドキュメント要件・技術選定が変わります。この項目は見落とされがちですが、後述の失敗事例の多くがここに起因します。

見落としがちなストア掲載後の運用要件

上記に加えて、ストア公開後に継続的に発生する運用要件を発注前に認識しておく必要があります。具体的には、iOS/Android のOSメジャーアップデートへの対応（年1回×2OS）、App Store・Google Play の規約改訂対応（不定期・年数回）、開発者アカウント・証明書・APIキーの更新管理（年次〜数年ごと）、脆弱性が発見されたライブラリの差し替えなどが挙げられます。

これらは「新機能開発」ではないため見積書に載りにくいのですが、放置するとアプリがストアから削除されたり起動しなくなるリスクがあります。年間の運用保守費用は開発費の10〜20%が一般的な相場とされます（アプリ開発費用相場（発注ナビ））。ただしモバイルアプリは Web システムと異なり OS メジャーアップデートへの追従が毎年発生するため、この目安の上限側（20%程度）に寄せて予算化する、あるいは大規模な UI 刷新や機能追加を含める場合はそれ以上を見込む前提で計画するのが安全です。

モバイルエンジニアの外注先タイプと選び方

モバイルエンジニアの外注先は、大きく「フリーランス／中小開発会社／大手開発会社／オフショア」の4タイプに分類できます。それぞれの特性を横並びで理解したうえで、自社の条件に合うタイプを選ぶ必要があります。

外注先タイプ4分類の特徴比較

以下は各タイプの一般的な特性を整理したものです。同じタイプ内でも個社差は大きいため、あくまで初期スクリーニングの目安として使ってください。

人月単価の目安値は複数の相場記事の平均的な水準を参考にしています（アプリ開発費用相場（発注ナビ） / アプリ開発費用の相場（システム幹事））。

フリーランスに向いているケース／向かないケース

フリーランスのモバイルエンジニアを起用するのが向いているのは、社内にプロダクトマネージャー（PM）・デザイナー・技術リード相当がいて、実装工数だけを外部に切り出したいケースです。既存アプリの追加機能開発、社内スペシャリストと並走する新規機能開発、MVP検証フェーズの小規模開発などが代表例です。単価は中小開発会社よりも抑えられる場合が多く、意思決定スピードも早い傾向にあります。フリーランス側の実勢単価をより細かく把握したい場合は、iOS/Android別の月収レンジを整理したモバイルエンジニアのフリーランス単価相場（iOS/Android別）を発注前の相場感チェックに活用してください。

一方で、フリーランス単独に「設計から運用まで丸ごと」を委ねるのは避けるべきです。仕様策定・デザイン・テスト計画・リリース作業までを1人でこなせる人材は少なく、契約期間中の急な離脱リスクも構造的に存在します。上流工程を担える体制が社内にない場合は、次に紹介する中小開発会社を第一候補にする方が現実的です。

中小開発会社に向いているケース／向かないケース

中小開発会社は、要件定義から設計・実装・テスト・リリース・初期運用までを一貫して任せられる点が最大の特徴です。モバイル領域では、iOS/Android の両方に対応できるエンジニアを内部に抱えている中小開発会社が多く、中規模までのアプリを一気通貫で発注したい場合の第一候補になります。人月単価はフリーランスより若干高い傾向がありますが、上流工程・進行管理・品質保証まで含めた総コストで見ると、社内でPMを立てる場合よりも合理的なケースが多くあります。

向かないのは、複数チーム編成が必要な超大規模プロジェクトや、既存の大規模基幹システムと密結合するモバイルアプリの新規開発です。プロジェクトマネジメント能力・並行開発体制・エンタープライズ品質保証の観点で、次に紹介する大手開発会社の方が適合する場合があります。

大手開発会社・オフショアに向いているケース／向かないケース

大手開発会社（SIer含む）は、複数チーム編成が必要な大規模開発、既存基幹システムとの連携が複雑なケース、エンタープライズレベルのセキュリティ・監査要件があるケースに適しています。人月単価は高く、初動も遅い（体制構築に1〜2ヶ月かかることも珍しくない）ですが、長期の保守契約や大規模障害対応の体制で強みがあります。逆に、MVP検証フェーズや小〜中規模の新規事業には過剰な体制になりがちで、費用対効果が合いません。

オフショア（ベトナム・インド・フィリピン等）は人月単価を抑えられる点が最大の魅力ですが、日本側にブリッジSE兼PMを配置し、要件定義・仕様書・受入テスト計画を日本語で緻密に作れる体制が前提になります。「仕様書を英訳して丸投げすれば安く上がる」という発想では品質が確保できません。過去に社内でモバイル開発を経験したメンバーがいて、体制設計と日々のブリッジコミュニケーションを内製できる企業には有力な選択肢です。

自社条件別のフィット判断表

上記の特性を、自社の予算・スピード・機能規模の3軸で整理したフィット判断表を示します。上申資料の候補選定の根拠として使えます。

「予算1,500万円以上 × 大規模 × 3ヶ月以内」のセルは、現実的にはリリース時期の見直しか、スコープ縮小によるMVP化を検討したほうが合理的です。

モバイルエンジニア外注の費用相場（iOS/Android別・技術選定別）

費用相場は「人月単価」「機能規模別総額」「技術選定別」「iOS/Android別」「運用保守費用」の5つの切り口で整理すると、見積書の妥当性を判断しやすくなります。

モバイルエンジニアの人月単価相場

外注先タイプ別のモバイルエンジニアの人月単価目安を、実勢の相場記事を参照して整理します。個人のスキルレベル・案件難易度・契約形態（準委任・請負）で変動します。

フリーランスのモバイルエンジニアの単価水準について、iOS/Android別の月収目安を詳しく確認したい場合はモバイルエンジニアのフリーランス単価相場（iOS/Android別）で整理しています。Android側の週稼働別月収目安はKotlinフリーランスAndroid案件の単価相場、iOS側の技術別差分はSwift/iOSフリーランス単価とFlutter経験の差別化戦略を、それぞれ相見積もりの相場感チェックに使ってください。

機能規模別のアプリ開発総額レンジ

新規モバイルアプリを外注する際の総額レンジは、一般的な相場記事では以下のように整理されています（アプリ開発費用の相場（システム幹事））。

同じ「中規模」でも、決済（Apple Pay / Google Pay / PSP連携）やチャット（自前実装 vs 外部SaaS利用）の選択で数百万円単位の差が出ます。相見積もりでは、単純な総額比較ではなく、機能ごとの内訳金額を並べて比較することが重要です。

ネイティブ（Swift+Kotlin）vs クロスプラットフォーム（Flutter/React Native）の費用差

技術選定は費用に直接影響する重要な判断項目です。iOS/Android 両対応を前提とした場合の主な選択肢は次の3つに整理できます。

• ネイティブ2本立て（Swift + Kotlin）: iOS 版・Android 版を別々に実装します。OS 固有機能の実装が最もスムーズで、パフォーマンスも最適化しやすい反面、開発工数は実質2倍近くになります。両OS でリッチな体験を提供したい BtoC アプリ、パフォーマンスがシビアなゲーム・映像系に向きます。
• Flutter: Google が開発しているクロスプラットフォームフレームワークで、単一コードベースから iOS/Android の両アプリを生成します。ネイティブ2本立てと比較して、開発工数を6〜7割程度に圧縮できるケースが多く見られます。UI の統一感が高く、パフォーマンスも実用水準に達しています。Flutter エンジニアの単価水準や案件の実勢はFlutterフリーランス案件の単価相場で整理しているため、見積の妥当性判断に活用できます。
• React Native: Meta が開発しているクロスプラットフォームフレームワークで、Web エンジニア（React経験者）が参画しやすいのが強みです。既存の Web エンジニアリング資産・チームを活かしたい場合に候補になります。

クロスプラットフォームは万能ではありません。決済・生体認証・プッシュ通知・カメラ・センサー等のOS固有機能を深く使うアプリでは、結局OS固有のネイティブモジュールを書く必要が出て、想定より工数が膨らむケースがあります。技術選定は「機能要件のうち何%がOS固有機能に依存するか」を軸に判断するのが実務的です。Swift ネイティブと Flutter を横並びで比較した際の単価差・案件特性はSwift/iOSフリーランス単価相場｜Flutter経験を活かす差別化戦略で扱っており、技術選定と費用の関連付けに役立ちます。

iOS単独・Android単独・両対応それぞれの費用感

同じ機能規模でも、対応OS範囲によって総額は大きく変わります。片OS単独でネイティブ開発する場合を基準（1.0倍）とすると、次のような相対関係になります。

片OS先行リリース→もう一方のOSを後追い開発、というアプローチは、初期投資を抑えながら市場検証を進めたいケースで有効です。ただし後追い時に「ネイティブで作った資産をクロスプラットフォームに置き換える」ような選択をすると、実質的に作り直しになるため、初期段階で技術選定を確定させることが重要です。Android 単独で先行リリースする際の Kotlin エンジニア相場はKotlinフリーランスAndroid案件の単価相場と週3月収の目安を参照してください。

見落としがちな運用保守費用（年間20%前後）と追加開発費用

初期開発費と同じくらい重要なのが、リリース後の運用保守費用です。一般的な相場では、年間の運用保守費用は初期開発費の10〜20%とされ、モバイルアプリの場合はOSアップデート対応が毎年発生するため、この目安の上限側（20%程度）を基準に予算化するのが安全です。大規模な UI 刷新や機能追加を継続する場合は、これに追加開発費を上乗せする形で年30%程度まで見込むケースもあります。

運用保守の内訳には、iOS/Android の新OSバージョン対応、App Store・Google Play の規約改訂対応、ライブラリ・SDKのバージョンアップ追従、軽微な不具合修正、証明書・APIキーの更新管理、モニタリング・障害対応などが含まれます。「新機能追加」は別途「追加開発費用」として見積もることが多く、月次・四半期単位のリテイナー契約（月額固定枠）を組むケースも一般的です。

モバイルエンジニアの探し方と発注までの流れ

外注先の探し方には代表的な4経路があります。それぞれの特性を理解したうえで、RFP 作成から契約までの発注フローを整えます。

モバイルエンジニアの探し方4経路の比較

モバイルアプリの外注は要件が複雑になりがちなため、クラウドソーシング単体で完結させるのは小規模案件に限る方が安全です。中〜大規模案件は、マッチングサービスまたはエージェント経由で3〜5社に相見積もりを依頼するのが標準的な進め方です。

RFP（提案依頼書）に最低限盛り込むべき項目

相見積もりの精度を上げるには、RFP（提案依頼書）で「同じ前提」を提示することが不可欠です。モバイルアプリ外注のRFPには、最低限次の項目を含めることを推奨します。

• プロジェクトの背景・目的: なぜこのアプリを作るのか、事業上のゴールは何か
• ターゲットユーザー・利用シーン: 想定ペルソナ、利用頻度、主な利用シナリオ
• 対応OS範囲: iOS のみ／Android のみ／両対応、対応バージョンの下限
• 機能一覧: 必須機能・任意機能を優先度付きで整理
• 非機能要件: パフォーマンス（起動時間・レスポンス）、セキュリティ、可用性、想定同時利用者数
• 希望リリース時期: マイルストーン、絶対に外せない日付があるか
• 予算レンジ: 想定予算の上限・下限（明示するのが望ましい）
• 保守運用の範囲・期間: リリース後の想定保守体制、契約更新条件
• 成果物・納品物: ソースコード、設計書、テスト結果、開発者アカウント権限
• 既存資産・制約: 既存Webサービスとの連携、既存デザインシステム、業界規制
• デザイン要件: 既存デザインシステムの有無、想定するデザイン粒度（ワイヤー／ハイフィデリティ）、UI設計工程の担当分担

デザイン粒度・UI設計工程の担当分担は、発注後に「デザインは別途」と切り出されて追加費用が発生しやすい領域です。モバイル特有のUI設計論点（画面遷移・ジェスチャー・タブ／スタック構造・ダークモード対応・アクセシビリティ等）と工数の目安はモバイルアプリのUI設計とは？発注者が知るべき工程・費用にまとめています。

RFP を先に整えると、次の相見積もりフェーズで比較すべき軸が定まり、各社の提案を「同じ土俵で」評価できるようになります。

相見積もりで確認すべき見積書の内訳項目

複数社から見積書を受領したら、総額だけでなく内訳を確認します。特にモバイル案件で注視すべき内訳項目は次のとおりです。

• 要件定義・設計工数: どの粒度まで含むか（画面設計・API設計・DB設計・非機能設計）
• iOS 実装工数と Android 実装工数の内訳: 両OS対応の場合、片方に工数が偏っていないか
• テスト工数: 単体テスト・結合テスト・受入テストの範囲、実機検証の対象機種
• リリース対応工数: App Store・Google Play への申請・審査対応、リジェクト時の再申請対応
• 予備・バッファ: 見積工数のうちバッファがどの程度含まれているか
• 成果物ドキュメント: 設計書・API仕様書・運用手順書がどこまで含まれるか
• 保守運用フェーズの見積: 月額 or 都度、対応時間帯、SLA、対応スコープの明示

同じ機能一覧でも、テスト工数・リリース対応工数・ドキュメント成果物の粒度で総額が数百万円ずれることは珍しくありません。「一式」「別途相談」が多い見積書は、後工程で追加費用が発生するリスクが高いため注意が必要です。

契約時に確認すべき保守・仕様変更・成果物権利の3ポイント

契約段階では、次の3ポイントを必ず条項として明文化しておくことを推奨します。

1. 保守運用の範囲と期間: リリース後の保守がどこまで含まれるか（バグ修正のみか、OSアップデート対応も含むか）、期間、対応時間帯、月次リテイナーの内容
2. 仕様変更・追加開発の扱い: 契約範囲内で対応する軽微な変更と、追加見積が必要な仕様変更の境界、追加見積の単価と提示プロセス
3. 成果物の権利帰属と引き渡し範囲: ソースコード・設計書・開発者アカウント・APIキー・第三者ライブラリのライセンス情報の帰属と引き渡し。将来別会社に移管する可能性を残したい場合は、この条項が特に重要です

3点目の成果物権利は、将来の外注先変更・内製化・M&Aなどのシナリオで大きな影響を持ちます。「動くアプリだけ納品されて、ソースコードは開発会社所有」といった契約は、モバイルアプリでは避けるべきです。契約直前に確認すべき論点を10項目に整理したチェックリストは外注エンジニアとの初回ミーティングで決める10項目｜発注者チェックリストにまとめているため、契約前打ち合わせの叩き台として活用してください。

モバイルエンジニア外注で失敗しないための注意点

モバイル特有の失敗事例は、Webシステム外注の教訓では捉えきれない領域が多くあります。ここでは代表的な4つのカテゴリを整理します。

iOS審査リジェクトのよくあるパターンと発注時の予防策

App Store Review Guidelines は年に複数回更新されており、リジェクト理由も年々多様化しています。頻出パターンは次のとおりです。

• プライバシー要件の不備: App Tracking Transparency（ATT）の実装漏れ、プライバシーマニフェスト（PrivacyInfo.xcprivacy）の未対応、必要な使用目的説明（NSCameraUsageDescription等）の未記載
• サブスクリプション課金の実装ミス: 定期課金の説明画面、キャンセル方法の明示、価格変更時の通知フロー
• サインイン方式の縛り: 他社SNS認証を提供する場合の「Sign in with Apple」併用要件
• 未成年ユーザー保護: 年齢確認、保護者同意フロー、広告配信の制限

発注時の予防策としては、RFP に「App Store Review Guidelines および Google Play ポリシーの遵守を成果物の要件に含む」旨を明記し、リジェクト時の再申請対応が見積範囲に含まれることを確認します。過去に App Store のプライバシー要件対応実績があるかを提案書の実績欄で確認するのも有効です。

OSアップデート（iOS/Android）追従を契約に織り込む方法

iOS・Android のOSメジャーアップデートは毎年発生します。開発時点の最新OSに対応するだけでは、翌年には「新OSで一部機能が動作しない」「非推奨APIを使い続けているとストアから警告される」といった問題が発生します。

契約に織り込む方法としては、次のいずれかのパターンが実務的です。

• 年次OS対応リテイナー契約: 毎年の新OSリリース時期（秋前後）に、対応工数枠を月額に含める
• OSアップデート対応の別途見積スキーム: 契約時点で単価とプロセスを合意し、都度発注する
• 社内内製化への移管条件: 一定期間後に内製化する前提で、ドキュメント引き渡しとナレッジ移管を段階的に実施する

「バグ対応は含むが、OSアップデート対応は含まない」という契約になっているケースが多く、リリース後1〜2年で追加費用が発生するのが典型的な失敗パターンです。契約書のスコープ条項を発注前に必ず確認します。

ストア規約変更・ガイドライン改訂への対応体制

App Store と Google Play は、プライバシー保護・広告表示・課金方式・データ利用等について、年数回のポリシー改訂を行います。改訂後、既存アプリにも遡って対応が求められるケースがあり、期日までに対応しないとアプリの更新公開が差し止められる、あるいは既存公開が停止されるリスクがあります。

対応体制の作り方としては、以下を発注前に確認しておきます。

• 開発会社側でストアポリシー改訂のウォッチ体制があるか（誰が、どの頻度で、どのようにキャッチアップしているか）
• 改訂通知後の対応工数は誰の負担になるか（月次リテイナー内か、別途見積か）
• 対応期日までのプロセス（改訂通知→影響分析→見積提示→実装→再申請）が定義されているか

大手開発会社は社内でポリシー改訂のウォッチ体制を持っているケースが多く、中小開発会社・フリーランスの場合は「発注側からポリシー情報を共有する」ワークフローを設計する必要があるかもしれません。

継続的な機能改善・保守運用のための体制設計

モバイルアプリは「リリースがゴール」ではなく「リリースがスタート」です。ユーザーフィードバックに基づく機能改善、A/Bテスト、パフォーマンス改善、離脱率改善、決済フロー最適化などが継続的に発生します。

継続的な体制設計としては、次のような選択肢を発注前に検討します。

• 月額リテイナー契約: 月あたりの対応工数枠を確保し、優先度の高いタスクから消化する
• プロジェクト単位の追加発注: 大型機能追加は都度プロジェクト化する
• 社内エンジニアとの併走: 開発会社に主幹を任せつつ、社内エンジニアを段階的にキャッチアップさせる
• 内製化への計画的移管: 開発会社と協業しつつ、期限を切って内製チームに引き継ぐ

「作って終わり」の契約にしてしまうと、リリース後に「軽微な改善のたびに新規プロジェクト起票→見積→承認→発注」の重い手続きが発生し、機動的な改善が回らなくなります。継続改善のペースを想定した体制設計を、契約時に組み込むことを推奨します。

まとめ｜モバイルエンジニア外注を成功させるためのチェックリスト

本記事では、モバイルエンジニアを外注する際に必要な意思決定フローを、モバイル特有の特殊性・外注先タイプの選び方・費用相場・発注フロー・失敗を避ける注意点の順に整理しました。上申資料の骨子と相見積もりの準備に、以下のチェックリストを活用してください。

発注前の前提整理

• iOS/Android のどちらに対応するか（片OS先行か、両対応か）を決めた
• 機能規模の粗い一覧（MVP機能・追加機能候補）を書き出した
• 希望リリース時期と、絶対に外せないマイルストーンを明確にした
• リリース後の保守運用体制（継続委託／内製化）の方向性を決めた

外注先タイプの絞り込み

• 予算×スピード×機能規模の3軸でフィット判断表を確認し、候補タイプを2〜3に絞った
• 各タイプの人月単価レンジと、社内で許容できる範囲を突き合わせた
• 上流工程（要件定義・PM）を内製で担うか、外注に含めるかを決めた

費用相場の把握

• 人月単価レンジ（フリーランス60〜120万円／中小80〜150万円／大手120〜200万円／オフショア30〜80万円）を上申資料に貼れる形にした
• 機能規模別の総額レンジ（小規模100〜300万円／中規模300〜1,000万円／大規模1,000万円〜）を把握した
• 技術選定（ネイティブ vs Flutter/React Native）の費用差を理解した
• 運用保守費用を年間20%前後（大規模改修を含める場合は30%程度）で予算化した

発注プロセスの準備

• RFPの必須項目（背景・機能一覧・OS範囲・非機能要件・予算レンジ・デザイン要件等）を洗い出した
• 相見積もりで確認する内訳項目（設計工数・iOS/Android別実装工数・テスト・リリース対応・ドキュメント）を整理した
• 契約時に明文化する3ポイント（保守範囲・仕様変更・成果物権利）を確認した

モバイル特有の落とし穴の予防

• App Store・Google Play の審査要件遵守を成果物要件に含めた
• OSアップデート追従の対応スキームを契約条件に含めた
• ストア規約改訂のウォッチ体制を確認した
• 継続的な機能改善のための体制設計（リテイナー／内製化計画）を組み込んだ

モバイルエンジニアの外注は、Webシステム外注と比べて論点が多く、初回発注では判断に迷う場面が続きます。本記事のチェックリストを叩き台として、自社の条件に合わせてカスタマイズしながら、上申資料と相見積もりの準備を進めていただければと思います。