前任者が結んだ保守契約の中身が分からないまま運用している状態の点検方法

毎月、決まった金額が開発会社に振り込まれています。誰がいつ、どんな内容でこの保守契約を結んだのか、社内の誰に聞いても分かりません。前任者はすでに退職していて、契約書らしきものは総務のキャビネットのどこかにあるはずですが、探したことはありません。それでも今のところシステムは動いているので、疑問を持つ機会もなく毎月の支払いだけが続いています。

これは30〜100人規模の会社で、情シス担当者が初めて置かれた組織に非常によく見られる状態です。前任者が「なんとなく」引き継いだ、あるいはそもそも専任の前任者がおらず、総務や経営者が場当たり的に契約してきた保守契約が、内容不明のまま存在し続けています。この状態の危険なところは、何か問題が起きるまでは表面化しないという点です。障害が起きて初めて「この契約でどこまで対応してもらえるのか」が分からないことに気づき、開発会社との交渉が後手に回る、という事態が実際に起こります。

このガイドは、内容不明の保守契約を、業務を止めずに段階的に洗い出し、最低限確認すべき条項を点検する手順を示します。契約前に確認すべきチェックポイントは保守契約の内容を契約前に確認すべき理由に譲り、このガイドは「すでに結ばれてしまっている、内容不明の契約」をどう後から点検するかに焦点を当てます。

なぜ「内容不明の契約」は静かに危険なのか

内容不明の保守契約が問題化するのは、多くの場合、次の3つの瞬間です。

1. 障害が起きたとき: 「今回の障害対応はこの保守費に含まれるのか、追加費用が発生するのか」が分からず、開発会社の説明をそのまま受け入れるしかなくなります
2. 保守費の値上げを打診されたとき: 現在の契約範囲と提示された新しい金額を比較する材料がなく、妥当性を判断できません。保守費の値上げへの向き合い方は保守費の値上げを打診されたときの判断基準で扱っていますが、そもそも今の契約内容が分からなければ、その判断基準を当てはめることもできません
3. 開発会社を変更・解約したいと考えたとき: 解約条件、データの引き渡し義務、契約期間の縛りが分からず、身動きが取れなくなります

これらはいずれも、「契約内容を知らない」状態が続いた結果、選択肢そのものを失っている状況です。逆に言えば、内容が分かっていれば、障害時も値上げ交渉時も解約検討時も、自社に有利な材料を持って開発会社と話すことができます。契約の点検は、トラブルが起きてから慌てて行うものではなく、平時のうちに済ませておくべき「保険」に近い作業です。

洗い出しのステップ1: 契約書そのものを探す

最初のステップは、契約書の原本またはその写しを物理的に見つけることです。当たり前に思えるかもしれませんが、多くの会社ではこの段階でつまずきます。探すべき場所の候補は次の通りです。

• 総務・経理の書類保管庫: 紙の契約書は総務や経理が一括管理していることが多く、情シス担当者自身が保管場所を知らないケースがほとんどです
• 経営者・役員のメールボックス: 契約締結時のやり取りが経営者宛に届いていることがあります。経営者に直接尋ねるのが最も早い場合もあります
• クラウドストレージ・共有ドライブ: 電子契約サービス(クラウドサイン等)を使っている場合、契約書はそのサービス内、あるいは社内の共有ドライブにPDFとして保存されています
• 開発会社への直接照会: 社内のどこにも見当たらない場合、開発会社に「契約書の写しを再送していただけますか」と依頼することも有効です。多くの開発会社は契約書の控えを保管しており、快く対応してくれます

この段階で契約書そのものが見つからない、あるいは「口約束で始まって書面化されていない」ことが判明する場合もあります。これは軽視できない問題です。事業者間の取引であっても、委託内容や金額を記載した書面を交付する義務が下請代金支払遅延等防止法(下請法)で定められている取引類型があり、情報成果物(プログラム)の作成委託もこの対象に含まれます。書面が存在しない、あるいは著しく不十分な場合は、契約の実態そのものを開発会社との対話を通じて明文化し直す必要があります。

洗い出しのステップ2: 契約書がない・古すぎる場合の代替手段

