[速習] システム開発契約 第3回 見積もり作成と契約書作成の実践手法

シリーズ第3回では、実際の契約締結プロセスにおける実践的な知識を提供します。これまでの2回で学んだ契約形態の特徴と開発手法との適合性を踏まえ、実際に契約を締結する際の具体的な手順について解説します。

本記事では特に、詳細な見積もり作成方法と、トラブルを未然に防ぐ契約書作成の実務に焦点を当てます。これらの知識は、プロジェクトの成功確率を大きく左右する重要な要素です。

見積もり作成の実践的手法

なぜ段階的見積もりアプローチが必要か

SES契約¹に慣れた開発者が陥りやすい最大の落とし穴は、提案段階でいきなりWBS（作業分解構造）による詳細見積もりを作成してしまうことです。これは以下のような深刻な問題を引き起こします。

実際の失敗例：

【あるECサイト開発プロジェクトの失敗】
提案段階でのWBS見積もり：
- 商品検索機能：10人日（画面作成5人日、API実装5人日）

実際に発生した作業：
- 全文検索エンジンの選定・導入：15人日
- 検索インデックスの設計・最適化：20人日
- ファセット検索の実装：15人日
- パフォーマンスチューニング：10人日
- 既存データの移行・インデックス作成：10人日
実際の工数：70人日（当初見積もりの7倍）

この失敗例では、ファセット検索²のような複雑な機能の実装工数を見誤っています。このような事態を防ぐため、プロジェクトフェーズに応じて適切な見積もり手法を選択し、段階的に精度を上げていくアプローチが不可欠です。

フェーズ別見積もり手法の実践

1. 企画・提案段階：NESMA指標的見積もり（精度±50%）

提案段階では、詳細な機能要件は不明です。この段階でWBSを作成しても、それは「当てずっぽう」に過ぎません。代わりに、データモデルの概要から機械的に算出できるNESMA指標的見積もり³を使用します。

ECサイトの詳細なエンティティ分析：

【ECサイトの主要エンティティ（ILF）】

1. 顧客関連（3エンティティ）
   - 顧客マスタ（Customer）
   - 配送先住所（ShippingAddress）
   - お気に入り（Favorite）

2. 商品関連（4エンティティ）
   - 商品マスタ（Product）
   - カテゴリ（Category）
   - 在庫（Stock）
   - 商品レビュー（Review）

3. 注文関連（4エンティティ）
   - 注文（Order）
   - 注文明細（OrderDetail）
   - カート（Cart）
   - 支払履歴（Payment）

4. マーケティング関連（2エンティティ）
   - クーポン（Coupon）
   - メールマガジン購読（Subscription）

ILF合計：13エンティティ

【外部インターフェース（EIF）】
1. 決済代行会社の取引情報
2. 配送会社の配送状況
3. 仕入先の在庫情報API

EIF合計：3エンティティ

計算結果：
FP = 35 × 13 + 15 × 3 = 455 + 45 = 500FP
概算工数 = 500FP ÷ 10FP/人月 = 50人月（±50%）
→ 25〜75人月のレンジ

この段階では「最低でも25人月、最大75人月」という幅のある見積もりを提示し、詳細は要件定義で精査することを明確にします。

2. 要件定義段階：NESMA概算見積もり（精度±25%）

要件定義が進み、主要な機能が見えてきた段階で、NESMA概算見積もりに切り替えます。この段階では機能の複雑度は平均値を使いますが、機能の数は正確にカウントできます。ここで使用する機能タイプ別の標準値⁴は、多くのプロジェクト実績から導き出された平均的な複雑度です。

【要件定義完了時の見積もり更新】

機能タイプ別の標準値を使用：
- ILF：平均複雑度として10FPで計算
- EIF：平均複雑度として7FPで計算  
- EI/EO/EQ：平均複雑度として4.5FPで計算

識別された機能数：
- ILF：18個 × 10FP = 180FP（詳細分析で5個追加）
- EIF：4個 × 7FP = 28FP（外部API連携が1個追加）
- トランザクション機能：35個 × 4.5FP = 157.5FP
  - EI（外部入力）：15個
  - EO（外部出力）：12個
  - EQ（外部照会）：8個

