30-100人規模で基幹システムの契約書・仕様書が見当たらないときの復元手順

ひとり情シスとして着任し、基幹システムの全体像を把握しようとキャビネットや共有フォルダを探しても、肝心の契約書や仕様書が見当たらない。担当していた社員はすでに退職していて、社長に聞いても「たぶん経理のどこかにあるはず」という曖昧な返事しか返ってこない。この状況は、社員30-100人規模のひとり情シスが最初にぶつかる壁として、驚くほど頻繁に起こります。

なぜこの規模で情報の散逸が起きやすいのでしょうか。0-10人規模であれば社長がすべてを把握しており、10-30人規模でもまだ関係者の記憶に頼れる範囲です。しかし30-100人規模になると、契約当時の担当者が異動・退職し、部署も細分化され、紙の書類は倉庫の奥、電子データは退職者のPCやメールボックスに残ったまま、という「ちょうど記憶と記録の間に落ちる」時期に差し掛かります。この記事では、そうした状況から契約書・仕様書を実務的に復元し、権利関係を洗い出す手順を示します。

なぜ30-100人規模で契約書が「消える」のか

契約書や仕様書そのものが完全に失われることは稀です。多くの場合、「存在はしているが、誰も所在を知らない」状態に陥っています。この背景には、成長期特有の3つの要因があります。

• 担当者の異動・退職による引き継ぎの欠落: 契約を締結した当時の担当者が、書類の保管場所を後任に正式に引き継がないまま異動・退職している
• 紙と電子の二重管理による分散: 契約書の原本は紙で経理のキャビネットに、仕様書や見積書はメールの添付ファイルとして個人のメールボックスに、というように保管形式がバラバラで、どちらか一方しか探さないと見つからない
• 部署の細分化による管理主体の不明確化: 契約当時は総務が一括管理していたが、その後総務・経理・情シスに業務が分かれ、「今どこが管理すべき書類か」の合意が更新されないまま放置されている

こうした状態は属人化の一形態と捉えることができます。書類の所在という情報そのものが、特定の個人の記憶に依存していたということです。復元の作業は、単に紙を探す作業ではなく、この属人化した情報を組織の記録として作り直す機会でもあります。

ここで強調しておきたいのは、「契約書・仕様書が見当たらない」という事態は、決して珍しいトラブルではないということです。専任の情シスがいない期間が長かった会社ほど頻繁に起きており、あなた自身の落ち度でも、前任者の重大な過失でもありません。焦って自分を責めたり、逆に前任者を過度に責めたりする必要はなく、淡々と実務として復元を進めればよい、という前提でこの先を読み進めてください。

復元にどのくらいの時間がかかるか、目安を持っておく

復元作業に着手する前に、大まかな所要期間の見通しを持っておくと、本業との兼任スケジュールを立てやすくなります。会社の状況によって幅はありますが、目安として次のように考えてください。

• 社内の保管場所を一通り確認するまで: 数日〜2週間程度。ただし退職者のPCの初期化状況の確認など、情シス以外の部署(総務・経理)の協力が必要な項目があるため、依頼してから回答を待つ時間も含まれます
• 開発会社への照会と回答待ち: 1〜3週間程度。開発会社側の書類保管状況や繁忙期によって前後します
• 見つかった情報の整理・権利関係の分類: 数日〜1週間程度。情報量にもよりますが、この作業自体はあなた1人で完結できます

全体としては、着手から一段落するまでおおよそ1〜1.5ヶ月程度を見込んでおくと、無理のないスケジュールになります。本業の繁忙期と重ならないよう、着手のタイミングも意識してください。

着手前に確認しておきたい前提: 何を「見当たらない」と判断するか

復元作業を始める前に、そもそも「何が見当たらないのか」を具体的に定義しておくことをおすすめします。「契約書が見当たらない」という状態は、実は次の3パターンに分かれ、それぞれ対処の優先度が異なります。

1. どのシステムについて契約したか自体が分からない: 稼働しているシステムはあるが、そもそもいつ、誰が、どんな契約で導入したのかという前提情報が欠けている状態です。まずこの記事のステップ1で全体像を洗い出す必要があります
2. 契約したことは分かっているが、契約書の現物が見当たらない: 「〇年に発注した」という事実は分かっているが、書面そのものが行方不明の状態です。ステップ1・2で現物の所在を追跡します
3. 契約書はあるが、仕様書や納品物一覧が見当たらない: 契約の存在自体は明確でも、実際に何を、どこまで発注したかの詳細が分からない状態です。この場合はステップ2で開発会社への照会を優先し、当時のやり取りの記録を辿ります

