正解：ウ
各選択肢の解説
ア全工程を一つの請負契約にまとめ、着手前に総額と納期を確定させる。
誤り。これは一括契約の考え方です。完成を約束させる請負は発注側に安心感があるので選びがちですが、 要件が固まらないうちに総額と納期を決めると、見積りの前提が曖昧なまま責任だけが固定され、 後の追加費用や紛争の原因になります。
イ全工程を準委任契約にまとめ、システムの完成までの責任をベンダに負わせる。
誤り。準委任契約は、仕事の完成ではなく事務の処理を引き受ける契約です。完成までの責任を 負わせたいなら、要件が確定して完成の内容を特定できる工程で請負契約にする必要があります。 契約の型と負わせたい責任がかみ合っていません。
ウ要件定義は準委任、要件確定後の開発は請負とし、工程ごとに個別契約を結ぶ。
正解。工程ごとに契約を分ける多段階契約です。何を作るかが決まっていない要件定義は作業の遂行を 約する準委任、作るものが確定した後の開発は完成を約する請負、と工程の性格に合わせます。
エ要件定義は請負、要件確定後の開発は準委任とし、工程ごとに個別契約を結ぶ。
誤り。工程ごとに分ける点は正しいのですが、契約の型が逆です。要件定義は成果の中身が事前に 決まらないので完成を約束させにくく、逆に要件確定後の開発は作るものが特定できるので 完成を約する請負になじみます。
理解を深めるために
決まっていないものに「完成」は約束できない
家を建てるとき、間取りも予算も決まらないうちに「この金額でこの日までに完成させてください」と 契約する人はいません。まず設計の相談をして、図面が固まってから工事の契約を結びます。 システム開発も同じで、何を作るかが決まる前と後とで、結ぶべき契約の型が変わります。
なぜ工程ごとに契約を分けるのか
情報システム・モデル取引・契約書は、ユーザ企業とITベンダの間の開発委託契約のひな型です。 経済産業省が公開した版をIPAが見直した第二版があり、別にアジャイル開発版もあります。 ここでは、基本契約の下に工程ごとの個別契約を積み重ねる多段階契約の考え方が取られています。
- 要件定義: 作るものの中身を決める工程。完成形を事前に特定できないので、作業の遂行を約する準委任になじむ
- 要件確定後の開発: 作るものが特定できるので、完成を約する請負になじむ （モデル契約では、外部設計の段階は準委任型と請負型のどちらも選べる整理で、請負が基本になるのは ソフトウェアの設計・製作以降です。この問題では、要件が確定した後の開発を請負とする考え方を問います）
- 前の工程の結果を見てから次の工程の見積りと契約をするので、曖昧な前提で総額を固定せずに済む
委託する側の担当者にとっては、どの工程でベンダが何に責任を負うのかが契約の型で決まる、という点が大事です。 完成責任を求められるのは請負の工程であり、準委任の工程では、ユーザ企業自身も要件を決める当事者になります。
混同しやすいものとの違い
| 契約の結び方 | 中身 | この場面での評価 |
|---|---|---|
| 多段階契約（要件定義＝準委任、開発＝請負） | 工程の性格に合わせて型を変える | 要件が未確定の場面に合う |
| 一括の請負契約 | 全工程の完成を最初に約束させる | 前提が曖昧なまま総額・納期が固定される |
| 全工程を準委任 | 作業の遂行を約する | 完成責任を負わせる型ではない |
| 型を逆にした多段階契約 | 要件定義に完成を求める | 中身の決まらない工程に完成を約束させている |
「要件が固まっていない」という条件が出たら、その工程は準委任、固まった後は請負、と読み分けます。