システム開発の契約書で、発注側が読むべき5つの場所

見積もりに合意すると、契約書が送られてきます。十数ページのPDFで、普段使わない言葉で書かれていて、正直なところ読み通すのはつらい。総額と納期だけ確認して押印する、というのはよくある話です。

ただ、あとで揉めるところはだいたい決まっています。金額ではありません。「これは追加費用になりますか」「いつ終わったことになりますか」「作ったものは誰のものですか」の3つです。そしてこの3つは、契約書のどこかに必ず書いてあります。書いていなければ、書いていないこと自体が問題です。

この記事は法律の解説ではなく、発注側として読む場所を絞るための整理です。最終的な判断は顧問弁護士にご確認ください。

1. 請負か、準委任か

だいたい契約書のタイトルか第1条に書いてあります。ここで契約全体の性格が決まるので、最初に見る場所です。

請負は、完成させる義務を負う契約です。完成しなければ報酬を請求できませんし、引き渡したものが契約の内容に合っていなければ、修補や減額の責任が発生します。発注側から見ると安心に見えます。

準委任は、作業を提供する義務を負う契約です。専門家として注意を払って作業することが義務で、完成そのものは義務ではありません。ただし成果完成型といって、成果物の引き渡しを報酬の条件にする形もあります。

	請負	準委任
義務の中身	完成させる	注意して作業する（成果完成型なら成果物の引き渡しまで）
仕様変更	原則すべて追加見積もり	範囲内なら調整できることが多い
始める前に必要なもの	完成の定義（要件定義書）	作る対象と進め方の合意
向いている状況	作るものが確定している	作りながら決める部分がある

請負のほうが有利に見えますが、落とし穴があります。請負では「完成」を先に固定しなければならないので、要件をがっちり決めきってからでないと着手できません。そして一度決めた仕様を途中で変えると、原則としてすべて追加見積もりになります。使ってみて気づいたことを反映したい、という進め方とは相性が悪いのです。

逆に準委任は柔軟ですが、「作業はしたが動くものが無い」が理屈の上ではありえます。準委任で契約する場合は、成果物として何を引き渡すのかが書いてあるかを確認してください。

2. いつ終わったことになるか（検収）

検収の条項を探します。ここで見るのは3つです。

ひとつめは検収期間。納品から10営業日、14日といった日数が書いてあります。その間に受け入れ確認をして、合否を通知します。

ふたつめはみなし検収があるかどうか。「期間内に通知がない場合は検収に合格したものとみなす」という一文です。発注側からすると不利に見えますが、これが無いと検収がいつまでも終わらず、開発会社が請求できない状態が続きます。期間が現実的な長さなら、あって普通の条項です。

みっつめが一番大事で、検収の基準が何かです。「発注者が満足したとき」と書いてあると、永遠に終わりません。逆に発注側から見ても、基準が無いと「これは仕様通りです」「いや違います」の水掛け論になります。テスト項目に対する合否、といった確認できる基準が書いてあるほうが、双方にとって安全です。

基準が書かれていない契約書が来たら、「検収のときに何を見て判断しますか」と質問してください。その回答を契約書に足してもらえば済みます。

3. 作ったものは誰のものか

著作権の帰属です。実務では次の3つのどれかになります。

1. 開発したもの一式を、発注者に譲渡する
2. 著作権は開発会社に残し、発注者に利用を許諾する
3. 汎用的な部分は開発会社、この案件のために作った部分は発注者

多いのは3番目です。開発会社は自社で育てた部品や過去案件の共通部分を使い回すことで開発期間を短縮しているので、それごと譲渡することはできません。これは不誠実なのではなく、そうしないと料金が上がるという話です。

見るべきなのは、「譲渡される範囲で、自社が将来やりたいことができるか」です。判断の材料になるのは、たとえばこういう問いです。数年後に別の開発会社に引き継いで改修したくなる可能性はあるか。事業ごと他社に譲渡する可能性はあるか。同じ仕組みを子会社やグループ会社にも展開したいか。どれかに当てはまるなら、その前提を先に伝えて、譲渡の範囲を調整してもらってください。契約後に頼むより、契約前のほうが通ります。

あわせて、著作者人格権を行使しない旨の記載があるかも見ておきます。著作者人格権は譲渡できない権利なので、譲渡の条項だけでは足りず、不行使の合意が別に要ります。

4. 途中でやめるときの条件

始める前に終わり方を確認するのは、後ろ向きなことではありません。特に相手が小さい会社の場合、ここを見ておくと安心して発注できます。

確認するのは次のあたりです。発注側の都合で解約できるか、できるとして支払い済みの費用はどう精算されるか。開発会社が続けられなくなったとき、その時点までのソースコードは引き渡されるか。そして意外に見落とされるのが、ソースコードがどこに置いてあるかです。

コードの置き場所が開発会社のアカウントの中だけだと、関係が切れたときに取り出せません。自社のGitHubアカウントを作って、そこに置いてもらう。あるいは自社アカウントにも読み取り権限をもらっておく。これは契約書というより運用の話ですが、契約前に確認しておく価値があります。サーバーやドメイン、外部サービスの契約名義も同じです。

5. リリース後が、どの契約に入っているか

開発の契約と、動かし続けるための契約は別であることが多いです。開発契約は検収で終わり、その先は保守契約を別途締結する、という形です。

ここで確認するのは、リリース直後の不具合修正がどちらに入っているかです。契約不適合責任の期間が書いてあるはずなので、その期間と、期間内の修正が無償かを見ます。そのうえで、期間を過ぎたあとの修正、機能追加、サーバー費用、外部サービスの利用料がそれぞれ誰の負担かを確認します。

「開発費300万円」という見積もりに運用が入っていないと、1年目に実際に出ていく金額はまったく違うものになります。見積もりの読み方そのものについてはMVP開発の費用は、何で決まるのかに書きました。金額を比べるときは、表示価格ではなく1年目の総額で並べてください。

ニカゲツの場合

私たちは、初回のお打ち合わせから提案までを無料で行い、3営業日以内に画面構成のラフと見積もりをお出ししています。契約書はその提案と一緒にお渡しするので、着手を決める前に読んでいただけます。

契約の型は、範囲がどこまで固まっているかで変わります。作るものが確定している場合と、使いながら決める部分が残る場合とで適した形が違うためです。どちらになるかとその理由は、提案のときにこちらから説明します。この記事で挙げた5つについても、聞かれる前に説明するようにしています。

2ヶ月で何を作り、何を作らないかを先に紙にして合意しておくことが、結局いちばん揉めない方法だと思っています。その中身は2ヶ月で作れるもの、作れないものに、週ごとに書いてあります。

読む時間を、先にとってください

契約書を送られたその日に返す必要はありません。社内で回して、気になる条項に付箋を貼って、まとめて質問する。それで1週間かかっても、開発会社は困りません。むしろ質問が来るほうが、あとの進行は楽になります。

そして、質問への答え方をよく見てください。条項の意味を説明できるか、修正に応じるか、応じないならその理由を言えるか。契約書そのものより、そのやりとりのほうが情報量があります。相談する前に自社側で決めておくといいことは、開発会社に相談する前に、決めておくと話が早い3つのことにまとめました。