見積もりはなぜいつも外れるのか
業務システムの開発を依頼して、「6ヶ月で完成します」と言われたのに1年かかった。あるいは「3ヶ月でできます」と聞いて発注したら、途中で要件が膨らんで予算も期間も2倍になった——こういう経験をしている会社は少なくない。
なぜシステム開発の期間見積もりはよく外れるのか。その理由を理解すると、発注側として何を準備すればいいかが見えてくる。
最も大きな理由は、見積もりの時点では「何を作るか」が確定していないからだ。発注者が伝えた要件は、業務の実態を言語化したものだが、完全ではない。ヒアリングでは聞けなかったことがある。言わなくても分かると思っていたことがある。使い始めて初めて気づくことがある。これらが開発途中で出てきて、スコープが変わる。スコープが変わると期間も変わる。
もう一つの理由は、発注者側の意思決定速度が見積もりに含まれていないことだ。仕様の確認や画面のOKを出すまでに時間がかかると、開発の手が止まる。承認フローが複雑な組織では、この待ち時間が積み上がって全体の期間が伸びる。これは開発会社の問題ではなく、発注者側の状況によって変わる変数だ。
規模別の期間内訳と、なぜその期間がかかるか
業務システムの構築期間は、規模によって大きく異なる。小・中・大の3つの規模に分けて、それぞれの期間の目安と内訳を整理する。
小規模（開発費100〜300万円程度、画面数10〜20程度）の場合、合計で2〜3ヶ月が目安だ。ヒアリング・要件整理に2〜3週間、設計・プロトタイプに1〜2週間、開発に3〜5週間、テスト・修正に1〜2週間、導入・引き渡しに1週間というイメージになる。
この規模で期間が短くなる理由は、関係する機能が少なく、複雑なデータ連携がないことが多いからだ。発注者と開発担当者が直接話しながら進めやすく、確認サイクルが短い。判断が速い発注者との案件では、2ヶ月を切ることもある。特定業務の一部をシステム化する「スポット型」の開発がこの規模に当たる。
中規模（開発費500〜1500万円程度、画面数30〜50程度）の場合、合計で4〜6ヶ月が目安になる。ヒアリング・要件整理に3〜5週間、設計・プロトタイプに3〜4週間、開発に8〜12週間、テスト・修正に3〜4週間、導入・引き渡しに1〜2週間という内訳だ。
この規模になると、複数の部署が関わる業務フローが対象になることが多い。それぞれの部署の要件を整理して整合性を取る作業が増える。また、既存の会計ソフトや外部サービスとのデータ連携が発生することもあり、その仕様確認と接続テストに時間がかかる。関係者が増えるほど、意思決定のサイクルも長くなりやすい。
大規模（開発費2000万円以上、画面数60以上）の場合、合計で8〜12ヶ月以上かかることが多い。要件整理だけで2〜3ヶ月かかることがある。設計フェーズも複数のチームが関わり、整合性確認に時間が必要になる。開発・テストのサイクルも長くなる。
大規模案件では、途中でプロジェクト全体を把握している人間が減ることがある。担当者の交代、チームの分業、外部への一部委託——これらが重なると、情報の伝達ロスが生まれ、後工程での手戻りにつながる。それが期間を押し上げる主な原因の一つだ。
期間を短くできる条件
同じ機能量でも、期間が大きく短くなる条件がある。
一つは、スコープが最初から絞られていることだ。「全部一度に作らなくていい。まず月次レポートの自動化だけを先に動かしたい」という発注者との案件は、同じ予算でも期間が短い。絞ることは諦めではなく、早期に成果を出しながらリスクを下げる方法だ。コア機能から始めて、使いながら機能を追加するフェーズ分割型の開発は、全体の期間を短くしながらリスクも下げる。
もう一つは、発注者側の意思決定者が商談から導入まで一貫して関与していることだ。担当者が権限を持って判断できる場合、確認待ちの時間がなくなる。逆に、担当者が「上に持ち帰って確認します」を毎回繰り返す場合、開発の手が止まる待ち時間が積み上がる。発注者側の決裁スピードは、開発期間に直接影響する変数だ。
要件定義の精度も大きく影響する。最初のヒアリングで「何を作るか」が明確になっていると、後から仕様変更が出にくい。ヒアリングに十分な時間をかけることは、後工程の短縮につながる。
期間が長引く原因
予定より期間が長くなる案件には、共通するパターンがある。
要件確定の遅延は最も多い原因の一つだ。開発が進んだ後で「やっぱりこの機能も欲しい」「この画面の使い方を変えたい」という変更が入ると、それまでの工数が無駄になり、全体スケジュールが後ろにずれる。変更そのものは避けられないが、発生するタイミングが遅いほど影響が大きい。
既存システムとの連携も期間に影響する。他のシステムとデータをやり取りする場合、相手側のAPI仕様の確認、テスト環境の準備、接続テストと不具合修正のサイクルが必要になる。相手側のベンダーの対応速度に依存する部分があり、ここは開発会社だけではコントロールできない。
データ移行も見落とされやすい作業だ。既存の台帳やExcelのデータを新システムに移す場合、データの整備、フォーマットの変換、移行後の検証が必要だ。データの質が低い（欠損、表記ゆれ、重複）ほど、この作業に時間がかかる。プロジェクト初期にデータの状態を確認しておくことが、後工程の見通しを立てるために重要だ。
検収・本番稼働後の安定期まで含めた「プロジェクト全体の期間」の考え方
開発会社が提示する期間は、多くの場合「本番リリースまで」の期間だ。でも、プロジェクトとして考えるなら、本番稼働後の安定期まで含めた期間を把握しておく必要がある。
本番稼働直後は、現場での使い方の問題や想定していなかった操作パターンによる不具合が出やすい時期だ。この「初期安定化フェーズ」に1〜2ヶ月かかることが多い。開発が終わっても、プロジェクトとしてはまだ続いている。この期間に開発会社が素早く対応できる体制を持っているかは、発注前に確認しておくべき点だ。
その後、現場からの改善要望が上がってくる「改善フェーズ」がある。使い始めて分かった「ここはこうした方がいい」という修正は、稼働後に必ず出てくる。これを小さなコストで素早く対応できるか、それとも都度大きな見積もりが必要かによって、システムが現場に定着するかどうかが変わる。
発注者として「プロジェクト期間」を考える時は、「納品まで」ではなく「現場に定着して安定稼働するまで」を見ておく方がいい。一般的に、本番稼働から3〜6ヶ月でそのフェーズに達する。つまり、受注から計算すると小規模で5〜9ヶ月、中規模で7〜12ヶ月、大規模で12〜18ヶ月以上がプロジェクト全体の期間の目安になる。
期間の見積もりは、開発会社の力量だけで決まるものではない。発注者側の準備と関与の質が、大きく影響する。自社としてどの速度で意思決定できるか、どこまで要件を絞れるか、データ移行にどれくらいの工数を出せるか——これらが期間を左右する変数だ。「開発会社に任せた」ではなく、発注者自身がプロジェクトに主体的に関与することが、期間通りに完成させるための最も確実な方法だ。