アプリ開発の費用｜内訳と相場の決まり方・抑える順番

アプリ開発の見積もりを3社に頼むと、金額が3倍違うことがあります。よくある説明は「会社によって単価が違うから」ですが、単価表を見比べても3倍の差は説明できません。

今日は、アプリ開発の費用がなぜ数倍ぶれるのか、どの発注先だとどう決まるのか、という話をしていこうと思います。この記事は、発注先を6つの類型に分けます。そして類型ごとに、代表的な会社の公式サイトの実物（ファーストビューのスクリーンショット）と、各社が自分で書いているディスクリプション（検索結果に出す自己紹介文）を並べて比較します。紹介記事の伝聞ではなく、各社が自分のサイトで名乗っている言葉を一次情報として使います。あわせて、費用のぶれ幅の大きさを、公開されている調査データの実数で確かめます。

先に結論を一行だけ置きます。アプリ開発の費用を動かしているのは、時間あたりの単価ではなく、仕様が決まるまでの往復の回数です。 6つの類型は、この「決まっていない量」をどう扱うかで分かれています。

① 費用を動かしているのは、単価ではなく「決まるまでの往復」。

アプリ開発の費用の決まり方をすでにご存じの方は、② 公開データで、ぶれ幅がどれくらいかを確かめるから読み進められます。

アプリ開発の費用は何で決まるのか

見積書の金額は、突き詰めると人件費（人月単価）× 開発期間 ＋ 諸経費でできています。相場表を先に見るより、この3つのどれが自社の条件で膨らむのかを見るほうが実用的です。

要素	何で変わるか
人月単価	担当する人の役割と技術、発注先の所在地と体制
開発期間	機能の数と複雑さ、対応OS、そして決まっていない項目の量
諸経費	サーバー・インフラ、外部サービスの利用料、ストアの登録費

相場表が当てにならないのは、2つ目の最後の項目が入っていないからです。同じ機能でも、決まっていない項目が多いほど期間は伸びます。

内訳1｜人件費（人月単価）

1人が1か月働いたときの費用です。役割（設計・実装・デザイン・テスト・管理）ごとに単価が違い、誰が何人月入るかの内訳が書かれていない見積書は比較できません。

単価の安さだけで選ばないでください。単価が低くても、仕様を書き切る作業が発注側に残るなら、その工数は自社の人件費として発生しています。

内訳2｜開発期間

期間は、機能の数、対応するOSの数、外部システムとの連携の本数で決まります。

もっとも読みにくいのは、決めるのにかかる時間です。実装そのものより、「どうするかを決めて、確認して、直す」往復のほうが期間を押し広げます。

内訳3｜諸経費とリリース後の維持費

開発費とは別に、続けて発生する費用があります。

• サーバー・インフラの維持 — 利用者が増えると増える
• OSのアップデート対応 — 年に数回、必ず来る
• 不具合の修正
• 機能の改善と追加
• ストアの年間登録料と、外部サービスの利用料
• 運用のサポート・問い合わせ対応

2つ目を見積もりに入れていない計画をよく見ます。OSの更新はこちらの都合で止められません。作った後に必ず来る費用として、初年度から見込んでください。

開発手法によって費用はどう変わるか

手法	中身	費用と自由度
フルスクラッチ	ゼロから作る	高い／制限が無い
ハイブリッド（クロスプラットフォーム）	1つのコードでiOS/Androidに対応	中／2OS対応の費用を圧縮できる
パッケージ・クラウド型	既製の土台に載せる	低〜中／土台の範囲内
ノーコード・ローコード	画面の設定中心で作る	低い／できることの上限がある

手法は、費用ではなく「変え続けるかどうか」で選んでください。出したあとに頻繁に変える前提なら、初期費用が低い手法が結果的に高くつくことがあります。

アプリの種類別（ネイティブ・Web・ハイブリッド）

• ネイティブアプリ — 端末の機能（カメラ、通知、位置情報）を使い切れる。OSごとに作るぶん費用が上がる
• Webアプリ — ブラウザで動く。ストア審査が要らず、更新が速い
• ハイブリッド — 中間。1つの土台で両OSに配れる

