契約ソフトウェア開発の契約の話がアツい?ここ数日のトピックとして、120年ぶりに民法が改正されたというニュースがあり、それに伴い、様々なサイトで解説記事などが掲載されていました。以下にいくつか挙げておきます。契約ではなく利用規約の話ですが。IT企業のインターネット法務、法律に強い弁護士|中野秀俊また、先月、弊社のお客様であるリーデックス様で、リーダークラスの方を主な対象とした全3回の講習を行ったのですが、そのうちの1回で、契約に関する話が話題となりました。今回は、そのホットなトピックである、ソフトウェア開発における契約形態について書いていきます。最初にお断りしておきますが、私自身は法律の専門家ではなく、ソフトウェア開発の専門家ですので、そうした観点での話となることをご承知いただければと思います。これらについての解説は至るところでなされていますし、今回の改正民法によってこの2つの契約形態にどのように影響があるかは、以前書きましたので、ご参考になれば幸いです。ぶん雇用契約ソフトウェア開発企業が社員を雇う際に締結する「雇用契約」も、広い意味ではソフトウェア開発に関する契約と言えるでしょう。今までは、通常の正社員としての契約、つまり週5日x8時間+残業、という形態がほとんどでしたが、近年は多様化してきているのは周知の事実かと思います。それ以外の契約形態はないのか詳細な議論はここでは繰り返しませんが、最初に挙げた請負契約及び準委任契約の2つだけで問題ないかというとそうでもなく、世間の要請などに応えて、それ以外の契約形態を模索する会社が増えているようです。Project」と、それ以外のいくつかの契約形態について解説していきます。いった問題(あるいは特徴)があるのかについて述べます。大きく分けて、請負契約の問題点は以下の2つです。契約時に仕様が確定している必要がある契約後の仕様変更は、(原則としては)追加発注となる前者により、仕様を事前に確定させないアジャイル開発には向かない契約形態となっています。後者に関しては、「これは仕様の範囲内だ」、「いや、追加仕様だ」というよくあるトラブルにつながる事が多く、発注側と受注側の力関係により、どちらか一方にリスクが乗っかってくるという構造になります。問題は、以下の1点に収斂されると思います。払えばシステムが完成するかが事前に分からない(主に発注側の)プロジェクトマネジメントがしっかりしていないと、お金と時間だけを浪費して何も出来上がらない、という結果になりかねません。受注側は、次回以降の注文を失うリスク、あるいは評判が下がるリスクなどはあるものの、プロジェクトを効率よく進めるインセンティブが若干弱いという点も指摘しておきます。契約形態について解説していきます。Project」を日本語で解説した、一般社団法人コンピュータソフトウェア協会(CSAJ)の以下の記事と合わせてご参照下さい。(なお、英語の元記事は現在はリンク切れとなっていますので、検索エンジンなどで検索してください。スプリント契約これは、「実際の商取引で利用される契約ではなく、スクラムにおいて、プロダクトオーナーと開発チームの間でスプリントごとに交わされる合意(スプリント計画)」のことなので、ここでは説明は省きます。スクラムの関連書籍などをご参照下さい。Scope)これは、従来型の請負契約の事なので、こちらも説明は省略します。)準委任契約の事ですが、特に固定仕様のケースを想定した書き方です。Ceiling)固定仕様の準委任契約ですが、金額に上限があるケースです。以下のような開発プロジェクトを考えます。しては、月に400時間=120万の上限があるため、その月にやるべき事は、その400時間のうちに収まるように努力しますが、プロジェクトが順調に行って早く終わりすぎると受け取る金額が少なくなるため、早く終わりそうな場合は350時間位かかるように調整するはずですし、6ヶ月の予定が4ヶ月で終わっても困るので、5ヶ月半くらいで一通り全部終わるように進めると思います。特徴をまとめると以下のとおりです。発注側のメリットは請負契約より大きい固定仕様かつ金額に上限が決まっているしかも早く終わった場合には払う金額が少なくて済む受注側のメリットは少ない請負契約が持っているリスクはすべて当てはまるそれに加えて、早く終わった場合には受け取る金額が少なくなるという新たなリスクがある以上より、使いどころはほとんど無いと言っていいと思います。Ceiling)仕様(スコープ)は固定ではなく、支払いに上限がある準委任契約です。金額の上限に達するか、発注側が望むシステムが得られた時点でプロジェクトを終了します。優先順位がタスク・ストーリーから順に開発していくアジャイル開発を想定した形態です。3の(固定仕様の)準委任契約と比べると、以下のようになります。実際に「準委任契約」というと、3よりはこちらを指すことが多いような気がします。発注側にプロジェクト管理能力が求められる契約形態だと思います。Development)開発を細かいフェーズ(例えば3ヶ月)に分け、各フェーズで固定スコープの準委任契約で進めるというものです。各フェーズで予定のスコープの開発が完了したら、次のフェーズに進めるという仕組みです。この方式を勧めていますが、リスクがフェーズごとに分割されるというメリットはあるものの、本質的には準委任契約と同様の問題があると思います。受注側は、次のフェーズの契約を得るために、各フェーズのスコープ分の開発を終わらせるインセンティブがあるのは確かですが、仮に予定のスコープの開発が終わらなかった場合に、別のベンダーに切り替えることが出来るかというと現実的には難しいと思うので、普通の準委任契約に比べて大幅に望ましいかというと、そうではないと思います。Clauses)固定スコープの請負契約ですが、早く開発が終わったらボーナスを、逆に遅くなったらペナルティを課す契約です。CSAJによる日本語の解説記事は、アジャイル開発が前提となっているので、この契約形態は使いづらいですが、アジャイル開発に限定しなければそれなりにメリットはあると思います。この契約形態が有効となる前提としては、以下の点が挙げられます。発注側にとって早く開発を終わらせる理由がある(競合サービスがある、等)受注側にとっては、早く終わらせればボーナスがもらえますし、早く終わって余った時間は、人員を別のプロジェクトに回すことができますので、メリットが大きいと思います。Profit)これは4の派生系のようなもので、ある上限に達するまでは準委任契約と同じですが、その上限以降は、受注側の利益は増えない仕組みです。時給3000円で月の上限150時間(月に最大45万)の例を考えます。この仕事を、月給30万の開発者(≒時給2000円)に担当させるとすると、月150時間に達した場合は、受注側の粗利は15万円です。問題は、月150時間の上限を超えた場合ですが、「固定利益」なので、受注側の利益は15万円のままとなるように、つまり150時間超過分は支払金額が時給2000円となります。CSAJの解説では「スティーブンスはこの契約について、顧客、開発側の両者に早期完了のインセンティブがあると述べているが、売上高を重視する日本の企業を考えると、開発側に早期完了のインセンティブがあるとは思えない。」と書いてありますが、まさにここで書かれているように、受注側が売上高を重視するかどうか、がこの契約形態を選ぶポイントになるかと思います。受注側にとって、沢山プロジェクトがあって選べる状況であれば、利益率が高いプロジェクトを選ぶ事になりますので、この契約形態のプロジェクトの上限時間を過ぎた場合は、早めに終わらせて他のプロジェクトに移るインセンティブがあると思います。FreeCSAJの解説記事から引用します。基本は、スコープの変更が可能で、予算上限のある準委任(実費清算型)契約であるが、早期完了(あるいはプロジェクト中止)になった場合には、開発側は、キャンセル料として残余期間で開発側が得べかりし利益分を受け取る権利がある(図3参照)。どの時点でプロジェクトが完了、あるいは中止になったとしても開発側が得られる利益は一定となる。ポイントは「どの時点でプロジェクトが完了、あるいは中止になったとしても開発側が得られる利益は一定となる。受注側としては、早く終わらせるインセンティブがありますし、発注側も早く終わった場合の支払いは少なくて済みます。こちらを選ぶポイントは、8と正反対で、受注側が利益を重視するかどうかがポイントです。8もそうですが、この契約形態を選ぶ場合には、コスト構造(つまり時給2000円の開発者が従事している)を明らかにする必要があります。Venture)これは、一般的なソフトウェア開発には適用できないと思うので、説明は省略します。次の450時間以降は時給2500円という大雑把な方式でも、900時間でプロジェクトが終われば平均時給3000円で、それ以降は利益率が下がりますので、受注側が早く終わらせるインセンティブにはなると思います。まとめソフトウェア開発に関する契約にの基本は、請負契約と準委任契約ですが、いろんなバリエーションがありますので、自社の置かれた立場やプロジェクトの性質などを考慮して、最適な契約形態を選ぶと、発注側も受注側も満足の行くソフトウェア開発になるのではないかと思います。ソフトウェア開発に関するご相談は、以下のリンクよりお願いいたします。お問い合わせフォーム共有:メールアドレス印刷TweetBookmarkEvernotePocketkashima株式会社もばらぶの代表です。コメントをキャンセルメールアドレスが公開されることはありません。↑もばらぶんをもっと見る今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。