DX

業務システムを頼んだ会社と連絡が取りづらい。今のうちにやっておきたい3つの備え

目次

「先月メールしたんですが、まだ返事がなくて。前は翌日には返ってきていたんですけどね」――業務システムの引き取り相談で、ヒアリングの冒頭にこの種のセリフを聞くことが、ここ1〜2年で目に見えて増えました。

開発を頼んだ会社が音信不通になったわけではない。請求書は今月もちゃんと届く。電話もつながる。ただ、返事が遅い。担当者が変わってから話の通じ方が違う。何かを頼んでも「確認します」のまま戻ってこない。そんな段階の相談です。

業務は今日も動いている。ベンダーが消えたわけでもない。だから後回しになりがちなのですが、引き取り案件の現場で言うと、この段階こそ動ける最後のタイミングです。連絡が完全に取れなくなってからではできないことが、まだいくつもできます。今からやっておくと効く3つの備えを、現場の温度感のまま整理します。

「最近、あの会社から返事が遅い」と感じたときに起きていること

返信が遅くなる、担当者がころころ変わる、話が通らなくなる。こうした変化の裏では、ベンダー側の組織が静かに痩せていることがほとんどです。倒産や夜逃げの話ではなく、もっと地味な縮小が起きています。

弊社にご相談が来る段階で、ベンダー側に何が起きていたかを後から聞き出すと、共通するパターンがいくつかあります。

  • 担当エンジニアが退職し、後任が決まらないまま在籍メンバーで案件を回している
  • ベテラン担当者の引退や新規採用難で人員が薄くなり、優先順位の低い既存顧客から対応が後回しになっている
  • 元請けが廃業・統合し、保守だけが別会社に引き継がれて、現場の知識が断片化している
  • 経営者がそろそろ事業整理を考えていて、新規開発から保守だけの体制に絞り込んでいる

どれも「悪い会社」だから起きるわけではありません。中小の開発会社で人手の縮小が進んでいるなかでは、長く付き合ってきたベンダーほど、こうした変化の波を受けやすい構造にあります。

つまり「最近返事が遅い」は、ベンダー側の人手が薄くなっている初期サインとして受け取るのが現実的です。ここで動き出すか、動かないままもう1年待つかで、後の選択肢の幅がかなり変わります。「相手の都合が悪いだけ」「自分が神経質になっているだけ」と片づけずに、まず現状の整理から始めるのが安全です。

連絡が取りづらいまま放置すると、業務システムに何が起きるか

連絡が取りづらい状態を放置すると、業務システムは「動いているけれど、誰にも頼めない」資産に静かに変わっていきます。突然止まる話ではなく、徐々に手が出せなくなる話です。連絡が取りづらいまま放置すると、結果として実質的なベンダーロックイン状態に陥ります。

引き取り案件で繰り返し見るのは、次のような連鎖です。

最初は、軽い改修ができなくなります。請求書のフォーマットを少し直したい、税制改正に追従したい、新しい決済手段に対応したい――その程度の依頼に対して、見積もりだけで何カ月もかかる、そもそも返事が戻ってこない、という事態が出てきます。現場としては「言ってもどうせ動かない」が常態化し、依頼すること自体をやめてしまいます。

次に来るのが、セキュリティ更新の停滞です。OSやライブラリのサポート期限が切れても、対応する人手がベンダー側にありません。脆弱性が公表されていることは分かっていても、改修の影響範囲が読めないからベンダーも手を出せず、結果としてパッチ未適用のまま動き続けてしまいます。「動いているから大丈夫」がいちばん危ない、という総論は中小企業がシステム保守を後回しにできない3つの理由で整理しています。

そして最後に起きるのが、ベンダーの事業縮小・撤退と、「読めるエンジニアの母数」そのものの縮小が重なる事態です。古い言語やフレームワークを実戦で扱えるエンジニアは現役層が細っており、人材市場でもなかなか見つかりません。今のベンダーが対応をやめた段階で別の会社を探しても、引き受け手が見つからない、見つかっても保守料が高くつく、というのが現実です。この構造的な背景はレガシーシステムの運用管理を立て直す3つの手順でも触れています。

