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

アプリ開発の見積もりで最も多いトラブルは、金額の高い安いではありません。「見積もりに書いていなかった作業を、書いていないという理由で無償でやらされる」という形で起きます。これ、知らない人が本当に多いんです。見積書は価格を伝える紙ではなく、どこまでやるかを決める書類です。この記事では、アプリ開発の見積もりの出し方を、積み上げの手順と「あとで足せない項目」の両面から整理します。

見積書は価格表ではなく、約束の範囲を決める書類

見積もりを「いくらでやりますという提示」だと考えていると、必ずどこかで削られます。実務上、見積書は契約書の一部として機能します。発注者が見積書を承認して発注書を出した時点で、そこに書かれた作業範囲が「合意した仕事の中身」になるからです。

見積書に書いた範囲が、そのまま契約の範囲になる

請負であれ準委任であれ、何を納めるかは契約で決まります。契約書に細かい作業一覧を書くケースは少なく、多くの現場では「別紙見積書のとおり」という一文で見積書が仕様の代わりになります。つまり、見積書に書いていない作業は「契約に含まれていない作業」であると同時に、「請求の根拠がない作業」でもあります。

ここが厄介なところで、書いていない作業は二重の意味であなたに不利に働きます。ひとつは、やらなくてよいと主張しても「常識的に含まれるはずだ」と押し切られやすいこと。もうひとつは、実際にやったあとで請求しようとしても「事前に金額の合意がない」と言われることです。前者は交渉で押し戻せる余地がありますが、後者はほぼ通りません。

発注者が見積もりに求めているのは金額より根拠

発注者側の立場で見ると、複数の見積書を並べたときに最初に見るのは合計欄です。しかし発注を決める段階で見ているのは内訳です。同じような合計金額でも、「アプリ開発一式」とだけ書かれた見積書と、画面ごと機能ごとに作業が割られている見積書では、後者のほうが圧倒的に選ばれます。

理由は単純で、内訳が細かい見積書は社内稟議を通しやすいからです。決裁者に説明する材料になり、予算が足りなければどこを削るかの相談ができます。内訳が「一式」だと、削る相談ができないので、そのまま見送りになります。見積もりを細かく書くのは、自分を守るためであると同時に、受注確率を上げるためでもあります。

概算と本見積もりを分けて考える

問い合わせ段階でいきなり精緻な見積もりを求められることがありますが、要件が固まっていない状態で出す数字は、あとから自分を縛ります。実務では二段構えにするのが安全です。

ひとつ目が概算です。目的、対応OS、想定する主要機能だけを聞いて、幅を持たせた金額と前提条件を提示します。ここでは「この前提が変われば金額も変わる」ことを明記します。ふたつ目が本見積もりです。要件定義を経て機能一覧が確定してから出します。要件定義そのものを有償の作業として切り出す方法もあり、これについては後半で詳しく扱います。

見積もりを出す前に必ず確定させる前提

見積もりの精度は、計算力ではなくヒアリングの精度で決まります。以下の項目が埋まっていない状態で数字を出すと、ほぼ確実にどこかで赤字になります。

対応OSと対応端末の範囲

iOSとAndroidの両方に対応するのか、片方だけなのかで作業量は大きく変わります。さらに、どのOSバージョンまで動作保証するかも決めておく必要があります。古いバージョンまで対応範囲に含めると、実装だけでなくテストの手間が跳ね上がります。

タブレット対応の有無も忘れがちです。スマートフォン向けに作った画面がタブレットで表示崩れを起こしたとき、「同じアプリなのだから直してほしい」と言われるのはよくある展開です。対応する端末サイズを見積書の前提条件に書いておけば、この会話は追加見積もりの相談に変わります。

開発言語の選択も工数に影響します。プラットフォームごとにネイティブで作るのか、共通のフレームワークで作るのかで、実装量もテスト量も変わってきます。

