請負契約と準委任契約

それぞれが契約的にどの様なタイプのものかはわかっていても、ソフトウェア開発の文脈でこれらが何を意味するのか、意外によくわからない人が結構いそうだ。今更とも思うが、記事にしてみる。

ソフトウェア開発の文脈で、請負契約と準委任契約がそれぞれどの様な意味をもつのかを、筆者の独断と偏見で記載する。

アウトソーシングとかベンダコントロールとか仕事でやらなきゃいけない人！知らないとは言いづらいと思っているそこのあなた！多分損したとしても5分くらいだから、読んでください。

請負契約

請負契約は英語で Fixed Scope and Fixed Price Contract と呼びます。
つまり、スコープと価格を決めて受注者が責任を持って成果物を納品するタイプの契約です。

準委任契約

準委任契約は英語では Time & Material Contract。こっちは英語がわかりやすいとも言えないので訳す意味はないが、日本語が小難しい。
「提供した労働時間に対して対価が支払われる」契約です。請負契約は成果物を納品すること、さらにその品質に対して受注側が責任を持ちます。

で、あえて断言します。
請負契約は、受注側にとってとても不利です。
そして、受注側にとって不利なのと全く同じ理由で、発注側にも実は不利です。

アジャイルが生まれた真の理由

別の記事でこれについては書きました。
アジャイルが生まれた理由、それは、要件定義をしっかりやって、ちゃんと予算つけて、真面目にこなしていればサービスだろうが建物だろうが予算内でしっかり作れるよ、というのが実はそうでもないということがわかってしまったこと。
色々理由はあるけれど、物を作り出す前に完璧な要件定義とか良い仕様を作ることが、そもそもほぼ不可能だからという理由が大きい。

この理由と、請負契約が良くない理由が同一だ。

請負契約が良くない理由

請負契約が不利だという件に話を戻します。

受注側：
要件や要求仕様は物を作り始めてから変化するのが当たり前なのに、変わる前の要件定義や要求仕様に基づいて計画し、それに対してコストやスケジュールの責任を負うから。無理ゲー。ギャンブルですらない。
仕方ないから法外な利益を載せて契約しても、土台が変わっちゃうんだから利益が出る保証はない。

発注側：
受注側がこれだけ不利なんだから、本来臨機応変に見直した方が良い要件定義や要求仕様を、変えようとすれば受注側はゴネます。「仕様を変えるなら料金が変わります」「仕様が変わるならスケジュールが変わります」と。
つまり、それらを受け入れる用意がない場合、例えば1億で発注かけたら、大して良くないものができ、後でもっと金がかかるのをわかっているのに1億使い切るまでやめられない。

だったら、途中で予定変更できる様に準委任契約の方がよくない？途中で予定変更するのが恥ずかしいとされる様な組織だったら、そもそも物作りは諦めた方がいい。言い方悪いけど「あなたにゃまだ早い。」というやつです。

請負と準委任のハイブリッド型契約

要件定義ができるまでは準委任でやって、それで要件確定してから今度は請負契約で物作りという手もあるし、比較的一般的にやられている様だ。しかし、開発は準委任でしかやらないというのが、最近の若いソフトウェア開発サービスを提供する企業では主流と言って良いだろう。

名前だけの責任者より、自由に価値創造を目指す方が楽しい

日本の大きな企業だと、請負が当たり前という時代があったのだろう。
要件定義から仕様策定から開発まで全部ベンダ任せ。何が起きても発注責任者が名前ばかりで責任を取らない構え。自ら要件定義も仕様策定もしないで、よく知らない部外者にお任せでは成功は望み薄だし、そもそも楽しくないんじゃないか。

出費の限度額などは決めた上で、納得できる価値創造だけを目指してチームで仕事できると、楽しい。私はそれが好き。