開発会社を途中で変えるとき：引き継ぎで渡すものと、確かめること

業務システムを作ってもらった開発会社と、ずっと付き合い続けられるとは限りません。担当のエンジニアが辞めてしまった、相手の会社が事業の中心を変えた、改修の相談をしても返事が遅くなった、新しい技術に対応してもらえない。理由はさまざまです。どちらが悪いという話ではなく、何年もシステムを使っていれば、自然に起きることです。

困るのは、いざ別の会社に頼もうとしたときです。「ソースコードはどこにあるのか」「サーバーは誰の名義なのか」「そもそも、他の会社が直してもよいのか」。こうしたことが分からないまま話を進めると、新しい会社は見積もりを出せず、今の会社との関係もこじれやすくなります。

この記事は、開発会社や保守会社の変更を考えている情報システムの担当者や、事業の責任者に向けて書いています。次のことを順にまとめます。

• 乗り換えを決める前に、契約で確かめること
• 今の会社から受け取るものと、自社の名義に移すもの
• 新しい会社に最初に頼むこと（現行システムの調査）
• 引き継ぎの手順と、つまずきやすい所
• そのまま使える引き継ぎのチェックリスト

結論：探す前に「渡してもらえるもの」と「直してよいか」を確かめる

開発会社を変えるときの順番は、次のとおりです。

1. 今の契約書を読み、ソースコードの扱いと、著作権がどちらにあるかを確かめる
2. 引き継ぐもの（コード、設計書、環境、アカウント、データ、運用の手順）を一覧にする
3. 名義が今の会社になっているもの（ドメイン、サーバー、クラウドなど）を、自社の名義に移す
4. 新しい会社に、要件を決める前に、まず現行システムの調査を頼む
5. しばらくは両方の会社が関わる期間を作り、動かしながら引き継ぐ

新しい会社を探すのは、1と2の目途が付いてからで間に合います。むしろ、1と2の結果を新しい会社に見せたほうが、見積もりは正確になります。

なぜ引き継ぎでつまずくのか

引き継ぎがうまくいかない理由は、大きく2つあります。

1. 書かれているものと、動いているものがずれている

長く使っているシステムほど、設計書と実際の動きがずれていきます。IPA のモデル契約の解説では、この状態を次のように説明しています。

長年運用・保守を続けてきたシステムを再構築する場合、関係者の退職や異動により、対象システムが実現する業務内容やシステムの仕様について理解する人材がいない、対象システムに関するドキュメントが散逸していることや、改良内容のドキュメントへの反映がされず動作しているシステムと設計書やソースコードとが整合していないことがある、といった問題があることが少なくない。

（IPA「情報システム・モデル取引・契約書（第二版）」の解説より）

たとえば、障害が起きたときにソースコードだけを直して、設計書は直さなかった。仕様を変えたとき、関係する別の業務の資料までは直さなかった。こうしたことが何年も積み重なると、資料は「昔の姿」を表すだけになります。同じ解説では、こうしたずれがあると、発注する側が期待する「今と同じ動き」と、開発会社が資料から読み取る「今と同じ動き」が食い違うと指摘しています。

つまり、資料を受け取っただけでは引き継ぎは終わりません。新しい会社が、実際に動いているシステムを見て確かめる時間が必要です。

2. 権利と名義が、契約や登録の上で今の会社に残っている

もう一つは、権利と名義の問題です。ソースコードを受け取れても、契約で著作権が今の会社にあると決まっていれば、どこまで直してよいかは契約しだいになります。ドメインやサーバーの契約が今の会社の名義なら、移す手続きには今の会社の協力が必要です。

どちらも、今の会社が協力的であれば解決できます。ただ、手続きに時間がかかるので、乗り換えの期限が迫ってから気づくと間に合いません。

準備：乗り換えを決める前に確かめる3つのこと

1. 契約書で、著作権がどちらにあるか

システム開発の契約では、作ったプログラムの著作権を、開発会社に残すか、発注した会社に移すかを決めることが多くあります。IPA のモデル契約（第二版）の第45条には、次の3つの案が用意されています。

（IPA「情報システム・モデル取引・契約書（第二版）」の受託開発の契約書より）

A案のように著作権が開発会社にある場合でも、発注した会社が何もできないわけではありません。モデル契約のA案には、発注した会社が著作権法第47条の3などに従って、自分でプログラムを実行するために必要な範囲で複製したり、手を加えたりできることが書かれています。

著作権法第47条の3の条文は、次のとおりです。

プログラムの著作物の複製物の所有者は、自ら当該著作物を電子計算機において実行するために必要と認められる限度において、当該著作物を複製することができる。

（著作権法 第47条の3）

