契約書を受け取ったとき、細かい条項を読み込まずに、金額とスケジュールだけを確認して署名してしまう人は少なくありません。しかし、契約書の条項の中には、後々のトラブルを避けるために、事前に確認しておくべき重要なポイントがいくつかあります。この記事では、個人が開発を発注する際、契約書で必ず確認したい条項を解説します。
この記事で分かること
契約書のすべての条項を専門家のように理解する必要はありませんが、いくつかの重要なポイントに絞って確認することで、大きなトラブルを避けられます。この記事では、特に確認しておきたい3つの条項を紹介します。
結論を先に示すと、押さえておきたいポイントは次の3つです。
- 知的財産権が、誰に帰属するかを確認する
- 検収の基準（何をもって完成とするか）を確認する
- 納品後の保守・修正対応の範囲を確認する
多くの個人発注者は、開発経験も契約書レビューの経験もないまま、初めての契約書を受け取ります。専門用語が並ぶ長い文書を前に、「金額と納期さえ合っていれば大丈夫だろう」と考えてしまうのは自然なことです。しかし、契約書の条項は、トラブルが起きたときにこそ効力を発揮します。何もなければ読まれないまま契約は完了しますが、何かが起きたときには、この条項の一文一文が、あなたの権利や負担を決めることになります。
なぜ契約書の条項確認が重要なのか
個人が開発を発注する場面では、開発会社側が契約書のフォーマットを用意し、発注者はそれを受け取って確認するという流れが一般的です。開発会社が用意する契約書は、開発会社にとって不利益が出ないように作られていることが多く、発注者側の視点で見ると、細部で不利な条件が含まれている場合があります。
もちろん、これは開発会社が悪意を持っているという意味ではありません。契約書のテンプレートは、過去のトラブル経験や業界慣習を踏まえて作られていることが多く、双方にとって合理的な内容になっていることがほとんどです。ただし、個人の発注者が置かれている状況（専門知識が少ない、契約書レビューの経験がない、開発会社との情報の非対称性がある）を踏まえると、契約書の内容を「そのまま受け入れる」のではなく、「疑問点は質問する」という姿勢が重要になります。
特に、個人が複業や小規模事業として開発を発注する場合、契約金額が数十万円から数百万円程度になることが多く、弁護士に正式なレビューを依頼するには金額的に見合わないと感じることもあるでしょう。だからこそ、専門家に頼らなくても自分で確認できる、重要なポイントを知っておく価値があります。なお、契約条項の確認は、そもそもどの開発会社と契約するかという発注先選定の段階から地続きの問題でもあります。契約前の見極め方については、開発会社を見極めるために、提案書で見るべきポイントも参考になる。
なお、この3条項の確認と並行して、実際に納品されたときにどう検収を進めるべきかも押さえておくと安心です。具体的なチェック項目や、対応完了と言われたのに直っていない場合の対処はシステム開発の検収とは。何を確認すれば「対応完了」と言えるかで解説しています。
確認ポイント1：知的財産権の帰属
開発してもらったシステムやアプリの「著作権」が、誰に帰属するのかは、契約書で必ず確認すべき重要なポイントです。多くの契約では、代金の支払いと同時に、著作権が発注者（自分）に譲渡されると定められていますが、契約書によっては、著作権が開発会社側に残る、あるいは一部の権利（改変権など）が制限されるケースもあります。
将来的に、別の開発会社に運用を引き継いだり、大幅な改修を依頼したりする可能性がある場合、著作権が自分に帰属していないと、身動きが取りづらくなることがあります。契約書に著作権の帰属について明記されていない場合は、必ず開発会社に確認し、契約書に追記してもらうことをおすすめします。
著作権が移転しないとどうなるか
著作権が開発会社に残ったままだと、具体的にはどのような不都合が生じるのでしょうか。まず、ソースコードの改変を、著作権者である開発会社の許諾なしに行えなくなります。日本の著作権法では、著作者人格権の一種として「同一性保持権」が定められており、著作物を無断で改変することは、原則として著作権侵害にあたる可能性があります。
つまり、著作権が自分に譲渡されていない状態で、別の開発会社に「このソースコードを引き継いで改修してほしい」と依頼した場合、元の開発会社の許諾を得ないと、法的にはリスクを伴う行為になってしまう可能性があるのです。実際には、著作権譲渡の条項が曖昧なまま、事実上ソースコードだけ受け渡されて運用が継続されているケースも見られますが、これは法的に不安定な状態と言えます。
著作権譲渡と「著作者人格権の不行使」条項
著作権は、譲渡できる財産権的な側面（複製権・翻案権など）と、譲渡できない人格権的な側面（著作者人格権）に分かれています。著作者人格権は、著作者本人に一身専属的に帰属するため、契約書で「譲渡する」と定めても、法的には移転しません。
そのため、実務上は「著作者人格権を行使しない」という条項（不行使特約）を契約書に入れることで、実質的に著作権者（発注者）が自由に改変・公開・利用できる状態を作ります。この不行使特約が入っているかどうかも、あわせて確認しておくとよいポイントです。不行使特約がない場合、著作権自体は移転していても、開発会社側の著作者人格権（同一性保持権や氏名表示権など）を理由に、改変や利用の制限を主張される可能性が残ります。
汎用フレームワークやライブラリの扱い
もう一点、注意しておきたいのが、開発会社が独自に持つ「汎用的な部品」の扱いです。開発会社の中には、複数の顧客向けプロジェクトで再利用できる、認証機能や管理画面のテンプレートといった汎用コンポーネントを持っている場合があります。これらの汎用部品については、著作権を発注者に完全譲渡せず、利用許諾（ライセンス）の形にする契約もよく見られます。
これは開発会社にとって合理的な取り決めであり、必ずしも不利な条件とは言えません。汎用部品を毎回新規に開発するコストを避けることで、結果的に発注者側の開発費用も抑えられている場合が多いためです。ただし、「システム全体の著作権は自分に帰属するが、一部の汎用コンポーネントはライセンス提供である」という区分がある場合、契約書のどの部分がその区分に該当するのかを、具体的に確認しておくことをおすすめします。将来、そのシステムを第三者に譲渡したり、別会社に引き継いだりする際に、汎用部品のライセンス条件が影響することがあるためです。
確認ポイント2：検収の基準
検収とは、納品された成果物が、契約内容通りに完成しているかを確認し、それを承認する手続きです。契約書には、「何をもって検収完了とするか」という基準が明記されているべきですが、この基準が曖昧なまま契約してしまうと、「完成したと思っていたのに、認識が違った」というトラブルにつながります。
検収の基準としては、事前に取り決めた仕様書や要件定義書との一致を基準とすることが一般的です。検収期間（納品から何日以内に確認するか）や、不合格だった場合の対応（修正して再度検収するプロセス）についても、契約書で確認しておくことをおすすめします。
検収の基準が曖昧だと起きる典型的なトラブル
検収基準が曖昧な契約でよく起きるのが、「発注者が期待していた機能」と「開発会社が仕様書で合意したと認識している機能」のズレです。たとえば、発注者が口頭で「予約管理機能もあると助かる」と伝えていたとしても、それが仕様書に明記されていなければ、開発会社は検収の対象外と考えます。結果として、納品時に「予約管理機能がない、これは未完成では」という主張と、「そもそも契約範囲に含まれていない」という反論がぶつかり合うことになります。
このようなトラブルを避けるためには、検収の基準を「仕様書・要件定義書との一致」という形で明文化し、口頭でのやり取りに依存しないことが重要です。仕様書に記載のない要望は、検収の合否判断には使えません。逆に言えば、発注者としては、要望をできる限り仕様書に反映させてもらうことが、自分の身を守ることにつながります。
検収期間と「みなし検収」条項
契約書には、「納品後○営業日以内に検収を行う」という検収期間の定めがあることが一般的です。この期間内に発注者から異議（不合格の通知）がなければ、検収に合格したものとみなす「みなし検収」条項が入っている契約も多く見られます。
みなし検収条項自体は、開発会社にとって、いつまでも検収が完了しない状態が続くリスクを避けるための、合理的な仕組みです。しかし発注者側からすると、検収期間内にしっかり動作確認をしないと、不具合を見つける前に検収が完了してしまうリスクがあります。特に、本業が別にある個人事業主の場合、検収期間中に十分な時間を確保できないことも考えられます。契約書に記載されている検収期間が、自分のスケジュールに対して現実的な長さかどうかも、事前に確認しておくとよいでしょう。期間が短すぎると感じた場合は、延長を相談することも可能です。
検収不合格時の再検収プロセス
検収の結果、不合格と判断した場合、その後どのようなプロセスで修正・再検収が行われるのかも、契約書で確認すべき点です。一般的には、不合格の理由（仕様書との不一致点）を書面で通知し、開発会社が修正を行った上で、再度検収を実施する、という流れになります。
このとき、再検収にかかる期間や、修正対応の回数に制限があるかどうかも確認しておきましょう。契約書によっては、「再検収は1回まで」といった制限が設けられている場合もあります。もし複数回の修正・再検収が必要になった場合の対応が契約書に明記されていない場合、開発会社との協議になりますが、事前にこの点を確認しておくことで、トラブルの発生を未然に防げます。
確認ポイント3：納品後の保守・修正対応の範囲
システムが納品された後も、不具合の修正や、軽微な調整が必要になることがあります。契約書には、納品後、どの範囲までを無償で対応してもらえるのか、そしてそれ以降の対応は有償になるのかが明記されているべきです。
「納品後1ヶ月間は、不具合修正を無償で対応する」といった条項が一般的ですが、この期間や対応範囲は契約によって異なります。この条項が曖昧だと、納品後に見つかった不具合が、無償対応の範囲なのか、追加費用が発生する「新規の依頼」なのかで、開発会社との間で見解が分かれることがあります。なお、無償保守期間が終了した後の保守費用については、納品後の保守費用の相場を事前に把握しておくと、契約書の保守条項を読むときの判断基準になる。
「不具合修正」と「機能追加」の境界線
無償保守の範囲でもっともトラブルになりやすいのが、「これは不具合なのか、それとも新機能の追加依頼なのか」という境界線の判断です。仕様書に記載されていた動作と異なる挙動をしている場合は、明確に「不具合」として無償修正の対象になります。一方で、仕様書には記載がなかったが、使ってみて初めて必要性に気づいた機能を追加してほしい、という依頼は「機能追加」であり、有償対応になることが一般的です。
問題は、この2つの中間に位置するケースです。たとえば、「エラーメッセージが分かりにくい」「入力フォームの使い勝手が悪い」といった、仕様書には明記されていないものの、実用上の不便さに関する指摘は、開発会社によって「不具合」と捉えるか「改善要望（機能追加）」と捉えるかが分かれます。契約書に、この境界線についての考え方が明記されていることは稀ですが、少なくとも「不具合の定義」がどのように書かれているかを確認し、疑問があれば契約前に開発会社に質問しておくことをおすすめします。
保守契約と開発契約の分離
多くの開発会社では、開発契約と、納品後の保守契約を別の契約として扱います。この場合、開発契約に含まれる無償保守期間が終了した後は、別途、保守契約を締結することになります。保守契約の内容としては、月額固定料金で一定時間まで対応する「月額保守プラン」や、発生した都度、時間単価で費用を請求する「都度対応」などのパターンがあります。
個人が発注する小規模なシステムの場合、月額保守プランを契約するほどの改修頻度がないことも多く、都度対応の方が費用を抑えられる場合があります。逆に、店舗の業務改善ツールのように、日常的に利用し、不具合対応の即時性が求められる場合は、月額保守プランの方が安心感があります。どちらが適しているかは、システムの利用頻度や、自分自身の対応リソースを踏まえて判断するとよいでしょう。
対応時間・対応スピードの確認
保守対応の「範囲」だけでなく、「対応スピード」についても確認しておくべきポイントです。契約書やその付随資料に、「問い合わせから何営業日以内に初回回答を行うか」「緊急度の高い不具合（システムが完全に停止するなど）の場合、優先的に対応するか」といったSLA（サービスレベルアグリーメント）に近い内容が明記されているかを確認しましょう。
特に、平日の営業時間内のみ対応可能なのか、休日や夜間の緊急対応にも応じてもらえるのか、応じる場合は追加費用が発生するのか、といった点は、実際に不具合が発生してから初めて認識するケースが多くあります。事前に確認しておくことで、「思っていたより対応が遅い」という不満を避けられます。
契約不適合責任についても確認する
契約不適合責任は、納品された成果物が、契約内容と異なっていた場合に、開発会社が負う責任です。この責任の範囲や、責任を追及できる期間（契約不適合を知ってから1年以内など）についても、契約書で確認しておくことをおすすめします。
この責任の範囲が狭く定められていたり、期間が極端に短く設定されていたりする場合は、発注者にとって不利な契約になっている可能性があるため、注意が必要です。
契約不適合責任の基本的な考え方
契約不適合責任は、民法改正（2020年施行）によって、それまでの「瑕疵担保責任」という考え方から名称・内容が変更された制度です。基本的な考え方としては、納品された成果物が、契約で定めた内容（種類・品質・数量など）に適合していない場合、発注者は開発会社に対して、修補（修正）の請求、代金の減額請求、損害賠償請求、契約解除といった対応を求めることができます。
ただし、この権利には期間制限があります。民法上は、発注者が契約不適合を「知った時から1年以内」に、開発会社にその旨を通知しなければ、権利を失うとされています。契約書では、この期間をさらに具体的に定めている場合が多く、「納品後6ヶ月以内」「納品後1年以内」など、期間の起点や長さが契約によって異なります。契約書に定められた期間が、民法上のデフォルトよりも発注者にとって不利（短い）内容になっている場合、その点を認識した上で契約するかどうかを判断する必要があります。
責任範囲を限定する条項に注意
契約書の中には、「開発会社が負う損害賠償責任の上限は、契約金額を上限とする」といった責任限定条項が入っていることがあります。これは開発会社にとって、想定外の巨額の賠償リスクを避けるための、業界でよく見られる条項です。発注者側としても、この条項自体が直ちに不合理というわけではありませんが、上限額が契約金額よりも極端に低く設定されている場合や、故意・重過失による損害についても責任が免除されるような書き方になっている場合は、注意が必要です。
一般的には、故意または重過失がある場合には責任限定の適用を除外する、という書き方がされることが多く、これは発注者・開発会社双方にとって公平な内容と言えます。契約書にこの除外規定があるかどうかも、あわせて確認しておくとよいでしょう。
契約書の条項に、疑問点があった場合の対応
契約書を読んで、内容が理解できない、あるいは自分にとって不利に感じる条項があった場合、そのまま署名せず、開発会社に質問することをおすすめします。誠実な開発会社であれば、条項の意図を丁寧に説明してくれるはずです。
説明を受けても納得できない場合や、大きな金額が関わる契約の場合は、契約書のレビューを専門家（弁護士など）に依頼することも検討する価値があります。特に、初めての発注で、契約書の内容に不安がある場合は、専門家のセカンドオピニオンを得ることで、安心して契約を進められます。
質問することが失礼にならないか、という不安について
個人の発注者からよく聞かれるのが、「契約書の内容について細かく質問すると、開発会社に嫌がられないか」という不安です。しかし、契約書の内容について質問することは、発注者として当然の権利であり、多くの開発会社はこうした質問を歓迎します。むしろ、契約内容を確認せずにそのまま署名する発注者よりも、内容を理解した上で契約する発注者の方が、後々のトラブルが少なく、開発会社にとっても望ましい関係につながります。
質問の仕方としては、「この条項の意図を教えてください」「この場合、実際にはどのような対応になりますか」といった、具体的な状況を想定した聞き方をすると、開発会社側も答えやすくなります。逆に、「この条項を全部削除してほしい」といった一方的な要求は、開発会社にとって受け入れづらい場合があるため、まずは意図を確認し、必要であれば代替案を相談する、という順序をおすすめします。
専門家に相談する際の見極め方
契約金額が大きい場合や、契約内容が複雑な場合は、弁護士による契約書レビューを検討する価値があります。近年は、スポットで契約書レビューのみを依頼できる法律事務所やオンラインサービスも増えており、数万円程度の予算感で、契約書全体のリスクをチェックしてもらえる場合があります。
契約金額が小さい場合（数十万円程度）は、レビュー費用が契約金額に対して割高になることもあるため、必ずしも専門家への依頼が最適とは限りません。その場合は、この記事で紹介したような重要ポイントに絞って自分で確認し、疑問点だけを開発会社に質問する、という進め方が現実的です。契約金額が大きくなるほど、専門家への相談の優先度は高くなると考えてよいでしょう。
よくある失敗パターン
契約書の条項確認において、実際によく見られる失敗パターンをいくつか紹介します。自分の契約書を確認する際の参考にしてください。
失敗パターン1：口頭でのやり取りを仕様書に反映しないまま契約
打ち合わせの中で「これも対応してもらえますよね」といった口頭でのやり取りがあったにもかかわらず、それが仕様書や契約書に反映されないまま契約を締結してしまうケースです。開発会社側は「契約書・仕様書に書かれていること」を基準に対応するため、口頭でのやり取りは、後から「言った言わない」の水掛け論になりがちです。重要な要望は、必ず文書（メールやチャットの記録でも構いません）に残し、可能であれば仕様書に反映してもらうことが重要です。
失敗パターン2：著作権の帰属を確認せず、後から改修を別会社に依頼
最初の開発会社との関係が悪化し、別の開発会社に改修を依頼しようとしたところ、著作権が最初の開発会社に残っていることに気づき、身動きが取れなくなるケースです。このような事態を避けるためには、契約時点で著作権の帰属を明確にしておくことが不可欠です。
失敗パターン3：検収期間中に十分な動作確認をせず、みなし検収が成立
検収期間内に忙しくて十分な確認ができず、みなし検収条項によって検収が完了してしまい、後から見つかった不具合が「検収済みだから」という理由で有償対応になってしまうケースです。検収期間が短いと感じた場合は、契約前に期間の延長を相談することをおすすめします。
失敗パターン4：保守範囲の解釈違いで追加費用が発生
納品後に見つかった問題を「不具合だから無償で直してもらえる」と思っていたが、開発会社側は「仕様書にない挙動についての改善要望」と判断し、有償対応になってしまうケースです。この境界線については、契約前に開発会社の考え方を確認しておくことで、認識のズレを減らせます。
契約書チェックリスト
契約書を確認する際に見るべきポイントを、チェックリストとしてまとめました。署名前に、一つひとつ確認してみてください。
- 著作権（知的財産権）の帰属が、発注者に明記されているか
- 著作者人格権の不行使特約が入っているか
- 汎用コンポーネント・ライブラリなど、ライセンス提供扱いになる部分がないか
- 検収の基準が、仕様書・要件定義書との一致という形で明文化されているか
- 検収期間が、自分のスケジュールに対して現実的な長さになっているか
- みなし検収条項の有無と、その期間を理解しているか
- 検収不合格時の再検収プロセス（回数制限の有無）が明記されているか
- 納品後の無償保守期間・対応範囲が明記されているか
- 「不具合」の定義が、どのように書かれているか
- 保守契約が開発契約と別になっている場合、その内容と費用感を理解しているか
- 対応時間・対応スピード（営業時間内のみか、緊急時の対応があるか）を確認したか
- 契約不適合責任の範囲と、責任を追及できる期間が明記されているか
- 損害賠償責任の上限額と、故意・重過失の場合の除外規定があるか
- 疑問点がある条項について、開発会社に質問し、納得できる説明を得たか
Q&A：よくある疑問
Q. 契約書に著作権の帰属が書かれていない場合、自動的にどちらのものになりますか。
A. 著作権法上、原則として著作物を創作した者（この場合は開発会社側のエンジニア）に著作権が発生します。契約書に譲渡の定めがない場合、著作権は開発会社側に残ると考えるのが基本です。「代金を払ったのだから当然自分のものになる」という思い込みは避け、契約書に譲渡の条項が明記されているかを必ず確認しましょう。
Q. 検収期間が短いと感じた場合、契約後に変更してもらうことはできますか。
A. 契約締結後に一方的に条件を変更することは難しいため、契約前の段階で、検収期間が自分のスケジュールに対して現実的かどうかを確認し、必要であれば延長を相談することをおすすめします。契約後に「思っていたより短かった」と気づいた場合は、開発会社に個別に相談し、柔和に対応してもらえるかどうかを確認するしかありません。
Q. 保守契約を結ばなかった場合、不具合が出たらどう対応すればよいですか。
A. 保守契約を結んでいない場合、不具合が発生した際は、都度、開発会社に見積もりを依頼して対応してもらうことになります。ただし、対応の優先度や費用感が、保守契約を結んでいる顧客と比べて低くなる可能性があるため、日常的に利用するツールであれば、保守契約の締結を検討する価値があります。
請負契約・準委任契約、どちらでも確認すべきこと
これらの確認ポイントは、請負契約・準委任契約のどちらの契約形態であっても、共通して確認すべき内容です。契約形態の基本的な違いについては、別記事で詳しく解説しています。
なお、契約形態によって、検収の位置づけが異なる点には注意が必要です。請負契約では、成果物の完成・納品に対して報酬が支払われるため、検収は「契約上の重要な手続き」として明確に位置づけられます。一方、準委任契約では、業務の遂行そのものに対して報酬が支払われるため、厳密な意味での「検収」は存在しない場合もあります。ただし、実務上は準委任契約であっても、成果物の確認・受け入れに近い手続きが設けられていることが多く、その場合は同様の視点で確認しておくとよいでしょう。
専門知識を活かしたツールの場合、追加で確認したいこと
専門分野の業務ロジックを含むツールの場合、そのロジック自体に独自性がある場合、知的財産権の扱いがより重要になります。自分の専門知識をもとに設計した業務ロジックが、開発会社側の「ノウハウ」として、他の顧客にも流用されないかどうかも、必要に応じて契約書で確認しておくとよいでしょう。
このようなケースでは、著作権の帰属だけでなく、秘密保持条項（NDA）の内容も併せて確認することをおすすめします。自分が提供した業務知識やノウハウが、開発会社の他のプロジェクトに流用されないよう、秘密保持義務の対象範囲や、契約終了後もその義務が継続する期間（一般的には2〜5年程度）が定められているかを確認しましょう。
また、業務ロジックの独自性が高く、それ自体が競争力の源泉になっている場合は、著作権譲渡に加えて、「開発会社が類似のロジックを他社に提供しない」という競業避止に近い条項を交渉することも考えられます。ただし、こうした条項は開発会社にとって負担が大きいため、簡単には受け入れてもらえない場合もあります。契約金額や取引の重要度に応じて、交渉の余地があるかどうかを見極めるとよいでしょう。
店舗の業務改善ツールの場合、追加で確認したいこと
店舗の業務改善ツールでは、納品後の保守対応の範囲が特に重要です。日々の業務で使うツールである以上、不具合が発生した際にすぐに対応してもらえるかどうかが、業務への影響を左右します。保守対応の対応時間（営業時間内のみか、緊急時はどうかなど）についても、確認しておくことをおすすめします。
店舗業務で使うツールの場合、営業時間中にシステムが停止すると、直接的に売上や顧客対応に影響します。そのため、契約書または保守契約の内容として、「システム停止時の緊急連絡先」「初回回答までの目安時間」「代替手段（紙の記録など）に切り替える際の判断基準」といった、実務的な対応フローを事前に確認しておくと安心です。
また、店舗のオペレーションは、繁忙期・閑散期で状況が大きく変わることもあります。繁忙期に不具合対応が集中しやすいことを見越して、開発会社との間で、繁忙期前に軽い動作確認を依頼できるかどうかも相談しておくとよいでしょう。契約書に明記されていなくても、良好な関係を築いておくことで、柔軟に対応してもらえる場合があります。
まとめ
契約書の条項確認は、専門家のように全てを理解する必要はありません。この記事で紹介した「知的財産権の帰属」「検収の基準」「納品後の保守・修正対応の範囲」という3つのポイントに加えて、契約不適合責任の範囲や期間を確認するだけでも、後々の大きなトラブルを避けられる可能性が高まります。
契約書は、開発会社との関係が良好なうちは意識されることがほとんどありませんが、何かトラブルが起きたときに初めて、その内容が重要な意味を持ちます。署名する前に、疑問点をきちんと質問し、納得した上で契約を結ぶという姿勢を持つことが、個人が安心して開発を発注するための第一歩です。
この記事の次に読みたい記事
契約書の重要な条項を理解したら、次は見積書の読み方についても確認しておきましょう。あわせて次の記事も参考にしてください。