Androidアプリの開発には、Javaをはじめとした開発言語を習得しなければなりません。初心者にとって、Javaは習得が難しいといわれている開発言語です。一方、iPhoneアプリ開発では、Swiftが使用されることが一般的です。Swiftは比較的新しいプログラミング言語であり、扱いやすく直感的な文法を持っています。 出典: hnavi.co.jp

画面数と機能の粒度

「ログイン機能」という一行は、見積もりの単位としては粗すぎます。メールアドレスとパスワードだけなのか、SNSアカウント連携を含むのか、パスワード再設定の画面とメール送信まで含むのか、退会処理はあるのか。この分岐だけで作業量は何倍にも変わります。

見積もりを作るときは、機能名ではなく画面と処理の単位まで割ってください。画面一覧を作り、それぞれの画面で発生する処理を書き出すと、抜けが見つかります。とくに抜けやすいのが、エラー画面、通信失敗時の表示、空データのときの表示、読み込み中の表示です。この四つは仕様書に書かれないまま「当然あるもの」として期待されます。

外部サービス連携と、アカウント準備の主体

決済、地図、プッシュ通知、認証基盤、分析ツール。外部サービスを使う場合、実装工数以外に確認すべきことが三つあります。アカウントを誰が用意するか、審査や申請が必要か、利用料を誰が負担するかです。

決済サービスの審査は事業者情報の提出が必要で、発注者側が動かないと進みません。この待ち時間をこちらの遅延として扱われないよう、「発注者側で用意いただく項目」を見積書に列挙しておきます。

検収の基準と期間

検収は、いつ仕事が終わったことになるかを決める重要な工程です。ここが曖昧だと、いつまでも修正依頼が続きます。見積書か、それに添える前提条件の欄に、検収の考え方を書いておきます。

具体的には、納品物を提出してから何日以内に検収するか、期限内に返答がない場合はどう扱うか、検収の合格基準は何か。合格基準は「事前に合意した機能一覧の動作が確認できること」と定義しておくと、主観的な感想での差し戻しを避けやすくなります。

素材とコンテンツの提供責任

アイコン、ロゴ、写真、アプリ内の文言、利用規約、プライバシーポリシー。これらを誰が用意するかは、見積もりの前提として必ず書きます。「文章はそちらで考えてくれると思っていた」という認識のずれは非常に多く、しかも工数としては小さくありません。

とくにプライバシーポリシーと利用規約は、法的な内容を含むため受注側が勝手に書くべきものではありません。※アプリの内容によっては専門家の確認が必要になるケースがあるため、そのまま流用せず、発注者側で法務確認を取ってもらう前提にしてください。

リリース作業をどこまで含むか

ストアへの申請、審査対応、公開後の初期不具合対応。この三つは「開発」に含まれると思われがちですが、作業としては別物です。とくに審査対応は、こちらの実装に問題がなくても発生します。

見積もりの積み上げ方

前提が固まったら、実際に数字を作ります。ここでは作業分解から工数に落とす手順を追います。

機能一覧を作業に割る

まず画面と機能を一覧にします。次に、それぞれについて「設計」「実装」「テスト」の三つの作業に分けます。この分け方をすると、実装だけを見積もって設計とテストを忘れる、という典型的な失敗が防げます。

一覧ができたら、似た画面をまとめます。同じ形式の一覧画面が複数あるなら、一つ目は作り込みの工数、二つ目以降は差分の工数として計上します。この考え方を見積書の摘要欄に書いておくと、発注者から「同じような画面なのに何度も費用がかかるのはなぜか」と聞かれたときに説明ができます。

見えない作業を必ず行として立てる

見積書に載りにくいのに確実に時間を使う作業があります。これらは行として立てないと存在しないことになります。

環境構築とプロジェクトの初期設定。ライブラリの選定と検証。設計書やデータ構造の整理。コードレビューと修正の反映。動作確認用のビルド配布。進捗報告と打ち合わせ。納品時のドキュメント作成。これらを「管理費」や「ディレクション費」としてまとめる方法もありますが、まとめすぎると削られやすくなります。作業名を具体的に書いたほうが残ります。

