システム開発契約には、「請負型契約」「委任型契約」「混合型契約」の大きく3種類があり、受注者であるソリューションプロバイダには、それぞれメリットとデメリットがある。現在、受注者側が成果物に責任を負う請負契約が主流だが、契約時には、請負責任に関する免責事項を明確にしておく必要がある。
システム開発におけるトラブルは、ユーザー企業のソフト開発の目的や適用業務を、開発委託先であるソリューションプロバイダがきちんと理解できていないことが原因であることが少なくない。
その点からは、業務内容やシステムに必要な要件を最もよく分かっているユーザー企業のSE自らが開発する「自社開発」が望ましい。だが実際には、多くのユーザー企業にとって、自らが十分なシステム開発の経験や技術を持つことは難しく、ソリューションプロバイダに開発を委託することになる。
システム開発を外部に委託する契約には、（1）開発請負契約型、（2）開発委任契約型、（3）請負契約型と委任契約型を併用する混合契約型──の3つの形態がある（図）。
 |
| 図●システム開発の契約形態とメリット、デメリット |
発注者が原因のトラブルは免責事項で回避
請負契約は、受注者がシステムの完成に責任を持ち、成果物を発注者に引き渡すことを約束する契約である（民法632条）。発注側のユーザー企業にとっては、完成と引き渡しが保証されるので大変安全な契約である。一方受注者側にとっては、想定したコストで完成できなければ、大幅な赤字案件になる可能性すらある、リスクの高いビジネス形態である。ただし、適切なリスク管理をして、高い付加価値のあるシステムを構築できれば、大きな利益を得られる契約形態でもある。
システム開発の発展経緯を見ると、約20年前までは圧倒的に委任型の契約が多く、請負契約は一般的な契約形態として普及しなかった。その後「SI（システムインテグレーション）契約」と呼ばれる、ソフト開発の請負を含むシステム構築請負契約が誕生した。筆者が所属していたIBMの「システム・マネジメント・サービス（SMS）」というシステム構築請負契約がその先駆けとなって、爆発的に普及した。筆者は、このSMSこそが、システム開発技術を急速に発展させるきっかけになったと考えている。都市銀行の第2次オンラインシステムや新聞社の自動印刷・集配システムなどは、この請負契約型のシステム開発契約によって完成したものが多い。
2番目の委任型システム開発契約（民法第643条）は、発注者がシステム開発行為を行うことを受注者に委託し、受注者がそれを受諾することにより成立する契約である。委任型の開発契約が請負型契約と大きく違うのは、契約で合意したスキルレベルのSEを提供してシステム開発行為を行うことは約束するが、システム開発の成果物の完成は約束しないことだ。そのため発注側にとっては、開発の遅れが直接コスト増に響くほか、最悪の場合はシステムが完成しないリスクまで自ら負わなければならない。逆に受注者側は、失敗リスクを負わないという点で魅力的な契約ではあるが、その分、大きな利益にはつながりにくい。
そしてもう1つが、請負型と委任型を併用した混合契約型のシステム開発契約だ。開発するシステムのうち、開発が難しい部分は請負型契約の対象とし、その部分の開発代金は請負リスクをカバーするに足る高い料金とする。そして、比較的開発が容易でリスクの低い開発部分は委任契約でカバーする契約形態である。発注者にとっては、コストとリスクのバランスがよいというメリットを享受でき、ユーザー企業の満足度を高めやすい。
現在のシステム開発では、請負型や混合型の契約が主流で、受注者であるソリューションプロバイダには、成果物責任のリスク管理が不可欠になる。契約という観点からは、システムの完成に障害が発生したときの原因が発注者側にあるときのリスク回避を忘れてはならない。例えば、要件定義の段階で、ユーザー企業が提出した要望や指示に従って作業したために生じた瑕疵（かし）については、一切責任を負わないという明確な免責をしておかなければならない。意外にこの部分をいいかげんにした契約が少なくない。
常駐スペースを区切って偽装請負の誤解を阻止
請負契約で問題となる「偽装請負」についても触れておきたい。請負契約の形態を取りながら、受託したソリューションプロバイダのSEをユーザー企業に送り込み、ユーザー企業の開発管理者の指揮下で作業すれば、それは偽装請負という違法行為である。職業安定法違反（第44条第9号）や、労働者派遣事業法違反（第5条および第59条2号）を構成し、いずれも1年以下の懲役刑もしくは100万円以下の罰金に処せられる。
通常、システム開発請負の場合には開発作業は受注者側の事業所で行われる場合が多く、その場合は偽装請負と見られるケースは少ない。しかし、発注者側の事業所に受注者側のSEを駐在させ、そこで共同開発作業を行うケースはよくあることで、その場合は、偽装請負と見られないための措置が必要である。
まず発注者側は、受注会社の担当SEに直接指示・命令をするのではなく、受注会社の現場責任者に発注者側の要望を提示する必要がある。そして発注者側の事業所内に常駐する場合は、発注者事業所内の一室もしくは一部を仕切って、請負会社の事業所であることを明示しておくことが偽装請負と誤解されるのを阻止するための効果的な方法だ。請負以外の開発受託の場合も、同様である。
請負契約はかつて、ソューションプロバイダに大きな開発リスクをもたらし、大幅な赤字案件の続出につながった。赤字の要因を分析すると、その多くは、請負代金の見積もりの欠陥や、本来発注者が負担しなければならない要件定義書（仕様書）作成過程に問題がある。次回は、仕様書の問題について解説する。
|