さらに、モデル契約の解説には、著作権を持たない発注者でも、ほかの会社に保守や運用を頼むことはできる、という考え方が示されています。

著作権を有しないユーザが情報システム子会社その他アウトソーシングベンダに保守運用を委託することは可能である。

（IPA「情報システム・モデル取引・契約書（第二版）」の解説より）

ただし、実際にどこまでできるかは、手元の契約書の条文で決まります。モデル契約は、あくまで「ひな型」です。自社の契約がどの案に近いのか、別の約束（ほかの会社への開示の禁止など）が入っていないかを確かめましょう。判断に迷う場合は、弁護士などの専門家に契約書を見てもらうのが確実です。

2. 「納入物」に、ソースコードと資料が含まれているか

次に、契約で決めた「納入物」（開発会社が作って渡すもの）の中身を確かめます。モデル契約の解説には、開発会社が倒産した場合でも、ソースコードや資料を受け取れるようにする方法として、次のように書かれています。

ソースコードや付帯するドキュメントの開示・交付を受けることは、納入物にソースコードを明記するか、エスクロウ制度の活用により対応可能である。

（IPA「情報システム・モデル取引・契約書（第二版）」の解説より）

逆に言えば、納入物にソースコードが書かれていない契約では、渡してもらえるかどうかを、今の会社と話し合って決めることになります。実行できる形のプログラムだけが納入物で、ソースコードは開発会社が持っている、という契約もあり得るからです。

確かめる場所は、契約書の本体だけではありません。個別の契約や注文書、見積書の「納入物」の欄、検収のときに受け取った一覧も見てください。

3. 今の契約の終わらせ方と、社内の期限

最後に、今の保守契約の期間と、解約するときの決まりを確かめます。何か月前までに知らせるか、引き継ぎの作業を頼むときの費用はどうなるか、などです。

あわせて、社内で「いつまでに切り替えたいか」と「誰が決めるか」を決めておきます。システムの引き継ぎは、技術の話だけでは終わりません。契約、費用、社内の承認が絡むので、窓口になる人と最終的に決める人を先に決めておくと、話が止まりにくくなります。

引き継ぎの手順

準備ができたら、次の順に進めます。

1. 今の会社に、引き継ぎを書面で相談する

まず、今の会社に、開発会社を変える予定であることと、引き継ぎに協力してほしいことを伝えます。口頭だけで済ませず、何を、いつまでに渡してほしいかを書面（メールでも構いません）で残します。

ここで大事なのは、相手を責める言い方をしないことです。引き継ぎがうまくいくかどうかは、今の会社の協力にかかっています。「これまで支えていただいたシステムを、今後も安定して動かし続けるために、引き継ぎに協力していただきたい」という伝え方なら、相手も動きやすくなります。

引き継ぎの作業は、今の会社にとっても仕事です。資料をまとめる時間や、新しい会社からの質問に答える時間がかかります。必要であれば、引き継ぎの作業として費用を払う前提で相談したほうが、話は早く進みます。

2. 引き継ぐものを一覧にする

次に、受け取るものを一覧にします。漏れやすいのは、ソースコード以外のものです。

• ソースコード： どこで管理しているか（Git などの置き場所）、最新版はどれか、本番で動いている版と一致しているか
• 設計書と仕様書： 最後に直したのはいつか、実際の動きとずれている所はあるか
• 環境： 本番、検証、開発の環境がどこにあり、どう作ったか
• アカウントと鍵： サーバー、クラウド、データベース、外部サービスのログイン情報や API キー
• データ： データベースの中身、ファイル、バックアップの場所と取り方
• 運用の手順： 定期的な作業、障害が起きたときの対応、毎月の更新作業
• 外部との約束： 決済、メール配信、地図、SMS など、つないでいる外部サービスの契約

後で使えるように、この記事の最後にチェックリストを載せています。

3. 名義を自社に移す

ドメイン、サーバー、クラウド、外部サービスの契約が今の会社の名義になっている場合は、自社の名義に移します。開発会社の名義のままだと、契約が切れたときに、サイトやメールが止まるおそれがあるからです。

移すときは、次の順番が安全です。

1. 自社の名義でアカウントを作り、請求先を自社にする
2. 今の会社の担当者に、移す作業を手伝ってもらう
3. 移したあと、今の会社のアカウントからの権限を外す日を決める

特にドメインは、メールやサイトの全部に関わります。登録している会社と、名義、更新の期限を最初に確かめておきましょう。

4. 新しい会社に、まず現行システムの調査を頼む

新しい会社が決まったら、いきなり改修や作り直しの見積もりを頼むのではなく、まず今のシステムの調査を頼みます。IPA のモデル契約の解説では、作り直しの前に現行システムを調べる必要があると、はっきり書かれています。

