モバイルアプリのテスト外注｜端末戦略と依頼範囲

モバイルアプリのテスト外注を検討する段階で、多くのPMがぶつかるのは「外注すべきかどうか」ではなく「どう発注設計するか」です。外注そのものは前向きに考えている方が多いはずです。

それでも一歩踏み出せないのは、頼み方の解像度が上がらないからではないでしょうか。何を渡し、どこまで任せ、どう費用を見積もるか。そこが曖昧なままだと、社内の合意も取りにくくなります。

兼任のテスト体制では、手元にある数台の端末で確認するのが精一杯です。市場に出回る機種とOSの全組み合わせを、少人数で網羅するのは物理的に不可能に近い状態です。

さらにリリース直前になると、実機での最終確認が納期に間に合わない場面が出てきます。かといって外注先に「全端末やってください」と依頼すれば、見積もりが膨らみ、上長への説明が通らなくなります。

この記事のゴールは、モバイルアプリのテスト外注をどう設計するかの判断軸を整理し、稟議に持ち込める形にすることです。端末カバレッジの決め方、社内に残す範囲と外に出す範囲の切り分け、費用の当たりの付け方、ストア審査を見据えた段取り、そしてよくある失敗の型まで順に見ていきます。実機テストのやり方そのものより、発注する側の判断に一貫して絞って解説します。

なぜモバイルアプリはテスト外注が効くのか

Webアプリと比べて、モバイルアプリは検証コストが構造的に高くなります。だからこそ、この領域の外注は費用対効果が出やすいのです。理由を3つに分けて整理します。

第一に、端末とOSの断片化です。同じアプリでも、機種・OSバージョン・画面サイズの組み合わせによって挙動が変わります。特にAndroidはメーカーごとの独自ファームが多く、標準機では起きない不具合が実機で顔を出すことがあります。

断片化が厄介なのは、軸が一つではなく掛け合わせで効いてくる点です。UIの見え方一つ取っても、確認すべき条件の組み合わせは想像以上に増えます。代表的な軸を挙げると次のとおりです。

• 画面サイズと解像度（小型端末から大画面・タブレットまで）
• ノッチ・パンチホール・切り欠きによる表示領域の差
• 折りたたみ端末の展開・折りたたみ時のレイアウト変化
• ダークモードとライトモードの切り替え
• OS設定のフォントサイズ拡大による崩れ
• アクセシビリティ設定（拡大表示・太字・コントラスト調整など）

これらは一つずつなら軽微でも、掛け合わさると確認パターンが膨れ上がります。しかも大画面やアクセシビリティ設定でだけ崩れる不具合は、標準設定の実機を眺めているだけでは気づけません。だからこそ物量の要る領域で、実機を数多く持つ人手を借りる価値が最も出やすい部分です。

この組み合わせ爆発を、兼任の体制で拾い切るのは困難です。端末の掛け合わせが増えるほど、確認工数は加速度的に膨らみます。

第二に、ストア審査という納期直結の関門です。iOSもAndroidも、公開前に審査を通過する必要があります。審査でリジェクトされればリリースは遅延し、審査通過後に本番で不具合が出れば最悪の事故になります。

審査基準はAppleのレビューガイドラインやGoogle Playのポリシーセンターで公開されています。これらへの適合確認も検証の一部です。公式ガイドラインで繰り返し触れられる、リジェクトされやすい代表的なカテゴリを挙げておきます。

• 起動直後や特定操作でのクラッシュ・フリーズ
• 権限取得の理由説明が不足している（なぜその権限が要るかが不明瞭）
• アプリ内課金の導線やサブスクリプション表示の不備
• プライバシー関連の表示・データ利用の説明不足
• 実機で機能が動かない、審査時にログインできないなど再現性の問題

これらは仕様の作り込みだけでなく、検証時のチェック観点にも落とし込めます。審査で落ちやすい観点を発注時のテスト項目に含めておくと、リジェクトによる手戻りを前もって減らせます。