合計：365.5FP
想定工数：36.6人月（±25%）
→ 27.4〜45.7人月のレンジ

3. 基本設計段階：標準FP法（精度±10%）

基本設計で各機能の詳細が明確になった段階で、標準的なファンクションポイント法⁵を適用します。ここで初めて機能の複雑度を個別に評価します。最終的には調整係数⁶を適用し、組織の生産性実績値⁷で工数を算出します。

【基本設計完了時の詳細FP計算】

1. 外部入力（EI）詳細：
   - 会員登録（複雑度:高,DET15個,FTR3個）：6FP
   - ログイン（複雑度:低,DET3個,FTR1個）：3FP
   - 商品登録（複雑度:高,DET20個,FTR5個）：6FP
   - カート追加（複雑度:中,DET8個,FTR2個）：4FP
   （他11機能）
   小計：68FP

2. 外部出力（EO）詳細：
   - 注文確認書PDF（複雑度:高）：7FP
   - 売上分析レポート（複雑度:高）：7FP
   - 在庫アラート（複雑度:中）：5FP
   （他9機能）
   小計：71FP

3. 外部照会（EQ）詳細：
   - 商品検索（複雑度:高）：6FP
   - 注文履歴（複雑度:中）：4FP
   （他6機能）
   小計：38FP

4. 内部論理ファイル（ILF）詳細：
   - 顧客マスタ（複雑度:中,RET2個,DET25個）：10FP
   - 商品マスタ（複雑度:高,RET4個,DET45個）：15FP
   - 注文データ（複雑度:高,RET3個,DET35個）：15FP
   （他15ファイル）
   小計：198FP

5. 外部インターフェース（EIF）詳細：
   - 決済API（複雑度:中）：7FP
   - 配送API（複雑度:中）：7FP
   （他2インターフェース）
   小計：24FP

未調整FP合計：399FP

調整係数（14の特性評価）：0.98
調整済みFP：399FP × 0.98 = 391FP

生産性実績値：11FP/人月
見積もり工数：35.5人月（±10%）
→ 32.0〜39.1人月のレンジ

4. 詳細設計段階：WBS積算（精度±5%）

詳細設計が完了し、実装方法が確定した段階で、初めてWBS⁸による積み上げ見積もりを行います。この段階では、具体的な作業内容が明確なため、高精度な見積もりが可能です。

【詳細設計後のWBS見積もり（一部抜粋）】

1. 商品検索機能（合計：52人日）
   1.1 Elasticsearch環境構築
       - Docker環境セットアップ：2人日
       - クラスタ設計・構築：3人日
       - 日本語アナライザー設定：2人日
   1.2 検索インデックス設計
       - 商品データスキーマ設計：3人日
       - 同義語辞書作成：2人日
   1.3 検索API実装
       - 基本検索API：5人日
       - ファセット検索API：8人日
       - サジェスト機能：5人日
       - ソート・フィルタ機能：4人日
   1.4 検索UI実装
       - 検索画面コンポーネント：5人日
       - 検索結果表示：3人日
   1.5 テスト
       - 単体テスト：5人日
       - 性能テスト：3人日
       - 統合テスト：2人日

（全機能のWBS積算結果）
総工数：710人日 = 35.5人月（±5%）
→ 33.7〜37.3人月のレンジ

段階的見積もりの実践例

実際のプロジェクトでどのように見積もりが精緻化されていくか、まとめて見てみましょう。

このように、情報の詳細度に応じて適切な手法を使い分けることで、段階的に見積もり精度を向上させることができます。

工程毎の個別契約による段階的リスク管理

なぜ全工程一括契約は危険なのか

見積もり精度が段階的に向上することを踏まえると、プロジェクト全体を一括で契約することは、発注側・受注側双方にとって大きなリスクとなります。そこで実践的なアプローチとして、工程毎に個別契約を結ぶ手法が推奨されます。

工程毎契約の実践例

【ECサイト開発プロジェクトの契約構成】

