契約形態の基礎――請負と準委任の使い分け
「要件定義から請負で」という契約は、日本のシステム開発で最ももめる組み合わせのひとつです。何を作るかが決まっていない段階で「完成」を約束しているため、そもそも完成の定義ができません。
契約形態の知識は法務の仕事だと思われがちですが、実際に困るのは現場のPMです。工程と契約が噛み合っていないと、スコープの議論が毎回「契約上どうなのか」に流れていきます。
■ 請負と準委任の違い
違いは一点に集約されます。完成を約束しているかどうかです。
請負は仕事の完成を約束します。完成しなければ報酬は発生せず、成果物に不備があれば契約不適合責任を負います。受注者がリスクを引き受けるぶん、見積りには相応のバッファが乗ります。
準委任は業務の遂行を約束します。約束しているのは「専門家として注意を尽くして作業すること」であり、成果そのものではありません。発注者側が主体的に関与する前提の契約です。
なお、2020年施行の改正民法で、準委任には成果の引渡しに対して報酬を支払う型（成果完成型）も明文化されました。実務では、履行割合型か成果完成型かを契約書で明示しておくと、後の解釈の食い違いを避けられます。
■ 工程との対応
工程の性質で、適した契約は変わります。
企画・要件定義：何を作るかが決まっていない段階。準委任が適する。ここを請負にすると、受注者は「完成」を守るために要件を絞ろうとし、発注者は「まだ足りない」と主張する構図になる
基本設計：要件の固まり具合による。動くなら準委任、固まっていれば請負も可能
詳細設計・製造・テスト：作るものが確定していれば請負が適する
運用・保守：作業量が読めないため準委任。ただしSLAを定めて成果を測る形もある
一括請負が選ばれるのは、発注者にとって予算が確定するためです。しかし要件が動く前提の案件で一括請負にすると、変更のたびに契約交渉が発生し、結果として動きが遅くなります。工程ごとに契約を分ける（多段階契約）ほうが、双方にとって現実的なことが多くなります。
■ 偽装請負に注意する
契約形態にかかわらず、発注者が受注者の要員に直接指示を出すことはできません。これは請負でも準委任でも同じです。
具体的には、次のような行為が問題になります。
発注者が受注者のメンバーに直接、作業内容や優先順位を指示する
発注者が受注者メンバーの勤務時間や休暇を管理する
受注者側に責任者が置かれておらず、実質的に発注者の指揮下にある
対策は明確です。受注者側に責任者を置き、指示はその責任者を通す。会議で直接会話することは問題ありませんが、作業の割り当てや変更の指示は責任者経由にします。同じ場所で働いていると曖昧になりやすいため、意識的に運用する必要があります。
■ 契約書で確認しておく項目
PMとして、契約書のすべてを読む必要はありませんが、次の項目は把握しておくと判断が早くなります。
作業範囲：何が含まれ、何が含まれないか（除外事項）
検収条件：誰が、何をもって完了と判断するか
変更の手続き：仕様変更が生じたときの進め方と費用の扱い
契約不適合責任の期間：引渡し後いつまで責任を負うか
再委託の可否：下請けに出せるか、事前承認が必要か
知的財産権の帰属：成果物の権利がどちらに帰属するか
このうち、現場で最も効くのは検収条件です。ここが「発注者が満足すること」といった曖昧な表現になっていると、いつまでも終われません。スコープ記述書の受入基準と契約書の検収条件は、同じ内容を指している必要があります。
■ 多重下請け構造での注意
日本のシステム開発では、元請け・一次下請け・二次下請けと階層になることが少なくありません。この構造では、次の点に注意が必要です。
情報が伝わる過程で劣化する：要件の意図が、階層を降りるほど薄れる
指揮命令が曖昧になる：元請けが二次下請けのメンバーに直接指示すると、偽装請負の問題が生じる
品質責任の所在が分かりにくい：どの階層がどこまで責任を持つのかを、契約で明確にしておく
PMにできる現実的な対策は、体制図に契約関係を書き込んでおくことです。誰が誰と契約しているかが図で見えていれば、指示の出し方を間違えにくくなります。
■ チェックリスト
工程の性質と契約形態が合っているか
準委任の場合、履行割合型か成果完成型かが明示されているか
検収条件が具体的に書かれているか
変更が生じたときの手続きと費用の扱いが決まっているか
受注者側に責任者が置かれ、指示がそこを通っているか
体制図に契約関係が書かれているか
契約形態の選択は、コストや法務の都合だけで決まるものではありません。プロジェクトの進め方そのものを規定します。要件が動く前提の仕事に完成を約束させる契約を結べば、その矛盾は必ず現場に降りてきます。契約の段階でPMが意見を言えるかどうかは、後の数か月を左右します。