システムの受託開発での「準委任契約」で気を付けることは？

準委任契約は「やり方を誤ると工数管理トラブルが起きやすい」ですが、設計と運用をきちんと整えれば、受託開発でも非常に合理的な契約形態です。

受託開発での準委任契約とは

準委任契約は一言で言うと、

「成果物」ではなく「業務遂行そのもの」に対して報酬が発生する契約

です。

請負契約との違い（超重要）

👉 「仕様が固まらない」「変化前提」な開発では準委任が向く

👉 「完成物を保証したい」なら請負

なぜ工数管理でトラブルが起きやすいのか

準委任で揉める原因は、ほぼこの3つに集約されます。

① 「何をやっているのか分からない」問題

1. クライアント側

「毎月○○時間って言うけど、何をやったの？」

1. 開発側

「仕様検討・調査・調整も業務です」

👉 業務内容の粒度が合っていない

② 「思ったより進んでいない」問題

1. クライアント

「3ヶ月もやってるのに、まだこれ？」

1. 開発側

「仕様変更と検討が多くて…」

👉 成果物期待 vs 作業提供のズレ

③ 「準委任なのに請負っぽく扱われる」問題

1. 「これ完成させてください」
2. 「この日までに必ず」

👉 契約は準委任、運用は請負 ← 地雷

トラブルを防ぐ実践的な工数管理の考え方

① 工数ではなく「タスク単位」で可視化する

❌ NG

1. 「今月120時間作業しました」

✅ OK

1. 要件整理：20h
2. API設計：15h
3. 実装（ユーザー管理）：30h
4. 調査・検証：10h

👉 時間＋中身のセットが必須

② 「成果物を約束しないが、進捗は約束する」

準委任でも、以下は決めておくべきです。

1. 週次／隔週の進捗報告
2. 今週やったこと
3. 来週やること
4. 課題・判断待ち事項

👉 「完成責任はないが、説明責任はある」

③ 稼働時間の上限・下限を決める（超重要）

例：

1. 月140〜180時間
2. 超過・未達時の精算ルール

これがないと、

1. 「使い放題だと思われる」
2. 「勝手に減らされたと思われる」

という不毛な対立が起きます。

④ 役割分担を明文化する

準委任では特に、

1. 仕様決定者は誰か
2. 優先順位を決めるのは誰か
3. レビュー責任は誰か

を曖昧にすると、

「言われてない」

「聞いてない」

の応酬になります。

受託開発で準委任が向いているケース

✔ 要件が流動的

✔ アジャイル／スクラム開発

✔ 技術的検証が多い

✔ 社内エンジニア不足の補完

✔ プロダクト思考で伴走したい

逆に、

❌ 納期・成果物が固定

❌ 見積金額を絶対に変えたくない

❌ 開発過程に関与したくない

なら、請負の方が無難です。

実務的な結論

1. 準委任＝危険ではない
2. 「契約理解」と「運用設計」が甘いと地獄
3. 工数管理は時間 × タスク × 進捗説明の3点セットでやる