問題
"情報システム・モデル取引・契約書"によれば、ユーザー(取得者)とベンダー(供給者)間で請負型の契約が適切であるとされるフェーズはどれか。
ア：システム化計画フェーズから導入・受入支援フェーズまで
イ：要件定義フェーズから導入・受入支援フェーズまで
ウ：要件定義フェーズからシステム結合フェーズまで
エ：システム内部設計フェーズからシステム結合フェーズまで
結論
正解は 「エ：システム内部設計フェーズからシステム結合フェーズまで」 です。
なぜ上流工程（要件定義など）は請負に向かないのか？
「請負」と「準委任」の性質の違いから解説します。
1. そもそも「請負」と「準委任」の違いは？
IT開発における契約は、大きく分けてこの2つです。
-
請負型（うけおい）
- 目的： 「仕事の完成」を約束するもの。
- 責任： 成果物（動くシステムなど）を納品する義務がある。
- 向いているフェーズ： ゴール（仕様）が明確な工程。
-
準委任型（じゅんいにん）
- 目的： 「業務の遂行」を約束するもの。
- 責任： 善管注意義務（プロとして最善を尽くすこと）はあるが、完成の義務はない。
- 向いているフェーズ： ゴールが流動的で、ユーザーと一緒に作り上げる工程。
2. フェーズごとの「適切」な契約形態
モデル取引・契約書では、開発工程を以下のように切り分けています。
【準委任型】が適切なフェーズ
- システム化計画 / 要件定義 / 外部設計
- これらは「何をどう作るか」を決める工程。不確定要素が多く、ベンダーだけに「完成」の責任を負わせるのが難しいため、ユーザーと協力して進める準委任が適しています。
【請負型】が適切なフェーズ
- 内部設計 / プログラミング / システム結合
- 理由：外部設計（UIや機能一覧）が固まった後の工程。作るべきものが明確なため、「期間内にこの通り完成させて納品する」という請負契約がなじみます。
【準委任型】（再度）
- システムテスト / 導入・受入支援
- 最終的なテストや導入は、ユーザー側の環境や判断が大きく関わるため、再び準委任が推奨されます。
3. 図解で見る「エ」の範囲
問題の図にある「エ」の矢印を見てみると、
「システム内部設計」から始まり「システム結合」で終わっています。
これは、仕様が固まった後の「製造・構築」のフェーズをピンポイントで指しています。したがって、ここが「請負型」として最も適切な範囲となります。
まとめ
- 上流（要件定義〜）は「準委任」：一緒に考えるフェーズ
- 中流（内部設計〜）は「請負」：決まったものを作るフェーズ
- 下流（テスト〜）は「準委任」：一緒に確認・導入するフェーズ
＝＝＝＝
実務でも「ここから先は請負なので、仕様変更は追加見積もりですよ」なんて
会話が発生する境界線です。この構造を頭に入れておくと、契約トラブルの際にも役立ちそう。
脱作業者。
