溜池随想録 #15 「アジャイルソフトウェア開発に適した契約（その１）」　（2010年8月）

請負契約の限界

　一般的に情報システムの開発で用いられる契約は、準委任契約と請負契約である。経済産業省が2007年に公開したモデル取引・契約書＜第一版＞は、ウォーターフォール型開発を前提として、外部設計までは原則として準委任契約、内部設計からソフトウェアテストは請負契約、システムテストから運用・保守の段階は準委任契約を基本としている（図参照）。

　ただし、実態は外部設計からシステムテストまでを一括にして請負契約にしている例が多いと言われている。
　問題は、この請負契約がアジャイルソフトウェア開発に適していないという点にある。

　そもそも、民法によれば、請負契約は「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる」契約である。簡単に言えば、仕事が完了したら報酬を支払う契約である。逆に言えば、仕事が完了していなければ、報酬は支払わなくてよい。それが請負契約である。
では仮に、仕事を請け負った側が、仕事が完成したので報酬を支払うように要求し、仕事を頼んだ側が、仕事は完成していないから報酬は支払う必要がないと主張した場合はどうなるのだろうか。最悪の場合、裁判になり、第三者によって仕事が完成しているかどうかを判定することになる。したがって、第三者によって「仕事の完成」が判断できないものは請負契約になじまない。

　一方、アジャイルソフトウェア開発の最大の特徴は、要求仕様を固定しないで開発を開始するところにある。時間の経過とともに変化する顧客や市場のニーズに応えようとするのだから当然である。
つまり、契約時に仕様を固定できないアジャイルソフトウェア開発の場合、請負契約はなじまないということになる。
 

社内開発という道

　それでは、準委任契約はどうだろう。民法では、「当事者の一方が何らかの行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる」契約が委任契約である。ちなみに、法律行為を対象とするものを「委任」、法律行為でない行為を対象とするものを「準委任」と呼ぶ。
　この契約では、仕事の完成は求められない。何かの行為（作業）をすることが報酬の支払い条件となる。

　アジャイルソフトウェア開発の場合、開発すべき要件がなくなるまでイテレーションを繰り返すので、一見、この準委任契約で問題ないように見える。発注側が、システムが完成したと判断した時点で開発を終了し、その時点までの作業量に応じて報酬を払えばよい。
　しかし、もし、開発側が悪意をもって開発期間の引き伸ばしを図った場合は、その報酬は本来あるべき水準より高くなってしまう。悪く言えば、ダラダラと働いた方が報酬が増えるのである。
　もちろん、そんな悪意のある業者が多いと言っているわけではない。継続的な取引や風評を考えれば、開発期間を不必要に引き伸ばそうという業者は少ないだろう。しかし、その危険性はゼロではない。

　また、開発側に悪意がなくても、生産性を上げて、開発を早く終わらせるというモチベーションが生まれなくなってしまう。
　この危険性を小さくするには、プロジェクト管理を発注側がきちんと行うとよい。つまり、発注側が主導権をもってシステム開発を行うことが一つの解決策になる。極端に言えば、システム開発を外注するという発想ではなく、社内で開発する（インハウス開発）という考え方が望ましい。実際、アジャイルソフトウェア開発は、社内開発における利用事例が多い。
 

新しい契約モデルの可能性

　ただ、アジャイルソフトウェア開発を採用する場合には、すべて社内開発でというわけには行かない。日本ではやはりソフトウェア開発をアウトソーシングする企業が多い。
　民法には、13種類の契約が規定されている。これを典型契約という。実際に社会で用いられている契約の多くは、この典型契約に基づいている。しかし、民法で典型契約以外の契約を禁じているわけではない。公序良俗に反しない限り、新しい契約モデルをつくり、それに従って契約しても構わない。たとえば、パッケージソフトによく用いられるソフトウェアの使用許諾契約は典型契約外の契約である。
　民法に規定された典型契約が、アジャイルソフトウェア開発に適していないのであれば、新しい契約モデルを考えればよい。発注側と開発側がそれぞれ納得でき、より優れたシステムをより早く完成させようというインセンティブが働く契約が望ましい。
 
　次回も、引き続きアジャイルソフトウェア開発に適した契約について考えてみたい。