システムの保守を引き継いだら、最初にやること：資料の少ない既存システムを把握して、次の開発を計画する

業務システムやサービスを作ってもらった会社が、ある日、対応できなくなることがあります。担当のエンジニアが辞めた、会社が事業を変えた、連絡が取りにくくなった。理由はさまざまです。そうなったとき、発注した会社は、別の開発会社に保守や追加開発を引き継いでもらうことになります。

乗り換えるときに今の会社から何を受け取り、契約で何を確かめるかは、開発会社を途中で変えるときにまとめました。この記事はその続きです。引き継いだあと、システムをもう一度「直せる、足せる」状態にするまでに、何をするのかを書きます。発注する側にとっては、引き継ぎ先の会社が最初の数週間で何をしているのかを知ることで、相談や見積もりの中身を判断しやすくなるはずです。

結論：最初にやるのは「把握」と「計画」

引き継いだ直後に、すぐ新しい機能を作り始めることはおすすめしません。まず今の作りを把握し、そのうえで、何をどの順で直し、何を足していくかの計画を立てます。

クリーヴァが、別の開発会社が作ったサービスを引き継いだときも、最初にしたのはこの2つでした。既存の実装を把握すること、そして追加開発の計画を立てることです。資料や開発の環境は、十分に整っている状態ではありませんでした。最初に把握と計画から始め、その後は必要な機能を足しながら、少人数で開発を続けています（くわしくは後の「クリーヴァの例」で書きます）。

なぜ、引き継いだシステムはすぐに直せないのか

資料とコードと、動いている姿がずれている

長く使われてきたシステムでは、設計書などの資料と、ソースコードと、実際に動いている姿が、少しずつずれていきます。IPA の『システム再構築を成功に導くユーザガイド 第2版』は、このずれが生まれる理由を次のように説明しています。

仕様変更を実施した際に、変更の契機となった業務についてはドキュメントとソースコードの双方を更新したが、関連する業務のドキュメントは更新が必要であることが分からず更新しなかったといったケースや、障害対応時にソースコードを修正したもののドキュメントを修正しなかったといったケースがある。

（IPA『システム再構築を成功に導くユーザガイド 第2版』より）

同じガイドには、設計書があることを前提に開発を進めたところ、5割以上の設計書が実際のシステムと合っておらず、くわしい人もいないことが分かった、というトラブルの事例も載っています。資料があっても、それが今の姿と合っているとは限りません。資料が少なければ、なおさらです。

作った人がいないと、属人的な知識が失われる

経済産業省のレガシーシステムモダン化委員会の総括レポート「DXの現在地とレガシーシステム脱却に向けて」（2025年5月）は、レガシーシステムの要因の一つに「ブラックボックス化」を挙げ、その中身を次のように書いています。

• 仕様や設計のドキュメントが整備されておらず、新システムへの移行や再構築時に支障が発生
• システムの運用維持保守が属人的な状態に陥っている
• システム障害発生時に原因がすぐに特定できない

作った会社が対応できなくなるのは、まさに「属人的だった知識」が失われる場面です。同じレポートの調査では、企業がシステムを新しくすることを決めるきっかけとして、大きな障害や、保守をしていた人の離脱といった、問題が起きてからの受け身の理由が上位に来ています。引き継ぎは、準備が整ってから始まるとは限らない、ということです。

だからこそ、引き継いだ側は、いきなり手を入れずに、まず今の姿を自分たちの目で確かめる必要があります。

既存の実装を把握する：何を確かめるか

把握の目的は、「このシステムを安全に直せるか、足せるか」を判断できるようにすることです。全部を理解しきる必要はありません。次の項目を、動かして、読んで、確かめます。

この表のうち、引き継いだ直後にいちばん効くのは「動かせるか」です。本番と同じものを手元で動かせないと、直した結果を試す場所がありません。試さずに本番を直すことになり、引き継いだばかりの時期に障害を起こしやすくなります。

手元で動かすまでに、何がそろっていないかを洗い出す

手元で動かそうとすると、ソースコードだけでは足りないことがすぐに分かります。動かすには、たとえば次のものが要ります。

• 接続先やパスワードなどの設定値（多くはソースコードの外に置かれています）
• 外部サービスのテスト用のアカウントや鍵
• 画面を確かめるためのテスト用のデータ
• どの版の言語やミドルウェアで動いているか、という情報