幅を持たせるときの正しい書き方

要件が固まりきらない段階では、金額に幅を持たせざるを得ません。このとき「最小と最大」を並べるだけだと、発注者は最小の数字だけを記憶します。幅を書くなら、必ず条件をセットにします。

書き方としては、「この条件であればこの範囲」という形にします。たとえば、機能一覧が確定した時点で範囲の下限側、外部連携が三つ以上になる場合は上限側、といった形です。条件と数字を対にすると、あとで上限側になったときの説明が成立します。

バッファは工数ではなく前提で確保する

見積もりを厚めに出しておくという方法は、価格競争になったときに真っ先に不利になります。それよりも、前提条件を明確にして、条件が変わったら追加見積もりにする、という設計のほうが健全です。

あとで足せない項目

ここからが本題です。以下は、見積もりの段階で書いておかないと、後から請求するのが極めて難しくなる項目です。

要件定義とヒアリングの工数

提案段階の打ち合わせは無償になりがちですが、要件定義は明確に作業です。画面設計を作り、機能一覧を整理し、データの持ち方を決める作業を無償でやると、その成果物だけ持って他社に発注されるリスクもあります。

対応としては、要件定義を独立した契約として先に受けるのが最も安全です。要件定義の成果物を納品し、その内容をもとに開発の本見積もりを出す、という二段階にします。この形なら、開発に進まなかった場合でも要件定義分の対価は確保できます。

修正回数の上限

デザインや画面の修正は、上限を決めないと際限なく続きます。見積書に「修正は各工程2回まで、それを超える場合は別途お見積もり」と書くだけで、進行が大きく変わります。

回数を書くと角が立つと感じるかもしれませんが、実際には逆です。回数が決まっていると発注者側も修正依頼をまとめて出すようになり、細かい差し戻しが減ります。

ストア申請とリジェクト対応

審査の基準は運営側で更新されます。過去に通った実装が通らなくなることもあり、その対応にかかる時間は事前に読めません。見積書では、初回申請の作業を含めるかどうかを明記し、リジェクトが発生した場合の対応を「別途」とするか、あるいは回数の上限を決めて含めます。

テスト用端末とアカウントの費用

実機での動作確認が必要な場合、その端末をどちらが用意するかを決めておきます。開発者アカウントの年間費用、証明書の管理、テスト配信の仕組みなども同様です。金額の大小より、「誰が契約主体になるか」が重要です。開発者アカウントを受注側の名義で取ると、契約終了後もアプリの管理権限が受注側に残り続けるという別の問題が起きます。

権利の帰属と譲渡の範囲

納品したソースコードの著作権をどうするかは、見積もりの段階で触れておくべき論点です。全部を譲渡するのか、利用を許諾するだけなのか、汎用的な部品は受注側に残すのか。

とくに、自分が過去に作った汎用部品を流用する場合、その部分まで丸ごと譲渡してしまうと、次の案件で使えなくなります。「本件固有の実装は譲渡、汎用ライブラリは使用許諾」という形にするのが現実的です。※譲渡の範囲は契約条項として整理すべき事項なので、大きな案件では弁護士の確認を取ることをおすすめします。

保守と運用、障害対応

リリースして終わりではありません。OSの更新に伴う修正、外部サービスの仕様変更への追随、不具合の修正。ここを見積もりに含めないまま納品すると、「作った人の責任」として無償対応を求められがちです。

アプリ開発の費用というと開発費に着目しがちですが、実際はリリースしてからも保守・運用の費用がかかります。 出典: moduleapps.com

対応としては、開発の見積もりとは別に保守の見積もりを用意します。月額で受ける形、時間単位で受ける形、スポットで都度見積もる形の三つが基本です。どれを選ぶにせよ、「開発の見積もりには保守を含みません」という一文を必ず入れます。