第三に、OS更新への追随です。iOSもAndroidも年次で大型アップデートがあり、ベータ版が公開される時期に事前検証をしておかないと、新OSリリース直後に既存機能が壊れるリスクがあります。

追随の対象はベータ期だけではありません。GA後の.xパッチ更新、セキュリティパッチ、WebViewなどシステムコンポーネントの独立更新でも挙動は変わります。Androidではメーカーごとに配信タイミングがずれるため、更新の波が長く続きます。OS更新の検証は、兼任体制では最も抜けやすいポイントの一つです。

以下に、Web検証とモバイル検証の違いを整理します。

観点	Webアプリ検証	モバイルアプリ検証
実行環境	ブラウザ中心。数種の主要ブラウザで大半を担保	実機・エミュレータ・シミュレータを併用。端末依存が強い
断片化	ブラウザとバージョンの組み合わせが中心	機種・OS・画面サイズ・メーカー独自ファームで爆発的に増える
リリース関門	自社リリースが基本。外部審査は原則なし	ストア審査を通過しないと公開できない
更新頻度	ブラウザ更新に随時追随	年次OS更新に加え.xパッチ・セキュリティ更新・独立更新が継続

モバイルアプリのテスト外注で何を・どこまで頼むか

成否を分けるのは、社内に残す範囲と外に出す範囲の線引きです。すべてを丸投げしても、すべてを抱え込んでも、うまくいきません。

社内に残すべきは、仕様理解が前提になる領域です。受け入れ観点の定義、ビジネスロジックの妥当性判断、優先度の判断。これらは自社の事業やクライアント要件を理解していないと判断できません。

丸投げが失敗しやすいのは、この責任分界を曖昧にしたまま渡すからです。外注先が担えるのは、あくまで決められた観点でのテスト実行と、その結果の報告です。「この挙動を合格とするか」「この不具合を今回のリリースで許容するか」といった合否判断は、仕様の意図とクライアントの期待を知る自社にしか下せません。実行と報告は外へ、判断は社内へ、という線引きを最初に握っておくと、後工程での押し付け合いが起きにくくなります。

外注が効くのは、労力が大きく、仕様の深い理解がなくても品質を担保できる領域です。実機マトリクスの網羅、回帰テスト、探索的テストなどが該当します。

責任分界を機能させるには、外注先に渡すインプットの質がそのまま結果を左右します。最低限そろえておきたいのは次の4点です。

• テスト観点リスト（何を確認してほしいかを機能・非機能に分けて明記）
• 対象端末リスト（機種名とOSバージョンを具体的に指定）
• 優先度（どの機能・端末から手を付けるかの順位づけ）
• 既知の注意点（未修正の不具合、触ってはいけない箇所、再現条件の共有）

このインプットが薄いと、外注先は手探りになり、報告の粒度も安定しません。逆にここを整えておけば、同じ費用でも拾える不具合の質が上がります。

ここで発注時に意識したいのが、機能・状態遷移系の観点と、真の非機能系の観点を分けて指定することです。回線切替・バックグラウンド復帰・プッシュ通知・ディープリンク・IAP（アプリ内課金）は、主に機能テストや状態遷移テストの領域です。一方、性能効率性・メモリやバッテリー消費・起動時間・信頼性・セキュリティが、いわゆる非機能の領域にあたります。発注書では、機能・状態遷移系と非機能系を別項目に分けて指定すると、抜けと解釈違いが減ります。

グレーゾーンになりやすいのが自動化です。既存の自動テスト資産の有無で、外注に含めるべきかが変わります。自動化の導入や実装手順は本記事の範囲を超えるため、Webアプリのテスト自動化のツール選定とE2E導入手順を解説した記事を参照してください。

