業務アプリの見積りは「含まれないもの」から読む

たとえば、机の上に見積りが3通あるとする。5万円、12万円、28万円。どれも書いてあるのは「業務システム開発一式」の一行と、納期と、振込先だけ。

安いところに頼んで失敗するのは怖い。かといって28万円を払う根拠も見当たらない。こうして数週間止まってしまうことがあります。見積りを並べたところで手が止まる、という話はよく聞く。

先に結論を書く。見積書は、書いてあることではなく書いていないことから読む。金額の差は腕の差ではなく、範囲の差であることがほとんどだ。

金額の差は、たいてい範囲の差

同じ「顧客管理アプリを作ってほしい」という依頼でも、出来上がるものは全然違う。画面が2つのものと8つのもの。1人で使うものと、20人が同時に触るもの。ログインが要るか要らないか。部署ごとに見えるデータを変えるかどうか。

5万円の見積りは、小さく作る前提で正しく積んだ数字かもしれない。28万円の見積りは、広めに見ているだけかもしれない。どちらが妥当かは、開発者ではなくあなたの業務が決める。だから比べるのは金額ではなく、その金額がどこまでを指しているかになる。

厄介なのは、範囲を文章だけで書いた見積りだ。「貴社の業務に合わせた管理システムを構築します」と書いてあると、読んだ側は自分の頭の中にある理想の姿を当てはめて読んでしまう。そして着手のあとに必ず出てくるのが、「それは当然含まれていると思っていました」である。

物差し1｜画面の数と、使う人数

範囲を数字で切るなら、まず画面数と利用者数を見る。当方の標準も、画面数と利用者数の上限を先に決めておき、超える分は追加画面1セットいくら、と単価を出しておく形にしている。

画面数を聞くときは、数え方も一緒に確認してください。「一覧・登録・編集・削除」をまとめて1画面と数える人と、4画面と数える人がいる。同じ「5画面」でも中身が4倍違うことになる。

利用者数は、単なる人数制限の話ではない。1人しか使わないなら、同時に同じデータを触ったときの処理を考えなくていい。5人が同時に触るなら、後から保存した人が前の人の入力を消してしまう、という事故を防ぐ作りが要る。人数は、そのまま作りの複雑さになる。

物差し2｜修正は何回まで、バグ対応は何日か

次に見るのが、渡したあとの話。ここは性質の違う2つが混ざりやすい。

ひとつは修正。「やっぱりこの項目も入れたい」という仕様の変更で、当方は無償で受ける回数を先に決めて、そこから先は別見積りにしている。もうひとつはバグ対応。決めた仕様どおりに動いていない状態のことで、これは無償で直すのが筋だ。当方はお渡しから14日間としていて、この14日を、そのまま動くかどうかを確認していただく期間として扱っている。

見積書にこの区別がないと、着手後に全部が「修正」として押し寄せるか、逆に全部が「仕様変更なので追加費用です」になる。どちらに転んでも気分は悪い。

「修正無制限」と書いてある見積りは、むしろ一度立ち止まったほうがいい。

回数を数えていないということは、範囲を決めていないということでもある。実際には途中から「それは仕様変更にあたります」と線が引かれるか、最初から不安分が金額に乗っているかのどちらかになりやすい。ちゃんと数えてある見積りのほうが、結果として安く済むこともある。

物差し3｜費用は、誰が持つのか

「月額0円」「買い切り」と書かれていても、アプリが動いている場所の代金はどこかで発生している。サーバー、ドメイン、通信。誰の名義で契約して、誰が払うのか。ここは見積りの段階で確認しておいてください。

当方は依頼者さま名義でのご契約をお願いしている。理由は開発費と月々の費用を切り離せるからだけではない。名義が開発者側にあると、その人と連絡が取れなくなった瞬間にアプリが止まる。支払いが遅れても止まる。データの持ち主も曖昧になる。名義が依頼者側にあれば、少なくとも自分の意思で維持できる。

とはいえ設置作業まで自分でやるのは骨が折れるので、そこは代行を有料オプションにしている。費用を誰が負担するかと、作業を誰がやるかは、別の話として分けておくと整理しやすい。

着手前に、完了条件を一行で書く

ここからは発注する側でも準備できることだ。まずいつ終わったことにするのかを、着手の前に文字にしておく。

「案件管理ができる」では終わらない。この書き方だと、渡したあとに「検索も欲しい」「月ごとの集計も見たい」が続いて、いつまでも終わらない。開発側も終われないので、結局どこかで気まずくなる。

粒度は「一覧・登録・編集・削除が動く」くらいまで落とす。動いているかどうかを、両方が同じ基準で判定できる形にする。当方はご購入いただく前に、画面の一覧とやらないことを1枚にまとめてお渡ししている。やらないことを先に書いておくほうが、揉め事はよく防げる。

受け取るものを、先に決めておく

最後は納品物だ。動く画面だけ渡されて終わり、という形は避けたほうがいい。

当方の場合は、ソースコード一式、データベースのバックアップ手順、管理者向けの操作手順を1枚。なかでもソースコードを受け取れるかどうかは、あとから他の技術者に引き継げるかどうかを決めてしまう。受け取れないなら、その先ずっとその開発者にしか直せない。

そして、受け取れるかと同じくらい大事なのが、受け取ったソースをどこまで自由に扱ってよいかだ。他の技術者に渡して直してもらえるか、社内の別業務に流用してよいか。ここも見積りの段階で文字にしておきましょう。手元にあることと、好きに使えることは別だ。

小さい依頼でも考え方は同じ。当方は1業務・1〜2画面の小さなツールもお受けしているが、そちらでも本体と使い方の説明はお渡しする。金額の大小と、手元に何が残るかは別の話だ。

---

当方はココナラで、Excel・紙で回している業務を買い切りのWebアプリにする仕事をしている。当方への月額料金は0円ですが、サーバー代は依頼者さま名義でのご負担になります。今回の物差しは他所に頼むときもそのまま使えるので、比べる候補に当方も入れていただけるようでしたら、ココナラのメッセージからご相談ください。