ストアに出す必要があるかを先に確かめてください。社内利用や特定の顧客向けなら、Webアプリで足りることが多く、審査と更新の手間が消えます。

規模と対応OSで、どのくらい変わるか

規模は、画面の数と、扱うデータの種類で見ます。

• 小規模 — 情報の表示と簡単な入力が中心
• 中規模・業務系 — 会員管理、権限、既存システムとの連携が入る
• 大規模 — 決済、外部連携が多数、大量の同時利用

対応OSは、費用に直接効きます。iOSとAndroidの両方をネイティブで作れば、テストの工数も2倍になります。片方から始めて反応を見る、という選択肢を先に検討してください。

機能ごとに上乗せされる費用

見積もりが膨らむのは、たいてい次の機能です。

• 会員登録・ログイン（外部アカウント連携を含む）
• 決済 — 審査、返金、明細の扱いまで要る
• プッシュ通知 — 配信の管理画面も必要になりやすい
• 既存システム・顧客管理との連携 — 本数がそのまま費用
• 地図・位置情報、チャット、動画 — 外部サービスの利用料が継続で発生
• 管理画面 — 利用者向け画面と同じくらいの分量になることがある

最後の管理画面が、見積もりから抜けやすい項目です。運用する人が使う画面が無いと、結局そこを人の手作業で埋めることになります。

デザイン（UI/UX設計）とインフラ・セキュリティ

デザインは、画面を整えるだけの範囲か、使われ方から設計し直す範囲かで費用が変わります。

インフラとセキュリティは、扱う情報の種類で必要な水準が決まります。個人情報、決済情報、位置情報を扱うなら、対策と監査のぶんを最初から見込んでください。後から足すほうが高くつきます。

工程ごとの費用の配分

工程	やること	見落とされやすい点
要件定義	何を作るかを決める	ここを削ると、後の工程が膨らむ
設計	画面とデータの構造を決める	管理画面の設計が抜けやすい
実装	作る	見積もりの中心はここだが、比率は思ったより低い
テスト	確かめる	対応OSの数だけ増える
リリース	審査・公開	ストア審査で差し戻されると期間が伸びる

要件定義の費用を値切ると、総額は上がります。決まっていない項目は消えず、後の工程で往復として現れるためです。

発注のしかたと、それぞれの費用感

発注先	向いているとき	注意
自社で作る	継続して作り変える。人がいる	採用と育成の費用が別に要る
開発会社に外注	一定の品質と体制が要る	選定を誤ると費用がかさむ
個人・フリーランス	小規模、範囲が明確	体制の代替が効かない
クラウド・パッケージのサービス	早く安く出したい	できることの範囲が決まっている

「作らずに済ませられないか」を先に検討してください。既製のサービスで確かめてから作ると、作る範囲そのものが小さくなります。

外注するメリットとデメリット

• メリット — 自社に技術者がいなくても作れる／一定の品質が見込める／費用を変動費にできる／公開後の保守も任せられる
• デメリット — 社内にノウハウが残らない／選定を誤ると費用がかさむ／仕様を伝える工数が自社に残る

ノウハウを残したいなら、契約に何を残すかを書いてください。ソースコードの権利、設計書の納品と更新、運用手順書。これが無いと、次の発注先を選べなくなります。

見積もりの取り方と、見積書で確認すること

• 同じ条件で複数社に出す — 条件が違うと比較にならない
• 金額だけで比べない — 何が含まれ、何が含まれないかを見る
• 保守・運用費まで含めて比べる — 初期費だけの比較は2年目にずれる
• 内訳の粒度を見る — 「一式」が多い見積書は、後から増えやすい
• セキュリティと拡張性の扱いを聞く
• 安すぎる見積もりを疑う — 含まれていない工程が、後から追加費用として出てくる

いちばん効く質問は「この見積もりに含まれていないものは何ですか」です。含まれるものの一覧は各社が書きますが、含まれないものの一覧は、聞かないと出てきません。

費用を抑える方法

方法	効き方
要件定義を先に固める	もっとも効く。往復の回数が減る
MVPで小さく出す	作る範囲そのものを減らす
クロスプラットフォームにする	2OS対応の費用を圧縮する
ノーコード・既製サービスを使う	作らずに済ませる範囲を増やす
工程ごとに契約形態を分ける	決まっていない工程を準委任、決まった工程を請負にする
相見積もりを取る	条件を揃えたうえで比べる
補助金を活用する	自己負担を下げる