テスト種別	主な担当	委託／残す理由
受け入れ観点の定義	社内	事業・クライアント要件の理解が前提。外に出せない判断
ビジネスロジックの妥当性判断	社内	仕様の意図を知る側でないと合否を決められない
実機マトリクスの網羅	外注	物量が大きく、端末を持つ外注先の強みが出る
回帰テスト	外注	反復作業。OS更新に合わせ定期実行枠を持たせやすい
探索的テスト	外注	実機での使い込みが必要。人手の厚みが効く
機能・状態遷移系（回線切替・通知・IAP等）	外注	実機環境が要る。項目を明示して依頼する
非機能系（性能・メモリ・起動時間等）	外注	測定観点が独立。別枠で指定すると精度が上がる
自動化	資産次第	既存資産があれば維持を委託、なければ社内判断を先行

迷ったら、まず実機マトリクスの網羅を外に出すのが費用対効果の高い一手です。

外注の基本的な費用感と進め方をまず押さえたい場合は、ソフトウェアテスト代行とは？費用と進め方を解説した記事で全体像を確認しておくと、この切り分けの判断がしやすくなります。

モバイル特有の実機テスト観点

外注する範囲を決めたら、次は「実機でないと再現性が低い観点」を依頼側として把握しておく必要があります。ここで大事なのは、実機とエミュレータ・シミュレータを二分法で捉えないことです。

ロジックの不具合やレイアウト崩れの多くは、エミュレータ（Android）やシミュレータ（iOS）でも前段で検出できます。だからこそ、社内でエミュレータ・シミュレータによる前段スクリーニングを行い、そこで拾えない領域を実機に回す二段構えが有効です。社内で一次スクリーニング、実機は外注という役割分担が、費用と品質の両立点になります。

一方で、実機でないと再現性が下がる領域があります。代表的なのは次のとおりです。

• センサ・カメラ・生体認証・NFC／おサイフケータイなどのハードウェア連携
• 実回線の輻輳・電波品質・キャリア依存の挙動
• GPU描画・発熱・バッテリーなど性能や熱制御に関わる挙動
• Androidのメーカー独自ファームに起因する差異
• IAPやプッシュなど、実サービスと連携する経路

見落とされがちなのが割り込み系の挙動です。テスト中に着信やアラームが入る、他アプリが前面に出る、OSの権限ダイアログが割り込む、低電力モードに遷移する。こうした外部イベントで処理が中断され、復帰時に画面が崩れたり入力中データが消えたりします。割り込みは発生タイミングが読みにくく、シミュレータでは実機どおりに再現しづらいため、実機での使い込みが効きます。

課金・IAP系も注意が要ります。開発時はサンドボックス環境で購入フローを確認しますが、サンドボックスと本番課金では挙動が完全に一致するとは限りません。加えて、購入の復元や返金後の状態反映など、正常系以外のフローも検証対象です。実サービスと連携する本番課金の確認は、実機と実アカウントでの担保が前提になります。

観点を発注しやすいように、系統別に整理します。

系統	主な観点	分類
ネットワーク／状態遷移系	Wi-Fi⇔モバイル回線の切替、圏外復帰、オフライン時のデータ保持、バックグラウンド復帰、低速時の再送・タイムアウト	機能・状態遷移
割り込み系	着信・アラーム・他アプリ起動・権限ダイアログ割り込み・低電力モード遷移からの復帰	機能・状態遷移
通知／連携系	プッシュ通知の受信とタップ後遷移、ディープリンク、IAPの購入・復元フロー	機能・状態遷移（一部インターオペラビリティ）
端末リソース／表示系	低メモリ端末での劣化、権限ダイアログと拒否時の挙動、画面回転、ノッチ・切り欠き表示崩れ	機能・表示
性能・信頼性系	起動時間、メモリ・バッテリー消費、長時間稼働時の安定性	非機能

前者の状態遷移・割り込み・連携・表示系は主に機能・状態遷移系、最後の1系統が真の非機能系です。発注時に両者を分けて指定すると、外注先も観点を取り違えにくくなります。

端末カバレッジの決め方

費用が膨らむ最大の原因は、端末カバレッジを決めずに発注することです。「全端末」ではなく「守るべき端末」を定義することが、費用対効果の分岐点です。

優先端末を絞る基準は、次の順で考えると整理しやすくなります。

