システムの引き継ぎ｜コードがあっても引き継げない理由

開発会社を変えたいという相談で、最初に話題になるのはたいていソースコードです。ただ、コードが手元にあっても引き継げないことがあります。直したものを、動いているサーバーに反映できなければ、書き換えたところで画面は何も変わりません。そのサーバーやドメインを動かせるかどうかが、名義の話です。

引き継げる状態かどうかは、次の3つで決まります。

• 名義 — サーバー、ドメイン、外部サービスの契約が誰の名前になっているか
• 納品物 — ソースコードと、構成や設定が分かるものが手元にあるか
• 権利 — 機能を足したり作り変えたりしてよい権利が自社にあるか

欠けているものによって、次にやることが変わります。名義が相手のままなら、相手に頼まないと先へ進めません。納品物が無いなら、読み解くところから始まるので、調査に費用がかかります。権利が曖昧なら、機能を足す段で止まります。順番としては、自分だけで進められる名義の確認から始めるのが早いです。

名義・納品物・権利の3つは、引き継ぐ段になって慌てて揃えるものではありません。作り始めるときに決めておけば、システムは3つが揃ったまま動きます。決めておきたいのは、次の5つです。そのまま、いま動いているシステムを見るときの物差しにもなります。

効き方には順番があります。1つめの名義さえ自社なら、ほかが欠けても打つ手は残ります。逆に名義が相手だと、ほかが揃っていても動かせません。

実際に申し込みの手続きをするのは開発会社ですが、着手前に契約者名を自社にしてほしいと頼めば、通ることが多い項目です。ただし、相手が自社のサービスとして再販している場合は、自社名義にできないことがあります。そのときは、管理者アカウントをもらったうえで、契約が終わるときにアカウントごと引き渡す取り決めを代わりに求めておくと安心です。

3つめは見積もりに響きます。著作権を移す分の対価が乗るためです。金額を聞いたうえで決める形になります。IPAと経済産業省のモデル契約は、著作権の決め方を3案示していますが、どの案でも汎用的に使い回せる部分の権利はベンダ側に残します。そこまで求めると話がまとまりにくくなります。

右の列を見て、埋まらないところがあったなら、ここから先は、足りないものを順に足していく話になります。

洗い出しは、いまの開発会社に何も言わずに始められます。手元の請求書と、ログインできる管理画面を見るだけで半分ほどは埋まるはずです。埋まらなかった行が、そのまま相手に聞くことの一覧になります。

ドメインは、手続きの順番で60日止まることがある

ドメインには手続きが2つあります。管理している事業者を変えることと、登録者そのものを変えることです。似たものに見えますが別の手続きで、進め方も違います。

「.com」や「.net」のように、国ごとの区分ではない種類のドメインには、世界共通のルールを決めている団体（ICANN）の移管ポリシーがあります。登録者を変えた後の60日間は、ほかの事業者へ移せない扱いです。同じポリシーは、最終的に事業者を変えたいなら、登録者を変える前に事業者の移管を済ませるよう勧めています。順番を逆にすると2か月動かせないことがあります。

この60日は、事業者が断りの仕組みを用意している場合に限り、登録者を変える手続きより前に、登録者の側で外しておけます。後からは外せません。引き金になるのは登録者の氏名や組織名だけではありません。登録者情報として届け出ているメールアドレスの変更も、同じ扱いです。確認のついでに連絡先を自社宛へ直すと、それだけで2か月動かせなくなります。

JPドメインの場合、管理している事業者を変えるには、いまの事業者を通して認証コード（そのドメインごとの合言葉）を取ることになります。co.jp でも汎用のJPドメインでも同じです。通常は相手に動いてもらう形です。

ただし、相手が動かないままでも手がなくなるわけではありません。JPドメインを管理しているのは株式会社日本レジストリサービス（JPRS）です。いまの事業者が認証コードの提供やロックの解除を適切に行っていない。それをJPRSが確認した場合、JPRSが登録者に直接、認証コードを渡してロックを解除できる扱いがあります。JPRSが事業者に意思確認を頼み、10日以内に「登録者にその意思がない」という回答が返らなければ、意思があったものとみなす規定もあります。連絡が取れないだけなら、手は残っています。

クラウドは、アカウントごと渡せるかで話が変わる

自社の環境を、開発会社が契約したクラウドの上に載せている場合、3つの状態を分けて見ると、話が早くなります。開発会社の組織に、自社だけのアカウントやプロジェクトが切られているか。開発会社名義のアカウントが1つあるだけか。開発会社のアカウントの中に相乗りしているか。