安くする順番があります。まず作る範囲を減らし、次に作り方を変え、最後に単価を見ます。順番を逆にすると、単価だけ下がって総額が変わらない結果になります。

補助金・助成金の使い方

アプリやシステムの開発で使われるものには、ものづくり補助金、IT導入補助金、事業再構築の枠、小規模事業者持続化補助金などがあります。

補助金は後払いです。採択されても支払いは実績報告の後になるため、立て替える資金が要ります。対象になる経費の範囲と、報告に必要な書類の量を申請前に確認してください。

費用を概算するときの順番

相場表から入らず、次の順で自分の条件を埋めると、各社の見積もりを読めるようになります。

• 1. 出す先を決める — ストアに出すか、Webで足りるか
• 2. 対応OSを決める — 片方から始められないか
• 3. 画面と機能を数える — 管理画面を忘れずに
• 4. 連携する外部システムの本数を数える
• 5. 扱う情報の種類を書き出す — 個人情報・決済の有無
• 6. 決まっていない項目に印を付ける

6が、この記事の主題です。1〜5は各社の見積もりでほぼ同じ結論になりますが、6の扱い方だけは、発注先によってまったく違います。

アプリ開発の費用についてよくある質問

Q. アプリ開発の費用は、何で決まりますか。
人月単価 × 開発期間 ＋ 諸経費です。期間を動かすのは機能の数、対応OSの数、外部連携の本数、そして決まっていない項目の量です。

Q. 費用を抑えるには、何から手を付ければよいですか。
まず作る範囲を減らし、次に作り方（手法）を変え、最後に単価を見ます。順番を逆にすると、単価だけ下がって総額が変わりません。要件定義を先に固めるのが、もっとも効きます。

Q. 見積もりで見落とされやすい費用は何ですか。
運用側が使う管理画面、OSのアップデート対応、テストの工数（対応OSの数だけ増える）、そして外部サービスの継続利用料です。

Q. 見積もりを比べるとき、何を聞けばよいですか。
「この見積もりに含まれていないものは何ですか」です。含まれるものの一覧は各社が書きますが、含まれないものの一覧は聞かないと出てきません。

Q. リリース後は、どんな費用がかかりますか。
サーバーとインフラの維持、OSアップデート対応、不具合の修正、機能の改善、ストアの年間登録料、外部サービスの利用料、運用サポートです。初期費だけで比較すると、2年目に差が出ます。

費用の式は、どの会社でもほぼ同じです。人数 × 期間 × 単価。式そのものは正しいものです。ところが、この式には「期間」を膨らませる変数が隠れています。仕様が決まるまでの往復の回数です。

アプリの開発では、プログラムを書き換えるたびに、いつ・どのファイルを・何回直したかが履歴として残ります。発信元（ARCHECO）の開発記録にある実測を1つだけ引きます。着手前に決めごとを文書化せずに作った機能では、関連ファイルの変更が362回に達しました。一方、同じチーム・同じ道具でも、結果が変わった機能があります。作る手順を10段階に割り、確かめる項目を31個書き出してから着手したもので、こちらは25回で完了しています。362回と25回。単価は同じでも、費用は十数倍の差になります。

つまり、見積もりを比較する前に見るべきなのは、単価の欄ではありません。「決まっていない項目を、誰が、どの工程で、何回の往復で決めるか」の扱いです。6つの類型は、ここへの答え方がそれぞれ違います。

この記事の後半では、その扱い方の違いを、発注先の6類型に分けて見ていきます。

② 公開データで、ぶれ幅がどれくらいかを確かめる

感覚の話に留めないために、一次資料（調査元が直接公表した資料）を2つ置きます。どちらも無料で全文が読めます。

IPA（独立行政法人情報処理推進機構）の『ソフトウェア開発分析データ集2022』は、5,546プロジェクトの定量データを分析したものです。2022年9月26日公開。企業の業務システムの実績値が、工数・工期・規模・生産性の別に載っています。