資料が少ないシステムでは、これらがどこにも書かれていないことがあります。足りないものを一つずつ洗い出し、発注した会社や、前の会社から受け取れるものは受け取ります。受け取れないものは、新しく作り直します。

このとき、本番のデータをそのまま手元に持ってこないように気をつけます。本番のデータには、利用者の個人情報が含まれていることが多いからです。テスト用のデータを作るか、個人を特定できる部分を置き換えたデータを使います。

部品の版と、サポートの期限を確かめる

引き継いだシステムでは、使っている言語やフレームワークの版が、すでに古くなっていることがあります。部品にはそれぞれ、不具合や脆弱性の修正を受けられる期間があります。たとえば次のとおりです。

• PHP は、それぞれの版が最初の公開から2年間は不具合と脆弱性の修正を受けられ、その後の2年間は重大な脆弱性の修正だけを受けられます。4年が過ぎると、修正は出なくなります（PHP 公式「Supported Versions」）。
• Node.js は、長期サポート（LTS）になる偶数の版でも、最初の公開からおよそ36か月でサポートが終わります。奇数の版は、さらに短い期間で終わります（Node.js の Release）。

期限の切れた部品は、新しい脆弱性が見つかっても修正が出ません。把握の段階で、使っている部品の版と期限を一覧にしておくと、次の計画で「何を先に更新するか」を決めやすくなります。

資料が少ないときは、最低限の資料を作りながら把握する

資料が少ないときは、把握しながら、最低限の資料を作っていきます。最初から立派な設計書を作り直す必要はありません。次のくらいがあれば、引き継いだ側も、発注した側も、同じものを見て話せるようになります。

• システムの構成図（サーバー、データベース、外部サービスのつながり）
• 画面と機能の一覧
• 主なデータの一覧と意味
• 本番に出す手順と、問題が起きたときに戻す手順

これらは、把握の途中で分かったことを書き留めたものです。次に誰かが引き継ぐときにも、そのまま使えます。システムが特定の人の頭の中だけにある状態から、少しずつ抜け出していくための作業でもあります。

「今の動き」をそのまま正しいと決めつけない

把握の途中で、資料と動きがずれている所や、意図が分からない処理が見つかることがあります。このとき、今の動きをそのまま正しいと決めつけないことが大切です。前の担当者が急いで入れた仮の処理かもしれませんし、使われていない機能かもしれません。

IPA のガイドも、ソースコードと資料が食い違うときは、どちらの情報で実現したいのかを見極めないと、誤った「今のとおり」になってしまう、と注意しています。分からない所は、発注した会社の担当者や、実際に使っている人に聞いて確かめます。引き継いだ側だけで決めないことが、あとで「そんなつもりではなかった」を防ぎます。

把握の結果を、発注した会社と共有する

把握が一区切りついたら、その結果を発注した会社と共有します。技術の細かい話をすべて伝える必要はありません。次の4つに分けて伝えると、判断に使いやすくなります。

「まだ分からない所」を隠さずに伝えることが大切です。分からない所がある状態で計画を立てると、後から見積もりが変わることがあるからです。分からない所を先に共有しておけば、その所を確かめる作業も計画に入れられます。

引き継いだ直後に、やらないほうがよいこと

把握の途中では、気になる作りがたくさん見つかります。それでも、引き継いだ直後は、次のことは控えます。

• 大きな書き直しを一度にすること：読みにくいコードを一気に書き直すと、今のシステムが黙ってこなしている処理を壊すおそれがあります。
• 部品の版をまとめて上げること：一度に多くの部品を更新すると、問題が起きたときに原因を絞り込めません。危ない所から一つずつ上げます。
• 使われていないように見える機能を、確かめずに消すこと：月に一度、年に一度だけ使われる機能もあります。消す前に、使っている人に確かめます。

どれも、把握が進み、確かめる仕組みが整ってから取りかかれば、安全に進められることです。

追加開発の計画を立てる：何から手を付けるか

把握ができたら、次の開発の計画を立てます。引き継いだシステムでは、やりたいことがたくさん出てきます。新しい機能の要望、気になる作り、古い部品。全部を同時には進められないので、順番を決めます。

IPA のガイドも、作り直しの企画の段階で、今のシステムの資産の量と質、くわしい人がいるかどうか、といった現状を正しく認識することが大切だと書いています。作り直す場合に限らず、引き継いだシステムに手を入れるときも同じです。把握の結果が、計画の土台になります。

順番の決め方

順番は、おおむね次のように考えます。