第1契約：企画・要件定義フェーズ（準委任契約）
- 期間：3ヶ月
- 金額：1,515万円（5名体制）
- 成果物：要件定義書、概算見積書（±25%精度）
- 次フェーズ移行条件：要件定義書の合意

第2契約：基本設計フェーズ（準委任契約）
- 期間：2ヶ月  
- 金額：1,010万円（5名体制）
- 成果物：基本設計書、詳細見積書（±10%精度）
- 次フェーズ移行条件：技術的実現性の確認

第3契約：詳細設計・開発・単体テストフェーズ（請負契約）
- 期間：6ヶ月
- 金額：4,260万円（確定金額）
- 成果物：ソースコード、詳細設計書、テスト結果
- 検収条件：単体テスト完了

第4契約：結合テスト・受入テストフェーズ（準委任契約）
- 期間：1.5ヶ月
- 金額：757.5万円（5名体制）
- 成果物：統合テスト結果、本番移行準備

追加工程が必要になる典型的なパターン

プロジェクトの進行に伴い、当初想定していなかった追加工程が必要になることがあります。これらは個別契約として追加することで、柔軟に対応できます。

【よくある追加工程と発生タイミング】

1. パフォーマンス最適化工程
   発生タイミング：負荷テストで想定性能を満たさなかった場合
   典型的な内容：
   - データベースのインデックス最適化
   - クエリチューニング
   - キャッシュ戦略の見直し
   - インフラ構成の最適化
   契約形態：準委任契約（1-2ヶ月）

2. セキュリティ強化工程
   発生タイミング：脆弱性診断で重大な問題が発見された場合
   典型的な内容：
   - 認証・認可機能の再設計
   - 暗号化処理の実装
   - セキュリティパッチの適用
   - WAF導入・設定
   契約形態：請負契約（診断結果に基づく）

3. ユーザビリティ改善工程
   発生タイミング：ユーザーテストで大きな問題が発覚した場合
   典型的な内容：
   - UI/UXの再設計
   - 画面遷移の見直し
   - レスポンシブ対応の追加
   契約形態：準委任契約（1-3ヶ月）

4. データ移行最適化工程
   発生タイミング：移行リハーサルで想定時間を大幅に超過した場合
   典型的な内容：
   - 移行ツールの開発・最適化
   - 並列処理の実装
   - データクレンジング処理の追加
   契約形態：請負契約（移行完了を条件）

5. 運用自動化工程
   発生タイミング：運用設計で手動作業が多いことが判明した場合
   典型的な内容：
   - CI/CDパイプラインの構築
   - 監視・アラート設定
   - 自動バックアップ・リストア
   契約形態：準委任契約（1-2ヶ月）

追加工程に対する契約上の配慮

【マスター契約での追加工程条項例】

第8条（追加工程の取り扱い）
1. 各工程の完了時点で、品質基準を満たすために追加工程が必要と
   判断された場合、甲乙協議の上、個別契約を追加締結できる。

2. 追加工程の必要性は、以下の客観的指標により判断する：
   - 性能要件：負荷テストの結果が要件の80%未満
   - セキュリティ要件：脆弱性診断で危険度「高」以上の指摘
   - ユーザビリティ：ユーザーテストでタスク完了率70%未満

3. 追加工程の費用負担は、その原因により以下の通りとする：
   - 要件の不備・変更に起因：甲の負担
   - 設計・実装の不備に起因：乙の負担  
   - 外部要因（法規制変更等）に起因：甲乙協議

4. 追加工程により当初スケジュールに影響が出る場合、
   後続工程の契約条件を見直すものとする。

このように、工程毎の個別契約と追加工程への対応を組み込むことで、プロジェクトのリスクを適切に管理しながら、必要に応じて品質向上のための投資を行うことが可能になります。

リスク分析に基づく予備費の算出

どの見積もり手法を使う場合でも、リスク分析は不可欠です。リスクマトリクス⁹を使用して、プロジェクト固有のリスクを評価します。

準委任契約における柔軟な見積もり

準委任契約¹⁰の見積もりは、請負契約とは根本的に異なるアプローチが必要です。成果物ではなく、提供する専門性と稼働時間に基づいて価格を設定するため、チーム構成と単価設定が重要になります。