工数から見ます。単位は人時で、1人が1時間働く量を1と数えます。データのある1,444件で、プロジェクト全体の工数の中央値は7,395人時でした。1人が1日8時間働くとして、およそ920日ぶんです。

ただし、中央値ではなく、ばらつきが本題です。件数を小さい順に並べて4等分したとき、下から4分の1の地点（第1四分位）が3,105人時、上から4分の1の地点（第3四分位）が20,446人時でした。極端に小さい案件と極端に大きい案件を捨てて、真ん中の半分だけを取り出しても、上下で6.6倍の開きがあるという意味になります。

工期にも同様のばらつきがあります。1,396件で、工期の中央値は10.1か月。第1四分位が6.0か月、第3四分位が15.0か月です。IPAはこの中央値について「2014年度〜2019年度と比較して、1ヶ月多くなっている」と書いています。つまり、3社の見積もりが3倍違うのは異常値ではありません。公開されている実績のばらつきの範囲に、きれいに収まっています。

もう1つ。JUAS（日本情報システム・ユーザー協会）の『企業IT動向調査2025』は、2024年度の調査結果を2025年4月10日に公表したものです。こちらは規模を人月で区切っています。業務アプリを1本作る規模なら、たいてい、いちばん小さい100人月未満の区分に入ります。

工期が「予定どおり完了」した割合は、その100人月未満のプロジェクトで31.0%でした（回答694件）。100〜500人月未満では393件のうち16.0%、500人月以上では245件のうち11.0%。規模が大きくなるほど、予定どおりに終わらなくなります。 そして、いちばん小さい区分でも、予定どおり終わったのは3件に1件です。JUASは「10年間（15〜24年度）の推移では、すべてのプロジェクト規模で『予定どおり完了』の割合が低下傾向にあり、24年度においても改善の兆候は見られない」と書いています。

ここで、同じ工期を扱う2つの資料に大きな差が出ます。IPAの集計では、開発した側の自己評価で工期が「ほぼ計画以内」だったプロジェクトが約90%ありました。同じ工期の話で、IPAは90%、JUASは31.0%です。差を生んでいるのは実態ではなく、問いの立て方です。費用の議論も同じで、何を数えるかを決めないうちは、どの数字も正しく見えます。

③ 発注先は6類型に分かれる。分ける軸は「決まっていない量」。

発注先の候補は、規模や国ではなく、「決まっていない量をどう扱うか」で分けると選びやすくなります。この記事では6つの類型に分けます。

1. A. グローバル総合型 ── 決まった大規模要件を、統制をかけて確実に動かす。
2. B. プロダクトエンジニアリング型 ── 変え続けても壊れない設計で作る。
3. C. デザイン起点型 ── 使う人の行動から、作るものの形を決める。
4. D. オフショア・ラボ型 ── 決まった仕様を、単価あたりの投入量で量産する。
5. E. ローコード／ノーコード型 ── 標準部品で「作らずに済む範囲」を先に確かめる。
6. F. AI活用の共創型 ── 決める工程そのものに入り、往復の回数を減らす。

④ 6類型の比較表

類型	代表的な会社	強い場面	噛み合わない場面
A. グローバル総合型。	アクセンチュア、TCS、インフォシス、NTTデータ。	止められない大規模業務、監査対応。	小規模案件（統制の分まで払う）。
B. プロダクトエンジニアリング型。	Thoughtworks、EPAM、Globant。	長く変え続ける製品の設計。	何を作るか未定の段階。
C. デザイン起点型。	IDEO、グッドパッチ。	「動くのに使われない」の防止。	大量の実装・運用体制。
D. オフショア・ラボ型。	FPTソフトウェア。	仕様確定後の量産。	仕様が固まる前（往復が高くつく）。
E. ローコード／ノーコード型。	OutSystems、Mendix、Power Apps。	標準業務の高速立ち上げ。	標準から外れた業務、利用料の累積。
F. AI活用の共創型。	ARCHECO。	決まっていない段階からの伴走。	決まりきった大規模量産。

以下、類型ごとに実在の会社を置きます。スクリーンショットは各社の公式サイトのファーストビュー（2026年8月取得）、引用文は各サイトのディスクリプションの原文です。 記述は公開情報に基づく整理であり、契約前には必ず各社へ最新の内容を確認してください。