契約書そのものが見つからない、あるいは見つかっても何年も前の内容で今の運用実態と合っていない場合、次の代替手段で実態を把握します。

1. 請求書・支払い記録を遡る: 経理の支払い記録から、毎月いくら、どんな名目で支払っているかを確認します。請求書の摘要欄に「保守費」「月額サポート費」などの記載があれば、契約の存在自体は裏付けられます
2. 開発会社に直接、現在の契約内容の説明を依頼する: 「今、どのような契約内容で、何が保守の対象になっているか、あらためて説明してもらえますか」と率直に尋ねます。前任者から十分な引き継ぎを受けていない旨を正直に伝えれば、多くの開発会社は状況を理解し、丁寧に説明してくれます
3. 過去のメールのやり取りを検索する: 契約更新時、金額変更時のメールが残っていれば、契約内容の変遷を追う手がかりになります

この段階で重要なのは、「分からないことを分からないと開発会社に伝えることを恐れない」姿勢です。前任者からの引き継ぎが不十分なのは情シス担当者本人の落ち度ではなく、正直に状況を伝えたほうが、開発会社側も的確な説明をしやすくなります。

契約の中身が分からないことを隠して、分かったふりで運用を続けるほうが、後々のトラブルのリスクは大きい。「引き継ぎが不十分で、契約の詳細を把握できていません。あらためて確認させてください」という一言は、担当者としての誠実さの表れであって、恥じる必要はない。

契約書がそもそも下請法の対象になる取引かどうか

やや専門的な話になりますが、契約書の点検にあたって知っておくと役立つ制度として、下請代金支払遅延等防止法(下請法)があります。この法律は、資本金の規模によって「親事業者」と「下請事業者」の関係にあたる取引について、委託内容・金額・支払期日などを記載した書面(いわゆる3条書面)を交付する義務を発注者側に課しています。プログラムの作成委託(情報成果物作成委託)もこの対象に含まれます。

自社が発注者としてこの法律の対象になる規模の取引かどうかは、双方の資本金額によって決まるため一律には言えませんが、もし対象になる取引であれば、開発会社(受託側)は本来、委託内容を明記した書面を交付されているはずです。点検の過程で契約書が見当たらない、あるいは内容が著しく曖昧な場合、この書面交付義務の観点からも、開発会社に対して「委託内容を明記した書面をあらためて発行してもらえないか」と依頼する根拠になります。

もっとも、下請法の適用関係の判断や、実際に義務違反が疑われる場合の対応は専門的な判断を要するため、疑問がある場合は無理に自己判断せず、顧問弁護士や商工会議所の相談窓口などを頼ることをお勧めします。ここで重要なのは、「委託内容を書面で残してもらうことは、決して過大な要求ではなく、法律上も想定されている当然のプロセスである」と知っておくことです。この知識があるだけで、開発会社に書面化を依頼する際の心理的なハードルが下がります。

点検すべき8つの条項

契約書(または開発会社からの説明)が手元に揃ったら、次の8つの条項を順に確認します。これは、契約前に確認すべき観点と重なる部分もありますが、「すでに動いている契約を後から検証する」という視点で、特に優先度の高い項目に絞っています。

この8項目のうち、特に見落とされがちなのが4番目の「更新条件」です。多くの保守契約は自動更新の形式を取っており、「更新拒否の通知は契約終了の◯ヶ月前までに書面で行う」といった期限が定められています。この期限を知らずに過ぎてしまうと、たとえ契約内容に不満があっても、望まないまま次の契約期間に自動的に入ってしまいます。契約書を見つけたら、まずこの更新期限だけでも先にカレンダーに登録しておくことをお勧めします。

「対応範囲」の確認が最も重要な理由

8項目の中でも、最優先で確認すべきは1番目の「対応範囲」です。これは、月々の保守費が具体的に何をカバーしているのかという、最も基本的でありながら最もトラブルになりやすい項目です。

対応範囲は、大きく次の3つのパターンに分かれることが多くあります。

