LASSIC Media らしくメディア

LASSIC IT事業部｜プライムベンダーとしてシステム保守・運用を受託

androidアプリ開発外注とは｜契約段階で握るべき検証範囲とAPIレベル

androidアプリ開発外注とは、自社のアプリ開発に必要な工程の一部または全部を外部の開発会社・専門ベンダーに依頼する取り組みである。総務省「令和6年版 情報通信白書」では国内のスマートフォン世帯保有率が90.6%だったと報告されている^*1。Android利用者向けのアプリ需要は引き続き拡大している。外注は単なる人手の補完ではありない。Google Playの審査要件・端末分裂への対応・継続リリース体制までを含めた専門力の調達手段として位置づけられる。

AndroidアプリはAPIレベル並存と継続リリース体制が契約設計を左右する

androidアプリ開発では、Googleの公式情報でも複数のAPIレベルが並存していると整理されています^*2。外注先がどの端末・どのAPIレベルを検証対象とするかを契約段階で握ることは、品質と費用の両面で大きな影響を持つ。Google Playの審査要件・プライバシーポリシー対応・ターゲットAPIレベル要件は定期的に更新されるため、継続リリース体制を前提とした契約設計が要件となる。

外注検討の背景は「人材確保・専門知識・事業スピード」の3課題

androidアプリ開発外注が検討される背景には「人材確保の困難」「専門知識の不足」「事業スピードの要請」の3課題がある。経済産業省「IT人材需給に関する調査」（2019年公表）では2030年に最大約79万人のIT人材不足が見込まれている^*3。さらにIPA「DX動向2025」によると、日本企業の85.1%が「DXを推進する人材が大幅に不足／やや不足」と回答しており、米国の23.8%・ドイツの44.6%を大きく上回る水準で推移している^*4。自社のみでAndroid開発人材を継続的に確保する難易度は構造的に高い。

Kotlin・Java実務経験者の母集団は限定的で内製のみのスピード担保は現実的でない

Android開発に必要なKotlin・Java・Jetpack Composeの実務経験者は、母集団そのものが限定的である。IPA「DX動向2025」では、DXを推進する人材の量・質ともに大幅な不足が継続して報告されており^*4、開発系人材の獲得難は構造的な状況にある。求人を出しても応募が集まらない、採用できても定着しないというケースでは、内製のみで開発スピードを担保することが現実的でなくなる。

審査要件・プライバシー設計・SDK連携の専門家を社内のみで継続確保するのは困難

androidアプリ開発では、多領域の専門知識が必要である。Google Playの審査ガイドライン、ターゲットAPIレベル要件、改正個人情報保護法に対応したプライバシー設計、各種SDK連携などが該当する。これらを社内のみでカバーするには、複数の専門家を継続的に確保する必要があり、事業規模に応じた人件費負担が発生する。

採用リードタイムによる機会損失を回避するため外注で先行リリースを確保する

市場投入のタイミングが事業成否を左右する場合、内製で人材確保から始めると採用リードタイムだけで機会損失が拡大する。外注を活用することで、要件定義から先行リリースまでの期間を圧縮でき、競合先行を回避できる。

状況別の外注パターンは4類型｜一括／部分／保守運用／オフショア

androidアプリ開発外注のパターンは、自社の事業フェーズと内製チームの状態によって以下の4類型に整理できる。

外注成功の共通要因は3点｜契約前文書化・Android要件理解・障害時の責任分界

状況に関わらず外注の成功確率を引き上げる要因は、以下の3点に集約できる。本節では「事前に何を握るか」、次節では「握れていないと何が起こるか」をペアで整理する。

検証範囲と納品物リストを契約前に文書化することで後工程の認識ズレを抑える

検証対象端末・OSバージョン・主要シナリオを契約段階で文書化することは、品質と費用の両面で大きな影響を持つ。納品物リスト・引き継ぎ条項・ソースコードの帰属先まで合意しておくことで、後工程の認識ズレを抑えられる。納品物リストに含めるのは、ソースコード・設計書・テスト結果・運用手順書の4点であり、契約終了時の協力義務もあわせて明文化する。

委託先のターゲットAPI更新対応実績がリリース可否を直接左右する

