電話で受けた予約を紙のカレンダーへ書き、LINEで届いた変更依頼を担当者へ転送する。メールで届いた申込内容を手元の表へ移し、夕方になってから「返信済みか」「担当者は見たか」をもう一度確かめる。そんな作業をWebアプリにしたいと思ったとき、費用の見当がつかず不安になることがあります。

Webアプリとは、ブラウザやスマートフォンから使える業務用の画面です。見た目は入力画面、一覧画面、確認画面の3つだけに見えても、実際には通知、権限、保存する情報、例外時の対応、個人情報の扱いまで一緒に考える必要があります。

この記事では、画面数だけでは費用が読みにくい理由を、依頼する側が相談前に確認できる前提として整理します。相場を断定するのではなく、見積もり前に何を聞けばよいかを見える形にします。

画面数だけで考えると不安になります

「入力と一覧だけなら小さく作れそう。でも、どうして見積もりが大きくなるのか分からない」

たとえば、次のような場面です。

  • 電話で受けた予約を入力するだけに見えるが、変更、キャンセル、前日のお知らせまで考えると範囲が広がる
  • LINEで届いた注文を一覧にしたいが、担当者へのお知らせ、対応済みの印、月ごとの確認も必要に見える
  • 紙の申込書をフォームにしたいが、入力ミス、重複申込、確認メール、管理者の確認をどうするかで迷う
  • スタッフ用の画面は少なく見えるが、店長だけが見られる情報や変更できる項目を分けたい
  • お客様の名前、連絡先、予約内容を扱うため、安全な保管や閲覧できる人の整理が必要になりそう

この不安は、依頼する側の準備不足だけが原因ではありません。

業務用のWebアプリは、画面の枚数よりも「その画面の裏で、誰が、何を、どこまで確認するか」で大きさが変わります。だから、最初から正確な金額を当てようとするより、費用が変わりやすい前提を相談できる状態にする方が現実的です。

先に結論

Webアプリ開発の費用は、画面数だけでは決まりません。

特に、次の7つを相談前に見ると、見積もりの前提をそろえやすくなります。

  1. 使う人とログインの分け方
  2. 入力する情報と保存しておく情報
  3. 確認、承認、差し戻しの流れ
  4. 通知する相手とタイミング
  5. 管理画面で誰が何を直すか
  6. 外部サービスや今の表とのつなぎ方
  7. 個人情報と安全対策の考え方

この7つは、専門的な資料にする必要はありません。

「店長だけが変更できる」「受付には申込内容だけ知らせたい」「月ごとの確認は手元の表でよい」のように、日常の言葉で十分です。

開発会社へ相談するときは、金額だけを先に聞くより、どの前提が大きくなりそうか、どこを小さく始められるかを一緒に確認します。

同じ3画面でも、前提で大きさが変わります

「入力画面、一覧画面、詳細画面だけなら安く作れますか」と聞きたくなることがあります。

ただ、同じ3画面でも、次のように中身が変わります。

  • 入力した内容を誰でも見てよいのか、担当者ごとに見える範囲を分けるのか
  • 入力後にすぐ確定するのか、店長が確認してから確定するのか
  • お客様へ自動でお知らせするのか、担当者が文面を確認してから送るのか
  • 間違えたときに誰が直せるのか、直した履歴を残すのか
  • 月ごとの確認は画面で見るのか、手元の表へ取り出して確認するのか

画面数は入り口です。

相談で見るべきなのは、画面の裏にある仕事の流れです。

画面だけで見る言い方実際に確認したいこと費用の前提が変わる理由相談時の言い方
入力画面がほしい

誰が入力し、必須項目はどれで、間違えたときに誰が直すかを確認する

入力の確認、エラー表示、修正の扱いで必要な準備が変わる

最初は受付担当が入力し、店長だけが修正できる形で相談したい

一覧画面がほしい

何を並べ、どの状態を見分け、どの項目で探したいかを確認する

