見積もりや要件定義のあとに発注をやめるとき｜契約前に立ち消えた案件で、開発会社側に起きていたこと

見積もりをもらったあとに発注をやめたい。要件定義まで進んだけれど、事情が変わって止めたい。そのとき費用はかかるのか、どう断ればよいのか。発注側からすると聞きにくい話だと思います。

この記事では、FUNBREWが実際に経験してきた「見積もりのあとに立ち消えになった案件」と、これまで1件だけあった「要件定義のあとにキャンセルになった案件」を、開発会社側から書きます。責めるための記事ではなく、開発会社の側で何が起きているかを知ってもらうための記事です。

見積もりのあとに立ち消えになるのは、珍しくない

見積もりを出したあとにそのまま発注に至らないことは、開発会社にとって珍しいことではありません。FUNBREWでも、見積もりを提出したあとに立ち消えになるケースは、結構な頻度であります。

金額が合わないのは、仕方がない

見積もりの金額が予算と合わなかった、という理由で発注に至らないのは、仕方のないことだと考えています。見積もりは「この内容をこの体制で作るといくらになるか」を示すもので、それが予算に収まらないなら、発注しないのは自然な判断です。見積もりがどう作られているかで書いたとおり、FUNBREWはバッファーを積まない見積もりを出しているので、金額が合わないときに無理に下げる余地はあまりありません。予算が先に決まっているなら、最初に予算を伝えてもらえれば、その範囲でできることを一緒に考えます。

困るのは、理由も連絡もないまま止まること

金額が合わないこと自体より、開発会社として困るのは、理由がわからないまま、あるいは連絡がないまま止まることです。これも実際に結構あります。

見積もりを出した側は、その案件のために時間を確保して待っています。返事がないと、断られたのか、社内で検討中なのか、忙しくて後回しになっているだけなのかがわかりません。「今回は見送ります」の一言があれば、確保していた時間を別の案件に回せます。理由は「金額が合わなかった」で十分です。断ること自体に気を遣う必要はありません。

見積もりを作る側では、何が起きているか

なぜ立ち消えが開発会社にとって重いのかは、見積もりを作るときに何をしているかを知ってもらうと伝わりやすいと思います。

開発の見積もりは、調査を含むことが多い

システム開発の見積もりは、料金表から金額を引くような作業ではありません。今ある業務の流れを聞き、既存システムがあればその中身を確認し、使えそうな技術や外部サービスを調べたうえで、必要な工数を積み上げます。つまり、見積もりを作る段階で、すでに調査という作業が発生しています。

この調査の工数は、見積もりの段階では請求していません。発注に至れば開発全体の中で回収できますが、立ち消えになれば、そのまま開発会社の持ち出しになります。

だから「何のための見積もりか」を確認することがある

調査に工数がかかるからこそ、FUNBREWでは見積もりの依頼を受けたときに、どういう用途で見積もりを依頼しているのかを確認することがあります。

たとえば、来期の予算を取るための概算がほしいのか、発注先を決める段階で正式な見積もりがほしいのかで、どこまで調べて出すべきかが変わります。予算取りの概算でよいなら、詳細な調査をせずに幅を持った金額を出すほうが、お互いに早いこともあります。見積もりを何パターンも依頼する前にでも書きましたが、見積もりの精度と、それを作るためにかかる手間は比例します。用途を最初に教えてもらえると、そこに見合った出し方ができます。

要件定義のあとにキャンセルになったのは、これまで1件だけ

見積もり段階での立ち消えは珍しくないと書きましたが、要件定義まで進んだあとにキャンセルになったのは、FUNBREWではこれまで1件だけです。その1件がどういうものだったかを書きます。

お客様が非常に忙しく、立ち消えになった

その案件は、何かが決裂したわけではありませんでした。お客様が非常に忙しい状態になり、打ち合わせの時間が取れなくなって、そのまま立ち消えになったというパターンです。誰かが「やめる」と決めたわけではなく、進める人の時間がなくなって、自然に止まりました。

