LASSIC Media らしくメディア

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

結論：モバイルアプリ開発会社は「見積透明性・実績領域・運用保守」の3軸で絞り込む

モバイルアプリ開発会社の選び方とは、自社のアプリ要件・運用体制・予算制約に対して、開発委託先を「見積根拠の透明性」「実績領域の一致」「リリース後の運用保守体制」の3軸で評価し、複数社の比較を通じて発注先を確定する一連の選定プロセスである。総務省「令和7年版情報通信白書」によると、スマートフォンの世帯保有率は90.5%に達しており（2024年調査）^*1、個人のインターネット接続端末としてのスマートフォン利用率は74.4%で、パソコンの46.8%を上回るチャネルとなっている。アプリは事業の主要接点となるため、開発会社の選定ミスはユーザー獲得機会の損失に直結する。

結論として、価格の安さだけで選定すると、見積に含まれない作業範囲（OS更新追従、ストア審査差戻し対応、軽微改修）が後工程で追加費用化し、総額が初期見積を超過する。経済産業省が2019年4月に公表した「IT人材需給に関する調査」では、2030年に高位シナリオで最大約79万人のIT人材不足が生じると試算されており^*2、優良な開発会社のリソース確保競争はさらに激しくなる。価格交渉力よりも、要件適合度・運用継続性で選ぶ姿勢が実務上の定石だ。

比較軸7つ：実績領域・OS対応・体制規模・見積根拠・運用保守・契約形態・コスト構造

モバイルアプリ開発会社の評価は、以下の7つの比較軸で整理すると抜け漏れが起きにくい。すべての軸を満点で満たす会社は存在しないため、自社の優先順位に従って配点する運用が現実的である。

実績領域：自社業種・類似機能の開発経験がないと要件抽出で詰まる

同業種・類似機能（決済、予約、地図、IoT連携、チャット、動画配信など）の開発実績は、要件定義フェーズでの認識ずれを抑える判断材料になる。公開アプリの実機確認まで行うと、UI品質・遷移設計の癖が把握できる。事例の確認では、公開済みのプレスリリースまたはApp Store・Google Play上のアプリ名まで開示できるかを問うことで信頼性を判別できる。

OS対応：iOS・Android最新版＋過去2バージョンの保証範囲を提案書で明示する

iOS・Androidは年1回のメジャー更新があり、API変更・廃止に追従しないとストア審査で差戻しが発生する。最新版＋過去2バージョン（直近3世代）を保証範囲とする提案であるか、提案書のOS対応マトリクスで確認する。OS更新追従費用が運用保守費に含まれているか、別請求であるかも事前に握る必要がある。

体制規模：PM・iOS・Android・QAの稼働人月をアサイン予定者の経歴書で確認する

体制図は提案時に必ず提出を求めるべき資料である。PM、iOSエンジニア、Androidエンジニア、QA、デザイナーがそれぞれ何人月稼働するかを明示してもらう。アサイン予定者の経歴書まで開示できる会社を優先する。「人員はアサイン時に決定する」とする提案は、想定品質と乖離するリスクがある。

見積根拠：機能別×工程別の工数内訳と前提条件を必ず提出させる

一式表記の見積を許容しないことが、後工程の追加費用を抑える実効性の高い手段だ。機能別（ログイン・購入・通知・地図など）×工程別（要件定義・設計・実装・テスト・リリース）の工数内訳を提出してもらう。前提条件（OS範囲、想定端末数、対応言語数、API連携数）も明文化する。

運用保守：障害一次受け・OS更新追従・審査再申請の範囲をSLAで握る

リリース後に発生する障害一次受け、OS更新追従、ストア審査差戻し時の再申請対応は、運用保守契約の範囲で握っていない場合は都度見積の追加費用となる。SLA（サービスレベル合意書）のドラフトを提案段階で提示できる会社であれば、運用設計の経験値が高い可能性が高い。

契約形態：請負・準委任（SES）・ラボ型の切替条件を契約書ドラフトで確認する

