システム引き継ぎで用意する資料は何か｜実際に出てくるもの、役に立つもの、何も無いときの手がかり

他社が作ったシステムの保守や刷新を相談するとき、「資料が何も残っていないのですが、それでも見てもらえますか」と切り出されることがよくあります。この記事は、FUNBREWが引き継ぎの相談を受けたときに実際に何が出てきて、そのうち何が調査の役に立ち、何が思ったほど役に立たないのかを、開発会社側の視点でまとめたものです。記事の最後に、相談の前に探しておくとよいもののリストを置きました。

引き継ぎの相談で、実際に出てくる資料はどんな状態か

結論を先に書くと、出てくるのは現状のシステムそのもの（ソースコードがある場合とない場合の両方があります）と、当時作られたきり更新されていない古いマニュアル、というのが多いパターンです。設計書一式が最新の状態で保管されている、という状況にはまず出会いません。

資料が無いこと自体は、珍しくない

作った会社との連絡が途絶えている、担当者が退職している、そもそも納品物に設計書が含まれていなかった。事情はさまざまですが、資料が揃っていない状態は例外ではなく、むしろ引き継ぎ相談の標準的な入り口です。ですから、揃っていないことを理由に相談をためらう必要はありません。

全く役に立たない資料は無い。ただし陳腐化している前提で読む

調査する側としては、少しでもとっかかりが欲しいというのが正直なところです。そのため、全く役に立たない資料というものはありません。古いマニュアルであっても、当時どういう業務を想定して作られたのかという手がかりになります。

ただし前提があります。出てきた資料はおおむね陳腐化していると考えながら読み進めます。「これは現状と違う可能性がある」と頭の片隅に置いたまま調査するのが大前提であり、資料の記述をそのまま信じて設計を進めることはありません。だからこそ、古いという理由で資料を出さない判断だけは、しないでいただきたいのです。

意外と役に立たないもの、あると助かるもの

Gitは移行には効くが、業務知識は出てこない

意外に思われるかもしれませんが、Gitによるバージョン管理は、期待されるほど調査の役には立ちません。もちろん、別のサーバーへ移行したり手元にクローンして動かしたりするには非常に便利で、あるに越したことはありません。しかし、そこから本当に欲しい業務知識が読み取れることは多くないのが実際です。

コミット履歴が教えてくれるのは「いつ、どこが変わったか」であって、「その機能が何のために存在するのか」ではありません。逆に、Gitが無くレンタルサーバー上のファイルしか手がかりが無い状況では、変更の痕跡を追う作業そのものが重くなります。Gitは移行・複製・変更履歴の追跡に効き、業務知識の解明には効かない——この役割の違いを押さえておくと、期待値を間違えずに済みます。サーバーやコードを実際に見て何を判断しているかは、手を入れるより作り直した方が早いと判断するときで詳しく書いています。

あると助かるのは、ソースコード、次にドキュメント

この順番には理由があります。ソースコードが残っていない場合、既存の動きを引き継ぐという選択肢自体が消え、作り直しの検討に入らざるを得ません。実際にその判断に至った経緯はソースコードがないシステムは保守を引き継げるのかにまとめてあるので、ここでは繰り返しません。

ドキュメントは、検索したり引用したりできるテキスト形式が望ましいものの、画面写真が貼られたマニュアルでも十分に参考になります。「体裁が悪いから」「途中までしか書かれていないから」と選別せずに出していただくのがいちばん助かります。ドキュメントの整備そのものについてはシステム保守に必要なドキュメント一覧と整備方法もあわせてご覧ください。

資料が何も無いとき、何を手がかりにするか

資料がゼロでも調査は進みます。手がかりは大きく3つです。

手がかりは、動いているものと、人

• 現行のシステム自体を触る —— 実際に動かして、画面と挙動から仕様を読み取ります。
• 稼働しているサーバーの調査 —— 何がどう動いているかを、環境そのものから確認します。
• 顧客へのヒアリング —— 資料にもコードにも書かれていない「なぜそうなっているか」は、聞くしかありません。

資料が無い状態からの引き継ぎの進め方は、仕様書なしのシステム保守引き継ぎでも扱っています。

社内で誰に聞けると早いか

聞く相手は担当者です。ここで注意したいのは、どの会社にもシステムに詳しい担当者やSEがいるとは限らないということです。情報システム部門がある前提で書かれた記事は多いのですが、実際の中小企業では、総務や経理の方が兼任で窓口をしているケースが普通にあります。詳しくなくても構いません。当時の経緯を少しでも知っている方が窓口になってくださるだけで、調査の速度は変わります。

もう一人、今もそのシステムを日々触っているオペレーターがいれば、ぜひ話をさせてください。実際の使われ方は、資料にも管理者の説明にも出てこないことがあります。運用している人の目線が、引き継いだ後の品質にそのまま効いてきます（引き継ぎをやり切った後、何が変わったか）。

まとめ：相談の前に探しておくとよいもの

最後に、引き継ぎや刷新を相談する前に、社内で探しておくと話が早くなるものを挙げます。すべて揃っている必要はありません。

• ソースコード —— 手元、サーバー上、開発会社から受け取った媒体のいずれでも。あるかないかで進め方が大きく変わります。
• ドキュメント（古くて構いません） —— 操作マニュアル、当時の仕様書、画面の入った説明資料など。テキストだと助かりますが、画像入りでも参考になります。
• 稼働中のサーバーへアクセスする手段 —— 契約先や管理画面のログイン情報など、どこまで分かるか。
• 聞ける人 —— 経緯を知る担当者と、今そのシステムを使っているオペレーター。

この4つのうち、いくつ出せるかで初動の速さが変わります。ひとつも揃わない場合でも、現行システムとサーバーから調査を始められますので、まずはお問い合わせからご相談ください。