古い業務システムの入れ替えを考え始めたものの、仕様書も設計書も見当たらない。作った人はもう社内にいないし、開発会社に聞いても「ソースコードを見ないと分からない」と言われる。そんな状況で、何から手をつければいいのか迷う方は少なくありません。
「古い業務システムの仕様書が残っていない。入れ替えの前に、まず何を整理しておけばいいのか分からない」
先に結論をお伝えします。仕様書がなくても、入れ替えの検討は始められます。 最初にやるのは、立派な仕様書を作り直すことではありません。今のシステムが「何をしているか」「何の上で動いているか」「どんなデータを持っているか」「現場がどう使っているか」「誰と何の契約に支えられているか」の5つを、A4数枚のメモにまとめることです（執筆時点：2026年11月）。
この記事では、その5つの整理のしかたを、開発会社にそのまま渡せるチェックリストと質問例とあわせて解説します。法律や契約の個別の判断は、必要に応じて弁護士や専門家にご確認ください。
仕様書がないまま入れ替えを進めると、何が困るのか
整理に入る前に、なぜ今のシステムの中身が大事なのかを押さえておきましょう。理由が分かると、どこまで整理すればよいかの見当もつきます。
IPA（情報処理推進機構）のガイド「システム再構築を成功に導くユーザガイド 第2版」は、システムの再構築（＝今のシステムを作り直したり、新しいシステムへ移したりすること）が失敗する原因として、時間が経って不明瞭になった現行システムの仕様があいまいなまま、新しいシステムの開発に着手してしまうことを挙げています。
📰 出典：IPA「システム再構築を成功に導くユーザガイド 第2版」
また、経済産業省の「レガシーシステムモダン化委員会総括レポート」（2025年5月）では、古いシステムの特徴のひとつとして、仕様や設計の資料が整っておらず、運用が特定の人に頼った「ブラックボックス化」が挙げられています。
📰 出典：経済産業省「レガシーシステムモダン化委員会の総括レポートを取りまとめました」（2025年5月28日）
つまり、仕様書がないのは珍しいことではなく、「だからこそ、入れ替えの前に現状を確かめておく」ことが大事だと言われているわけです。
開発会社の側から見ても、現状が分からないシステムは、作業量の見当がつきません。見積もりが幅の広いものになったり、着手後に「こんな機能もあった」と分かって追加の相談になったりしやすいのは、多くの場合こうした事情によります。
入れ替えの前に整理しておきたい5つのこと
1. 今のシステムが「何をしているか」を一覧にする
最初に作るのは、機能の一覧です。きれいな文書でなくて構いません。次の4種類を、思いつく範囲で書き出します。
| 種類 | 書き出すもの | 見つけ方の例 |
|---|---|---|
| 画面 | メニューに並ぶ画面の名前、誰が使うか | メニューを上から順に開いて、画面のスクリーンショットを撮る |
| 帳票・出力 | 印刷する伝票、CSV、メールなど | 実際に出力された現物を集める |
| 定期処理（バッチ） | 夜間や月末に自動で動く処理 | 担当者に「毎月・毎日、勝手に動いているものは？」と聞く |
| 外部との連携 | 会計ソフト、取引先、銀行、他のシステムとのデータのやり取り | 受け渡しているファイルや、連携先の名前を担当者に聞く |
特に見落とされやすいのが、定期処理と外部連携です。画面には出てこないので、使う人が意識していないことが多く、入れ替えのあとで「月末の集計が出ない」と気づく原因になります。
2. 動いている環境と部品を書き出す
次に、システムが何の上で動いているかを確認します。技術に詳しくなくて構いません。現在の保守担当や開発会社、サーバーの請求書から分かる範囲で埋めます。
- サーバー（＝システムが動いているコンピューター）はどこにあるか（社内、データセンター、クラウド）
- OS（Windows、Linux など）と、そのバージョン
- 開発に使われている言語やソフト（分かる範囲で）
- ドメイン（＝Webサイトの住所のようなもの）や、証明書の管理者と更新時期
- 管理者用のログイン情報を誰が持っているか（パスワードそのものはメモに書かず、「誰が保管しているか」だけ書く）
ここで「誰も分からない」項目が出てきたら、それ自体が大切な発見です。入れ替えの前に、まず確認が必要な項目として印をつけておきます。
3. データの置き場所・量・扱いを確かめる
入れ替えで最も手間がかかりやすいのは、画面ではなくデータの移行（＝今のデータを新しいシステムに引き継ぐこと）です。費用の考え方は別の記事で詳しく扱っています。
詳しくは次の記事で解説しています。
ここでは、整理の対象だけを挙げます。
- どんなデータがあるか（顧客、商品、受注、請求、勤怠など）
- 何年分あるか、おおよその件数はどのくらいか
- どこに保存されているか（データベース、サーバー内のファイル、Excel など）
- 個人情報や取引先の機密情報が含まれるか
- 法令や社内ルールで保存が必要な期間があるか（一般論としては、帳簿や契約関係の書類に保存期間が定められています。個別の扱いは税理士などの専門家に確認してください）
- 古すぎて、もう使わないデータはないか
「全部移す」と決める前に、移すもの・保管だけするもの・捨てるものに分ける材料がここで揃います。
4. 現場の使い方と「例外ルール」を聞き取る
仕様書にもコードにも書かれていないのに、業務に欠かせない運用があります。たとえば次のようなものです。
- 画面の機能では足りず、Excel に書き出して手で直してから使っている
- 特定の取引先だけ、入力のしかたが違う
- 月末だけ、決まった順番で処理しないとエラーになる
- 「この項目は空欄のままにする」といった暗黙の約束がある
これらは、システムの外にある「業務の仕様」です。新しいシステムを作るときに、最も抜け落ちやすい部分でもあります。
聞き取りは、使っている人に1日の仕事の流れを話してもらうのが一番確実です。「このシステムで困っていること」と「このシステムがなくなると困ること」の2つを聞くと、必要な機能とそうでない機能が見分けやすくなります。
5. 人・契約・ソースコードの所在を確かめる
最後に、システムを支えている人と契約を確認します。入れ替えの話し合いが止まる原因は、技術よりもここにあることが少なくありません。
- 今の保守担当は誰か（社内の人か、開発会社か、個人か）
- 保守契約の範囲と期間、解約するときの条件
- ソフトのライセンス（＝使う権利の契約）の有無と期限
- ソースコード（＝システムの設計図にあたるプログラムの元の文章）は手元にあるか、誰が保管しているか
- 開発した会社と、いま連絡が取れるか
- 納品時の契約で、ソースコードや成果物の権利がどう決められているか
契約や権利の読み方は、案件ごとに異なります。気になる点があれば、契約書を持って専門家に相談してください。
仕様書がないときの現実的な進め方
5つを自分たちだけで埋めきる必要はありません。分からないところは「分からない」と書き、次の順に進めると無理がありません。
- 上の5つを、分かる範囲でメモにする（半日〜数日程度）
- 開発会社に、そのメモを見せたうえで「現行システムの調査」を見積もりに含めてもらう
- 調査の結果を、簡単な資料（機能一覧とデータの一覧）として納品してもらう
調査は、ソースコードやデータベースを開発会社が読み解いて、仕様を復元する作業です。費用や期間は、システムの大きさや残っている資料によって変わります。ここを省くと、着手後に「分かっていなかった部分」が見つかって追加の相談になりやすいため、最初から範囲に入れて話しておくほうが、結果的に見通しが立ちます。
どの入れ替え方法を選ぶかの考え方は、次の記事でまとめています。
やりがちな失敗
- 仕様書を一から作り直そうとして、検討が止まる：完成度よりも、まず現状の一覧を作ることを優先します。
- 担当者の記憶だけに頼る：口頭の説明は、必ずスクリーンショットや現物の帳票とセットで残します。
- 「今と同じものを作って」とだけ伝える：今の不満や、本当は不要な機能も引き継いでしまいます。残すもの・変えるものを分けて伝えます。
- ソースコードの所在を確かめないまま、入れ替えの日程を決める：手元になければ、先に取り戻す交渉が必要になることがあります。
発注者がやること チェックリスト
- ☐ 画面・帳票・定期処理・外部連携を、分かる範囲で一覧にした
- ☐ サーバーやOSなど、動いている環境を書き出した
- ☐ データの種類・保存場所・おおよその量・個人情報の有無を確かめた
- ☐ 使っている人に、1日の流れと「なくなると困ること」を聞いた
- ☐ 保守担当、保守契約、ライセンス、ソースコードの所在を確認した
- ☐ 「誰も分からない」項目に印をつけた
- ☐ 現行システムの調査を、見積もりに含めてもらうよう依頼した
開発会社への質問例
- 「仕様書が残っていません。現行システムの調査は、見積もりにどこまで含まれますか。」
- 「調査の結果として、機能一覧とデータの一覧を納品物にしていただけますか。」
- 「ソースコードとデータベースを見たうえで、調査後に見積もりの幅がどれくらい狭まりそうか、教えてください。」
- 「画面に出てこない定期処理や外部連携は、どのような方法で洗い出しますか。」
- 「調査で想定外の機能が見つかった場合、費用や期間の相談はどのような手順になりますか。」
まとめ
仕様書がなくても、入れ替えの検討は始められます。大切なのは、立派な資料を作ることではなく、今のシステムの機能・環境・データ・現場の使い方・人と契約の5つを、分かる範囲で書き出しておくことです。
そのメモを持って開発会社に相談すれば、現行システムの調査を見積もりに入れてもらいやすくなり、着手後の「聞いていなかった」を減らせます。まずは、メニューの画面を順に開いてスクリーンショットを撮るところから始めてみてください。
あわせて読みたい関連記事