連絡が取りづらい段階で動ける手は、まだあります。動けなくなるのは、相手が完全に応答しなくなり、しかも引き継ぎ素材が手元に残っていない状態に陥ったあとです。そこに至る前にできる備えを、ここから順に見ていきます。

【備え1】ソースコードと環境情報の所在を確認する

最初にやるべきは、自社の業務システムを構成している「素材」が、いま物理的にどこにあるのかを確認することです。動くシステムがあっても、ソースコードと環境情報が手元にないと、別の会社に保守を頼むことすらできません。

確認したいのは、おおむね次の5点です。

  • ソースコード一式: ベンダー側のリポジトリにあるのか、自社側のサーバや共有ストレージにもコピーがあるのか
  • サーバ・クラウドの管理者権限: AWSやGoogle Cloudのルートアカウント、オンプレサーバのrootパスワード、SSHキーが自社で保管されているか
  • ドメイン・SSL証明書の契約者: 名義が自社になっているか、ベンダー名義になっていないか。更新通知が誰に届くか
  • データベースの接続情報とバックアップ: 接続情報を自社が把握しているか、バックアップは自社側のストレージにも残っているか
  • 外部連携の認証情報: 決済代行、メール配信、CRMなど、外部サービスに接続するためのAPIキー・アカウント情報の保管場所

このうち、特に見落とされやすいのが「ドメイン・SSL証明書の契約者」です。導入時にベンダー名義で取得したまま、名義変更されずに来ているケースが珍しくありません。証明書の期限切れで、ある朝突然サイトが見えなくなる、という事故の多くはここに原因があります。

仕様書はこの段階では揃っていなくて構いません。ソースコードと稼働環境さえ手元にあれば、別の開発会社が引き継ぐ前提のスタート地点は作れます。「ソースはあるが仕様書がない」状態からどう直していくかは仕様書のない業務システムは直せるのかで4段階に分けて整理しているので、必要に応じて参照してください。

ベンダーに「コード一式とサーバ管理者権限のコピーをいただきたい」と依頼すること自体は、契約上ふつうの行為です。ソースコードの取得（引き渡し）を依頼すること自体は、契約上ふつうの行為で、やましい話ではなく、業務継続のためのリスク管理として、堂々と切り出して構いません。返答に時間がかかる、あるいは渋られるようであれば、それ自体が次の備えにつながる情報になります。

【備え2】 契約書を読み直す ― ソースコードと納品物の扱いはどうなっているか

次にやりたいのは、当時の開発契約書を引っ張り出して読み直すことです。連絡が取りづらいベンダーから別の会社へ保守を移そうとしたとき、いちばん最初に詰まるのが、ソースコードの著作権と納品物の扱いです。

確認したい条文は、おおまかに3か所です。

1つ目は、開発成果物の著作権の帰属です。ソースコード・設計書・データベース構造の著作権が「ベンダーに帰属」となっているのか、「自社に譲渡」または「共有」となっているのか。ここがベンダー側に残っていると、別の会社にコードを渡して保守してもらう行為そのものに、ベンダーの許諾が必要になる場合があります。

2つ目は、保守の独占条項です。「本システムの保守は弊社が独占的に提供する」のような文言が入っていることがあります。これが入っていると、契約期間中は別の会社に保守を頼みにくくなります。期間の定めや解除条件もあわせて確認しておきたい部分です。

3つ目は、解約予告期間と、解約時の引き渡し範囲です。多くの保守契約は3〜6か月前の解約予告が必要で、解約時にソースコードや運用ドキュメントの引き渡しを義務づける条項が入っていることもあります。逆に、引き渡し義務が書かれていない契約も少なくありません。

ここで強調しておきたいのは、契約書を読んだ結果の解釈は、最終的には法律の専門家に確認するのが安全だということです。著作権法と契約条項の組み合わせで結論が変わる論点なので、「ソースをもらえる／もらえない」「保守を切り替えていい／いけない」の最終判断を、自社内だけ、あるいは記事の情報だけで下さないでください。グレーに見える条文があるなら、弁護士または開発会社の法務に相談する一手間は省かない方が、後で揉めません。

