ソフトウェア開発の契約の話がアツい？

ここ数日のトピックとして、１20年ぶりに民法が改正されたというニュースがあり、それに伴い、様々なサイトで解説記事などが掲載されていました。以下にいくつか挙げておきます。

 

 

また、先月、弊社のお客様であるリーデックス様で、リーダークラスの方を主な対象とした全３回の講習を行ったのですが、そのうちの１回で、契約に関する話が話題となりました。

今回は、そのホットなトピックである、ソフトウェア開発における契約形態について書いていきます。

なお、最初にお断りしておきますが、私自身は法律の専門家ではなく、ソフトウェア開発の専門家ですので、そうした観点での話となることをご承知いただければと思います。

主な契約形態

基本的なもの

ソフトウェア開発に関連する契約形態として最も有名なのは、以下の2つでしょう。

  • 請負契約
  • 準委任契約

これらについての解説は至るところでなされていますし、今回の改正民法によってこの2つの契約形態にどのように影響があるかは、以前書きましたので、ご参考になれば幸いです。

民法改正がITベンダーに与える影響 – もばらぶん

雇用契約

ソフトウェア開発企業が社員を雇う際に締結する「雇用契約」も、広い意味ではソフトウェア開発に関する契約と言えるでしょう。

今までは、通常の正社員としての契約、つまり週5日x8時間＋残業、という形態がほとんどでしたが、近年は多様化してきているのは周知の事実かと思います。

それ以外の契約形態はないのか

詳細な議論はここでは繰り返しませんが、最初に挙げた請負契約及び準委任契約の2つだけで問題ないかというとそうでもなく、世間の要請などに応えて、それ以外の契約形態を模索する会社が増えているようです。

今回は、上の方で紹介した記事でも取り上げた、「10 Contracts For Your Next Agile Project」と、それ以外のいくつかの契約形態について解説していきます。

既存の契約形態の問題点

その前に、既存の請負契約、準委任契約ではどういった問題（あるいは特徴）があるのかについて述べます。

請負契約

大きく分けて、請負契約の問題点は以下の2つです。

  • 契約時に仕様が確定している必要がある
  • 契約後の仕様変更は、（原則としては）追加発注となる

前者により、仕様を事前に確定させないアジャイル開発には向かない契約形態となっています。

また、後者に関しては、「これは仕様の範囲内だ」、「いや、追加仕様だ」というよくあるトラブルにつながる事が多く、発注側と受注側の力関係により、どちらか一方にリスクが乗っかってくるという構造になります。

ソフトウェア開発の本質として、不確定要素が多い事は、アジャイル開発に関する書籍などで度々指摘されていますし、現在のように状況の変化が速い世の中の場合、請負契約をそのまま問題なく適用できるケースが少なくなっていると思います。

準委任契約

準委任契約の問題は、以下の1点に収斂されると思います。

  • いくら払えばシステムが完成するかが事前に分からない

（主に発注側の）プロジェクトマネジメントがしっかりしていないと、お金と時間だけを浪費して何も出来上がらない、という結果になりかねません。

また、受注側は、次回以降の注文を失うリスク、あるいは評判が下がるリスクなどはあるものの、プロジェクトを効率よく進めるインセンティブが若干弱いという点も指摘しておきます。

その他の契約形態についての解説

ここでは、請負契約・準委任契約以外の契約形態について解説していきます。「10 Contracts For Your Next Agile Project」を日本語で解説した、一般社団法人コンピュータソフトウェア協会（CSAJ）の以下の記事と合わせてご参照下さい。（なお、英語の元記事は現在はリンク切れとなっていますので、検索エンジンなどで検索してください。）

1. スプリント契約

これは、「実際の商取引で利用される契約ではなく、スクラムにおいて、プロダクトオーナーと開発チームの間でスプリントごとに交わされる合意（スプリント計画）」のことなので、ここでは説明は省きます。スクラムの関連書籍などをご参照下さい。

2. 定額請負型（Fixed Price & Fixed Scope）

これは、従来型の請負契約の事なので、こちらも説明は省略します。

3. 準委任型（Time and Materials ）

準委任契約の事ですが、特に固定仕様のケースを想定した書き方です。説明は省略します。

4. 固定仕様、シーリングありの準委任契約 （Time and Materials with Fixed Scope and Cost Ceiling）

固定仕様の準委任契約ですが、金額に上限があるケースです。

例えば、以下のような開発プロジェクトを考えます。

  • 時給3000円で開発者を2人割り当てる
  • 月の上限は1人200時間、合計400時間、つまり月に合計120万が上限
  • プロジェクトは6ヶ月で開発終了予定

受注側としては、月に400時間＝120万の上限があるため、その月にやるべき事は、その400時間のうちに収まるように努力しますが、プロジェクトが順調に行って早く終わりすぎると受け取る金額が少なくなるため、早く終わりそうな場合は350時間位かかるように調整するはずですし、6ヶ月の予定が4ヶ月で終わっても困るので、5ヶ月半くらいで一通り全部終わるように進めると思います。

特徴をまとめると以下のとおりです。

  • 発注側のメリットは請負契約より大きい
    • 固定仕様かつ金額に上限が決まっている
    • しかも早く終わった場合には払う金額が少なくて済む
  • 受注側のメリットは少ない
    • 請負契約が持っているリスクはすべて当てはまる
    • それに加えて、早く終わった場合には受け取る金額が少なくなるという新たなリスクがある

以上より、使いどころはほとんど無いと言っていいと思います。

5. シーリングありの準委任契約（Time and Materials with Variable Scope and Cost Ceiling）