1つめなら、公式の手段があります。Google Cloudには、プロジェクトの所属する組織を移す操作があり、サーバーやデータベースは原則として動いたままです。ただし、移す元の組織で移管先を許可する設定と、作業する人への権限付与が要ります。どちらも開発会社側の操作なので、頼まないと始まりません。受け取る側にも組織が必要で、Google WorkspaceかCloud Identityを契約すると作られます。上の階層で付けていた権限は外れるので付け直しが要り、請求先も自動では移りません。

AWSにも公式の手段があり、移す先の組織から招待を出し、移すアカウント側で受ける形です。ただし待機期間があります。受け皿の組織を新しく作った場合は作成から7日、相手の組織の中で作られたアカウントは作成から4日を過ぎないと移せません。引き継ぎの日程を引くときに効いてきます。

2つめ、つまり開発会社名義のアカウントが1つあるだけの場合は、ログインに使う情報と支払い方法をまるごと引き渡してもらう話になります。

3つめ、相乗りしている場合は、アカウントを移す手段がありません。環境を作り直して中身を移すことになり、費用は引き継ぎより構築に近くなります。見積もりを取る前に、どの状態かを聞いておきたいところです。

権限の整理は、順番を間違えると厄介です。先に、自社の管理者としてログインできることを実際に確かめる。そのうえで、前の開発会社から入れる権限を消す。逆にすると、誰も入れないアカウントができます。Google Cloudでは、組織やフォルダの階層で付いていた権限は移管で外れますが、プロジェクトに直接付いている権限は残ります。AWSでは、相手の組織の中で作られたアカウントに管理用の役割が自動で置かれ、組織から外しても消えません。自分で消すことになります。組織をまたぐと、組織側にまとめられていた請求のレポートは残りません。書き出せるのは相手の管理アカウントなので、移す前に頼んでおくと確実です。

著作権は「譲渡する」とだけ書いても足りない

契約書に「本件成果物の著作権は甲に譲渡する」とだけ書いてある場合、動かし続けるために必要な範囲の手直しはできます。ただ、機能を足したり作り変えたりする段になると止まります。作り変えに関わる権利は、名指しして書いていないかぎり、譲渡した側に残っていると推定されるためです。

見るのは、作るときに決める5つで挙げた2つの一文です。著作権法の第27条と第28条を名指ししたもの。そして著作者人格権を行使しないと定めたもの。前者が無いと作り変えの権利は譲渡した側に残っていると推定され、後者が無いと、権利を譲り受けていても作った側から異議を述べられる余地が残ります。文化庁の「誰でもできる著作権契約マニュアル」も、全部を譲り受けるなら前者を明記する必要があると書いています。手元の契約書に無ければ、譲渡まで求めなくても構いません。改修と、別の会社へ委託することを認める許諾を書面でもらう形でも進みます。譲渡より話が通りやすく、費用も抑えられます。別の会社へ出すことを認める旨は、書面に明記してもらう形にします。

納品物と権利は、契約に書かないと来ない

IPAと経済産業省の「情報システム・モデル取引・契約書」（第二版、2020年12月公表）は、成果物の著作権について3つの案を並べています。そのうち原則としているのは、ベンダに帰属させる案です。発注側に移す形にしたいなら、こちらから求めることになります。

ソースコードも同じです。同じモデル契約は、何を納めるかを個別の契約で決めるものとしています。納品物の一覧に書かなければ、ソースコードは納品されません。動くシステムを納めてもらったことと、ソースコードを受け取ったことは別です。

権利の所在が実際に詰まりの理由になることは、公正取引委員会が2022年2月に公表した官公庁の情報システム調達の調査にも出ています。既存の事業者と再び契約した事例があると答えたのは1,000機関でした。その1,000機関に理由を聞いた設問で、「既存システムの機能（技術）に係る権利が既存ベンダーに帰属していたため」を挙げたのが243機関、24.3%です（複数回答）。市販のパッケージソフトを入れている機関も含まれる、という注記が付いています。対象は国と自治体ですが、詰まる箇所は変わりません。

終わり方の取り決めは、自分で足す

同じモデル契約に、契約が終わるときに後任の会社へ引き継ぐ義務の条項はありません。資料を返す条項はありますが、いずれも発注側が貸したものを返してもらう向きです。逆向きの取り決めは、書き足さない限り存在しません。いま契約が続いているなら、次の更新のときに1文を足せます。契約が終わるときは、後任の会社への引き継ぎに協力する。有償で構わないので、範囲と期間も一緒に書きます。