途中で止まった案件のその後でも書いたとおり、いったん止まった案件は、よほどの意思がない限り再開されません。この案件も、そのまま終わりました。

要件定義の一部として、動くモックを作って提出していた

この案件で持ち出しが大きくなった理由は、要件定義の進め方にあります。FUNBREWはこのとき、要件定義の一部として、実際にシステムとして動くモックを作って提出していました。画面の絵ではなく、触って動くものです。

動くモックを要件定義の段階で出すのは、お客様が完成形をイメージしやすく、要件の認識のずれを早い段階で潰せるからです。ただ、それを作るには実装に近い工数がかかります。つまりこの案件では、要件定義という名前のもとで、開発の一部に相当する作業まで先に進めていたことになります。

契約前だったので、すべて持ち出しになった

そして、この案件はまだ契約前でした。契約前だったので、要件定義にかけた時間も、動くモックを作った工数も、お客様に請求はしていません。結構な持ち出し工数になりました。

これはお客様が悪いという話ではありません。契約前に、どこまでの作業を先に進めるかを決めていなかった、開発会社側の判断の問題でもあります。ただ、要件定義の段階で「動くもの」を求めるなら、その作業がどの扱いになっているかは、発注側にも知っておいてほしいところです。

発注側が知っておくとよいこと

ここまでを踏まえて、見積もりや要件定義のあとに発注をやめたいときに、発注側が知っておくとよいことをまとめます。

契約前なら、費用を請求されないのが一般的

契約を結ぶ前であれば、見積もりや要件定義にかかった工数を請求されないのが一般的です。FUNBREWでも請求していません。ただし、要件定義を有償のフェーズとして契約している場合や、着手金を支払ったあとであれば話は別です。自分の案件がどの段階にあるのか、交わした書面があるならその内容を確認してください。開発会社によって扱いは異なるので、不安なら直接聞くのがいちばん確実です。

断るときは、一言でよい

発注をやめるときに必要なのは、一言の連絡だけです。

• 「今回は見送ることになりました」だけで足りる
• 理由は「金額が合わなかった」「社内の優先度が変わった」で十分
• 謝る必要も、詳しく説明する必要もない

連絡が来ないことのほうが、開発会社にとっては重いです。見送りの連絡をもらって嫌な顔をする開発会社は、まずいません。

見積もりを頼むときは、用途を伝える

見積もりを依頼するときに、それが何のための見積もりかを一言添えてもらえると、開発会社はそれに合った出し方ができます。

• 予算取りのための概算なのか、発注先を決めるための正式な見積もりなのか
• いつまでに、誰が判断するのか
• 発注の可能性がまだ低いなら、その旨を正直に

可能性が低いと言われて見積もりを断る開発会社は少ないと思います。むしろ、それに見合った手間のかけ方ができるので、お互いに楽になります。

契約前にどこまで進めてもらうかは、先に決めておく

要件定義を契約前に進める場合は、どこまでを契約前の作業とするかを、開発会社と先に話しておくことをおすすめします。FUNBREWの1件のように、動くモックまで契約前に作ってしまうと、止まったときの持ち出しが大きくなります。それは開発会社の体力を削り、結果的に、その後の見積もりや対応に跳ね返ります。契約前は要件の整理と概算まで、動くものを作るのは契約後、といった線を引いておくと、発注側も気兼ねなく判断できます。

まとめ

契約前であれば、見積もりや要件定義のあとに発注をやめても、費用を請求されないのが一般的です。FUNBREWでも請求していません。ただ、見積もりには調査の工数が、要件定義には場合によって実装に近い工数がかかっていて、立ち消えになればそれは開発会社の持ち出しになります。

金額が合わないのは仕方のないことです。困るのは、理由も連絡もないまま止まることです。断るときは一言で構いません。見積もりを頼むときは用途を伝えてください。要件定義を契約前に進めるなら、どこまで進めるかを先に決めておいてください。それだけで、双方の無駄がかなり減ります。

見積もりの頼み方や、契約前にどこまで進めるかの線引きについては、お問い合わせからご相談いただけます。