アジャイル開発に適した契約形態は？準委任契約とアジャイルの相性を解説

「アジャイル開発でやりましょう」と言われたけれど、契約はどうすれば？

「ベンダーから『アジャイル開発で進めましょう』と提案されたのですが、契約形態はどうすればいいんでしょうか？」

中小工務店・設計事務所の経営者から、最近こうしたご相談が急増しています。DX（デジタルトランスフォーメーション）が業界の合言葉となり、施工管理システム・原価管理システム・顧客管理システムを新規開発したり刷新したりする中小企業が増える中で、「アジャイル開発」という言葉を耳にする機会もぐっと多くなりました。

しかし、いざ契約段階になると——

「請負契約と準委任契約、どっちがアジャイルに向いているのか？」
「請負だと『成果物が決まらないとダメ』と言われたが、アジャイルって要件を変えながら進めるんですよね？」
「準委任だと『いくらかかるかわからない』のが怖い」
「結局、契約書には何を書けばいいのか？」
「途中で要件が変わったとき、追加費用を請求されないか心配」

——こうした疑問と不安に直面します。

実は、**アジャイル開発には「請負契約はほとんど合わない」**という業界常識があります。一方で、準委任契約はアジャイル開発と非常に相性が良い契約形態です。しかし、その理由と注意点を正しく理解しないまま準委任契約を結ぶと、かえってプロジェクトが漂流するリスクもあります。

「アジャイルに最適な契約形態がわからない」——中小工務店・設計事務所のDX案件で頻発しています

この悩み、決してあなただけのものではありません。

中小工務店・設計事務所の経営者・管理者の方から、こんな相談をよく受けます。

「ベンダーに『アジャイル開発で進めたい』と言われて準委任契約を結んだのですが、3ヶ月経っても何ができあがるのか見えません。月々の請求は来るのに、形になったものは曖昧で、社員からも『これって本当に進んでいるの？』と不安の声が上がっています」

「逆に、アジャイル開発のはずなのに請負契約を結んでしまい、要件を少しでも変えようとすると『契約範囲外なので追加費用です』と言われる。これでは普通のウォーターフォール開発と何も変わりません」

これらは、契約形態とアジャイル開発の特性が噛み合っていないことから生じる典型的な失敗事例です。

そもそもアジャイル開発は、「要件の不確実性に対応するために、短いサイクル（スプリント）で開発・検証・改善を繰り返す」手法です。最初にすべての要件を確定させるのではなく、優先順位の高いものから実装し、動くものを見ながら次の方針を決めていきます。この特性は、「最初に成果物と金額を確定する請負契約」とは構造的に相性が悪いのです。

しかし、IT業界の慣習として「システム開発は請負契約が当たり前」という考え方が根強く、ベンダー側も発注者側も、アジャイルにふさわしい契約形態についての知識が不足しているのが現状です。特に中小工務店・設計事務所のように、システム発注の経験が少ない組織では、「ベンダーが出してきた契約書をそのまま受け入れる」ことが多く、それが後のトラブルの種になります。

建設業の感覚で言えば、「設計変更がしょっちゅう起きる現場なのに、最初の一発見積もりで請負契約を結ぶ」ようなものです。設計変更のたびに「これは契約範囲外」と言われたら、現場が回らないのは明らかですよね。

結論：アジャイル開発には準委任契約（特に履行割合型）が最適です

結論から言えば、アジャイル開発に最適な契約形態は「準委任契約（履行割合型）」です。

なぜなら、アジャイル開発の本質である「要件の柔軟な変更」「短いサイクルでの試行錯誤」「動くものを見ながらの優先順位調整」は、「成果物の完成を約束しない代わりに、業務遂行そのものに対価を支払う」準委任契約の構造と完全に合致しているからです。

逆に、請負契約は「最初に決めた成果物を、最初に決めた金額で、最初に決めた期日までに完成させる」契約なので、要件変更を前提とするアジャイル開発とは水と油の関係にあります。

この記事を読み終えれば、あなたは——

