長く使っている業務システムについて、「動いてはいるが、中身を説明できる人が社内にいない」という状態は珍しくありません。作った担当者が退職した、開発を任せていた会社との付き合いが終わった、 小さな改修を重ねるうちに当初の資料と実物がずれた——きっかけはさまざまですが、行き着く先は同じで、 直したくても触れない、止まっても誰が対応するのか決まっていない、という状況になります。
この状態から抜け出す入口は、作り直しの検討ではなく現状把握と引き継ぎです。 今何が動いていて、何に依存していて、誰が困るのかが分からないままでは、直す・置き換える・そのまま使う、 どの判断も根拠を持てません。この記事では、受託開発を手がけるCoconutWorksが、 仕様書のない既存システムを引き継ぐときの進め方を、資産の洗い出しからドキュメント化の範囲、 AIによるコード解読の位置づけまで、費用の数字を出さずに整理します。
結論: 引き継ぎは5つの段階に分けて進める
| 段階 | 何をするか | 終わったと言える状態 |
|---|---|---|
| ① 資産と環境を洗い出す | ソース・サーバー・ドメイン・アカウント・外部連携の所在と名義を一覧にする | 把握できていない契約や権限が残っていない |
| ② 使われ方を確認する | 誰がいつどの機能を使い、止まると何が困るかを業務側から聞く | 重要度の高い機能と、実は使われていない機能が区別できている |
| ③ 中身を読み解く | ソースとデータベースから実際の処理を確認し、聞いた話とのずれを埋める | 主要な処理の流れとデータの持ち方に見当がついている |
| ④ 記録に残す | 引き継いだ後に見返す前提で、判断に必要な範囲だけ文書化する | 別の人が同じ判断を再現できる |
| ⑤ 次の一手を決める | 現状維持・部分改修・作り直しのどれを選ぶかを判断する | 選択肢ごとの前提と影響が言葉で説明できる |
順番には意味があります。②の使われ方を確認する前に③のコード解読から入ると、重要でない処理に時間を使い、年に一度しか動かない大事な処理を見落とすことが起きます。 また①を飛ばすと、読み解きが進んだ頃になって「本番サーバーの契約が退職者の個人名義だった」といった問題が出てきます。 以下、それぞれの段階を掘り下げます。
なぜ「仕様が分からない」状態になるのか
仕様が失われるのは、資料を作らなかったからとは限りません。多くの場合、作った時点の資料は存在するのに、その後の改修が反映されていないことが原因です。 納品時の設計書はあるものの、その後の細かな修正は依頼メールとソースコードにしか残っていない。 すると資料と実物がずれ、ずれた資料は読まれなくなり、読まれない資料はますます更新されなくなります。
もう一つの経路が、知識が人に貼り付いたままになることです。 たとえば受注管理システムを長く使っている会社で、月末の締め処理だけは決まった順番で操作しないとデータが合わない、 という運用が残っているとします。担当者にとっては手が覚えている手順なので、わざわざ書き残す動機がありません。その人が異動や退職でいなくなった瞬間に、システムの一部が説明できないものに変わります。
この二つが重なると、社内には「触ると危ないらしい」という感覚だけが残り、改修の相談も止まります。 引き継ぎの目的は完璧な資料を作ることではなく、この「怖くて触れない」を「判断できる」に変えることだと考えると、やるべき範囲が絞りやすくなります。
最初にやること — 資産と環境の洗い出し
引き継ぎで最初に手をつけるのは、コードを読むことではなくシステムが動くために必要なものを全部並べることです。 ソースコードだけそろっても、実行環境の設定や外部サービスのアカウントが欠けていればシステムは動きません。 並べる対象と、それぞれで確認しておきたい点は次のとおりです。
| 洗い出す対象 | 確認しておきたいこと |
|---|---|
| ソースコード | どのリポジトリ・どのフォルダが本番と一致するか。複数の版が散らばっていないか |
| サーバー・実行環境 | 契約者の名義と支払い方法。個人名義・個人のカードのままになっていないか |
| ドメイン・SSL | 更新期限と管理者メールアドレス。退職者のアドレスが登録されたままになりやすい箇所 |
| データベース | バックアップが取得されているか、そして復元を試したことがあるか |
| 外部サービス・API | メール送信・決済・地図・認証など、止まると業務に直結する連携先と、その管理者権限 |
| 運用ルール | 月次や年次のように、たまにしか実行しない手作業の手順が残っているか |
一覧にするときは、「何が・どこに・誰の名義で・止まると何が困るか」の4つを列に持たせておくと、後の判断にそのまま使えます。 特に名義は見落とされやすい項目で、創業期に担当者が個人で契約したサーバーがそのまま本番で使われている、 といったケースは実際にあります。支払いが止まる・アカウントが消えるだけでシステムが止まる状態は、 仕様が分からないこと以上に緊急度が高い問題です。
つまずきやすいのは、「今動いているから急ぐ必要はない」と後回しにしてしまうことです。 ドメインの更新期限やサービスのサポート終了は、こちらの都合とは無関係にやってきます。 洗い出しはコードの読み解きより手間がかからないことが多く、先に済ませておくと安心して次へ進めます。
コードより先に、使われ方を業務側に聞く
次の段階は、実際に使っている人へのヒアリングです。狙いは操作手順の記録ではなく、業務の流れのどこにシステムが挟まっているかを把握することにあります。 機能一覧を上から順に確認する形だと、使う人の頭にある業務の順序とかみ合わず話が出てきません。 「受注が入ってから請求までにどんな作業をしますか」と業務の側から聞き、その中でシステムを触る場面を拾うほうが漏れが減ります。
このとき忘れずに確認したいのが、頻度の低い処理です。日々の入力や検索は誰でも説明できますが、 月次の締め、年度の切り替え、繁忙期だけ使う一括処理は、聞かれなければ話題に上がりません。 引き継ぎを短期間に詰め込むと、この一年に一度しか動かない処理が丸ごと抜け落ちるという失敗が起こります。 業務の一年分のサイクルを書き出し、それぞれの時期にシステムで何をするかを確認する形にすると防ぎやすくなります。
ヒアリングにはもう一つ効果があります。画面としては存在するのに、実際には誰も使っていない機能が見つかることです。 使われていない部分が分かれば調べる範囲を狭められますし、将来の作り直しの検討でも 「これは移さなくてよい」という判断材料になります。範囲を絞ることは手抜きではなく、 限られた時間を重要な部分に向けるための整理です。
中身を読み解く — AIで変わること・変わらないこと
使われ方の見当がついたら、ソースコードとデータベースを実際に確認していきます。 近年はこの工程でAIを使う場面が増えており、変化が出やすいのは読む量と速さが問われる下ごしらえの部分です。 全体の構造の見取り図を作る、テーブルと項目の一覧を起こす、影響が及びそうな箇所を挙げる、 古い言語の処理の流れを日本語で説明する。こうした作業は、人が一行ずつ追う場合より短時間で形になります。
一方で、変わりにくい部分もはっきりしています。コードが語れるのは「何をしているか」であって、「なぜそうなっているか」は書かれていません。 一見不自然な条件分岐が、実は特定の取引形態に合わせた業務上の必要から入っている、ということはよくあります。 その背景を知っているのは業務側の人であって、コードでもAIでもありません。読み解きの結果は、 使っている人の説明と突き合わせて確かめる工程が要ります。
実務でつまずきやすいのは、AIが出した説明をそのまま資料に貼ってしまうことです。 出力には、コードから確かめられる事実と、文脈からの推測が混ざり込むことがあります。どのファイルのどの部分を根拠にしているかを残す運用にしておくと、 後から読む人が確かめ直せますし、推測の部分だけを業務側に質問する形に持っていけます。 AIの活用で発注側にとって何が変わるかはAIコーディングを使う開発会社に頼むと何が変わるのかでも整理していますので、あわせてご覧ください。
ドキュメントはどこまで作るか
引き継ぎで手が止まりやすいのが、文書化の範囲です。網羅的な仕様書を目指すと途中で力尽き、 仮に作り切っても改修のたびに更新されず、また実物とずれた資料が生まれます。 現実的なのは、引き継いだ後に誰が何を判断するかから逆算して範囲を決めるやり方で、 優先度の高いものから挙げると次のようになります。
- ①資産と環境の一覧 — 前述の表の内容。止まったときにどこを見ればよいかが分かる、最も使用頻度の高い資料です。
- ②業務の流れと機能の対応 — どの業務のどの場面で、システムのどこを使うか。新しい担当者が全体像をつかむ入口になります。
- ③データの持ち方 — 主要なデータが何を単位に保存されているか。改修の相談を受ける側が最初に知りたい情報です。
- ④止まったときの手順 — 誰に連絡し、何を確認し、どう復旧するか。使う場面が限られるからこそ、記憶に頼らず残す価値があります。
- ⑤触ると影響が大きい箇所と理由 — 読み解きの過程で分かった注意点。理由まで書いておかないと、次の人がまた同じ調査をすることになります。
逆に、全画面の詳細仕様書や網羅的な項目定義書は、手間の割に読まれないことが多い部類です。 コードとデータベースを見れば分かる情報を、二重に管理し続けることになるためです。コードを見れば分かることは書かず、コードを見ても分からないことを書く、 という切り分けが目安になります。
置き場所も決めておきます。担当者のパソコンやメールの中に資料があると、その人がいなくなった時点で今回と同じ状況が繰り返されます。 社内で共有される場所を一つ決め、そこに集めるところまでを引き継ぎの作業に含めてください。
迷ったときのチェックポイントと、進め方の順序
どこから手をつけるか判断しづらいときは、次の点を確認すると急ぐべき範囲が見えてきます。 いずれも専門知識がなくても社内で確認できる項目です。
- 止まったら業務が止まるか — 半日使えないと困るのか、数日待てるのか。影響の大きさが優先順位をそのまま決めます。
- 社内に触れる人がいるか — 操作は分かるが中身は分からない、という状態も「いない」に近い扱いで考えます。
- 作った会社と連絡が取れるか — 取れるなら、資料や環境の情報をもらえるうちにもらっておくのが先決です。
- 動作環境のサポート期限が来ていないか — 期限切れは、こちらの都合と関係なく対応時期を決めてしまいます。
- 個人名義の契約が混ざっていないか — 混ざっている場合は、仕様の把握より先に名義の移管を進めたほうが安全です。
進め方の順序は、資産の洗い出し、止まったときの影響の見立て、使われ方の確認、中身の読み解き、記録、次の一手の判断、という流れです。 外部に相談する場合も、いきなり刷新の見積もりを取りにいかないことをおすすめします。 仕様が分からない状態で各社に声をかけると、それぞれが別の想定で金額を出すため比較が成り立ちません。 現状把握や調査だけを切り出して依頼し、その結果を材料に次の依頼を出すほうが、遠回りに見えて話が早く進みます。 現状を把握したうえでの選択肢の整理はレガシーシステム刷新の進め方で扱っています。
あわせて、この場面で繰り返されやすい誤解も挙げておきます。
- 「ソースコードさえ受け取れば終わり」 — 動かすにはコードのほかに環境の設定・接続情報・データ・運用手順が要ります。受け取ったものの設定値が分からず起動しない、ということも起こり得ます。
- 「分からないなら作り直したほうが早い」 — 現行が何をしているか分からないまま着手すると、公開後に「以前は自動でやっていた処理がない」という抜けが出ます。順序としては把握が先で、把握の結果そのまま使い続ける結論になることもあります。
- 「引き継ぎは退職直前にまとめてやればいい」 — 短時間では日常業務の話しか出ず、頻度の低い処理やトラブル対応の経緯が残りません。担当者がいるうちに少しずつ書き出してもらうほうが、同じ手間でも残る情報の質が変わります。
よくある質問
まとめ
仕様書のない既存システムの引き継ぎは、資料を完璧にそろえる作業ではなく、判断できる状態を取り戻す作業です。 資産と環境を洗い出し、使われ方を業務側から確認し、そのうえで中身を読み解く。 記録は引き継いだ後に使う範囲に絞り、共有される場所に置く。この順序を守るだけでも、 「触ると危ないらしい」という状態からは抜け出しやすくなります。
担当者の退職が決まっている、開発元と連絡が取れない、直したい箇所があるが影響範囲が分からない—— こうした状況では、現状把握だけを先に切り出してご相談いただくこともできます。 現在の状況をお伺いしたうえで、どこから手をつけるかの整理からお手伝いしますので、お気軽にご相談ください。 相談・お見積もりは無料です。