⑤ A. グローバル総合型 ── 規模と統制

数千人が使うシステムを、決めた期日に、決めた品質で動かす類型です。強いのは、止められない業務を載せられること。基幹システムとの連携や、法令対応の継続も含めて引き受けられます。見積書に「非機能要件の定義とテスト計画」という行が立っていたら、この類型の作法です。一方で、小規模案件とは噛み合いません。統制の作り込みそのものに工数がかかるため、要らない安全装置の分まで払うことになります。

アクセンチュア

公式ディスクリプション:「アクセンチュアは、ストラテジー & コンサルティング、テクノロジー、オペレーションズ、インダストリーX、ソングの領域でサービスを提供する総合コンサルティング企業です」。

日本TCS（タタ・コンサルタンシー・サービシズ）

公式ディスクリプション:「日本TCS(Tata Consultancy Services Japan)は、世界的なITサービス企業であるタタコンサルタンシーサービシズの一員として、日本企業に向け先進性・合理性を兼ね備えたITサービス・ソリューションを提供しています」。インド発で、世界有数の技術者数を抱えます。

インフォシス

公式ディスクリプション:「Infosys is a global leader in next-generation digital services and consulting.」。訳すと、次世代デジタルサービスとコンサルティングのグローバルリーダー。同じくインド発の大手です。

NTTデータ

公式ディスクリプション:「NTTデータグループのウェブサイトです。NTTデータグループのビジョン、経営戦略、ニュース、IR、サステナビリティなどの情報をご覧いただけます」。国内最大手にあたります。

4社のサイトを並べると、共通点が見えます。製品の画面ではなく、変革・戦略・産業の言葉が先頭に来ることです。個別のアプリを作る話より前に、業務全体を引き受ける立て付けで書かれています。この名乗り方が、そのまま見積もりの構造（統制と体制の費用が乗る）に対応しています。

⑥ B. プロダクトエンジニアリング型 ── 変え続けても壊れない設計

他社の製品開発を丸ごと引き受けるソフトウェア専業の類型です。強いのは、あとから変えることを前提に作れること。アプリは作った瞬間がいちばん単純で、そのあと必ず複雑になります。5年後に触れる状態で残っているかどうかは、最初の設計で決まります。弱いのは、そもそも何を作るかが決まっていない段階です。設計の力は、対象が定まってから効きます。

Thoughtworks

公式ディスクリプション:「We are laser-focused on transforming your digital journey so you can make extraordinary impact.」。訳すと、お客様のデジタルの旅の変革に集中し、並外れたインパクトを生み出す。『リファクタリング』の著者マーティン・ファウラーが、Chief Scientist（最高科学責任者）として在籍しています。ファウラーは2001年の「アジャイルソフトウェア開発宣言」の起草者の1人です。

EPAM Systems

公式ディスクリプション:「Since 1993, we’ve helped customers digitally transform their businesses through our unique blend of world-class software engineering, design and consulting services.」。訳すと、1993年以来、世界水準のソフトウェアエンジニアリングとデザインとコンサルティングの組み合わせで顧客のデジタル変革を支援してきた。米国企業で、東欧に大きな開発拠点を持ちます。

Globant

アルゼンチン発のソフトウェア専業で、他社の製品開発を丸ごと引き受ける点は上の2社と同じです（公式サイトは自動アクセスを遮断する設定のため、スクリーンショットは掲載していません）。

3社に共通するのは、エンジニアリングという言葉を会社の名乗りの中心に置いていることです。A類型が「変革」を名乗るのに対し、この類型は「作る技術」を名乗ります。打ち合わせで「このデータの持ち方は、3年後に足かせになります」という指摘が出たら、この類型が重視する視点です。

⑦ C. デザイン起点型 ── 使われる形にする力

画面の見た目を整える類型ではありません。使う人の行動を調べたうえで、製品の形そのものを決める類型です。強いのは、「動くのに使われない」を防げること。作る前に、使う人の行動を確かめにいきます。提案の冒頭に「まず利用者に10人ほど話を聞かせてください」と置かれたら、この類型です。一方で、主戦場は体験の質なので、大量の実装や運用体制まで同じ体制で担うかは案件によります。