なぜアジャイル開発に請負契約が向かないのか、その構造的な理由を説明できるようになります
準委任契約とアジャイル開発が相性の良い理由を、ビジネス的にも法的にも理解できます
アジャイル開発で準委任契約を結ぶ際の、契約書の必須条項とチェックポイントを把握できます
「準委任契約だと予算が読めない」という不安を解消する具体的な方法を知ることができます
ベンダーから契約書を提示されたときに、自社を守るために何を確認すべきかを判断できます

アジャイル開発と準委任契約が相性の良い理由

アジャイル開発と準委任契約の相性を深掘りする——実務で使える完全ガイド

なぜアジャイル開発に「請負契約」は向かないのか

まずは、請負契約がアジャイル開発と相性が悪い理由を構造的に整理します。

請負契約とは、民法第632条に定められた**「仕事の完成を約束し、その対価として報酬を支払う契約」です。重要なのは「仕事の完成」という結果に対して報酬が発生する**点です。つまり、契約時点で「何を完成させるか」が確定していなければ、そもそも成立しない契約形態なのです。

しかし、アジャイル開発は——

要件は固定しない。 開発しながら優先順位を見直す
詳細仕様は事前に決めない。 スプリントごとに細部を詰める
完成形は変化する。 ユーザーフィードバックで方針が変わる
見積もりも変動する。 予期せぬ課題で工数が増減する

——という特性を持ちます。この時点で、請負契約の前提と矛盾しているのが明らかです。

無理に請負契約でアジャイル開発を進めると、次のような問題が起きます。

問題1：要件変更のたびに「契約範囲外」という壁ができる

請負契約の本質は「契約時点で約束した成果物」を完成させることです。途中で要件が変われば、それは「変更契約」となり、追加費用と追加期間が発生します。

アジャイル開発では要件変更が前提なので、スプリントごとに変更契約を結ぶような事態になり、契約事務だけで現場が疲弊します。

問題2：ベンダーが「変更を嫌がる」インセンティブを持つ

請負契約は「決めた金額で完成させる」契約なので、ベンダーは仕様変更を極力避けようとします。なぜなら、変更によって追加工数が発生しても、その分の報酬がもらえないリスクがあるからです。

結果として、アジャイル開発の本質である「学びながら方針を変える」ことが、ベンダー側の防衛意識によって阻害されることになります。

問題3：契約不適合責任が重くのしかかる

請負契約には**「契約不適合責任（旧・瑕疵担保責任）」**があります。納品物が契約内容と異なる場合、ベンダーは無償で修正する義務を負います。

アジャイル開発のように「動くものを見ながら方針を変える」スタイルでは、「契約と異なる」状態が常に発生するため、この責任の境界線が極めて曖昧になり、トラブルの温床となります。

準委任契約がアジャイル開発と「構造的に相性が良い」理由

一方、準委任契約は民法第656条に定められた「法律行為以外の事務の委託」を内容とする契約で、**「業務遂行そのものを目的とする契約」**です。成果物の完成を約束するのではなく、「専門家として善良な注意義務を尽くして業務を行う」ことに対して報酬を支払います。

この構造が、なぜアジャイル開発と相性が良いのかを整理します。

理由1：要件変更を「契約変更」にしなくてよい

準委任契約では、業務範囲を「○○システムの設計・開発・テストに関する作業全般」のように定めます。具体的な機能や仕様は契約書に書かれていないため、スプリントごとに要件が変わっても、契約変更が発生しません。

これにより、アジャイル開発の柔軟性を契約面でブロックすることなく、スムーズに進められます。

理由2：ベンダーが「要件変更を歓迎する」インセンティブを持つ

準委任契約（特に履行割合型）では、稼働した時間や期間に応じて報酬が発生します。要件が変わっても、その対応に費やした時間は適正に支払われるため、ベンダーは要件変更を嫌がる必要がありません。

むしろ、「学びを反映してより良いものを作る」というアジャイル開発の文化と、契約上のインセンティブが一致します。

理由3：契約不適合責任の問題が発生しない

準委任契約には、原則として契約不適合責任がありません（成果完成型を除く）。「業務を遂行したかどうか」が報酬の根拠なので、成果物の細かい仕様の違いで揉めることがありません。

ただし、これは**「品質を問わない」という意味ではない**ので注意が必要です。次の項で解説します。

