大手SIerが、顧客の現場に入り込んで課題解決まで担うFDE(フォワードデプロイドエンジニア)を、人月ではなく「このユースケースをこの期間でいくら」という固定価格で提供し始めています。生成AIで設計・開発の作業量が縮む中、人月を前提にしてきたIT取引の見直しが話題になっています。
発注者にとっての論点は、流行の価格モデルを採るかどうかではありません。自社が何に対価を払っているのかを説明できるかです。本記事では、契約形態を慣習ではなく判断基準で選ぶ方法を整理します。
課題 ― 契約形態が「いつもの形」で決まっている
多くの企業で、契約形態は「要件定義は準委任、開発は請負」といった前例で決まっています。その結果、次のようなずれが起きがちです。
- 要件が固まっていないのに請負で発注し、変更のたびに追加見積もりと交渉が発生する
- 準委任で発注したのに完成を期待し、成果が出ないまま稼働時間への支払いが続く
- 見積もりの根拠が人月しかなく、生産性が上がっても価格に反映されない
三つの型は「何に対価を払うか」が違う
| 型 | 対価の対象 | ベンダーの主な責任 | 発注者の主な負担 |
|---|---|---|---|
| 準委任(履行割合型) | 稼働・業務の遂行 | 専門家として適切に遂行する | 成果を出すための方向づけと判断 |
| 請負 | 仕事の完成 | 完成と、契約内容に適合しない場合の責任 | 着手前の要件確定と変更管理 |
| 成果型(成果完成型準委任・固定価格サービス等) | 合意した成果 | 成果の達成 | 成果の定義と検収基準の合意 |
2020年施行の改正民法では、成果の引き渡しに対して報酬を払う準委任(成果完成型)が明文化されました。「準委任か請負か」の二択ではなく、対価の対象を選ぶという発想に立つと選択肢が広がります。
選び方 ― 不確実性がどこにあるかで決める
基準はシンプルで、「何を作るか」が決まっているかどうかです。
- 何を作るかが決まっている(詳細設計以降、仕様が固まった改修):請負が機能します。ベンダーが作り方の工夫で効率を上げる余地があり、発注者は完成で評価できます
- 何を作るかを探している(企画・要件定義、アジャイル開発、AIのPoC):準委任が妥当です。IPAのアジャイル開発版モデル契約も準委任を前提にしています。ただし、スプリントごとの目標と振り返りで成果を可視化する運営が前提です
- 解くべき課題は明確だが、解き方は任せたい:成果型が候補になります。成果の定義と検収基準を発注者が言語化できることが条件です
IPAの「情報システム・モデル取引・契約書」も、工程ごとに契約類型を使い分ける考え方を示しています。一つのプロジェクトを一つの契約形態で括らず、工程単位で選ぶのが定石です。
生成AIで人月の前提が揺らぐとき
人月で払う契約では、ベンダーがAIで作業を短縮すると売上が減ります。生産性向上の成果を発注者とベンダーのどちらが受け取るかが、契約上決まっていない状態です。
一方で、成果型に切り替えれば解決するわけでもありません。成果を定義できない発注者は、固定価格の妥当性を評価できず、ベンダーの言い値を受け入れるしかなくなるためです。発注者側には次の備えが必要です。
- 成果と検収基準を業務の言葉で書ける人を、IT部門か事業部門に置く
- 見積もりに、工数だけでなく成果物と前提条件の明細を求める
- 準委任でも、AI活用で浮いた工数を何に振り向けるかをベンダーと合意する
よくある失敗と回避策
| 失敗 | 回避策 |
|---|---|
| 要件未確定のまま請負で発注する | 要件定義を準委任で切り出し、確定後に請負で見積もり直す |
| 準委任で成果が見えなくなる | 期間ごとの目標と報告内容を契約で定める |
| 準委任の要員に発注者が直接指示を出す | 指示は窓口経由とし、偽装請負と見なされない体制にする |
| 成果型で検収基準が曖昧 | 契約前に「何をもって達成とするか」を文書で合意する |
契約形態と実態がずれたまま頓挫した場合に責任がどう分かれるかは、PM義務・協力義務を発注者の実務に翻訳するで扱っています。契約後の委託先統制はマルチベンダー時代のベンダーマネジメントを参照してください。
まとめ
契約形態の選択は、法務の手続きではなくリスクと責任の配分を決めるIT投資判断です。何を作るかが決まっていれば請負、探しているなら準委任、課題が明確で解き方を任せたいなら成果型。この判断を工程ごとに行い、根拠を説明できる状態にしておくことが、AIで取引の前提が変わる局面での発注者の備えになります。
FAQ
Q. 請負のほうが発注者に有利ではないのですか。 A. 完成責任をベンダーに負わせられる点では有利です。ただし要件が固まっていない段階で請負にすると、ベンダーはリスクを見積もりに上乗せし、変更のたびに交渉が発生します。有利になるのは、何を作るかを発注者が確定できている場合に限られます。
Q. アジャイル開発で請負契約は使えませんか。 A. 作るものが開発を通じて変わるアジャイル開発では、着手時に完成の内容を確定しにくいため、請負はなじみにくいとされています。IPAのアジャイル開発版モデル契約も準委任を前提としています。
Q. 成果型の契約で注意すべき点は何ですか。 A. 成果の定義と検収基準です。「業務効率化」のような曖昧な表現では達成を判定できません。対象業務、測る指標、判定する時期と判定者を契約前に合意してください。
参考資料
- IPA「情報システム・モデル取引・契約書(第二版)」 https://www.ipa.go.jp/digital/model/model20201222.html
- IPA「情報システム・モデル取引・契約書(アジャイル開発版)」 https://www.ipa.go.jp/digital/model/agile20200331.html
- e-Gov法令検索「民法」(請負・委任) https://elaws.e-gov.go.jp/document?lawid=129AC0000000089
- 週刊BCN「SIerにおける『FDE』の意義は 富士通とNTTデータの実践から考える」 https://www.weeklybcn.com/journal/feature/detail/20260907_217086.html