IDEO

公式ディスクリプション:「We envision new businesses and brands, and we design the experiences and capabilities that bring them to life.」。訳すと、新しい事業とブランドを構想し、それを実現する体験と組織能力をデザインする。人間中心設計を広めた米国のデザインファームです。

グッドパッチ

公式ディスクリプション:「新規事業立ち上げやプロダクトのUI/UX改善など、戦略策定〜グロースフェーズまで一気通貫でパートナーとして並走します」。国内で、デザイン会社として初めて上場した企業です。

2社とも、サイトの先頭に製品ではなく人と体験を置いています。UI/UXデザイン会社の比較はUI/UXデザイン会社18社を言葉で解析して3つに分けたで別途行っているので、この類型を検討する場合はあわせて読んでください。

⑧ D. オフショア・ラボ型 ── 単価あたりの投入量

オフショアとは、人件費の安い国の拠点に開発の作業を出すこと。ラボ型とは、その拠点に専任のチームを一定期間まるごと確保しておく契約の形です。強いのは、仕様が確定したあとの量産。画面数が多い、対応端末が多い、多言語が要る。決まっているものを大量に作る場面では、これ以上の解がありません。弱いのは、決まっていない案件です。距離と時差の分だけ1往復にかかる時間が伸びるので、固まる前に投入すると逆に高くつきます。

FPTソフトウェア

公式ディスクリプション:「FPT Software is a global technology solutions provider, headquartered in Vietnam.」。訳すと、ベトナムに本社を置くグローバルテクノロジーソリューション企業。同国最大手のIT企業で、ラボ型契約で世界各国の開発を請け負っています。

見積書が「画面数 × 単価」の形で組まれていたら、この類型が得意な見積もりの組み方です。数えられるものを基準に見積もるため、数えられないもの（決まっていない仕様）が混ざると見積もりが崩れます。オフショア開発の往復の実測はオフショア開発の記事に別途あります。

⑨ E. ローコード／ノーコード型 ── 作らずに済ませる範囲

ローコード／ノーコードとは、プログラムをほとんど書かずに、画面や処理を用意された部品の組み合わせで作れるようにした道具のことです。強いのは、作る前に「作らなくて済む範囲」を確かめられること。標準機能で動く部分を先に動かし、足りない部分だけを作る順番が取れます。弱いのは、標準から外れた瞬間です。自社にしかない業務はたいてい標準機能の外側にあり、外側の部分は結局ふつうに作ることになります。そのうえで、道具そのものの利用料は使い続けるかぎり毎年かかります。

この分野の評価としてよく参照されるのが、米国の調査会社ガートナー（Gartner）が毎年出す「マジック・クアドラント」です。企業向けローコード基盤の2025年版では、OutSystems、Mendix、Microsoft Power Apps を含む6社が「リーダー」に入りました。OutSystems と Mendix は、いずれも9年連続です。

OutSystems

公式ディスクリプション:「OutSystems combines a low-code foundation with AI-driven software development to deliver enterprise-grade applications.」。訳すと、ローコード基盤とAI駆動のソフトウェア開発を組み合わせ、エンタープライズ級のアプリケーションを提供する。サイトは同意設定の画面が常時表示されるため、スクリーンショットは掲載していません。

Mendix

公式ディスクリプション:「Mendix is the fastest and easiest low-code platform.」。訳すと、最速で最も簡単なローコードプラットフォーム。ドイツの産業機器大手シーメンスの傘下にあります。

Microsoft Power Apps

公式ディスクリプション:「Microsoft Power Apps は、プロセスを効率化し、組織全体の生産性を向上させるカスタム ビジネス アプリを作成できるロー コード アプリ ビルダーです」。

提案で「標準機能で8割、作り込みは2割です」と言われたら、残りの2割の中身を確かめてください。その2割が自社にしかない業務かどうかで、総額が変わります。

⑩ F. AI活用の共創型 ── 決める工程に入り、往復を減らす

最後の類型は、この記事の発信元（ARCHECO）が属する類型です。贔屓が入る可能性があるので、そのつもりで読んでください。他の類型と同じ条件で、公式サイトの実物とディスクリプションを置きます。

