トップ

/

コラム

/

「口頭でOKもらいました」が通じない。I...

2026.06.13

IT法務

投稿者:田口 久美子

「口頭でOKもらいました」が通じない。IT開発を外注するとき、契約書が必要な本当の理由

システムの開発やWebサイトの制作を外注するとき、こんなふうに進めていませんか?

「知人の紹介だから、細かい書類は省略した」
「チャットでやり取りして、口頭でOKをもらった」
「相見積もりをとって、メールで発注した」

信頼関係があれば、わざわざ契約書を用意するのは大げさな気がしますよね。でも、IT開発の現場では、こうした進め方が後々の大きなトラブルにつながることが少なくありません。

今日は、IT開発を外注する際に契約書が必要な理由と、最低限押さえておきたいポイントをやさしく解説します。

なぜIT開発は「口頭OK」が通じにくいのか

一般的な商品の売買であれば、「いくらで・何を・いつ渡す」という3点が決まれば、取引はシンプルに完結します。

ところがIT開発は、そう単純ではありません。

最初に話し合った内容が、開発を進める中でどんどん変わっていくことがあります。「やっぱりこの機能も追加してほしい」「デザインをもう少し変えたい」。こうした変更が積み重なった結果、最初の合意と最終的な成果物がかけ離れてしまうことがあります。

このとき、契約書がなければ「最初にそんな話はしていない」「いや、あのとき追加でお願いしたはずだ」という水掛け論になってしまいます。

IT開発でよく起きる「こんなはずじゃなかった」

実際にご相談いただく内容の中で、特に多いのが以下のような場面です。

  • 仕様の認識がずれていた
    「動けばいい」という認識で発注したが、想定していた機能の半分しか実装されていなかった。何が「完成」なのかを定義していなかったため、追加費用を求められた。

  • 納期が守られなかった
    「だいたい3ヶ月くらいで」という口約束だったが、半年経っても納品されない。遅延に対するペナルティを定めていなかったため、催促することしかできない。

  • 著作権がどちらに帰属するかでもめた
    開発費用を全額支払ったのに、「ソースコードの著作権は渡していない」と言われた。契約書に著作権の扱いを明記していなかったため、交渉が難航した。

  • バグの修正費用で争いになった
    納品後にバグが見つかったが、「仕様通りに作った」と言われ、修正費用を別途請求された。瑕疵担保責任(かしたんぽせきにん)の範囲を決めていなかったため、どちらが負担すべきかが曖昧になった。

瑕疵担保責任(かしたんぽせきにん)とは?
納品されたものに欠陥(バグや不具合)があった場合に、受注側が負う責任のことです。「どんな不具合を・いつまでに・無償で直してもらえるか」を契約書で定めておくことが大切です。

契約書に盛り込んでおきたい6つのポイント

IT開発の契約書では、一般的な業務委託契約書に加えて、以下の項目を明確にしておくことが重要です。まずは一覧で確認してみてください。

項目

定めておくべき内容

定めていないと…

① 業務の範囲

何を作るか、機能の一覧や仕様書を別紙で添付

「そこまでやるとは聞いていない」と追加費用を請求される

② 納期と遅延ルール

納品日と、遅延時の損害賠償・解除条件

半年待っても納品されず、催促しかできない

③ 検収のルール

完了の基準・確認期間・合格の判断方法

際限のない修正要求が続く

④ 著作権の帰属

ソースコードや成果物の著作権がどちらに帰属するか

代金を払ったのに著作権が受注側に残る

⑤ 瑕疵担保責任

納品後のバグ対応範囲・期間・費用負担

修正費用を別途請求される

⑥ 秘密保持(NDA)

共有した機密情報の取り扱い方

事業計画やシステム構成が外部に漏れるリスクがある

それぞれ、もう少し詳しく見ていきましょう。

① 業務の範囲(スコープ)
「何を作るのか」を具体的に定めます。機能一覧や仕様書を契約書の別紙として添付しておくと、後からの認識のズレを防げます。

② 納期と遅延時のルール
納品日を明記した上で、遅延が生じた場合の対応(損害賠償や解除の条件など)も定めておきましょう。

③ 検収のルール
納品されたものを「合格」と判断するための基準と期間を決めます。「いつまでに・どうやって確認し・何をもって完了とするか」を明確にしておくことで、際限のない修正要求を防げます。

④ 著作権の帰属
開発したシステムやソースコードの著作権が、発注側・受注側のどちらに帰属するかを明記します。何も定めない場合、著作権は制作者(受注側)に残るのが原則です。

⑤ 瑕疵担保責任の範囲
納品後に見つかったバグや不具合について、受注側がどこまで・いつまで対応するかを定めます。

⑥ 秘密保持(NDA)
開発を依頼する過程で、自社のシステム構成や事業計画など、機密性の高い情報を共有することがあります。その情報をどう扱うかを定めておきましょう。

「信頼できる相手だから大丈夫」は、関係を守るためにも逆効果

「契約書を用意すると、相手に不信感を与えてしまうのでは」と心配される方もいます。

でも、考えてみてください。契約書は相手を疑うためのものではなく、「私たちはこういう約束をしました」という共通認識を形に残すものです。信頼関係があるからこそ、最初に認識を揃えておくことが、長く良い関係を続けるための土台になります。

トラブルが起きてから「あのとき書面にしておけば」と後悔するよりも、最初に少し時間をかけて契約書を整えておく方が、お互いにとって安心です。

「こんな内容で発注しようと思っているが、契約書はどう作ればいい?」「今使っている契約書を一度見直したい」そんなときは、お気軽にご相談ください。IT現場の実務経験を持つ行政書士が、実態に即した契約書づくりをサポートします。

RELATED SERVICE利用規約・契約書の作成をサポートしています

IT現場の実務を知る行政書士が、利用規約・プライバシーポリシー・業務委託契約などの作成を承っています。