開発ベンダー契約終了で引き継ぐ12項目と次の体制

「今の開発ベンダーとの契約を終えることになったが、次の体制がまだ決まっていない」「ベンダー側から体制の縮小を告げられ、何をいつまでに引き継げばよいか分からない」「ソースコードは受け取れるはずだが、それだけで本当に足りるのか不安だ」。開発ベンダーとの契約終了は、自社の判断で切り替える場合も、ベンダー側の事情で終わる場合も、準備の時間が限られがちです。この記事では、契約終了が決まったらすぐにやること、引き継ぐべき12項目のチェックリスト、引き継ぎ期間の過ごし方、次の開発・保守体制の選び方と、失敗しやすい点をお伝えします。

契約終了が決まったらすぐにやること

引き継ぎは、終了日から逆算して進めます。最初の数日で次の3つを済ませておくと、後の作業が大きく変わります。

1. 契約上の期限と範囲を確認する

まず、今の契約書と、保守・運用の契約があればその契約書も手元に集めます。確認するのは次の点です。

• 契約が終わる日と、解約の予告期間
• 契約終了時の引き継ぎや、資料の引き渡しについての定め
• ソースコードや設計書などの成果物の扱い（どこまで引き渡されるか）
• 引き継ぎの作業が契約の範囲に含まれるか、別途の費用になるか

成果物の権利や引き渡しの範囲は、契約書の条項によって異なります。自社だけで判断せず、契約書の条項を確認し、必要に応じて法務部門や専門家に相談してください。契約書の書き方を比べる材料としては、IPA（情報処理推進機構）がユーザ企業とベンダの双方を対象に公開している情報システム・モデル取引・契約書（第二版）があり、受託開発と保守運用のモデル契約が含まれています。

2. 終了日までのスケジュールを引く

終了日が決まったら、そこから逆算して次の区切りを置きます。

区切り	この時点で済ませておくこと
引き継ぎ開始	引き継ぐもののリストを前のベンダーと合意し、窓口を決めること
名義・権限の移管	クラウド・ドメイン・外部サービスの名義と管理者権限を自社に移すこと
並走期間	次の担当者が実際に作業し、前のベンダーが確認・回答すること
契約終了	前のベンダーのアクセス権限をすべて外し、未解決の質問が残っていないこと

ポイントは、名義と権限の移管を後回しにしないことです。資料の受け渡しは終了日の直前でも何とかなることがありますが、名義の変更は相手側の手続きが必要なことが多く、終了日を過ぎると進めにくくなります。

3. 次の体制の「仮の担い手」を決める

次の開発・保守体制が決まっていなくても、引き継ぎを受け取る人は先に決めます。受け取る人がいないまま資料だけ受け取っても、中身が足りているかを判断できないためです。社内にエンジニアがいない場合は、情報システム部門の担当者が窓口になり、技術的な確認は外部の人材に頼むという分け方もあります。

引き継ぐもの12項目のチェックリスト

引き継ぎというとソースコードの受け取りを思い浮かべがちですが、システムを動かし続けるにはそれだけでは足りません。次の12項目を、前のベンダーと一緒に1つずつ確認します。

#	項目	確認すること
1	ソースコードとリポジトリ	本番で動いているものと同じ版か、履歴ごと受け取れるか
2	開発・運用ツールのアカウントと権限	リポジトリ・CI・課題管理・チャットなどの管理者が誰か
3	クラウド・サーバーの契約名義	契約者と支払い名義、管理者権限が誰にあるか
4	ドメイン・DNS・証明書	ドメインの登録者、DNSの管理画面、証明書の更新方法
5	外部サービス・ライセンスの契約名義	メール配信・決済・地図・認証などの外部サービスと、APIキーの持ち主
6	設計書・仕様書	今のシステムと内容が合っているか
7	運用手順書	リリース・バックアップ・監視・定期作業の手順
8	課題・未対応の一覧	既知の不具合、保留中の要望、技術的な懸念
9	テスト環境とテストの方法	検証環境の有無、テストデータ、テストの手順
10	データ	データベースの構成、バックアップの場所、データの意味
11	障害対応の履歴	過去の障害と原因、その時の対処
12	暗黙知の聞き取り	文書になっていない理由や注意点

ソースコード・アカウント・名義（1〜5）

1〜5は、受け取り漏れがあると後から取り返しにくい項目です。

ソースコードとリポジトリは、本番環境で動いているものと同じ版かを必ず確かめます。開発者の手元にだけある変更や、本番サーバー上で直接書き換えた箇所が残っていることがあるためです。リポジトリごと自社の管理下に移せると、変更の履歴や過去の議論も残せます。たとえば GitHub では、リポジトリの移譲でコミット履歴に加えて Issue・プルリクエスト・Wiki も一緒に移ります。移譲には元のリポジトリの管理者権限が必要なため、前のベンダーの協力が欠かせません。また、移譲後も webhook やデプロイキーなどは関連付けられたまま残るため、移した後に中身を見直します。

