業務アプリ開発の費用と見積もりの考え方

業務アプリの見積もりは、画面数と金額だけを見ても比べられません。同じ「顧客管理」でも、一覧と検索だけなのか、部署別の権限、承認、基幹連携、過去データの移行まで必要なのかで仕事の量が変わります。

費用を整理するには、最初に使う範囲と、将来追加したい範囲を分け、データ、画面、権限、移行、運用の前提をそろえることが必要です。本記事では、見積依頼の準備、概算と確定の違い、比較表、追加費用、契約終了後の確認までを説明します。個別案件の金額を市場全体の相場として示すものではありません。

概算見積もりと、範囲を決めた見積もりを分ける

相談の初期段階では、作りたい業務の概要しか分からず、連携やデータ移行の条件が未確認ということがあります。その段階の概算は、予算の目安や実現方法を考えるためのものです。機能範囲を確認した後の見積もりと、同じ確実さの金額として扱わないようにします。

見積書には、何が確認済みで、何を仮定し、何が対象外なのかを示してもらいます。「既存データは整理済み」「外部サービスは標準機能で連携できる」といった前提が違えば、後で必要な作業も変わります。

不明点が多い場合は、要件の整理や技術的な確認を先に行い、その結果で開発範囲を見直す進め方もあります。最初から一式の確定額を求めることだけが、費用を管理する方法ではありません。見積もりが変わる条件を説明できることが重要です。

最初に「何の仕事を、どこまで改善するか」を決める

見積依頼の中心は、機能名ではなく業務の目的です。「顧客管理を作る」より、「営業が顧客情報を登録し、重複を確認し、管理担当が月末に一覧を出力する」と書いた方が、必要な操作と利用者を判断できます。

次に、初期版に必須のもの、使いながら判断するもの、将来の候補を分けます。現行のExcelにある列や帳票をすべて必須にせず、使っている理由を確認します。一度も見ていない集計を、そのまま新しいアプリへ移す必要があるかも見直してください。

完了の判断も具体化します。「使いやすい」だけでは確認が難しいため、「担当者が検証用の顧客を登録し、権限の範囲内で検索・修正・出力できる」など、操作で確かめられる形にします。性能や処理量の条件があれば、その前提も添えます。

見積もりの前提を、七つの項目でそろえる

画面数は、作業量の一部を示す情報です。同じ一画面でも、表示するだけなのか、複数の部署の権限を判定し、外部データを照合して更新するのかで実装とテストの内容が異なります。

外部連携では、サービス名だけでなく、何を読み取り、何を書き換えるかを確認します。APIの利用条件、追加プラン、連携の制限、検証環境を用意できるかが費用や日程に影響する場合があります。確認前に「連携あり」の一語で済ませないでください。

既存データの整理を誰が行うかも明記します。開発側が列の意味や重複の正解まで決められるとは限りません。業務担当者が判断するもの、開発側が変換するもの、移行しないものを分けます。

依頼文の例と、最初に渡す資料

以下は、架空の顧客・見積管理アプリを相談するための依頼文です。自社の条件に置き換えて使ってください。

営業担当5人と管理担当2人で、顧客と見積の情報を共有したいです。初期版は顧客登録、見積一覧、検索、CSV出力までを想定しています。担当者ごとの編集権限が必要です。過去2年分のExcelがありますが、顧客の重複は未整理です。会計連携は初期版から外し、公開後に検討します。データ整理、移行、外部利用料、運用を分けて見積もりたいです。

添付資料は、機密情報を取り除いた画面例、入力項目、業務の流れ、希望する出力があれば十分な出発点になります。顧客の実データや認証情報を、問い合わせフォームへ最初から送る必要はありません。

社内で決まっていない事項も一覧にします。承認者、権限、移行対象、必要な帳票が未決定なら、誰がいつ決めるかを置きます。未決定のまま開発を始めると、途中の判断待ちが日程に影響するためです。

初期費用だけでなく、利用期間全体の費用を考える

費用は、要件整理、設計・開発、移行、外部サービス利用料、公開後の運用、変更、終了時の移管に分けます。開発の見積もりに入っていない費用を、後からまとめて追加する状況を避けることが目的です。

計算する期間を決め、「初期費用＋契約期間の固定費＋従量費＋想定する追加作業＋移管費用」の形で並べます。従量費は、利用者数、処理件数、データ量など、何によって増えるかも記録します。金額が未確定なら、無料と扱わず、未確認として残してください。

社内の準備時間も必要です。現行業務の説明、データの確認、テスト、利用者への案内は、外注しても社内の判断が残ります。社内担当が対応できる時間帯と、返答の期限を計画へ入れると、無理な公開日を避けやすくなります。

パブロフの6か月プランを確認する

パブロフの業務アプリ開発の6か月プランは、総額88万円（税込）です。内訳は初期費用22万円（税込）と月額11万円（税込）×6か月で、契約時に一括前払いとなります。月額表示だけで支払いのタイミングを判断しないでください。

要件整理、画面設計、開発、テスト、公開、機能追加・改善を含みます。ただし、具体的にどの機能をどこまで作るかは、対象業務、優先順位、技術的な条件を整理して確認する必要があります。機能数や成果を、金額だけから一律に保証するものではありません。

APIやサーバー等の外部サービス利用料、基幹システム連携、決済、標準範囲を超える個別要件は別途費用です。開発済みアプリは契約終了後も利用できます。自社運用へ移管する場合の移管費用は11万円（税込）です。正式な条件は料金と支援範囲をご確認ください。