請負契約は成果物責任を負う形態、準委任（SES。System Engineering Service、技術者の役務提供契約）は工数提供型、ラボ型は専属チームを期間契約する形態である。要件確定後のスコープ拡大が想定される場合は、請負＋追加機能はラボ型といった併用も選択肢に挙がる。

コスト構造：初期開発費・運用保守費・追加開発単価の3層で3年TCOを試算する

初期開発費だけを比較すると、運用保守費・追加開発単価が高い会社が結果的に総額で割高になることがある。初期開発・運用保守（年額）・追加開発単価の3層で3年分の総保有コスト（TCO、Total Cost of Ownership）を試算依頼する。これにより本当の価格競争力が見える。

受託・ニアショア・オフショア・SESの4形態は目的とリスク許容度で使い分ける

モバイルアプリ開発を外部委託する形態は、大別して受託開発（請負）、ニアショア開発、オフショア開発、SES（準委任）の4つになる。それぞれ強みと制約があり、目的・リスク許容度に応じた使い分けが現実的である。

受託開発（請負）：成果物責任を委託先に持たせて新規アプリ立ち上げ向き

受託開発は請負契約に基づき、委託先が成果物に責任を持つ形態である。要件定義が固まっている新規アプリ立ち上げ・大規模リニューアルに向く。一方、要件変更を要求するたびに追加見積が発生するため、要件未確定のまま発注すると総額が膨らみやすい。

ニアショア開発：国内地方拠点活用で意思疎通とコスト圧縮を両立できる

ニアショア開発は、地方拠点に開発リソースを置く形態である。海外オフショアと比較して、言語・時差の摺り合わせコストが小さい点が強みだ。都市部の人件費水準と比較してコスト圧縮効果があり、品質基準の認識合わせも国内基準のままで進められる。LASSICはニアショア型でモバイルアプリ開発の元請受託を行う体制を持つ。

オフショア開発：海外拠点活用で人件費圧縮効果が大きい一方で標準化前提

オフショア開発は、東南アジアやインドなどの海外拠点を活用する形態である。人件費の圧縮余地が大きく、長期間・大規模の継続開発で効果を発揮する。言語・時差・文化的な品質基準の摺り合わせが必要になるため、ドキュメント標準化・テストプロセス標準化が進んだ組織で適合度が高い。

SES（準委任）：工数提供契約で要件流動的な改修・保守支援に向く

SES（準委任）は工数を提供する契約形態で、スコープが流動的な案件・既存チームへの工数増強・改修保守の継続支援に向く。成果物責任は発注側が負うため、進行管理・受入判断は自社の力量が問われる。エンジニアの稼働を自社で管理する体制があることが、SES活用の前提だ。

向き不向き：自社の状況別「選ぶべき開発会社」マトリクス

「どの開発会社が良いか」は自社の状況によって変わる。ここでは、初発注か継続発注か、要件確定度、想定アプリ規模、内製エンジニアの有無の4軸で、適合する委託形態を整理する。

アプリ開発が初めて・要件未確定の場合は、要件定義から伴走する受託開発を選ぶことをおすすめする。要件確定段階で投資判断ができるため、リスクを抑えやすい。継続的な機能追加が見込まれる場合は、SESまたはラボ型でチームを固定する形態が向いている。

RFP・見積依頼で確認漏れが起きやすい4項目と確認文例

RFP（Request for Proposal、提案依頼書）または見積依頼書の作成段階で、以下の4項目を盛り込む。これにより後工程の手戻り・追加費用を抑えられる。確認漏れが頻発する典型項目を、確認文例とあわせて整理する。

OSバージョン対応方針：保証範囲と更新追従コストの負担区分

iOS・Androidの最新版＋過去2バージョンを保証範囲とするか、過去1バージョンまでか、提案書で明示してもらう。OSメジャー更新時の追従対応コストが運用保守費に含まれるか、別請求かも合意しておく。

確認文例：「提案するアプリのOS保証範囲を、iOS・Androidそれぞれ最新版から何バージョン前までとするか提示してください。あわせて、OSメジャー更新時のAPI追従対応費用が運用保守契約に含まれるかをご回答ください。」

ストア審査差戻し対応の範囲：再申請工数の負担区分

