システム開発の契約は、固定価格の請負と準委任（タイム・アンド・マテリアル）のどちらを選ぶべきでしょうか。固定価格は予算が確定する安心感がありますが、リスク分の費用が上乗せされたり、仕様変更をめぐるトラブルにつながったりします。準委任（実働に応じた支払い）は柔軟に対応できますが、発注者側の主体的な管理が欠かせません。どちらが適しているかは、「何を作りたいか」が現時点でどれほど明確かによって決まります。

この記事では、システム開発の見積もりが不確実になる理由、各支払いモデルの仕組み、チェコ民法における扱い、そして見積書の読み方を解説します。なお、本記事は一般的な原則を説明するものであり、法的助言に代わるものではありません。

システム開発の見積もりが不確実な理由

システム開発の見積もりが不確実なのは、オーダーメイドのアプリケーションが、家具職人が完成済みの図面から10台目の同じキッチンを作るようには作れないからです。毎回異なる業務フローを扱い、異なる外部システムと連携します。

最も費用を左右するのは、現時点では誰も把握していない細部です。注文の一部返品はどう処理するのか。発送後に顧客が住所を変更したらどうなるのか。既存の会計ソフトはデータを自動で取り込めるのか。こうした疑問が一つあるだけで、工数が1日、あるいは1週間増えることがあります。答えがない状態での見積もりは、単なる当て推量にすぎません。

これは古い家のリノベーションに似ています。壁の裏がどうなっているかは、漆喰を剥がして初めて分かります。そのため、誠実な現場監督や開発会社は、金額の幅と、最初に調査すべき項目について説明します。

さらに人間には、自分の計画にかかる時間や費用を過小評価する傾向があります。心理学者のDaniel KahnemanとAmos Tverskyは1979年、この現象を「計画の誤謬（planning fallacy）」と名付けました。開発会社も発注者も、この罠に陥ります。

不確実性のコーン：意思決定で見積もり精度が上がる

「不確実性のコーン（cone of uncertainty）」は、プロジェクトの各段階で見積もりに生じ得る誤差を示したものです。アイデア段階では、実際の工数が見積もりの4倍になることもあれば4分の1になることもあり、最大で16倍もの開きが生じます（Construx, Steve McConnell）。

Steve McConnellによれば、製品に「させること・させないこと」や画面構成を決断すれば、プロジェクト期間の最初の20〜30％のうちにコーンの幅は大きく縮まります。開発会社が机上で考えるだけでは見積もりは正確になりません。発注者と開発会社が共同で意思決定を重ねることで初めて精度が上がります。アイデア段階での固定価格は2倍〜4倍の誤差を伴う賭けであり、プロジェクトを管理しなければ不確実性は一切下がりません。

現在コーンのどの位置にいるかは、次の5つの質問で分かります。

• アプリに「やらせないこと」が決まっていますか？
• 機能に優先順位がついていますか？
• 主要な業務フローの例外処理が整理されていますか？
• 主要な画面の設計案がありますか？
• どの外部システムと、どのように連携するか分かっていますか？

「いいえ」が多いほど、見積もりの幅は広くなります。そのため私たちは、これらの疑問を解消する初期分析を別契約（有償）で実施することをお勧めしています。私たちの開発手法は4つのフェーズ（調査、設計、開発、公開）で構成されており、最も費用のかかる開発作業に入る前に、最初の2フェーズで不確実性を減らします。

大規模プロジェクトに潜むブラックスワン

Bent FlyvbjergとAlexander Budzierが1,471件のITプロジェクトを分析した調査では、平均27％の予算超過が確認されました。さらに6件に1件はいわゆる「ブラックスワン」、つまり影響の大きい想定外の事態が発生し、予算が平均200％超過、期間も約70％延びていました（Flyvbjerg a Budzier, Harvard Business Review, 2011年9月）。ソフトウェア開発では、古いシステムとの複雑な連携、法改正、あるいは社内の重要な業務フローが想定と異なっていたことの発覚などがこれに当たります。