要件定義に入る前に、まず、再構築対象の現行システムについての調査を行い、その仕様を明らかにする必要がある。

（IPA「情報システム・モデル取引・契約書（第二版）」の解説より）

同じ解説では、この調査と、リスクについての認識合わせを十分に行わずに作り直しを始め、後の工程でトラブルになった事例が多数報告されている、とも書かれています。IPA は、作り直しの前の計画づくりについて『システム再構築を成功に導くユーザガイド 第2版』という手引きも出しています。その紹介ページでは、作り直しの失敗や運用後のトラブルが起きる原因を、時間がたって分からなくなった現行システムの仕様があいまいなまま、新しいシステムの開発に着手してしまうことだ、と説明しています。

調査では、たとえば次のことを確かめます。

• 受け取ったソースコードから、本番と同じものを動かせるか
• 使っている言語やフレームワークの版が、まだ更新を受けられるか
• 設計書と実際の動きが、どこでずれているか
• 毎日、毎月の運用で、人の手でやっている作業は何か
• すぐに直したほうがよい危ない所（古い版、権限の付け方など）はないか

調査には時間と費用がかかります。それでも、調査の結果があれば、新しい会社の見積もりは「分からないから多めに見ておく」ものではなく、根拠のあるものになります。発注する側にとっても、費用を判断しやすくなります。

5. 並行して関わる期間を作る

調査が終わったら、すぐに今の会社との契約を切るのではなく、しばらく両方の会社が関わる期間を作ります。新しい会社が実際に保守の作業をしてみて、分からないことを今の会社に質問できる期間です。

この期間に、次のことを一度ずつやってみると安心です。

• 小さな修正を一つ、新しい会社が本番に反映する
• バックアップから、データを戻せるか試す
• 月に一度の作業や、年に一度の更新（証明書など）の手順を確かめる

一度も試さないまま切り替えると、障害が起きたときに初めて「手順が分からない」と気づくことになります。

6. 古い権限を外して、引き継ぎを終える

最後に、今の会社が使っていたアカウントや鍵を外します。共有していたパスワードは変えます。API キーは作り直します。サーバーに入るための鍵も、新しいものに替えます。

ここを忘れると、契約が終わった会社のアカウントが、いつまでも本番のシステムに入れる状態で残ります。相手を疑うためではなく、誰が入れるかを自社が分かっている状態にするための作業です。

新しい会社に最初に相談するとき、伝えること

新しい会社への最初の相談では、次のことが分かっていると、話が早く進みます。全部がそろっていなくても構いません。分からない所は「分からない」と伝えれば、調査で何を確かめるべきかが見えてきます。

特に「変えたい理由」は、遠慮せずに伝えてください。理由によって、新しい会社が最初に確かめる所が変わるからです。たとえば「改修のたびに別の所が壊れる」なら、テストの仕組みや作りの複雑さを先に見ます。「版の更新に対応してもらえない」なら、使っている言語やライブラリの版と、更新にかかる手間を先に見ます。

また、新しい会社からの提案を比べるときは、金額だけでなく、現行システムの調査をどう進めるか、引き継ぎの期間に今の会社とどう連絡を取るか、を見ると違いが分かります。引き継ぎを経験したことのある会社なら、この2つを具体的に説明できるはずです。

引き継ぎのチェックリスト

そのまま使える一覧です。印が付かない所が、今の会社と話す点、または新しい会社に調べてもらう点です。

契約と権利

• 開発の契約書と、個別の契約、注文書を手元にそろえた
• 著作権がどちらにあるか（モデル契約の A・B・C 案のどれに近いか）を確かめた
• 納入物に、ソースコードと設計書が含まれているか確かめた
• ほかの会社への開示や、改修を制限する約束がないか確かめた
• 今の保守契約の期間と、解約を知らせる期限を確かめた

コードと資料

• ソースコードの置き場所と、最新版がどれかが分かる
• 本番で動いている版と、受け取ったソースコードが一致している
• 設計書、仕様書、画面の一覧、データの項目の一覧を受け取った
• 資料と実際の動きがずれている所を、今の会社に聞いた

環境とアカウント

• 本番、検証、開発の環境の場所と作り方が分かる
• ドメインの登録先、名義、更新の期限を確かめた
• サーバー、クラウド、データベースの名義と請求先が自社になっている
• 外部サービス（決済、メール配信など）の契約の名義が自社になっている
• API キーやパスワードの一覧を、安全な方法で受け取った

データと運用

• データベースとファイルのバックアップの場所と、戻し方が分かる
• 毎日、毎月、毎年の定期作業の一覧がある
• 障害が起きたときの連絡先と、対応の手順がある
• 使っている言語、フレームワーク、ライブラリの版の一覧がある

