モバイルアプリ開発の見積もりの作り方｜あとで足せない項目

2026年3月11日

丸山桃子

この記事のポイント

✓モバイルアプリ開発の見積もりの出し方を
✓あとから追加できない項目を落とさない手順として整理しました
✓前提条件と除外事項の書き方

モバイルアプリ開発の見積もりの出し方で失敗するとき、原因はたいてい単価の設定ではありません。作る時間は正しく見積もれているのに、作る以外の工程が丸ごと抜けているのです。しかもその抜けた項目は、着手後に「これも必要でした」と言い出しにくい種類のものばかりです。この記事では、あとから足せない項目の一覧と、それを落とさない見積もりの手順、前提条件と除外事項の書き方までを具体的に整理します。

見積もりで抜けるのは、作る時間ではない

見積書を作るとき、多くの人は機能を並べて工数を積み上げます。この作業自体は難しくありません。画面が何枚あり、どんな処理が必要かは、要件を聞けばおおよそ見えます。

問題は、その一覧に載らない工程です。ストアに出すための準備、審査の対応、実機での確認、権限の扱い、外部サービスの申請、引き渡しの資料。これらは「開発」という言葉に含まれていると誤解されやすく、見積書に行として現れません。

そして、着手後にこれらの作業が発生したとき、追加の請求がしにくくなります。相手からすれば「アプリを作ってもらう契約」に含まれていると考えるのが自然だからです。だからこそ、着手前に行として書いておく必要があります。

見積書は金額を伝える書類であると同時に、何をやって何をやらないかの合意書です。金額の精度より、範囲の明確さのほうが後の消耗を減らします。

あとで足せない項目

見積もりから落ちやすく、かつ着手後に追加しにくい項目を挙げます。

配信用のアカウントと証明書の扱い

アプリを配信するには、ストアの開発者アカウントが必要です。誰が保有し、誰が管理するかで作業量が変わります。依頼者がまだ持っていない場合、法人としての登録には確認の手続きと時間がかかります。

証明書や鍵の発行、更新、管理も継続的な作業です。これらは一度きりではなく、期限が来れば更新が必要になります。見積書には「アカウントの取得支援」「証明書の設定」を項目として書き、更新は保守の範囲であることを明記します。

ストアに掲載する素材の作成

ストアのページには、説明文、スクリーンショット、アイコン、プライバシーに関する情報の記載が必要です。これらは開発の成果物ではありませんが、公開には不可欠です。

依頼者が用意する前提なのか、こちらで作るのかを決めておきます。とくにスクリーンショットは、指定の画面サイズごとに用意する必要があり、機能を変更するたびに撮り直しが発生します。作る側が担当するなら、それは独立した工程です。

審査への対応と再提出

提出して一度で通るとは限りません。指摘を受けた場合、内容を確認し、修正し、再提出します。指摘の内容によっては仕様そのものの見直しになります。

この作業を見積もりに入れていないと、審査で止まった期間がすべて自分の負担になります。項目として「審査対応（再提出を含む）」を置き、想定する回数を明記します。

実機での確認

エミュレータでの確認と、実機での確認は別物です。実機では、通信の速度、通知の受け取り、カメラや位置情報の権限、バックグラウンドに回ったときの挙動が実際に確かめられます。

確認に使う端末とOSのバージョンの組み合わせを、見積もりの前提として書きます。「主要な端末で確認」という書き方では範囲が定まらず、依頼者が持っている古い機種での事象が後から持ち込まれます。

権限まわりの実装と説明文

カメラ、位置情報、通知、写真へのアクセス。これらを使う場合、利用の目的を利用者に説明する文言が必要です。文言の作成、拒否されたときの動作、設定画面への誘導まで含めると、見た目に現れない実装が積み上がります。

権限を求める設計は、ユーザーの使い心地に直結します。

特に一般公開するモバイルアプリ開発の場合、ユーザー体験（UX）を大切にしましょう。UXとは、アプリの利用を通して得るすべての経験を指します。見た目の美しさ、操作のしやすさ、情報の分かりやすさなど、あらゆる面で満足させるための設計が不可欠です。出典: valtes-innovations.co.jp

