準委任と請負でここまで変わるPMの責任・リスクと実務上の着眼点

なぜ契約類型がPMにとって重要なのか

システム開発の現場では、「まず要件」「まずスケジュール」という話が先に出がちですが、本来その前に確認すべきものがあります。それが「契約の種類（契約類型）」です。

同じように要件定義や開発をしていても、「準委任契約なのか」「請負契約なのか」によって、次のような点が大きく変わります。

• ベンダ側PMがどこまで結果責任を負うのか
• 手戻りや仕様変更が発生したとき、どちらがどこまで負担するのか
• 遅延が起きたときの責任の位置づけ
• 検収・支払いの条件やトラブルになりやすいポイント

契約の理解は「法務の仕事」と思われがちですが、実務ではPMの判断や進め方に直結します。本記事では、法律の細かい条文の話ではなく、「PMとして何を押さえておくべきか」という視点で解説していきます。

契約類型の基礎：準委任と請負のざっくり整理

まず、準委任と請負の違いをざっくり整理します。

準委任契約とは

準委任は「結果」よりも「作業やプロセス」を提供する契約です。

特徴をシンプルに言うと：

• ベンダは「一定の注意義務をもって仕事をする」ことを約束する
• 成果物の完成そのものを保証する契約ではない
• 期間や稼働時間に応じて対価が支払われることが多い（いわゆる準委任型の業務委託）

イメージとしては「専門家に相談して並走してもらう」ようなものです。要件定義支援やPMO支援などでよく使われます。

請負契約とは

請負は「特定の成果物を完成させること」を約束する契約です。

特徴は：

• ベンダは成果物を完成させる「結果責任」を負う
• 完成しないと報酬が支払われない（または減額・損害賠償などのリスク）
• 検収合格をもって支払い・プロジェクト完了とするケースが多い

イメージとしては「家を建ててもらう」ようなものです。システム開発（設計〜テスト〜リリース）を一括で請け負う契約でよく見られます。

PM視点での一言まとめ

• 準委任：
  • 「プロセス提供型」
  • 注意義務を果たしているかが問われる
• 請負：
  • 「成果物完成型」
  • 約束した成果を出せたかが問われる

この違いが、以降で説明する「PMの着眼点」を大きく分けるポイントになります。

準委任契約におけるPMの着眼点

準委任契約では「成果物完成」よりも「適切なプロセス」と「適正な工数・体制」が重要になります。PMとして特に意識したいポイントを見ていきます。

範囲（スコープ）のあいまいさをどう扱うか

準委任では、契約上のスコープがざっくりしているケースが多く、以下のような問題が起こりがちです。

• いつの間にか対応範囲が広がり、メンバーが疲弊する
• 「それは契約外では？」というやり取りが増える
• お客様とベンダの期待値がズレたまま走ってしまう

PMとしては、以下を意識します。

• 毎月または四半期ごとに「対応範囲」の棚卸しを行う
• 要求・依頼を「チケット化」して、何にどれだけ工数を使っているか可視化する
• 大きな追加・変更は、契約更新や体制見直しとセットで相談する

3-2. 成果の「見える化」をどう設計するか

準委任では「時間でお金が動く」ため、顧客からは「何をどれだけやってくれているのか分かりにくい」という不満が出やすくなります。

PMとしては、次のような見える化が有効です。

• 週次・月次での作業報告（対応案件一覧、ステータス、使用工数）
• 改善提案やリスク指摘など、「付加価値」の記録
• 成果物がある場合は、レビュー記録や成果物一覧の共有

「時間を売る」のではなく、「価値あるアウトプットを提供している」ことを丁寧に示すことが信頼につながります。

体制・スキルと工数見積もりのバランス

準委任では、月○人日、○名体制といった形で契約することが多いため、PMは次のバランスを見る必要があります。

• 実際の仕事量と契約工数のギャップ
• メンバーのスキルレベルと求められる成果物の難易度
• 短期的な「頑張り」で吸収してしまい、慢性的な過負荷になっていないか

必要に応じて、

• 契約工数の見直しを提案する
• ナレッジ化・自動化で効率を上げる
• 役割分担（上位者レビュー、省力化）を見直す

といったアクションもPMの重要な役割になります。

請負契約におけるPMの着眼点

請負契約では、「成果物」と「検収」に焦点が集まります。PMとしては、契約リスクを踏まえたうえで、スケジュール・品質・コストのバランスを取ることが求められます。

成果物と受入基準（検収条件）の明確化

請負で最も重要なのは、「何ができていればOKなのか」を具体的に握っておくことです。

• 成果物の一覧（例：設計書一式、テスト結果報告書、運用マニュアルなど）
• 検収基準（どのテストで、どの条件を満たせば合格か）
• 軽微な不具合の扱い（残件があっても検収してもらえるのか など）

これらが曖昧だと、

• 「まだ完成していない」と言われ検収してもらえない
• 修正対応が延々と続き、追加費用ももらえない

といったトラブルに直結します。

要件変更・仕様追加への対応ルール

請負契約では、途中での仕様追加や変更が大きなリスクになります。PMは以下を徹底する必要があります。

• 口頭やチャットでの「ついでにやっておいて」を放置しない
• スコープ変更は、必ず「影響範囲（工数・コスト・納期）」を整理したうえで合意を取る
• 大きな変更は、契約変更や追加見積もりとセットで扱う

「お客様のために」と善意で対応を積み重ねると、最終的に自チームが疲弊し、採算も合わなくなります。PMが「線引き役」を担うことがとても重要です。

