仕様書がない先代システムの仕様を、動きから逆算して復元する方法

「この画面のこのボタンを押すと何が起きるのか、正確には誰も説明できない」。先代のシステムを引き継いだ承継社長から、驚くほどよく聞く言葉です。長年動き続けてきたシステムほど、その中身がブラックボックス化していることは珍しくありません。仕様書や設計書が残っていない業務システムは、中小企業では珍しくありません。先代の代に、開発を依頼した担当者と話し合いながら少しずつ作り込まれ、正式な文書化がされないまま何年も稼働し続けている。そうしたシステムは、動作原理が誰にも分からないレガシーシステムになっていることがほとんどです。

とはいえ、仕様書がないからといって、システムの中身を諦める必要はありません。実際の動作を手がかりに、仕様を逆算して復元していく方法があります。この記事では、その具体的な手順を解説します（「触ると壊れる」と警告されたシステムの調査順序は「触ると壊れる」と先代に言われ続けたシステムを調査する順番も参考にしてください）。

株式の承継や登記の変更であれば、税理士や司法書士に相談すれば専門的な支援を受けられます。ところがシステムの仕様となると、相談できる専門家自体が身近にいないことが多く、承継社長が一人で手探りで向き合わざるを得ない場面が少なくありません。この記事は、そうした状況にいる人のために、非エンジニアでも実践できる調査の進め方を整理したものです。

この記事で分かること

仕様書・設計書が一切残っていない先代のシステムについて、実際の画面操作やデータの動きから仕様を推測・復元していく方法を、調査の優先順位に沿って解説します。ソースコードが読めない非エンジニアの承継社長でも、外側から観察できる情報だけで、ある程度まで実態をつかむことができます。

調査の基本方針は次の3つです。

• ブラックボックスとして扱う: 中身を分解する前に、まず「何を入れたら、何が出てくるか」を観察する
• 一次情報を優先する: 人の記憶より、実際の画面・データ・帳票を優先して確認する
• 完璧を目指さない: 全機能を解明する必要はなく、業務に影響する部分から優先的に調べる

IPA（情報処理推進機構）が発行する「システム再構築を成功に導くユーザガイド」でも、現行システムの調査・分析は再構築計画の最初のステップとして位置づけられており、ここを丁寧に行うことが、その後の判断ミスを防ぐ土台になります。専門的な開発経験がなくても、この最初のステップだけは自分の手で進められます。

なぜ先代のシステムには仕様書が残っていないのか

調査に入る前に、そもそもなぜ仕様書が残っていないのかを理解しておくと、調査の見通しが立てやすくなります。

中小企業の業務システムの多くは、先代が個人的な信頼関係で開発会社や個人のエンジニアに依頼し、要望を口頭で伝えながら段階的に機能を追加していく形で作られてきました。正式なプロジェクトとして要件定義書を作成し、仕様書を納品物として受け取る、という進め方が最初から取られていないケースが大半です。信頼している相手だからこそ、書面での取り決めを省略してしまう、という側面もあります。

さらに、開発した担当者が退職・独立したり、開発会社自体が廃業していたりすると、当時の経緯を知る人が社内にも社外にも誰もいない、という状態に陥ります。先代自身も、細かい仕様までは把握しておらず、「頼んだら、こうなった」という認識しか持っていないことも珍しくありません。

もう一つよくある背景として、当初は簡易的な仕組みとして作られたものが、業務の拡大に合わせて場当たり的に機能を追加され続け、気づけば会社の基幹業務を支える重要なシステムになっていた、というパターンがあります。作られた当初の規模感のまま、正式な文書化のタイミングを逃し続けてしまった結果、今になって「なぜこんなに複雑なのか誰も説明できない」という状態に陥っているのです。こうした経緯を知っておくことで、「なぜ先代はきちんと記録を残さなかったのか」と原因を追及する方向に労力を使うのではなく、「今、目の前にあるシステムをどう理解するか」という前向きな調査に集中しやすくなります。

先代・古参社員への聞き取りは「補助線」として使う

仕様の調査を始める前に、先代や古参社員から話を聞けるのであれば、聞いておいて損はありません。ただし、ここで得られる情報はあくまで「補助線」として扱うべきで、それだけを根拠に判断を進めるのは危険です。

人の記憶は、時間が経つほど曖昧になります。「たしかこういう仕組みだったはず」という先代の説明が、実際のシステムの動作と食い違っていることは珍しくありません。悪意があるわけではなく、単に細部を覚えていない、あるいは当時から正確に把握していなかっただけ、というケースがほとんどです。