権限の求め方ひとつで、利用者が最初の画面で離脱するかどうかが変わります。ここは削れる工程ではありません。

通知の仕組み

プッシュ通知は「機能を一つ足す」ように見えますが、実際には送る側の仕組みが必要です。誰に、いつ、何を送るかを管理する画面や仕組みを用意するかどうかで、作業量は大きく変わります。

依頼者が「通知は必要です」と言ったとき、送信の管理まで含むのか、開発側が手作業で送るのかを確認します。ここを曖昧にしたまま見積もると、後から管理画面の開発が必要になります。

外部サービスの申請

決済、地図、認証、分析。外部のサービスを使う場合、申請と審査に時間がかかるものがあります。申請の書類を用意する作業も発生します。

これらは開発の進み具合と関係なく日数を消費するため、工程として独立させます。申請を出す時期も、着手直後に設定します。

データの移行

既存のシステムやアプリから置き換える案件では、いまあるデータをどうするかが必ず問題になります。移行の対象、形式の変換、移行後の確認。この工程は、規模によっては開発本体に匹敵する作業量になります。

「既存のデータは引き継ぎます」という一言で合意されがちですが、実際に何件のデータをどの形式で受け取れるのかは、着手してから判明することが多い項目です。

引き渡しと資料

納品の対象がアプリの本体だけとは限りません。ソースコード、設計の資料、運用の手順書、アカウントの情報。これらの整理と引き渡しには時間がかかります。

とくに手順書は、書き始めると想定の何倍もの時間を使います。納品物の一覧を見積書に書き、資料を含む場合は独立した項目にします。

公開後の運用

アプリは公開してからのほうが長く続きます。OSは毎年更新され、ライブラリも更新されます。放置すればビルドが通らなくなり、ストアの要件も満たさなくなります。

この領域は開発の見積もりとは分け、保守として別に提示します。混ぜてしまうと、納品後も終わらない案件になります。

見積もりを作る手順

落ちやすい項目を把握したうえで、手順に沿って組み立てます。

画面ではなく状態で数える

「画面が10枚」という数え方は、実態と合いません。一つの画面には、通常の状態、読み込み中、データが空、通信に失敗、権限が拒否された状態など、複数の状態があります。

状態の数で数えると、実装と確認の量に近い数字になります。要件を聞く段階で、主要な画面について「データがないときはどう見えますか」「通信に失敗したらどうしますか」を確認しておくと、見積もりの精度が上がると同時に、要件の抜けも見つかります。

一つの機能を三つの層に分ける

機能ごとに、見た目の実装、内部の処理、外部との通信の三つに分けて考えます。同じ「一覧を表示する」でも、内部のデータを並べるだけの場合と、外部から取得して並べ替えと絞り込みまで行う場合では、作業量が大きく違います。

層に分けて数えると、見積書の説明もしやすくなります。相手から「なぜこの機能にこれだけかかるのか」と聞かれたとき、層ごとに説明できるからです。

両方のプラットフォームを別に数える

iOSとAndroidの両方に対応する案件では、共通化できる部分と、そうでない部分を分けます。クロスプラットフォームのフレームワークを使っても、レイアウトの崩れ方、キーボードの挙動、戻る操作、通知の権限の扱いは異なります。

見積書には、片方のみの対応と両方の対応で金額が変わることを明示します。依頼者が「まずは片方でよい」と判断できる材料になり、範囲を調整する余地も生まれます。

確認と手直しの時間を工程として置く

作って終わりではなく、確認して直す時間が必要です。この時間を工数の内側に隠すと、遅れが出たときに説明できません。

工程として「動作確認」「指摘対応」を置き、それぞれに日数を割り当てます。修正の回数や期間の考え方も、同じ見積書に書いておきます。回数を決めておかないと、確認の工程がいつまでも終わりません。

前提条件と除外事項を書く

見積書の最後に、前提条件と除外事項を書きます。ここが見積書の中で最も重要な部分です。