対策は次の通りです。

• プロジェクトを小さなフェーズに分割します。各フェーズの終了時に動作する成果物が手元に残るため、継続、方針転換、あるいは早期撤退を判断できます。
• 不確実性に見合った予備費を確保して計画します。使わなければ手元に残ります。
• 最もリスクの高い部分（会計システムや在庫管理システムとの連携など）を最初のフェーズで検証します。問題があっても、数か月後ではなく数日で気づけます。

固定価格（請負）：安心の代償

固定価格の請負とは、実際の工数が想定を超えても、合意した範囲の成果物を開発会社が定額で納品する方式です。リスクは開発会社が負うため、価格にはリスクプレミアム（予備の上乗せ費用）が含まれます。プロジェクトが順調に進んだ場合でも、発注者はこの上乗せ分を支払うことになります。

チェコ市場の例を見ると、請負契約（smlouva o dílo）における固定価格はチェコ民法（法律第89/2012号）で保護されています。第2620条により、想定と異なる労力や費用がかかったという理由だけでは、いずれの当事者も価格変更を請求できません（裁判所が判断する極めて例外的な状況を除きます）。一方、拘束力のない概算見積もりの場合、第2622条に基づき開発会社は増額を求められるものの、遅滞なく通知する義務があります。概算を10％超上回る増額を求められた場合、発注者は契約を解除できます（法律第89/2012号、2026年1月1日時点の条文）。

固定価格で注意すべき点：

• 仕様変更の追加費用。 合意した範囲を超える作業はすべて別料金になります。要件が曖昧だとトラブルに発展します。
• 品質へのしわ寄せ。 予算が逼迫すると、開発会社はテスト、ドキュメント、コードの丁寧さを削りがちになります。
• 柔軟性の低さ。 仕様を少し変えるたびに再交渉が必要になります。

これらのリスクを抑える方法：

• 明確な検収基準。 各機能について、何をもって完成とするかを明文化します。
• 変更用の予備予算。 開発中に見えてくる追加要望に備え、予算の一部を取り分けておきます。
• 変更管理ルールの合意。 作業に着手する前に、誰が変更を提案・見積もり・承認するかを契約書で定めます。
• フェーズの細分化。 プロジェクト全体よりも数週間単位の短い区切りの方が、開発会社は少ない上乗せで正確に見積もれます。

固定価格は、完成済みのデザインに基づくコーポレートサイト、仕様が明確な2システム間の連携、初期分析の後に続く開発フェーズなど、小規模で範囲が明確に定義された案件に向いています。

準委任（タイム・アンド・マテリアル）：管理を前提とした柔軟性

タイム・アンド・マテリアル（T&M、日本では準委任契約などの実費精算型に相当）では、実際に行われた作業に対して支払います。計算式は「稼働時間または人日（MD、通常は1人あたり8時間の作業）×単価＋必要なライセンス費用」です。リスクの上乗せ費用を払わなくて済む反面、工数増加のリスクは発注者が負います。

最大の利点は柔軟性です。毎週優先順位を見直すことができ、実際に作業した分だけを支払います。作りながら形を探るプロダクトや、長期的な機能改善に適しています。

この方式が機能するには、次の3つの条件が不可欠です。

• 主体的な発注者： 意思決定のための時間と権限を持つ担当者がいること。
• 定期的な優先順位付け： 理想的には毎週、完成した成果物を見て次の優先順位を決めること。
• 透明性の高い稼働報告： 項目ごとに日付、担当者、作業内容、時間、および週次の予算消化状況が分かること。

なお、チェコ民法の請負契約（smlouva o dílo）では固定額の合意は必須ではなく、第2586条により価格の算出方法や見積もりを定めるだけでも成立します。ソフトウェア開発の契約では、単価、稼働報告の方法、作業の承認手順を明確に記載し、適切な契約形態については弁護士にご相談ください。

有効な安全策は、フェーズごとまたは月ごとの「上限予算（キャップ）」を設定することです。上限に近づいた段階で開発会社から通知を受け、予算内に収まるよう作業範囲を調整できます。