さらに分けて考えるべきなのが、瑕疵の修正と機能追加です。納品した機能が仕様どおり動かない場合の修正は、契約不適合として受注側の責任範囲です。一方、OSの更新に伴う対応や新機能の追加は別の作業です。この線引きを書いておかないと、すべてが「直してほしい」に見えます。

第三者サービスの利用料

地図、通知、認証、分析。これらの利用料は使用量に応じて変動します。誰の名義で契約し、誰が支払うかを明記します。受注側が立て替える形にすると、利用が増えたときの負担が読めなくなります。

打ち合わせと報告の回数

定例会議を毎週行うのか、月次でまとめるのか。会議の時間も工数です。回数と時間の目安を前提条件に書いておくと、想定外の会議が増えたときに調整の話が持ち出せます。

納品物の定義

何を納めたら納品なのかを具体的に書きます。ソースコード一式、ビルド済みのファイル、設計書、操作マニュアル、テスト結果。ここが「アプリ一式」としか書かれていないと、あとからマニュアルや設計書を求められます。

見積書の様式と、金額以外に書く欄

見積書の体裁そのものにも決まりごとがあります。ここを整えるだけで、印象と防御力の両方が上がります。

前提条件の欄を必ず作る

明細の下、あるいは別紙で「前提条件」の欄を作り、ここまでに整理した項目を列挙します。対応OSと端末、機能一覧の版数、発注者側で用意いただくもの、修正回数、検収の基準、含まないもの。この欄がある見積書とない見積書では、トラブルになったときの立場がまったく違います。

「含まないもの」を明示するのは気が引けるという声がありますが、実務では逆効果になりません。含まないものが書いてあると、発注者は「この人は範囲を管理できる人だ」と受け取ります。

有効期限

見積もりには有効期限を書きます。半年前の見積もりを持ち出されて「この金額でお願いします」と言われる展開を防ぐためです。1か月程度が一般的です。

支払い条件と支払期日

着手金の有無、分割の有無、支払いのタイミング。長期の案件では、着手時、中間、納品時の三分割にするのが一般的です。

支払期日については法律上の定めがあります。フリーランス保護新法では、発注者は成果物を受領した日から起算して60日以内のできる限り短い期間内で支払期日を定め、その期日までに報酬を支払う義務があります。つまり、「検収が終わるまで支払わない」という理由で受領から60日を超えて支払いを引き延ばすことは認められません。これ、知らない人が本当に多いんです。

別途費用の欄

見積もりに含めない項目を「別途費用」として列挙します。含まないものを書く欄とセットで機能します。ストア申請代行、保守、追加の会議、素材の作成、といった項目をここに置きます。

明細の並び順にも意味がある

明細は、発注者が読む順番を意識して並べます。上から「要件定義」「設計」「実装」「テスト」「リリース」「その他」と工程順に並べると、開発の流れがそのまま伝わります。機能名だけをばらばらに並べると、何にいくらかかっているのかが読み取れず、比較の際に不利になります。

工程順に並べたうえで、実装の中を機能ごとに割ります。こうすると、予算調整の相談があったときに「実装のこの機能を次のフェーズに回す」という会話ができます。工程を削る相談にはならないので、要件定義やテストが値引きの対象になりにくくなります。

消費税と源泉徴収の表記

金額欄は、税抜と税込のどちらで書いているかを明記します。源泉徴収の対象になる業務かどうかも確認が必要です。表記が曖昧だと、入金額が想定と違ってから慌てることになります。

追加が発生したときの進め方

見積もりを丁寧に作っても、開発中に要望は増えます。増えること自体は問題ではなく、増えたときの扱い方が決まっていないことが問題です。

軽微な修正と仕様変更の線引き

境界線をあらかじめ定義しておきます。実務的に使いやすい基準は、「合意した機能一覧に書かれた動作を実現するための作業か、そうでないか」です。書かれた動作を満たすための修正は瑕疵の修正、書かれていない動作を足すのは仕様変更です。