【アジャイル開発チーム（5名体制）の月額見積もり】

役割別の構成と単価：
1. テックリード（1名）
   - 必要スキル：アーキテクチャ設計、技術選定、コードレビュー
   - 月額単価：140万円（税別）
   
2. シニアエンジニア（1名）
   - 必要スキル：フルスタック開発、メンタリング
   - 月額単価：120万円（税別）
   
3. エンジニア（2名）
   - 必要スキル：担当領域の実装、テスト
   - 月額単価：100万円（税別） × 2 = 200万円（税別）
   
4. UI/UXデザイナー（0.5名）
   - 必要スキル：ユーザー体験設計、デザインシステム構築
   - 月額単価：90万円（税別） × 0.5 = 45万円（税別）

月額合計：505万円（税別）
3ヶ月契約：1,515万円（税別）

重要： 見積もり精度が低い企画・要件定義段階は準委任契約で実施し、基本設計以降で精度が上がってから請負契約を検討するアプローチが、リスク管理の観点から推奨されます。

契約書作成の実務

契約書に必ず含めるべき重要条項

契約書は単なる形式的な文書ではなく、プロジェクトで発生する可能性のあるあらゆる事態に対する取り決めです。特にソフトウェア開発では、一般的な契約書のテンプレートでは不十分で、IT特有の条項を追加する必要があります。

まず、最も重要な「業務範囲」の定義から見ていきましょう。曖昧な表現は後々のトラブルの元となるため、可能な限り具体的に記載します。特に非機能要件¹¹については、性能・可用性・セキュリティなどの品質特性を数値で明確に定義することが重要です。

【業務範囲の記載例（請負契約）】

第3条（業務内容）
1. 乙は、甲の販売管理システム（以下「本システム」という）の開発業務を行う。
2. 本システムの機能要件は、別紙「機能要件定義書」に定める通りとする。
3. 本システムの非機能要件は、以下の通りとする：
   - 同時接続ユーザー数：最大1,000名
   - レスポンスタイム：画面表示3秒以内（通常時）
   - 稼働率：99.5%以上（計画停止を除く）
4. 以下の業務は本契約の範囲外とする：
   - 既存システムからのデータ移行作業
   - 本番環境のインフラ構築
   - ユーザー教育・マニュアル作成

このように、何を作るかだけでなく、何を作らないかも明確にすることが重要です。特に「データ移行」や「インフラ構築」など、見落としがちな作業については、契約範囲に含まれるかどうかを明確にしておく必要があります。

次に、検収条件の定義も極めて重要です。検収基準には重大な不具合¹²の定義を明確に含める必要があります。

第10条（検収）
1. 乙は、本システムの開発完了後、以下の成果物を甲に納品する：
   - ソースコード一式（Gitリポジトリでの提供）
   - システム設計書（基本設計書、詳細設計書）
   - テスト仕様書およびテスト結果エビデンス
   - デプロイメント手順書
   
2. 甲は、納品後10営業日以内に、別紙「受入テスト仕様書」に基づき検収を行う。

3. 検収基準は以下の通りとする：
   - 全ての必須機能が要件通り動作すること
   - 重大な不具合が存在しないこと
   - 受入テストの合格率が95%以上であること

4. 甲が正当な理由なく検収を遅延した場合、納品後20営業日を経過した時点で
   検収に合格したものとみなす。

変更管理プロセスの明文化

ソフトウェア開発において、要件変更は避けられません。重要なのは、変更を禁止することではなく、適切に管理することです。契約書には、変更管理プロセス¹³を明確に定義しておく必要があります。

第15条（仕様変更）
1. 甲は、やむを得ない事情により仕様変更が必要な場合、
   書面により乙に申し出ることができる。

2. 乙は、変更要求を受けた場合、5営業日以内に以下を提示する：
   - 技術的な実現可能性の評価
   - 追加工数の見積もり
   - 納期への影響分析
   - 追加費用の見積もり