• 自プロダクトの利用実績（アクセス解析での機種・OS分布）
• ターゲット層のデバイス傾向
• 自社のOSサポート方針（下限バージョンをどこに置くか）

最も確実な根拠は、自プロダクトの実利用データです。ただし、納品して終わる受託案件では、手元に実利用データがない場面も少なくありません。その場合は、以下のような代替根拠で優先端末を組み立てます。

• クライアントにアクセス解析データの共有を依頼する
• 国内のストアシェア・OSシェアの公開統計を、出典を明示して参照する
• ターゲット層と利用シーンから利用端末を想定する
• クライアントのサポート方針（どの機種を保証対象とするか）を確認する

端末シェア統計を参考にする場合も、断定的な数値の引用は避け、出典を明示します。数値そのものより、「なぜこの端末セットなのか」を説明できる根拠の積み上げが重要です。

集めた根拠は、端末を一律に並べるのではなく、優先度で階層化すると発注に載せやすくなります。おすすめは「必須／推奨／任意」の3階層に分ける設計です。

• 必須：実利用の上位を占める機種と、主要OSの現行・一つ前バージョン。ここが落ちると事業影響が直撃する層
• 推奨：準主要の機種・OS。必須ほどではないが、無視すると一定数のユーザーに影響が出る層
• 任意：ロングテールの旧機種・マイナー端末。予算と時間に余裕があれば拾う層

この3階層で設計しておくと、予算の増減にそのまま対応できます。予算が削られたら任意を落とし、余裕が出たら推奨を厚くする、という調整が根拠つきで説明できるからです。全端末を平らに要求するのではなく、階層ごとに投じる工数を変えるのがカバレッジ表の作り方の要点です。

実機とクラウド端末ラボは、役割を分けて使います。共有のクラウド端末ラボは、多数の端末で並列実行し、互換性・レイアウト・広域な端末を一気に一次スクリーニングするのが得意です。短時間で「どの端末で崩れるか」の当たりを付ける用途では強みが出ます。

一方で、クラウドラボには不得手な領域があります。実SIMを挿した実回線での通信、指紋・顔などの生体認証、NFC/おサイフケータイ、IAPの本番課金、プッシュの実受信などは、環境上の制約で十分に担保できません。ここを見誤ると、クラウドで通ったのに本番端末で落ちる、という取りこぼしが起きます。

そのため、実回線・生体認証・IAP本番・プッシュ実受信は、所有実機か、実機を持つ外注先で担保します。クラウドラボの例としてFirebase Test Labがあります。広く浅くはクラウド、深く継続的には実機という使い分けが基本です。

判断軸	見るポイント	端末選定への反映
利用実績	アクセス解析の機種・OS分布	上位を占める端末を必須枠に
ターゲット層	想定ユーザーのデバイス傾向	データがない場合の主要な補完根拠
OSサポート方針	保証する下限OSバージョン	検証対象の範囲を確定
実機／クラウド	深さ重視か広さ重視か	実機で深く、クラウドで広く
iOS／Android配分	実利用比重	比重の高い側に検証工数を厚く

発注時の費用の当たりの付け方

稟議で必ず問われるのが費用です。相場そのものは案件次第で、断定できる金額はありません。それでも、費用がどう決まるかの構造を押さえておけば、上長への説明は組み立てられます。

費用の当たりは、次の3つのドライバーで考えます。

• 対象端末数（守るべき端末をいくつ検証するか）
• テスト観点数（機能・状態遷移系と非機能系をどこまで指定するか）
• 実行回数（回帰をどの頻度で回すか）

この3つの掛け算が、おおよその工数感を決めます。守るべき端末に絞るほど、掛け算の一辺が縮み、見積もりは目に見えて小さくなります。端末を絞る根拠を用意することは、そのまま費用を抑える根拠にもなります。

見積もりを取るときは、複数社から相見積もりを取るのが基本です。その際、同一のテスト範囲・端末リスト・観点をそろえて依頼します。条件がずれた見積もりを並べても比較になりません。