この基準を最初の打ち合わせで共有しておくと、追加見積もりの相談が「お金の話」ではなく「範囲の確認」として進みます。

追加見積もりを出すタイミング

要望が出たその場で「できます」と答えないことが重要です。持ち帰って作業量を確認し、追加分の見積もりを文書で出してから着手します。口頭で了承を取っただけで作業を始めると、請求の根拠が残りません。

書面での条件明示は法律上の要請でもあります。フリーランス保護新法では、発注者は業務内容や報酬額、支払期日などを書面または電磁的方法で明示する義務を負います。追加作業も業務の一部である以上、条件を書面で残すのが本来の形です。メールでの合意でも記録としては有効なので、少なくともメールのやり取りは残してください。

断らずに調整する提案の型

追加費用の話は、断り方ではなく選択肢の出し方で決まります。要望に対して、そのまま実装する案、簡易版で実装する案、次のフェーズに回す案の三つを並べ、それぞれの作業量の目安を添えます。選択肢があると、発注者は「削られた」ではなく「選んだ」と感じます。

予算が足りないと言われたときの対応

金額を下げるのではなく、範囲を減らすのが原則です。値引きで対応すると、その金額が次回以降の基準になります。範囲を減らして調整すれば、次に予算が付いたときに残した機能を提案できます。

段階的にリリースする進め方も有効です。最初は必要最小限の機能で出し、運用しながら追加していく形です。

ハイブリッド型アプリ開発サービスの代表である「ModuleApps 2.0」では、最低限の機能から始めてみて、運用しながら機能を追加したり、カスタマイズしたり……という動き方も可能なため、アプリを初めて導入するという方にもおすすめです。 出典: moduleapps.com

見積もりを守るための法務の基礎

見積もりは民事の話に見えますが、フリーランスの取引には保護のための仕組みが用意されています。

書面での明示を求めるのは正当な要求

条件を書面で出してほしいと求めることを、気まずいと感じる必要はありません。発注者側にとっても義務であり、応じるのが当然の対応です。取引条件の明示に関する制度の考え方は、公正取引委員会の公表資料でも整理されています。制度の詳細は公正取引委員会の情報を確認してください。

支払いが遅れたときの相談先

支払期日を過ぎても入金がない場合、まずは書面で督促します。それでも動かない場合、相談窓口があります。※金額が大きい場合や、契約内容そのものに争いがある場合は、早い段階で弁護士に相談してください。

見積書と発注書をセットで保管する

見積書を出したら、発注書または承認の返信を必ず受け取ります。口頭発注のまま作業を始めると、後で範囲を争ったときに何も証拠が残りません。メールの本文で「別紙見積書のとおりで承認します」という返信をもらうだけでも、記録としての価値は大きく変わります。

法律はあなたの味方です。ただし、味方になってもらうには記録が必要です。見積書はその記録の起点になります。

市場から見た見積もりの位置づけ

見積もりの精度は、そのまま案件の探し方にも影響します。範囲を管理できる人は、単発の仕事ではなく継続的な依頼を受けやすくなります。

アプリ開発の仕事がどのような形で募集されているかは、AIチャットボット・アプリ開発のお仕事で職種としての全体像を確認できます。募集の書かれ方を見ると、機能一覧が明記されている案件と、目的だけが書かれている案件があり、後者ほど見積もりの前提づくりが重要になります。関連する分野として、AI・マーケティング・セキュリティのお仕事では、アプリに付随する分析や情報管理の業務がどう切り出されているかが分かります。

職種としての位置づけを把握しておくと、見積もりの説明もしやすくなります。ソフトウェア作成者の年収・単価相場では、統計にもとづく職種の分布が確認できます。自分の作業がどの領域に当たるのかを言葉にできると、見積もりの根拠の説明が具体的になります。