外注先がGoogle Playの最新ガイドラインを継続把握しているかは、リリース可否を直接左右する。ターゲットAPIレベル更新、プライバシーマニフェスト、データセーフティ宣言など、ガイドライン更新への追従能力を委託先選定時に確認する。提案書で「直近12か月のリリース実績」「ターゲットAPI更新対応の事例」を求めることで、実務能力を把握できる。

一次対応責任とSLAの階層別フローを契約書に明記して事業継続性を確保する

障害発生時の責任分界を明文化しておくことは、ECや決済を含むアプリでは事業継続性に直結する。契約書に明記する論点は「どちらが一次対応するか」「どの時間帯まで対応するか」「重大障害の定義は何か」の3点である。SLA（Service Level Agreement、サービス品質合意書）の階層別対応フローも契約書に組み込む。

外注の典型失敗は4パターン｜要件定義の丸投げが最大リスク

androidアプリ開発外注でつまずきやすい典型失敗は、以下の4パターンに整理できる。

失敗1｜要件定義の丸投げが追加発注と納期遅延を招く

「要件定義から全部お任せします」という丸投げは、外注の最大リスクである。発注側の業務理解が反映されないまま設計が進み、実装後に「想定と違う」となって追加発注・再設計の連鎖が発生する。要件定義段階に発注側の業務担当者が必ず参加し、ユーザーストーリー・受入基準を共同で文書化する体制を組むことで回避できる。

失敗2｜テスト計画の不在で審査差戻しと不具合が連鎖する

Androidは端末・OSの組み合わせが多岐にわたる。Statcounter Global Statsの公開データを参照すると、日本国内ではAndroid 16から12まで複数バージョンが分散しています^*5。検証対象を絞らずに開発を進めると、リリース直前にクラッシュ報告が集中するリスクが高まる。IPA「ソフトウェア開発分析データ集」でもテスト工程の計画的な実施が品質確保の前提と指摘されています^*6。検証対象端末・OSバージョン・主要シナリオを契約段階で合意することが、リスク低減の現実的な手段となる。

失敗3｜運用引き継ぎ条項の不備でベンダーロックインが固定化する

引き継ぎ協力義務・ドキュメント帰属・運用履歴保管が契約段階で握られていないと、委託先切り替え時に高額な切替コストが発生する。回避策は3点である。運用ドキュメントの所有権を委託元に帰属させる契約条項、契約終了時の引き継ぎ協力義務の明文化、運用履歴の自社保管が有効である。

失敗4｜SLA未設定でリリース後の障害対応が後手に回る

契約書にSLAの記載があっても、障害レベルの定義・報告タイミング・休日深夜の対応可否が具体化されていない場合、重大障害時に対応が後手に回る。決済機能を含むアプリでは、ユーザー対応・問い合わせ処理・修正版の再審査を含めて復旧までに相応の時間と運用コストが発生する。要求段階の誤りをリリース後に修正するコストは要求段階の数十倍〜数百倍に達するとされており^*7、上流工程での品質ゲート設計が事業リスクの前払いとして機能する。

外注の実践6ステップ｜目的整理から運用移行まで

androidアプリ開発外注は「目的整理→要件文書化→外注先選定→契約・体制構築→開発推進→運用移行」の6ステップで進めることが現実的である。

ステップ1｜事業目的・KPI・想定ユーザーを社内で言語化する

外注先選定の前に、事業目的・KPI・想定ユーザー像・競合アプリとの差別化点を社内で言語化する。事業目的は売上・LTV・問い合わせ削減など、KPIはDAU・継続率・コンバージョンなどが該当する。これらが曖昧なまま外注先を選定すると、提案内容を比較する基準を持てず、結果的に丸投げ型の発注になる。

ステップ2｜検証範囲・対応OS・納品物リストを要件定義書に文書化する

対応OSバージョン・検証対象端末リスト・Google Play審査要件・納品物リストを要件定義書として文書化する。納品物リストには、ソースコード・設計書・テスト結果・運用手順書を含める。RFP（提案依頼書）の段階でこれらを明示することで、各社からの提案を同じ基準で比較できる。

ステップ3｜Android開発実績・継続リリース実績・運用体制で委託先を評価する

