開発会社がいなくなった既存システムでも、別会社へ改修を依頼できるのか
- 3 日前
- 読了時間: 14分
以前システムを作った開発会社と連絡が取れない、担当者が退職した、保守契約が終了した。そんな状態でも、別の開発会社へ既存システムの改修を依頼できる場合があります。
重要なのは、前の会社から完璧な引継ぎ資料を受け取っていることではありません。新しい開発会社が、そのシステムを調べ、変更し、試験し、本番へ反映できるだけの管理権限を確保できるかが、引継ぎ可否を大きく左右します。
はじめに：前の開発会社がいないことと、改修できないことは同じではない
既存システムを長く運用していると、開発当時とは状況が変わることがあります。
たとえば、
開発会社が廃業した
担当していたエンジニアが退職した
開発会社との保守契約を終了した
以前の担当者と連絡が取れなくなった
社内に当時の経緯を知る人がいない
別の開発会社へ保守・改修を切り替えたい
といったケースです。
この状態になると、
前の会社に聞けないなら、もう改修できないのではないか。
と考えがちです。
しかし、前の開発会社がいなくても、現在のシステムを調査し、新しい開発会社へ引き継げる場合があります。
一方で、システムが今も正常に動いているからといって、必ず引き継げるわけでもありません。
「システムを利用できる状態」と「別会社がシステムを変更できる状態」は別だからです。
既存システムを別会社へ引き継ぐときは、仕様書の有無だけではなく、誰がシステムを管理しており、新しい会社へ必要な権限を渡せるのかまで確認する必要があります。
結論：引継ぎ可否は「資料の量」より、管理権限と変更可能性で決まる
既存システムの改修では、まず現在のシステムを誰がどのように管理しているかを確認します。
「既存システムの改修を外注するときに失敗しないためのポイント」でもシステムの管理状況について触れていますが、前の開発会社がいない場合、この確認がそのまま引継ぎが成立するかどうかの判断になります。
仕様書や設計書が残っているに越したことはありません。
ただし、仕様書がないことだけを理由に、
引継ぎできない。
と判断する必要はありません。
それより重要なのは、新しい開発会社が次の4つを行える状態かどうかです。
現在の仕組みを調べられるか。ソースコード、実行環境、設定、データなどへ必要な範囲でアクセスできるか。
変更できるか。現在動いているシステムに対応するソースコードや設定を、新しい開発会社が扱えるか。
変更結果を確認できるか。開発・検証環境を用意する、または本番へ影響を与えずに試験できる方法があるか。
本番へ反映できるか。サーバー、クラウド、デプロイ、ドメイン、DNS、外部サービスなど、本番リリースに必要な環境を操作できるか。
この4つが成立すれば、前の開発会社から詳細な説明を受けられなくても、調査から引継ぎを進められる可能性があります。
逆に、仕様書やソースコードが大量に残っていても、クラウド環境の管理者権限がない、本番への反映方法が分からない、新しい会社へアカウントを発行できない、といった状態では改修が難しくなります。
引継ぎで確認したいのは、「何が残っているか」だけではなく、「新しい会社がそれを使って変更できる状態になっているか」です。
まず確認したいのは「何があるか」ではなく「誰が管理しているか」
前の開発会社がいなくなった場合、システムを構成するものを一つずつ調べることも必要です。
ただし、本記事で特に確認したいのは、その内容そのものよりも管理主体と権限です。
たとえば、AWSを使っていることが分かったとしても、それだけでは引継ぎ可能とは判断できません。
自社が契約しているAWSアカウントへ、前の開発会社が作業していた。
のか、
前の開発会社が契約しているAWSアカウントの中で、自社システムを動かしていた。
のかでは、状況が大きく違います。
前者なら、自社側で新しい開発会社用のアカウントや権限を追加できる可能性があります。
後者の場合は、環境そのものの移行や契約変更が必要になることがあります。
同じことはAWSだけではありません。
対象 | 確認したいこと |
ソースコード | リポジトリや保管場所を誰が管理しているか。自社からアクセスできるか。新しい会社を追加できるか |
サーバー・クラウド | 契約名義は誰か。自社に管理者権限があるか。新しい会社へ必要な権限を発行できるか |
ドメイン・DNS | ドメインの契約者は誰か。DNSを誰が変更できるか |
決済・メール・外部API・SaaS | 契約主体は誰か。管理画面へ自社がログインできるか。担当者を変更できるか |
証明書・秘密情報・各種設定 | どこで管理されているか。特定の担当者しか知らない状態になっていないか |
特に注意したいのが、前の開発会社だけが管理者権限を持っている状態です。
通常の利用者としてシステムへログインできても、
サーバー設定を変更できない
ドメインを変更できない
APIキーを再発行できない
新しい開発会社のアカウントを追加できない
のであれば、別会社への引継ぎには追加の対応が必要です。
また、ソースコードやサービスを別会社へ渡してよいかは、以前の開発契約や利用している製品・サービスの条件によって確認が必要な場合があります。
ここは技術だけで判断せず、以前の契約書や利用条件も確認する方が安全です。
筆者の実体験：ソースコードが残っていても、引継ぎできる状態とは限らない
筆者自身、事業会社の情報システム部門で、引継ぎ資料が十分に整備されていない既存システムを引き継いだ経験があります。
当時は、引継ぎ資料を読んでもシステムの全体像を十分に把握できず、実際に動いているシステムを一つずつ確認しながら構造を読み解く必要がありました。
特に大変だったのがデータベースです。
データベースのテーブルや項目の物理名が連番で付けられており、対応する論理名も残っていませんでした。
そのため、
このテーブルは何を管理しているのか。この項目は画面上のどの値なのか。どの処理から更新されているのか。
といったことを、実データ、画面の動作、ソースコードを突き合わせながら読み解く必要がありました。
資料が不足しているだけなら、まだ調査して補える部分があります。
さらに問題だったのが、どのように本番へデプロイしていたのかを把握している人がいなかったことです。
調べてみると、Gitなどのバージョン管理システムは使用されておらず、残っていたのは日付付きのフォルダに保存された複数世代のソースコードでした。
つまり、
ソースコードは残っている。
という状態ではありました。
しかし、
どれが現在の本番環境と一致しているのか。どの手順でビルドしていたのか。どのファイルを本番へ配置していたのか。どのようにリリースしていたのか。
は、別途調査しなければ分かりませんでした。
これは、「ソースコードを受け取った」ことと「システムを引き継げた」ことは同じではないという分かりやすい例です。
新しい担当者や開発会社が、
現在の状態を再現し、変更し、試験し、安全に本番へ反映できるところまで情報と権限をつなげられるか。
そこまで確認して、初めて実務上の引継ぎが成立します。
仕様書などの資料が不足している既存システムをどのように調査するかについては、「仕様書がない既存システムでも改修を依頼できる？最初に行う調査とは」で詳しく解説しています。
開発会社の切替でよくある失敗
前の開発会社との契約を終わらせるときは、「早く関係を切りたい」という意識が先に立つことがあります。
ただし、必要な情報や管理権限を移す前に旧環境を整理してしまうと、その後の引継ぎが難しくなることがあります。
古い開発会社のアカウントを先に削除する
新しい会社が入るからといって、旧担当者のアカウントをすぐにすべて削除すると、そのアカウントしか持っていなかった情報へアクセスできなくなることがあります。
まず、
そのアカウントが何を管理しているか
自社側に同等以上の管理者アカウントがあるか
新しい開発会社用のアカウントを発行できるか
を確認します。
必要な権限を自社管理へ移した後に、旧会社のアカウントを停止する方が安全です。
もちろん、不正アクセスなどの懸念があり、セキュリティ上ただちに停止する必要がある場合は別です。
手元にあるソースコードを「最新版」と決めつける
社内フォルダからソースコード一式が見つかったとしても、それが現在の本番環境と一致するとは限りません。
筆者の実体験のように、日付付きのフォルダが複数残っているだけで、どれを本番へ反映したのか分からないケースもあります。
この状態で、
一番日付が新しいから、これが最新版だろう。
と判断して改修を始めるのは危険です。
まず現在の本番環境との関係を調べ、新しい開発会社が基準にするソースコードを確定してから変更を始める必要があります。
管理者ID・パスワードをそのまま新しい会社へ渡す
引継ぎを急ぐあまり、自社で使用している管理者IDとパスワードをそのまま新しい開発会社へ共有するのも避けたい進め方です。
可能であれば、新しい会社用のアカウントを発行し、作業に必要な権限だけを付与します。
こうしておけば、
誰がアクセスしたのか分かる
権限の範囲を調整できる
契約終了時にその会社のアカウントだけ停止できる
ため、その後の管理もしやすくなります。
「システムが動いているから大丈夫」と考える
現在ユーザーが問題なく利用できていると、
システムは正常に動いているので、別会社でもそのまま改修できるだろう。
と考えてしまうことがあります。
しかし、本番システムが動いていることと、
開発環境を作れる
ソースコードを変更できる
ビルドできる
試験できる
本番へリリースできる
問題があれば元へ戻せる
ことは別です。
稼働状況ではなく、変更可能性を確認する。
これが開発会社を切り替えるときの重要な視点です。
新しい開発会社へは「すぐ改修」ではなく、まず引継ぎ調査を依頼する
前の開発会社がいない状態で、
この画面に項目を一つ追加してください。
と新しい開発会社へ依頼しても、その変更だけを見てすぐ作業できるとは限りません。
たとえば、新しい会社としては、
どのソースコードを変更すればよいか
どのように開発環境を用意するか
どのデータベースへ接続するか
他の処理へ影響しないか
どのように試験するか
どのように本番へ反映するか
を確認する必要があります。
そのため、最初の依頼を、
○○画面の改修
だけにするのではなく、
既存システムの引継ぎ調査と、○○画面改修の可否確認
とする方法があります。
現行システムの調査だけを先に外注し、その結果から改修範囲を決めることもできます。
「バックエンド開発を外注するとき、どこまでを成果物として切り出せるのか」でも、現行システムの調査を先に切り出す考え方について紹介しています。
引継ぎ調査では、単に仕様を調べるだけではなく、
新しい開発会社がアクセスできる環境
管理者権限の所在
ソースコードの管理状況
開発・試験の方法
リリース方法
ロールバック方法
外部サービスとの接続
改修対象の影響範囲
などを確認します。
この段階で「何が分からないのか」を整理できれば、いきなり大きな改修を発注するよりもリスクを抑えやすくなります。
実案件では「発注側が開発チームを管理しなくてよい」形も成立する
プレイリーソリューションズが担当した証券会社向けの案件では、
テキストの株価情報を音声にして、インターネットラジオとして配信したい。
という段階から相談が始まりました。
当初は、作るものの具体的な形や、必要となる技術も完全には決まっていませんでした。
そこで、
要件定義
基本設計
詳細設計
実装
インフラの選定・構築
本番リリース
までを一貫して担当しました。
この案件では、発注側が、
開発者を何名集め、誰に何を割り振り、技術的な進捗をどう管理するか
という体制を別途組む必要はありませんでした。
必要だったのは、
実現したいサービスについて合意し、その実現を一定の範囲として任せること
です。これは、「エンジニアを何人確保するか」を中心とした発注とは異なる考え方です。
もちろん、案件の規模や発注側の体制によって適した進め方は変わります。
ただ、バックエンド領域を外部へ任せる際には、必ずしも発注側が個々の開発要員を管理する必要はなく、機能や成果物の完成に責任を持つ開発会社へまとまった範囲を任せる方法もあります。
引継ぎは、小さな改修を一つ通すところまで確認する
ソースコードを受け取った。
サーバーへログインできた。
管理画面のアカウントも発行できた。
ここまで進むと、「引継ぎは終わった」と考えたくなります。
しかし、実務上はまだ十分とは限りません。
引継ぎ後に重要なのは、
調査する → 開発環境で変更する → 試験する → 本番へ反映する
という一連の流れを、新しい開発会社だけで一度通せる状態にすることです。
たとえば最初に、
文言の変更
管理画面の小さな項目追加
軽微な不具合修正
影響範囲の小さい設定変更
などを実施します。
その過程で、
正しいソースコードを取得できるか
開発環境が動くか
ビルドできるか
データベース変更を反映できるか
試験できるか
本番リリース手順が分かるか
障害時に元へ戻せるか
を確認できます。
筆者が経験したケースでも、問題は単に「資料が少ない」ことだけではありませんでした。
残っているソースコードから、現在動いている状態と本番への反映方法を再構築しなければ、安心して次の変更へ進めない。
そこが引継ぎの難しいところです。
そのため、引継ぎの完了条件は、
前の開発会社から資料を受け取った。
ではなく、
新しい開発会社だけで、小さな変更から本番リリースまで一度完了できた。
と考える方が実務的です。
別会社への引継ぎが難しくなるケースもある
前の開発会社がいなくても引継ぎできるケースはありますが、状況によっては難易度が高くなります。
たとえば、
現在動いているソースコードを特定できない
本番サーバーやクラウドへ自社からアクセスできない
クラウドやドメインの契約主体が旧開発会社になっている
新しい会社へ必要な管理権限を発行できない
データベースのバックアップを取得できない
開発に必要な製品・ライセンスを利用できない
外部サービスの契約主体が旧開発会社になっている
古い技術で、同じ開発環境を再現できない
ソースコードの利用・改変条件を契約上確認できない
本番への反映方法が分からず、実行可能なリリース手順を再構築する必要がある
といった状態です。
この場合でも、すぐに、
すべて新しく作り直しましょう。
と決める必要はありません。
まず、
何が不足しているために新しい会社が変更できないのか
を整理します。
不足しているものによって、
管理者アカウントを再取得する
契約名義を変更する
新しい環境へ移行する
現行システムを解析する
リリース手順を再構築する
一部だけ作り直す
全体を段階的に再構築する
など、取るべき対応は変わります。
調査の結果、既存システムをそのまま引き継ぐより、一部または全部を再構築した方が安全だと判断する場合もあります。
重要なのは、「前の会社がいないから改修不能」と最初から決めるのではなく、何が引継ぎを阻害しているのかを特定することです。
プレイリーソリューションズでは、引継ぎ前の現状調査から対応しています
バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、他社が開発した既存Webシステムについて、現状調査から改修・機能追加まで対応しています。
前の開発会社から完全な引継ぎ資料がなくても、
現在のシステム構成
ソースコードの管理状況
データベース
実行環境
AWSなどのインフラ
外部API・外部サービス
管理アカウント・権限
現在の業務運用
リリース方法
などを確認し、どこまで引継ぎ・改修が可能かを整理します。
最初から既存システム全体を対象にするのではなく、
現状調査 → 管理状況・改修範囲の整理 → 小さな改修 → 必要に応じて保守・追加開発
と段階を分けて進めることも可能です。
Java / AWSを中心としたバックエンド開発、API連携、決済連携、既存Webシステム改修などを対応領域としています。
開発会社が廃業した、担当者が退職した、以前の会社と連絡が取れない。
その状態でも、別会社へ既存システムの改修を依頼できる場合があります。
最初に確認したいのは、前の開発会社から何ページの資料を受け取ったかではありません。
新しい開発会社が、現在のシステムを調査・変更・試験・リリースできるだけの管理権限を確保できるか。
特に確認したいのは、
ソースコードを誰が管理しているか
サーバー・クラウドの契約主体は誰か
自社に管理者権限があるか
ドメインやDNSを自社で変更できるか
外部サービスの管理権限を自社が持っているか
新しい開発会社用の権限を発行できるか
現在のソースから本番へ反映する方法を再現できるか
です。
そして、引継ぎのゴールは、
資料とソースコードを受け取った。
ことではありません。
新しい開発会社だけで、変更から試験、本番リリースまで一度通せる状態になること。
ここまで確認できて初めて、次の改修を安心して任せやすくなります。
自社でWebシステム・業務システムを運用している事業会社の方で、「前の開発会社と連絡が取れず、誰が何を管理しているのか分からない」「別会社へ引き継げる状態なのか調べてほしい」という場合は、プレイリーソリューションズへご相談ください。
現在の環境と管理状況を調査し、別会社で改修を再開するために必要な情報・権限の整理から対応します。
