受託開発の見積で赤字になる、要件定義の詰めどころ
「見積もったときは黒字だったはずなのに」
契約したときは、ちゃんと利益が出る計算だった。それなのに、いざ作り始めると「あれもお願い」「ここも直して」が続き、気づけば工数が倍になっていた。納品するころには、ほとんど利益が残っていない。受託でシステムやサイトを作っている方なら、一度は経験があるのではないでしょうか。
こうした「見積では黒字、終わってみれば赤字」は、たいてい作業中のミスが原因ではありません。多くの場合、開発が始まる前、つまり要件定義の段階で、詰めきれていなかったことが後から効いてくるのです。
赤字を防ぐ鍵は、コードを速く書くことよりも、「何を作るか」を最初にどこまで握れるかにあります。
「言われた通り」ではなく「なぜそれが要るのか」を聞く
要件をヒアリングするとき、お客さんの言葉をそのまま受け取ってしまうと危険です。お客さんは「こういう機能がほしい」と言いますが、その裏には「本当はこういう困りごとを解決したい」という目的があります。
ここを聞かずに言われた通り作ると、完成してから「思っていたのと違う」となり、作り直しが発生します。これが赤字の大きな原因です。「その機能で、どんな作業を楽にしたいんですか」と一歩踏み込んで聞く。目的がわかれば、もっと簡単な作り方が見つかることもありますし、認識のズレを最初に防げます。
「やらないこと」を書いておく
見積が崩れるいちばんの理由は、途中で仕事がじわじわ増えていくことです。これを防ぐには、「やること」だけでなく「今回はやらないこと」を、はっきり書いておくのが効きます。
たとえば、「今回はこの機能まで。この部分は次のフェーズで別途」と最初に紙に書いて、お客さんと一緒に確認しておく。こうしておくと、あとから追加の要望が出たときにも、「それは範囲外なので、別のお見積りになります」と自然に話せます。線を引くのは冷たいことではなく、お互いを守るための約束です。
あいまいな言葉を、その場でつぶす
「いい感じに」「よしなに」「ざっくり」。こうしたあいまいな言葉は、後で必ずトラブルになります。人によって思い描くものが違うからです。
ヒアリングの場で、あいまいな言葉が出たら、その場で「たとえばこういうことですか」と具体例に置き換えて確認します。画面のイメージを簡単な手書きでいいので一緒に見ると、ズレが一気に減ります。この地道な確認が、あとの作り直しを何倍も減らしてくれます。
まとめ:次の見積前に、「やらないこと」を一行書く
受託開発の赤字は、作業の速さではなく要件の詰め方で決まります。次に見積を出す前に、まず「今回やらないこと」を一行書いてみてください。それだけで、途中で仕事がふくらむのを防ぐ土台ができます。
要件の整理やお客さんとの認識合わせの進め方に迷ったら、五月雨がお手伝いできます。現場の実態に寄り添って考えますので、気になったときに気軽に声をかけてください。
