アプリの開発費用に、一般的な相場はありますか？

単一の相場で判断するのは危険です。同じ『顧客管理アプリ』でも、利用者数、画面数、権限、外部連携、データ移行、テスト水準で作業量が変わります。まず各社の見積に含まれる工程と成果物を揃え、その後に金額を比較します。

見積書で最初に確認する項目は何ですか？

対象範囲と対象外です。要件定義、データ移行、受入テスト、操作説明、公開後の不具合対応が含まれるかを確認してください。『開発一式』だけでは、公開までの総額を比較できません。

開発費用を抑えるには、機能を減らすしかありませんか？

機能数だけでなく、例外処理、権限、連携、データ品質を整えると手戻りを減らせます。最初に成果指標を1つ決め、主要業務を一巡できる最小範囲で公開し、実測後に追加する方法が有効です。

アプリの開発費用はどう決まる？見積内訳と予算を決める5ステップ

「顧客管理アプリを作りたい」と3社へ相談したら、見積額が大きく違った。安い会社はどこまで含み、高い会社は何を厚く見ているのか分からない。ここで平均額だけを探しても、発注判断は楽になりません。

アプリの開発費用は、名称ではなく作る範囲と不確実性で決まります。費用を考える基本式は次の通りです。

開発費＝要件定義＋設計＋実装＋テスト＋データ移行＋運用準備＋管理＋予備

この記事では市場平均を断定しません。代わりに、見積を同じ土俵へ揃え、自社で予算の上限と最初の開発範囲を決める方法を示します。

相場を探す前に、発注方法を3つに分ける

同じ「アプリ開発」でも、既製サービスを設定する場合と、業務に合わせて個別開発する場合では、費用の中身が違います。最初から個別開発を前提にせず、次の順で代替できないかを確認します。

選択肢	向く状態	見落としやすい費用	次へ進む条件
SaaS・既製サービス	標準機能へ業務を合わせられる	初期設定、データ移行、利用者教育、月額・従量課金	重要な業務要件を満たせない
ノーコード・ローコード	社内業務中心で、画面や承認を早く試したい	複雑な連携、権限、運用者の学習、製品制約	制約回避の作業が標準開発より重くなる
個別開発	固有の業務・顧客体験が競争力になる	要件定義、テスト、移行、保守、改善、移管	成果指標と初回範囲を決めて発注する

この比較で重要なのは、初期費用だけでなく、公開後に使い続けるための総費用を見ることです。既製サービスでも設定・移行・教育は発生し、個別開発でも最初の範囲を絞れば段階的に試せます。

アプリの開発費用に差が出る7つの内訳

内訳	主な作業	費用が増える要因
要件定義	対象業務、利用者、権限、例外、成果指標を決める	部署間でルールが違う、例外が未整理
設計	画面、データ、権限、連携、非機能要件を設計する	項目や状態が多い、複雑な承認がある
実装	画面、処理、通知、帳票、連携を作る	画面数、独自処理、外部APIが多い
テスト	単体、結合、システム、受入の各確認を行う	端末や権限の組合せ、重要度が高い
データ移行	既存データを整理、変換、投入、照合する	重複・欠損・表記揺れが多い
運用準備	手順、教育、問い合わせ、障害対応を決める	利用者が多い、引き継ぎ資料がない
管理・予備	進行、品質、変更、リスクを管理する	未決事項が多い、意思決定が遅い

IPAのソフトウェア開発データでは、基本設計、詳細設計、製作、結合テスト、総合テストを開発5工程として扱います。一方、要件定義や移行、インフラ、運用などの扱いはプロジェクトによって異なります。つまり、2社が同じ「開発費」と書いていても、含む工程が同じとは限りません。

予算を決める5ステップ

1｜目的を「機能」ではなく「変える数字」で決める

「日報アプリを作る」ではなく、「週次集計を3時間から30分へ減らす」のように置きます。成果指標がなければ、便利そうな機能が際限なく増えます。最初の指標は、作業時間、転記回数、入力漏れ、判断までの日数のどれか1つで十分です。

2｜現在の業務と例外を一枚にする

開始、入力、確認、承認、完了までを並べ、担当者と使う情報を書きます。特に費用へ効くのは「通常とは違うとき」です。値引き時だけ役員承認、契約種別ごとに帳票が違う、といった例外を後で発見すると設計と実装を戻します。