状態管理、検索、並び替え、担当者ごとの表示で範囲が変わる

初回は未対応、確認中、返信済みが分かればよい

通知がほしい

誰へ、いつ、どんな文面で知らせ、送れなかったときにどう気づくかを確認する

通知先、文面、再送、送信失敗の確認で必要な作り込みが変わる

初回は受付担当へのお知らせだけにして、お客様向けは文面を確認したい

管理画面がほしい

管理者が何を変更し、現場担当には何を見せないかを確認する

権限、変更履歴、誤操作の防止で必要な確認が増える

店長だけが状態を戻せる形にしたい。細かい権限は後で相談したい

この表は、費用を下げるためだけの表ではありません。

相談前に前提をそろえ、必要なものと後でよいものを分けるための表です。

費用が変わりやすい7つの前提

ここから、7つの前提を一つずつ見ます。

1. 使う人とログインの分け方

使う人が一人なのか、複数の担当者なのかで変わります。

受付担当、現場担当、店長、外部の協力者、お客様がそれぞれ使う場合、見える情報やできる操作を分ける必要があります。

最初は、全員分の細かい権限を作り込まなくてもよい場合があります。たとえば、受付担当と店長だけで始め、現場担当の細かい画面は後で足す形です。

相談前には、次のように書きます。

  • 最初に使う人は受付担当2名と店長1名である
  • 店長だけが内容を変更できる
  • 現場担当は、最初は一覧を見るだけでよい

2. 入力する情報と保存しておく情報

名前、連絡先、申込内容、対応状況、担当者メモ、日付。どの情報を残すかで、作る範囲は変わります。

後で月ごとに確認したいなら、日付や担当者を残しておく必要があります。後で検索したいなら、検索したい項目を最初から入力できる形にしておく必要があります。

「今すぐ画面に出すか」だけでなく、「後で確認したいか」を相談します。

3. 確認、承認、差し戻しの流れ

申込や予約が入ったら、すぐ確定するのか。店長が確認してから確定するのか。内容に不備があれば、お客様へ確認するのか。

この流れがあると、状態を分ける必要があります。

たとえば、未対応、確認中、返信済み、保留、取り消しのような状態です。最初から増やしすぎると複雑になりますが、少なすぎると現場で使いにくくなります。

相談前には、「最初はどの状態があれば仕事が進むか」を書きます。

4. 通知する相手とタイミング

通知は便利ですが、範囲が広がりやすい機能です。

受付担当へ知らせるだけなのか。お客様へ確認メールを送るのか。前日のお知らせを送るのか。店長へ未対応だけ知らせるのか。

文面を固定でよいか、担当者が確認してから送るかでも変わります。

最初は、通知先を一つに絞っても構いません。「受付担当へ申込を知らせる」だけでも、転記や確認漏れの改善につながる場合があります。

5. 管理画面で誰が何を直すか

管理画面は「あとで見る画面」ではありません。

実際には、登録内容の修正、状態の変更、検索、月ごとの確認、担当者の割り当て、お知らせ文面の変更などを扱います。

すべてを初回から作ると大きくなります。

まずは、現場が止まらないために必要な変更だけを選びます。たとえば、申込内容の修正と対応状態の変更だけです。

6. 外部サービスや今の表とのつなぎ方

Googleカレンダー、予約サービス、会計ソフト、メール配信、チャット、手元の表。今使っている道具とつなぎたい場合、確認することが増えます。

相手のサービスが何を受け取れるか、どの情報を取り出せるか、送れなかったときにどう気づくかを見ます。

初回は、自動でつながず、手元の表で確認する形でもよい場合があります。後でつなぐ可能性が高いなら、必要な情報だけ先に残しておきます。

7. 個人情報と安全対策の考え方

お客様の名前、連絡先、予約内容、申込内容を扱う場合、誰が見られるか、どこまで保存するか、不要になった情報をどう扱うかを考えます。

個人情報保護委員会のガイドラインでは、個人情報の利用目的、取得、個人データの管理、安全管理措置などが整理されています（参考）。