先代との関係性によっては、この聞き取り自体に気を遣う場面もあるかもしれません。それでも、システムの背景を知る唯一の手がかりが先代の記憶である以上、機会があるうちに話を聞いておく価値は十分にあります。

聞き取りをする際は、以下のような点を意識すると、有益な情報を引き出しやすくなります。

• 「なぜこの機能を作ったのか」という背景を聞く（仕様そのものより、意図を知ることで挙動の理解が進みやすい）
• 「困ったことはあったか」を聞く（過去のトラブル事例から、システムの弱点が見えてくる）
• 「今も同じように動いているか」を確認する（改修が加えられ、当時の説明と現状が変わっている可能性がある）

聞き取った内容は、この後の章で説明する「確認できたこと」と「推測にとどまること」を分けて記録するルールの中で、必ず「推測」側に分類し、実際の画面・データでの裏取りを忘れないようにしてください。

また、先代がすでに完全に引退し、連絡が取りづらい状況にある場合は、無理に聞き取りにこだわる必要はありません。この記事で紹介する調査方法は、そもそも「誰にも聞けない」状態を前提に組み立てているため、聞き取りができなくても支障なく進められます（開発を依頼していた会社自体と連絡が取れない場合は先代の代からの開発会社と連絡が取れなくなったとき、まず確認すべき3つのことを参照してください）。

調査の大原則: 触る前に、まず観察する

仕様が分からないシステムに対して、最もやってはいけないのが「試しに触ってみる」ことです。本番データが入っている状態で、仕様の分からないボタンを押したり、設定を変更したりすると、取り返しのつかないデータ破損につながりかねません。

調査は、次の順番で進めてください。

1. 画面を見る（操作しない）
2. 出力される帳票・データを見る（操作しない）
3. 実際に使っている人の操作を観察する（自分では操作しない）
4. ここまで終えてから、テスト環境か、影響の小さい範囲で操作を試す

本番環境しか存在せず、テスト環境がない中小企業のシステムは多くあります。その場合、いきなり自分で操作するのではなく、まず実際の利用者の隣で操作を見せてもらうことを優先してください。

この「観察してから動く」という順番は、システムに限らず、承継直後のあらゆる場面で応用できる考え方です。良かれと思って先に手を動かしてしまうと、意図せず現場を混乱させたり、取り返しのつかない結果を招いたりすることがあります。まずは現状を正確に理解することを優先し、判断や操作はそのあとに回す、という姿勢を調査全体で徹底してください。

調査を始める前に確認しておきたいこと

具体的な調査手順に入る前に、次の3点を確認しておくと、その後の作業がスムーズになります。

誰が今、このシステムを一番よく使っているか

先代よりも、実際に日々の業務でシステムを操作している現場の担当者のほうが、仕様の細部を把握していることがよくあります。まずは「このシステムを一番使っているのは誰か」を特定し、その人に協力を仰ぐ体制を整えることが、調査全体の効率を大きく左右します（従業員10人未満の会社で誰に聞くべきかの見極め方は従業員10人未満の承継1年目は、誰に聞くかを最初の1ヶ月で決め切るも参照してください）。

保守契約が残っているか

先代の代からの開発会社との保守契約がまだ有効な場合、契約の範囲内で「システムの仕様に関する質問」に答えてもらえることがあります。まずは契約書を確認し、保守の範囲にどこまで含まれているかを確認してください。契約が切れている、あるいは開発会社と連絡が取れない場合は、この記事で紹介する自力調査が中心的な手段になります。

バックアップは取れているか

調査のために画面を操作する前に、システムのバックアップが直近でいつ取られているかを必ず確認してください。バックアップが確認できていない状態で操作を始めるのは、たとえ閲覧のつもりであっても避けるべきです。誤操作が起きた場合に、復元できる状態を確保してから調査に入ることが、何より優先されます。

ステップ1: 画面遷移を一覧化する

最初に取り組むべきは、システムの画面構成を一覧にすることです。ログイン画面から始まり、メニュー、各機能の画面まで、どんな画面があり、どうつながっているかを図か表にまとめます。

このとき、完璧な画面設計書を作る必要はありません。以下の程度の粒度で十分です。

上記はあくまで一例です。自社のシステムに合わせて項目名や粒度を調整しながら、実際の画面を一つずつ確認して埋めていってください。

画面数が多いシステムでは、すべてを一度に洗い出そうとせず、日常業務で最も頻繁に使われる画面から優先して着手してください。