条件をそろえるには、発注仕様書に書くべき項目を先にチェックリスト化しておくと確実です。各社に同じ仕様書を渡せば、見積もりの前提が揃い、比較が成立します。仕様書に最低限盛り込みたい項目は次のとおりです。

• 対象OSと下限バージョン（どのOSを、どこまで古いバージョンまで見るか）
• 対象端末リスト（機種名とOSバージョンを具体名で）
• テスト観点（機能・状態遷移系と非機能系を分けて列挙）
• 実行回数・回帰頻度（初回のみか、リリースごとの定期回帰か）
• 不具合報告フォーマット（機種・OS・再現手順・頻度などの必須項目）
• 成果物と納品形式（報告書・不具合票・エビデンスの形式）
• 期間・体制（希望納期と、想定する体制規模）

この仕様書がそろっていれば、各社の見積もりの差が「単価や体制の差」なのか「前提の取り違え」なのかを切り分けられます。

費用対効果は、金額だけでなく時間・人的リソースの観点でも語れます。兼任者がリリース直前に張り付いていた実機確認の工数が、外注で外に出せれば、その分の人手が他の案件に回ります。具体的な時間数は案件次第で断定できませんが、「人が回るようになる」という論拠は、金額を詰める前でも上長に説明しやすい材料です。

費用ドライバー	増える要因	抑える打ち手
対象端末数	全端末を要求する	守るべき端末に絞り根拠を添える
テスト観点数	観点を無限定に広げる	機能・非機能を分け必要な観点を選ぶ
実行回数	毎リリース全量回帰	変更影響に応じ回帰範囲を調整

費用感をさらに具体的に詰めたい場合は、テスト代行の費用相場と見積もりの考え方をまとめた記事が判断材料になります。

依頼時の論点｜ビルド受け渡し・審査サイクル・端末情報の伝え方

範囲と費用の当たりが付いたら、次は渡し方です。ここでの段取りが、立ち上がりの速度を左右します。

まずビルドの受け渡しです。iOSならTestFlightなどの内部配信、Androidなら内部テスト配信を使います。配信経路と権限を事前にそろえておくと、初回の待ち時間が減ります。ここで起きやすいのがビルドの取り違えです。テスト用ビルドと本番用ビルドが混在すると、直したはずの不具合が再現するなどの混乱を招きます。配信時にはバージョンとビルド番号を必ず明示し、どのビルドを検証対象とするかを両者で確認しておきます。

次に、審査サイクルを織り込んだスケジュールです。リジェクトはあり得る前提で、手戻りの余白を確保します。審査は概ね次の流れで進むため、各段階に余白を持たせて日程を引きます。

• テスト完了：合格基準を満たしたことを確認
• ビルド確定：提出するビルドを固定し、番号を記録
• ストア提出：審査に申請
• 審査待ち：所要期間は変動する前提で待つ
• （リジェクト時）修正・再提出：指摘に対応し、再度提出

特に審査待ちと再提出は自社でコントロールできないため、ここに余白がないと、わずかなリジェクトでもリリース全体が後ろ倒しになります。

そして、端末情報と再現条件の伝え方です。不具合報告には、機種名とOSバージョン、回線状態、再現手順、発生頻度を添えます。これがそろっていないと、外注先での再現に時間がかかります。

論点	準備すること	目的
ビルド受け渡し	内部配信の経路と権限を整備、バージョン/ビルド番号を明示	初回の待ち時間短縮と取り違え防止
審査サイクル	再申請を含む日程に手戻り余白を確保	リリース遅延を防ぐ
端末情報・再現条件	機種・OS・回線・手順・頻度を定型化	再現の手戻りを削減

依頼前の段取りを型にしておくことが、外注の立ち上がり速度と手戻りの少なさを決める要素です。この準備の全体像は、テスト代行を依頼する前の準備を段取り5観点で整理した記事で確認できます。

モバイルアプリのテスト外注でよくある失敗と回避策

