アプリ開発会社の選び方｜委託先を見極める7つの確認事項
アプリ開発の委託で失敗する最大の原因は、会社選びではなく「何を頼むかが曖昧なまま発注すること」です。そのうえで会社を比べるときに何を見るべきか、見積りが3倍違う理由は何か、相場はいくらか——実際にApp Storeでアプリを配信・運用している立場から、当社が向かない案件も含めて書きます。
まず決めるべきは「何を外に出すか」
会社を比べる前に決めることがあります。アプリ開発の委託で失敗する最大の原因は、会社選びではなく「何を頼むかが曖昧なまま発注すること」です。
| 決めておくこと | 曖昧なままだと |
|---|---|
| 誰が何のために使うか | 機能が際限なく増え、予算を超える |
| 最初のリリースに何を入れるか | いつまでも公開できない |
| 公開後、誰が運用するか | 納品されたが誰も触れないアプリになる |
| 課金するか | 後から入れると設計をやり直すことになる |
| iOSとAndroidの両方が要るか | 費用が倍近く変わる |
すべて決まっていなくて構いません。ただし「決まっていない」ことを自覚したうえで、それを一緒に整理してくれる会社を選ぶべきです。要件が固まっている前提で見積もる会社に、固まっていない案件を出すと必ず揉めます。
確認すべき7つのこと
- どこまで自社でやるのか――再委託が多いと、責任の所在が曖昧になります。「設計は自社、実装は外注」は珍しくありません。悪いことではありませんが、把握しておくべきです
- 実際に公開したアプリがあるか――「対応可能」ではなく、ストアで実際に配信されているアプリを見せてもらってください
- 審査に落ちた経験があるか――落ちたことがない会社は、単に本数が少ないだけです。落ちて通した経験のほうが価値があります
- 見積りの内訳を説明できるか――「一式」だけの見積りは後で必ず揉めます。画面数・機能数・工数で分解されているか
- 仕様変更をどう扱うか――開発中に要件は必ず変わります。追加見積りになるのか、枠内で調整するのかを先に確認
- 公開後どうなるか――OSのバージョンアップ対応、ストア規約の変更対応を継続できる体制か
- ソースコードは誰のものか――納品範囲にソースが含まれるか。含まれないと他社に移せません
見積りが大きく違う理由
同じ要件で相見積もりを取ると、3倍以上の差がつくことがあります。安いほうが得とは限りません。
| 差が出る要因 | 安い見積りで起きがちなこと |
|---|---|
| 設計工程の有無 | 設計を省き、作りながら考える。後で作り直しになる |
| テストの範囲 | 実機テストが少なく、公開後に不具合が出る |
| 審査対応の有無 | 「申請は別料金」と後から言われる |
| 保守の扱い | 納品後の修正が全て追加費用になる |
| ソース納品の有無 | 他社に移せず、値上げに応じるしかなくなる |
見積書は総額でなく、何が含まれていて何が含まれていないかを比べてください。
費用の相場
| 規模 | 費用の目安 | 期間 |
|---|---|---|
| シンプルなアプリ（画面数少・課金なし） | 98万〜300万円 | 1〜3か月 |
| 一般的な業務アプリ・サービスアプリ | 300万〜800万円 | 3〜6か月 |
| 課金・サーバ連携あり | 500万〜1,500万円 | 4〜10か月 |
| 機器・センサーと連動するアプリ | 500万〜1,500万円 | 4〜10か月 |
iOSとAndroidの両方を作ると、1.5〜1.8倍が目安です。詳しくは開発費用と期間の目安をご覧ください。
当社を選ぶ場合の判断材料
公平を期すため、当社が向く案件と向かない案件を書いておきます。
| 向いている | 向いていない |
|---|---|
| 機器・センサーと連動するアプリ（ハードも自社で作れる） | 大規模な業務基幹システムの一部としてのアプリ |
| 作りながら決めたい新規事業 | すでに詳細設計書が完成していて実装だけ欲しい |
| 審査・課金まで含めて任せたい | とにかく最安を求める案件 |
| 補助金を使って開発したい | 即日納品のような短納期案件 |
当社は自社アプリをApp Storeで複数本、配信・運用しています。審査でリジェクトされ、原因を特定して通した経験が実際にあります。また、センサーやデバイスを自社で設計できるため、機器と連動するアプリでは「機器メーカーとアプリ会社に分けて発注する」必要がありません。
見積書のどこを見れば、その会社が分かるか
複数社から見積りを取ったとき、金額の大小より「何が書かれていないか」を見てください。抜けている項目は、後から追加費用になるか、そもそも想定されていないかのどちらかです。
- ストアへの申請と審査対応：開発費に含まれているか。「開発は終わったが公開できない」で止まる案件が実際にあります
- リジェクト時の再提出：何回まで含まれるか。回数無制限と書く会社はまずありません
- OSバージョン更新への追随：iOSは毎年更新され、動かなくなる箇所が出ます。1年後の対応が有償なのかを確認します
- サーバー費用：開発費と別に月額が発生するか。誰の名義で契約するか
- ソースコードの帰属：納品されるか、会社に残るか。ここが曖昧だと他社へ移れません
- テストの範囲：どの端末・どのOSバージョンで確認するか
- 瑕疵対応の期間：納品後、いつまで無償で直すか
見積書が1枚で「アプリ開発一式 ◯◯万円」とだけ書かれている場合、内訳を出してもらってください。出せない会社は、自分でも工数を把握していない可能性があります。
安い見積りが、なぜ安いのか
同じ要件で3社に出して、金額が2倍以上開くことは普通にあります。理由はだいたい次のどれかです。
| 安い理由 | 起きること |
|---|---|
| テンプレートを流用している | 他アプリと似すぎてストアで重複と判定されリジェクトされる（ガイドライン4.3）。デザイン・掲載文の作り分けが要ります |
| 要件を狭く解釈している | 「それは見積り外です」が着工後に出てくる |
| 申請・審査対応が入っていない | 公開の段階で別費用が発生する |
| テストが薄い | 審査でクラッシュを指摘されて落ちる（ガイドライン2.1） |
| オフショアに丸投げしている | 仕様の伝達が二重になり、認識ずれの手戻りが増える |
逆に高い見積りが常に良いわけでもありません。不確実性が大きいと、受注側はリスク分を上乗せします。仕様を具体的に示せるほど、見積りは正確かつ安くなります。
契約前に必ず確認する3点
- ソースコードは誰のものか：納品対象に含まれるかを契約書で確認します。含まれないと、その会社から離れられなくなります
- ストアのアカウントは誰の名義か：開発会社の名義で公開すると、アプリは実質その会社のものになります。必ず発注者名義のアカウントで公開してもらってください。後から移すのは非常に手間がかかります
- 担当者が変わったらどうなるか：小規模な会社では属人化が起きます。仕様書とコードが残る形で進めているかを確認します
この3点は、開発が順調なうちは問題になりません。問題になるのは、その会社と続けられなくなったときです。そのときに動けるかどうかが、最初の契約で決まります。
相談するときに持っていくとよいもの
- やりたいことのメモ――箇条書きで構いません。文章になっている必要はありません
- 参考になるアプリ――「これに近い」があると早いです
- 使う人の想定――社内向けか、一般公開か
- 予算の上限――伝えたくない気持ちは分かりますが、伝えたほうが早く適切な案が出ます
- いつまでに必要か――理由（展示会、決算、補助金の期限など）も一緒に
すべて揃っていなくて構いません。「この作業を楽にしたい」だけでも、そこから整理できます。