人日単価や時間単価は、エンジニアの経験、技術スタック、責任範囲、契約条件によって変わります。チェコのコミュニケーションエージェンシー協会（AKA）が2026年4月に実施した調査によると、エージェンシー所属プログラマーの時間単価は2,042.52チェココルナです（AKA, 2026）。ソフトウェア開発会社やフリーランスでは単価体系が異なるため、単価に何が含まれているかも必ず確認してください。

ハイブリッド型と「期間固定・スコープ可変」

完全な固定価格と準委任（T&M）の間には、いくつかの組み合わせがあります。

有償分析＋フェーズ別固定価格は最も安全な方法です。まず初期分析を有償で行い、完成した要件定義をもとに各フェーズを固定価格で発注します。フェーズが終わるごとに、次に何を進めるかを判断できます。

月額ラボ型（稼働枠確保）は、毎月一定の人日数を確保し、発注者の優先順位に従ってチームが開発を進める方式です。公開後の継続的な改善に向いています。

受注管理アプリを作りたい架空の家具工房を例に、組み合わせ方を見てみましょう。

1. 有償の初期分析を実施する（業務フローの整理、優先順位付け、画面設計）。
2. 第1フェーズ（受注管理とカレンダー機能）を固定価格で発注する。
3. 会計ソフトの連携仕様がまだ不明なため、会計・在庫連携は上限付きの準委任（T&M）で進める。
4. 公開後は月額の稼働枠確保に切り替える。

期間固定・スコープ可変は、Basecamp社の開発手法「Shape Up」で提唱されている考え方です。まず「アペタイト（appetite）」、つまりその機能にどれだけの期間をかけたいかを決めます。通常の見積もりは「設計から始まり数字（工数）で終わる」のに対し、アペタイトは「数字（期間）から始まり設計で終わる」のが特徴です（Basecamp, Shape Up）。Basecamp社は6週間サイクル（小規模な課題は1〜2週間）で開発を進めます。期間に合わせてスコープを調整するため、予算は固定されたまま維持できます。

開発の見積書・提案書の読み方

優れた提案書は、不確実性があることを正直に認めたうえで、どう対処するかを示しています。前提条件の記載がないまま「ぴったり1つの金額」だけが書かれている場合、多額のリスクプレミアムが隠れているか、後から仕様変更として追加請求が発生します。

注意すべき危険信号：

• 見積金額の根拠となる前提条件が書かれていない
• テスト、引き継ぎ、操作研修が含まれていない
• 「仕様変更は無制限で料金内」とうたっている（隠れた上乗せや将来のトラブルを意味します）
• ソフトウェア開発の契約書に中途解約時の取り決めがない
• ソースコードや管理権限が開発会社側だけに残る

押さえておきたい4つの用語：

• 人日（MD）： 1人が1日に働く作業量（通常8時間）で、人日単価の基準になります。
• 変更要求（change request）： 合意範囲外の追加作業で、個別に見積もりと承認を行います。
• バックログ（backlog）： 優先順位順に並べた作業リストです。
• 初期分析（discovery）： 要件定義、画面設計、精度の高い見積もりを作るための有償の準備工程です。

ソースコードの権利帰属は、将来別の開発会社へ乗り換えられるかどうかを左右します。関連するテーマは、以下の記事でも詳しく解説しています。

• コードの権利帰属：Webサイトの所有権は誰にあるのか
• 総費用と運用コスト：アプリ開発の費用はいくらかかるのか
• オーダーメイド開発が向くケース：オーダーメイド開発か既製システムか
• 開発の具体的な流れ：Webアプリ・モバイルアプリ開発の進め方

私たちはオーダーメイドのWebアプリケーションを23万チェココルナ〜で構築しています。開発範囲や費用の目安を把握したい方は、質問に答えるだけで要件定義のたたき台と3つのプランを作成するプロジェクト・コンフィギュレーターをお試しください。

よくある質問