最後に、つまずきやすい失敗の型を押さえます。どれも発注前の設計でほぼ防げます。

• 「全端末やって」で費用が膨らむ → カバレッジ設計で守るべき端末に絞る
• 審査サイクルを考慮せずリリースが遅延 → 再申請を含む手戻り余白を確保
• 仕様・再現条件の共有不足で手戻り → 依頼テンプレートで伝達項目を定型化
• 内製と外注の線引きが曖昧で二重作業 → 担当マトリクスで範囲を明文化

失敗の型	原因	回避策
費用膨張	端末カバレッジ未設計	守るべき端末を定義し根拠を添える
リリース遅延	審査サイクル未考慮	再申請前提で手戻り余白を確保
手戻り多発	仕様・再現条件の共有不足	依頼テンプレートで項目を固定
二重作業	内製と外注の線引き曖昧	担当マトリクスで責任範囲を明確化

4つの失敗はすべて、発注前の設計不足という同じ根に行き着きます。内製と外注のどこで線を引くかに迷う場合は、テストの内製と外注はどちらが得かを判断の物差しで整理した記事が参考になります。

モバイルアプリのテスト外注に関するよくある質問

発注設計の検討でよく挙がる疑問を、Q&A形式で整理します。

Q. モバイルアプリのテスト外注の費用はどう決まりますか。 A. 対象端末数・テスト観点数・実行回数の3つのドライバーの掛け算で、おおよその工数感が決まります。相場そのものは案件次第のため断定できません。守るべき端末に絞り、必要な観点を選ぶことで、見積もりは目に見えて小さくなります。

Q. どの端末まで対応すべきですか。 A. 「全端末」ではなく「守るべき端末」を定義します。最も確実な根拠は自プロダクトの実利用データです。データがない場合は、公開シェア統計やターゲット層の想定、クライアントのサポート方針で補います。

Q. どこまで自社に残し、どこから外注すべきですか。 A. 合否判断や仕様理解が要る領域は社内に残します。受け入れ観点の定義やビジネスロジックの妥当性判断は、事業やクライアント要件を知る側でないと下せないためです。一方、実機マトリクスの網羅や回帰のように実行物量が要る領域は外注が効きます。判断は社内、実行と報告は外へ、という分界が基本の型です。

Q. ストア審査は外注に含められますか。 A. 審査そのものは開発元が申請しますが、審査基準への適合確認は検証の一部として依頼できます。リジェクトを前提に、再申請を含む手戻り余白をスケジュールに確保しておくと安全です。

質問	要点
費用の決まり方	端末数×観点数×実行回数。絞れば縮む
対象端末	実利用データ優先、なければ公開統計等で補う
社内と外注の分界	判断は社内、実行と報告は外へ
ストア審査	適合確認は委託可、再申請の余白を確保

まとめ｜発注設計を稟議材料に変える

モバイルアプリのテスト外注は、「外注するか否か」ではなく「どう発注設計するか」で成否が決まります。発注設計は、4つの問いに答える作業です。

• 何を頼むか（社内に残す範囲と外に出す範囲の切り分け）
• どの端末を対象にするか（守るべき端末の絞り込み）
• いくらの当たりを付けるか（端末数×観点数×実行回数の構造）
• どう渡し、どう失敗を防ぐか（段取りの型化）

特に稟議で効くのは、「なぜこの端末セットなのか」を根拠で裏づけた優先端末の絞り込みです。実利用データがあればそれを軸に、なければ公開統計やターゲット層の想定で根拠を組み立てます。データの有無にかかわらず、説明の筋は通せます。

明日からの最初の一手として、既存案件を1件選び、「守るべき端末表」の空欄を埋めてみることをおすすめします。必須・推奨・任意の3階層で並べ替えるだけでも、足りない根拠と、外に出せる範囲が見えてきます。発注設計は一度型を作れば、次の案件でも流用できます。

自社の優先端末の絞り込みや依頼範囲の設計に迷ったら、テスト体制の相談窓口からお問い合わせください。