アジャイルな契約と請負契約の比較

最近注目されているアジャイルな契約が何故請負契約よりも優れていると思われるのか、考えたことをラフなメモ書き。
理解が間違っていたら後で直す。

【元ネタ】
Twitter / @akipii: その資料が是非見たい！委任契約と請負契約以外の選択肢はあるかな？ RT @haradakiro: アジャイル契約のプレゼン資料つくってたら、ウォーターフォール成立の歴史だけで時間を使い尽くしそうな勢い。

Twitter / @haradakiro: @akipii 発表前なのでちょっとお待ちを、というかまだできていないww 「次のアジャイルソフトウェアプロジェクトに使える10の契約」はご存知でしたか？ http://bit.ly/93lTtB 自分の話は、三者契約によってリスクと責任を分散させる話です。

Twitter / @akipii: @haradakiro 知らないので読んでみます。委任契約と請負契約の制約を誰かぶち壊して欲しいです。WF型開発と多重請負の源泉だから。アジャイル開発がアジャイルごっこになってしまうから。

情報処理推進機構：アジャイル型開発を推進するための活動成果を公開

翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約

[コラム] Bent Jensen 来日: アジャイル開発に適した契約 ～ ハイブリッド契約の例: TDD.NET

請負契約がソフトウェア開発者を苦しめている: プログラマの思索

再見積もり、Velocity、そしてアジャイルな契約: プログラマの思索

アジャイル開発の契約スタイルに関するIPAの報告書: プログラマの思索

請負契約はFixed price 契約と同じ。
スコープとコストと納期が固定ゆえに、アジャイル開発の特徴であるスコープの変更がやりにくい。
だから、アジャイル開発に向いた契約にするには、委任契約をベースにスコープを柔軟に変更出来る仕組みが必要。

イテレーション単位にリリースしていく開発スタイルを契約に反映させるならば、イテレーション単位に委任契約を結ぶのがいい。
そうすれば、イテレーションが完了するタイミングで、開発対象の機能を入れ替えるのがやりやすくなる。
昨今のようにビジネス環境がすぐに激変する時代では、リリース計画を柔軟に変更でき、急ブレーキ急発進できるアジャイルな契約スタイルの方が向いているのだろう。

実際、IPAが推奨している契約スタイルを読むと、アジャイルな契約は本質的には委任契約であると言える。
例えば、Time and Material 契約はいわゆる工数比例契約、つまり 準委任契約だ。 掛かった工数に比例して支払ってもらうやり方。
AgileJapanの懇親会で原田さんが話されていたインセンティブのある契約も工数契約つまり委任契約だと思う。
実費精算契約も委任契約に相当すると思う。

委任契約の弱点は、成果物の完成責任がないこと。
工数に比例する契約ゆえに、工数がかかるほど受託側は儲かるし、発注側は損をする。
だから、発注側は請負契約をSIと結んで、スコープとコストと納期を固定した契約にし、成果物の完成責任を負わせる。

請負契約が開発者に多大な負担を強いている点は、請負契約がソフトウェア開発者を苦しめている: プログラマの思索に書いた通り、「成果物の完成責任が無限責任にすり替わっている」点と「要員の変動が激しいため動員力のある企業が有利」という点にある。
特に、請負契約でシステム開発が終わった後、普通はリリース後１年間はSIが瑕疵担保責任として、バグが見つかったら無償で直す場合が多い。
だから、１次開発で赤字を覚悟の上で２次開発や運用保守で定期的にお金をもらうビジネスモデルになるので、資金力の無い会社は耐えられないだろう。
資金力の無い中小SIは下請けとして入って要員の変動をなくす。
そこに日本のIT業界特有の多重下請構造が発生する。

また、SI企業に勤務する技術者は裁量労働制の契約を結ぶ時が多いが、その理由の一つは請負契約のプロジェクトに従事する場合が多いからだろう。
委任契約のプロジェクトが多いならば、工数比例契約で労働してもいいからだ。
従って、サービス残業や休日出勤を強いられる時もある。

アジャイルな契約については今後も注視していく。

【追記】
@chomukyuさんと有意義な議論ができたので残しておく。
@chomukyuさん、ご指摘ありがとうございました。

Twitter / @chomukyu: @akipii こんにちは。システムの「完成形」を決めずに育てていくアジャイルでは、瑕疵と仕様変更を区別しようとする請負契約は向かなさそうですね。受託側が保証するとすれば、ベロシティでしょうか？ RT: アジャイルな契約と請負契約の比較

Twitter / @akipii: @chomukyu こんばんは。顧客の観点ではVelocity(開発規模)を保証されても、そのコストは工数ベースですか？成果物ベースですか？と質問されると思います。「成果物の完成責任」「瑕疵担保責任」が結局ボトルネックになると思うのです。

Twitter / @chomukyu: アジャイルではシステムの完成形を決めないので、瑕疵担保という考え方とは相性が悪そう。かといって、バグだらけでもOKとは発注側も言えない。とすると、落とし所はベロシティ保証？　という発想に。

Twitter / @chomukyu: でも、事前にベロシティを保証することも難しいので、契約単位を短くして「気に入らなければ切ってください」という倉貫さん方式か、「システムを使っている間だけ支払ってください」という平鍋さん方式になっていると理解してます。

Twitter / @chomukyu: @akipii 顧客のことを考えれば、成果物視点（ストーリーポイント単位など）になるでしょうね。ただし事前に保証することも難しいので、倉貫さんも平鍋さんも「気軽に使ってみて駄目だったら切ってください」という仕組みにしているんだと想像しています。

Twitter / @akipii: @chomukyuさんが仰る通り「気軽に使ってみて駄目だったら切ってください」という仕組みにならざるを得ないと思います。そのビジネスモデルはパッケージ製品やWebサービスなら自社で制御できるのでやりやすい。受託開発の請負契約はアジャイル開発にとって鬼門だと思います。

Twitter / @chomukyu: @akipii ちょっと視点を変えると、成果物責任や瑕疵担保責任は「あるべき成果物の姿」がないと定義不能なので、それらの責任を要求される時点で、アジャイルとしては詰みな気もします。『アジャイル契約でひどい目にあった話256』とか出版されたら、一万円くらいでも買うんですがｗ

Twitter / @akipii: @chomukyu なるほど、アジャイル開発では「あるべき成果物の姿」は未確定(常に変化)なので請負契約における「あるべき成果物の完成責任」を果たすのは元々無理ですね。一つ理解できました。ありがとうございました。