• 障害対応のみ: システムが停止・異常動作した場合の緊急対応のみが含まれ、機能改善や軽微な修正は別途費用が発生する
• 障害対応+軽微な修正: 障害対応に加えて、一定時間内(月◯時間まで等)の軽微な修正作業も含まれる
• 障害対応+相談窓口: 障害対応に加えて、技術的な相談への回答(実作業は含まない)が含まれる

自社がどのパターンに該当するか分からないまま「何かあったら開発会社に頼めばいい」と思い込んでいると、実際に依頼したときに「それは保守費の範囲外なので追加費用が発生します」と言われて驚くことになります。月額保守費でどこまでカバーされるかを日々の運用の中で把握する具体的な方法は月額保守費で何をやってもらえるのかで詳しく扱っているので、対応範囲の条項を読んでもなお曖昧さが残る場合は参照してください。

契約不適合責任・保証期間の考え方

6番目の「検収・不具合対応の責任範囲」も、内容不明の契約でよく見落とされる項目です。民法では、請負契約における契約不適合責任について、注文者が不適合を知った時から1年以内に請負人へ通知しなければ権利を失うという原則があります(民法第637条)。しかし、この規定は契約書での合意によって変更可能な任意規定であり、実際の契約書ではこの期間が短く設定されている、あるいは無償対応の対象範囲が限定されているケースが少なくありません。

前任者が結んだ契約の場合、この条項がどう定められているかを把握していないまま日々の運用が続いていることがほとんどです。特に、システムを長期間(数年単位)使い続けている場合、そもそも「検収完了からすでに何年も経っているため、契約不適合責任の期間はとうに過ぎている」ということもあり得ます。この場合、現在発生している不具合は、無償修正ではなく有償の追加対応として扱われる可能性が高いと理解しておく必要があります。検収と契約不適合責任の関係性そのものについては初めて開発会社とやり取りする情シス1人目が検収で失敗しないための確認項目でも詳しく扱っています。

点検の結果、不明点や不安な条項が見つかった場合

8項目を確認していく過程で、「そもそもこの条項が契約書に存在しない」「記載はあるが曖昧で解釈に幅がある」という状態に行き着くことも珍しくありません。この場合、次の2つの対応を検討します。

1. 開発会社に確認・すり合わせを申し入れる: 「契約書のこの部分の解釈について、あらためて確認させてください」という形で、既存契約の運用実態を明文化する交渉を行います。これは契約書を新しく結び直すことまでは求めず、覚書やメールでの確認だけでも一定の効力を持ちます
2. トラブル時に自社を守る条項が不足していないか確認する: 特に損害賠償の上限や解除条件が曖昧、あるいは自社に不利な内容になっている場合は、次回の契約更新のタイミングで見直しを打診する材料にします。契約書に書いておくべきトラブル条項の一般論は契約書に書いておくべきトラブル条項にまとめられています

不明点をすべてその場で解消しようとする必要はありません。まずは「何が分かっていて、何が分かっていないか」を自分の中で整理し、リスクの大きい項目(対応範囲・解約条件・損害賠償の上限)から優先的に確認していく進め方が現実的です。

点検を1回で終わらせない: 定期的な棚卸しの仕組み化

契約の点検は、一度やって終わりにするのではなく、定期的に見直す仕組みにしておくことが望ましいです。理由は2つあります。1つは、契約内容が更新のたびに少しずつ変わっている可能性があること。もう1つは、点検した本人(自分自身)が異動・退職した場合、同じ「内容不明の契約」問題が次の担当者に引き継がれてしまうリスクがあることです。

点検結果は、次のような簡単な一覧表にまとめて社内で共有できる場所に保管しておくことをお勧めします。

この一覧表があれば、次に自分が異動・退職する際にも、後任者へそのまま引き継ぐことができます。属人化を防ぐという観点からも、契約点検の結果を個人の頭の中だけに留めず、書面(表)として残すことが重要です。この一覧表自体が、システムの棚卸し全体の一部としても機能します。棚卸しの進め方全体については属人化していた社内システム、引き継いだら最初に何を調べるか、およびシステム管理台帳もあわせて参照してください。

ケースで考える: 複数の保守契約が絡み合っている場合

