はじめに

ソフトウェアの受託開発において、正確な見積もりはプロジェクトの成功に不可欠です。しかしながら実際には工数や期間が足りていなかったりプロジェクトを炎上させることは多々あるかと思います。本記事では、受託開発で失敗する見積もりのアンチパターンを5つ取り上げ、それぞれの事例と対策について解説します。この記事が、受託開発に携わるベンダーの皆様にとって有益な情報となり、プロジェクトの成功にお役立ていただければ幸いです。

対象の読者

ソフトウェア受託開発におけるプリセールス担当者
プロジェクトマネージャー
発注元企業の皆様（受託開発を検討される際の参考としてお読みいただければ幸いです）

アンチパターン① 開発要件が不明確な場合にウォーターフォールによる開発を提案する

ソフトウェアベンダーは発注企業から期日内までに成果物の納品を求められるケースが多い状況です。そこでベンダーサイドとしては、期日以内でプロジェクトを完了させるために、ウォーターフォールで提案したがる傾向にあります。ただし、一部の発注企業は、少しでも良いものを作りたいということで、途中で機能を多く盛り込んだり、変更依頼が発生したり、UIやデザインもブラッシュアップしたがる傾向にあります。中には発注企業自体があまりソフトウェア開発に詳しくない人がプロジェクト開始前に要件を伝えないこともあります。

その結果、プロジェクトを始めて、隠れた要件などが発生し、予算や工数が足りなくなることがあります。これがベンダーと発注企業との間での対立の要因となることもあるでしょう。

このような案件については、以下のように進めてみると良いと思います

アジャイル開発などでシステム変更ありきで提案する
- 予算の枠内で優先度を定義し、MVP（最小限の実行可能な製品）開発などを進める
要件定義と開発の2段階に分けて契約を締結する
- 要件定義の結果に基づいて開発の見積もりを改めて提示する

アンチパターン② 過小の見積もりを提案する

ベンダー側のプリセールス担当者は、案件を獲得するために、発注元企業が希望する予算と期限に収まるように提案したがる傾向があります。一方、発注元企業は、少しでもROIを高めて開発をしたいという思惑から、安価で期間の短い要望を出したがる傾向にあります。その結果、前述のアンチパターンのようなケースが発生し、大幅な赤字に陥ってしまうことが多々あります。

このような案件については、以下のように進めると良いでしょう。

開発工数を抑えるために以下手法を採用する
- ノーコードやローコード主体の開発手法を採用
- FirebaseやAmplifyなどのBaaSを使った開発手法を採用

アンチパターン③ ベンダー内のスキルセットのばらつきを考慮しない見積もりを提案する

ベンダー側のプリセールス担当者は、案件獲得のために、ベンダー内で最もスキルの高いエンジニアを基準に見積もりを作成してしまうことがあります。しかし、実際にプロジェクトにアサインされるエンジニアのスキルセットが見積もりの前提と異なる場合、開発の遅延や品質の問題が発生します。さらに、スキル不足を補うために外部リソースに依存することで、コストが増大し、プロジェクトが炎上する可能性があります。

このような案件については、以下のように進めると良いでしょう。

三点見積もり（最悪、最良、最尤）を採用し、スキルセットのばらつきを考慮する

三点見積もりの内訳は以下の通りです。

最悪のケース：スキルセットが最も低いエンジニアを基準とした見積もり
最良のケース：スキルセットが最も高いエンジニアを基準とした見積もり
最尤のケース：平均的なスキルセットのエンジニアを基準とした見積もり

アンチパターン④ 過去の類似プロジェクトの実績をそのまま適用する

ベンダー側のプリセールス担当者は、過去に成功した類似プロジェクトの実績をもとに、新しいプロジェクトの見積もりを作成することがあります。しかし、プロジェクトの規模、複雑さ、要件、アサイン要員、技術スタックなどが異なる場合、過去の実績をそのまま適用すると、見積もりが大きく外れる可能性があります。

このような案件については、以下のように進めると良いでしょう。

過去の類似プロジェクトの実績を参考にしつつ、現在のプロジェクトの特性を詳細に分析する
- プロジェクトの規模、複雑さ、要件、技術スタックなどの差異を明確にする
- 過去のプロジェクトとの差異を見積もりに反映させる

アンチパターン⑤ 不十分な与件理解と曖昧な要件定義に基づく見積もり

プリセールスが与件を十分に理解せずに見積もりを行ったり、要件定義が曖昧なまま開発フェーズの契約を結んでしまったりすると、プロジェクトの途中で大幅な手戻りや追加工数が発生し、当初の見積もりが大きく狂ってしまうリスクがあります。

このような状況を避けるために、ベンダーとしては以下のような対策を講じることが重要です。

要件定義が曖昧な状態では以下のように進める
- 開発フェーズの契約を結ばない
- どうしても開発フェーズに進む必要がある場合は、アジャイル開発を提案する
  - 工数や金額を見積もる際は、想定するユーザーストーリーを元に提案する（バッファも考慮に入れる）
  - 開発時は最低限MVP内で開発が完了できるように努める
与件が不明確な部分は以下のように進める
- クライアントに確認を取り、仮定条件を明示した上で見積もりを行う
- 見積もりの前提条件や範囲を明確にし、クライアントの同意を得る

アンチパターン⑥ 大規模開発にも関わらず超上流工程が不十分で、見積もりの誤差が発生しプロジェクトが頓挫する

大規模開発プロジェクトにおいては、要件の複雑さや関係者の多さから、プロジェクトの初期段階で十分な調査・分析を行うことが不可欠です。しかし、超上流工程（システム企画、システム分析、システム構想）が不十分なまま、不十分な情報に基づいて見積もりを行ってしまうと、プロジェクトの途中で大幅な手戻りや追加工数が発生し、当初の見積もりが大きく狂ってしまうリスクがあります。

ソフトウェア工学経済学（Software Engineering Economics）の観点からも、プロジェクトの初期段階における見積もりの誤差は非常に大きいことが知られています。この誤差を最小限に抑えるためには、超上流工程での十分な検討が必要不可欠です。

超上流工程が不十分な状態で大規模開発プロジェクトを進めた場合、見積もりの誤差が大きくなり、プロジェクトが頓挫する可能性があります。これにより、ベンダーは発注元企業から損害賠償を求められるなど、最悪の場合は訴訟リスクを抱えることになります。

このような状況を避けるために、以下のような対策を講じることが重要です。

大規模開発プロジェクトでは超上流工程を徹底的に行う
- システム分析、ソリューション案の検討、実現可能性の評価、主要機能選定など、プロジェクトの方向性を決定するための活動を十分に行う
- 超上流工程の成果物に基づいて、より正確な見積もりを行う

まとめ

本記事では、受託開発における見積もりのアンチパターンを5つ取り上げ、それぞれの事例と対策について解説しました。受託開発プロジェクトを成功に導くには、ベンダーと発注元企業が協力して、適切な見積もりを行うことが不可欠です。本記事で紹介したアンチパターンを参考に、自社のプロジェクトを見直し、より良い見積もりのプラクティスを実践していただければ幸いです。

受託開発の見積もりは、プロジェクトの成否を左右する重要な要素です。ベンダーと発注元企業が、本記事で紹介したアンチパターンを避け、適切な見積もりを行うことで、プロジェクトの成功確率を高めることができるでしょう。