BOOKS（AD）

技術的理由や契約の問題などでシステムの引き継ぎができないとき──7つのパターンと対策

2025/11/19 07:00

通知

　急にシステムの引き継ぎが必要になっても、様々な理由で引き継ぎができないことがあります。アクセス権がない、サーバーに実行ファイルしかないといった技術的理由や、未完成品かつ未払い、完全オーダーメイドの開発、サーバーの所有権が引き継ぎ元といった契約の問題など……。完全に引き継ぎができなくなるのを避けるには、こうしたパターンを事前に把握して対処しておくことが重要です。今回は書籍『システムの引き継ぎに失敗しないための本』（翔泳社）から、引き継ぎができない7つのパターンとその対策を紹介します。

通知

　本記事は『システムの引き継ぎに失敗しないための本担当者の交代、ベンダー変更、アウトソーシング化に対応できる！』の「第2章　引き継ぎ発生時の注意点」から一部を抜粋したものです。掲載にあたって編集しています。

技術的な理由からシステム引き継ぎができないとき

　まずは、技術的に引き継ぎができない場合を2つ紹介します。これらの問題が生じると、前任者や引き継ぎ元と連絡を取ることができない、もしくは非協力的であったときに障壁となり、引き継ぎができなくなるかもしれません。

　ただし、業者の場合はユーザー側が注意しておけば技術的な問題は解決できるため、初期納品時などのタイミングで気をつけておきましょう。

アクセス情報がない場合

　1つ目は、アクセス情報がない場合です。サーバーへのアクセス情報、データベースへのアクセス情報、外部サービスへのアクセス情報など、各種アクセス情報がまったくわからない場合はすべてのシステム、一部の場合は一部のシステムしか引き継ぎができません。外部サービスやクラウドサーバーなどであれば、問い合わせることで各種接続情報を入手できることもあります。

　しかし、社内にサーバーがあり、そのサーバーのログイン情報がわからなければお手上げです。このようなときには、まず接続情報を探してください。もしも見つからない場合は、似たシステムやサーバーなどを新規に構築します。

　接続情報がわからなくても、どのようなシステムかは説明できると思います。その説明を基に新規に構築するのです。本来システムは機能要件から入るものですが、「どのような機能がほしいか」はすでに定義されているため、工数が少し削減できます。

サーバーにあるものが実行ファイルのみの場合

　2つ目は、サーバーにあるものが実行ファイルのみの場合です。この解説を進めるにあたり、まずは実行ファイルとは何なのかを説明します。

　実行ファイルとは、コンピューターがタスクを実行するためのファイルです。これではまだイメージしにくいと思うので、システム引き継ぎをする際に必要な部分だけを説明します。この実行ファイルを生み出しているのは、プログラムです。プログラムには、実行ファイルを作成するものとしないものがあります。前者をコンパイラ言語、後者をスクリプト言語といいます。

　コンパイラ言語とは、コンパイラ処理を通じてソースコードを機械語（コンピューターが直接解釈・実行する言語）へ変換する作業を行い、実行ファイルを作成して処理させるプログラミング言語です。ここで理解してほしいのは、プログラムを実行するのは実行ファイルであり、ソースコードではないということです。主なプログラム言語には、C、C++、C#、Visual Basic、Javaなどがあります。

　スクリプト言語は、機械語への変換作業を省略して実行できるようにしたプログラミング言語です。ここも必要な点だけ説明すると、スクリプト言語は実行ファイルがなく、ソースコードのみでプログラムが実行されます。主なプログラム言語には、JavaScript、Python、Ruby、PHPなどがあります。

　まとめると、プログラムの中にはソースコードとは別に実行ファイルを作成するものがあり、実行ファイルがある場合、実際に動作するのは実行ファイルであるということです。

　ここからが本題です。サーバーへアクセスしたときに存在するのが実行ファイルのみの場合、引き継ぎができないことがあります。システム引き継ぎではソースコードが必要になります。構築された言語がスクリプト言語の場合は、サーバーにアクセスするとソースコードが手に入ります。つまり、サーバーにさえアクセスできれば、ソースコードが入手できるということです。