また、IPAの中小企業向けガイドラインでは、経営者が認識すべき指針と社内で実践する手順がまとめられています（参考）。

小さなWebアプリでも、お客様情報を扱うなら安全対策は後回しにしすぎない方がよいです。

ただし、最初から大げさな仕組みにする必要があるとは限りません。扱う情報、使う人、保存期間を整理し、必要な対策を相談します。

根拠から見た考え方

費用の話をするとき、金額だけを見ると判断が難しくなります。

先に見るべきなのは、業務と仕組みの前提です。

デジタル庁の標準ガイドライン群は、サービス・業務改革と情報システムの整備をまとめて扱い、開発前に決める内容や相談先へ伝える内容のテンプレートも示しています（参考）。これは政府向けの資料ですが、「業務の見直しとシステムを切り離さない」という考え方は、小さなWebアプリの相談にも使えます。

IPAの情報システム・モデル取引・契約書では、契約の時点で作る内容、進め方、完成として確認する方法について共通理解を持ち、対話を深めることが期待されています（参考）。依頼する側も、何を作るかだけでなく、何を確認して完了とするかを話せると、見積もりの前提がそろいやすくなります。

GOV.UKのサービスマニュアルでは、作り始める前に、利用者、制約、既存の業務や仕組みを理解することが大切だと説明されています（参考）。また、試す段階では、全体を作るのではなく、難しそうな部分に絞って確かめる考え方も示されています（参考）。

これらをReady Mock向けに言い換えると、次のようになります。

  • いきなり金額だけを聞く前に、今の業務の流れを書く
  • 画面数ではなく、誰が何を確認するかを書く
  • 最初から全部作らず、費用が大きくなりそうな前提を小さく試す
  • 個人情報や安全対策は、扱う情報と使う人を先に整理して相談する

相談前にできる5つの整理

完璧な資料は不要です。

ただ、次の5つをメモしておくと、見積もりの前提を相談しやすくなります。

1. 「画面名」ではなく「今の作業」を書く

最初は、入力画面、一覧画面、管理画面のように書かなくて大丈夫です。

次のように、今の作業をそのまま書きます。

  • 電話で予約を受け、紙のカレンダーへ書く
  • LINEで変更依頼が来たら、担当者へ転送する
  • メールで届いた申込内容を手元の表へ移す
  • 夕方に未返信の人がいないか確認する

この書き方なら、開発会社も「どの作業を楽にしたいのか」を見やすくなります。

2. 最初に楽にしたい流れを一つに絞る

注文、予約、申込、問い合わせ、在庫確認を一度に変えようとすると、前提が増えます。

最初は、一つの流れを選びます。

たとえば、予約変更の確認漏れが一番困っているなら、「予約変更を受ける、担当者へ知らせる、お客様へ返信する」までを最初の流れにします。

月ごとの確認や細かい検索は、後で足せるかを相談します。

3. 自動にしたいことと、手で残してよいことを分ける

全部を自動にすると、例外の扱いまで考える必要があります。

最初は、手で残してよいことを決める方が進めやすい場合があります。

  • 確認メールは決まった文面でよい
  • 月ごとの確認は手元の表でよい
  • お客様への個別返信は、最初は担当者が確認してから送る
  • 請求書作成は今の会計ソフトで続ける

手作業を残すことは、失敗ではありません。

最初に確認したい価値へ集中するための分け方です。

4. 「あとで足したいこと」は先に伝える

初回には作らなくても、後で足したいことは伝えておきます。

たとえば、後で月ごとに確認したいなら、日付、担当者、状態を保存しておく必要があります。後で外部サービスとつなぎたいなら、どの情報をつなぐかを考える必要があります。

「今は作らない」と「あとで困ってもよい」は違います。

初回では小さく作りつつ、後で足したい前提を相談します。

5. 個人情報をどこまで扱うかを書く

