アジャイルな契約と請負契約の比較
最近注目されているアジャイルな契約が何故請負契約よりも優れていると思われるのか、考えたことをラフなメモ書き。
理解が間違っていたら後で直す。
情報処理推進機構:アジャイル型開発を推進するための活動成果を公開
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
[コラム] Bent Jensen 来日: アジャイル開発に適した契約 ~ ハイブリッド契約の例: TDD.NET
請負契約がソフトウェア開発者を苦しめている: プログラマの思索
再見積もり、Velocity、そしてアジャイルな契約: プログラマの思索
アジャイル開発の契約スタイルに関するIPAの報告書: プログラマの思索
請負契約はFixed price 契約と同じ。
スコープとコストと納期が固定ゆえに、アジャイル開発の特徴であるスコープの変更がやりにくい。
だから、アジャイル開発に向いた契約にするには、委任契約をベースにスコープを柔軟に変更出来る仕組みが必要。
イテレーション単位にリリースしていく開発スタイルを契約に反映させるならば、イテレーション単位に委任契約を結ぶのがいい。
そうすれば、イテレーションが完了するタイミングで、開発対象の機能を入れ替えるのがやりやすくなる。
昨今のようにビジネス環境がすぐに激変する時代では、リリース計画を柔軟に変更でき、急ブレーキ急発進できるアジャイルな契約スタイルの方が向いているのだろう。
実際、IPAが推奨している契約スタイルを読むと、アジャイルな契約は本質的には委任契約であると言える。
例えば、Time and Material 契約はいわゆる工数比例契約、つまり 準委任契約だ。 掛かった工数に比例して支払ってもらうやり方。
AgileJapanの懇親会で原田さんが話されていたインセンティブのある契約も工数契約つまり委任契約だと思う。
実費精算契約も委任契約に相当すると思う。
委任契約の弱点は、成果物の完成責任がないこと。
工数に比例する契約ゆえに、工数がかかるほど受託側は儲かるし、発注側は損をする。
だから、発注側は請負契約をSIと結んで、スコープとコストと納期を固定した契約にし、成果物の完成責任を負わせる。
請負契約が開発者に多大な負担を強いている点は、請負契約がソフトウェア開発者を苦しめている: プログラマの思索に書いた通り、「成果物の完成責任が無限責任にすり替わっている」点と「要員の変動が激しいため動員力のある企業が有利」という点にある。
特に、請負契約でシステム開発が終わった後、普通はリリース後1年間はSIが瑕疵担保責任として、バグが見つかったら無償で直す場合が多い。
だから、1次開発で赤字を覚悟の上で2次開発や運用保守で定期的にお金をもらうビジネスモデルになるので、資金力の無い会社は耐えられないだろう。
資金力の無い中小SIは下請けとして入って要員の変動をなくす。
そこに日本のIT業界特有の多重下請構造が発生する。
また、SI企業に勤務する技術者は裁量労働制の契約を結ぶ時が多いが、その理由の一つは請負契約のプロジェクトに従事する場合が多いからだろう。
委任契約のプロジェクトが多いならば、工数比例契約で労働してもいいからだ。
従って、サービス残業や休日出勤を強いられる時もある。
アジャイルな契約については今後も注視していく。
【追記】
@chomukyuさんと有意義な議論ができたので残しておく。
@chomukyuさん、ご指摘ありがとうございました。
| 固定リンク
「ソフトウェア」カテゴリの記事
- プログラマとスクラムが社会実装を変えていく #Findy_GovTech(2021.03.02)
- TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか(2021.02.15)
- マインドマップをFreeplaneに乗り換えた(2020.11.21)
- ソフトウェアの政治的影響力とは何だろうか(2020.07.07)
- DevOpsがアジャイル開発を促進する(2020.06.11)
「経営・法律・ビジネス」カテゴリの記事
- Clubhouseは路上ライブや朗読のためのツールかもしれない(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- ノートパソコンが入ってUSBポートが付属しているビジネスリュックを買ってみた(2021.03.21)
- プログラマとスクラムが社会実装を変えていく #Findy_GovTech(2021.03.02)
- デブサミ2021の感想~コミュニケーションスタイルがオフラインからオンラインに激変している(2021.02.25)
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
コメント