　一方、コンパイラ言語の場合は、実行ファイルをサーバーに置いておけばプログラムは正常に動作するため、サーバーにアクセスして手に入るのは基本的に実行ファイルのみです。ソースコードを置いておく意味はなく、サーバーに余計なものを置くことは推奨されないので、ソースコードはないのが本来の姿です。

　そのため、サーバーに実行ファイルのみの場合は、ソースコードの入手が困難になります。これを解決しなければシステムの引き継ぎはできません。「基本的に」としたのは、コンパイラ言語の場合でもソースコードをサーバーに置いていた事例があるからです。このおかげで問題なく引き継ぎができたことは多く、とても助かったことがあります。

　なお、慣れてくると開発された言語によって、サーバーに何がアップされているのかがわかるため、別途ソースコードの手配が必要かどうかは瞬時に判断できます。少し蛇足になりますが、コンパイラ言語のときは開発環境の構築手順もあるとスムーズに引き継ぐことができます。逆に開発環境の構築手順がないと引き継ぎ先が苦労するため、ソースコードと一緒に手配して入手しましょう。

技術的な問題のまとめ

　ここまで技術的な問題で引き継ぎができない場合を紹介しました。これらの問題が起こってからでは遅いので、アクセス情報やソースコードなどは社内の共有サーバーに置き、業者の納品が完了した段階で先方から入手しておきましょう。

　もし今の段階で手元にない場合は、すぐに情報をもらってください。これにより何か問題が発生しても、システム引き継ぎという最終的な選択を取ることができます。システム引き継ぎでは、サーバーやデータベースなどの各種接続情報、ソースコード（実行形式ではない）が必須なのです。

契約やシステム運用が理由でシステム引き継ぎができないとき

　ここでは引き継ぎができない理由として、契約関連や運用によって発生するものを紹介します。また、解決策がある場合は併せて解説します。残念ながら解決策がない場合もあり、その際は諦めるか、システムの新規構築が必要です。

未完成品かつ未払いである場合

　システム開発ではさまざまな販売形態がありますが、販売形態全体に共通していえるのが、基本的に未完成品かつ未払いである場合の所有権は現在の業者側にあるということです。通常、商品の売買では商品と金銭の引き換えで商品の所有権が購入者側に移転されます。支払いをしていないのに、商品の所有権だけが移転することは基本的にありません。「基本的に」としたのは、契約によって変更することができるからです。

　契約の中には所有権の移転時期として、納入時、検収時などと定める場合もあります。ただし、一般的には支払い完了時です。私も一度「移転時期を納入時と定める」と顧客側の担当弁護士から伝えられたことがあったため、交渉して支払い完了時に変更したことがあります。

　そのため、基本的には支払い完了時と考えてよいのですが、所有権が現在の業者側にあった場合には、システム引き継ぎができません。システムは通常、プログラムの集合体であり、システムを運用していくとプログラムの変更が必要なタイミングがあるからです。

　通常、所有者からの依頼があれば変更の対応ができますが、そうでない人からの依頼は引き受けることができません。厳密にいうと、必ずしもユーザー側が所有権をもっている必要はありませんが、引き継ぎ時には所有権をもつ現在の業者側の同意が必要です。

　私も時折、未完成品の引き継ぎ依頼があります。「今開発中だが、開発が完了しそうにないので引き継いでほしい」という内容です。このようなときには、引き継ぎができる場合とできない場合があります。

　できる場合は、現在の業者と交渉できる関係が保たれており、現在の業者がシステム引き継ぎに理解を示して同意するときです。つまり、システムの所有者である業者が改変を認めている場合に限ります。

　一方、係争直前で引き継ぎを依頼してくる場合があります。未完成品のため、所有権は現在の業者である可能性が高く、係争直前の関係ならば交渉も難しいことが多いです。

　それでも引き継ぎを行うのなら、現在の業者の同意を得てソース改変の許可をもらう、成果物の完成割合を話し合い、その分の費用を支払って所有権の移転を行うという手段があります。または、新しく作り直すことも選択肢のひとつとしてあります。

　ここまで、未完成品の場合を説明しましたが、未完成品ではなくとも引き継ぎができないこともあります。次からは販売形態ごとに解説していきます。

依頼元の依頼に基づくシステム受託開発（完全オーダーメイドの開発）の場合