開発・運用ツールのアカウントと権限は、使っているツールを一覧にし、それぞれの管理者を自社の担当者に切り替えます。前のベンダーの担当者個人のアカウントで契約しているツールがないかも確認します。

クラウド・サーバー、ドメイン・DNS・証明書、外部サービスは、「誰の名義で契約しているか」と「誰が管理画面に入れるか」を分けて確認します。支払いは自社でも、契約者や管理者が前のベンダーになっていることがあります。証明書の更新やドメインの更新を前のベンダーが代行していた場合、契約終了後に更新が止まり、サイトやシステムが使えなくなるおそれがあります。更新日も一覧に書き込んでおきます。

文書・課題・環境（6〜9）

設計書・仕様書は、受け取ったら今のシステムと合っているかを確かめます。改修を重ねるうちに文書の更新が止まり、内容が古くなっていることは珍しくありません。合っていない箇所は、引き継ぎ期間のうちに前のベンダーに確認して書き足してもらうか、自社側で記録します。

運用手順書は、リリースの手順、バックアップと復元の手順、監視とアラートの通知先、月次や年次の定期作業を含めて受け取ります。年に1回しか行わない作業（年度替わりのマスタ更新など）は忘れられやすいため、カレンダーにして残すと安心です。

課題・未対応の一覧は、既知の不具合、対応を保留している要望、前のベンダーが気にしている技術的な懸念をまとめてもらいます。次の担当者が最初に何から手を付けるかを決める材料になります。

テスト環境とテストの方法は、本番とは別に検証できる環境があるか、テストデータはどこにあるか、リリース前にどんな確認をしていたかを聞きます。検証環境がない場合、次の担当者は本番でしか確かめられないことになり、変更のたびにリスクを抱えます。

データ・履歴・暗黙知（10〜12）

データは、データベースの構成とバックアップの保管場所に加えて、項目の意味や、コードの値の決まり（区分値など）を確認します。データの意味が分からないと、将来システムを作り替えるときの移行で困ります。

障害対応の履歴は、過去にどんな障害があり、原因は何で、どう対処したかを受け取ります。同じ障害が起きたときに、次の担当者が一から調べ直さずに済みます。

暗黙知の聞き取りは、12項目の中で最も抜けやすいものです。「この処理はなぜこうなっているのか」「この設定は触ると何が起きるか」「この顧客だけ例外の扱いがある」といった知識は、文書にはなっていないことが多く、担当者の頭の中にしかありません。経済産業省のレガシーシステムモダン化委員会総括レポートでも、仕様や設計の文書が整っていないことや、運用・保守が属人的になっていることを、システムのブラックボックス化の要因として挙げています。聞き取りは、次の「引き継ぎ期間の過ごし方」で述べる質疑の時間を使い、必ず記録に残します。

担当者の退職などで、すでに知識が失われかけている場合の進め方は、システムのブラックボックス化への対処で詳しく扱っています。

引き継ぎ期間の過ごし方

資料を受け取って終わりにせず、次の担当者が実際に作業できる状態になるまでを引き継ぎ期間と考えます。

並走期間を取る

前のベンダーがまだ契約中のうちに、次の担当者が実際の作業をしてみる期間を設けます。たとえば次のような作業です。

• 手元で開発環境を立ち上げ、ソースコードから動かしてみること
• 検証環境へのリリースを、手順書どおりに一度やってみること
• 小さな改修を1つ行い、前のベンダーに確認してもらうこと
• バックアップからの復元を試すこと

手順書を読んだだけでは分からないことは、実際にやってみて初めて見つかります。並走期間をどれだけ取れるかは、システムの規模や契約の残り期間によって変わりますが、少なくとも「リリース」と「障害時の一次対応」を次の担当者が一度は経験してから契約を終えるのが理想です。

質疑の窓口と期限を決める

質問は、担当者どうしが個別にやり取りするのではなく、窓口を一本にまとめます。質問の一覧を共有の場所に置き、誰が聞いて、誰が答えて、いつ解決したかを残します。回答の期限も決めておくと、終了日の直前に未回答の質問が積み残される事態を防げます。

やり取りをすべて記録する

口頭の説明や画面共有での説明は、その場では分かったつもりになっても、後から確かめられません。打ち合わせは録画するか議事録を残し、聞き取った内容は設計書や運用手順書に書き足します。引き継ぎ期間に記録したものが、次の体制で最初に頼る資料になります。

契約終了の日に確かめること

契約が終わる日には、次の点を確認して引き継ぎを締めくくります。

• 前のベンダーのアカウントとアクセス権限（クラウド・リポジトリ・各種ツール・VPN・共有されていたパスワード）をすべて外したこと
• 共有していたパスワードやAPIキーを変更したこと
• 質問の一覧に未解決のものが残っていないこと
• 契約終了後に問い合わせが必要になったときの連絡方法（有償か無償かも含めて）

次の開発・保守体制の選び方

次の体制は、大きく分けて3つの形があります。