ARCHECO

公式ディスクリプション:「ARCHECOは新規事業コンサルティングと生成AI導入支援を軸に、AIエージェント開発・UX/UIデザインまで統合的に提供。戦略設計からプロダクト開発まで、ビジネスの成長を支援します」。

この類型は、発注する側の企業と組んで、業務の中身を決めるところから入り、動くところまで一緒に作ります。強い軸は決まるまでの往復を短くすること。1往復あたりの日数を縮めるのではなく、往復そのものの回数を減らします。やり方は3つです。第一に、決まっていない項目の質問を着手前に出し切ること。第二に、決めていない項目を、AIで作った動く画面にして見せること。発信元の記録では、画面を1日で12枚作って見せる速度が出ており、文章で往復するより判断が速く正確になります。第三に、決まった範囲から作り始めて、残りは動くものを見ながら決めること。

噛み合わないのは、仕様が完全に決まりきった大規模案件の量産です。それはA類型かD類型の土俵で、この類型が入る余地はあまりありません。

⑪ 立場によって、最初に見る類型が変わります

• 止められない基幹業務に載せる ── A類型から。統制の費用は保険料と考えます
• 長く育てる自社プロダクトを作る ── B類型から。設計の質は後から買えません
• 使われるかどうかが不安 ── C類型から。作る前に行動を確かめます
• 仕様書が既にあり、量が多い ── D類型から。単価あたりの投入量で選びます
• 標準的な業務で、早く動かしたい ── E類型から。作らない範囲を先に確かめます
• 何を作るか自体がまだ決まっていない ── F類型から。決める工程を一緒にやります

①で見た362回と25回の差の大半は、発注前のこの確認で防げます。どの類型でも、見積書を受け取ったら最初に確かめることは同じです。「要件定義の工数が、この金額に入っているか」。 入っていないなら、何回の打ち合わせを想定し、超えたときどう精算するかまで聞く。即答できる相手は、往復の見込みを持って値付けをしています。

まとめ ── 相場表ではなく、名乗りと往復で選ぶ

IPAの5,546プロジェクトの実測では、真ん中の半分だけを取り出しても工数に6.6倍の開きがありました。JUASの調査では、いちばん小さい規模でも予定どおり終わるのは3件に1件です。この現実の前では、「アプリ開発の相場は◯◯万円」という1行は、ほとんど意味を持ちません。

代わりに使えるのが、この記事で並べた2つの一次情報です。各社が公式サイトで名乗っている言葉は、その会社がどの類型で戦っているかを正直に映します。そして決まっていない量をどう扱うかが、最終的な費用を決めます。相場表を探すより、自社の案件の「決まっていない量」を数えるほうが、見積もりのぶれは確実に小さくなります。

よくある質問

Q. アプリ開発の費用の相場はいくらですか？ A. 一律の相場は存在しません。IPAの5,546プロジェクトの実測で、極端な案件を除いた真ん中の半分だけでも工数に6.6倍の開きがあります。相場表の1行より、発注先の類型と「決まっていない量」で見積もりの前提を揃えるほうが、比較として機能します。

Q. 見積もりが安い会社を選んではいけませんか？ A. 安さ自体は問題ではありません。ただ、確かめるべきは、その金額に要件定義（作る機能や条件を決める工程）が入っているかです。入っていない見積もりは、決まるまでの往復が始まった時点で膨らみます。

Q. オフショア開発は結局安いのですか？ A. 仕様が確定している案件なら、単価あたりの投入量で他の類型より安くなります。仕様が固まっていない案件では、距離と時差のぶん往復が高くつき、逆転することがあります。

Q. ローコードで作れば開発会社は不要になりますか？ A. 標準機能の範囲なら大きく減らせます。ただし自社にしかない業務はたいてい標準の外側にあり、そこは結局作ることになります。また、道具の利用料は使い続けるかぎり毎年かかるので、総費用は数年単位で比べてください。

この記事を書いた会社について

アルチェコ（ARCHECO)は、UXデザイン・AI開発・新規事業開発を組み合わせた事業共創スタジオです。この記事のF類型に属します。決まっていない段階の案件を、動くもので決めていく形で伴走しています。