　完全オーダーメイドの開発とは、その企業の特定の課題やニーズに合わせて、新規にソフトウェアやシステムを開発することをいいます。つまり、システム開発を行う際に、その依頼に基づきイチから開発を行った場合です。そのため、すべてその会社用にカスタマイズされたものであり、支払い完了と同時にシステムの所有権がユーザー側に移転していることがほとんどです。

　完全に所有権が移転している場合はまったく問題ありませんが、特許などを取得した技術が開発に使われている場合は一部権利を業者側が保有していることがあります。この場合、特許を得ている部分は変更が難しい可能性が高く、所有権の移転に制限をかけなければならないことがあります。

　このようなときに一番確実なのは既存の業者に連絡をして確認することです。引き継ぎをしたいときは、連絡が取れるのであれば一報を入れて確認するようにしてください。

パッケージシステムをベースにカスタマイズした場合

　パッケージシステムとは既製品のことで、製品として完成しているシステムです。標準的な機能が網羅されており、比較的安価で導入しやすいのが特徴です。しかし、会社によってはそれ以外にも、実装したい機能が出てくることがあります。そうした機能や処理をシステムに実装するためにカスタマイズがあります。

　パッケージシステムの契約では利用権を販売しており、所有権はベンダー側が保有し続けていることが一般的です。そのため、目的に沿った利用はできるものの、パッケージシステム自体の改変はできないことになります。

　また、カスタマイズを行った際、カスタマイズ部分はその企業用に作られたもののため、その部分の所有権のみを認めている場合も中にはあります。しかし、これを併せて利用権のみとする契約も存在します。

　いずれせよ、パッケージ部分とカスタマイズ部分を併せて1つのシステムのため、改変することは難しいでしょう。

　この場合の引き継ぎの問題点は、パッケージ部分の所有権、ないしは改変してもよい権利を既存ベンダーから得られるかということです。

　難しい場合、基本的に引き継ぎはできません。それでも引き継ぎの必要がある場合は、引き継ぎではなく、外付けのシステムを構築して対応することは可能です。私もそのような場合には、別途外付けのシステムを開発して対応したことがあります。

　ただ、理想は所有権ないしは改変してもよい権利をもらうことです。こうした権利をもらうときは、プログラムソースなども一緒にもらいます。ちなみに私の経験談ですが、権利とソースをもらうときに費用が発生したことがあります。

　パッケージシステム企業のA社が、ある事業から撤退することになりました。そこで、A社のパッケージを利用していたユーザー企業から、私の元に「システムを引き継いでほしい」と依頼がありました。そこで、パッケージのための権利とソースを確認することになり、A社から費用掲示があったという経緯です。

　確かに権利とソースが有料というのは理屈ではわかりますが、以前に似たケースを手がけた際は、「撤退するので、あとは自由に使用してよい」と無償でした。とはいってもA社からの所有権の移転がなければ、システムは引き継げないため、このときには仕方なく費用を支払って所有権を移転してもらいました。

SaaSなどのWebアプリケーションベースにシステム開発を依頼した場合

　次は、SaaSなどのWebアプリケーションベースにシステム開発を依頼した場合です。SaaSとは「Software as a Service」の略称で、サービス提供事業者（サーバー）側で稼働しているソフトウェアを、インターネットなどを経由してユーザーが利用できるサービスです。SaaSは、ユーザーごとにカスタマイズできないことが多かったのですが、最近はカスタマイズできるサービスが登場しています。

　では、この場合の所有権はどうなるのかというと、SaaSそのものはベンダー側に所有権があり、ユーザー側はそのシステムの利用権をもつというのが一般的です。また、カスタマイズ部分も多くは利用権となる場合が多いです。

　もちろん、契約によってさまざまな形態はあると思いますが、SaaS本体が利用権になることから、そのままでは引き継げないことがほとんどです。仮にカスタマイズを行ったとしても、本体に付随して初めて使えるもののため、本体自体の引き継ぎが難しい以上、カスタマイズ部分も引き継ぐことが難しいと考えてください。

　では、この場合は何もできないのかというと、そうではありません。SaaSではデータのダウンロードをできることが多くあります。データのダウンロードができれば、プログラムを引き継げなくてもデータは引き継げる可能性が高いです。

　ただ、ダウンロードされたデータはSaaS側が指定した形式のため、こちらの都合のよい形式にはなっていません。そのため、実際にデータを引き継ごうとしても、何らかの加工作業や取り込むプログラムの構築など、一手間必要になることは押さえておいてください。