切り替え

• 新しい会社が、現行システムを調査した
• 両方の会社が関わる期間に、小さな修正を一度本番に反映した
• バックアップから戻せることを試した
• 今の会社のアカウントと、共有していた鍵やパスワードを外した、または変えた

つまずきやすい所

「全部そろってから」探そうとして、時間がなくなる

資料が全部そろうまで新しい会社に相談しない、という進め方は、時間がかかりがちです。手元にあるものの一覧ができた時点で、新しい会社に見てもらい、足りないものを一緒に洗い出したほうが早く進みます。

ソースコードを受け取ったのに、動かせない

ソースコードがあっても、動かすための設定や手順がなければ、本番と同じものを動かせません。サーバーの設定、環境ごとの設定値、外部サービスの鍵などが、ソースコードとは別の所にあることが多いからです。受け取ったら、新しい会社にすぐ動かしてもらい、足りないものを早めに見つけましょう。

「今と同じ」で頼んで、食い違う

新しい会社に「今と同じ動きのまま、保守してほしい」と頼むと、何が「今と同じ」なのかで食い違うことがあります。先に紹介した IPA の解説のとおり、資料と実際の動きがずれていることがあるからです。現行システムの調査で、どの動きを正とするかを一緒に決めておくと、後の食い違いを減らせます。

名義の移し忘れで、ある日止まる

ドメインやサーバーの更新が、今の会社に届く連絡のまま放置され、期限切れで止まる。こうしたことは、引き継ぎの後に起きやすいものです。名義と請求先、更新の期限は、一覧にして自社の予定表に入れておきましょう。

事例：株式会社R65様「らくもり」の引き継ぎ

クリーヴァでは、株式会社R65様の見守りサービス「らくもり」の引き継ぎをお手伝いしました。開発会社の変更とは少し違い、前の運営会社から事業ごとサービスを引き継いだ例です。ただ、「動いているシステムを、別の担い手に移す」という点は同じです。

株式会社R65様のインタビューでは、当時の状況が次のように語られています。前の運営会社から事業終了の連絡があり、事業を引き継ぐまでの期限が決まっていました。社内にシステムや技術に詳しいメンバーはおらず、引き継ぎにどれくらいの費用がかかるかも見えていませんでした。

依頼先を比べるときに、株式会社R65様が一貫して重視していたのは、技術的な基盤をきちんと引き継げるか、そしてその後も続けて運用できる体制をつくれるか、という点だったそうです。検討の途中で、要件がある程度見えてきた段階で、今のシステムを引き継がずにゼロから作り直すのは現実的ではない、と判断されています。

引き継いだあとは、管理画面を整えたことで、それまで都度問い合わせていたことを、自分たちで画面を見て判断できるようになったと話されています。費用は、当初想定していた予算の半分程度に収まったそうです。

この事例から言えるのは、引き継ぎで大事なのは「作り直すかどうか」を急いで決めることではなく、まず今のシステムを理解し、何を残して何を直すかを決めることだ、という点です。作り直しは選択肢の一つですが、引き継げるものを引き継いだほうが、期間も費用も抑えられることがあります。

引き継ぎが終わったと言える状態

最後に、引き継ぎが終わったかどうかを確かめる基準です。次の4つを満たしていれば、新しい会社に安心して任せられる状態です。

1. 新しい会社だけで、本番に修正を反映できる。 今の会社に聞かなくても、小さな修正を出せる。
2. 障害が起きたときの連絡先と手順が、社内で分かる。 誰に連絡し、何を確かめるかが書いてある。
3. 名義と鍵が、すべて自社の管理下にある。 ドメイン、サーバー、外部サービスの名義と、ログインできる人の一覧が自社で分かる。
4. 次の更新の予定が見えている。 使っている言語やフレームワークの版と、サポートが切れる時期が一覧になっている。

4つ目は、引き継ぎの後に忘れられがちです。古い版のまま使い続けると、重大な脆弱性が見つかったときに、更新に時間がかかります。この点は「PHPの重大な脆弱性で何が起きたか」で詳しく書いています。

おわりに

開発会社を途中で変えることは、珍しいことではありません。うまく進めるコツは、新しい会社を探す前に、今の契約で「何を渡してもらえるか」と「直してよいか」を確かめておくことです。そのうえで、受け取るものを一覧にし、名義を自社に移し、新しい会社に現行システムを調べてもらう。この順番で進めれば、今の会社との関係を壊さずに、引き継ぎを終えられます。

引き継ぎは、システムを見直すよい機会でもあります。新しく作るものを考えるときは、「要件定義とは」もあわせて読んでみてください。