最初のアプリの公開は、要件と外部サービスの準備が整ってから標準約2週間が目安とされています。社内承認やデータ整理の期間まで一律に含むと受け取らず、開始できる条件と公開までの工程を相談してください。

見積もりを比較する表の作り方

同じ業務でも、提案ごとに既製サービス、ノーコード、独自開発の組み合わせが違う場合があります。比較では、金額の合計だけでなく、対象とする仕事、社内に残る作業、外部利用料、変更できる範囲をそろえます。

条件の違う二案を比べるなら、違いそのものを残します。「片方は移行を含み、片方は社内作業」「片方は利用人数で費用が変わる」という差を消して、単純な安い・高いの評価へまとめないことが大切です。

開発の役割や契約の論点を整理する資料には、IPA「情報システム・モデル取引・契約書」があります。個別の契約条件は、実際の開発の進め方に合わせて責任者が確認してください。

追加費用は「変更の理由」と「影響」で管理する

開発中に新しい要望が出ること自体は珍しくありません。問題になるのは、何が追加で、どの費用や日程に影響するかが分からないまま進むことです。要望、理由、影響、判断者を一行ずつ記録し、実施前に合意する流れを作ります。

例えば、一覧の見出しを変えることと、新しい承認段階を追加することでは影響が異なります。承認段階を増やすなら、データ、権限、通知、履歴、テストまで変更する可能性があります。画面上は小さく見える変更でも、関係する仕事を確認してください。

変更時には、追加する、別の機能と入れ替える、次の段階へ回す、という選択肢を比較します。すべてを初期版へ追加して公開日を維持しようとするより、最初の目的に照らして優先順位を決める方が、予算を説明しやすくなります。

打ち合わせで話しただけの要望も、決定事項か検討事項かを明記します。開発側と社内側で認識が違わないよう、合意した範囲を双方が確認できる場所へ残しましょう。

受入テストと公開の準備を見積もりに入れる

受入テストは、担当者が通常の仕事と例外を実際に操作して、期待する結果になるかを確認する工程です。開発者の動作確認と、業務で使えることの確認は役割が異なります。利用者、データ、確認する手順を事前に決めます。

権限、金額、日付、重複、取消、差し戻し、出力、外部連携の失敗などを確認します。修正が必要なものと、次の改善に回せるものを分け、公開を判断する人を明確にします。確認する時間が取れないまま公開日だけを決めないようにしてください。

公開時は、旧システムをいつ止めるか、新しい入力をいつ始めるか、問題があったときに誰へ連絡し、どの手順へ戻すかを決めます。データ移行の結果を照合する作業も、担当と日程が必要です。詳しい手順はExcelからのアプリ化の記事で紹介しています。

費用が変わる条件を先に確かめる

金額が変わりやすい三つの場面

一つ目は、既存データの意味が後から分かる場合です。同じ列に複数の意味が混ざっている、部署ごとに集計の基準が違うといった問題は、単純な取り込み処理だけでは解決しません。調査と業務上の判断が必要な範囲を、初期の確認工程で見つけます。

二つ目は、外部連携の条件が想定と違う場合です。利用する機能が現行プランでは使えない、検証環境がない、相手側の変更が必要といった条件があれば、作業と日程を見直す必要があります。接続先の会社との調整を誰が担うかも、見積もりへ含めて確認します。

三つ目は、公開後の役割が未決定な場合です。利用者の追加、権限変更、データの修正、障害の連絡を誰が行うかが決まらないままでは、公開できても運用の仕事が残ります。開発の完了と、会社が継続して使える状態を分けずに準備しましょう。

「安い案」と「小さく始める案」を区別する

初期版を小さくする案は、単に機能を削ることではありません。最初の目的を満たす操作と確認を残し、後で判断できる機能を分けることです。権限やデータの保全など、使うための前提まで後回しにする案とは区別してください。

例えば、会計への自動連携を初期版から外して、確認済みのデータをCSVで出力する形から始める方法はあります。この場合も、出力する項目、文字や日付の形式、確認者、取り込み先の条件を決める必要があります。手動にすれば無条件に安く安全になるわけではありません。

見積もりの打ち合わせでは、「今回省くと、誰のどの作業が残るか」「次に追加する際に作り直しが必要か」を質問します。初期費用の差だけでなく、しばらく残る手作業と、次の変更の条件を理解できれば、自社に合う段階の分け方を選びやすくなります。

支払い条件と、機能を確認する時点も分けて確認します。一括払い、月ごとの支払い、工程ごとの支払いのどれであっても、何を確認し、どこで仕様や優先順位を合意するかが必要です。分からない条件は、契約前に書面で確認しましょう。

契約終了後まで考えた最終確認

アプリを使い続けるためには、契約名義、アカウント、外部利用料、管理権限、バックアップ、ソースや設定の扱いを確認します。「利用できる」と「自社で変更・保守できる」は、同じ条件ではありません。

移管を希望するなら、渡されるもの、形式、説明の範囲、移管後の窓口を決めます。データを取り出せても、別の環境で動かす準備や手順が必要な場合があります。契約の直前だけでなく、方式を選ぶ段階から確認すると比較しやすくなります。

この記事のまとめ

見積もりの前提をそろえることは、安い見積もりを探すためだけではありません。何を優先し、どの作業を社内で担い、どこから追加費用が生じるかを、自社で説明できるようにするためです。開発の相談窓口には、対象業務、利用者、現在の方法、希望時期の概要をお送りください。