前提条件には、この見積もりが成立するための条件を書きます。デザインの提供、素材の提供、確認への回答の期限、アカウントの用意、既存システムの仕様書の提供。これらが揃わない場合、金額も日程も変わることを明記します。

除外事項には、含まれないものを書きます。ストア掲載素材の作成、データの移行、公開後の保守、運用の代行、権利関係の調査。含まれないことを書いておかないと、含まれると解釈されます。

有効期限を書く

見積もりには有効期限を書きます。数ヶ月後に「あの見積もりで」と言われても、その間にOSは更新され、ライブラリの状況も変わっています。

期限を書くことは相手を急かす行為ではなく、前提が変われば内容も変わるという事実の表明です。

概算と確定を分ける

要件が固まりきっていない段階で、確定の見積もりを出すべきではありません。出せば、その金額が上限として扱われます。

段階を分けます。最初に、要件を整理する工程だけを独立した見積もりとして出す。この工程で画面と状態を洗い出し、外部との連携や移行の要否を確認する。そのうえで、開発の確定した見積もりを出す。

この進め方は依頼者にとっても利点があります。全体の金額が読めない状態で大きな判断をせずに済むためです。要件整理の段階で「思ったより大きい」と分かれば、範囲を絞る判断もできます。

段階を分ける提案に応じるかどうかで、相手の姿勢も見えます。進め方を一緒に考えられる相手なら、その後の工程も協力的に進みます。開発の受注がどのような工程で進むかを整理しておきたい場合は、アプリケーション開発のお仕事で案件の流れを確認しておくと、段階の切り方の目安になります。

開発の進め方の選択が見積もりを左右する

同じ要件でも、どう作るかによって工数の構造が変わります。見積もりを出す前に、この選択を相手と共有しておきます。

一つ目は、それぞれのプラットフォーム専用の作り方です。動作や見た目を細かく作り込めますが、二つのプラットフォームで別々に実装と確認が必要になります。端末の機能を深く使うアプリや、動きの滑らかさが価値になるアプリに向きます。

二つ目は、一つのコードから両方向けに作る方法です。実装の多くを共通化できるため、機能の量が同じなら作業は減ります。ただし、プラットフォーム固有の挙動に合わせる調整と、使うライブラリが両方に対応しているかの確認が必要になります。「共通化できるから半分になる」という単純な計算にはなりません。

三つ目は、Webの技術で作り、ブラウザから使えるようにする方法です。ストアの審査を経ずに更新できる利点がありますが、通知や端末の機能の扱いに制約が出ます。

見積書には、どの方法を前提としているかを明記します。前提が書かれていないと、後から「他社はもっと安かった」と比較されたときに、比較の土台が違うことを説明できません。方法によって、公開後の運用の負担も変わります。この違いは、見積もりの段階で説明しておくほうが、後の納得につながります。

既存のアプリを改修する場合

新規開発より難しいのが、既存のアプリの改修です。作業量が、渡される資産の状態に完全に依存するためです。

見積もりを出す前に確認するのは五点です。ソースコードが揃っているか。手元の環境でビルドが通るか。使っているライブラリのバージョンがどれだけ古いか。配信用のアカウントと証明書にアクセスできるか。設計の資料や、前の開発者への連絡手段が残っているか。

このうち一つでも欠けていると、調査だけで想定の工数を大きく超えます。前の開発者との関係が切れており、コードもアカウントも揃わない状態で相談が来ることは珍しくありません。

対処は、調査の工程を独立した見積もりとして先に出すことです。「現状の確認とビルドの再現」までを一つの契約とし、その結果を見てから改修の見積もりを出します。調査せずに改修の金額を出すのは、中身を見ずに修理費を約束するのと同じです。

古いライブラリを新しくする作業は、それ自体が独立した工程になります。長く更新されていないアプリでは、機能を一つ足す前に、動く状態に戻す作業が必要になることもあります。この作業を「改修のついで」に含めないよう、行として分けて書きます。

見積もりの根拠を説明できる形にする