自社の状況がこの3パターンのどれに近いかを最初に見極めておくと、無駄なく優先順位をつけて着手できます。

復元作業の全体像: 3ステップで進める

契約書・仕様書の復元は、闇雲に探し始めると時間ばかりかかります。次の3ステップで、優先順位をつけて進めてください。

1. 社内の保管場所を体系的に洗い出す: 紙・電子データの両方を、想定される保管場所を網羅的に確認する
2. 社外(開発会社・専門家)への照会を並行する: 社内で見つからない場合、契約の相手方である開発会社に控えの提供を依頼する
3. 見つかった情報を権利関係の観点で整理し直す: 復元できた書類・できなかった書類を、権利関係の3分類(著作権・ライセンス・データ)で棚卸しする

ステップ1: 社内の保管場所を体系的に洗い出す

最初に着手すべきは、思いつくままに探すのではなく、保管場所の候補をリスト化してから、順番に確認していくことです。次の一覧を、チェックリストとして使ってください。

特に会社法・税法上、契約書や請求書などの帳簿書類には一定の保存義務期間が定められています。法人税法では帳簿書類の保存期間は原則7年とされており、経理部門がこの義務を果たすために契約関連書類を保管している可能性が高いため、経理への照会は優先度を上げて行ってください。

社内探索を進める過程で見つかった情報は、その都度システム管理台帳の形式で記録しておくと、後から二度手間になりません。台帳の作り方の基本は30-100人規模で複数部署から集まる野良システムの棚卸し優先順位でも扱っているので、あわせて参照してください。

社内探索を進める際、意外と見落とされがちなのが「電子契約サービスの利用履歴」です。近年は紙の契約書を交わさず、クラウドサインやDocuSignのような電子契約サービス上で契約を締結しているケースが増えています。この場合、原本は各サービスのアカウント内に保管されており、そのアカウントの管理者が誰かを特定できれば、比較的短時間で復元できます。逆に、契約当時の担当者の個人アカウントで契約が締結されていた場合、退職後にそのアカウントへアクセスできなくなっているリスクもあるため、早めに人事・総務側と連携してアカウントの所在を確認してください。

退職者のPCについては、情報セキュリティの観点から、退職時に速やかに初期化・返却する運用ルールが望ましいとされる一方で、そのルールが徹底されていると、まさに今回のように「退職者のPCに残っていたはずの資料」が失われている可能性が高くなります。この場合は、退職者のPCではなく、そのPCから送信されたメールの送信履歴(メールサーバー側にログが残っていることがある)や、共有フォルダへのアップロード履歴を辿る方が現実的な場合があります。

ステップ2: 開発会社・専門家への照会を並行して進める

社内での探索と並行して、契約の相手方である開発会社への照会も進めてください。契約書は当事者双方が保有しているのが通常であり、自社側で紛失していても、開発会社側に控えが残っている可能性は十分にあります。

照会の際は、次の点を明確に伝えるとスムーズです。

• 何を、いつの契約について探しているか: 「基幹システム一式の契約書一式」のように曖昧に伝えるより、「〇年〇月頃に締結した〇〇システムの開発契約書と、その際の仕様書」のように、分かる範囲で具体的に伝える
• 控えの提供方法(PDF・郵送等)を確認する: 電子データでの提供が可能であれば、後々の管理もしやすくなる
• 提供にあたり手数料や条件が発生するかを事前に確認する: 一部の開発会社では、旧い書類の再発行に事務手数料を求める場合がある

開発会社への照会は、窓口が社長個人の携帯電話や私用メールに一極集中しているような属人的な関係が続いている場合、誰に、どう連絡すればよいか分からないという壁にもぶつかりやすくなります。窓口の分散や組織的な連絡体制の整理については創業時に依頼した開発会社としか付き合いがない状態から抜け出す準備を参照してください。

契約書が開発会社側にも見当たらない、あるいは提供を拒まれるようなケースでは、社内の記憶を頼りに合意内容を再構成する必要が出てきます。この場合、仕様書が存在しないシステムをどう調査するかについては仕様書がないシステムを引き継いだときの調査手順が実務的な手順を示しています。

開発会社が廃業していたり、担当していた個人事業主と連絡が取れなくなっていたりする、より深刻なケースもあります。この場合、契約書の復元自体を諦めざるを得ないことがありますが、それでも次の2点だけは可能な範囲で確認してください。第一に、システムが稼働しているサーバー・ドメインの契約者情報(WHOIS情報やホスティング事業者の契約者名義)を確認することで、少なくとも「今、誰が管理者権限を持っているか」は把握できます。第二に、社内に残っている請求書・振込記録から、当時の取引内容や金額を逆算的に推測できる場合があります。完全な復元ではなくても、こうした周辺情報の積み重ねが、後々の判断材料になります。

