システムアーキテクト 2016年午前2 問16

問題文

“情報システム・モデル取引・契約書”によれば、ユーザ（取得者）とベンダ（供給者）間で請負型の契約が適切であるとされるフェーズはどれか。

🖊️ 解答を隠して解いてみる

選択肢

ア：システム化計画フェーズから導入・受入支援フェーズまで

イ：要件定義フェーズから導入・受入支援フェーズまで

ウ：要件定義フェーズからシステム結合フェーズまで

エ：システム内部設計フェーズからシステム結合フェーズまで（正解）

🔒 解説は解答すると表示されます

請負契約の適用範囲【午前2解説】

正解の理由

「請負契約」は成果物（完成物）をベンダが責任を持って作成・引き渡す契約形態であり、設計・実装・結合といった作業の成果物が明確に定義できる工程で適しています。図に示される矢印エはシステム外部設計からシステム結合までを貫いており、ここはベンダが詳細設計・開発・結合の責任を負って成果物を納める範囲に相当するため、請負型が適切です。外部仕様に基づいてベンダが内部設計・コーディング・モジュール結合を行い、結合結果をもって検収を受けるという請負の性質と整合します。

解法ステップ

図（矢印の開始・終了位置）を正確に読み、各矢印がどの工程区間を示すかを把握する。
「請負契約」の特徴を確認する。すなわち「成果物（完成）」の引渡し責任がベンダにある点、作業範囲が明確に定められる点。
その特徴が当てはまる工程（設計→製造→結合など成果物が明確になる区間）を選ぶ。
図でその区間を示す矢印が正解であることを確認する（本問では矢印エが該当）。

選択肢別の誤答解説

ア: システム化計画～導入・受入支援（図の最広範囲）
理由: 計画段階や運用・受入支援まで含む範囲は、業務要件の整理やユーザ側との共同作業・支援が多く、成果物ベースで一括請負するには範囲が大きすぎ、責任分界が不明確になる。準委任や段階的契約が適する場面が多い。
イ: 要件定義～導入・受入支援（要件定義開始から最終導入まで）
理由: 要件定義はユーザと協議しながら作り上げる作業で、ベンダ単独の成果物として扱いにくい部分がある。また導入・受入支援は現地調整やユーザ側作業が混在するため、請負だけで一括するのが適切とは限らない。
ウ: 要件定義～システムテスト（要件定義開始からシステムテストまで）
理由: 要件定義開始を請負の起点にすると、仕様確定以前の不確実性をベンダが全部負うことになり、リスクが高い。要件段階は契約形態として準委任や協働が適する場合が多い。
エ: システム外部設計（開始）からシステム結合（終了）まで
理由: システム外部設計で外部仕様が確定し、その後の内部設計・開発・結合でベンダが具体的成果物を作成・引渡す流れになるため、請負契約の「成果物責任」に合致する。よって最も適切。

よくある誤解

「請負＝全部任せてよい」ではない：請負は成果物責任をベンダに課すが、要件定義や業務判断などユーザ側でしか決められない事項はユーザの責務のままにする必要がある。
「請負は常に固定価格」ではない：請負は成果物ベースだが、成果物の範囲が曖昧だと追加費用や変更管理が発生するため、契約書で範囲・受入基準を明確にする必要がある。

補足コラム

請負と準委任（または委任）の基本的な棲み分けは「成果物ベースか技能提供ベースか」です。請負は「完成物の引渡し」が目的で、受入検査や納入基準が設定されます。一方、準委任は作業やサービスの提供（作業時間や人的リソース）に重点を置き、成果物そのものよりも遂行状況の管理が重要です。実務では、設計・製造は請負、要件定義やユーザとの協議は準委任、運用・保守は保守契約（SLA）といったハイブリッド契約が多く用いられます。

FAQ

Q1: 請負で「結合」までを範囲にする理由は何ですか？
A1: 結合は複数モジュールの組合せによる成果物（統合された機能）を作る作業であり、ここまでをベンダが完成させて検収を受けることで、成果物責任の区切りが明確になるためです。

Q2: 導入・受入支援も請負に含められますか？
A2: 含めることは可能ですが、導入現場での調整やユーザ側作業が多い場合は、準委任や別契約（工数請求）にする方がリスク分配上適切なことが多いです。

Q3: 契約書で特に重要な点は？
A3: 成果物の定義、受入基準（検査項目と合格基準）、変更管理手続き、瑕疵担保期間や責任範囲を明確にすることが重要です。

関連キーワード: 請負契約、成果物責任、外部設計、システム結合、契約形態切替

← 前の問題へこの年度をクイズで解く次の問題へ →

\ せっかくなら /

システムアーキテクトを
クイズ形式で学習しませんか？

クイズ画面へ遷移する→

すぐに利用可能！