ベンダーロックインがなぜ構造的に起きやすいのか、契約書のどこを点検すれば見直しの起点が作れるかについては、保守費が妥当か分からない業務システムでも別の切り口から整理しています。費用の妥当性と引き継ぎ可能性は、契約書の同じ箇所を見れば両方分かることが多いので、合わせて点検すると効率的です。

契約書が見当たらない、というのもよくある相談です。当時のメールや見積書、請求書を時系列で並べると、契約条件のかなりの部分は再構成できる場合があります。「契約書がないからお手上げ」とは、まだ言わなくて構いません。

【備え3】 第二保守先の目処をつけておく

備え1・備え2で素材と契約条件が見えてきたら、3つ目にやりたいのが、第二の保守先の目処をつけておくことです。今すぐ乗り換える話ではなく、「いざというときに相談できる相手」を1社、関係としてだけ作っておく、という発想です。

ここで誤解しないでいただきたいのは、いま契約しているベンダーを切る前提ではないということです。連絡が取りづらいとはいえ、まだ動いてくれているなら、突然切り替える必要はありません。一方で、対応が完全に止まってから新しい相手を探し始めると、ソースの引き取り、現状把握、契約交渉のすべてを並行で進めることになり、判断材料が手元にないまま走り出す羽目になります。

第二保守先に求める条件は、新規開発が得意な会社とは少し違います。引き取り案件で繰り返し効いてくる観点は、次の4つです。

  • 仕様書がなくても、ソースコードと稼働環境から構造を読み解いて引き受けられるか
  • いきなり全面リプレースを勧めず、現状を引き取って段階的に直す選択肢を出せるか
  • 古い言語・フレームワーク・サポート切れOSに対応した経験があるか
  • 月額固定だけでなく、相談ベース・実働ベースなど、関係から作る契約形態を持っているか

このうち4点目に関しては、月額契約をすぐに二重で持つ必要はありません。最近は、月額契約を結ばずに必要なときだけ実働分を払う形（スポット保守・実働ベース）を扱う会社も出てきています。第二保守先を関係としてだけ作っておくときの、契約面でのハードルを下げる手段として知っておくと選択肢の幅が広がります。詳しくは使った分だけ払う業務システム保守で整理しています。

第二保守先として開発会社を選ぶときの観点は、社内SEが退職したときの後任選びとほぼ同じ構造になります。組織で支えてくれるか、特定の1人に依存していないか、診断から段階的に入れるか――この観点は社内SEが退職したら？システム保守を任せる開発会社の選び方で4基準に分けて整理しているので、選定時に並べて使ってください。

弊社の引き取り案件で言うと、塗装業（30名）・サービス業（50名以上）・製造業（50名以上）のいずれも、最初は「現状把握だけお願いしたい」「契約はまだ決められない」という診断ベースの相談から始まっています。診断レポートを材料に、今のベンダーとの関係をどう整理するかは経営判断として後から決められる、という入り方です。第二保守先の目処をつけるというのは、こうした診断1本から始められる種類の動きで、いきなり大きな決断を要求されるものではありません。

社内SEが退職したら？システム保守を任せる開発会社の選び方

保守を任せる開発会社を見極める4つの基準と、契約前に押さえる引き継ぎチェック項目を整理しています。第二保守先の選定にも使えます。

/blog/internal-se-resignation-maintenance/

やってはいけないこと ― 関係が悪くなる前に避けたい3つの動き

備えを動かすときに、つい踏みがちで、けれど後の交渉を難しくする動きが3つあります。いずれも、結果として実質的なベンダーロックイン状態を自ら強める方向に働きます。引き取り側として現場に入ったとき、「これは先にやらない方が良かった」と感じる典型を挙げます。

1つ目：感情的な抗議の連絡を入れる