3. 変更に伴う追加費用の算定基準は以下の通りとする：
   - 設計済み機能の変更：当該機能の開発工数の150%
   - 実装済み機能の変更：当該機能の開発工数の200%
   - 新規機能の追加：通常の見積もり基準を適用

4. 軽微な変更の定義：
   - 画面レイアウトの微調整（機能に影響しない範囲）
   - 文言の修正
   - 色やフォントの変更
   これらは月5時間を上限として追加費用なしで対応する。

5. 重大な変更（アーキテクチャの変更、基本機能の大幅な見直し等）が
   必要となった場合は、本契約を一旦終了し、新たな契約を締結する。

このように、変更の規模に応じた対応方法と費用を事前に定めておくことで、変更要求が発生した際にスムーズに対応できます。

知的財産権の取り扱い

ソフトウェア開発における知的財産権¹⁴の取り扱いは、しばしばトラブルの原因となります。特に、著作権の帰属と、開発者が持つ既存の知的財産（バックグラウンドIP）¹⁵の取り扱いについて、明確に定める必要があります。また、オープンソースソフトウェア¹⁶のライセンス条件についても注意が必要です。

第20条（知的財産権）
1. 本契約に基づき新規に開発された成果物の著作権は、
   甲による対価の完済をもって甲に移転する。

2. ただし、以下については乙または第三者に権利が留保される：
   - 乙が従前から保有していた知的財産権
   - 汎用的なライブラリ、フレームワーク、ツール
   - オープンソースソフトウェア

3. 乙は、甲に対し、前項の権利について、本システムの利用、
   改変、保守に必要な範囲で、永続的かつ非独占的な使用権を許諾する。

4. 乙は、本開発で得たノウハウを、甲の営業秘密に該当しない範囲で、
   他の案件に活用することができる。

5. 甲は、本システムに含まれるオープンソースソフトウェアの
   ライセンス条件を遵守するものとする。

責任制限と保証

IT契約では、開発側の責任を無制限にすると、ビジネスリスクが過大となります。そのため、適切な責任制限条項を設けることが一般的です。特に逸失利益¹⁷などの間接損害については、明確に免責することが重要です。

第25条（損害賠償）
1. 乙の責めに帰すべき事由により甲に損害が生じた場合、
   乙は甲に対して損害賠償責任を負う。

2. 前項の損害賠償額は、債務不履行、不法行為その他請求原因の如何を問わず、
   本契約の契約金額を上限とする。

3. いかなる場合も、乙は甲の逸失利益、間接損害、特別損害、
   派生的損害について責任を負わない。

第26条（瑕疵担保責任）
1. 乙は、検収完了後1年間、本システムの瑕疵について無償で修正する責任を負う。

2. ただし、以下の場合は瑕疵担保責任を負わない：
   - 甲または第三者による改変に起因する不具合
   - 甲の使用環境の変更に起因する不具合
   - 契約時に予見できなかった技術的制約による不具合

要点まとめ：契約書作成の重要ポイント

• 業務範囲は含むもの・含まないものを明確に記載
• 検収条件と検収基準を具体的に定義
• 変更管理プロセスと費用算定基準を明文化
• 知的財産権の帰属と利用許諾を明確化
• 適切な責任制限条項で過大なリスクを回避

まとめ

本記事では、ソフトウェア開発契約における見積もり作成と契約書作成の実践的な手法について詳しく解説しました。

見積もり作成においては、SES契約に慣れた開発者が陥りやすい「いきなりWBS」の危険性を指摘し、プロジェクトフェーズに応じた段階的アプローチの重要性を説明しました。企画段階でのNESMA指標的見積もり（±50%）から始め、要件定義でのNESMA概算（±25%）、基本設計でのFP法（±10%）、そして詳細設計後のWBS積算（±5%）と、段階的に精度を上げていく手法を実例とともに解説しました。

また、工程毎の個別契約によるリスク管理手法についても解説し、パフォーマンス最適化やセキュリティ強化など、プロジェクト進行中に必要となる可能性のある追加工程への対応方法も示しました。

契約書作成においては、業務範囲の明確化、検収条件の具体的な定義、変更管理プロセスの明文化、知的財産権の適切な取り扱いなど、トラブルを未然に防ぐための重要条項について解説しました。

