アジャイル開発は準委任契約の方が請負契約より上手くいく

こんにちは、mofmofのエンジニア兼代表の原田です。

今回は、システム開発を受発注する際に必ず考えなければならない契約形態、準委任契約請負契約について書いていきます。

準委任契約と請負契約の違い

それぞれの契約形態の違いは、ものすごく分かりやすく言えば、請負契約には成果物の完成責任があり、準委任契約にはありません。成果物の完成責任があるということは、民法上の言葉で言い換えれば契約不適合の完遂責任があるということです。

請負契約では成果物を完成させて納める義務があり、成果物に対して報酬が決められるのに対し、準委任契約では1ヶ月で○○万円などのように、労働期間に対して報酬が決められます。

一般的な認識として、成果物の完成責任がない分、準委任契約は発注者にとって不利な契約形態だと認識されています。しかし本当にそうなのでしょうか?

細かい定義の解説はこの記事では割愛するので、詳しく知りたい方は下記記事などを参照ください。

アジャイル開発をするなら準委任契約にすべき

結論から言うと、アジャイル開発をするなら受発注側共に準委任契約を選択した方が良いです。一見発注側に不利に見える契約でも、結果的に良い成果物になる可能性が高くなります。

IPA(情報処理推進機構)でも、アジャイル開発では請負契約ではなく準委任契約を前提としてモデル契約書を公開しており、弊社で受注する際にもこのモデル契約書を活用しています。

アジャイル開発版「情報システム・モデル取引・契約書」~ユーザ/ベンダ間の緊密な協働によるシステム開発で、DXを推進~

システムの開発は、非常に複雑で抽象的で実に多くの不確実性を含み、プロジェクトを進めるにつれて当初予定していなかった事柄が無数に出現します。どれだけ熟練したプロジェクトマネージャでも全てを予見し対処することなど到底不可能です。

そのような特性がある中で成果物の完成責任のある請負契約を選択してしまうと、未知の事象に対処する術を失ってしまい、以下のような問題を引き起こします。

  • プロジェクト後期に、仕様とバグの線引きで揉めて責任のなすりつけあいに発展する
  • 開発工程が分断されているため、ユーザー目線を失ったシステムが作られてしまう
  • 作るものが予め細かく定義されるため、前工程に戻って修正することがしづらい

参照: なぜ月額制が良いのか | 月額制受託開発の株式会社mofmof

請負契約でアジャイル開発をした失敗事例

書き込まれたホワイトボード

ぼくがmofmof inc.を立ち上げるよりも前の時期に起こった失敗事例で、とある業務システムの開発を受注した時の話です。

当時、アジャイル開発の駆け出しだったぼくは、まずはアジャイル開発の基本的プラクティスの一つ「スプリント」(イテレーションとも言う)を導入することからはじめました。

従来のウォーターフォール型開発では、年単位のプロジェクト規模で、最初の数ヶ月〜数年単位で1つずつ工程を進めていくのに対して、1週間〜1ヶ月くらいの短いスパンを1サイクルとして設計〜開発〜検証を行い、それを繰り返していく手法です。

これにより、プロジェクト進行中に発覚した未知の出来事に対して機動的に対処出来るようになるというメリットがあります。

これを一般的な請負契約の中でやるとどうなるでしょうか?

結果は、仕様変更を繰り返し続けることは出来るが、納期目前になって本来作るべきだった機能開発が出来ておらず、不具合もたくさん残った状態で、どうにか納品を達成するために突貫工事する羽目になりました。

なんとか動くものには仕上がりましたが、突貫工事だったため随所に不安を抱えながらも引きわすことになってしまいました。

この問題には2つ原因があります。1つは、機動的に仕様変更を受け入れることを優先しプロジェクトの進行管理を疎かにしてしまったこと。もう1つは、仕様変更を受け入れているのにも関わらず、最初に取り決めした開発範囲を動かせなかったことです

つまり請負契約で成果物の定義をして、その責任を負ってしまった以上、その通りに納品しなければならず、仕様変更を受け入れた分は単に工数上乗せになり自分の首を締めてしまっていたのです。

DXとアジャイル開発

以前にDX(デジタル・トランスフォーメーション)に関する記事を書きました。

経済産業省のデジタルトランスフォーメーションに向けた研究会の議事要旨から抜粋すると、日本におけるシステム開発の手法についての課題が言及されています。

・責任は全てベンダー側にあると判断されるような状況下では、レガシー化 しているシステムの刷新は、ベンダー側のリスクが高すぎて負いきれな い。

・デザイン思考やアジャイルなど様々な要素を取り入れ始めているが、米国 と比較すると日本の遅れを感じる。

請負契約はベンダー側に多くの責任を負わせる契約形態です。日本のシステム開発業界は商慣習上この契約形態を用い続けてきました。その結果多くの失敗事例を生み出し、諸外国に遅れをとり続ける結果になりました。

請負契約では発注側は成果物の定義さえきっちり完遂してさえいれば、あとは望んだ成果物が納品されると考えられるため、プロセスをシンプルに出来ます。

しかし実際には、両者が責任を共有し、未知の問題に協力的に対処していく体制を構築出来なければアジャイル開発は上手くいきません。

最も大切なことは、真に価値のある成果物を生み出すことです。そのために必要なのは、責任のなすりつけ合いではなくプロダクトを良くするための話し合いであり、当初の仮説を墨守することではなく変化を恐れず仮説検証を繰り返すことです。

そしてその後ろ盾となってくれるのが準委任契約なのです。

準委任契約での月額制開発サービス「開発チームレンタル」に興味を持ちましたらお気軽にご相談いただければと思います。

リーンキャンバス テンプレート

あなたのビジネスの構造がわかる 一枚のテンプレート【無料】

ダウンロード →
インセプションデッキ テンプレート

インセプションデッキの要点を解説 テンプレート付き実践ガイド【無料】

ダウンロード →
記事の作成者・監修者
原田 敦
-
Atsushi Harada
CEO / エンジニア
「作って人をしあわせにする」ことがミッション。多くの人を幸せにするプロダクトを世に送り出すことが、クリエイターにとって至上の幸せだと思ってます。デスマを憎んで人を憎まず。よりよいソフトウェアは、よりよいチームから生まれると思ってます。
記事の作成者・監修者
原田 敦
-
Atsushi Harada
CEO / エンジニア
「作って人をしあわせにする」ことがミッション。多くの人を幸せにするプロダクトを世に送り出すことが、クリエイターにとって至上の幸せだと思ってます。デスマを憎んで人を憎まず。よりよいソフトウェアは、よりよいチームから生まれると思ってます。