30〜100人規模の会社では、1社の開発会社とだけ契約しているとは限りません。基幹システムはA社、ホームページはB社、社内ネットワークの保守はC社、というように、複数の契約が並行して存在していることも珍しくありません。前任者からの引き継ぎが不十分な場合、そもそも「何社と契約しているか」自体が把握できていないケースもあります。

この状態を点検する場合、まず着手すべきは契約の「洗い出し」であり、個別の契約内容を深掘りするのはその後です。次の手順で進めます。

1. 経理の支払い記録から、開発会社・IT関連企業への定期的な支払いを全て抽出する: 毎月・毎年、同じ相手に繰り返し支払っている記録があれば、それは何らかの契約が存在する証拠です
2. 抽出した支払い先ごとに、契約の存在と内容を1社ずつ確認する: 前述の8項目チェックを、契約の数だけ繰り返します
3. 契約同士の重複・矛盾がないか確認する: たとえば、A社との契約に「ネットワーク機器の保守を含む」と書かれているのに、C社ともネットワーク保守契約を別途結んでいる、といった重複が見つかることがあります。この場合、どちらが実際に対応しているのか、両社に確認が必要です

複数のベンダーと契約している状態(マルチベンダー)自体は珍しいことではなく、それぞれの専門性を活かす合理的な体制であることも多いです。しかし、対応範囲が重複していたり、逆にどの契約にも含まれていない「隙間」の業務が存在していたりすると、いざというときに「どちらに連絡すればいいか分からない」という事態を招きます。マルチベンダーの体制を取っている場合は特に、契約ごとの対応範囲を一覧化しておく価値が高くなります。

契約の点検と同時に、口座・請求情報の妥当性も確認する

契約内容の点検と合わせて、支払いに関する情報も確認しておくことをお勧めします。前任者が退職している場合、次のような点が古いまま放置されているリスクがあります。

• 請求書の宛先・送付先メールアドレスが、退職者や現存しない部署宛のままになっていないか: 請求書が正しく届いていない、あるいは重要な通知が誰にも見られていない可能性があります
• 支払い方法(銀行振込・口座振替等)の登録情報が現状と合っているか: 会社の口座変更があった場合、開発会社側の登録情報が更新されていないと、支払いトラブルの原因になります
• 契約担当者として登録されている社内の氏名が、退職者のままになっていないか: 開発会社からの連絡が、退職済みの前任者の連絡先に送られ続けている可能性があります

これらは契約内容そのものではありませんが、内容不明の契約を点検する過程で同時に確認しておくと、後々の連絡ミスや支払いトラブルを未然に防げます。特に「契約担当者の登録情報」がずれていると、開発会社からの重要な連絡(値上げの打診、更新期限の通知など)が自分に届かないまま見過ごされるリスクがあるため、点検作業の中で必ずセットで確認してください。

点検作業にかかる時間の見積もり

最後に、この点検作業全体にどの程度の時間がかかるかの目安を示しておきます。契約の本数や複雑さによって差はありますが、おおよその感覚は次の通りです。

• 契約書を探す: 社内に保管されていれば30分〜1時間程度。開発会社への照会が必要な場合は、返送を待つ時間を含めて数日〜1週間程度
• 8項目の点検: 1契約あたり30分〜1時間程度(契約書を読み込み、不明点をリストアップするまで)
• 開発会社とのすり合わせ: 1契約あたり、メールでのやり取りか短時間の電話・オンライン会議で30分〜1時間程度

契約が1本だけであれば、実質的な作業時間は半日もあれば終わる規模です。複数契約がある場合でも、一度に全てを終わらせようとせず、リスクの大きい契約(金額が大きい、対応範囲が生命線に関わる等)から優先順位をつけて、本業の合間に少しずつ進めていけば、無理なく完了できます。

前任者を責めても解決しない: 点検作業への向き合い方

内容不明の契約を目の前にすると、「なぜ前任者はこんな状態で引き継いだのか」という不満が湧くこともあるかもしれません。しかし、前任者が悪意を持って情報を隠していたケースはむしろ稀で、多くの場合は次のような事情が重なっています。

• 前任者自身も専任の情シスではなく、片手間で契約対応をしていた
• 契約当時の担当者(前任者のさらに前の担当者)からの引き継ぎがすでに不十分だった
• 退職・異動が急だったため、引き継ぎの時間そのものが確保できなかった