これらの知識を活用することで、より成功確率の高いプロジェクトを実現できるでしょう。特に、見積もり精度と契約形態を連動させ、リスクを適切にコントロールすることが、プロジェクト成功の鍵となります。

1. SES（System Engineering Service）契約：技術者の労働力を提供する契約形態。成果物の完成責任を負わず、時間単価での精算が基本。指揮命令権の所在により、請負契約や派遣契約との区別が重要。 ↩

2. ファセット検索：検索結果を複数の切り口（価格帯、ブランド、カテゴリなど）で絞り込める検索機能。ECサイトでは必須機能だが、実装には検索エンジンの深い理解が必要。 ↩

3. NESMA指標的見積もり：Netherlands Software Metrics Associationが開発した簡易見積もり手法。データエンティティ数のみから機械的にFPを算出。ILF×35FP＋EIF×15FPという単純な計算式を使用。 ↩

4. 機能タイプ別標準値：NESMA概算見積もりで使用する平均的な複雑度。ILF=10FP、EIF=7FP、トランザクション機能（EI/EO/EQ）=4.5FPが一般的な値。 ↩

5. ファンクションポイント法（FP法）：IFPUG（International Function Point Users Group）が管理する国際標準の規模測定手法。ISO/IEC 20926として標準化。機能を5つの要素（EI/EO/EQ/ILF/EIF）に分類し、複雑度（DET：データ項目数、FTR：参照ファイル数、RET：レコード種別数）により重み付けして計測。 ↩

6. 調整係数：システムの技術的複雑性を反映する係数。データ通信、分散処理、性能要求など14の特性を0〜5で評価。ただし、IFPUG 4.0以降では廃止され、未調整FPの使用が推奨されている。 ↩

7. 生産性実績値：組織やプロジェクト特性により大きく異なる。日本では8〜15FP/人月が一般的。新規開発とエンハンスでも差があり、IPAのソフトウェア開発データ白書が参考になる。 ↩

8. WBS（Work Breakdown Structure）：プロジェクトの全作業を階層的に分解した構造。PMBOK（Project Management Body of Knowledge）の基本ツール。詳細設計後に作成することで、作業の抜け漏れを防ぐ。 ↩

9. リスクマトリクス：リスクの発生確率（1〜5）と影響度（1〜5）を掛け合わせてリスク値を算出。15以上は重大リスクとして対策必須。ISO 31000（リスクマネジメント規格）準拠。 ↩

10. 準委任契約：民法656条に基づく契約。法律行為以外の事務処理を委託。ソフトウェア開発では、成果物の完成責任を負わず、専門的な知識・技術の提供を目的とする。 ↩

11. 非機能要件：システムの品質特性に関する要件。性能、可用性、セキュリティ、保守性など。ISO/IEC 25010（システム品質モデル）で8つの品質特性として定義されている。 ↩

12. 重大な不具合：Severity 1またはCriticalと分類される不具合。システム停止、データ損失、セキュリティ侵害など。一般的に24時間以内の対応が求められる。 ↩

13. 変更管理プロセス：要件変更を体系的に管理する手順。変更要求（CR：Change Request）の受付、影響分析、承認、実装、検証のサイクル。PMBOK知識エリアの一つ。 ↩

14. 知的財産権：著作権、特許権、商標権、営業秘密の総称。ソフトウェアは著作権法第10条1項9号でプログラムの著作物として保護。データベースは同12号の2で保護。 ↩

15. バックグラウンドIP：受注者が従前から保有する知的財産。フォアグラウンドIP（新規開発部分）と区別。汎用ライブラリやフレームワーク、社内ツールなどが該当。 ↩

16. オープンソースソフトウェア（OSS）：GPL、MIT、Apache等のライセンスで公開されたソフトウェア。ライセンス条件により、改変物の公開義務やコピーレフト条項に注意が必要。 ↩

17. 逸失利益：契約違反により得られなかった将来の利益。予見可能性が争点となることが多い。民法416条で通常損害と特別損害が規定されており、IT契約では多くが特別損害として免責される。 ↩