「準委任契約だと品質が担保されないのでは？」という誤解

ここで多くの発注者が抱く疑問が、**「準委任契約だと、ベンダーは適当に時間を使うだけで報酬がもらえてしまうのでは？」**というものです。

これはよくある誤解です。準委任契約では、ベンダーは**「善良なる管理者の注意義務（善管注意義務）」を負います。これは「その業界・職種において一般的に期待される水準」で業務を遂行する義務であり、これを怠れば債務不履行責任**を問われます。

つまり、ITエンジニアであれば「プロのエンジニアとして期待される水準」で開発を行う義務があり、適当な仕事をすれば法的責任を問われるということです。

建設業界に置き換えると： 「常用（日当）で雇った職人さんが、丁寧に仕事をするのは当然で、手抜きをすれば信頼を失い、ひどい場合は責任を問われる」のと同じ構造です。日当契約だから手抜きされる、というのは現実の建設現場ではありえないですよね。それと同じです。

アジャイル準委任契約で必ず盛り込むべき7つの条項

アジャイル開発を準委任契約で進める場合、契約書には次の7つの条項を必ず盛り込みます。

条項1：業務範囲の柔軟な定義

悪い例：「○○機能の開発」（具体的すぎる） 良い例：「施工管理システムの設計、実装、テスト、ドキュメント作成、定例ミーティングへの参加、要件整理の支援を含む業務全般」

範囲を抽象化しすぎても揉めますが、機能名で限定すると要件変更時に困るため、「業務カテゴリ」レベルで記載するのがコツです。

条項2：スプリントの定義と運営ルール

アジャイル開発の単位である**「スプリント」**を契約書で定義します。

例：「本件業務は、原則として2週間を1スプリントとして進行する。各スプリントの開始時にスプリントプランニングを行い、終了時にスプリントレビューおよびレトロスペクティブを実施する」

条項3：提出物（ドキュメント・コード等）の明示

準委任契約でも、業務遂行の過程で生じる成果物（提出物）は必ず明示します。

例：

スプリントごとの動くソフトウェア（リポジトリへのコミット）
スプリントレビュー資料
スプリントレトロスペクティブの議事録
バックログ（プロダクトバックログ・スプリントバックログ）
設計ドキュメント・運用マニュアル

「提出物」という言葉を使えば、「成果物の完成を約束する」成果完成型との混同を避けられます。

条項4：工数上限と超過時の協議プロセス

「準委任契約だと予算が青天井になる」という不安を解消する最大のポイントが、この条項です。

例：「本件業務における月間稼働時間は原則として○○時間を上限とする。これを超える可能性が生じた場合、受託者は事前に委託者へ報告し、業務範囲の調整または上限の変更について協議する」

これにより、予算の予測可能性を確保しながら、アジャイルの柔軟性を維持できます。

条項5：知的財産権の帰属

開発したソースコード・ドキュメントの著作権は、発注者帰属を原則とします。

例：「本件業務の遂行過程で生じたプログラム、ドキュメントその他の成果物に関する著作権（著作権法第27条および第28条の権利を含む）は、対価の支払をもって委託者に移転する」

将来のシステム改修や別ベンダーへの移管を考えると、ここを発注者帰属にしておかないと身動きが取れなくなります。

条項6：中途解約の条件

アジャイル開発は「途中で方針を変える」ことが前提なので、プロジェクトを途中で終了する可能性も常にあります。

例：「本契約は、委託者または受託者が30日前までに書面で通知することにより、いつでも解約できる。解約日までに発生した稼働時間に対する報酬は、解約後30日以内に精算する」

条項7：定例ミーティングと意思決定プロセス

アジャイル開発では、発注者（プロダクトオーナー）の意思決定が頻繁に求められます。「誰が」「いつ」「何を決めるか」を契約書で明示しておくと、後の揉めごとを防げます。

例：「委託者は、本件業務に関する意思決定者（プロダクトオーナー）を1名指名し、各スプリントレビューおよび重要な仕様判断の場に参加するものとする」

よくある質問——「準委任だとブラックボックス化しないか？」

