Webアプリ開発はいくらかかる？見積もりの差を読み解く

「申込フォーム一つ」に、どこまで含まれているか

説明用の例として、法人向け研修の申込サービスを考えます。A案は申込みを一覧へ保存し、担当者がメールで連絡する構成。B案は定員管理、承認、キャンセル通知まで自動で行う構成です。どちらも申込システムですが、運営者に残る仕事が違います。総額だけで、開発会社の高い・安いは判断できません。

まず各社に「申込みを受けた後、担当者は何をするか」を説明してもらいましょう。自動化される仕事と、発注側が担う仕事を並べると差が見えます。必要な自動化が抜けているなら追加し、初回に不要な機能なら外す。その後に金額を比べると、安く見えた理由も高くなった理由も社内で説明できます。

金額差には、同じ仕事を異なる方法で実現する違いもあります。既存のサービスを組み合わせる案と、独自に作る案では、初期作業と月額利用料の配分が変わります。安い案を上位案と同じ機能へそろえるだけでなく、自社の運用を提案に合わせられるかも考えます。研修の例なら、複雑な承認経路を維持する必要があるのか、一人の担当者が確認する形へ変えられるのかで、選択肢が広がります。

公表料金は、案件の条件とセットで読む

ダンドリの公表料金は、小規模な開発・業務自動化が40万円〜、業務システム・Webサービス開発が80万円〜です。前者は特定作業の自動化や小規模なサイト制作など、後者は管理システムや新規Webサービスの初期開発などを対象とします。どの機能でも最低額に収まる定額パッケージではなく、必要な仕事を確認したうえでの個別見積もりです。

設計・開発の料金基準は1人月160万円、160時間換算です。説明用の計算例として、対象作業を仮に40時間と置けば、160万円×40÷160＝40万円になります。これは工数を金額へ換算する例であり、予約機能が40時間で完成するといった保証ではありません。ヒアリング、設計、開発、動作確認、移行、公開、引き継ぎなど、どの作業を見積もるかが先にあります。

費用を動かすのは、画面に見えない分岐

「管理者と一般利用者を分ける」だけでも、誰の情報を閲覧し、変更し、出力できるかで設計が変わります。OWASPは、操作の要求ごとに権限を検証することを推奨しています。管理ボタンを消すだけでは済まないため、利用者の種類や企業間の分離が増えると、実装と試験の対象も増えます。

決済も、支払い画面を表示して終わりではありません。Stripeの通知は到着順が保証されず、重複して届く場合があります。支払い済みなのに使えない、同じ通知で二度権限を付ける、といった問題を防ぐ処理が必要です。こうした説明が見積もりにあれば、追加費用の理由を業務上の価値として判断できます。

参考：OWASP Foundation：Authorization Cheat Sheet ／ Stripe：Receive Stripe events in your webhook endpoint

相見積もりでは、総額の横にこの違いを並べる

細かな作業時間をすべて読み解く必要はありません。自社が何を受け取り、何を準備し、公開後に何をできるかを比べます。「テスト込み」なら、申込みの成功だけか、重複や取消まで試すのかを尋ねます。書かれていない項目は、すぐ対象外と決めず、回答をもらってからそろえてください。

担当者自身が使う場面を一つ提示すると、提案の違いが具体的になります。「締切後に申込みを直したい」「担当者が退職した」といった場面です。技術名の多さより、その場面の対応を説明できるかを見ます。標準の管理画面で済ませる案にも、使いにくさが残るのか、十分なのかを確かめる価値があります。

「データを取り出したい」と伝える場合も、その用途を話すと提案を読みやすくなります。担当者が月末に表計算へ渡すだけなら一覧出力で足りるかもしれません。会計システムへ自動で送るなら、項目の対応やエラー時の照合も必要です。機能名をそろえるだけではこうした差は消えないため、代表的な入力と出力の例を同じ条件で各社へ渡します。自社が用意する資料を増やすなら、比較に直結するものから選びましょう。

表が収まらない場合は横にスクロールできます。

予算を下げるなら、品質より先に対象を絞る

最初は一つの事業部で使う、承認を一段階にする、レポートは一覧出力から始める。こうした変更なら、狙う効果を保ちながら仕事量を減らせる可能性があります。反対に、権限や重要データの保存確認を外すと、安心して使える範囲そのものが狭まります。削る項目ごとに、運営へ戻る仕事も一緒に確認しましょう。

連携先の仕様や古いデータの状態が不明なら、調査を先に区切る案があります。たとえば実データのサンプルを取り込み、変換できない項目を洗い出してから本開発を見積もる方法です。調査費を払うなら、調査後に何が分かるかと、その結果で開発を止めたり範囲を変えたりできるかも確認します。

削った機能は、追加する条件まで残しておきます。初回は申込みを人が承認し、対応が追いつかなくなったら自動化を検討する、といった区切りです。単に「次の開発へ延期」と書くより、なぜ今は不要で、何が変わったら必要かが分かります。開発会社にも、後から加えるときにデータ構造を大きく変える必要があるかを聞いておくと、目先の削減と将来の作り直しを比較できます。将来の全機能を先に実装する必要はありません。

公開までの日数と、公開後の支払いも見ておく

1人月は160時間換算の作業量であって、必ず一か月で公開できるという意味ではありません。発注側の原稿確認、利用アカウントの準備、外部サービスの審査で待つ時間もあります。短い納期の提案は、実装完了までか、本番で使い始めるまでかをそろえます。要望を変える際は、追加費用と再確認の日程を着手前に相談できる仕組みが必要です。

外部サービス利用料、ドメイン、有償素材、撮影・取材、広告費・広告運用は、ダンドリの設計・開発の料金基準には含まれません。保守・継続開発は月5万円〜で、当社が開発・納品したシステムが対象です。他社システムの保守のみは受けていません。初期費用に加え、どんな作業を継続して頼むかまで決めると、運営に使える予算を残せます。

引き渡しの条件も費用判断に関わります。ソースコードや管理アカウントへ誰がアクセスでき、保守先を変えるときに何を受け取れるかを聞きます。外部サービスの契約が制作側の個人名義に集まっていると、担当交代で困る場合があります。初期の導入を代行してもらう場合も、契約主体と日常の管理者を区別して確認します。運営に必要な情報を受け取れるかまで見ると、公開時点だけでは分からない負担を比べられます。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □各社に同じ利用場面と初回の対象を伝えた。確認状況・メモ：
• □会員・決済などの機能名の裏にある処理を聞いた。確認状況・メモ：
• □自社が準備・手作業で対応するものを把握した。確認状況・メモ：
• □調査が必要な事項と、金額を見直す時点が分かる。確認状況・メモ：
• □開発費と外部利用料・保守費を分けて見た。確認状況・メモ：
• □本番公開までの日程と、変更時の相談方法を確認した。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Authorization Cheat SheetOWASP Foundation
• Receive Stripe events in your webhook endpointStripe