一覧化の作業は、専用のツールを使う必要はありません。方眼紙に手書きで画面遷移図を描いたり、市販の表計算ソフトに画面名を書き出したりする程度で十分です。むしろ、承継直後の限られた時間の中では、道具選びに時間をかけるより、実際に手を動かして記録を残すスピードを優先してください。

画面の一覧化を進める過程で、「この画面、何のためにあるのか分からない」というものが出てくることがあります。無理にその場で解明しようとせず、いったん「用途不明」のまま先に進み、他の画面の調査が進んだ段階で改めて戻ってくると、周辺情報から用途が見えてくることもあります。

ステップ2: 入力と出力の対応関係を確認する

画面の一覧ができたら、次は「何を入力すると、何が出力されるか」の対応関係を確認します。これがブラックボックスとしての仕様把握の中核です。

この段階で焦って全ての機能を試そうとする必要はありません。1日1〜2機能程度のペースでも構わないので、確実に記録を積み重ねていくことを優先してください。

具体的には、以下のような観察を行います。

• 受注データを1件入力すると、在庫数はどう変化するか
• 月末に締め処理をすると、どんな帳票が出力されるか
• ある項目を空欄のまま登録しようとすると、エラーになるか、それとも通ってしまうか

実務上のコツ: 実際の利用者に「いつもと違う入力をしたことはありますか」と聞いてみると、想定外の挙動に関する貴重な情報が得られることがあります。マニュアル通りの使い方だけでなく、現場の"クセ"のような使い方の中に、仕様の手がかりが隠れています。

観察の結果は、その場でメモに残す習慣をつけてください。「後でまとめて記録しよう」と考えていると、細かい挙動の違いを忘れてしまい、結局同じ操作を何度も見返す羽目になります。スマートフォンのカメラで画面を撮影しておくだけでも、後から見返す際の助けになります。

ステップ3: データベースの中身を覗いてみる

システムがデータベースを使っている場合（多くの業務システムがそうです）、データベースの中身を直接確認できると、調査は大きく進みます。

Accessで作られた古い業務システムであれば、Access（データベースソフト）の画面から直接テーブルの構造を見ることができます。SQLServerやMySQLなどを使ったシステムでも、閲覧専用の権限があれば、テーブル名やカラム名から、システムが何を管理しているかをある程度推測できます。

テーブル名やカラム名が「T_JUCHU」「M_TORIHIKISAKI」のように分かりやすい命名になっていれば、それだけで多くのヒントが得られます。反対に、「TBL01」「FIELD_A」のような無機質な命名の場合は、実際のデータの中身を見ながら、何が入っているかを一つずつ確認していく地道な作業になります。

データベースへの直接アクセスは、誤って更新・削除をしてしまうリスクがあるため、必ず閲覧専用の権限で行うか、専門知識のある人に立ち会ってもらうことをおすすめします。なお、データベースの構造そのものが複雑に入り組んでいて、テーブル間の関連が見えてこない場合、これは自力調査の限界に近いサインです。無理に読み解こうとせず、この記事の後半で紹介する「外部の専門家に相談する」選択肢を検討する目安にしてください。

ステップ4: Excel・帳票に残る痕跡を探す

システム本体だけでなく、そこから出力された帳票や、システムと連携しているExcelファイルにも、仕様を読み解く手がかりが残っています。

先代の代から使われてきたExcelファイルの中には、VBAマクロでシステムと連携し、データを取り込んだり、独自の集計を行ったりしているものが見つかることがあります。こうしたExcelファイルは、システム単体の調査では見えてこない「実際の業務での使われ方」を教えてくれる貴重な資料です。

過去数ヶ月分の帳票を並べて見比べることで、「この項目は毎回同じ値が入っている」「この項目は月によって計算方法が違う」といった規則性やイレギュラーに気づくこともあります。

帳票やExcelファイルは、システム本体以上に個人のパソコンやメールに散らばっていることが多いため、社長室の引き出しやパソコンの中を確認する際に、システム関連の資料と合わせて回収しておくと効率的です。特に、先代が個人的に作成・更新していた集計用のExcelファイルは、システムでは対応しきれていない業務の実態を映し出す鏡になっていることがあります。

業種別に見る、調査で特に注意したいポイント

業種によって、システムの中で特に複雑になりやすい部分は異なります。自社の業種に合わせて、優先的に確認すべき箇所の見当をつけてください。

製造業・卸売業