中小工務店・設計事務所の経営者からよく受ける質問に、**「準委任契約だと、ベンダーが何をしているのか見えなくなりませんか？」**というものがあります。

確かに、準委任契約の運用次第ではブラックボックス化のリスクがあるのは事実です。しかし、これは**「アジャイル開発の運用ルールを契約書に組み込む」**ことで解消できます。

具体的には——

スプリントごとの動くソフトウェアのデモを必須化する（条項2で規定）
スプリントレビュー資料の提出を必須化する（条項3で規定）
月次稼働報告書に「実施した作業の具体的な記述」を必須項目として入れる
プロダクトバックログを発注者と共有する仕組みを契約書で約束する

こうした運用ルールを契約書に組み込めば、「何が進んでいるか」が常に可視化されます。むしろ、最初に詳細仕様を決めて後はブラックボックスになりがちなウォーターフォール×請負契約よりも、進捗が見えやすいくらいです。

「成果完成型準委任」という選択肢——一部の場面では有効

準委任契約には**「履行割合型」と「成果完成型」の2種類があります。これまで解説してきた内容は主に履行割合型**を想定したものですが、成果完成型準委任という選択肢もあります。

成果完成型準委任は、**「特定の成果が完成したら報酬を支払う」**準委任契約です。請負契約と似ていますが、契約不適合責任の範囲が限定的である点が異なります。

成果完成型が向いている場面：

業務分析・要件定義など、最終的な成果物（報告書・要件定義書）が明確な場合
システムの特定機能の開発で、要件が固まっている部分
アジャイル開発の前段階の準備フェーズ

ただし、スクラム開発の本体（スプリントを回して開発するフェーズ）には、履行割合型の方が圧倒的に向いています。成果完成型と履行割合型をフェーズによって使い分けるのが、実務的には最も賢い方法です。

アジャイル準委任契約の実践ステップ

アジャイル準委任契約を結ぶ前にチェックすべき5ステップ

ベンダーから提示された契約書を、自社でチェックする手順をまとめます。

ステップ1：契約形態の確認 契約書の冒頭に「業務委託契約書」とだけ書かれていることが多いですが、その実態が「請負」なのか「準委任」なのかを確認します。「成果物の完成を○○までに約束する」という文言があれば請負、「業務を遂行する」という表現なら準委任です。曖昧な場合は必ず確認してください。

ステップ2：業務範囲の柔軟性チェック 業務範囲が機能名レベルで限定されていないか。要件変更に対応できる程度の抽象度で記載されているか。

ステップ3：工数上限と協議プロセスの有無 稼働時間の上限が決められているか。上限超過時の協議プロセスが明示されているか。これがないと予算が青天井になります。

ステップ4：提出物リストの明示 スプリントごとの動くソフトウェア、レビュー資料、議事録、ドキュメントなどが「提出物」として列挙されているか。

ステップ5：著作権帰属と中途解約条件 著作権が発注者に帰属することが明記されているか。中途解約の条件と精算方法が明確か。

この5つをクリアしていれば、アジャイル準委任契約として実用上問題のない契約書と言えます。

「自社だけで判断するのが不安」なときは専門家に相談を

とはいえ、契約書のレビューは専門知識が必要な領域であり、特に「アジャイル開発」という新しい開発手法と「準委任契約」という法的枠組みを組み合わせる作業は、IT業界の経験がない発注者にとってハードルが高いものです。

そんなとき、建設業界の業務実態とIT開発の両方を理解している専門家に相談するのが最も確実です。アトリエ・バイナリ（atelier binary）では、中小工務店・設計事務所が抱える「紙とExcelに頼った業務」「属人化した見積もり作成」「現場と事務所の情報断絶」といったレガシーな悩みに対して、契約形態の選定から契約書レビュー、ベンダー選定、アジャイル開発の伴走支援までを一貫してサポートしています。「アジャイルって聞いたことはあるけど、自社にどう適用すればいいかわからない」という経営者の方からも、多くの相談をいただいています。建設業の現場感覚に寄り添いながら、IT発注の落とし穴を回避するコンサルティングは、これからDXを本格化させる中小企業の強い味方になります。

アジャイル準委任契約を成功させる7つのゴールデンルール