返事が遅い、対応が薄い、という不満が溜まると、つい強めの文面でメールを送りたくなります。ただ、こちらが備えとしてやりたいのは、ソースコードの引き渡しや契約条件の確認といった、相手の協力が要る作業です。先に関係を悪くしてしまうと、本来素直に出てくる素材が出てこなくなり、結果として自社が困ります。連絡が取りづらい背景は、たいていベンダー側の人手不足や高齢化など、相手の組織側の事情です。ベンダーを悪者にしないフラットな姿勢で、業務継続のための依頼として淡々と進める方が、結果的に早く進みます。

2つ目：乗り換えを匂わせて牽制する

「他社にも相談しているので」と牽制したくなる場面はあるのですが、これをやると、ベンダー側の協力が一気に渋くなります。ソースコードの引き渡しを先延ばしにされたり、契約期間の解釈をめぐって揉めたりと、移行の難易度を自分で上げる動きです。第二保守先の相談は、ベンダーに告げずに静かに進めて構いません。これは抜け駆けでも背信でもなく、業務継続のための準備としてふつうの行為です。

3つ目：現状を整理せずに新しい会社へ相談する

ソースの所在、契約書の条文、過去の改修履歴、業務上の困りごとが整理されていない状態で「うちはどうしたらいいですか」と聞かれても、相談を受けた側は答えようがありません。最初の30分の打ち合わせは、ほとんどが現状ヒアリングに使われ、判断の入り口に立つだけで終わってしまいます。備え1・備え2である程度の素材を揃えてから第二保守先と話す方が、診断の精度も上がり、結果として自社にとって有利な進め方ができます。

この3つは、いずれも「相手に怒りをぶつけたい」「早く動きたい」という気持ちから出てくるものです。気持ちは分かるのですが、業務システムの引き継ぎは半年から1年単位で動く話なので、初動の数週間は感情と切り離して、淡々と素材を集めるところに使う方が、結果として自社の選択肢を広く残せます。

まだ動ける今、何から始めるか

ここまで読まれて、「うちもそろそろ動いた方がいいかもしれない」と感じた方は、次の3つを順に進めてください。

  1. ソースコード・サーバ管理者権限・ドメイン名義の所在を、手元のメモにでも書き出す。書けない項目があれば、それが最初に取り戻すべき素材です。
  2. 当時の開発契約書を引っ張り出し、著作権の帰属・保守の独占条項・解約予告期間の3か所を読み直す。読み切れない条文は、弁護士か開発会社の法務に相談する選択肢を残しておきます。
  3. 第二保守先の目処として、診断ベースで相談できる開発会社を1社探しておく。すぐ契約する必要はありません。関係として作っておくだけで、いざというときの立ち上がりがまったく違います。

3つとも、今のベンダーとの関係を壊さずに、自社の中だけで静かに進められる動きです。連絡が完全に取れなくなってからでは、どれもできなくなります。動ける段階のうちに、素材だけでも揃えておいてください。

弊社では、「いまの開発会社との関係を切る前に、もう1社の目を入れておきたい」という段階のご相談を、診断ベースでお引き受けしています。現状把握のレポートを材料に、今のベンダーとの関係をどう整理するか、第二保守先として弊社を関係に置くか、判断は後から決めていただいて構いません。料金は月額固定ではなく、実際に動いた分だけ請求する実働ベース（従量課金）で、使わない月の費用は発生しません。初回の診断は成果保証で、お預かりした内容が直らなかった場合は料金を頂きません。

システムレスキュー

開発会社が廃業した、担当者が退職した、仕様書が残っていない。そんな業務システムを引き取り、保守・改修を継続します。第二保守先としての関係づくり・診断ベースのご相談から対応しています。

/service/system-rescue/

契約形態の比較や、保守費を実働ベースに切り替える考え方は、次の記事も参考になります。

使った分だけ払う業務システム保守 ― スポット保守と実働ベース料金の現実解

月額契約を二重で持たずに、第二保守先として関係だけ作っておくときに使える契約形態を整理しています。

/blog/business-system-spot-maintenance/

関連記事