システム開発で請負か準委任、どちらを選択すべきか、その基準はなんであろうか
営業とのやりとり
先日、こんなやりとりをすることがあった。（実際の話とは変えている）
営業「こんな仕様での処理をするシステムの開発を請け負います。お客さんにはこんな内容で説明しています。」
私「はいわかりました。その内容で契約書案を確認します。」
で、契約書の確認は終わった。
数日後、この営業からこんな話があった。
営業「あの開発、アジャイルらしくてサンプルで提示してフィードバックを受けて修正して仕様を決めていくらしいです。」
２番目の話を聞いて思ったこと
この契約書は顧客に提示していた資料を参照する形になっていた。
資料には仕様が確定しているように読めるような記載になっており、小さな規模の開発であったので私はこの資料に記載されている仕様通りに作る（完成させる）ことを約束する契約であると捉えて確認していた。
しかし、実際は仕様は確定していなかったのである。
しかも「アジャイル」というワードが出てきてきたため、「請負契約でよかったのか？」という疑念（焦り）が生じたのである。
システム開発の契約責任論
システム開発の契約書を確認する際、私は開発の不確実性がどこにどの程度あるのかを特に気にして確認している。
最も着目するのは開発物の仕様がどの程度決まっているか、開発の難易度はどこが高いか、見通せていない事項はあるか、である。
一方で、システム開発において仕様（機能要件、非機能）の詳細は契約時に決まっていることはほぼない。実際は打ち合わせを経ながら決まっていくことがほとんどである。
「仕事の完成」を約する請負契約において、この契約時点に仕様が決まっていることがほぼないことは、字面通りに捉えると「（固定報酬かつ納期を決めておきながら）何を作ればいいかの詳細は決まっていないが完成を約束する」というリスクをベンダーが抱えるように捉えられる。
システム開発契約は、それでも請負契約として締結されてきた。
裁判例の蓄積により、システム開発の中で完成をめぐる法的責任は建築請負契約の法理論を踏襲し、契約の本旨（報酬請求権の発生、債務不履行責任の発生契機）は「システムの完成」とし、完成後に生じる契約不適合責任（瑕疵担保責任）は「完成されたシステムの明示／当然備えるべき仕様との不一致」に関する責任であるとされてきた。
準委任契約によるアジャイル開発とIPA解説の「内容の特定」の意味とは？
IPAのアジャイル開発契約には、以下の説明がなされている。
（詳細は以前書いた「アジャイル開発契約は契約不適合責任を負うか？」を参照されたい）
アジャイル開発の特徴からすれば、あらかじめ内容が特定された成果物を予定したとおりに完成させることに対して対価を払う請負契約よりも、業務を受託したベンダ企業が専門家としての注意義務を果たしながら業務を遂行することそれ自体に対価を支払う準委任契約の方が馴染み易いと考えられる。
ここで、私は「あらかじめ内容が特定された」を「（詳細とは言えないまでも）ある程度備えるべき仕様が決まっている状態」であると捉えていたわけである。
しかし、よく考えればウォーターフォール型であろうと契約時にも詳細仕様は決まっていないし、一方でアジャイル型であってもある程度の開発物の見込みは決まっている（そうでないと見積もりも出せない）のだから、「内容が特定」とは何をいうのであろうか、という疑問が湧いたのである。
前述のとおり、ウォーターフォール型のシステム開発であっても、開発請負契約時に詳細仕様は決まっていないことは多く、例え開発工程前に要件定義工程を挟んでいたとしても（要件と仕様は違うのであるが）、契約締結後にシステムの要件・詳細仕様を変更することはざらにある。
すなわち、フォーターフォール型の開発であっても、契約締結時において仕様は確定しているとは言い切れない（というか多くの場合決まっていない）のである。
そのため、システム開発契約・紛争の専門家と大手ベンダーが参加して作られたモデル契約においてIPAのアジャイル開発モデル契約のいう「内容の特定」が「仕様の確定」とは考えていないはずなのである。
ここで、（理想的な）アジャイル開発の実態を考えてみる。
アジャイル開発はバックログに様々な要望を列記しておき、開発の中でそれを整理、優先度の整理をして、実際にプログラムを作成しながら確認・フィードバックしてリリースし、改善していく。
バックログは「必ず完成させなければならない要件リスト」ではない。
また「バックログ全体が対象にするのは１つのシステム」とも言い切れない。言い方が難しいが、それぞれ独立してリリース・動作する複数の機能・アプリケーションに対する要件が混在することもある（スプリントの中でそれがはっきりすることもある）。
ゆえに、仕様は当然として、「どのような機能・アプリケーションを作るべきか」すら決まっていない。
バックログを整理した結果、A、B、Cの３つの機能（を実現するシステム）を作る必要があるとなったとしても、全てを作るべきかすら決まっていない。
では、IPAの「内容が特定された成果物」とはどの粒度の話であろうか。
想定するシステム開発を示しているであろうアジャイルモデル契約の別紙には以下のような例が示されている。
1. 本プロジェクト
現在、甲の営業部門において使用している営業日報作成・管理のシステムは、10 年以上前に開発されたもので、社内の PC からしか使用できず、インターフェイスも使いにくい。営業日報には営業が集めてきた様々な情報が含まれているが、検索性が低いために単なる記録にとどまっており、情報を組織として十分活用できていない。 本プロジェクトでは、従来のシステムに代わる新たなシステムを開発する。新システムでは、スマートフォンからも使用できるようにし、営業担当者らの意見を聞きながら、インターフェイスや検索性を改善して、情報をより組織的に活用できるようにする。
2. 開発対象プロダクト
甲の営業部門において使用する営業日報作成・管理システム （サーバアプリケーション、モバイルアプリケーション、データべース、クラウド環境を含む。）
この記述からは、最終的な開発物は「営業日報作成・管理システム」であり、具体のプログラムとしてサーバアプリケーション等まで言及されている。
個人的には、これだけ捉えると「内容が特定されていない」とは直感的には捉えづらい。
「営業担当者らの意見を聞きながら」とあるが、これだけではアジャイルを特徴づけるとは言えない。
結局のところ、モデル契約においてはウォーターフォールを前提にした請負開発契約とのはっきりした違いは、以下の記述の差異しか見いだせないように思う。
第 5 条（乙の義務）
1. 乙は、情報処理技術に関する専門知識及びノウハウに基づき、善良な管理者の注 意をもって、本件業務のうち自らの担当業務を行う。なお、甲及び乙は、本契約は準委任契約であり、乙が開発対象プロダクトの完成義務を負うものではないことを確認する。
アジャイル開発という言葉を信じて準委任契約を提示してよいか
ここまで見たように、請負契約か準委任契約かを分ける「内容の特定」の具体的な線引ははっきりしない。
ということは開発現場の「アジャイル開発手法を採用する」という言葉を頼りに請負契約か準委任契約かいずれを選択すべきかを判断するしかないということにもなる。
しかし、現場の「アジャイル開発」という言葉を信じていいかはケースバイケースである。
冒頭の例にあるように、顧客に提示した資料には開発物もその仕様も確定しているかのような説明をしている。
これにも関わらず開発現場の言葉を信頼して準委任型の契約書を提示したとき、顧客から「仕様は確定しているから請負契約であるべきである」という反論がなされる可能性がある。
何をもって完成を約束できるかどうかを判断すべきか
請負契約は仕事の完成を約する契約であるので、完成が約束できるならば請負、そうでないならば準委任を選択すべきとなる。
しかし、開発現場にアジャイルかどうかという手法ではなく「求めている開発物の完成を約束することに不安はないか」と問うたところで、開発現場は「不安はないかと言われればある」と答えるに決まっている（むしろ自信満々に「不安はない」という現場だったら見通しに不安を覚える）。
さて、堂々巡りで答えが出ないので裁判例を見てみよう（松尾剛行・西村友海「紛争解決のためのシステム開発法務」を参考）。
・プロトタイプを作成し、ユーザーが評価する工程を設ける。
・評価結果に基づき合意した内容で開発を行うプロトタイプ開発。
↓
・プログラムの本数がおおむね60〜70本であることがすでに決まっている、
・その後の詳細化の過程を経れば、
完成したか評価できるため、請負契約であると認定。
要求仕様確定後の段階で締結された契約は、要求仕様が大幅に変動する段階ではなくなっていた。
↓
請負契約であると認定。
・設計、プログラミング、テストを短い周期で繰り返し、ユーザーの要望や意見を聴取しながら成果物の完成度を高めていくスパイラル方式。
・当初の段階では完成成果物の具体的内容は確定されていない。
・契約書上の工数や完了目標月日は予定であり、確定されていない。
↓
準委任契約であると認定。
これを参考に、紛争解決のためのシステム開発法務」では「契約の性質の判断基準の１つとして、契約時における確定度合いがどの程度であったかという点が重要であるが、それ以外の要素も踏まえて契約の性質が総合的に判断される」と述べる。
残念ながら、専門家をもってしても明確な基準は示せないわけである。
請負か準委任かがすべてではないけれども
ここまでいっておいて何であるが、請負か準委任かのみをもって法的責任のすべてが決まるわけではない。
・何をすれば報酬請求権が生じるか。
・何を履行できなければ契約解除権や損害賠償請求権が生じるか。
・履行により何が生じ、それに対しどのような責任を生じるか。
・契約締結後に何をしていくか（決めていくか）。
業務委託契約で主要なポイントであるこれらをどう決めていくか、請負・準委任二元論を乗り越え、この領域に進むべきなのだろう。
冒頭の例を踏まえ、法務担当がすべきことは、結局の所以下なのだろう。
・顧客に提示した資料の確認
・上記資料が確定か否か、未確定部分の有無の確認
・未確定部分の重要さの確認
※重要さの指標として、全体の予定工数や契約金額に占める未確定部分のウェイト、顧客の重視の度合い（それができないときに損害賠償を辞さないかどうかの事情の有無、例えば事業ユーザーにとってのリリース予定日、元請ベンダーの引き渡しの義務の有無）が参考になろう。
法務担当者は現場の資料や感触を信頼するけれども、特定の資料やワードを過度に信頼せず、自らの経験と判断で紛争ポイントを予測し、契約に反映させなければならないのである。
この記事が気に入ったらサポートをしてみませんか？