金額の妥当性を問われたとき、答え方は二つに分かれます。作業の量で説明するか、成果の価値で説明するかです。

作業の量で説明する場合、工程ごとの日数と、そこで何をするかを示します。この説明は納得を得やすい反面、「もっと早くできませんか」という交渉を招きます。日数を減らす交渉になると、削られるのはたいてい確認の工程です。

成果の価値で説明する場合は、この機能があることで依頼者の何が変わるかを示します。手作業でやっていた業務が減る、問い合わせが減る、利用者が離脱する箇所が改善される。価値の話ができると、金額の交渉は範囲の交渉に変わります。

実務では両方を使います。全体の構成は工程で示し、削る削らないの議論になったときは価値で説明する。この二段構えにしておくと、確認の工程を守りやすくなります。

見積もり後に要件が増えたときの扱い

見積もりを出したあと、着手前に要件が増えることがあります。ここで「その程度なら」と飲み込むと、以降の追加も同じ扱いになります。

対応は単純です。増えた分について、追加の見積もりを出します。金額を変えるかどうかは後の判断であり、まず「これは当初の範囲に含まれていない」ことを記録します。書面で残すこと自体が目的です。

着手後に増えた場合も同じです。範囲外の依頼が来たら、その場で範囲外である旨を書いて送ります。対応するかどうかは、そのあとで決めます。この一往復を省くと、次から同じ種類の依頼が範囲内として扱われます。

追加が続く案件では、まとめて再見積もりを提案する方法もあります。個別に小さな追加を積むより、一定の区切りで全体を見直すほうが、双方にとって管理しやすくなります。

検収と不具合対応の範囲を決める

開発の見積もりで最後まで曖昧に残りやすいのが、いつ終わったことになるのかという線です。ここを決めていないと、公開したあとも修正の依頼が続き、契約が終わりません。

検収の基準と期間を書く

何をもって完了とするかを、確認できる形で書きます。合意した機能の一覧に対して、あらかじめ決めた端末とOSの組み合わせで動作することを確認できたら検収とする、という形です。基準を「問題なく動くこと」と書くと、どこまでが問題なのかを相手が決めることになります。

検収の期間も区切ります。納品から一定の日数以内に確認と回答をいただき、期間内に指摘がなければ検収完了として扱う、と書いておきます。この一文がないと、返答がないまま案件が宙に浮き、請求のタイミングも決まりません。

公開後の不具合対応をどこまで含めるか

引き渡したあとに見つかる不具合の扱いを決めます。合意した仕様どおりに動いていない箇所を直す作業と、仕様そのものを変える作業は別のものです。前者を一定期間は無償で対応する、後者は追加の見積もりとする、という切り方が実務的です。

対象となる期間の長さは、案件の規模と検収の丁寧さで決めます。期間を書かずに引き渡すと、公開から時間が経ってからの依頼も同じ扱いになります。あわせて、対象外にするものも書きます。OSの更新に伴う不具合、外部サービスの仕様変更に伴う不具合、依頼者側で加えた変更に起因する不具合。これらは自分の作業が原因ではないため、保守として別に扱います。

仕様の変更と不具合の切り分け基準を持つ

「動くけれど思っていたものと違う」という指摘は必ず来ます。これを不具合として無償で直し続けると、確認の工程が終わりません。切り分けの基準は、合意した資料に書かれているかどうかの一点です。書かれているとおりに動いていなければ不具合、書かれていない挙動についての要望は仕様の変更。

この基準を機能させるには、合意した内容が文書として残っている必要があります。要件を整理する工程を独立させておくと、その成果物がそのまま判定の基準になります。口頭で決めた内容しかない案件では、この切り分けができません。

確認に参加する人と回答の窓口を決める

検収の期間を書いても、確認する人が決まっていなければ機能しません。依頼者側の誰が触って、誰が指摘をまとめて返すのかを、着手前に決めておきます。

