アプリ開発を外注するには？費用の考え方・依頼先の選び方・発注前の準備
この記事でわかること
- アプリ開発の費用が変わる条件と、見積もりの見方
- 開発会社と個人に依頼するときの違い
- 仕様が決まっていない段階で相談するための準備
- 公開後の保守にかかる費用と、発注前の確認事項
「アプリを作りたいけれど、予算も頼み先も決められない」 調べ始めると金額に幅があり、自社の場合はいくらなのか迷いますよね。 画面や機能を細かく決めてからでないと、相談できないと感じるかもしれません。
仕様が決まっていなくても、企画や要件整理に対応する依頼先へ相談できます。 最初は、誰が使い、何をできるようにしたいかを伝えられれば大丈夫です。 そこから初回の開発範囲を整理し、費用や公開後の対応を具体化していきましょう。
この記事では、店舗の予約アプリを例に、外注を検討する順番を紹介します。 主にスマートフォン向けのアプリを想定していますが、社内向けの開発にも使える考え方です。
アプリ開発の費用は、機能と任せる範囲で変わる
費用を考えるときは、作る機能に加えて、設計や試験に必要な作業も確認しましょう。 「予約アプリ」という同じ名前でも、店舗数や予約のルールで開発内容は変わります。 一店舗の予約受付と、複数店舗の空き枠をまとめて管理する仕組みでは、必要な処理が違うためです。
金額に影響する条件をそろえる
相談時には、次の条件を伝えると見積もりの前提を整理しやすくなります。 決まっていない欄は「未定」のままで構いません。
| 費用が変わる条件 | 確認する内容 | 作業が増える例 |
|---|---|---|
| 対応する端末 | iPhone、Android、タブレットなど | 対応端末が増え、表示や動作の確認が増える |
| 機能と処理の複雑さ | 予約、会員登録、決済、通知など | キャンセル時の返金や、重複予約を防ぐ処理を加える |
| 管理者向けの機能 | 店舗側が予約や顧客情報を操作する画面 | 店舗ごとに閲覧・変更できる範囲を分ける |
| 既存システムとの接続 | 顧客管理や在庫管理とのデータのやり取り | 接続先の調査や、相手側の改修が必要になる |
| 利用人数と利用環境 | 同時に使う人数、通信できない場所での利用 | 予約開始直後の集中や、通信切断に対応する |
| デザインと使いやすさ | 独自の画面、操作の試作、利用者による確認 | 試作と確認を繰り返し、操作方法を調整する |
| 希望納期 | 公開希望日と、その日までに必要な機能 | 短期間に進めるため、担当者の追加や調整が必要になる |
iPhoneとAndroidの両方に対応しても、費用が必ず二倍になるわけではありません。 共通に作れる部分と、端末ごとに調整する部分があるからです。 見積もりでは、対応範囲と確認する端末の条件を聞いておきたいですね。
予約受付が目的なら、Webアプリ（ブラウザーで使うアプリ）も比較候補になります。 インストールする形式が必要か、利用者の使い方から相談しましょう。 端末の機能を使う条件や通知の要件によって、適した作り方は変わります。
開発費は作業量と単価に分けて見る
作業費の基本的な考え方は、工数（必要な作業量）と単価の掛け合わせです。 そこに、利用するサービスの費用などが加わる場合があります。
たとえば、ある作業が20人日で、一人日あたりの単価が6万円なら、作業費は120万円です。 人日とは、一人が一日働く量を一単位とする数え方を指します。 これは税抜の架空の計算例で、アプリ開発の相場や総額を示すものではありません。
見積書では、要件整理、画面設計、開発、試験、公開支援の内訳を確認しましょう。 利用者向けの画面に加えて、管理画面やデータを保存する仕組みも見ておきます。 同じ条件で比べるには、「含まれる作業」と「別料金の作業」をそろえることが大切です。
予算が合わない場合は、初回に作る機能を絞る方法があります。 予約の受付とキャンセルを先に作り、クーポン配信は利用状況を見て追加する、といった進め方です。 ただし、後から追加する際にも設計や試験の費用はかかります。 将来加えたい機能は先に伝え、初回にどこまで備えるかを相談してください。
開発会社と個人への依頼は、担当できる範囲で比べる
依頼先を選ぶときは、自社でどこまで進行や確認を担えるかも考えましょう。 企画段階から相談したい場合と、決まった機能だけを作ってほしい場合では、必要な支援が違います。
次の表は、依頼先を比較するための目安です。 会社でも少人数で担当する場合があり、個人でも協力者とチームを組む場合があります。 実際の担当者と体制を確認してください。
| 比較する点 | 開発会社に依頼する場合 | 個人に依頼する場合 |
|---|---|---|
| 担当範囲 | 設計・開発・試験を分担する体制を相談できる | 得意分野と、一人で担当できる範囲の確認が必要 |
| 費用 | 進行管理や複数担当者の費用も含めて確認する | 直接やり取りする場合も、設計や試験の費用を確認する |
| 相談の進め方 | 窓口と実際の開発担当者が異なる場合がある | 開発担当者と直接調整できる場合がある |
| 不在時の対応 | 代わりの担当者がいるか、引き継ぎ方法を聞く | 休業時の連絡や、協力者による対応の可否を聞く |
| 公開後の保守 | 保守窓口と対応時間、担当体制を確認する | 継続対応できる期間と、確保できる時間を確認する |
| 自社に必要な役割 | 社内の要望をまとめ、提案を判断する担当者 | 依頼範囲によっては、進行管理や他の担当者との調整も必要 |
複数の業務との調整や、継続した保守窓口が必要なら、その体制を持つ開発会社が候補です。 範囲を絞った試作などで、自社に進行を管理できる人がいれば、個人への依頼も検討できます。 個人なら必ず安い、会社ならすべて任せられる、とは限らない点は押さえておきましょう。
実績は「どこを担当したか」まで聞く
似たアプリの実績を見るときは、担当した機能や公開後の対応まで聞いてみてください。 画面だけを作ったのか、予約処理や管理画面まで担当したのかで、経験の範囲は違います。 今回の担当者が、その実績に関わったかも確認したいところです。
相談中は、説明のわかりやすさも判断材料になります。 未定の項目を質問してくれるか、予算内に収める案と制約を説明してくれるかを見てみましょう。 たとえば、予約機能の経験だけでなく、予約が重なった場合の扱いまで話せるかが参考になります。
仕様が未定なら、目的と困りごとを一枚にまとめる
最初の相談では、完成した仕様書よりも、現在の業務や利用場面がわかる資料が役立ちます。 仕様書は、画面や動作など、作るものの内容をまとめた資料です。 手元にある予約表や、参考にしたいアプリの画面から話を始めても構いません。
相談前に用意したいメモ
店舗の予約アプリなら、次のように書ければ相談のたたき台になります。 数値は記入例なので、自社の状況に置き換えてください。
| 伝えること | 記入例 |
|---|---|
| 目的と現在の困りごと | 電話予約への対応を減らし、営業時間外も予約を受け付けたい |
| 利用者 | お客様と店舗スタッフ。一店舗から始めたい |
| 最初に必要なこと | 空き枠の確認、予約、キャンセル、店舗側の予約一覧 |
| 相談して決めたいこと | 会員登録や事前決済が必要か。Webでも実現できるか |
| 今あるもの | 紙の予約表、店舗サイト、ロゴ、サービスの写真 |
| 予算 | 初期費用の上限と、毎月使える運用予算。社内承認はこれから |
| 公開時期 | 来春を希望。間に合う範囲と、段階的な公開を相談したい |
| 社内の担当者 | 店長が業務を説明し、責任者が予算と開発範囲を決める |
予算も未定なら、社内で検討するための概算がほしいと伝えましょう。 必要な機能を絞った案と、追加機能を含む案に分けてもらうと、判断しやすくなります。
そのまま使える相談文の例はこちらです。
店舗の電話予約を減らすため、予約アプリを検討しています。 仕様は未定ですが、空き枠の確認と予約受付をできるようにしたいです。 現在の予約表をもとに、必要な機能と作り方から相談できますか。 初期費用の概算、公開までの期間、保守費用を知りたいです。 初回相談と、その後の要件整理が有料になる範囲も教えてください。
要件整理を依頼し、開発範囲を決める
相談後は、要件定義（必要な機能や利用条件を整理して合意する作業）へ進みます。 IPAも、要件定義を利用者側と開発者側の認識を合わせる工程として説明しています。 参考：IPA「要件定義とは？」( https://dx.ipa.go.jp/youken-teigi )
仕様が未定の段階では、要件整理の費用と、その後に開発を判断できる区切りを確認しましょう。 無料相談でわかることと、有料の調査や設計で決めることを分けておくと安心です。 整理した機能一覧や画面案を受け取れるかも聞いておいてください。
最初の概算には、まだ確認できていない条件が含まれることがあります。 既存システムとの接続方法などが決まった時点で、見積もりを更新する流れです。 追加費用が発生する条件と、変更を承認する人も決めておきましょう。
発注前に、完成の基準と公開までの役割を決める
発注するときは、どの状態になれば完成とするかを、依頼先と文書で共有します。 予約アプリなら「予約できる」だけでは、確認する範囲があいまいです。 満席時の表示、予約の重複、キャンセル後の空き枠など、実際の操作に沿って整理しましょう。
自社でも、受入確認（依頼した内容どおりに使えるかを確かめる作業）の時間を確保します。 店舗スタッフに操作してもらう日程も、開発計画に入れておきたいですね。 修正後の再確認を誰が行うかまで決めると、公開前の作業を進めやすくなります。
公開については、次の役割も確認してください。
- アプリストアへ申請する担当者と、修正を求められたときの対応範囲
- ストア掲載文や画像、利用者向けの案内を用意する担当者
- 公開用アカウントの名義と、発注側が持つ管理権限
- 公開の判断をする人と、希望日に間に合わない場合の進め方
プログラムの完成日と、利用者が使い始められる日は分けて確認しましょう。 支払い時期についても、何を納品・確認した段階で支払うかをそろえておきます。
公開後の保守まで含めて、予算と依頼先を決める
保守とは、不具合の修正や、使い続けるための更新などを行うことです。 開発時の見積もりとあわせて、公開後の費用と対応範囲も出してもらいましょう。
Appleの公式案内でも、公開後の更新や、利用者のレビュー・アプリの動作状況の確認を挙げています。 公開後に誰が状況を見て、修正を依頼するかまで決めておきたいですね。 参考：Apple「Overview of maintaining an app」( https://developer.apple.com/help/app-store-connect/update-your-app/overview-of-maintaining-an-app )
月額の保守費に何が含まれるかを確認する
「保守あり」という記載だけでは、頼める作業を判断できません。 次の項目を、月額に含むものと、別料金になるものに分けてもらってください。
| 確認する項目 | 聞いておきたい内容 |
|---|---|
| 不具合の修正 | 開発費に含む修正の期間・条件と、保守契約で扱う範囲 |
| 端末や外部サービスの変更 | OS（端末の基本ソフト）の更新や、接続先の変更に伴う確認・修正 |
| 安全性の維持 | ソフトの弱点への対処や、利用者情報を守る設定の確認 |
| 障害時の連絡 | 受付時間、連絡方法、調査を開始するまでの目安 |
| データの保護 | バックアップ（復旧用の複製）の頻度と、復元作業の費用 |
| 機能追加 | 画面や機能の変更を、どの規模から別途見積もりにするか |
問い合わせを受け付ける時間と、復旧までの時間は別の条件です。 休日も予約を受け付けるなら、休日に止まった場合の連絡と対応を確認しましょう。 月額内の作業時間に上限があれば、超過時の単価や承認方法も聞いておきます。
運用費と、将来の引き継ぎも見ておく
保守の作業費以外に、サーバー（データの保存や処理を担うコンピューター）の利用料も検討の対象です。 外部サービスの利用料や、公開用アカウントの維持費が必要な場合もあります。 誰に、いつ、いくら支払うかを整理してください。
たとえば公開後一年間の予算なら、初期費用と月額費用の12か月分を合わせます。 別途の年額費用や、予定している追加開発費も加え、同じ費用を二重に数えないようにしましょう。 利用者数で変わる料金は、想定人数をそろえて比較することが大切です。
また、依頼先を変更するときに必要なものも、発注前に確認しておきます。 ソースコード（アプリの動作を記述したプログラム）や設計資料を受け取れるかは、その一つです。 受け取ったものを他の担当者が改修できる条件も、文書に残してもらいましょう。 アカウントの管理権限、データの取り出し方、引き継ぎ支援の費用も確認したいところです。
おわりに
アプリ開発の外注を考え始めたら、まず「誰の、どんな困りごとを減らしたいか」を書いてみてください。 そこに初回に必要な機能と、まだ決まっていないことを添えれば、相談用のメモになります。
そのメモをもとに、初期費用と保守費用、依頼先が担当する範囲を確認していきましょう。 細かな画面や技術の選定は、依頼先と話しながら具体化できます。 今使っている資料を用意して、「この段階から相談できますか」と伝えるところから始めてみてください。