開発会社が事業を継続している場合でも、担当していた個人が独立・転職し、法人としての開発会社に照会しても当時の経緯を知る人が誰も残っていない、というケースもあります。この場合は、法人としての開発会社に「契約書の控えの有無」だけを確認し、経緯そのものの復元は諦めて、現状のシステムの動作から仕様を逆読みする方向に切り替える判断も必要です。仕様書がない状態からシステムの仕様を読み解く具体的な手法は、先述の仕様書がないシステムを引き継いだときの調査手順で扱っています。

ステップ3: 復元できた情報を権利関係の3分類で整理する

契約書・仕様書の断片が集まってきたら、次はそれらを「何のための情報か」という観点で整理し直します。ここで有効なのが、著作権・ライセンス・データという性質の異なる3つの軸で分類する方法です。

既存の社内システムについて、著作権・ライセンス・データという性質の異なる3つの権利の軸を切り分けて棚卸しすることが、権利関係の整理の基本になります。

• 著作権: システムのソースコード・設計書の著作権が、自社と開発会社のどちらに帰属するか。契約書に譲渡条項の記載があるかを確認する
• ライセンス: 使用している市販ソフトウェア・ミドルウェアのライセンス条件、利用可能な範囲(ユーザー数・サーバー台数の上限等)
• データ: 業務で蓄積してきたデータそのものの権利と、そのデータを汎用形式で取り出せるかどうか

この3分類の詳しい確認方法はシステムの権利関係の整理: 納品物・ライセンス・データにまとめています。復元した契約書・仕様書を、この3分類のどこに位置づけられる情報かを見ながら読み直すと、「結局このシステムについて何が確定していて、何が不明なままか」が整理しやすくなります。

整理の際は、次のような簡易な一覧表を作ると、社内で共有しやすくなります。

このように「分かっていること」と「分かっていないこと」を分けて一覧化しておくと、経営層への報告や、後任者への引き継ぎの際にそのまま使える資料になります。すべての欄を埋め切る必要はなく、「不明」という記載も立派な調査結果です。

一部がどうしても見つからない場合の現実的な対応

社内・社外の両方を探しても、契約書や仕様書の一部がどうしても見つからないケースは実際にあります。この場合、無理にすべてを完璧に復元しようとするのではなく、次の優先順位で「割り切り」を入れることを検討してください。

1. 著作権の帰属に関わる書類は最優先で探す: 見つからない場合、著作権法上、原則として著作権は制作者(開発会社)側に残ります。この前提を踏まえて以後の判断をする必要があるため、優先度が最も高い
2. 稼働中のシステムに直結する仕様書は次点: 障害対応や改修時に必要になるため、口頭でのヒアリングも含めて内容の再構成を優先する
3. すでに解約済み・使われていないサービスの契約書は優先度を下げてよい: 現在進行形のリスクにはつながりにくいため、時間をかけすぎない

見つからない書類があること自体を隠さず、「〇〇は復元できたが、△△は見つからなかった」という状態を正直に台帳に記録しておくことが重要です。将来、同じ立場の後任者が同じ調査を繰り返さずに済むよう、「探したが見つからなかった」という事実そのものも記録として残す価値があります。

見つからないことを理由に経営層への報告を先延ばしにする必要もありません。「〇〇の契約書は社内・開発会社の両方で確認したが見つからなかった。現時点でのリスクは△△だが、実務上大きな支障は出ていない」というように、事実と現状のリスク評価をセットで報告すれば、それだけで十分な進捗報告になります。むしろ「見つからないまま黙って抱え込む」ことの方が、後になって問題が表面化したときの対応を難しくします。

復元後にやるべきこと: 再発防止の仕組み化

書類の復元作業が一段落したら、同じ問題を繰り返さないための仕組みを最低限整えておいてください。大掛かりな文書管理システムを新規導入する必要はありません。次の3点から始めれば十分です。

• 契約書・仕様書の電子データを、部署に依存しないクラウドストレージに一元保管する: 個人のPCやメールボックスへの依存をなくす
• 保管場所と閲覧権限を持つ担当者を、システム管理台帳に明記する: 「誰が」「どこに」保管しているかを常に追跡できる状態にする
• 契約更新・担当者異動のタイミングで、書類の所在を確認するルールを決める: 異動・退職時のチェックリストに「契約関連書類の引き継ぎ」を1項目として加える

