発注の朝、社判を押す手が一瞬止まった理由
先代が亡くなって二年目の秋、営業3課の在庫管理をExcelから専用システムに移すという、社長になって最初の「大きな買い物」の契約書が届いた。開発会社の担当者は先代の代からの付き合いで、名刺交換のときから「先代にはずいぶんお世話になりました」と言われ続けている。見積書、業務委託契約書、個人情報の取扱いに関する覚書。三点セットがクリップで留められ、判を押す欄には赤い付箋が貼られていた。
読んでみると、契約書はA4で3枚しかない。委託業務の内容、委託料、支払方法、契約期間、それだけだ。念のため経理担当の女性に聞いてみても「先代の時からこの会社とはずっとこの書式でやってますよ」という答えが返ってくる。たしかに、長年の付き合いがある相手に、今さら分厚い契約書を突き返すのは気が引ける。だが同時に、頭の中では別の記憶がよぎっていた。取引先の社長仲間から聞いた「発注したシステムが完成せず、開発会社と揉めて結局裁判になった」という話。あるいは自社の情報システム担当者が漏らした「あのベンダーの見積もり、何が含まれているのか正直よくわからない」というつぶやき。
判を押せば、この関係は少なくとも数ヶ月、あるいは数年続く。もし途中でシステムが思うように動かなかったら。もし担当者が突然辞めてしまったら。もし完成後に「これは仕様通りではない」という食い違いが起きたら。そのとき、この3枚の紙は自分たちを守ってくれるのか。手元にあるのは「先代の代からの信頼関係」という、法的にはなんの効力もない安心材料だけだった。
この記事は、まさにこの瞬間に立っている後継社長のために書いている。先代から会社を継いだばかりで、開発会社との契約に慣れていない経営者が、契約書のどこに何を書いておけば「もしものとき」に困らないのか。トラブルが起きてから慌てて弁護士に相談するのではなく、契約を結ぶ前の段階で押さえておくべき条項を、実務目線で整理する。
なぜ承継後の会社ほど「トラブル条項の空白」が起きやすいのか
先代の契約書がそのまま「標準」になってしまう構造
事業承継を経験した経営者にとって最も厄介な罠のひとつが、「先代が使っていた契約書のフォーマット」が、そのまま社内の標準として無批判に引き継がれてしまうことだ。先代が15年前、20年前に結んだ契約書のひな形が、社内の総務フォルダに「契約書テンプレート.doc」として保存されている。後継社長がシステム発注のたびにこのファイルを開き、会社名と金額だけを書き換えて使い続ける。
このテンプレートが問題になるのは、多くの場合、それが作られた時代には想定されていなかったリスクが、現在のシステム開発には存在するからだ。20年前のオフィスソフトの導入と、現在のクラウドサービス連携・API接続を前提としたシステム開発は、リスクの種類がまったく異なる。データの帰属、セキュリティインシデントが起きたときの責任分担、途中でベンダーが倒産したときの取り扱い、契約不適合が見つかったときの対応期限——これらは20年前のテンプレートには影も形もない条項であることが多い。
さらに、先代の代からの取引先である開発会社に対して、後継社長が「今さら契約内容にうるさく言うのは失礼ではないか」という心理的なブレーキをかけてしまう構造がある。これは事業承継特有の力学だ。創業者や先代であれば、対等な立場として契約条件を交渉するのが当然だと考えられていても、後継者は「先代が築いた関係を壊してはいけない」という無言の圧力を自分自身にかけがちだ。結果として、契約書の内容を精査せず、先代の代からのフォーマットをそのまま踏襲し、トラブル条項が空白のまま契約が成立してしまう。
システム開発特有の「完成基準のあいまいさ」
もう一つの構造的な問題は、システム開発という取引の性質そのものにある。物を買う取引であれば、納品された商品が仕様書通りかどうかは目視や検査で比較的容易に判断できる。ところがシステム開発では、「完成」の定義自体が発注者と開発会社の間で食い違いやすい。
要件定義書が曖昧なまま契約を結んでしまうと、「この機能はあって当然だと思っていた」「いや、それは追加開発の範囲だ」という水掛け論が発生する。これは開発会社側の悪意によるものというよりも、そもそも要件定義の段階で発注者側(つまり後継社長やその会社の現場担当者)が、自社の業務フローを言語化しきれていないケースが非常に多い。先代の時代からの業務が「暗黙知」として現場に染み付いており、それを情報システムの要件として明文化する作業自体を、開発会社に任せきりにしてしまう。
この状態で契約書に「トラブルが起きたときにどうするか」という条項が書かれていなければ、いざ食い違いが発生したときに、どちらの言い分が通るかは「声の大きさ」や「関係性の強さ」で決まってしまう。先代の代からの付き合いがある開発会社であればあるほど、後継社長は「強く言えない」立場に置かれやすい。契約書に明文化されたルールがあれば、それは関係性やパワーバランスに依存しない、客観的な判断基準として機能する。
法律上の建付けを知らないまま契約している後継社長が多い
日本の民法では、2020年の改正によって、従来「瑕疵担保責任」と呼ばれていた考え方が「契約不適合責任」という制度に整理された。これは、納品されたシステムが契約内容と異なる場合、つまり契約書や仕様書に定められた種類・品質・数量に適合しない場合に、開発会社が修補・代替物の提供・損害賠償・場合によっては契約解除といった責任を負うという、契約全般に関わる基本的な民法上のルールである。
この制度は法律上デフォルトで適用される考え方ではあるものの、契約書の中でその適用範囲や責任を負う期間、責任の上限額などを具体的に定めておかなければ、トラブルが起きたときに「どこまでが開発会社の責任で、どこからが発注者側の追加要望なのか」の切り分けが極めて難しくなる。多くの後継社長は、この制度の存在自体を知らないまま契約書に判を押している。知らないということは、契約書に何も書かれていなくても法律で守られていると誤解しているケースと、そもそもリスクの存在自体に気づいていないケースの両方を含む。どちらにしても、いざトラブルが起きた時点で初めてこの制度の存在を知り、契約書に何の手当もされていないことに気づく、というパターンが後を絶たない。
先代の「勘と経験」が通用しない領域であるという認識不足
先代が長年経営してきた会社であれば、取引先との人間関係や現場の慣習で、多少の行き違いは「まあまあ、そこは大人の対応で」という形で吸収されてきた歴史があるかもしれない。しかし、システム開発という領域は、先代が得意としてきた製造業や小売業の現場感覚とは異質なリスクを含んでいる。ソースコードの著作権は誰のものか、開発中に流出した個人情報の責任は誰が負うのか、リリース後にサーバーがダウンして売上が止まったときの損害はどう補填されるのか。これらは「人間関係で丸く収める」ことが構造的に難しい、技術的・法律的な問題である。
後継社長が「先代のやり方」を無意識に引き継いでしまい、システム開発という異質なリスクに対して同じ対応様式(つまり、契約書に細かく書かず、関係性で解決しようとする姿勢)を取ってしまうことが、トラブル条項の空白を生む最大の構造的原因だと言える。
「情報の非対称性」が後継社長側に不利に働く構造
システム開発の契約においては、発注者(後継社長側)と受注者(開発会社側)の間に、技術知識の量に大きな差がある。この情報の非対称性は、契約書の条項を検討する場面で如実に表れる。開発会社が提示してくる契約書のひな形には、開発会社側に有利な条項(責任の上限を低く設定する、検収期間を極端に短く設定する、再委託を自由に認めるなど)が自然に多く含まれがちである。これは開発会社が悪意を持っているというよりも、契約書のひな形自体が受注者側の弁護士や過去の経験に基づいて作られているため、構造的に受注者に有利な内容になりやすいという背景がある。
後継社長は、先代の代からシステム開発の契約に立ち会った経験がないことが多く、提示された契約書のどこが「標準的な内容」で、どこが「開発会社に有利に傾いている」のかを判断する材料を持っていない。この判断材料の欠如こそが、情報の非対称性の本質である。加えて、先代の代から付き合いのある開発会社であればあるほど、「今さら細かく確認するのも気が引ける」という心理的な壁が、情報の非対称性をさらに固定化してしまう。
「誰が交渉するのか」という社内体制の不備
中小企業の多くは、システム開発の契約交渉を専任で担う部署や担当者を置いていない。総務担当者が契約書の押印手続きを担当し、情報システムの担当者(いる場合)が技術的な要件を詰め、最終的な契約内容の是非は社長自身が判断するという分業になっていることが多い。しかし、この体制では「契約書の法的な妥当性」を専門的にチェックする役割が抜け落ちてしまう。
先代の時代であれば、先代自身が長年の経験と業界の相場観をもとに、契約書の妥当性を肌感覚で判断していたかもしれない。しかし後継社長は、その肌感覚をまだ持ち合わせていない。肌感覚の欠如を補うためには、社内の誰かが「契約書の法務チェック」という役割を明確に担う体制を作るか、外部の専門家(弁護士、中小企業診断士、商工会議所の相談窓口など)を頼る仕組みを、承継後早い段階で整えておく必要がある。この体制整備を怠ったまま個別の契約に場当たり的に対応していると、トラブル条項の空白は永久に解消されない。
システム開発特有の「工程の見えにくさ」がトラブルを増幅する
建築工事であれば、現場に足を運べば工事の進捗をある程度目視で確認できる。しかしシステム開発の工程は、ソースコードという専門知識がなければ読み解けない形式で進行しており、発注者側から見た「進捗の見えにくさ」がトラブルを増幅させる一因になっている。開発会社から「順調に進んでいます」という報告を受けても、実際に何が完成していて何が未完成なのかを、後継社長自身が検証する手段を持たないことが多い。
この見えにくさは、トラブルが発生した際にさらに深刻な問題を引き起こす。仕様通りに動作しないという不具合が見つかったとき、それが「開発会社の実装ミス」なのか、「そもそも要件定義の段階で発注者側の説明が不十分だった」ことに起因するのかを、後継社長自身が技術的に判断することはほぼ不可能である。この判断の困難さこそが、契約書に「検収の手続き」「不具合発生時の原因調査の方法」を明文化しておく必要性を高めている。工程が見えないなら、見えない部分をカバーする手続きを契約書側で用意しておく、という発想の転換が必要になる。
ケーススタディ1:仕様変更の泥沼で追加費用が請求されたケース
従業員45名の食品加工会社を父親から継いだ二代目社長の事例である。受発注管理システムのリプレイスを、先代の代から付き合いのある地元の開発会社に依頼した。契約書は簡素なもので、「委託業務の内容:受発注管理システムの開発」という一行だけが業務内容として記載され、詳細な仕様は別途「打ち合わせにより決定する」という一文で片付けられていた。
開発が進む中で、現場の担当者から「この画面にはこの項目も表示してほしい」「この機能も追加でお願いしたい」という要望が次々と出てきた。開発会社側は当初、口頭で「対応します」と応じていたが、開発が半年を過ぎたあたりから雲行きが変わった。追加要望のたびに個別の見積もりが提示されるようになり、最終的に契約時の想定金額の1.6倍近い金額が請求書として届いた。
社長が「なぜこんなに膨らんだのか」と問い合わせたところ、開発会社側の答えは「当初の契約範囲を超える要望が多数あったため、それぞれ別途の開発として計上している」というものだった。契約書には、どの範囲までが契約金額に含まれる「基本開発」で、どこからが追加費用が発生する「変更」なのかを区分する基準が一切書かれていなかった。さらに、変更が発生した場合の見積もりの出し方、承認の手続き、途中でキャンセルした場合の扱いについても何も定められていなかったため、後継社長は開発会社の言い値に近い金額を支払わざるを得ない状況に追い込まれた。
このケースで本来契約書に必要だったのは、まず基本契約の対象範囲を明確にする「仕様書」を契約書の一部として添付し、その仕様書に記載のない要望が出た場合の変更管理手続き(変更を要望する側が書面で申請し、開発会社が影響範囲と追加費用の見積もりを提示し、発注者が承認して初めて着手するという一連の流れ)を条項化しておくことだった。承認前に着手した作業については、原則として追加費用を請求できないという取り決めも合わせて入れておけば、開発会社側が先行して作業を進めてから後出しで金額を提示してくるという事態を防げたはずである。後継社長は結局、追加費用の一部を減額してもらう交渉に3ヶ月を費やし、開発会社との関係もぎくしゃくしたものになってしまった。先代からの付き合いだからこそ強く出られなかった、という悔しさを社長本人が語っている。
このケースをさらに詳しく振り返ると、問題の根は契約締結前の段階にまで遡る。もともとの見積書には「受発注管理システム一式」という漠然とした記載しかなく、画面数や機能一覧、データ移行の範囲といった内訳が明示されていなかった。社長は「専門的な内容だから開発会社にお任せするしかない」と考え、見積書の内訳を細かく確認しないまま契約に進んでしまった。もし契約前の段階で、社長自身か、あるいは現場の担当者を交えて「この業務で最低限必要な機能は何か」を書面に落とし込む作業を行っていれば、少なくとも基本契約の範囲がどこまでかという土台ができていたはずである。
また、このケースでは開発会社側からも「途中で要望が増えるのはよくあることなので、その都度対応します」という説明があったという。この言葉自体は間違っていない。システム開発において、開発が進むにつれて新しい要望が出てくることは自然な現象であり、それ自体は開発会社の不誠実さを意味しない。問題は、その「都度対応」がどのようなルールで金額に反映されるのかを、契約の時点で取り決めていなかったことにある。ルールがなければ、開発会社側は単価や算定根拠を自由に設定できてしまい、発注者側はそれを検証する手段を持たない。後継社長がこの経験から学んだのは、「要望が増えることは避けられないが、その扱い方は事前にルール化できる」という点だった。同社は次の契約更新の際に、変更管理の手続きを明文化した条項を追加し、以降のプロジェクトでは同様のトラブルが起きていないという。
ケーススタディ2:納品後に不具合が続出し責任の所在で揉めたケース
従業員28名の建築資材の卸業を継いだ三代目社長のケースである。基幹システムの刷新を大手ではない中堅の開発会社に発注し、約1年をかけてシステムが完成、納品された。しかし稼働開始からわずか2ヶ月で、在庫数の計算が実際の数量と食い違う不具合が頻発するようになった。現場は混乱し、得意先への納期回答を誤るというトラブルにまで発展した。
社長は開発会社に修正を依頼したが、担当者からは「稼働後の運用トラブルであり、システム自体の不具合ではない可能性がある」という回答が返ってきた。契約書を確認すると、納品後の不具合対応に関する条項が「納品後、瑕疵が発見された場合は誠意をもって対応する」という一文のみで、具体的にどの期間まで無償対応するのか、どのような不具合が対応範囲に含まれるのか、対応にあたっての検証手順や責任の切り分け方法についての定めが一切なかった。「誠意をもって」という言葉は法的にはほとんど意味を持たず、双方の解釈が食い違えばそれで終わりだった。
さらに厄介だったのは、この契約が2020年の民法改正前に結ばれた古い雛形を流用していたため、契約不適合責任に関する条項自体が実質的に更新されておらず、責任の存続期間(いつまで開発会社が責任を負うか)についての明記も欠けていたことだった。開発会社側の弁護士は「契約書に具体的な期間の定めがない以上、法律上の一般原則に従うべきだが、そもそも不具合の原因がシステム側にあるのか運用側にあるのか、客観的な検証手順が契約書に定められていないため、責任の所在を特定するための調査費用について協議したい」という趣旨の回答をしてきた。結果として、社長は本来無償で対応してもらえるはずの不具合修正のために、追加の調査費用まで支払う羽目になった。
このケースが教えてくれるのは、契約不適合責任という制度が民法上存在していても、それを実際に機能させるためには、契約書の中で「対応期間」「対応範囲」「不具合発生時の検証手順」「責任の所在を判定する基準」を具体的に定めておく必要があるということだ。法律があるから安心、ではなく、法律が機能する土台を契約書に作っておかなければ、実務上はほとんど役に立たない。後継社長は「先代の代からの契約書のひな形を、民法改正後も一度も見直していなかった」ことを深く後悔したという。
このケースのその後についても触れておきたい。社長は最終的に、地元の商工会議所が実施している中小企業向けの無料法律相談を利用し、顧問弁護士のいない自社に代わって契約書の内容を確認してもらった。弁護士からの指摘は明快で、「対応期間の定めがない契約は、発注者側が最も不利になる典型例だ」というものだった。結果として、開発会社との間で改めて協議の場を持ち、不具合修正にかかった調査費用の一部を開発会社側に負担してもらう形で和解が成立した。しかし、この和解に至るまでに要した時間と労力、そして社内の混乱(得意先への納期回答の誤りによる信用の低下)は、契約書に対応期間と検証手順を明記しておけば避けられたはずのコストだった。
社長はこの経験を振り返り、「先代の時代は納品後のトラブルなど滅多になかったので、対応期間なんて気にしたことがなかった。しかし今のシステムは複雑で、稼働してから初めて見えてくる不具合も多い。契約書の役割そのものが、先代の時代とは変わってきているのだと痛感した」と語っている。この言葉は、事業承継後のシステム開発契約を考えるうえで象徴的な指摘だと言える。先代の時代の「常識」が、そのままでは通用しない領域が確実に存在するのである。
ケーススタディ3:担当者の退職とベンダー変更でデータが人質になったケース
従業員62名の運送業を兄から継いだ後継社長のケースだ。配送管理システムを地場の小規模な開発会社に発注していたが、システムを一人で開発・保守していた技術者が独立し、開発会社自体の事業継続が不安定になった。社長はリスクを感じ、別の開発会社にシステムの保守を引き継ぎたいと考えたが、ここで大きな壁にぶつかった。
契約書には、システムのソースコードやデータベースの構造に関する情報を発注者に開示する義務についての条項が存在しなかった。開発会社に問い合わせても、「ソースコードの提供は別途契約が必要」「データ移行の作業自体を弊社に依頼してほしい」という返答が続き、事実上、既存の開発会社にしがみつかざるを得ない状況、いわゆるベンダーロックインの状態に陥っていた。ソースコードは開発会社の資産であり、契約書上、発注者への開示義務が明記されていなければ、法律上も開発会社側に開示を強制する根拠は乏しい。
さらに問題を複雑にしたのは、この会社が扱う配送データの中に得意先の個人情報や取引条件などの機密情報が含まれていたことだった。契約解除や契約終了時に、システム内に保存されたデータをどのように返却・削除するかについての条項も存在しなかったため、社長は「もし今の開発会社と完全に縁を切ったら、自社の重要なデータそのものが取り戻せなくなるのではないか」という強い不安を抱えることになった。最終的には、旧開発会社に対して相応の対価を支払い、ソースコードの開示とデータの移行作業を依頼するという形で事態を収拾したが、当初の契約時にこの条項が入っていれば発生しなかったはずの余計な費用と時間だった。
このケースは、事業承継後の会社が特に陥りやすいリスクを象徴している。先代が長年同じ開発会社・同じ技術者に頼り切ってきた結果、契約上の取り決めがなくても「その人がいるから大丈夫」という体制になっていた。しかし後継社長の世代では、担当技術者の独立、開発会社自体の廃業や事業縮小といった事業継続性のリスクに直面する場面が増えている。契約書に「知的財産権の帰属」「ソースコード等の開示条件」「契約終了時のデータ返却・引き渡し手続き」を明記しておくことが、経営の継続性を守るための必須の備えになる。
補足すると、このケースの後継社長は、旧開発会社との交渉が難航している最中に、もう一つの選択肢として「システムを新規に作り直す」ことも検討したという。しかし、配送管理システムには数年分の取引履歴や得意先ごとの配送条件といった、業務上失うことのできないデータが蓄積されており、ゼロから作り直すという選択は現実的ではなかった。結局、旧開発会社に対して当初の想定を上回る対価を支払うことでソースコードとデータの引き渡しを受けることになったが、社長は「もし契約書に開示義務が明記されていれば、この対価はもっと低く抑えられたはずだ」と振り返っている。
このケースから得られる教訓はもう一つある。それは、システム開発の委託先を「個人の技術力」に依存させすぎることの危うさだ。開発会社という法人格であっても、実質的な開発作業を一人の技術者が担っているという体制は、中小規模の開発会社では決して珍しくない。後継社長がこのリスクに気づくためには、契約時に「本件業務の主たる担当者」を契約書上で確認し、体制の変更があった場合の通知義務を条項に加えておくことが有効である。これによって、担当者の退職や独立という事態が起きたときに、後継社長が早期に状況を把握し、対応を検討する時間的余裕を確保できる。
契約書に入れておくべきトラブル条項:実務チェックリスト
以下は、後継社長が開発会社との契約書を確認・作成する際に、最低限チェックしておきたい項目を整理したものである。すべてを一度に完璧にする必要はないが、少なくとも「この項目が契約書のどこに書かれているか」を自分の言葉で説明できる状態を目指したい。
1. 業務内容と仕様の明確化に関する条項
契約書本体に「業務内容は別紙仕様書による」と明記し、仕様書を契約書の一部として添付する形にする。仕様書がない、あるいは「詳細は打ち合わせにより決定する」としか書かれていない契約書は、後になって「何が契約に含まれていたか」を巡る争いの火種になる。仕様書自体が完全でなくても構わないが、少なくとも「何を作るのか」の骨格を書面に残すことが、その後のすべての判断基準になる。
条文のイメージとしては、「甲(発注者)及び乙(開発会社)は、本業務の内容が別紙『仕様書』に定める内容であることを相互に確認する。本契約締結後に仕様書の内容を変更する場合は、第◯条(変更管理)の手続きによるものとする」といった形で、仕様書と変更管理条項をセットにして書き込むのが実務上望ましい。仕様書自体を社長が一人で作成するのは難しいが、開発会社に作成を依頼した仕様書案を、必ず現場の担当者と一緒に読み合わせる工程を挟むだけでも、後々の食い違いを大きく減らせる。
2. 変更管理(仕様変更・追加開発)の手続きに関する条項
開発中に仕様変更や追加要望が生じることは、システム開発では珍しくない。問題は、それが「無償の範囲内」か「有償の追加開発」かを判断する手続きが決まっていないことだ。変更を要望する側が書面(メールでも構わない)で申請し、開発会社が影響(工期・費用)を見積もり、発注者が承認して初めて着手する、というフローを条項として明記する。承認前の着手については原則費用を請求できない、という一文を加えておくと、後出しの請求を防ぐ効力を持つ。
実務上は、「変更依頼書」という簡単なフォーマット(依頼日、依頼内容、想定される影響、見積金額、承認者の署名欄程度で十分)を契約書の別紙として用意しておき、開発期間中はこのフォーマットに沿ってすべての変更要望をやり取りするルールにしておくと運用しやすい。メールやチャットでの口頭に近いやり取りだけで進めてしまうと、後から「言った・言わない」の水掛け論になりやすいため、簡易であっても書面化する仕組みを契約書レベルで義務化しておくことに意味がある。ケーススタディ1のように、要望のたびに個別の見積もりが後出しで提示される事態を防ぐには、この変更管理条項が最も直接的に効く備えになる。
3. 検収(受入テスト)の基準と手続きに関する条項
「納品」と「検収完了」は同じではない。納品されたシステムが仕様通りに動作するかを検証する検収手続きの期間(例:納品後2週間以内)、検収で不備が見つかった場合の対応(修正して再検収)、期間内に発注者から異議が出なければ検収完了とみなす、といった一連の流れを明記する。検収基準が曖昧だと、いつまでも「まだ確認中」という状態が続き、支払いのタイミングも不明確になる。何をもって「完成」とみなすかという基準の立て方は、納品物は何をもって「完成」とするか、検収の基準を決めるでも掘り下げている。
検収の主体を誰にするかも、後継社長が見落としがちな論点である。検収作業を社長自身が行うのか、現場の実務担当者に委ねるのかによって、検収の精度は大きく変わる。実際に日々システムを使う現場担当者の目を通さずに検収完了としてしまうと、稼働後になって「現場が本当に必要としていた動きと違う」という問題が表面化しやすい。契約書に検収担当者や検収項目のチェックリストを明記しておくことで、検収作業の抜け漏れを防ぎ、支払いの条件を明確にできる。検収に合格した後も油断せず開発会社との関係をどう保つべきかは、検収に合格した後、開発会社との関係で気をつけたいことを参照してほしい。
4. 契約不適合責任(旧・瑕疵担保責任)に関する条項
前述の契約不適合責任について、対応の対象となる不具合の範囲、責任を負う期間(納品後何ヶ月・何年か)、対応方法(無償修補が基本か、代替物の提供か、損害賠償の範囲はどこまでか)を具体的に定める。特に「対応期間」を明記していない契約書は多いが、これがないと「いつまで無料で直してもらえるのか」が発注者側から見えなくなる。相場としては納品後6ヶ月から1年程度を定める契約が多いが、システムの規模や重要度によって変動するため、開発会社との交渉で妥協点を探る必要がある。
もう一点、実務上意外と見落とされがちなのが、対応期間の「起算点」である。「納品後1年」と書かれていても、その「納品」がいつを指すのか(検収完了時点か、実際に本番稼働を開始した時点か)が契約書内で統一されていないと、期間の解釈自体が争いの対象になる。稼働までに検収から数ヶ月の準備期間を要するシステムであれば、「本番稼働開始日から1年」といった形で起算点を明確にしておくほうが、発注者側にとって安全である。ケーススタディ2のように稼働後2ヶ月で不具合が出た場合でも、起算点が明確であれば、それが無償対応の範囲内かどうかを即座に判断できる。
5. 責任の上限額(損害賠償の範囲)に関する条項
システムの不具合によって発注者側に損害(売上の損失、取引先への損害賠償など)が生じた場合、開発会社がどこまで責任を負うのかを定める条項である。多くの契約書では、開発会社側の責任を「契約金額の範囲内」に制限する条項(責任限定条項)が入っていることが多い。これは開発会社にとって当然のリスク管理だが、発注者側としては、この上限額が自社の想定される損害規模と比べてあまりに低すぎないかを確認する必要がある。上限額の設定自体を拒否するのは難しいが、「故意または重大な過失がある場合は上限を適用しない」という例外規定を入れられるかどうかは交渉の余地がある。
後継社長が特に注意したいのは、自社の事業規模とシステムの重要度に対して、責任の上限額が見合っているかという視点である。たとえば基幹システムが停止した場合、1日あたりの売上損失が数百万円規模になる会社であっても、契約金額(たとえば数百万円)がそのまま上限として設定されていれば、実際の損害に対してまったく不十分な補償にしかならない。もちろん開発会社側にも、受託金額に対して無制限の責任を負うことへの抵抗があるのは当然であり、上限額をゼロにする交渉は現実的ではない。しかし、少なくとも「上限額がどの程度の損害を想定して設定されているのか」を双方で確認し合う対話自体には価値がある。あわせて、事業の重要度に応じて、システム停止時の損害を保険(サイバー保険など)でカバーするという選択肢も、契約上の上限額と並行して検討しておくとよい。
6. 知的財産権の帰属に関する条項
開発したシステムのソースコード、設計書、データベースの構造などの著作権・知的財産権が、発注者と開発会社のどちらに帰属するのかを明記する。多くの場合、発注者が開発費を全額支払った受託開発であれば、著作権は発注者に譲渡されるのが一般的だが、契約書に明記されていなければ、開発会社側に権利が残ったままになるケースもある。特に、将来的に別の開発会社に保守を引き継ぐ可能性を考えるなら、著作権の帰属とソースコードの開示義務は必ずセットで確認しておきたい。
なお、開発会社が自社独自の汎用フレームワークやライブラリ(複数の顧客に共通して使う部品)を利用している場合、その部分についてまで著作権の全面譲渡を求めるのは現実的ではないことが多い。この場合は、「本件のために新規に開発した部分の著作権は発注者に譲渡し、開発会社が従前から保有する汎用的な部分については、発注者に対して本システムの利用に必要な範囲で無償かつ非独占的な利用許諾を行う」といった形で切り分けるのが一般的な実務慣行である。この切り分けが契約書に明記されていないと、後になって「この部分は当社の汎用部品なので譲渡できない」という主張が出てきて、著作権の範囲を巡る認識の齟齬が生じることがある。
7. データの取り扱い・返却・削除に関する条項
契約終了時、あるいは契約期間中であっても、システムに保存されているデータ(顧客情報、取引データなど)を発注者がどのように取得・移行できるかを定める条項である。データのエクスポート形式、移行に必要な作業とその費用負担、契約終了後のデータ削除の期限と方法まで具体的に書いておく。ケーススタディ3のように、データが実質的に「人質」になってしまう事態を防ぐための最重要条項のひとつである。
具体的な文言としては、「本契約が終了した場合、乙(開発会社)は、甲(発注者)の求めに応じて、本システムに保存されたデータを甲が指定する形式で速やかに引き渡すものとする。データの移行に要する合理的な費用は、別途甲乙協議のうえ定める」といった条項を入れておくと、契約終了時に「データの引き渡しには別途高額な費用が必要」と一方的に主張されるリスクを下げられる。あわせて、日常的なバックアップの取得方法や保管場所についても契約書または覚書で確認しておくと、開発会社に依存しない形で自社が最低限のデータを保持できる体制を整えられる。
8. セキュリティインシデント発生時の責任分担に関する条項
個人情報の漏えいやサイバー攻撃によるシステム障害が発生した場合、どちらが第一次対応を行うか、通知義務(発注者への報告期限)、原因調査の費用負担、監督官庁への報告義務がある場合の対応主体を定める。近年、中小企業でもランサムウェア被害や取引先経由の情報漏えいが増えており、この条項の重要性は年々高まっている。
後継社長が意識しておきたいのは、セキュリティインシデントが発生した場合、発注者である自社にも一定の説明責任が生じるという点である。取引先の個人情報や機密情報を預かっている以上、インシデントの発生時には得意先への説明や、場合によっては個人情報保護委員会への報告が必要になるケースもある。契約書に「開発会社は、インシデントを認識した場合、24時間以内に発注者へ報告する」といった具体的な時間軸を書き込んでおくことで、自社側の対応(得意先への説明、行政への報告)を後手に回さずに済む。この条項が空白のままだと、開発会社からの報告が遅れ、自社の対外的な説明責任を果たすタイミングまで遅れてしまうという二次的な被害につながる。
9. 契約解除・中途解約に関する条項
開発が思うように進まない、あるいは開発会社の経営が不安定になったといった事情で、契約を途中で終了させる必要が生じた場合の手続きを定める。特に、どの段階まで進んだ作業に対して費用を支払う義務があるのか(既履行部分の対価)、解除通知の方法と期限、解除後の引き渡し義務(データやソースコードの返却)を明記しておく。
中途解約は、開発会社側の事情(経営不振、担当者の退職、対応品質の著しい低下など)によって発注者側から解約を申し出るケースと、発注者側の事情(事業方針の転換、予算の見直しなど)によって解約するケースの両方が想定される。どちらの場合でも、「解約時点までに完了している工程の対価をどう算定するか」という点が最も揉めやすい。工程ごとの対価をあらかじめ契約書または見積書の中で明示しておく(要件定義でいくら、設計でいくら、実装でいくらといった内訳)ことで、中途解約時の清算をスムーズに行える。逆に、一括の金額しか決まっていない契約では、解約時にどこまでの対価を支払うべきかについて、双方の主張が大きく食い違う可能性が高い。
10. 再委託(下請け)に関する条項
契約した開発会社が、実際の開発作業を別の会社や個人事業主に外注(再委託)する場合の取り扱いを定める。再委託そのものを禁止する必要はないが、少なくとも「再委託する場合は事前に発注者へ通知し、承諾を得ること」という条項を入れておくことで、誰が実際にシステムを作っているのかを把握できる状態を保てる。ケーススタディ3のように、実質的な開発者が個人技術者一人だったという事態は、再委託条項があれば早期に気づけた可能性が高い。
再委託先においても、秘密保持義務やセキュリティ対策が確実に適用されるようにしておくことも重要である。「乙は再委託先に対して、本契約における秘密保持義務及びセキュリティ対策に関する義務と同等の義務を課すものとし、再委託先の行為について乙が責任を負う」という一文を加えておくと、再委託先が原因でトラブルが発生した場合でも、契約上の窓口である開発会社に対して責任を追及できる体制を確保できる。
11. 保守・運用フェーズへの移行条件に関する条項
開発契約と保守契約が別立てになっている場合、開発完了後に自動的に保守契約へ移行するのか、別途交渉が必要なのかを明記しておく。保守契約の内容(対応時間、対応範囲、費用)が開発契約の中で「別途協議」とだけ書かれていると、納品直後に保守条件の交渉を迫られ、交渉力が弱い状態で不利な条件を受け入れざるを得なくなることがある。
保守契約の交渉は、開発契約を結ぶ時点、つまりまだ発注者側が「これから発注するかどうか」を選べる立場にあるうちに、大枠だけでも取り決めておくのが最も交渉力を保てるタイミングである。「開発完了後、甲乙は別途保守契約を締結するものとし、保守契約の月額費用は本契約の開発費用の◯パーセントを目安として協議する」といった形で、大まかな目安だけでも先に書き込んでおくと、納品直後に不利な条件を突きつけられるリスクを軽減できる。実際に契約更新の場面で何を確認し、何を受け取っておくべきかは、保守契約を更新する前に、開発会社から受け取っておくべきものにまとめている。
12. 反社会的勢力排除条項・秘密保持条項
これは開発案件に限らずほぼすべての業務委託契約に必要な基本条項だが、先代の代からの古い雛形にはこれらの条項が存在しないことも珍しくない。特に秘密保持条項は、開発の過程で開発会社に開示する自社の業務データ・取引先情報の取り扱いに直結するため、必ず契約書に明記されているか確認する。
よくある失敗パターン
失敗パターン1:先代の契約書をそのまま使い続けてしまう
最も多い失敗は、承継前から使われていた契約書のフォーマットを、内容を精査せずそのまま使い続けることである。先代が15年前、20年前に作成、あるいは開発会社から提示されたひな形をそのまま流用し、社名と金額だけを書き換えて発注を続けているケースは非常に多い。前述のとおり、2020年の民法改正で契約不適合責任の制度自体が変わっているにもかかわらず、契約書の条文が旧法の表現(「瑕疵担保責任」という言葉のまま)で止まっていることもある。後継社長になったタイミングは、実は契約書全体を見直す絶好の機会である。先代への敬意と、契約書の現代化は別の話だと割り切って、少なくとも一度は専門家(弁護士や中小企業診断士など)にレビューを依頼する価値がある。
見直しの進め方としては、いきなり全面的な契約書の改訂を持ち出すのではなく、まずは既存の契約書を「更新のタイミング」に合わせて段階的に見直すのが現実的である。多くの業務委託契約は1年更新や複数年更新の条項を持っているため、更新のタイミングで「せっかくの更新なので、契約内容も最新の基準に合わせて確認させてください」と持ちかけるのが、自然で角の立たない進め方になる。既存の契約が更新のタイミングを迎えていない場合でも、新規のプロジェクトを発注するタイミングで、その契約書だけでも見直すことから始めれば十分である。
なお、見直しの際に見積書と契約書の整合性を確認することも忘れてはならない。見積書には詳細な作業内訳が書かれているのに、契約書本体には「システム開発一式」としか記載されていない、というギャップは意外と多く見られる。トラブルが発生した際に法的な効力を持つのは契約書本体(および契約書が引用する添付書類)であり、見積書に書かれた内容が契約書に反映されていなければ、見積書の記載内容を根拠として主張することが難しくなる場合がある。見積書の内容を契約書の添付資料として正式に位置づける一文(「本契約における業務内容の詳細は、令和◯年◯月◯日付見積書及び別紙仕様書による」など)を加えておくだけでも、実務上の安全性は大きく高まる。
失敗パターン2:関係性の良さを条項の代わりにしてしまう
「この開発会社とは先代の代から長い付き合いだから、細かいことを契約書に書かなくても大丈夫」という発想は、承継後の経営者が最も陥りやすい罠のひとつだ。人間関係が良好であることと、トラブルが起きたときに適切に対応できる契約書が整っていることは、まったく別の問題である。関係性が良いからこそ、トラブルが起きたときに「言い出しにくい」空気が生まれ、条項が明記されていないことでその空気に押し切られてしまう。実際、良好な関係を維持したいのであれば、むしろ最初にきちんとした条項を取り決めておいたほうが、後々の言い争いや気まずさを避けられる。「契約書をしっかり作りたいのは、あなたを信頼していないからではなく、これから長く付き合っていきたいからこそ」という趣旨を、開発会社に率直に伝えることが有効な場合が多い。
この失敗パターンの根深さは、トラブルが実際に起きるまで表面化しないという点にある。関係性を条項の代わりにしても、何事もなく開発が終わる案件は少なくない。しかし、それは「関係性で乗り切れた」のではなく、「たまたま何も問題が起きなかった」だけであり、次のプロジェクトでも同じように運が良いとは限らない。ある後継社長は、10年以上トラブルなく付き合ってきた開発会社との契約を、内容を精査せず更新し続けていたが、11年目に発生した仕様の食い違いで初めて契約書の不備に気づいたという。10年間トラブルがなかったことが、契約書の質を証明するものではないという点を、後継社長は強く意識しておく必要がある。
失敗パターン3:契約書のレビューを社内の誰にも相談せず一人で判断してしまう
後継社長は、承継直後は社内に相談できる相手が限られていることが多い。先代の右腕だった古参の役員は技術やITの契約に詳しくなく、逆に情報システムに詳しい若手社員は契約書の法的な読み方に不安がある、というギャップがしばしば生じる。結果として、社長が契約書を一人で抱え込み、「よくわからないが、まあこんなものだろう」という感覚で判を押してしまう。契約金額が一定規模を超える場合は、顧問弁護士や中小企業向けの法律相談窓口(商工会議所の無料相談等)を一度は活用し、複数の視点でチェックする体制を作ることが望ましい。特にIT・システム開発の契約に詳しい弁護士は限られているため、可能であれば情報処理分野の契約実務に慣れた専門家を探すとよい。
社内の相談体制を整えるという観点では、たとえ専任の担当者を置く余裕がない中小企業であっても、「契約書のチェックリストを社長と現場担当者で一緒に確認する」という簡単な運用を仕組み化するだけで、一人で判断するリスクを大きく減らせる。本記事で紹介したチェックリストの12項目を、社内の打ち合わせの場で一つずつ確認し、抜けている項目があれば開発会社に質問する、という手順を社内のルールとして定着させることが、専門家に依頼するコストをかけられない小規模な会社にとっての現実的な第一歩になる。
よくある質問
Q1. 先代の代からの開発会社に「契約書を見直したい」と言うのは失礼にあたりませんか
失礼にはあたらない。むしろ、承継を機に契約実務を現代の基準に合わせることは、経営者としてごく自然な業務改善である。伝え方としては、「先代から受け継いだ会社として、これからも長くお付き合いしたいので、双方が困らないように契約書を今の基準に合わせて整理させてください」という趣旨で切り出すと、関係性を損なわずに進めやすい。良心的な開発会社であれば、契約内容の見直しに応じることに何ら抵抗はないはずである。逆に、契約内容の見直しを強く拒む、あるいは条項の追加を極端に嫌がる開発会社であれば、その対応自体がその会社との今後の取引を見直すひとつの判断材料になり得る。
Q2. 契約書に不備があった場合、今からでも修正できますか
すでに契約を締結し、開発が進行中であっても、双方の合意があれば契約内容を変更する覚書(変更契約書)を後から取り交わすことは可能である。特に、開発の初期段階であれば、開発会社側も柔軟に応じてくれる可能性が高い。逆に、納品直前や納品後になってから条項の追加を求めると、開発会社側から「今さら条件を変えるのか」と難色を示されることもあるため、契約内容の懸念に気づいた時点で早めに相談することが望ましい。すでに完了・納品済みのプロジェクトについては、覚書での手当てが難しい場合もあるが、次回以降の契約に向けた材料として、今回の経験を整理しておくことには大きな価値がある。
Q3. 契約不適合責任の対応期間はどのくらいに設定するのが一般的ですか
システム開発の契約書では、納品後6ヶ月から1年程度を無償対応期間として設定する契約が比較的多く見られる。ただし、これは法律で一律に定められた期間ではなく、あくまで契約当事者間の交渉によって決まる項目である。システムの規模、複雑さ、重要度(基幹システムかどうか)によって、適切な期間は変わってくる。開発会社側から提示された期間が短すぎると感じた場合は、その根拠を確認し、必要であれば延長を交渉する余地がある。重要なのは、期間が明記されていない契約書は避けるべきだという点である。
Q4. 契約書は自分たちで作成しても大丈夫ですか、専門家に依頼すべきですか
契約金額が小規模で、双方の関係性がすでに確立している場合は、本記事のようなチェックリストを参考に自社で条項を整理し、開発会社と協議しながら作成することも可能である。ただし、契約金額が大きい、システムが事業の中核を担う、あるいは初めて取引する開発会社である場合は、少なくとも一度は弁護士など専門家によるレビューを受けることを強く推奨する。多くの弁護士事務所や商工会議所では、中小企業向けの契約書レビューサービスや無料相談窓口を用意している。専門家に依頼するコストは、トラブルが実際に発生してから対応する費用と比較すれば、多くの場合はるかに小さい投資になる。
まとめ:契約書は「関係性を壊さないための道具」である
先代から会社を継いだ後継社長にとって、開発会社との契約書に細かい条項を追加することは、時に関係性を壊すリスクのように感じられるかもしれない。しかし実際には、その逆である。仕様変更の手続き、検収の基準、契約不適合が見つかった際の対応期間、データの取り扱い、契約解除の条件——これらを事前に明文化しておくことは、トラブルが発生したときに「関係性」や「声の大きさ」ではなく、書面という客観的な基準に基づいて解決策を探れるようにするための備えである。
言い換えれば、しっかりとした契約書は、良好な関係を長く維持するための道具でもある。何も決めずに進めた結果、後から感情的な対立に発展するよりも、最初に淡々と条件を取り決めておいたほうが、双方にとって気持ちよく仕事を進められる。先代の代からの付き合いを大切にしたいという気持ちがあるなら、むしろ契約書を今の基準にきちんと整えることこそが、その関係を次の世代に引き継いでいくための誠実なやり方だと言える。
本記事で紹介したチェックリストは、一度にすべてを完璧に満たす必要はない。まずは自社が今結んでいる契約書、あるいはこれから結ぼうとしている契約書を開き、12項目のうち何がすでに書かれていて、何が抜けているのかを確認することから始めてほしい。抜けている項目があれば、開発会社との打ち合わせの場で「この点についてはどう考えていますか」と質問を投げかけるだけでも、リスクの見える化につながる。承継後のシステム刷新という大きな決断の場面において、契約書という一枚の紙が、後継社長自身と会社を守る最も静かで確実な備えになる。
