先代の急な引退や相続をきっかけに社長の椅子に座った方の多くが、最初にぶつかる壁は「営業」でも「資金繰り」でもなく、実は「システム発注」です。基幹システムの更新、ホームページの刷新、業務アプリの新規開発。先代が長年付き合ってきた開発会社やベンダーとの取引を、そのまま引き継ぐケースがほとんどでしょう。しかし、先代がどんな契約を結び、何にいくら払い、何を持っているのかを正確に把握している後継者は驚くほど少ないのが実情です。
本記事では、後継社長・後継者が社内のシステム発注担当として初めて発注書に印を押す前に、必ず確認しておくべき事項を「契約」「権利」「データ」「保守」の4つの切り口でチェックリスト化しました。開発会社の営業担当は決して嘘をつくわけではありませんが、契約書の細部まで丁寧に説明してくれるとは限りません。知らないまま進めると、数百万円単位の損失や、事業継続そのものを脅かすトラブルに発展することもあります。順番に見ていきましょう。すでに引き継いだ保守契約がある場合は、先代から引き継いだ保守契約、内容を確認せず放置していませんかもあわせて確認しておくと安心だ。
なぜ「発注前チェック」が事業承継のタイミングで特に重要なのか
先代経営者は、長年の付き合いの中で「あの会社に任せておけば大丈夫」という信頼関係を築いていたかもしれません。しかしその信頼関係は、契約書という文書の形で正しく残されているとは限りません。口約束や、名刺交換程度のゆるい関係のまま、何百万円もの開発案件が動いていたという話も珍しくないのです。
後継者が発注担当になる場面は大きく2つに分かれます。ひとつは、先代が結んだ既存の契約・システムを「引き継ぐ」場面。もうひとつは、自分の代になって新しいシステムを「発注する」場面です。前者では契約書や納品物の所在確認が、後者では発注前のリスク回避が主眼になります。本記事のチェックリストは両方に対応できるよう構成していますが、特に重要なのは「今まさに新規発注しようとしている」後継者の方です。なぜなら、先代の代のトラブルは既に固定化されていて対処のしようがない場合が多い一方、これから発注する案件は事前にリスクを潰せるからです。
中小企業庁が公表している「中小企業白書」でも、事業承継後の経営者が直面する課題としてIT・デジタル活用の遅れが繰り返し指摘されています。先代の時代に導入されたシステムがブラックボックス化し、誰も中身を把握していない「レガシーシステム」となって、身動きが取れなくなっている企業は少なくありません。これから新しく発注するシステムを、次の代にとってのブラックボックスにしないためにも、発注段階でのチェックが欠かせないのです。
チェックリスト1: 契約書まわりの確認事項
まず最も基本的でありながら見落とされがちなのが、契約書そのものの中身です。以下の項目を、発注前に必ず自分の目で確認してください。
契約形態が明記されているか
システム開発の契約には大きく分けて2種類あります。成果物の完成に対して報酬を支払う請負契約と、一定期間の業務遂行に対して報酬を支払う準委任契約です。どちらの形態かによって、発注者側の権利義務がまったく異なります。請負契約であれば「完成しなければ報酬を支払わなくてよい」という原則が働きますが、準委任契約では稼働時間や業務遂行に対して支払いが発生するため、成果物が思うようなものでなくても報酬支払い義務が生じることがあります。両者の違いをさらに詳しく知りたい場合は、請負契約と準委任契約、何がどう違うのかを参照してほしい。
契約書に「請負」「準委任」のどちらの文言も明記されていない、あるいは玉虫色の表現になっている場合は要注意です。開発会社に「これは請負ですか、準委任ですか」と率直に聞いてみましょう。まともな会社であれば即答できるはずです。答えに詰まるようであれば、契約内容を精査する専門家(弁護士や中小企業診断士)への相談を検討してください。
作業範囲が文書化されているか
「だいたいこんな感じのシステムを作ってほしい」という口頭の依頼だけで発注してしまうと、後になって「言った言わない」の水掛け論になりがちです。何を作るのか、どこまでが契約範囲に含まれるのかを明文化した文書、いわゆるSOW（作業範囲記述書）が契約書に添付されているかを確認しましょう。
作業範囲記述書がない、あるいは1枚のポンチ絵だけで済まされている場合、開発が進んでから「この機能は追加費用です」「これは契約に入っていません」という追加請求が頻発するリスクが高まります。逆に、作業範囲記述書がしっかり作られていれば、追加費用が発生する場面でも「これは元の範囲外だから」と双方が納得しやすくなります。発注前には、必ず作業範囲記述書の提示を求め、自社の要望がすべて盛り込まれているか、担当者だけでなく経理や現場責任者にも確認してもらいましょう。
検収の条件と期間が明記されているか
システムが完成した際に、発注者側が内容を確認して合格・不合格を判定する手続きを検収と呼びます。この検収の条件(何をもって合格とするか)と期間(何日以内に判定するか)が契約書に明記されているかを確認してください。
検収条件が曖昧なまま契約すると、明らかに不具合だらけのシステムでも「検収期間が過ぎたので自動的に合格とみなす」という条項によって、支払い義務だけが発生してしまうケースがあります。逆に発注者側が検収条件を厳しくしすぎると、開発会社側が「いつまでも合格をもらえない」というリスクを負うため、双方にとって現実的な基準を事前にすり合わせておくことが大切です。検収期間は一般的に1週間から1ヶ月程度が多いですが、システムの規模によって調整が必要です。自社の担当者が実際にテストする時間を確保できる期間になっているか、業務の繁忙期と重ならないかも合わせて確認しましょう。
支払い条件とスケジュール
前払い、着手金、中間金、完成後の一括払いなど、支払いのタイミングと金額配分を確認します。特に注意したいのは、開発がまったく進んでいない段階で高額な前払いを求められるケースです。もちろん一定の着手金は業界慣行として一般的ですが、総額の50%を超えるような前払いを求められた場合は、その根拠を確認してください。
また、支払いスケジュールが検収のタイミングと連動しているかも重要です。検収前に全額支払いを求められる契約は、発注者側のリスクが極めて高くなります。理想的には「検収完了後に残金を支払う」という条項が入っていることが望ましいでしょう。
契約解除・中途解約の条件
事業を進める中で、開発会社との関係がうまくいかなくなったり、経営環境の変化でプロジェクト自体を中止せざるを得なくなったりすることもあります。そうした場合に、どのような条件で契約を解除できるのか、解除した場合にそれまでの成果物や支払い済みの費用がどう扱われるのかを、事前に確認しておきましょう。
中途解約に関する条項がまったくない契約書も少なくありません。この場合、いざトラブルが起きたときに民法の一般原則に頼ることになり、交渉が長引く可能性があります。
チェックリスト2: 権利関係の確認事項
システム開発において、契約と同じくらい、あるいはそれ以上に見落とされがちなのが「誰がそのシステムの権利を持つのか」という点です。
著作権の帰属先はどこか
開発してもらったシステムのプログラムやデザインには著作権が発生します。日本の著作権法では、原則として「著作物を創作した者」に著作権が帰属します。つまり、何も取り決めをしなければ、発注者が費用を全額支払ったとしても、開発したプログラムの著作権は開発会社側に残ることになります。
これは多くの経営者が誤解しているポイントです。「お金を払ったのだから、そのシステムは全部うちのものだ」と思い込んでいると、後になって「このシステムをベースに別の会社に改修を頼みたい」「ソースコードを社内で保有したい」という場面で、開発会社から「著作権はこちらにあるので、それはできません」と言われてトラブルになることがあります。
契約書に「著作権は発注者に譲渡する」という条項があるかどうかを必ず確認してください。譲渡条項がない場合、少なくとも「利用許諾(発注者が自由に使ってよいという許可)」の範囲がどこまで及ぶのかを明記してもらう必要があります。特に、既存のシステムを改修する場合や、複数の開発会社を使い分ける可能性がある場合は、著作権譲渡または広範な利用許諾が確保されているかが極めて重要になります。
ソースコードの納品と保管
完成したシステムの「設計図」にあたるソースコードが、発注者に納品される契約になっているかを確認してください。意外に思われるかもしれませんが、ソースコードを納品せず、開発会社のサーバー上で稼働させたまま「利用料」だけを請求するビジネスモデルの契約も存在します。
このこと自体が悪いわけではありませんが、発注者側がそれを理解せずに契約してしまうと、将来的にその開発会社と縁を切りたくなったときに、システムを丸ごと作り直さなければならない事態に陥ります。ソースコードの納品を受ける契約であれば、納品後は必ず社内(あるいは信頼できる外部の保管サービス)でバックアップを取り、いつでも取り出せる状態にしておきましょう。担当者の退職や異動で「ソースコードがどこにあるか誰も知らない」という状態になっている中小企業は、実際にとても多く存在します。
第三者ライブラリ・OSSのライセンス確認
現代のシステム開発では、ゼロからすべてのプログラムを書くのではなく、オープンソースソフトウェア(OSS)や外部の部品(ライブラリ)を組み合わせて開発するのが一般的です。これらのライブラリにはそれぞれ独自のライセンス条件があり、中には「商用利用する場合は追加のライセンス費用が必要」「改変した場合はソースコードを公開する義務がある」といった制約を持つものもあります。
発注者としては、使用しているライブラリの一覧とライセンス条件について、開発会社から説明を受けておくことが望ましいです。特に将来的に他社に事業譲渡したり、システムを他社に販売したりする可能性がある場合は、ライセンス上の制約が事業計画の障害にならないか、事前に確認しておく必要があります。
独自開発(フルスクラッチ)かパッケージ・テンプレート利用か
既存のパッケージソフトやテンプレートをカスタマイズして作るのか、要件に合わせてゼロから設計・実装するフルスクラッチ開発で作るのかによって、権利関係も大きく変わります。パッケージ利用の場合、そのパッケージ自体の著作権は当然パッケージ提供元に残り、発注者が持てるのはカスタマイズ部分の権利だけというケースが一般的です。
自社の要望をどこまで実現したいのか、将来的にどこまで自由に改修したいのかによって、どちらの開発形態を選ぶべきかが変わってきます。開発会社から提案を受けた際は、それがパッケージベースなのかフルスクラッチなのかを明確にしてもらい、権利関係の説明も合わせて求めましょう。
チェックリスト3: データまわりの確認事項
意外と軽視されがちですが、システムに蓄積される「データ」の扱いも、契約前に必ず確認すべき重要事項です。
顧客データ・取引データの所有権と持ち出し可否
システムを通じて蓄積される顧客情報や取引履歴などのデータは、原則として発注者(自社)に帰属するべきものです。しかし、クラウド型のサービスやSaaS型のシステムを利用する場合、契約によっては「サービス提供者側の資産」として扱われ、契約終了時にデータを取り出せない、あるいは取り出す際に高額な費用を請求されるという事例が実際に発生しています。
契約前に「契約終了時にデータをエクスポート(取り出し)できるか」「エクスポートする場合、どのような形式(CSV、Excelなど、他のシステムでも扱える汎用的な形式か)で受け取れるか」「エクスポートに追加費用がかかるか」を必ず確認してください。これを怠ると、将来別のベンダーに乗り換えたくなったときに、実質的に「人質」に取られたような状態になり、乗り換えのコストが跳ね上がってしまいます。
データのバックアップ体制
システムに障害が起きたとき、データが失われないようにするためのバックアップがどのように取られているかを確認しましょう。バックアップの頻度(毎日なのか、週次なのか)、保管場所(自社サーバーなのか、クラウドなのか、両方なのか)、復旧にかかる想定時間(何時間、何日で元に戻せるのか)を、契約前の段階で開発会社に質問してください。
特に、顧客からの注文情報や決済情報を扱うシステムの場合、バックアップ体制の不備は事業継続そのものに関わる重大なリスクとなります。「バックアップは取っています」という曖昧な返答だけで済ませず、具体的な頻度と復旧手順を文書で確認することをお勧めします。
個人情報の取り扱いと委託先管理
顧客の氏名、住所、電話番号などの個人情報をシステムで扱う場合、個人情報保護法上の「委託先の監督義務」が発注者側に発生します。つまり、開発会社やシステムの運用会社に個人情報の取り扱いを委託する以上、発注者(自社)にはその委託先が適切にデータを管理しているかを監督する法的な義務があるのです。
契約書に個人情報の取り扱いに関する条項(秘密保持、目的外利用の禁止、再委託の制限など)が含まれているかを確認しましょう。特に近年は、開発会社がさらに別の下請け会社にデータ処理の一部を再委託するケースもあるため、再委託の可否とその際の責任の所在についても明記してもらうことが望ましいです。個人情報保護委員会のガイドラインでは、委託先の選定基準や必要かつ適切な監督の内容について具体的な指針が示されていますので、不安がある場合は一度目を通しておくとよいでしょう。
データの保存場所(国内か海外か)
クラウドサービスを利用する場合、データが物理的にどこのサーバーに保存されるのかも確認しておきたいポイントです。海外のサーバーにデータが保存される場合、その国の法律が適用される可能性があり、日本国内とは異なるデータ保護基準が適用されることがあります。業種によっては、データの保存場所に関する社内規定や業界ガイドラインが存在する場合もあるため、該当する場合は事前に確認しておきましょう。
チェックリスト4: 保守・運用フェーズの確認事項
システムは「作って終わり」ではありません。納品後の保守・運用フェーズでどのような契約になるのかも、発注前に必ず確認しておくべき事項です。
保守契約は別契約か、開発費に含まれるか
開発が完了した後、システムに不具合が見つかった場合の修正対応や、法改正・OSアップデートへの追従作業などは、通常「保守契約」という別の契約で扱われます。開発費用の中に何ヶ月分の保守が含まれているのか、その期間が過ぎた後の保守料金はいくらになるのかを、発注前の段階で確認しておきましょう。
「開発費が安い」と思って契約したら、実は保守費用が別途高額に設定されていて、トータルコストでは他社より高くついた、という失敗例は少なくありません。見積もりを比較する際は、開発費だけでなく、少なくとも3年程度の保守費用を含めたトータルコストで比較することをお勧めします。
保守対応の範囲と対応時間
保守契約に含まれる作業範囲(バグ修正のみか、軽微な機能追加も含むか)、対応時間(平日日中のみか、休日・夜間も対応するか)、緊急時の対応スピード(何時間以内に一次回答があるか)を確認しましょう。ECサイトなど、システム停止が売上に直結するようなサービスの場合、対応時間の条件は特に重要です。
担当者の退職・会社の廃業リスクへの備え
小規模な開発会社、特にフリーランスに近い個人事業主に発注する場合、その担当者が病気や独立、廃業などで対応できなくなるリスクも考慮しておく必要があります。契約時点で「もし担当者が対応できなくなった場合、誰が引き継ぐのか」を確認し、可能であればソースコードや設計書を定期的に自社側にも共有してもらう体制を作っておくと安心です。
これは冒頭で触れた「事業承継後にブラックボックス化したシステムを引き継ぐ」問題そのものです。自分の代で新たに発注するシステムについては、次の代(あるいは将来の自分自身)が困らないよう、属人化を避ける工夫を発注段階から組み込んでおきましょう。それでも実際に担当者と連絡が取れなくなってしまった場合は、システム引き継ぎ・レスキュー（運営会社ゼットリンカーの受託メニュー）のように、ソースコードやドキュメントがない状態からの調査・引き継ぎを専門に引き受ける会社に相談する選択肢もあります。
保守終了後の乗り換えやすさ
将来的に別の開発会社に乗り換える可能性を見据え、乗り換えに必要な情報(ソースコード、設計書、サーバーの管理権限、ドメインやDNSの管理権限など)がすべて自社側で把握・保有できる契約になっているかを確認してください。これらの情報が開発会社側に握られたままだと、乗り換えの際に高額な「引き継ぎ費用」を請求されたり、最悪の場合、乗り換え自体が事実上不可能になったりすることがあります。
発注プロセス全体で押さえておきたい進め方
ここまで契約・権利・データ・保守の4つの切り口でチェック項目を見てきましたが、これらを発注プロセスのどの段階で確認すればよいのかも整理しておきましょう。
まず、システムに何をしてほしいのかを整理し、開発会社に伝えるための提案依頼書、いわゆるRFP（提案依頼書）を作成する段階があります。この段階で「著作権は発注者に譲渡してほしい」「データはいつでもエクスポートできる形にしてほしい」といった、本記事で挙げた要望を盛り込んでおくと、後々の交渉がスムーズになります。提案依頼書を作らずにいきなり見積もり依頼をしてしまう中小企業も多いのですが、要望が整理されていないまま話を進めると、後になって「そんな話は聞いていない」という食い違いが生じやすくなります。そもそも開発会社に相談する前に社内で決めておくべきことは、刷新を開発会社に相談する前に、決めておきたい3つのことで解説している。
次に、開発会社から提案を受けて要件を固める、要件定義の段階があります。この段階で、開発会社が作成した要件定義書の内容を発注者側が理解し、合意する必要があります。専門用語が多くて理解しづらい場合は、遠慮なく「素人にも分かるように説明してほしい」と伝えましょう。まともな開発会社であれば、丁寧に噛み砕いて説明してくれるはずです。
そして契約締結、開発、検収、納品、保守開始という流れに進みます。本記事のチェックリストは、主に契約締結前の段階で確認すべき事項ですが、要件定義の段階から並行して意識しておくことで、契約書に落とし込む際の抜け漏れを防げます。
いきなり大規模開発をしない、という選択肢
後継者にとってもうひとつ重要な視点は、最初から完璧な大規模システムを一発で発注しようとしないことです。特に、先代から引き継いだばかりで、社内の業務フローや本当に必要な機能をまだ把握しきれていない段階では、まず必要最小限の機能に絞った試作版、いわゆるMVP（実用最小限の製品）の形で小さく発注し、実際に使ってみてから本格的な開発に進むという進め方が有効です。
小さく始めることで、契約金額のリスクを抑えられるだけでなく、開発会社との相性や仕事の進め方を見極める期間としても機能します。最初の小さな案件で、本記事に挙げたチェック項目(著作権の扱い、データのエクスポート可否、保守対応の質など)がきちんとしているかを見極め、問題がなければ本格的な発注へと進む、という2段階のアプローチをお勧めします。既存システムを直すか新しく作り直すかの判断タイミングについては、攻めのIT投資、既存システムを直すか新しく作るかを決めるタイミングも参考になる。
IT導入補助金を使う場合の注意点
システム開発の費用を抑えるために、国の補助金制度を活用したいと考える経営者も多いでしょう。中小企業庁が所管するIT導入補助金は、ITツール導入にかかる費用の一部を補助してくれる制度です。ただし、補助金を使う場合は、通常の発注プロセスに加えて、補助金の申請要件を満たすための手続きが必要になります。
補助金の対象となるITツールは、事前に事務局に登録された「IT導入支援事業者」が提供するものに限られるなど、独自のルールがあります。フルスクラッチ開発の場合は対象外となることもあれば、対象となる場合でも交付決定前に契約・発注をしてしまうと補助対象外になってしまうといった、時期に関する厳格なルールも存在します。補助金の活用を検討している場合は、本記事のチェックリストの確認と並行して、必ず最新の公募要領を確認し、疑問があれば事務局や商工会議所などの支援機関に相談することをお勧めします。補助金ありきで契約を急ぐと、本記事で挙げた契約・権利・データ・保守のチェックがおろそかになりがちなので注意してください。
よくある失敗パターン集
最後に、実際に中小企業の現場でよく見られる失敗パターンをいくつか紹介します。自社が同じ轍を踏まないための参考にしてください。
失敗パターン1: 先代の口約束を信じて契約書を確認しなかった 先代が「あそこは昔からの付き合いだから安心だ」と言っていたベンダーとの契約を、内容を確認せずにそのまま更新してしまい、実は著作権が全面的にベンダー側に残る内容だったと後から判明したケース。システムを他社に移管しようとした際に、想定外の高額な費用を請求されました。
失敗パターン2: 見積もりの安さだけで開発会社を選んだ 複数社から見積もりを取った際、最も安い会社を選んだところ、保守費用が別途高額に設定されており、3年間のトータルコストでは最も高い提案をしていた会社を上回ってしまったケース。見積もり比較は開発費だけでなく保守費用も含めて行うべきという教訓です。
失敗パターン3: データのエクスポート形式を確認していなかった クラウド型の販売管理システムを解約する際、データはエクスポートできると言われていたものの、実際に出てきたのは汎用性のないファイル形式で、新しいシステムに取り込むために追加の変換作業費用が発生したケース。契約前にエクスポート形式まで具体的に確認しておくべきでした。
失敗パターン4: 検収期間中に十分なテストができなかった 検収期間が1週間しかなく、繁忙期と重なったために現場担当者が十分にテストできないまま「みなし検収」で自動的に合格扱いとなり、後から重大な不具合が発覚したケース。検収期間は自社のスケジュールに合わせて交渉すべきです。
失敗パターン5: 個人事業主に発注し、廃業で連絡が取れなくなった 知人の紹介で個人で開発を請け負っているエンジニアに発注したところ、納品後しばらくして連絡が取れなくなり、軽微な不具合すら修正できない状態になったケース。ソースコードは受け取っていたものの、社内に読める人材がおらず、結局別の会社に一から解析を依頼する費用がかかりました。
発注前チェックリスト早見表
以下に、本記事で紹介した確認事項を一覧にまとめました。契約書にサインする前に、印刷して一つずつチェックしてみてください。
契約まわり
- 請負契約か準委任契約か明記されているか
- 作業範囲記述書が添付され、要望が漏れなく反映されているか
- 検収の条件と期間が明記され、自社のスケジュールに合っているか
- 支払い条件が検収完了と連動しているか、前払い比率が過大でないか
- 契約解除・中途解約の条件が明記されているか
権利まわり
- 著作権の帰属(譲渡か利用許諾か)が明記されているか
- ソースコードが納品される契約になっているか
- 使用している外部ライブラリのライセンス条件を確認したか
- フルスクラッチかパッケージ利用か、権利関係の違いを理解しているか
データまわり
- 顧客データ・取引データの所有権が自社にあると明記されているか
- 契約終了時のデータエクスポート可否と形式、費用を確認したか
- バックアップの頻度と復旧にかかる想定時間を確認したか
- 個人情報の委託先管理・再委託条項を確認したか
- データの保存場所(国内か海外か)を確認したか
保守まわり
- 保守契約の範囲と料金体系(開発費に含むか別契約か)を確認したか
- 保守の対応時間・緊急時対応スピードを確認したか
- 担当者交代・会社の廃業リスクへの備えを確認したか
- 乗り換えに必要な情報(コード・管理権限)を自社で保有できるか
FAQ
Q1. 先代が結んだ契約書が見当たりません。どうすればよいですか。
まずは経理担当者や顧問税理士に、過去の支払い記録から取引先の開発会社を特定してもらいましょう。契約書の写しがなくても、開発会社側に控えが残っている可能性が高いため、直接問い合わせて再発行を依頼するのが確実です。その際、著作権の帰属やソースコードの所在についても合わせて確認し、本記事のチェックリストに沿って現状を棚卸ししておくことをお勧めします。
Q2. 開発会社に「著作権を譲渡してほしい」と言うと、機嫌を損ねないか心配です。
著作権の帰属を明確にすることは、発注者としてごく一般的な要望であり、まともな開発会社であれば嫌がることはありません。むしろ、権利関係を最初にはっきりさせておくことは、後々のトラブルを防ぎ、双方にとってメリットがあります。もし著作権の完全譲渡が難しい場合でも、少なくとも「自社が自由に改修・再利用できる利用許諾」の範囲を明文化してもらうよう交渉しましょう。言いにくいと感じる場合は、専門家(弁護士など)を通じて確認する形にすると角が立ちにくくなります。
Q3. 小さな会社なので、契約書の細かい交渉をする時間も専門知識もありません。どうすればよいですか。
すべての項目を自社だけで判断する必要はありません。まずは本記事のチェックリストを使って、契約書の中で「明記されていない項目」をリストアップし、それを開発会社に質問するところから始めましょう。回答が曖昧な項目については、地域の商工会議所や中小企業診断士、ITコーディネーターなど、中小企業支援に詳しい専門家に相談する方法もあります。多くの自治体では無料相談窓口を設けているので、活用を検討してください。
Q4. すでに契約してしまった後で、著作権やデータの扱いに不安な点が見つかりました。今からできることはありますか。
契約後であっても、覚書(おぼえがき)という形で追加の合意事項を書面化することは可能です。開発会社に事情を説明し、著作権の帰属やデータのエクスポート条件について、追加の覚書を締結できないか相談してみましょう。応じてもらえない場合でも、少なくとも現状のデータについて自社でバックアップを取得できないか、担当者に確認しておくことをお勧めします。次回の契約更新や新規発注の際には、必ず契約前の段階で本記事のチェックリストを活用してください。