在庫管理や原価計算のロジックが、Excelマクロと業務システムをまたいで組み合わさっていることが多く、システム単体を見ただけでは全体像がつかめないケースが目立ちます。仕入・在庫・出荷のデータがどの順番で連携しているかを、実際の伝票の流れと突き合わせながら確認する必要があります。

小売業・サービス業

POSレジと在庫・売上管理システムが別々に導入され、後から連携部分だけを追加開発している場合があります。連携部分は特に、担当者の異動や退職とともに仕組みが分からなくなりやすい箇所です。日々の売上データがどのタイミングでどこに反映されるかを、時間帯を分けて観察すると仕組みが見えてきます。

建設業・工事関連

原価管理や工事台帳が、案件ごとに個別のExcelファイルで管理され、それが独自にシステムと連携している場合があります。案件数が多い会社ほど、この「個別ファイルの集合体」が実質的な基幹システムになっていることがあり、システム本体だけを調査しても全体像はつかめません。

ステップ5: 分かったことを記録し、分からないことも明示する

調査で分かった内容は、簡単な資料としてまとめておきます。この段階で目指すのは、完璧な仕様書の再現ではありません。「このシステムは何をするものか」「何に注意すべきか」が、後から読んでも分かる程度の記録があれば十分です。

記録する際は、次の2つを分けて書くことを意識してください。

• 確認できたこと: 実際に画面・データ・帳票で確認した事実
• 推測にとどまること: おそらくこうだろう、という仮説の段階の情報

この2つを混同して記録してしまうと、後で「確認済みの仕様」として扱われ、誤った前提で判断が進んでしまう危険があります。分からないことは正直に「不明」「要確認」と書いておくほうが、結果的に安全です。焦って空欄を埋めようとせず、事実と推測の境界を曖昧にしないことを、記録全体を通じて徹底してください。

この記録は、将来的にシステムの刷新を検討する際、開発会社に現状を説明する資料としても使えます。ゼロから調査をやり直さずに済むという意味で、費やした時間は決して無駄になりません。

記録の形式は、Excelの一覧表でも、Wordの文書でも、社内で使い慣れたツールで構いません。重要なのは形式の立派さではなく、承継後に別の担当者が見ても理解できる状態になっていることです。担当者が変わるたびに調査をゼロからやり直す事態を避けるためにも、この記録自体をシステム管理台帳の一部として保管しておくことをおすすめします（台帳全体の作り方は属人化した先代システムを防ぐ、承継後の管理台帳の作り方で詳しく解説しています）。

記録を残す作業は、地味で後回しにされがちですが、承継後何年か経ってから振り返ったときに、その価値が最も分かる作業でもあります。「あのとき調べておいてよかった」と思える瞬間は、たいてい忘れた頃にやってきます。

調査で見つかりやすい落とし穴

仕様の逆算調査を進めていく中で、いくつか典型的な落とし穴があります。あらかじめ知っておくと、余計な混乱を避けられます。

「使われていない機能」に見えて、実は使われている

メニューの奥にある、普段使われていない機能に見えても、月次・年次といった低頻度でしか使わない処理であるケースがあります。決算処理や年次の締め作業に関わる機能は、日常的な観察だけでは見落としやすいため、月次・年次のサイクルまで視野に入れて調査してください。

同じような画面が複数ある

過去の改修の際、既存の画面をコピーして新しい画面を作り、古い画面を削除し忘れたまま放置されている、というケースもよく見られます。似た画面が複数見つかった場合は、実際にどちらが使われているかを利用者に確認し、使われていない方は「未使用の可能性が高い」と記録しておきます。

例外処理だけ別のところで手作業になっている

システムが対応しきれない例外的なケースだけ、担当者がExcelや紙で個別に処理している、というパターンも頻出します。一見システムがすべてを処理しているように見えても、月に数件、特定の条件のときだけ手作業が挟まっている、ということがあるため、「例外はありますか」と直接尋ねる質問を調査項目に加えておくと発見しやすくなります。

自力での調査に限界を感じたら

ここまで紹介してきた方法は、いずれも専門的な開発知識がなくても実践できる範囲を想定しています。それでも、以下のような状況に当たった場合は、無理に自力で解決しようとせず、外部の専門家に相談する判断も選択肢に入れてください。

• データベースの構造が複雑で、素人目には手がかりがまったくつかめない
• システムが複数のプログラム言語・技術で組み合わさっており、動作原理の見当がつかない
• 誤操作によるデータ破損のリスクが高く、これ以上は自己判断で触りたくない

