あなたのお見積もりはどこから？私は設計から

私が経験してきた受託の光景を思い出しながら、一括請負のスタイルで儲けるのは難しいなあ、という話をつらつらと。話題が課題のみ散発的な感じになるので、しばらく寝かせておいたら発酵していいアイデアになるかもしれません。どうするかはチームで模索中なので、理想的なビジネスモデルまでは出てきません。

見積もり

だいたい見積もりと時期に関する相関は皆さんもこんな感じかな、と思います。みんな大好き不確実性コーン。

で、一括請負の場合、どこかの時点で契約のための合意をとる必要があるわけですが、開発はこの時点以降のコストをコミットメントします。開発プロセスの改善は、合意したこの期間のコスト計画の最適化として作用するわけです。

お客さまが見積もりを高いと感じる理由

この時、合意前まで動いていた分というのがあります。営業がかけた費用やら、開発の調査やら打ち合わせやら見積もりのためのお試しやら。何がしかの形でお客さまからいただかないと合意ポイント移行のコストと利益だけでは赤字です。基本的な回収戦略は「保守開発で継続的にいただく」か「単発で終わる覚悟で回収しにいくか」のどちらか(あるいはミックス)となります。

ところが、実際にその費用を出してみると、お客さまは高いと感じることがあるようです。開発と見積もりに向けた具体的な内容の話をしている間で、おそらくお客さまにも合意ポイント移行の規模感ができているからでしょう。

というわけで、保守開発頼みで契約を取るために合意したコストギリギリで請け負ってしまうとかも実際にはありえます。そもそも最初の契約を取らないと回らないわけですから。

見積もり精度を上げるには

ところで、見積もり精度を上げるための方策は大きく分けて下図のどちらかになります。

具体的なやり方の話でいうと、

• なるべく多くの目で見積もり
• 見積もり対象およびゴールについての情報を得る
• プロダクトについての学習を得る

となり、それぞれが案1,2に関わります。三番目なんかは、単発のプロジェクトではあまり望めないことで、保守開発としてプロダクトに継続的に関わることで得られる知見がないとやり方として成り立たないので、プロジェクト開始期には望むべくもないという感じです。

私のチームは、その上で解決方のパターンを出して選んでもらったりします。

で、残念ながら、これらの見積もり精度を上げる話は、受託の儲けの話にはあんまり寄与しないんですよね。案2とか特に。

見積もりなんか正確にできるわけがない

それは当然。ですが、お客さまの事業も年度の予算計画がある中で動いています。当然、ロードマップから大きく外れるようなことがあれば上司に説明責任が出てきます。その合意を得るプロセスが嫌なら、自社で内製するための組織を抱える方がよっぽどいいと思います。

まとめ

単純な話だけしてるので、現場の細かいところはそうじゃなかったりするし、お客さまの習慣的な話で「見積もりはただ」というところでその費用を認めてないところもあるし、個別の問題は出てきますが、総じて儲けは取りづらいというのが今までの経験です。で、何をどうすればいいか、と言うのはまだまだ模索中。そもそも一括請負やめたほうがいいよね、が理想なんですが、お客さまが乗ってきてくれるかは全く別の話だったりして悩ましい。