3｜画面・データ・権限・連携を数える

概算を依頼する前に、画面、主要データ、利用者の権限、外部連携を一覧にします。IPAが紹介する見積手法でも、機能や画面、テーブルなどの規模と、複雑性・信頼性・体制が入力になります。「何となく便利なアプリ」では、見積側も大きな安全幅を置くしかありません。

画面：一覧、詳細、登録、承認、集計
データ：会社、担当者、案件、活動、請求
権限：一般、管理者、経営者、外部委託先
連携：メール、会計、チャット、既存基幹

4｜同じ見積依頼書で、内訳と対象外を出してもらう

各社へ同じ資料を渡し、工程別の工数、成果物、前提、対象外、追加費用になる条件を回答してもらいます。比較表の列は「総額」より先に「含まれる工程」と「含まれない作業」を置きます。

すでに見積を受け取っているなら、システム見積もりを判断する5つの観点も使えます。

5｜変更費と公開後の費用を別枠で持つ

開発中に分かることは必ずあります。変更をゼロにするのではなく、誰が変更を承認し、納期・費用への影響をどこへ記録するかを決めます。公開後も保守、問い合わせ、アカウント管理、改善が続きます。初期開発費だけでなく、運用責任者の工数まで予算に入れます。

見積を同じ条件で比べるフォーマット

比較列	記入する内容	確認責任者
目的・成果指標	解決する業務、現状値、公開後に変える数字	事業責任者
利用者・権限	利用者数、役割、閲覧・編集・承認の範囲	業務責任者
画面・データ・連携	主要画面、データ項目、外部サービス、連携頻度	業務＋システム担当
対象工程	要件定義、設計、実装、テスト、移行、教育、保守	発注責任者
成果物・検収	納品物、受入条件、不具合区分、確認期間	受入責任者
対象外・変更	含まれない作業、追加費用条件、再見積の手順	決裁者
公開後	保守、問い合わせ、障害対応、改善、移管条件	運用責任者

金額を人月で確認する場合も、単価だけで判断しません。たとえば「合意した単価×必要工数」で計算できますが、必要工数の前提が違えば総額は変わります。過去案件の実績とリスク要因を使う見積方法もあり、IPAのCoBRAは組織固有の実績データを使って見積精度を高める考え方を示しています。

予算超過が起きやすい3つの境目

要望が要件へ変わる前

「できれば欲しい」と「初回公開に必須」が混ざると、見積の途中で範囲が膨らみます。必須、後続、対象外の3区分にし、初回公開後に測る指標まで決めます。

既存データを移すとき

件数だけでなく、重複、欠損、表記揺れ、過去データの保持範囲が工数へ効きます。移行元ごとに件数と品質を確認し、誰が修正し、誰が照合するかを見積条件へ入れます。

公開から運用へ渡すとき

利用者登録、問い合わせ、障害時の判断、マニュアル更新が未定だと、公開後に担当者へ負荷が集中します。開発完了と業務で使える状態を分け、運用開始までの作業を予算に含めます。

公開後に測る5つの数字

見積差：計画工数と実績工数の差
変更要求数：合意後に追加・変更した件数
受入不具合数：業務側の確認で見つかった問題
成果までの日数：着手から現場利用までの日数
運用工数：問い合わせ、手直し、集計に使う時間

初回から完璧な予算を当てるより、実績を次の見積へ戻す方が精度は上がります。数値を残せば、2回目以降は自社の業務に合った基準を持てます。

来週やること

対象業務を1つに絞り、短くしたい時間を決める
通常フローと例外を付箋または表で書く
画面・データ・権限・連携を数える
既存見積に7つの内訳が含まれるか印を付ける
不足項目を同じ質問文で各社へ確認する

これだけで、価格だけの比較から、業務と成果物の比較へ移れます。

まとめ

アプリの開発費用は、アプリの名前だけでは決まりません。要件定義、設計、実装、テスト、移行、運用準備のどこまでを含むか、未決事項と例外がどれだけあるかで変わります。目的を数字で決め、業務を一巡させ、見積条件を揃える。この順番なら、発注判断を一人の勘から会社の基準へ移せます。