スケジュール遅延リスクの管理

請負では「納期遅延」が契約上の大きなリスクになります。

PMとしては、

• クリティカルパス上のタスクに対するリスク洗い出し
• 早期に遅延兆候をキャッチできる進捗管理（EVMなども有効）
• 要件凍結のタイミングと、後出し変更の抑制

を意識して運営します。

また、顧客側の遅れ（仕様決定の遅れ、レビュー遅延など）で納期に影響する場合は、

• 事実を記録に残す（議事録・メール・チケット）
• 影響を定量的に示したうえでスケジュール再調整を依頼する

といった「証跡」と「交渉」が重要になります。

契約類型で変わる具体的なPMの判断ポイント

ここでは、準委任と請負の違いがPMの判断にどう影響するかを、少し具体的な場面で見てみます。

追加作業依頼が来たとき

準委任の場合

• まず現行の契約工数内で吸収できるかを検討
• 重要度・優先度を顧客とすり合わせ、既存タスクとの入れ替えで対応する選択肢も
• 大幅な増加が続く場合は、次回契約更新時に工数・体制見直しの材料として蓄積

請負の場合

• 追加依頼が「契約スコープ内」か「スコープ外」かを判断
• スコープ外であれば、追加見積もり・契約変更をセットで検討
• 口頭合意だけで進めず、最低限メールや議事録で条件を明文化

不具合や品質問題が見つかったとき

準委任の場合

• 不具合が発生したプロセスを振り返り、「注意義務を尽くしていたか」を整理
• 再発防止策の提案やプロセス改善を通じて、価値を示すことが重要

請負の場合

• 検収前であれば、原則として無償修正の範囲となることが多い
• 検収後の不具合は「瑕疵担保（保証）」の期間や範囲を契約で確認
• 品質問題が大きい場合には、損害賠償や違約金などのリスクも視野に入れた対応が必要

顧客からの「とにかく急いでほしい」要望

準委任の場合

• 急ぎ対応が続くと、メンバーの負荷が増えやすい
• 優先度の明確化と、他作業の後ろ倒し・中止の相談がポイント
• 長期的には、契約工数や体制の見直し提案も検討

請負の場合

• 納期短縮の要望であれば、コスト増（増員・残業）とのトレードオフを整理
• 範囲縮小（フェーズ分割、MVP化（実用最小限の製品））とのセット提案が有効
• 契約上の納期・遅延ペナルティの条件を踏まえて判断

契約類型が混在するケースと現場での工夫

現場では、単純に「準委任だけ」「請負だけ」ではなく、以下のように混在することも多いです。

• 上流（要件定義）は準委任、下流（設計〜開発〜テスト）は請負
• 基本機能は請負、改善・追加は準委任で保守契約
• PMOや品質監査は準委任、本体開発は請負

このような場合、PMとして特に意識したいのは次の3点です。

契約ごとに「責任の線引き」を図示する

• 上流の合意内容（要件定義の成果）をどこまで請負側の前提とするのか
• 仕様の曖昧さが残っている部分は、誰がどのタイミングで確定させるのか
• 保守・追加開発の範囲と、請負契約での無償対応範囲の境界

これらを口頭ではなく、図や表で整理し、顧客・社内で共有しておくとトラブル予防に役立ちます。

契約の違いをチーム全体で共有する

PMだけが契約内容を理解していても、現場メンバーが把握していないと、

• 善意でやりすぎてしまう
• 必要なエビデンスを残さない
• スコープ外対応を当たり前だと思ってしまう

といったギャップが生まれます。

キックオフや定例会で、

• 「このプロジェクトはどの部分が準委任で、どの部分が請負か」
• 「どこに気を付けると会社として大きなリスクを避けられるか」

を共有しておくことで、チーム全体の意識合わせができます。

契約更新・次フェーズに向けた学びの蓄積

契約類型が混ざるプロジェクトでは、フェーズを重ねるほど「こうしておけばよかった」が見えてきます。

PMとしては、

• 問題が起きた場面と、契約のどの部分が影響していたかを振り返る
• 次回の契約時に、条文やスコープ記載をどう変えるべきかメモしておく
• 社内テンプレートやチェックリストに反映する

といった「契約×PM」のナレッジ化を意識すると、組織全体のレベルアップにつながります。

まとめ

準委任と請負という契約類型は、一見すると法務の専門領域のように感じられますが、実際にはPMの日々の判断に直結しています。

本記事で押さえたポイントを振り返ると：

• 準委任では「プロセス提供」「工数・体制の適正」「価値の見える化」が重要
• 請負では「成果物と検収基準の明確化」「スコープ管理」「納期・品質リスク」が鍵
• 契約類型ごとに、追加対応、不具合対応、納期短縮要望への向き合い方が変わる
• 準委任と請負が混在する場合は、「責任の線引き」「チーム全体での共有」「次契約への学びの反映」がポイント

PMとして「契約を前提にしたプロジェクトマネジメント」を意識できるようになると、

• 無理な要求に振り回されにくくなる
• トラブルの芽を早めにつぶせる
• チームと会社を守りつつ、顧客にも価値を出せる

という良い循環が生まれます。

まずは、自分が担当しているプロジェクトの契約書をもう一度眺めてみて、
「この部分が準委任っぽい」「ここは請負の責任が重そうだ」
といった観点で読み直してみてください。きっと、これまでとは違った見え方がしてくるはずです。