外部の開発会社に調査を依頼する場合でも、この記事で紹介した手順に沿って自分なりに分かったこと・分からないことを整理しておくと、依頼時の説明がスムーズになり、調査費用や期間を抑えられる可能性があります。まったくの白紙の状態で相談するより、「ここまでは分かっているが、ここから先が分からない」という状態で相談したほうが、専門家も的確な提案をしやすくなります。

相談する開発会社は、必ずしも先代の代からの付き合いのある会社である必要はありません。むしろ、しがらみのない第三者の開発会社に調査だけを依頼し、客観的な現状把握を得るという進め方も、承継後のシステム対応では現実的な選択肢の一つです。仕様書もソースコードも無い状態からの調査・引き継ぎそのものを専門に受け付けている会社（システム引き継ぎ・レスキュー、運営会社ゼットリンカーの受託メニュー）に相談する選択肢もあります。誰に相談するかを決める段階でも、焦って1社だけに絞らず、複数の選択肢を比較検討する余地を残しておいてください。

どこまでを自力で調査し、どこから専門家に頼るかの線引きに、絶対的な正解はありません。会社の規模、システムの複雑さ、承継社長自身が使える時間によって、最適なバランスは変わります。まずは無理のない範囲で自力調査を進め、限界を感じた時点で相談する、という柔軟な姿勢で臨んでください。

まとめ

仕様書がない先代のシステムを調査する作業は、地道で時間のかかる作業です。しかし、いきなり触って壊してしまうリスクを避けながら、画面・データ・帳票という一次情報を積み重ねていけば、専門的な開発知識がなくても、実務に必要な範囲の仕様は十分に把握できます。

先代が何年もかけて積み上げてきたシステムの中身を、文書という形でほとんど残していなかったことに、承継直後は戸惑うかもしれません。しかし、それは先代個人の落ち度というより、多くの中小企業に共通する構造的な課題です。この記事で紹介した手順を一つずつ実践していけば、承継社長自身の手で、会社の重要な経営資源であるシステムの実態を、少しずつ言葉と記録に変えていくことができます。

焦らず、一つずつ。それが、仕様書のないシステムと向き合うときの、最も確実な近道です。今日確認できた一つの事実が、明日の判断を支える土台になります。

大切なのは、確認できたことと推測にとどまることを分けて記録し、無理にすべてを解明しようとしないことです。ここで作った記録は、将来システムを刷新するかどうかを判断する際にも、必ず役に立ちます。

よくある質問

Q. データベースに直接アクセスする権限がない場合、どうすればよいですか。

管理者権限が不明な場合は、まず先代・古参社員に「システムの管理者アカウントを知っているか」を確認してください。それでも分からない場合は、開発会社に問い合わせる、あるいはシステムの管理画面のログイン試行履歴から手がかりを探すといった方法があります。権限が全く得られない場合は、画面操作の観察と帳票の確認だけでも、ある程度の仕様把握は可能です。

Q. 調査にどれくらいの期間を見込めばよいですか。

システムの規模や複雑さによって大きく異なりますが、日常業務で使う主要な機能に絞った調査であれば、数週間から1〜2ヶ月程度を目安にするとよいでしょう。全機能を完全に解明しようとすると際限がなくなるため、業務への影響が大きい部分から優先順位をつけて進めることをおすすめします。

Q. 調査結果を、これから刷新の相談をする開発会社にそのまま渡してもよいですか。

「確認できたこと」と「推測にとどまること」を分けて記録しておけば、そのまま参考資料として開発会社に共有して問題ありません。むしろ、現状の業務フローや仕様の理解度を示す資料として、見積もりの精度を高める効果が期待できます。ただし、記録の中に誤りが含まれている可能性がある前提で、開発会社側にも実機での再確認を依頼するとより確実です。

Q. 調査の途中で、システムに重大な不具合やセキュリティ上の問題を見つけた場合はどうすればよいですか。

業務に支障が出る不具合や、情報漏えいにつながりかねないセキュリティ上の問題を見つけた場合は、詳細な調査を続ける前に、まず経営層への報告を優先してください。特に、顧客情報や取引先情報の管理に関わる問題は、対応の遅れが会社の信用に直結します。緊急性が高いと判断した場合は、この記事で紹介した手順の途中であっても、専門家への相談を前倒しで検討してください。

仕様の復元と合わせて、そのシステムが動いているサーバー自体の脆弱性も点検しておきたい。先代の代からのサーバーが壊れたら何が止まる？単一障害点の洗い出し方で確認できる。