最後に、実務で使える7つのゴールデンルールをまとめます。

アジャイル開発には準委任契約（履行割合型）を基本にする——構造的な相性の良さを活かす
業務範囲は機能名ではなく業務カテゴリで定義する——要件変更に強い契約にする
工数上限と超過時の協議プロセスを必ず入れる——予算の予測可能性を確保する
スプリントごとの提出物を契約書で約束させる——ブラックボックス化を防ぐ
著作権は発注者帰属を原則にする——将来の改修・移管の自由度を確保
プロダクトオーナーを発注者側から明示的に指名する——意思決定の遅延を防ぐ
フェーズによって履行割合型と成果完成型を使い分ける——契約形態を柔軟に組み合わせる

これらを契約段階で押さえておくだけで、アジャイル開発と契約形態のミスマッチによるトラブルの大半は防げます。

こんな方に今すぐ読んでほしい

ベンダーから「アジャイル開発」を提案されたが、契約形態に迷っている方
過去にシステム開発で「契約範囲の解釈違い」によるトラブルを経験した方
DXを本格化させたいが、要件が固まりきらない状態で契約を結ぶことに不安がある方
「準委任契約は予算が読めない」と言われて躊躇している中小工務店・設計事務所の経営者
請負契約でシステム開発を進めたら、要件変更のたびに追加費用を請求されて疲弊している方
これからDX投資を本格化させたい、IT発注経験が少ない中小企業の経営者・管理者

アジャイル開発と準委任契約は、「変化に強いシステム開発」を実現するための最強の組み合わせです。しかし、その効果を引き出すには、契約書の設計段階で**「アジャイルの運用ルールを契約条項に落とし込む」**作業が不可欠です。

「ベンダーが出してきた契約書をそのまま受け入れる」受け身の姿勢から、「自社のDXを成功させるために契約書に何を書くべきか能動的に決める」姿勢へ。この転換こそが、DX投資を成功させる発注者の第一歩です。

まとめ

アジャイル開発に最適な契約形態は、準委任契約（履行割合型）です。 請負契約は「最初に決めた成果物を完成させる」ことを前提とするため、要件変更を歓迎するアジャイル開発とは構造的に相性が悪いのです。

本記事のポイントを整理します。

請負契約はアジャイル開発と構造的に相性が悪い——要件変更が「契約範囲外」という壁を作るため
準委任契約（履行割合型）はアジャイル開発と相性が良い——業務遂行に対して報酬が発生するため、要件変更を歓迎できる
「準委任契約は品質が担保されない」は誤解——善管注意義務によりプロとしての品質責任は当然負う
アジャイル準委任契約には7つの必須条項——業務範囲、スプリント運営、提出物、工数上限、著作権、解約条件、意思決定プロセス
「予算が青天井になる不安」は工数上限条項で解消できる——準委任契約でも予算予測は可能
ブラックボックス化の不安は運用ルールを契約に組み込めば解消——スプリントレビュー・提出物の明示で常に可視化
フェーズによって履行割合型と成果完成型を使い分ける——前段階の要件定義は成果完成型、開発本体は履行割合型

中小工務店・設計事務所の経営者にとって、「アジャイル開発」も「準委任契約」も馴染みの薄い概念かもしれません。しかし、建設業の現場感覚に置き換えれば、決して難しい話ではありません。「設計変更が前提の現場では、一発見積もりの請負ではなく、信頼できる職人さんに常用で入ってもらう方が結果的に上手くいく」——アジャイル開発と準委任契約の関係は、まさにこの感覚と同じです。

「アジャイルでやりましょう」とベンダーに言われたとき、契約形態の選択が運命の分かれ道になります。 請負契約のままアジャイルを始めれば、必ずどこかで破綻します。準委任契約に切り替えるだけで、プロジェクトの空気は劇的に変わります。

契約書の細部に迷ったとき、「自社にとって本当にこれでいいのか？」という不安を抱えたとき、迷わず建設業界とIT発注の両方を知る専門家に相談してください。契約段階で数時間投資するだけで、プロジェクト後半の数百万円規模のトラブルを防げるのですから。DXは「契約段階で勝負が決まる」——この事実を、ぜひ覚えておいてください。