仕様（スコープ）は固定ではなく、支払いに上限がある準委任契約です。金額の上限に達するか、発注側が望むシステムが得られた時点でプロジェクトを終了します。

優先順位がタスク・ストーリーから順に開発していくアジャイル開発を想定した形態です。

3の（固定仕様の）準委任契約と比べると、以下のようになります。

  • 発注側
    • 早めにプロジェクトを終了できる点はメリット
    • 金額が上限に達しても、システムが完成していないリスクがあるのは一緒
  • 受注側
    • 早めにプロジェクトが終わるリスクがある
    • 効率良く進めるインセンティブが若干弱いのは一緒

実際に「準委任契約」というと、3よりはこちらを指すことが多いような気がします。発注側にプロジェクト管理能力が求められる契約形態だと思います。

6. 段階的開発契約（Phased Development）

開発を細かいフェーズ（例えば3ヶ月）に分け、各フェーズで固定スコープの準委任契約で進めるというものです。各フェーズで予定のスコープの開発が完了したら、次のフェーズに進めるという仕組みです。

元の記事の Peter Stevens は、この方式を勧めていますが、リスクがフェーズごとに分割されるというメリットはあるものの、本質的には準委任契約と同様の問題があると思います。

受注側は、次のフェーズの契約を得るために、各フェーズのスコープ分の開発を終わらせるインセンティブがあるのは確かですが、仮に予定のスコープの開発が終わらなかった場合に、別のベンダーに切り替えることが出来るかというと現実的には難しいと思うので、普通の準委任契約に比べて大幅に望ましいかというと、そうではないと思います。

7. ボーナス／ペナルティ条項（Bonus/Penalty Clauses）

固定スコープの請負契約ですが、早く開発が終わったらボーナスを、逆に遅くなったらペナルティを課す契約です。

CSAJによる日本語の解説記事は、アジャイル開発が前提となっているので、この契約形態は使いづらいですが、アジャイル開発に限定しなければそれなりにメリットはあると思います。

この契約形態が有効となる前提としては、以下の点が挙げられます。

  • 発注側にとって早く開発を終わらせる理由がある（競合サービスがある、等）

受注側にとっては、早く終わらせればボーナスがもらえますし、早く終わって余った時間は、人員を別のプロジェクトに回すことができますので、メリットが大きいと思います。

8. 固定利益（Fixed Profit）

これは4の派生系のようなもので、ある上限に達するまでは準委任契約と同じですが、その上限以降は、受注側の利益は増えない仕組みです。

時給3000円で月の上限150時間（月に最大45万）の例を考えます。この仕事を、月給30万の開発者（≒時給2000円）に担当させるとすると、月150時間に達した場合は、受注側の粗利は15万円です。問題は、月150時間の上限を超えた場合ですが、「固定利益」なので、受注側の利益は15万円のままとなるように、つまり150時間超過分は支払金額が時給2000円となります。

CSAJの解説では「スティーブンスはこの契約について、顧客、開発側の両者に早期完了のインセンティブがあると述べているが、売上高を重視する日本の企業を考えると、開発側に早期完了のインセンティブがあるとは思えない。」と書いてありますが、まさにここで書かれているように、受注側が売上高を重視するかどうか、がこの契約形態を選ぶポイントになるかと思います。

受注側にとって、沢山プロジェクトがあって選べる状況であれば、利益率が高いプロジェクトを選ぶ事になりますので、この契約形態のプロジェクトの上限時間を過ぎた場合は、早めに終わらせて他のプロジェクトに移るインセンティブがあると思います。

9. Money for Nothing, Changes for Free

CSAJの解説記事から引用します。

基本は、スコープの変更が可能で、予算上限のある準委任（実費清算型）契約であるが、早期完了（あるいはプロジェクト中止）になった場合には、開発側は、キャンセル料として残余期間で開発側が得べかりし利益分を受け取る権利がある（図3参照）。つまり、どの時点でプロジェクトが完了、あるいは中止になったとしても開発側が得られる利益は一定となる。

ポイントは「どの時点でプロジェクトが完了、あるいは中止になったとしても開発側が得られる利益は一定となる。」という点です。受注側としては、早く終わらせるインセンティブがありますし、発注側も早く終わった場合の支払いは少なくて済みます。

こちらを選ぶポイントは、8と正反対で、受注側が利益を重視するかどうかがポイントです。

また、8もそうですが、この契約形態を選ぶ場合には、コスト構造（つまり時給2000円の開発者が従事している）を明らかにする必要があります。

10. ジョイントベンチャー（Joint Venture）

これは、一般的なソフトウェア開発には適用できないと思うので、説明は省略します。

派生系

8, 9 の、「利益一定」というのは厳密に行う必要はなく、要は早めに終わっても受注側の利益が少なくならなければいいので、例えば月150時間で6ヶ月くらい（＝合計900時間）を完了見込みとしているプロジェクトの場合、一律時給3000円にするのではなく

  • 最初の450時間は時給3500円
  • 次の450時間以降は時給2500円

という大雑把な方式でも、900時間でプロジェクトが終われば平均時給3000円で、それ以降は利益率が下がりますので、受注側が早く終わらせるインセンティブにはなると思います。

まとめ

ソフトウェア開発に関する契約にの基本は、請負契約と準委任契約ですが、いろんなバリエーションがありますので、自社の置かれた立場やプロジェクトの性質などを考慮して、最適な契約形態を選ぶと、発注側も受注側も満足の行くソフトウェア開発になるのではないかと思います。

ソフトウェア開発に関するご相談は、以下のリンクよりお願いいたします。

お問い合わせフォーム