氏名、電話番号、メールアドレス、住所、予約履歴、相談内容。どこまで扱うかで、確認すべき安全対策が変わります。

相談前には、次のように書きます。

  • お客様の氏名と連絡先を扱う
  • 予約内容と担当者メモを保存する
  • スタッフ全員ではなく、受付と店長だけが詳細を見られるようにしたい
  • 退会やキャンセル後に、どの情報を残すかは相談したい

安全対策は専門家任せにする部分もあります。

ただし、扱う情報と見せたい相手は、依頼する側が一番よく分かっています。

小さく始めるなら、ここから相談します

費用が不安なときは、「安くしてください」より先に、小さく始める範囲を相談します。

次の3つに分けると話しやすくなります。

分け方向いている内容主なメリットデメリット・確認点相談時の言い方
最初から必要

入力、対応状況、担当者へのお知らせなど、これがないと最初の業務が進まないもの

現場で実際に使える流れになり、公開後の確認がしやすい

入れすぎると初回の確認範囲が大きくなる

この流れが止まらないために、初回から必要な範囲を一緒に見たい

小さく試す

スマートフォンでの確認、簡単な検索、担当者メモなど、使われ方を見たいもの

実際に使ってから広げるかを決められる

何を確かめるかを書かないと、ただの追加機能になりやすい

まず小さく入れて、現場が使うかを確認したい

今は作らない

月ごとの細かい確認、複数サービスとの自動連携、細かい権限など、後でよいもの

初回の相談範囲を小さくし、今ある道具を活かせる

後で足したいなら、必要な情報を先に残しておく

初回には作らないが、後で足せるかだけ確認したい

これは、必要なものを無理に削る考え方ではありません。

最初の相談で、費用が大きくなりやすい場所を見つけるための分け方です。

費用の前提整理チェック

全部にチェックが入らなくても大丈夫です。

未チェックの項目は、初回相談で確認する項目です。

そのまま使える相談メモ

費用の前提整理メモをコピーできます

画面数や機能名だけでは伝わりにくい前提を、相談前にまとめるためのメモです。分からない項目は「相談で確認したい」と書けます。

Webアプリ開発の相談で確認したい内容：

【今困っていること】
例：電話、LINE、メールで受けた内容を紙に書き、あとで手元の表へ移している

【最初に楽にしたい流れ】
例：問い合わせ受付 → 担当者確認 → お客様へ返信 → 対応状況の確認

【使う人】
例：受付担当2名、現場担当5名、店長1名

【扱う情報】
例：氏名、連絡先、申込内容、対応状況、担当者メモ

【確認や承認が必要な場面】
例：内容確認後に確定する、店長だけが変更できる、返信前に二重確認したい

【知らせたい相手とタイミング】
例：申込直後に受付へ知らせる、前日にお客様へお知らせする

【今の道具で続けてもよいこと】
例：月ごとの集計は手元の表で確認する、請求書は今の会計ソフトで作る

【あとで足したい可能性があること】
例：外部サービスとの連携、細かい検索、スタッフ別の画面

【費用が読めず不安なこと】
例：画面数は少ないのに、どこで大きくなりそうか分からない

【共有できる資料】
例：紙の記入例、今の管理表、よく使うLINE文面、確認メールの文面

次にやること

まず、今の業務から「最初に楽にしたい流れ」を一つ選びます。

次に、画面名ではなく、誰が何を入力し、誰が確認し、誰へ知らせるかを書きます。最後に、今は作らなくてもよいものと、後で足したいものを分けます。

開発会社へ相談するときは、次の3つを聞いてください。

  1. この内容で、費用が大きくなりやすい前提はどこか
  2. 初回から必要な範囲と、小さく試せる範囲はどこか
  3. 後で足すために、最初から残しておくべき情報はあるか

Ready Mockの業務改善チェックでは、紙、電話、LINE、メール、転記、確認漏れのうち、どこからWebアプリ化するとよいか確認できます。画面数や金額を考える前の入口整理に使えます。

参考情報