システム開発の契約を段階に分割する方法｜動くものを見て判断
システム開発の契約を段階に分割すると、先に動くものを見てから本契約を判断できます。この記事では、段階の分け方の代表的な3パターン、請負と準委任の使い分け、各段階の終わりに何を見て次へ進むかを決める方法を整理します。
新規事業のように仕様が固まりきらない開発で、契約の形をどう組み立てるかを検討している方に向けた内容です。
なぜシステム開発の契約を段階に分けるのか
システム開発を外注するとき、最初に結ぶ契約は「要件を固め、金額と納期を決め、完成まで一括で引き受けてもらう」形になりがちです。すでに仕様が決まっている開発であれば、この形は分かりやすく、管理もしやすい方法です。
ただ、新規事業の開発では、この形が負担になる場面があります。
一括契約で起きやすいこと
新規事業では、作りたいものの輪郭はあっても、細部は使ってみないと決まらないことが多くあります。一括契約では契約前に仕様を固める必要があるため、次のようなことが起こりえます。
- 言葉と資料だけで要件を決めるため、完成したものが思っていたものと違う
- 実物を初めて見るのが開発の終盤で、その時点の修正が追加対応になる
- 費用と仕様を先に固めた後で、事業の前提が変わっても契約の枠を動かしにくい
- 社内で稟議を通すために、決めきれていない部分まで書類上は決めてしまう
要件の食い違いは、契約や担当者の問題というより、実物を見る時期が遅いことから起きやすい面があります。仕様変更の扱いについては、システム開発の仕様変更への対応でも整理しています。
段階に分けると何が変わるか
契約を段階に分割する考え方の中心は、「一度に大きな判断をせず、判断の回数を増やして、1回あたりの重さを小さくする」ことです。最初の段階では小さな範囲だけを契約し、その成果を見てから次の段階の契約を結びます。
この形には、次のような利点があります。
- 実物や成果物を見てから、次に進むかどうかを決められる
- 前の段階で分かったことを、次の段階の範囲に反映できる
- 事業の見込みが変わったときに、途中で見直しやすい
一方で、契約の手間が増える、段階の間で開発が止まる可能性がある、といった注意点もあります。この点は後半で取り上げます。
契約を段階に分割する3つのパターン
分け方には決まった型があるわけではありません。ここでは、システム開発でよく検討される3つのパターンを挙げます。
パターン1：工程で分ける
要件定義・設計、開発・テスト、運用・保守というように、工程ごとに契約を分ける方法です。経済産業省が公開している「情報システム・モデル取引・契約書」でも、開発を複数の段階に分けて契約する「多段階契約」という考え方が紹介されています。
この方法の利点は、要件が固まっていない段階で完成まで約束せずに済むことです。たとえば最初は要件の整理と設計だけを契約し、その成果を見てから開発の契約へ進みます。
注意したいのは、設計書や要件定義書は、読んだだけでは「使ってみたらどうか」が分かりにくいことです。工程で分けても、次の判断材料が書類だけだと、実物を見てから決めたいという目的は十分に果たせません。
パターン2：機能やリリースの範囲で分ける
最初のリリースに必要な機能だけを第1段階とし、残りの機能は後の段階に回す方法です。MVP（最小限の機能で価値を確かめるための製品）の考え方に近く、範囲を絞る基準はMVP開発の機能の絞り方で詳しく扱っています。
この方法は、利用者の反応を見ながら次の範囲を決められる点が強みです。反面、第2段階以降の機能追加をどう見積もり、どう契約するかを最初に決めておかないと、段階ごとの条件が揃わずに話し合いが長引くことがあります。
パターン3：動くプロトタイプを最初の段階にする
最初の段階で、実際に動くプロトタイプだけを作り、それを見てから本契約を判断する方法です。プロトタイプとモックアップ、MVPの違いはプロトタイプとモックアップ・MVPの違いにまとめています。
この方法が向くのは、次のような場面です。
- 企画書だけでは、社内や提携先に可能性が伝わりにくい
- 画面や操作の流れを、実際に触って決めたい
- 事業として成り立つかを、大きな投資の前に確かめたい
動くものがあれば、「ここはこう」と具体的に指摘でき、認識のズレが早い段階で表に出ます。その上で本契約に進むかどうかを決められるため、費用と仕様を先に固めて失敗するリスクを下げられます。小さく作って確かめる考え方は、新規事業の開発は小さく作って確かめる投資判断の進め方も参考になります。
三つのパターンは組み合わせることもできます。たとえば、最初に動くプロトタイプを作り、次に機能の範囲を絞って本開発を契約し、その後は運用しながら機能を追加していく、という流れです。
請負契約と準委任契約を段階ごとにどう使い分けるか
段階に分けると、段階ごとに契約の種類を変える場面が出てきます。システム開発でよく使われるのは、請負契約と準委任契約です。受託開発全体の契約の違いは、受託開発とは？メリット・デメリットと依頼の流れ・契約の違いで整理しています。
| 請負契約 | 準委任契約 | |
|---|---|---|
| 約束する内容 | 仕事の完成 | 一定の業務の遂行 |
| 報酬の考え方 | 成果物に対して支払う | 業務を行ったことに対して支払う |
| 完成の責任 | 受注側が負う | 完成そのものは約束しない |
| 向く場面 | 仕様と範囲が決まっている開発 | 要件が固まっていない段階の検討・試作・運用 |
請負契約では、成果物が契約の内容に合っていないときの対応が問題になります。2020年の民法改正により、いわゆる「瑕疵担保責任」は「契約不適合責任」という考え方に整理されました。納品後の不具合の扱いは、システム開発の契約不適合責任で確認できます。
段階ごとの考え方の例
あくまで一般的な考え方ですが、次のように整理されることが多くあります。
- 要件が固まっていない最初の段階：業務の遂行を約束する準委任の形が合いやすい
- 仕様と範囲が決まった本開発：完成を約束する請負の形が合いやすい
- 納品後の改善や機能追加：継続的に業務を行う準委任の形が合いやすい
ただし、契約書の表題が請負か準委任かだけで、実際の責任の範囲が決まるわけではありません。成果物の定義、完了条件、検収の方法といった中身が重要です。個別の契約については、弁護士などの専門家に確認することをおすすめします。
各段階の終わりに「次へ進む基準」を決めておく
契約を段階に分けても、次へ進む基準が決まっていなければ、判断は結局その場の印象に左右されます。基準は、段階を始める前に、発注側と受注側で言葉にしておきます。
判断の材料になる5つの項目
プロトタイプや第1段階の成果を見るとき、次の項目を確認します。
- 課題に合っているか：想定した利用者の困りごとに、実際に答えているか
- 動作と操作：主要な流れが最後まで動くか、迷わず使えるか
- 利用者の反応：実際に触った人が、どこで戸惑い、どこで価値を感じたか
- 次の段階の範囲：本開発で何を作り、何を後に回すかが具体的に言えるか
- 引き継げるか：作ったものを土台にするのか、作り直すのかの見通しが立つか
利用者の反応を確かめる方法は、プロトタイプのユーザーテストにまとめています。数値で判断する場合は、MVP検証の指標を先に決める方法が役立ちます。
「進まない」という選択肢も決めておく
段階に分ける意味の一つは、進まない判断ができることです。そのためには、止めるときの基準もあらかじめ決めておきます。事業の撤退や見直しの基準は、新規事業の撤退判断で扱っています。
次の段階に進まない場合に何が残るかも、契約の段階で確認しておきます。
- 作成したプロトタイプや設計書、ソースコードの権利は誰に帰属するか
- 第1段階で受け渡された資料やデータは、どう返却・消去するか
- 事業アイデアなどの秘密情報の扱いは、契約終了後も続くか
権利の扱いはソースコードの著作権譲渡、秘密情報の扱いはシステム開発のNDAで詳しく確認できます。
判断者を最初から決めておく
次へ進む判断は、現場の担当者だけでなく、決裁者も実物を見て行うほうが、後の食い違いを減らせます。企画書だけで決裁を取ろうとすると、現場と経営陣で判断材料が違い、話が噛み合わないことがあります。実物を共有して進める考え方は、稟議を通すシステム開発｜プロトタイプの使い方で紹介しています。
段階契約で起きやすい落とし穴
段階に分ける方法にも、注意しておきたい点があります。
段階の間に空白ができる
契約が段階ごとに切れていると、判断や契約手続きの間に開発が止まることがあります。次の段階の条件（範囲、期間、体制）を、前の段階の途中から話し合っておくと、空白を短くできます。
プロトタイプと本開発の関係が曖昧になる
プロトタイプを本開発にそのまま使えるのか、作り直しになるのかは、事前に確認すべき点です。引き継げる部分と見直す部分は、MVPから本開発は作り直し？で整理しています。
次の段階の条件が先送りになる
第1段階の契約だけを結び、その後の条件を決めないままにすると、いざ次へ進むときに、条件の交渉が難しくなりえます。次の段階の進め方や見積もりの前提を、大まかにでも合意しておきます。見積もりの前提や範囲の見方は、システム開発の見積もりの違いが参考になります。
段階を細かく分けすぎる
段階が多すぎると、契約や検収の手間が増え、判断の負担も大きくなります。目的ごとに2〜3段階程度で区切る、というように、実際に判断が必要な節目で分けるのが現実的です。
環境やアカウントの名義が曖昧になる
段階ごとに環境を作り直す場合、サーバーやアカウントの名義が混在することがあります。誰の名義で持つかを、早い段階で決めておきます。詳しくはシステム開発のサーバー名義は誰にする？を参照してください。
段階契約を進める手順の例
最後に、実際に段階契約を組み立てるときの手順を、一般的な流れとして示します。
- 目的を言葉にする：何を確かめたいのか、何が決まれば次へ進めるのかを整理する
- 第1段階の範囲を決める：確かめたいことに絞り、作るものと作らないものを分ける
- 各段階の完了条件を決める：成果物、期間、確認方法、判断者を書き出す
- 契約書に反映する：段階ごとの目的と成果物、権利、秘密情報、次に進まない場合の取扱いを明記する
- 段階の終わりに実物で判断する：事前に決めた基準で、次へ進むか、見直すか、止めるかを決める
仕様が固まりきらない段階でも、確かめたいことと判断基準が決まっていれば、依頼先に相談できます。依頼内容の書き方は、RFP システム開発の書き方が参考になります。また、納品時の確認項目はシステム開発の検収とは、納品後の対応範囲はシステム開発の保守契約で整理しています。
まとめ
システム開発の契約を段階に分けるのは、仕様が固まりきらない新規事業で、実物を見てから判断するための現実的な方法です。この記事の要点は次の通りです。
- 一括契約は、実物を見る時期が遅く、仕様と費用を先に固める必要があるため、新規事業では負担になりやすい
- 分け方には、工程で分ける、機能やリリースの範囲で分ける、動くプロトタイプを先に作る、という3つのパターンがある
- 請負と準委任は、段階の性質に合わせて使い分け、契約書の中身まで確認する
- 各段階の終わりに次へ進む基準を決め、「進まない」場合の権利や情報の扱いも決めておく
- 段階の空白、プロトタイプと本開発の関係、次の段階の条件といった落とし穴を事前に確認する
契約の段階分けは、判断を先送りするためではなく、確かな材料を持って判断するための仕組みです。私たちJustFitは、構想をもとに約1ヶ月で実際に動くプロトタイプを先に開発し、実物を見てから契約を判断していただく進め方をとっています。仕様が固まっていない段階や、稟議を通す前の段階でも相談できますので、契約の組み立てから考えたい場合は、JustFitのサービス紹介をご覧ください。