台帳の継続的な運用方法については属人化を防ぐ社内システム管理台帳の作り方も参考にしてください。

よくある失敗パターン

復元作業を進める中で実際に起きがちな失敗を3つ紹介します。

• 紙の書類だけを探して電子データを見落とす: 経理のキャビネットを確認して満足してしまい、メールやクラウドストレージに残っている電子データの確認が漏れるケースがあります。紙と電子の両方を、必ずセットで確認してください
• 開発会社への照会を後回しにしてしまう: 社内探索だけで完結させようとして時間がかかりすぎ、結果的に開発会社への照会が遅れることがあります。社内探索と並行して、早い段階で開発会社にも一報を入れておくと、全体の期間を短縮できます
• 見つかった書類を読み込まずに「復元完了」としてしまう: 契約書が見つかったこと自体に安堵し、その中身(著作権の譲渡条項の有無など)まで精査しないまま次のステップに進んでしまうケースがあります。見つけることと、内容を理解することは別の作業だと意識してください

よくある疑問

Q. 契約書が見当たらないこと自体が、法律上の問題になりますか。

契約書の紛失自体が直ちに法律違反になるわけではありませんが、税務調査の際に帳簿書類の提示を求められて提示できない場合、税務上不利な扱いを受ける可能性はあります。特に経理関連の書類については、早めに経理担当・税理士と連携して所在を確認することをおすすめします。

Q. 開発会社に照会したら、逆に足元を見られて費用を請求されませんか。

書類の再発行やデータの提供に、実費程度の手数料を求められることはありますが、それ自体は不当な要求とは言えません。ただし、法外な金額を提示された場合や、提供そのものを拒否された場合は、契約書の内容や著作権法上の原則に照らして、どこまで開発会社側に協力義務があるかを確認する価値があります。判断に迷う場合は専門家(弁護士等)への相談も選択肢に入れてください。

Q. 復元作業と並行して、他の業務(月次のシステム保守対応など)も進める必要があります。優先順位はどう考えればよいですか。

日々の運用に支障が出るような緊急対応がある場合は、そちらを優先してください。復元作業は多くの場合、即座に業務を止めるリスクには直結しないため、時間の融通が利く作業として位置づけ、まとまった時間が取れるタイミングに寄せて進めるのが現実的です。

Q. 複数の基幹システムがあり、すべてで契約書が見当たりません。どこから手をつければよいですか。

すべてを同時に進めようとせず、業務への影響度が最も大きいシステムから優先的に着手してください。判断基準としては、「そのシステムが止まると、どの部署の、どの業務が止まるか」を考えると分かりやすくなります。基幹の販売管理・会計システムのような、止まると即座に業務全体に影響が出るものを最優先とし、利用者が限定的な補助的システムは後回しにしても大きな問題にはなりにくいです。

まとめ: 復元は「探す」だけでなく「整理し直す」機会

30-100人規模で契約書・仕様書が見当たらない状態は、成長期特有の情報散逸の結果であり、特定の誰かの怠慢が原因とは限りません。焦らず、社内の保管場所を体系的に洗い出し、開発会社への照会を並行し、見つかった情報を権利関係の3分類で整理し直す。この3ステップを踏めば、たとえ一部の書類が見つからなくても、今後の判断材料としては十分な状態を作れます。

復元作業を終えた後は、その成果を自分の頭の中だけに留めず、必ず文書として残してください。せっかく苦労して復元した情報も、記録に残さなければ、あなた自身の異動・退職とともに再び同じ問題が繰り返されます。この記事のステップ3で作った権利関係の一覧表と、復元できなかった項目のリストを、そのままシステム管理台帳の一部として組み込んでおくことをおすすめします。台帳は完璧な状態を目指すのではなく、「今分かっていること」を正直に反映した、生きた記録として運用し続けることに意味があります。

権利関係の整理が終わったら、次はその内容を踏まえて費用面の見直しを検討する段階に進めます。社員数の増加に伴うライセンス費用の見直しは社員数増加でSaaSライセンス費用が急増したときの見直しタイミングを、実際にベンダーの変更を検討する段階になったらひとり情シスが1人で進めるベンダー変更のリスク低減ステップを参照してください。

最後にもう一度強調しておきたいのは、この復元作業のゴールが「完璧な書類一式を揃えること」ではないという点です。ゴールは、今の時点で分かっていること・分かっていないことを正確に把握し、それを後任者や経営層とも共有できる形にしておくことです。全項目が埋まらなくても、この記事の手順を一通り踏んだのであれば、それは十分に価値のある成果だと捉えてください。