業務システムやアプリを外注しようと何社かに見積もりを取ったら、金額が会社によって何倍も違った。よくある話です。どちらかがぼったくっているとは限らず、多くの場合、各社は別のものを見積もっています。
見積もりを出す側は、依頼の中で決まっていない部分を自分で想像して埋めます。「予約を管理したい」とだけ書かれていれば、ある開発会社はスマホで予約を受ける画面まで入れ、別の開発会社は社内で入力する台帳だけを考える。どちらも間違いではない。発注する側が決めていないことが多いほど、各社の想像がずれて、金額の差が広がります。
逆に言えば、依頼の前に社内でいくつか決めておくだけで、見積もりは比べられるものになります。専門用語で書く必要はありません。社内の言葉で書いたメモで十分です。手書きでもいい。
見積もりの金額がばらつく仕組み
開発の費用は、ほぼ作業時間で決まります。単純な話です。そして作業時間は、画面の数、扱うデータの種類、例外の多さで変わります。
抜けやすいのは例外です。「基本はこの流れだけど、常連さんは電話で直接入れる」「月末だけ別の集計が要る」「担当者が休みの日は別の人が承認する」。現場では当たり前のことほど、依頼文から抜けます。
見積もる側に選べる手は二つです。分からない部分を安全側に積んで高めに出すか、いったん外して安く出すか。安く出した会社の見積もりには、後から追加費用が出る余地が残っています。高く出した会社は、分からない部分に余裕を持たせているのかもしれません。依頼の情報が少ないと、金額の安さが本当の安さなのか、外しているだけなのかを発注側が見分けられなくなります。
今の仕事の流れを紙1枚に
まず、今の仕事の流れを書き出します。システムにしたい部分だけでなく、その前後も書きます。
書き方は自由です。付箋でも箇条書きでも構いません。大事なのは次の点が読み取れることです。
- 仕事が始まるきっかけ（電話が来る、フォームが届く、月初になる など）
- 誰が、何を見て、何を書くか
- 紙やExcel、LINE、電話のうち、今どれを使っているか
- 例外の時にどうしているか
例外は、思い出せる限り書いてください。見積もりの差の多くは例外の扱いから生まれます。全部を今回のシステムに入れる必要はありません。書いておけば、開発会社のほうから「これは手作業で残しましょう」と提案できます。
量も添えておくと助かります。1日に何件くらい来るのか、忙しいのは月末か週末か、過去のデータは何年分あって新しいシステムに移したいのか。正確な数字でなくても、だいたいの桁が分かれば十分です。特に過去データの移し替えは、Excelの書き方が人によってばらばらだと手作業が増え、それだけで費用が変わります。
使う人と使う場面
同じ予約管理でも、使うのが事務の方1人なのか、現場のスタッフ10人がスマホで見るのか、それともお客様自身が家から予約を入れるのかで、画面の数も、確認のしかたも、作るものがまるで変わってきます。
決めておきたいのは、誰が使うか、どの端末で使うか、どこで使うかです。事務所のパソコンだけなら画面は1種類で済みます。現場でスマホから見るなら、手袋のまま押せるか、電波の弱い場所で使うか、といったことも関係してきます。お客様が触る画面があるなら、説明なしで使えるかどうかが大事になり、その分の手間が増えます。
見落としやすいのが、人によって見せる情報を変えたいかどうかです。売上は社長だけが見る、パートさんには自分のシフトだけ見せる。こうした権限の分け方は後から足すと手間がかかるので、最初に伝えておくと見積もりが正確になります。
やめたい作業と、残したい作業
目的は、たいてい何かの作業をやめることです。ところが依頼文には「作りたいもの」だけが書かれ、「やめたいこと」が書かれていないことがよくあります。
たとえば「毎月の請求書作りに丸1日かかっている、これをやめたい」と書いてあれば、開発会社は請求書のところから考えます。やめたいことが分かると、作るべきものの優先順位を開発会社と一緒に決められます。
同時に、残したい作業も書いておきます。紙の控えは法律や取引先の都合で残す、ベテランの目視チェックは今のままにする、など。全部をシステムに置き換えるつもりで見積もると、現場で本当は困っていない作業まで画面にすることになり、金額も完成までの期間も、思っていたより大きく膨らみます。やめる作業と残す作業の線を引いておくことが、費用を抑えるいちばん確かな方法です。
予算の出し方と、完成後の費用
予算を伝えると高く見積もられるのでは、と心配する方がいます。気持ちは分かります。それでも上限は伝えたほうがいい。伝えないと、各社はそれぞれが想像した規模で出すので、比べる土台がそろいません。
伝えるのは上限の目安で十分です。「今年は200万円まで、うまくいけば来年また出せる」と分かれば、開発会社は最初に作る範囲と次に回す範囲を分けた提案ができます。最初から全部を作らず、いちばん困っている作業から小さく始めるほうが、使ってみて分かる直しにも対応しやすくなります。
もう一つ、完成した後にかかる費用も決めておきます。サーバーの利用料、保守の月額、法改正や取引先の変更に合わせた手直しなどです。初期費用だけで比べると、月々の費用が高い会社を選んでしまうことがあります。月々いくらまでなら払い続けられるかを、社内で先に決めておいてください。費用の目安は業務システムの費用をまとめた記事も参考になります。
動き出した後に面倒を見る人
ここが一番抜けます。完成後の社内の担当者です。ここが空いたままだと、システムは作ったのに使われなくなる、という結果になりがちです。
決めておきたいのは次のようなことです。
- 社内で困った時に最初に相談を受ける人
- 新しく入った人のアカウントを作り、辞めた人のアカウントを止める人
- データの持ち主はどこか（自社か、開発会社か）
- 不具合の連絡を開発会社に入れる人
データの持ち主は特に大事です。後で開発会社を変えたくなった時に効いてきます。データを自社で取り出せる形で受け取れるかを、見積もりの時に聞いておいてください。保守契約でどこまで開発会社が見てくれて、どこからが別料金なのかも、同じタイミングで確かめます。
詳しくなくていいんです。「この件はこの人に聞けばいい」が決まっていることが大事です。
見積もり依頼に添えるもの
ここまでの内容を、見積もりを頼む全社に同じ形で渡します。A4で2〜3枚のメモで十分です。
- 今の仕事の流れ（例外を含めて）
- 使う人、端末、場所、見せる情報の分け方
- やめたい作業と残したい作業
- 予算の上限と、月々払える費用の目安
- 完成後の社内の担当者
決めきれない項目は、空欄にせず「未定」「社内で意見が割れている」と書いておきます。何が決まっていないのかが分かれば、開発会社はその部分を別の金額として分けて出せます。
全社に同じメモを渡すと、見積もりの金額だけでなく、各社の質問の仕方も比べられます。メモを読んで「ここはどうしますか」と細かく聞いてくる会社は、例外まで考えて見積もろうとしている会社です。
要件を決めるところをもっと詳しく知りたい方には、IPAが発注者向けに出しているユーザのための要件定義ガイド 第2版があります。ページ数は多いですが、よくある失敗と対処が並んでいるので、気になる項目だけ拾い読みしても役に立ちます。
当社でも業務システムやアプリの開発を承っていて、メモがまだ固まっていない段階でのご相談も受けています。