App Store・Google Playの審査で差戻しが発生した場合、再申請に要する工数の負担区分を提案段階で確認する。リリース直前のスケジュール逼迫を避けるため、差戻し対応の標準工数・回数上限も合意するとよい。

確認文例：「App Store・Google Playの審査差戻しが発生した場合、再申請対応の工数は誰の負担となるか、また何回までを契約範囲内とするかを明示してください。」

運用保守の役割分担：障害一次受けからOS追従までの範囲

運用保守の作業範囲は、障害監視・一次受け、軽微改修、OS追従、ストア対応、利用ユーザー問い合わせ対応など複数のレイヤーに分かれる。RACI（Responsible・Accountable・Consulted・Informed、責任分担マトリクス）形式で役割分担を明文化してもらう。

確認文例：「リリース後の運用保守について、障害監視・一次受け・軽微改修・OS追従・ストア対応の各作業について、貴社対応範囲と当社対応範囲をRACI形式で提示してください。」

契約形態と変更管理：請負か準委任かと仕様変更時のプロセス

請負契約・準委任契約のどちらが適用されるか、仕様変更時の変更管理プロセス（変更要求書、影響範囲評価、追加見積、合意手続き）を契約書ドラフトで確認する。

確認文例：「契約形態（請負・準委任）と、開発期間中に発生する仕様変更時の変更管理プロセス（変更要求書様式・追加見積算定基準・合意フロー）を契約書ドラフトに含めて提示してください。」

発注後の失敗を防ぐ：契約・運用保守・受入テストで握るべき条件

選定が終わった後の契約・運用保守・受入テストの段階でも、握るべき条件を漏らすと発注後の手戻りが大きくなる。発注者として最低限押さえるべき条件を整理する。

契約：請負契約書の検収条件と瑕疵担保責任期間を明文化する

請負契約では、検収完了の条件（合格基準）と瑕疵担保責任の期間を契約書に明記する。検収完了後に発見された不具合への対応範囲・費用負担をどう取り決めるかが、運用フェーズの安心感を左右する。

運用保守：SLAで応答時間・解決目標時間・営業時間の合意を取る

運用保守契約には、障害発生時の応答時間（受付応答までの目標）と解決目標時間（一次対応完了までの目標）、対応営業時間（平日日中・24時間365日）を明記する。サービス影響度別（重大・通常・軽微）の対応基準も整理する。

受入テスト：受入テスト基準書を発注側で作成し合格基準を握る

納品物の検収では、受入テスト基準書を発注側で作成することが品質確保の出発点だ。委託先のテスト結果報告書を受け取るだけでは、要件適合の客観評価ができない。受入テスト工数を確保し、不合格時の対応プロセスを契約書に含める。

失敗回避：内製で完結する場合のリスク・工数を事前評価する

モバイルアプリ開発を内製で完結させる場合、iOSエンジニア・Androidエンジニア・QA・PM・デザイナーの確保が必要だ。経済産業省が2019年4月に公表した「IT人材需給に関する調査」では、2030年に高位シナリオで最大約79万人のIT人材不足が生じると試算されており^*2、必要スキルセットの確保リードタイムは事業計画への影響が大きい。内製で全工程を完結させる場合と外部委託する場合のリスク・コスト・工数を事前に比較した上で判断する。

まとめ：モバイルアプリ開発会社選定の3つの判断軸

モバイルアプリ開発会社の選定では、見積根拠の透明性・実績領域の一致・運用保守体制の有無の3軸で一次選別することで、発注後の手戻りリスクを大幅に抑えられる。受託・ニアショア・オフショア・SESの4形態は、自社の要件確定度・継続開発の見通し・内製体制の有無に応じて使い分けるのが実務の基本だ。RFP段階でOSバージョン対応方針・審査差戻し対応・運用保守の役割分担・契約形態を明文化することで、発注後に発生しがちな追加費用と認識ずれを防げる。これらの判断軸を揃えた上で複数社を並列評価することが、モバイルアプリの長期運用を見据えた選定の実務的な出発点だ。

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：総務省「令和7年版 情報通信白書」（2025年）
2. *2　出典：経済産業省「IT人材需給に関する調査（概要）」（2019年）

Tweet