窓口が一本化されていない案件では、複数の担当者から別々の指摘が届き、内容が食い違うことがあります。指摘は一つの表にまとめて送っていただく前提を書き、その表をそのまま対応の記録として使います。指摘ごとに、不具合か仕様の変更かを判定して返せば、追加の見積もりの根拠も同じ表に残ります。

配布前の確認用の配信を行う場合は、その回数と対象の人数も前提条件に書きます。確認用の配信は、そのたびに準備と説明の作業が発生します。回数を決めていないと、確認の依頼が来るたびに作業が積み上がります。

権利の帰属とセキュリティの前提を書く

金額と日程が合っていても、権利の扱いが決まっていない案件は、引き渡しの段階で止まります。

ソースコードと著作権の扱い

納品するものにソースコードを含めるのか、動作するアプリだけを渡すのか。含める場合、著作権を譲渡するのか、利用を許諾するにとどめるのか。この違いは、依頼者がその後に他の開発者へ引き継げるかどうかを左右します。

譲渡する場合でも、汎用的に使い回している部品まで渡す必要はありません。「本件のために作成した部分の権利を譲渡し、汎用の部品については利用を許諾する」という形にしておけば、次の案件で同じ部品を使えます。この区分を書かずに一括で譲渡すると、自分の資産を毎回手放すことになります。

外部の部品とライセンスの確認

アプリには、外部の公開されている部品を組み込みます。それぞれに利用の条件があり、条件によっては、組み込んだ側のコードの扱いにも影響します。使う部品の条件を確認する作業は工程として実在します。

見積書には、使用する主要な部品と、そのライセンスの確認を含むかどうかを書きます。依頼者から特定の部品の指定がある場合は、条件の確認結果によって構成が変わる可能性があることも前提条件に添えます。

個人情報とセキュリティの前提

利用者の情報を扱うアプリでは、収集する項目、保存する場所、保存する期間、誰が参照できるかを決める必要があります。この設計は開発の一部ですが、方針を決めるのは依頼者です。方針が決まらないまま実装を進めると、あとから作り直しになります。

見積書の前提条件に「個人情報の取り扱い方針は貴社にてご決定いただく前提です」と書き、方針の策定を支援する場合は独立した項目として立てます。あわせて、外部の専門家による診断や検査を含むかどうかも明記します。診断は開発とは別の専門領域であり、含まないなら除外事項に書いておきます。

相手に伝わる見積書の形

金額の一覧だけの見積書は、判断の材料になりません。次の構成にすると、相手が社内で説明しやすくなります。

対象と目的。前提条件。含まれる範囲を工程ごとに。含まれない範囲。日程の目安。修正対応の考え方。検収の期限。支払いの条件。有効期限。

工程ごとに書くことには意味があります。総額だけを示すと、値引きの交渉は総額に対して行われます。工程ごとに書けば、「この工程を減らすと総額が下がる」という会話になります。削るのは金額ではなく範囲だという前提を、書類の構成で作れます。

依頼者側の作業も書きます。素材の提供、確認の返答、アカウントの発行、審査に必要な情報の準備。これらが遅れると日程が動くことを、着手前に共有しておきます。

予算に合わないときの調整

提示した見積もりが予算に合わないことは頻繁に起こります。このとき、金額だけを下げるのは最も避けるべき対応です。範囲が変わらないまま金額だけが下がると、その差は作る側が負担します。

削る順番には定石があります。

最初に削るのは、対応するプラットフォームです。両方から片方に絞ると、実装と確認の両方が減ります。次に削るのは、機能の数ではなく機能の深さです。絞り込みや並べ替え、細かい設定を後回しにします。三番目に、管理する仕組みです。通知の送信管理や、コンテンツの入稿画面を初期から作らず、当面は手作業で運用する形にします。

削ってはいけないのは、確認の工程と、権限や個人情報の扱いに関わる実装です。ここを削ると、公開後に問題が起きたときの損害が、削った金額をはるかに上回ります。

削った項目は「次の段階」として一覧に残します。消すのではなく、後で足せる形にしておくと、相手の社内でも予算の追加を検討しやすくなります。