ネットワークや基盤まわりの知識が必要になる案件では、資格が説明材料として使えることがあります。CCNA（シスコ技術者認定）は、通信やインフラの基礎を体系的に扱う認定で、外部連携やサーバー側の設計に関わる場面で理解の裏づけになります。

20年この市場を見てきた運営者の立場から言えば、継続して仕事が途切れない人の見積書には共通点があります。金額が安いことではなく、前提条件の欄が丁寧に埋まっていることです。前提条件が書かれた見積書は、発注者にとって「この人と進めれば話が食い違わない」という信号になります。逆に、合計金額だけが書かれた見積書は、比較の土俵に乗った瞬間に金額だけで判断されます。

もうひとつ、運営者として見てきた限りでは、仲介手数料の構造を理解している人ほど見積もりの設計がうまい傾向があります。中間マージンが乗らない手数料0%の直接取引では、同じ予算でも依頼者はより多くを頼めますし、受け手は手取りが厚くなります。この差は金額の大小の話ではなく、見積もりに載せられる作業の幅の話です。手取りが厚い分だけ、要件定義やテストといった「見えにくいが必要な作業」を正直に見積書へ載せられます。値引き競争の中で真っ先に削られるのはこの部分であり、削った結果として品質が落ち、次の依頼が来なくなるという流れは何度も見てきました。

海外の案件に広げる場合も、考え方は同じです。Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法では、海外のプラットフォームで案件を受ける際の進め方が整理されています。契約の考え方や範囲の決め方は、国内案件よりもさらに明文化が求められます。

見積もりは、自分の仕事を守る最初の書類です。金額を決める作業ではなく、範囲を決める作業だと捉え直すと、書くべき項目は自然に見えてきます。

よくある質問

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

概算と本見積もりを分けて出すのが安全です。概算では目的と対応OS、主要機能だけを前提に幅を持たせた金額を示し、前提条件が変われば金額も変わることを明記します。そのうえで、要件定義を独立した作業として受注し、機能一覧が確定してから本見積もりを出します。この二段構えにすると、精緻な数字を出したあとに要件が膨らんで赤字になる展開を避けられます。

Q. 見積書に「含まないもの」を書くと印象が悪くなりませんか？

実務では逆の効果になります。含まない範囲が明記された見積書は、発注者にとって範囲を管理できる相手であるという判断材料になります。含まないものが書かれていない見積書は、比較されたときに合計金額だけで判断されがちです。前提条件と別途費用の欄をセットで用意し、ストア申請や保守、追加の会議などを具体的に列挙してください。

Q. 開発中に追加要望が出たとき、どのタイミングで追加見積もりを出しますか？

要望を受けたその場で可否を答えず、持ち帰って作業量を確認し、追加分の見積もりを文書で出してから着手します。口頭の了承だけで作業を始めると請求の根拠が残りません。判断の基準は、合意した機能一覧に書かれた動作を実現する作業かどうかです。書かれた動作を満たすための修正は瑕疵対応、書かれていない動作を足すのは仕様変更として扱います。

Q. 検収がいつまでも終わらず入金されない場合はどうなりますか？

フリーランス保護新法では、発注者は成果物を受領した日から起算して60日以内のできる限り短い期間内で支払期日を定め、その期日までに支払う義務があります。検収が終わらないことを理由に受領から60日を超えて支払いを引き延ばすことは認められません。まずは書面で督促し、それでも動かない場合は相談窓口の利用を検討してください。金額が大きい場合は弁護士への相談をおすすめします。

Q. 保守費用は開発の見積もりに含めるべきですか？

分けるのが基本です。開発の見積書には「保守は含みません」と明記し、保守は別の見積もりとして用意します。受け方は月額、時間単位、都度見積もりの三通りがあります。あわせて、仕様どおり動かない場合の修正と、OS更新への対応や機能追加を線引きしておいてください。この区別がないと、リリース後のすべての依頼が無償の修正として扱われやすくなります。