サーバーの所有権が引き継ぎ元（業者など）の場合

　続いて、サーバーの所有権が引き継ぎ元である場合です。システムの所有権が引き継ぎ元の場合は前述の通りで、今回はあくまでもサーバーのみが引き継ぎ元である場合を解説します。システムとサーバーともに所有権が引き継ぎ元である場合は、両方の対応が必要なため前述のシステム部分も参照してください。

　では、システムの所有権はユーザーであるのに、サーバーの所有権が引き継ぎ元である場合とはどのような状況でしょうか。実際にあった私の経験をベースに紹介していきます。

本番サーバーが引き継ぎ元業者契約の共有サーバーに入っていた

　文字通り、本番サーバーとして稼働していたものが、引き継ぎ元業者のサーバーであった場合です。なぜこのような状況になったのかというと、初期の予算は多少あったものの毎月の予算があまりないときに、業者から「自社で管理しているサーバーであれば費用がほとんどかからない」と提案があったそうです。確かに、現在契約しているサーバーの領域に載せるだけなので、費用はあまりかからないかもしれません。

　しかし、それがのちのち問題となりました。その後、さまざまな事情からこのシステムの引き継ぎを検討することになりました。プログラムのソースはサーバー上にあるわけですが、そのサーバーは引き継ぎ元のサーバーであり、サーバーの中には第三者のプログラムが入っていたため、アクセスすることができません。

　この案件は最終的に引き継ぎ元の業者にプログラムをダウンロードしてもらうことでソースは入手できたもののサーバーの継続利用はできませんでした。

　そのため、新規でサーバーを立てて、そこにプログラムをアップして稼働させることになりました。ちなみにサーバーを立てるといっても、そのプログラムを稼働させる環境が完全にはわからなかったため、そのまま利用できたわけではなく、サーバーの環境に合わせてプログラムを修正することになりました。

　この事例では幸いなことに引き継ぎができましたが、サーバーの所有者が引き継ぎ元である場合はアクセスすらできないことが多く、少なくともそのままサーバーを継続利用することはできません。また、サーバーの環境情報の入手が非常に困難なため、プログラムだけをもらってもそのまま改変せずに動作させるのは難しいことが多いです。

　ちなみに、このようなことは少ないと思われるかもしれませんが意外に多く、私は何度も経験したことがあります。

パッケージシステムでサーバーも提供していた

　次はSaaSのような状態の事例ですが、パッケージシステムの契約をしたときにサーバーの運用も依頼していた場合です。プログラムの所有権は引き継ぎ元業者でも、サーバーはユーザーがもっていることがよくあります。しかし、この事例では、サーバー自体も引き継ぎ元の業者のものでした。

　そのため、前述したプログラムの対応に加え、サーバーの問題もクリアしなければ引き継ぎができないことになります。このサーバーがユーザー単体で利用されているものならば、有償で所有権の移転をすることで解決できますが、ユーザー単体でないときには新規で別のサーバーを用意する必要があります。

所有権の確認を行っていない

　所有権の確認は、引き継ぎを行う上での最重要事項です。システムの販売方式が利用権の売買になっていることもよくあり、「毎日利用しているから、これは自分のものだ」と勘違いしている人もそれなりにいます。システム引き継ぎを検討するときは、そのシステムの所有者は誰なのか契約書などを見返して、必ず把握するようにしてください。

システムの機能をわかる人がいない

　システムの機能をわかる人が誰もおらず、引き継ぎができない場合もあります。これはシステムのメイン担当者がいなくなった後、引き継ぎを開始したときなどに発生します。例えば、情報システムの担当者が引き継ぎをする十分な時間もないまま、急に退職し、その後に引き継ぎを開始するときです。

　このとき、どのような問題が起こるのかというと、例えば「この機能を修正してほしい」と依頼されて修正したとします。ところが、その機能を別の人が使っていた場合、「なぜあの機能が修正されたのか」とクレームがくる可能性があります。また、データ連携にも使われていた場合、修正したことで他システムが動かなくなることもあります。

　これでは、「これを直してほしい」「不具合だから復旧するように」と言われても、本当に修正するべきかが判断できません。