依頼を受ける相手を選ぶ段階から範囲の話ができていると、この調整も進めやすくなります。案件の性質や市場での位置づけを確認しておきたい場合は、ソフトウェア作成者の年収・単価相場で職種としての立ち位置を把握しておくと、判断の目安になります。

実績の提示が見積もりの説得力を作る

同じ内容の見積書でも、過去の実績を添えるかどうかで受け取られ方が変わります。依頼する側は、金額の妥当性を自力で判断できないため、実績を手がかりにします。

依頼先の開発実績は、モバイルアプリの品質やデザイン性を判断するうえで大切な情報です。開発実績を確認し、自社が期待するモバイルアプリを実現できる開発会社か確かめましょう。特に、自社と同じ業種や似た規模のモバイルアプリ開発実績があると心強いです。同種のモバイルアプリ開発経験が豊富だと、ノウハウが蓄積されているため、大きな失敗を避けられるでしょう。出典: valtes-innovations.co.jp

添えるべきなのは、作ったものの見た目ではなく、進め方の実績です。どういう手順で要件を固めたか、どんな問題が起きて、どう対処したか。これが書けると、見積もりに書かれた工程の一つ一つに理由があることが伝わります。

技術の裏付けを示す手段としては、資格も補助になります。運用や基盤の知識を体系的に持っていることを示す認定として、CCNA（シスコ技術者認定）のようなものは、保守や運用まで含めた提案の説得力を補います。

現場を見てきた立場からの観察

在宅とフリーランスの仕事の市場を20年見てきた運営者の立場から言えば、見積もりで消耗する人と、そうでない人の違いは計算の精度ではありません。違いは、除外事項を書いているかどうかの一点に出ます。

除外事項を書くのは気が引ける、という声はよく聞きます。断りの多い書類に見えるのではないか、という心配です。実際に起きているのは逆で、含まれないものが明記された見積書のほうが、依頼する側にとって安心材料になります。何が別途必要になるかが事前に分かるため、社内の予算計画が立てられるからです。

もう一つ、長く続く人に共通しているのは、見積もりを「金額を伝える書類」ではなく「進め方を合意する書類」として扱っていることです。工程ごとに書き、相手の作業も書き、前提が崩れたときにどうなるかも書く。この形の見積書を出している人は、案件が始まってからの説明が少なくて済みます。

仲介の手数料が乗らない直接の取引では、同じ予算で依頼する側はより多くを頼めて、受ける側は手取りが厚くなります。手数料0%という条件が効くのは金額の多寡そのものではなく、その余白を「削らずに済む範囲」に回せる点にあります。確認の工程や権限まわりの実装を削らずに提示できることは、そのまま成果物の質になります。

海外の依頼者に見積もりを出す場合は、前提条件の書き方がより重要になります。商習慣が異なる相手と条件をどう詰めるかは、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法でも、契約前の確認事項として整理されています。

よくある質問

Q. 見積もりから最も落ちやすい項目は何ですか？

作る以外の工程です。配信用アカウントと証明書の設定、ストア掲載素材の作成、審査対応と再提出、実機での確認、権限まわりの実装、外部サービスの申請、データ移行、引き渡し資料の作成が代表的です。いずれも着手後に追加の請求がしにくい種類のため、行として見積書に書いておく必要があります。

Q. 要件が固まっていない段階で見積もりを求められたらどうしますか？

確定の見積もりは出しません。出すとその金額が上限として扱われます。まず要件整理の工程だけを独立した見積もりとして提示し、そこで画面と状態、外部連携やデータ移行の要否を洗い出してから、開発の確定見積もりを出します。段階を分ける提案に応じるかどうかで、相手の姿勢も判断できます。

Q. 前提条件には何を書けばよいですか？

その見積もりが成立するための条件を書きます。デザインの提供、素材の提供、確認への回答期限、配信アカウントの用意、既存システムの仕様書の提供などです。あわせて、これらが揃わない場合は金額と日程が変わることを明記します。除外事項には、掲載素材の作成、データ移行、公開後の保守など、含まれないものを列挙します。