システム開発手法で、古典的だが今も主流なのがウォーターフォール型だ。この手法では、要件定義、基本設計（外部設計）、詳細設計（内部設計）、プログラミング、単体テスト、結合テスト、総合テスト、受入テスト（ユーザーテスト）と、八つの開発フェーズを規定するケースが多い。

　ベンダーとユーザー企業がシステム開発の契約を結ぶに当たり、要件定義と受入テストは準委任契約、詳細設計から総合テストまでは一括で請負契約とするのが一般的であった。要件定義ではユーザー企業の業務上の要件を決めるし、受入テストはユーザー自身が要件定義書に書かれた通りにシステムを使って業務ができるか否かを確認するので、まさしく発注者が責任を持って行う作業である。ベンダーは準委任契約でそのサポートを行う役割だ。

　一方、基本設計から総合テストはプログラム開発の専門的な知識や経験が必要なフェーズなので、ベンダー主体の作業であり、成果物に関しても基本的にベンダーが作成し、それらはプロジェクトの納品物とされる。

　ところが、少し前から基本設計を準委任契約で提案するベンダーが増えている。主な理由として、「要件定義フェーズでユーザーが決めきれない部分が多く残ったまま、基本設計に入るケースも少なくない。そのため、基本設計にもユーザーに主体的に参加してもらい、仕様を決めてもらう必要があるから」とベンダーは説明する。

　本音に言い換えれば「要件定義があいまいな状態で基本設計を請負でやると、スコープの増大や手戻りなどのリスクが高いから準委任でやりたい」となる。以前はIT業界でも「お客様は神様です」的な商習慣があり、リスクを承知の上で受注を優先して一括請負契約での受託が多かった。たとえ最初の開発プロジェクトは赤字でも追加開発や運用保守で取り返せばよい、といった風潮があった。

　しかし、今はそんな時代ではない。慢性的な人手不足の状況では最初であっても赤字プロジェクトは許されず、プロジェクトごとに厳しく収益管理するベンダーがほとんどだ。その姿勢の表れの一つが基本設計の準委任契約への移行だろう。

　もちろん一部は他社の真似をしているだけで、製造者責任から逃げているようなベンダーもいるが、トレンドとしては基本設計を準委任契約として提案するベンダーは増えるだろう。まだ過渡期なので、準委任契約であっても実態は請負契約に近く作業超過に対して追加請求しないケースが多いようだが、数年後はどうなるか分からない。

　準委任契約になった場合に発注者が留意すべきは設計上の瑕疵の解釈が変わる点だ。請負契約で納品物に基本設計書が明記されていればベンダーの責任となる。しかし、準委任契約で基本設計書をユーザーが作成するとなれば、設計上の瑕疵は発注者責任となる。

　ユーザーとしてはどうすべきか。要件定義をきちんと行い、基本設計を請負契約とするようにベンダーと交渉するか。あるいは基本設計も発注者責任として受け入れてスキル習得も含めて対応できるようにするか。どちらにしても、基本設計の準委任契約への移行をユーザーは甘く見ないほうがよい。