引き継ぎの相談は、受ける側が断ることがあります。よくあるのは6つで、こちらで先に手を打てるものがほとんどです。

断られた場合にできることは2つです。1つは、調査だけを切り出して発注し、引き継げるかどうかの判断材料を作ること。もう1つは、作り直しに切り替えることです。どちらを選ぶにしても、断られた理由を聞いておくと次の相談が早く進みます。

続けたほうがよい場合から挙げます。止まらずに動いていて、請求の内訳の説明があり、改修の相談に返事が来るなら、変える理由はありません。費用だけが不満なら、値上げの理由を1回聞いてみるほうが、乗り換えるより安く済みます。当社を含め、どこにも相談しなくてよい状態です。

続ける・移す・作り直すを比べる前に、もう1つ考えたい選択肢があります。給与、勤怠、請求、在庫のように、どこの会社もやっている業務なら、既製のサービスに移すのがいちばん安く済むことも少なくありません。データはデータベースに残っていることが多いので、そこに入れるなら、コードが手元に無くても取り出せます。自社ならではのやり方が要る業務かどうかが分かれ目です。

作り直しは、3つが揃っていないときの現実的な選択肢でもあります。名義も納品物も権利も欠けていて、この先も長く使うなら、調査に費用を積むより作り直したほうが総額で下回ることがあります。分かれ目は、いまの業務の進め方を変えずに残したいかどうかです。残したいなら引き継ぎ、業務のほうを見直したいなら作り直しが噛み合います。作り直すと決めた後の進め方は業務システムのリプレースで、業務を止めない切替のしかたとあわせて扱いました。

引き継ぎの費用は、月額の保守費が始まる前に、まず調査の費用として出てきます。中身を読んで、動く形にできるかを確かめる作業が要るためです。ここを月額に紛れ込ませると、後から追加の請求が出やすくなります。調査だけを分けて発注し、その結果を見てから保守の契約を結ぶ形にすると、どちらの側も見通しが立ちます。ただし、調査を頼む先は、作り直しも売っている会社です。引き継げないという結論だけの報告ではなく、何がどう足りないかまで書いてもらいます。

• 現状の調査 — コードと構成を読み、動かせるかを確かめる
• ドキュメントの整備 — 引き継ぐ側が読める最小限まで
• 環境の作り直しや移設 — 名義を移せない場合は、ここが膨らむ
• 並走の期間 — 前の会社と新しい会社が同時に動く間は、両方に費用がかかる
• 移した後の月額 — 含まれる作業と、別に見積もる作業の線引きとセットで

金額の相場を先に知ろうとしても、規模と残っている資産で変わりすぎて当てになりません。代わりに、比べられる形で出してもらいます。上に挙げた5つを項目ごとに分け、それぞれに金額と期間を入れてもらうこと。調査だけを切り分けて、結果を見てから次を決められる契約にしてもらうこと。この2つが揃えば、総額ではなく中身で比べられます。1社だけに聞くと、その会社の前提が、そのまま相場に見えてしまうもの。複数から取ると、その偏りが見えてきます。

相場を調べると「年間の保守費は開発費の◯%」という数字が並びます。5%とするものから30%とするものまであり、出典を書いた記事はほとんど見当たりません。数字がこれだけ開く理由の1つは、直す作業と、機能を足す作業を分けずに足していることです。

分けて集計した調査があります。日本情報システム・ユーザー協会のソフトウェアメトリックス調査は、保守と追加開発を分けて比率を出しています。ただし、何に対する比率かは区分ごとに違います。

同じ調査は、一から作ったシステムでは稼働後の5年間で開発費とほぼ同じ額がかかるとしています。見積もりが開発費の20%前後でも、高いとは限らないということです。中身が直す作業だけなのか、機能を足す分まで含むのかで、意味が変わります。ただし対象は、一から作ったシステムで初期の開発費が中央値1億5,000万円、平均7億3,787万円という規模です。この記事が想定する発注とは桁が違います（2020年版。2019年度の調査までに蓄積したデータで、この開発費の分布は549件が対象）。

この比率を自社の開発費に掛けて、見積もりの妥当性を判定することはできません。小さい規模では、人が動く以上、比率とは関係なく下限があります。月額に何が含まれているかを一覧にしてもらい、その内訳で見るほうが確かです。障害の一次対応、問い合わせ、軽い設定変更まで含むのか、機能追加は別に見積もるのか。ここが書かれていない見積もりは、金額の大小に関係なく比べられません。

