受託開発の契約書をレビューしていると、「この条項は法的に問題があるか」という点に目が向きがちです。
もちろん、契約書として必要な条項が盛り込まれているか、どちらか一方に著しく不利な内容になっていないかを確認することは重要です。
しかし、私自身、これまで開発現場にPM（プロジェクトマネージャー）として入ってきた経験から感じるのは、受託開発で実際に揉める原因は、必ずしも難しい法律論ではないということです。
むしろ現場では、
「それは当初の見積もりに入っているのか」
「その修正は追加費用なのか」
「どの状態になれば納品なのか」
「どこまで直せば検収完了なのか」
といった、非常に実務的な認識のズレからトラブルが始まることが少なくありません。
契約書上は一見きれいにまとまっていても、営業担当者、PM、エンジニア、そして発注者がそれぞれ違う認識でプロジェクトを進めていれば、後から問題が表面化します。
そこで本記事では、横浜市で契約書作成・レビューを取り扱う行政書士としての視点に加え、実際に開発現場へPMとして入ってきた経験も踏まえ、受託開発の契約書レビューで特に確認しておきたいポイントを解説します。
受託開発の契約書レビューが重要な理由
契約書があってもトラブルになるのはなぜ？
「契約書を交わしているから大丈夫」と考えてしまうことがありますが、受託開発では契約書が存在するだけでトラブルを防げるわけではありません。
重要なのは、実際のプロジェクトで問題になりそうな場面を想定し、そのときのルールが契約書や仕様書などに落とし込まれているかどうかです。
たとえば、開発途中で発注者から、「ここは少し使いにくいので変更してほしい」と言われたとします。
受注者からすれば「仕様変更なので追加費用が必要」と考えるかもしれません。
一方、発注者からすれば「当初お願いしたシステムを使える状態にするための修正なのだから、当然、契約金額に含まれている」と考える可能性があります。
この認識の違いを放置すると、追加費用や納期をめぐるトラブルにつながります。
受託開発では「契約内容」と「現場の認識」がズレやすい
受託開発では、契約書だけでプロジェクトのすべてを表現することは困難です。
実際には、契約書のほかにも、
・見積書
・提案書
・要件定義書
・仕様書
・設計書
・議事録
・メールやチャットでのやり取り
など、さまざまな情報をもとにプロジェクトが進んでいきます。
PMとして開発現場に入っていると、この「複数の資料に情報が分散している状態」が後々問題になりやすいことを実感します。
営業時には「できます」と説明していた。しかし、見積書には書いていない。仕様書にも明記されていない。開発担当者は対象外だと思っている。
このような状態になると、「言った・言わない」「含まれる・含まれない」という話になりやすくなります。
契約締結前のレビューで確認しておきたいこと
受託開発の契約書レビューでは、単に条項の有無を見るのではなく、「この条項で、実際にプロジェクトを運用できるか」という視点が重要です。
特に、業務範囲、仕様変更、追加費用、納期、検収、修正対応については、プロジェクトの進め方と契約内容が一致しているか確認しておきたいところです。
受託開発の契約書でいちばん揉めやすい「業務範囲」
私が受託開発の契約書を見るうえで、特に重要だと考えているのが「業務範囲」です。
受託開発では、発注者が期待しているものと、受注者が「契約上作ることになっている」と認識しているものが一致しているとは限りません。
このズレが、追加開発、納期遅延、検収拒否など、さまざまな問題につながります。
「どこまで作れば納品なのか」が曖昧な契約書のリスク
たとえば、契約書に「顧客管理システムの開発」としか書かれていなければ、それだけでは具体的な業務範囲は分かりません。
顧客情報を登録できればよいのか。
検索機能も必要なのか。
CSV出力は必要なのか。
既存システムからのデータ移行まで含まれるのか。
マニュアル作成や操作説明も含まれるのか。
発注者にとっては「当然含まれている」と思っている機能でも、受注者は見積もりに含めていないことがあります。
そのため、契約書だけではなく、仕様書や見積書なども含めて業務範囲を特定できる状態にしておくことが重要です。
仕様変更・追加開発をどのように扱うか
開発プロジェクトでは、途中で仕様が変わること自体は珍しくありません。
むしろ、プロジェクト開始時点ですべての仕様を完全に確定できないケースもあります。
問題は「仕様変更が発生すること」ではなく、発生したときのルールが決まっていないことです。
たとえば、「仕様変更については、受注者が追加見積もりを提示し、発注者が承認した後に着手する」という流れを決めておけば、追加作業なのか無償対応なのかという認識のズレを減らしやすくなります。
追加費用と納期変更のルールを決めておく
仕様変更が発生すれば、工数が増えます。
工数が増えれば、費用だけではなく納期にも影響します。
ところが、「追加費用は払うが納期はそのまま」という要求が出てくるケースもあります。
そのため、仕様変更を行う場合には、追加費用だけでなく納期その他の条件についても協議・変更できる仕組みを検討する必要があります。
仕様書・見積書・契約書の内容を一致させる
実務上、特に注意したいのが資料間の不整合です。
契約書ではA、見積書ではB、仕様書ではCと読める状態では、いざ問題が起きたときに判断が難しくなります。
基本契約書、個別契約書、注文書、見積書、仕様書など複数の文書を使用する場合は、それぞれの役割と優先関係も整理しておくとよいでしょう。
業務範囲以外にも確認したい受託開発契約の重要条項
検収条件と検収期間
「納品したのに、いつまで経っても検収してもらえない」という問題は、受注者にとって大きな負担になります。
検収期間だけではなく、何をもって合格とするのか、問題があった場合にどのように通知するのかなど、検収のルールを確認しておくことが重要です。
報酬・支払時期・追加費用
報酬額だけでなく、
「いつ請求できるのか」
「いつ支払われるのか」
「追加作業はどのように見積もるのか」
まで確認します。
特に検収完了を支払条件としている場合は、検収が長引くことで入金まで遅れる可能性にも注意が必要です。
契約不適合責任と修正対応の範囲
納品後の修正対応も揉めやすいポイントです。
本来の仕様を満たしていない不具合の修正と、発注者の新しい要望による仕様変更は、同じ「修正」でも性質が異なります。
この区別が曖昧だと、受注者がいつまでも無償修正を求められる原因になります。
著作権・知的財産権の帰属
システム開発では、成果物の著作権やソースコードの扱いも重要です。
特に、受注者が以前から保有しているプログラムや汎用的なモジュールまで発注者へ移転する内容になっていないかなど、実際の開発方法を踏まえた確認が必要になります。
秘密保持と情報管理
開発では、顧客情報や営業情報、システムへのアクセス情報などを扱うことがあります。
どの情報を秘密情報として扱うのか、第三者や再委託先への開示をどうするのかなども確認しておきたいポイントです。
中途解約・契約解除時の精算方法
長期間の開発では、途中でプロジェクトが終了する可能性も考える必要があります。
その場合、すでに実施した作業の費用をどうするのか、作成途中の成果物をどう扱うのかなどを事前に整理しておくことが重要です。
損害賠償の範囲と上限
システムトラブルによって発注者に損害が発生した場合、受注金額を大きく上回る請求が問題になる可能性があります。
損害賠償の対象となる範囲や上限についても、契約金額や業務内容、想定されるリスクを踏まえて確認します。
請負契約か準委任契約かも受託開発では重要
請負契約と準委任契約の基本的な違い
システム開発契約を考える際には、請負と準委任の違いも重要です。
大まかにいえば、請負では仕事の完成が契約上の重要な要素となるのに対し、準委任では一定の業務を適切に遂行することが中心となります。
そのため、「システム開発契約」という名称だけを見て判断するのではなく、実際にどのような業務を、どのような責任で行う契約なのかを確認する必要があります。
開発工程によって契約類型を分ける考え方
システム開発では、要件定義から設計、開発、テストまで複数の工程があります。
すべてを同じ契約類型で処理するのではなく、業務の性質に応じて契約関係を整理することが適切な場合もあります。
特に要件が固まっていない段階で「完成すべき成果物」を明確に定めようとすると、現場の実態と契約内容が合わなくなることがあります。
契約書の名称だけで判断しないことが重要
「業務委託契約書」と書いてあるから準委任、「開発請負契約書」と書いてあるから請負、と単純に判断できるとは限りません。
契約書レビューでは、タイトルだけでなく、業務内容や報酬、成果物、検収などの具体的な条項を確認することが大切です。
受託開発で実際に起こりやすい契約トラブルの具体例
事例1｜「この機能も当然含まれる」と追加開発を求められた
典型的なのが、業務範囲をめぐる認識のズレです。
発注者は「当然あると思っていた」。
受注者は「見積もりには入れていない」。
この状態を避けるためには、開発対象を明確にするだけでなく、必要に応じて「対象外となる業務」を明確にすることも有効です。
事例2｜納品したのに検収が終わらず代金が支払われない
成果物を納品したものの、発注者から具体的な指摘がないまま検収が進まず、請求できないというケースです。
検収期間や検収方法、期間内に回答がない場合の取り扱いなどを事前に検討しておく必要があります。
事例3｜納品後の修正を無償で繰り返し求められた
「バグだから直してほしい」という依頼でも、確認すると当初の仕様にはなかった機能追加だった、ということがあります。
何を不具合として扱い、何を追加開発として扱うのか。
契約書と仕様書の双方から判断できる状態にしておくことが大切です。
事例4｜ソースコードや著作権の帰属で認識が食い違った
発注者は「お金を払ったのだから全部自社のもの」と考え、受注者は「汎用的なコードは自社で再利用できる」と考えているケースです。
知的財産権については、契約締結前に双方の認識を合わせておく必要があります。
横浜市のIT企業・システム開発会社が契約書レビューで確認したいポイント
横浜市で受託開発を行うIT企業やシステム開発会社が契約書を整備する場合も、重要なのは「ひな形として整っているか」だけではありません。
自社の実際の受注・開発フローと契約書が合っているか
契約書の内容が実際の業務フローと合っていなければ、現場で運用されなくなります。
営業から見積もり、契約、要件定義、開発、検収、請求まで、自社が実際にどのように案件を進めているのかを確認したうえで契約書を設計することが重要です。
取引先から提示された契約書をそのまま締結しない
取引先から契約書を提示された場合、その契約書は基本的に相手方の取引を想定して作られています。
自社の業務内容と合っているか、過度な責任を負う内容になっていないかなどを確認したうえで締結することが大切です。
基本契約書・個別契約書・仕様書の優先順位を明確にする
継続的な取引では、基本契約書に加えて個別契約書や注文書、仕様書などを使用することがあります。
内容が矛盾した場合にどの文書を優先するのかを整理しておけば、後の解釈をめぐる争いを減らしやすくなります。
継続的な受託開発では契約書のひな形整備も検討する
案件ごとにゼロから契約書を作るのではなく、自社の標準的な契約書を整備しておく方法もあります。
ただし、ひな形を作って終わりではありません。
実際の案件で発生した問題や、サービス内容・開発体制の変更に合わせて定期的に見直していくことが重要です。
行政書士が見る受託開発の契約書レビューのポイント
条文だけでなく実際の取引フローとの整合性を確認する
私が契約書を確認する際に重視したいのは、「法的な文章として成立しているか」だけではありません。
PMとして開発現場に入ってきた経験があるからこそ、
「現場ではこの条項をどう運用するのか」
「仕様変更が起きたら誰が判断するのか」
「この条件でPMやエンジニアが実際に動けるのか」
という視点も重要だと考えています。
契約書は、締結して保管しておくだけの文書ではなく、プロジェクトを進めるためのルールでもあるからです。
曖昧な表現を減らし「誰が・何を・いつまでに」を明確にする
「必要に応じて対応する」「速やかに協議する」といった表現だけでは、実際に問題が発生したときに判断できないことがあります。
すべてを細かく規定すればよいわけではありませんが、トラブルになりやすい部分については、できる限り具体的なルールを設定することが重要です。
将来の仕様変更や追加作業まで想定して契約を設計する
受託開発では、契約時点の仕様だけを見るのではなく、「予定どおりに進まなかったとき」を考えることも大切です。
仕様変更が発生したらどうするのか。
発注者側の確認が遅れたらどうするのか。
外部サービスの仕様変更があったらどうするのか。
こうした例外的な場面を想定することが、実務に即した契約書レビューにつながります。
行政書士による契約書作成・レビューと弁護士への相談を使い分ける
行政書士は、契約内容について当事者間で争いが生じていない段階における契約書等の作成支援などを行うことができます。
一方、すでに紛争が発生しており、相手方との交渉や法的紛争への対応が必要となっている場合などは、弁護士への相談を検討すべきケースがあります。
「契約を結ぶ前にトラブルを予防したい」のか、「すでに発生しているトラブルを解決したい」のかによって、相談先を適切に選ぶことが大切です。
受託開発の契約書レビューに関するよくある質問
取引先から提示された契約書もレビューできますか？
契約書レビューでは、自社で作成した契約書だけでなく、取引先から提示された契約書について、自社の業務内容や取引条件と整合しているかを確認するというニーズもあります。
特に、業務範囲、検収、知的財産権、損害賠償、解除などは確認しておきたい項目です。
契約書と仕様書はどちらを優先させるべきですか？
一律にどちらを優先すべきというより、複数の契約文書を利用するのであれば、それぞれの位置付けや矛盾した場合の優先順位を明確にしておくことが重要です。
少額の受託開発でも契約書は必要ですか？
金額が小さいからトラブルにならないとは限りません。
むしろ小規模案件では、メールやチャットだけで開発を開始し、業務範囲や納期、検収条件が曖昧なまま進んでしまうことがあります。
少なくとも「何を、いくらで、いつまでに、どのような条件で行うのか」が双方で確認できる状態を作ることが重要です。
まとめ｜受託開発の契約書は「業務範囲の明確化」が重要
受託開発の契約書レビューでは、損害賠償や知的財産権といった条項ももちろん重要です。
しかし、PMとして実際の開発現場を経験してきた目線から見ると、日々のプロジェクトで揉め事の入口になりやすいのは、もっと基本的な「どこまでが今回の仕事なのか」という認識のズレです。
業務範囲が曖昧であれば、仕様変更なのか当初仕様なのかが分からなくなります。
そこから追加費用、納期、検収、修正対応と、問題が連鎖していきます。
そのため受託開発の契約書を作成・レビューするときは、条文だけを見るのではなく、
「この契約書を現場のPMに渡したとき、実際にプロジェクトの判断基準として使えるか」という視点で確認してみることをおすすめします。
横浜市で受託開発の契約書レビューを行政書士に相談するなら
受託開発の契約書は、一般的なひな形に会社名や金額を入れれば完成するものではありません。
開発会社によって、案件の受け方、要件定義の方法、見積もり方法、開発工程、検収方法、保守対応などは異なります。
だからこそ、自社の実際の開発フローに合わせた契約書を整備することが重要です。
私は行政書士として契約書を見るだけでなく、PMとして開発現場に入ってきた経験を踏まえ、「この契約条件で現場が実際に回るのか」という視点も大切にしています。
横浜市で受託開発・システム開発に関する契約書の作成やレビューをご検討の事業者様は、契約締結後のトラブルを予防するためにも、契約前の段階で内容を整理しておくことをおすすめします。