1. 止まると困る所と、危ない所：古くて更新を受けられない部品、権限の付け方の問題など。放っておくと、事故や障害につながる所です。
2. 直すたびに壊れやすい所：テストがなく、直すと別の所が壊れる部分。ここに確かめる仕組みを少しずつ足すと、その後の開発が速くなります。
3. 事業として急ぐ機能：利用者や事業のために、いま必要な機能です。

ただ、3を後回しにしすぎると、引き継いだ意味が見えにくくなります。発注した会社にとって、引き継ぎの目的は「また機能を足せるようになること」だからです。1と2を小さく区切りながら、3も並行して少しずつ出していく計画にするのが現実的です。

作り直すかどうかは、把握のあとに決める

引き継いだ直後は、「いっそ作り直したほうが早いのでは」と感じることがあります。資料が少なく、作りが分かりにくいほど、そう感じやすくなります。

ただ、作り直すかどうかは、把握のあとに決めるべきです。把握する前に作り直しを決めると、今のシステムが黙ってこなしている処理を見落とし、新しいシステムで同じ失敗をくり返すおそれがあります。直して使い続けるか、作り直すかの判断の基準は、古いシステムは直すか、作り直すかにまとめています。

計画は、発注した会社と一緒に見直す

計画は、一度決めたら終わりではありません。引き継いでしばらくは、把握が進むほど新しい事実が出てきます。計画も、それに合わせて見直します。

見直すときは、発注した会社と一緒に決めます。何を先に直すかは、技術の都合だけでは決まりません。事業として何を急ぐか、どこまで費用をかけられるかは、発注した会社にしか決められないからです。改修の費用が何で決まるかは、業務システムの改修の費用は何で決まるかにまとめています。

最初の小さな修正で、本番に出す手順を確かめる

計画を立てたら、最初は小さな修正から始めます。文言の修正や、小さな不具合の修正など、失敗しても影響の小さいものです。

小さな修正の目的は、修正そのものより、「直して、確かめて、本番に出して、問題があれば戻す」という一連の流れが、引き継いだ側の手で回るかを確かめることです。この流れが一度回れば、その後の追加開発は、同じ流れに乗せていけます。逆に、この流れを確かめないまま大きな機能に取りかかると、本番に出す段階で初めて問題に気づくことになります。

前の会社と並行して関わる期間がある場合は、その間に一度、この流れを試しておくと安心です。並行期間の作り方は、開発会社を途中で変えるときに書いています。

クリーヴァの例：別の会社が作ったサービスを引き継いで、育てている

クリーヴァは、株式会社日本能率協会マネジメントセンター様の、キャリアコンサルタントと相談者をつなぐサービス「Knotter（ノッター）」の開発をお手伝いしています。

このサービスには、別の開発会社が作ったベースがありました。クリーヴァが引き継いだとき、ソースコードや開発の環境、資料は、十分に整っている状態ではありませんでした。そこで最初に、既存の実装の把握と、追加開発の計画から始めました。

その後の進め方は、株式会社日本能率協会マネジメントセンター様のインタビューで、次のように語られています。

• もともとあったベースをもとに検証を進め、その中で必要になった機能を追加してきた
• 今使っている機能のほとんどを、クリーヴァが開発している
• 1〜2名ほどの少人数のチームで開発し、必要に応じてデザイナーも加わる
• 担当者がコードを書きながら、事業についても会話できる
• プロダクトの状況によって「今は急いで開発したい」という時期があり、そうした変化に合わせて体制を変えている

利用している企業の人事担当者からは、キャリアコンサルタントと受講者の日程調整が、ツールを入れたことでワンストップでできるようになった、という声が届いているそうです。

登録しているキャリアコンサルタントからも、ほかのサービスと比べて機能が必要最低限に整理されていて使いやすい、という評価があると話されています。

資料が少ない状態で引き継いだシステムでも、最初に把握と計画から始めれば、その後は少しずつ機能を足しながら育てていけます。引き継ぎは、作り直すか、我慢して使い続けるかの二択ではありません。

引き継ぎ先の提案で、見ておきたいこと

引き継ぎ先を探すとき、いくつかの会社から提案や見積もりを受け取ることがあります。金額のほかに、次の点を見ると、引き継いだあとの進め方の違いが分かります。