体制	向いている場合	注意すること
別のベンダーへの委託	システムが安定していて、改修の量が多くない場合。社内で開発を担う予定がない場合	引き継ぎを受ける力があるかを選定時に確かめること。同じ依存の形を繰り返さないよう、名義と権限は自社に置くこと
内製	システムが事業の中核で、改修を素早く続けたい場合。採用と育成に時間をかけられる場合	採用が整うまでの空白期間をどう埋めるかを決めておくこと
内製と外部人材の組み合わせ	内製化を目指しているが、今すぐ社内にエンジニアをそろえられない場合	技術判断と知識の蓄積を社内側に残す仕組みをつくること

どの形を選ぶ場合も、名義と権限、文書と記録は自社の手元に置きます。次の委託先や外部人材が代わっても、引き継ぎをやり直さずに済むためです。システムそのものが古くなっていて、引き継ぎを機に作り替えを検討する場合は、基幹システムリプレイスの進め方も参考にしてください。

内製化するなら「誰が技術判断をするか」を先に決める

内製化を選ぶ場合に、最初に決めるべきなのは「誰が技術判断をするか」です。どの技術を使うか、どの改修を先にやるか、外部の提案が妥当かを判断する人がいないと、エンジニアを集めても方向が定まりません。

社内にその役割を担える人がいない場合は、技術判断ができる人（プロジェクトマネージャーや技術リード）を外部から迎え、その人のもとで社内のメンバーや外部のエンジニアが動く形にすると、立ち上げが進めやすくなります。並行して正社員の採用を進め、判断の役割を少しずつ社内に移していきます。前述のレポートも、システムの可視化と内製化の必要性として、仕様を文書にして属人性をなくし、担当者が代わっても知識を引き継げるようにすることを挙げています。

社内にエンジニアがいない状態からチームを立ち上げる具体的な手順は、エンジニアがいない会社の開発チームの立ち上げ方で説明しています。

外部人材を加えるときの見極め

外部のエンジニアを加える場合は、経歴書だけで決めず、事前の面談で技術力と進め方を確かめます。加わった後も、最初の短い期間で実際の働きぶりを見て、合わなければ早めに交代できる取り決めにしておくと、体制が崩れにくくなります。

私たちが支援した医療系DX企業では、内製化に向けて開発ベンダーとの契約を終了した一方で、社内にエンジニアがいない状態でした。そこで、PMを含むチームで参画し、コーディングテストを含む事前面談とPMのもとでの短期間の見極め、アサイン後の稼働管理と必要に応じた交代・追加を続けました。18ヶ月の支援の中で、最大20人（PM3名・エンジニア17名）の体制になっています。ほかの事例は支援実績で紹介しています。

失敗しやすい点

契約終了と引き継ぎでつまずきやすいのは、次の4つです。

失敗	起きること	防ぎ方
名義が前のベンダーのまま	契約終了後に、クラウドやドメインの設定を変えられなくなります。更新が止まり、サービスが使えなくなることもあります	名義と管理者権限の移管を、引き継ぎの最初の段階で行います
権限の回収漏れ	契約が終わった相手が、本番環境やデータに入れる状態が残ります	ツールとアカウントを一覧にし、終了日に外したことを一つずつ確かめます
口頭の知識の消失	「前の担当者なら知っていたこと」が分からなくなり、改修や障害対応に時間がかかります	質疑と聞き取りをすべて記録し、設計書や手順書に書き足します
短すぎる引き継ぎ期間	資料は受け取ったが、次の担当者が一度も作業しないまま契約が終わります	並走期間を取り、リリースと障害対応を次の担当者が一度経験してから終えます

とくに注意したいのは、支払いは自社で行っているのに、契約者や管理者が前のベンダーになっているケースです。請求書だけを見ていると気付きにくいため、各サービスの管理画面で契約者と管理者を直接確認します。

まとめ：契約終了は「名義・権限・記録」を自社に戻す機会

• 契約終了が決まったら、まず契約書で期限と引き継ぎの定めを確認し、終了日から逆算してスケジュールを引きます。権利や引き渡しの範囲は、必要に応じて法務部門や専門家に相談します。
• 引き継ぐものはソースコードだけではありません。アカウントと権限、クラウド・ドメイン・外部サービスの名義、設計書と運用手順、課題の一覧、テスト環境、データ、障害対応の履歴、暗黙知の聞き取りまでの12項目を確認します。
• 引き継ぎ期間には並走期間を取り、質疑の窓口を一本にして、やり取りをすべて記録します。
• 次の体制は、別ベンダー・内製・内製と外部人材の組み合わせから、システムの位置付けと社内の人材で選びます。内製化するなら、誰が技術判断をするかを先に決めます。
• 名義が前のベンダーのまま、権限の回収漏れ、口頭の知識が消える、引き継ぎ期間が短すぎる、の4つが失敗しやすい点です。

契約終了後の開発・保守を担うチームを、技術判断ができる人材を含めて組みたい場合は、開発体制支援の内容をご覧ください。引き継ぎの段階からご相談いただけます。