つまり、内容不明の契約は「誰か1人の落ち度」というより、組織として引き継ぎの仕組みを持ってこなかったことの結果であるケースがほとんどです。この点検作業を、前任者への不満のはけ口にするのではなく、「自分の代では同じ状態を次の担当者に残さない」という前向きな目的として捉え直すと、作業そのものへの心理的な負担も軽くなります。

点検を終えて一覧表を整備したら、それを社内のどこに保管し、誰がアクセスできるようにするかも決めておきましょう。自分だけが分かる場所ではなく、上司や、将来の後任者が見つけられる場所に置いておくことが、今回の「内容不明の契約」を繰り返さないための最も確実な対策です。

点検の過程で「そもそも不要な契約」が見つかることもある

契約を1つずつ丁寧に点検していく過程で、稀に「このシステムはもう使っていないのに、保守契約だけが自動更新され続けている」という契約が見つかることがあります。前任者の退職や部署異動の際に、システムの利用自体は終了していたにもかかわらず、契約の解約手続きだけが漏れてしまっていたケースです。

このような契約を見つけた場合、点検のついでにそのまま放置せず、次の手順で確認します。

1. 本当に誰も使っていないか、社内の関連部署に確認する: 情シス担当者の視点では「使われていない」ように見えても、特定の部署だけがひっそり使い続けている可能性もあるため、独断で解約に動く前に必ず確認します
2. 本当に不要と確認できたら、解約条件(予告期間・違約金の有無)を確認した上で、正式な解約手続きを進める: 契約書に記載された解約予告期間を守らないと、望まないまま次の契約期間に入ってしまうため、早めに着手します
3. 解約によって浮いたコストを可視化し、次の予算相談の材料にする: 「不要な契約を整理した結果、年間◯万円のコスト削減につながった」という実績は、情シス業務の価値を経営層に説明する際の具体的な材料になります

契約点検は、単にリスクを洗い出すだけの作業ではなく、こうした不要なコストを発見する副次的な効果もあります。予算の説明材料として使える形にまとめておくと、点検作業そのものの意義を社内に示しやすくなります。

まとめ: 「分からないまま払い続ける」状態を最初に脱する

前任者が結んだ内容不明の保守契約は、多くの場合、何か問題が起きるまで放置されがちです。しかし、内容を知らないまま毎月の支払いを続けることは、いざというときに自社が不利な立場に置かれるリスクを抱え続けていることと同じです。

点検の進め方を整理すると、次の3ステップになります。

1. 契約書を探す: 社内の保管場所、経営者のメール、開発会社への直接照会の順に確認する
2. 見つからない・古すぎる場合は代替手段で実態を把握する: 請求書・支払い記録・過去のメール・開発会社への説明依頼を活用する
3. 8つの条項を順に点検し、不明点や不安な項目は開発会社とすり合わせる: 特に対応範囲・更新条件・解約条件・契約不適合責任の4点は優先的に確認する

この3ステップは、一度にまとめて終わらせる必要はなく、本業の合間に少しずつ進めても構いません。重要なのは、「分からないまま」の状態を放置し続けないという意識を持つことです。

点検を終えた後も、この作業は一度きりで終わりにせず、半年〜1年に1回程度、同じ8項目を見直す機会を作ることをお勧めします。契約は更新のたびに条件が変わっていることもあり、また自社のシステム利用状況(従業員数の増減、業務フローの変化)によって必要な保守範囲そのものが変わっていくためです。最初の点検が最も時間のかかる作業であり、2回目以降は一覧表を更新するだけで済むため、負担は大きく下がります。

契約の点検が完了したら、開発会社との日常的な連絡体制の整備、検収の進め方の理解とあわせて、自社のIT運用の土台を固めていってください。前任者からの引き継ぎがほぼゼロという厳しい状況からのスタートであっても、契約・連絡体制・検収という3つの土台を1つずつ固めていけば、次に何かトラブルが起きたときに慌てず対応できる体制に近づいていきます。自社の状況を客観的に振り返りたい場合はひとり情シス危険度診断も活用できます。