期間も、こちらで決める数字ではありません。工程ごとに何週間かかるかを見積もりに書いてもらい、自社に残っている時間から逆算します。相手からの終了の連絡に期日がついているなら、工程を並べて収まるかを見ます。収まらないなら、引き継ぎ先を探すより、保全と、期日を延ばせないかの相談が先です。移った先で落ち着くまでを含めると、当初の見立てより延びるものだと見ておくと安心です。

伝え方で、相手から出てくるものが変わります。取引をやめる話として切り出すと、相手は身構えるものです。必要なものをまとめて頼むと、それだけで乗り換えを察知されやすくなります。2回に分けるのが無難です。1通目は名義と管理者アカウントだけ。コードや資料の一式は、次の会社の目処が立ってからにします。電話だけで済ませず、記録に残る形にしておきます。

件名: 契約とアカウントのご確認について

いつもお世話になっております。

社内で管理台帳を整えており、あわせて、障害時に当社側でも状況を確認できる体制にしておきたいと考えています。
つきましては、下記をご相談させてください。

1. ドメイン・サーバー・外部サービスの契約者名義と、更新の請求先
2. 各管理画面に、当社の管理者アカウントを1つ追加していただくこと

○月○日までにご返信いただけると助かります。窓口は下記の者です。
お手数をおかけしますが、よろしくお願いいたします。

ただし、相手からすでに終了を告げられているなら、分ける意味はありません。察知を避ける理由がもう無いからです。この場合は急ぎます。期日を確かめたうえで、2通目の内容まで最初にまとめて頼むほうが確実です。担当者が辞めると聞いた場合も、その人がいるうちに運用の手順と残っている課題を聞いておきたいところです。

件名: システムの資料一式のご提供について

いつもお世話になっております。

現在ご対応いただいているシステムについて、社内で今後の運用体制を検討しています。
つきましては、下記をご提供いただけますでしょうか。

1. ソースコード一式（現在稼働しているものと同じ内容のもの）
2. サーバーやクラウドの構成が分かる資料と、設定の内容
3. データベースのバックアップと、その取得方法
4. 現在ご対応中の課題があれば、その状況

ファイルの受け渡し方法はご指定に合わせます。
ご提供に費用や作業が発生する場合は、金額と期間をお知らせください。
○月○日までにご返信いただけると助かります。よろしくお願いいたします。

2通目を送る前に、契約書の納品物の一覧を見ておきます。ソースコードが含まれているなら、費用の一文は外して、納品として求める形にします。含まれていないなら、有償での提供を相談する話です。費用が発生するかを先に聞いているのは、後から請求で揉めないためです。断られた場合も、説明のつかない金額が返ってきた場合も、その返事自体が判断材料になります。文面はそのまま使わず、自社の言い方に直してから送るほうが自然です。名義の変更を切り出すのは、管理者アカウントを持ってからにするほうが有利です。順番が逆だと、相手はこちらが名義を気にしていると知ったうえで交渉に臨むことになります。

• 引き継げるかどうかは、名義・納品物・権利で決まる。ソースコードだけでは足りない
• この3つは、作るときに5つを決めておけば揃う。名義を自社で取る、区切りごとに納品物を受け取る、改修と再委託を認める一文を入れる、終わり方を書く、月額の線引きを決める
• 洗い出しは、いまの開発会社に何も言わずに始められる。請求書とログインできる管理画面で半分は埋まる
• 「.com」などは事業者の移管を先に、登録者の変更を後に。逆にすると60日動かせないことがある。JPドメインは、いまの事業者が認証コードを渡さないままでも、JPRSを通す道が残っている
• 契約書の著作権の条項は、著作権法の第27条と第28条を名指しした一文と、著作者人格権を行使しないという一文があるかで見る。「譲渡する」とだけでは足りない
• 断られる理由は決まっている。先に揃えられるものから揃える
• 続ける・移す・作り直すは、名義・納品物・権利が揃っているかと、あと何年使うかで分ける
• 「開発費の◯%」は、直す作業だけか機能追加まで含むかで倍以上変わる。月額に含まれる作業の一覧で判断する

これから作る場合の相手の選び方はシステム開発の外注先の選び方に、決める順番はシステム開発の要件定義の進め方にまとめています。そもそも作らずに済ませる判断は業務システムの内製化で扱いました。名義とアカウントの洗い出しからご一緒することもできます。必要でしたらお問い合わせからお声がけください。