委託先評価では、Android開発の実績件数だけでなく、運用フェーズまで踏まえて確認する観点を持つ。直近12か月の継続リリース実績、ターゲットAPI更新対応の経験、Google Play審査差戻し時の対応事例、運用フェーズの体制を確認する。提案書・見積書・体制図のチェック観点を一覧化し、複数社で同条件比較することが有効である。

ステップ4｜契約形態・SLA・引き継ぎ条項・知財帰属を契約書に明文化する

契約形態・SLAの階層別対応フロー・引き継ぎ条項・知的財産権の取り扱いを契約書に明文化する。契約形態は請負／準委任／ラボの3類型から要件に応じて選択する。RACIチャートで委託と内製の境界を可視化することで、運用フェーズでの責任空白を予防できる。

ステップ5｜定例レビュー・受入基準・受入テストで開発を推進する

開発フェーズでは、週次・月次の定例レビュー、受入基準（受入テスト・性能基準・セキュリティ基準）、受入テスト体制を発注側で整える。発注側がレビュー責任を放棄すると、納品時に大きな手戻りが発生する。

ステップ6｜運用引き継ぎと内製化に向けた段階的スキル移管を進める

リリース後の運用フェーズでは、定期レビューと障害対応訓練、段階的なスキル移管（ドキュメント整備・運用ハンドブック・社内勉強会）を進める。完全な内製化を目指すか、保守運用外注を継続するかは事業フェーズによる。いずれの場合も「いつでも切り替えられる状態」を維持することが、ベンダーロックイン回避の前提となる。

androidアプリ開発外注の3つの判断軸：事業フェーズ・契約前4点・専門力評価軸

本稿では、androidアプリ開発外注の進め方を、状況別4類型・成功要因3点・典型失敗4パターン・実践6ステップで整理した。要点を3つに集約すると次の通りである。

第一に、外注パターンの選定は「自社の事業フェーズ」と「内製チームの状態」で決まる。一括外注／部分外注／保守運用外注／オフショア併用の4類型から、自社状況に合うものを選ぶ。

第二に、契約前段階で4点を必ず文書化することが、後工程の手戻りと事業リスクを抑える前提条件となる。「検証範囲・Google Play審査要件・障害時の責任分界・引き継ぎ条項」の4点が該当する。

第三に、外注は人手の補完ではなく「Android専門力の調達」であるため、委託先選定の評価軸が変わる。実績件数だけでなく、継続リリース実績とAPI更新対応経験を評価軸に組み込む。これらの判断軸を踏まえることで、要件定義の丸投げや運用引き継ぎ不備による失敗を予防し、事業スピードと品質の両立に近づくことができる。

LASSICのモバイルアプリ開発支援サービス

モバイルアプリ開発支援の対応領域

LASSIC IT事業部はプライムベンダーとして、システム保守・運用と先端技術開発を一体で受託する体制を整えています。Androidを含むモバイルアプリ開発領域では、要件定義から実装・ストア申請・運用保守までを一貫して支援します。Google Play審査要件への追従、ターゲットAPIレベル更新対応、運用引き継ぎ設計までをカバーします。スキル移管を前提とした契約設計にも対応しているため、将来的な内製化を見据えた段階的な体制構築にも適合します。

1. *1　出典：総務省「令和6年版 情報通信白書 情報通信機器・端末」（2024年）
2. *2　出典：Google「Android API レベル一覧（developer公式ドキュメント）」（最新版を参照）
3. *3　出典：経済産業省「IT人材需給に関する調査」（2019年公表、2030年に最大約79万人のIT人材不足を試算）
4. *4　出典：独立行政法人情報処理推進機構（IPA）「DX動向2025」（2025年6月公表）
5. *5　出典：Statcounter Global Stats「Mobile & Tablet Android Version Market Share Japan」
6. *6　出典：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」（2022年）
7. *7　出典：アラン・M・デービス『ソフトウェア開発201の鉄則』（1995年、近代科学社）。要求段階の誤りの修正コスト倍率は研究により幅があり、IBM Systems Sciences Instituteの公開資料では運用フェーズで100倍超とされている（書籍のためオンラインURLなし）。

Tweet