• 把握の範囲と、その結果として何を受け取れるか：構成図や機能の一覧など、把握の結果が形として残るかどうか。
• 計画をどう見直すか：把握が進んで新しい事実が出たときに、どう相談して計画を変えるか。
• 体制：大人数である必要はありません。少人数でも、技術の話と事業の話を一緒にできる担当者がいるかどうか。Knotter の例でも、担当者がコードを書きながら事業の話もできることを、安心して任せられる理由に挙げていただいています。
• 最初から作り直しを前提にしていないか：把握の前に作り直しを勧める提案は、根拠が弱いことがあります。

開発会社の選び方の一般的な進め方は、SucSak の「ベンダー選定とは？進め方と選定基準・注意点」にまとまっています。

引き継ぎを頼む前に、発注する側が用意しておくもの

引き継ぎ先に相談するとき、次のものが分かっていると、把握が早く進みます。全部そろっていなくても大丈夫です。「ない」「分からない」ということ自体が、把握で確かめるべき所を教えてくれます。

• ソースコードの置き場所：どこにあり、誰がアクセスできるか
• 動いている環境の情報：サーバーやクラウドのアカウントと、その名義
• 外部サービスのアカウント：決済、メール、地図などの外部サービスと、その名義
• ドメイン：登録している会社、名義、更新の期限
• 手元にある資料：契約書、設計書、手順書など、どれがあるか
• 使っている人の声：よく使う機能、困っている所、最近起きた不具合

名義やアカウントの移し方、契約で確かめる権利については、開発会社を途中で変えるときでくわしく書いています。保守の契約の範囲と費用の一般的な考え方は、SucSak の「受託開発の保守はどこまで頼む？費用相場と契約の判断軸」が参考になります。ソースコードの権利については、SucSak の「システム開発の著作権は誰のもの？」にまとめられています。

よくある質問

資料がほとんどなくても、引き継いでもらえますか

資料が少ないことは、引き継ぎではよくあることです。この記事で書いたように、動かして、読んで、確かめながら、最低限の資料を作っていきます。ただし、ソースコードや動いている環境に入れない場合は、把握そのものができません。まずは、ソースコードと環境に入れるかどうかを確かめてください。

把握には、どれくらいかかりますか

システムの大きさ、資料の状態、外部とのつながりの数によって大きく変わります。決め打ちの期間を先に約束するより、まず把握の範囲を決めて、その結果をもとに追加開発の計画と見積もりを出すほうが、発注する側にとっても判断しやすくなります。

前の開発会社にも、協力してもらったほうがよいですか

協力してもらえるなら、そのほうが確実です。アカウントや名義の移し替え、本番に出す手順の確認など、前の会社にしか分からないことがあるからです。連絡が取れない場合でも、ソースコードと環境に入れれば、把握は進められます。

追加開発ではなく、保守だけを頼むこともできますか

できます。機能を足す予定がなくても、古くなった部品の更新、障害が起きたときの対応、定期的な点検など、システムを安全に動かし続けるための保守があります。保守だけを頼む場合も、最初にやることは同じで、今の作りの把握から始めます。把握ができていないと、障害が起きたときに原因を探すところから始めることになり、復旧までに時間がかかるからです。

保守の中身は、システムの使われ方によって変わります。毎日多くの人が使う業務システムと、月に数回だけ使う管理画面とでは、障害が起きたときにどれくらい急いで直すべきかが違います。どこまでを保守で頼むかは、引き継ぎ先と相談して決めます。

引き継ぎ先を探すとき、何を伝えればよいですか

システムの役割、引き継ぎたい理由、手元にあるもの、期限の4つが分かっていれば、最初の相談としては十分です。「前の会社と連絡が取れない」「資料がない」といった状況も、そのまま伝えてください。それによって、把握で最初に確かめる所が変わります。

作り直しを勧められたら、どう判断すればよいですか

まず、今のシステムの把握をしたうえでの提案かどうかを確かめてください。把握の結果、直して使い続けるより作り直したほうがよい、という根拠が示されていれば、検討する価値があります。判断の基準は、古いシステムは直すか、作り直すかにまとめています。

おわりに

作った会社が対応できなくなったシステムは、資料が少なく、作りも分かりにくいことがよくあります。そのときにまずやるべきなのは、急いで機能を足すことでも、作り直しを決めることでもなく、今の姿を把握して、次の開発の計画を立てることです。

把握と計画に時間をかけることは、遠回りに見えるかもしれません。それでも、引き継いだあとに「また直せる、また足せる」状態をつくる、いちばんの近道です。今動いているシステムの保守や引き継ぎで迷っていることがあれば、今のシステムの状態をうかがうところから、一緒に整理します。