同じ「顧客管理を作りたい」でも、相見積りを取ると金額が数倍違うことがあります。手抜きでも、ぼったくりでもありません。違っているのは、前提です。どこまで作るか、誰が使うか、どんな例外を見込むか。それを伝えていない分を、各社は自分の解釈で埋めます。だから幅が出ます。
画面数や機能名が固まっていなくても、前提は伝えられます。伝えるべきは、作りたいものの名前ではなく、業務上の困りごと、使う人、判断に迷う場面、事故が起きやすい情報です。
見積りの幅は、相手の腕よりも、こちらが渡した前提で決まる。
(想定例)製造業で事務を担う佐藤さんは、同じ要望メモを3社に送りました。返ってきた見積りは、倍以上に開きます。戸惑いますが、からくりは単純でした。メモに書かなかった例外処理や権限を、各社がそれぞれの解釈で見積もっただけ。差は腕ではなく、渡さなかった前提にありました。
1. 目的と困りごとを、一文で書く
「何を作りたいか」より先に、「何に困っているか」を一文で書きます。最新版が分からない、転記が多い、承認状況が追えない、担当者不在で止まる。この程度の表現で十分です。
- いま一番困っている作業
- 誰が困っているか
- どのタイミングで止まりやすいか
- ミスが起きたときに影響する相手
- いま使っているExcel、紙、メール、SaaS
2. 必須と後回しを、分ける
全部を一度に作ろうとすると、見積りも開発も膨らみます。初回で必ず要るものと、あとから足してよいものを分けておく。それだけで、各社が同じ前提で見積もれるようになり、幅が縮みます。
- 初回リリースで必要な画面
- 後回しにできる帳票や集計
- 今のExcelを残す部分
- 他のシステムと連携したい時期
- 手作業のまま残す確認作業
3. 権限と記録が要る場所を、伝える
金額、契約、個人情報、顧客への連絡に関わる作業は、便利さだけで決めないほうが安全です。誰が見てよいか、誰が直してよいか、変更履歴を残すべきか。ここは見積りの前提を大きく動かすので、相談時に共有します。あとから足すと作り直しになりやすい部分なので、NeoLogicでも、画面や機能の前に、権限と記録の要否を要件整理の段階で一緒に確かめます。
見積りの前に、これだけメモする
完璧な仕様書は要りません。目的、利用者、必須範囲、既存資料、権限や記録が要る場所。この5つをメモしておくだけで、見積りの精度は上がり、各社の金額も比べやすくなります。