仕様書がないシステムを引き継いだときの調査手順

「この画面、何のために動いているんですか」と聞いても、答えられる人が社内に誰もいない。フォルダの奥から出てきたのは、拡張子だけでは中身の想像がつかないファイルと、いつ作られたのかも分からない実行ファイルの束。マニュアルはおろか、簡単なメモ書きすら残っていない。それでも毎朝9時になると、そのシステムは何事もなかったかのように動き出し、請求データや在庫数を吐き出し続けている。

こうした「仕様書のないシステム」を引き継ぐことになった担当者は、決して珍しい存在ではありません。前任者が属人化した状態のまま退職し、動いているという事実だけを頼りに、誰かが後を継がなければならない。しかも相手は、もはや聞くことのできない過去の担当者が作り上げた仕組みです。何から手をつければよいのか、どこまで調べれば「分かった」と言えるのか、見当がつかないまま時間だけが過ぎていく。この記事は、そうした状況にいる方のために書きました。

先に結論を言います。仕様書がないシステムを理解する方法は、実は一つしかありません。動いているものを観察し、入力と出力の関係から仕組みを逆算することです。頭の中で仕様を推測するのではなく、実際にシステムが「何を受け取り、何を返しているか」を一つずつ確認していく。地道に見えますが、これが最も確実で、遠回りに見えて実は一番早い方法です。

この記事で分かること

この記事では、仕様書・設計書が一切ない状態で社内システムを引き継いだときに、動いているものから仕組みを調べていく調査手順を、着手前の心構えから具体的な調べ方、最終的な記録の残し方まで順を追って解説します。対象とするのは、要件定義や設計工程からは一切ノータッチで、すでに稼働しているシステムを「調査」しなければならない状況です。

調査の全体像を先に示すと、次の6段階で進めます。

• 段階1: 壊さないための準備(バックアップ・観察環境の確保)
• 段階2: 外側から見える範囲を洗い出す(画面・帳票・通知)
• 段階3: データの入口と出口を特定する(何を受け取り、何を吐き出しているか)
• 段階4: 中身(コード・設定・ジョブ)を確認する
• 段階5: 外部との連携先を洗い出す
• 段階6: 分かったことを記録し、仮説と事実を区別して残す

それぞれの段階でやることと注意点を、順番に見ていきます。

着手前に肝に銘じること。壊さないことが最優先

仕様書のないシステムを前にすると、多くの人が「早く理解しなければ」と焦り、いきなり設定を変更したり、動いているプロセスを止めて挙動を確認しようとしたりします。これが最も危険な行動です。

裏側の仕組みが分からないシステムほど、一見無関係に見える処理が、実は別の業務の土台になっていることがあります。夜間バッチが会計データの締め処理を兼ねていた、使われていないように見えるサーバーが実は社内DNSの役割を担っていた、といった話は珍しくありません。調査のために触った結果、業務が止まってしまっては本末転倒です。

調査に入る前に、必ず確認・準備しておきたいことを挙げます。

• 現状のバックアップを取得する(可能であれば。取得方法自体が分からない場合は、この確認作業も調査の一部になる)
• 本番環境と同じ内容を複製したテスト環境がないか確認する(あれば、そちらで検証してから本番に反映する)
• 「触ってよいもの」と「見るだけにとどめるもの」を自分の中で区別する(設定画面を開くだけなら安全、値を変更するのは危険、という線引きを都度意識する)
• 調査中に気づいたことは、その場でメモに残す(後で「あれ、さっき見た画面どこだっけ」とならないように)

実務上の心構え: 「動いているものは、動いている理由がある」という前提で臨んでください。一見不要に見える処理・ファイル・設定であっても、削除や停止をする前には必ず「なぜこれが存在するのか」の仮説を立て、確認が取れるまでは手を出さない。この姿勢が、調査中の事故を防ぐ最大の防御策になります。

段階1 全体像をつかむ。稼働している「箱」を数え上げる

最初にやるべきは、細部を追いかけることではなく、まず「システムがいくつの部品(サーバー・端末・クラウドサービス)で構成されているか」という全体像を把握することです。

具体的には、次の観点で洗い出しを行います。

この段階でのゴールは、詳細を理解することではなく「箱の数」を確定させることです。「サーバーが1台、クラウドサービスが2つ、パソコン上で動くマクロファイルが3本」といった具合に、まず全体の輪郭を描いてください。輪郭が見えないまま細部を追いかけると、後になって「実はもう一つ別の仕組みが動いていた」という手戻りが発生しやすくなります。

物理的なサーバーが社内に設置されている、いわゆるオンプレミスの環境である場合は、機器そのものの型番・設置場所・電源系統まで含めて確認しておくと、後の調査がスムーズになります。

段階2 外側から見える範囲を洗い出す。画面・帳票・通知を全部触る

箱の数が見えたら、次は実際にシステムを操作できる人の立場になって、外側から見える機能を一通り触ってみます。この段階では、まだ中身のコードを読む必要はありません。

チェックすべき項目を整理します。

1. ログイン画面があるか。あれば、どんなアカウントでログインできるか(管理者用・一般用の区別があるか)
2. メニュー・画面の一覧。表示されている機能を一つずつクリックし、何が表示されるかを記録する
3. 出力される帳票・ファイル。印刷される帳票、ダウンロードされるCSVファイルなどがあれば、そのファイルの中身と、どの業務で使われているかを確認する
4. 通知・アラートの有無。メール通知やポップアップ表示があれば、どんな条件で発生するかをメモする
5. エラーメッセージ。あえて誤った操作をしてみて、どんなエラーが出るかも手がかりになる(ただし本番データを壊さない範囲で)

この段階の作業は、いわば「使う人」の視点でのなぞり作業です。実際に業務でこのシステムを使っている社員がいれば、同席してもらいながら一緒に操作してもらうのが最も効率的です。使っている本人にとっては当たり前すぎて説明が省かれがちな操作こそ、外部から来た調査者にとっては重要な手がかりになります。

聞き取りのコツ: 「このシステムで何をしていますか」という漠然とした質問より、「今日一日でこの画面を何回開きますか」「この画面のこのボタンを押すと、その後どうなりますか」といった具体的な質問のほうが、実務に即した答えが返ってきやすくなります。

段階3 データの入口と出口を特定する。逆算調査の核心

外側からの操作が一通り分かったら、いよいよ調査の核心部分に入ります。「このシステムは、どこからデータを受け取り、どこにデータを渡しているか」を特定する作業です。仕様書がない状態でシステムを理解する際、最も再現性が高く確実なのがこの「入口と出口」からの逆算です。

入口の例を挙げます。

• 手入力(画面上のフォームに人がデータを打ち込む)
• 他システムからのファイル取り込み(CSV・Excelファイルのインポート機能)
• 他システムとの自動連携(API・データベース間の直接連携)
• 外部からのメール受信をきっかけにした処理

出口の例も同様に挙げます。

• 画面上の一覧・詳細表示
• 印刷される帳票
• 他システムへのファイル出力・自動連携
• メール送信・通知

入口と出口が分かれば、その間にある処理は「入力を出力に変換する仕組み」として捉えることができます。中身の処理ロジックが複雑で読み解けなくても、「何が入って、何が出るか」さえ押さえておけば、業務上の影響範囲はかなりの精度で把握できます。

たとえば、「毎日17時に自動生成される請求書データが、実は経理システムへのCSVファイル取り込みを前提にしている」と分かれば、生成処理そのものの中身を完全に理解していなくても、「このファイルが生成されなくなると経理の請求処理が止まる」という業務影響が見えてきます。仕様書がない状況での調査は、コードを一行ずつ読み解く精密さよりも、この業務影響の見える化を優先するほうが実務的です。

データの流れを図にする

入口と出口の関係が見えてきたら、簡単な図に起こすことを強くおすすめします。図というと大掛かりに聞こえるかもしれませんが、ホワイトボードや手書きのメモで十分です。

図に描き起こす際の基本形は次の通りです。

[入力元] → [処理・保存されている場所] → [出力先]

例えば次のような形になります。

現場の在庫入力(画面) → 在庫管理データベース(社内サーバー) → 日次で在庫一覧CSVを出力 → 経理担当が手動で会計ソフトに取り込み

この図を作る過程で、しばしば「あれ、この矢印がどこにもつながっていない」という気づきが得られます。それは、まだ調査できていない箇所を示すサインです。図を描くこと自体が、調査の抜け漏れを可視化する手段になります。

• 矢印が途中で途切れている箇所 → まだ調査が終わっていない箇所
• 一つの箱に矢印が集中している箇所 → 単一障害点（SPOF）になっている可能性が高い箇所
• 誰も使っていないはずの矢印がある箇所 → 実は誰かがまだ使っている、あるいは過去の名残で不要になっている箇所(判断は保留し記録だけしておく)

段階4 中身を覗く。ファイル・コード・設定を確認する

入口と出口の関係がおおむね見えてきたら、必要な範囲で中身の確認に進みます。ここで大事なのは「全部を理解しようとしない」ことです。仕様書がない状態からのスタートでは、コードの一行一行を完全に読み解くのは現実的ではありません。業務影響の大きい部分から優先順位をつけて見ていきます。

確認すべき対象の例です。

• プログラムファイルの種類(拡張子から使われている技術をある程度推測できる。.accdbはAccessのデータベースファイル、.xlsmはマクロ付きExcelファイルなど)
• 設定ファイル(接続先データベースの情報、外部サービスのURLなどが書かれていることが多い)
• ログファイル(処理が実行された記録が残っていれば、いつ・何が動いたかの実績を追える)
• コメント・作成日時(コード中にコメントが残っていれば、たとえ断片的でも貴重な手がかりになる。ファイルの作成日・更新日からも、いつ頃作られた仕組みかが推測できる)

自分自身にプログラミングの知識がない場合、この段階を丸ごと自力でこなすのは難しいこともあります。その場合は、無理に一人で読み解こうとせず、次のいずれかを検討してください。

• 保守契約を結んでいる会社があれば、現状調査として中身の確認を依頼する
• 社内・知人にプログラムを読める人がいれば、スポットで見てもらう
• セカンドオピニオンとして、契約前の会社に現状確認だけを依頼できないか相談する

無理に理解しようとして時間を浪費するより、「分からない部分がある」という事実を認め、適切な相手に確認を仰ぐほうが、結果的に早く前進できます。

定期実行されているジョブ・バッチ処理を見落とさない

システムの中には、人が操作しなくても決まった時刻に自動で動く処理が組み込まれていることがよくあります。夜間のデータ集計、月末の締め処理、定期的なバックアップなどです。こうした処理は画面上の操作からは見えないため、意識して探しに行かないと見落とされがちです。

確認方法の例を挙げます。

1. Windowsであれば「タスクスケジューラ」を開き、登録されているタスクの一覧と実行時刻を確認する
2. サーバーの管理画面や設定ファイルに、定期実行の設定(スケジュール設定)が残っていないか確認する
3. ログファイルに、決まった時刻に繰り返し出現する処理の記録がないか探す
4. 「毎月25日になると急に重くなる」「月初になるとエラーが増える」といった、社員の体感的な気づきを聞き取る

こうした定期処理は、レガシーシステムほど見落とされがちな一方、実は経理の締め処理や給与計算といった、止まると業務に直結する重要な役割を担っていることが少なくありません。「今は何も問題が起きていないから存在しないだろう」と決めつけず、必ず一度は確認しておくべき項目です。

段階5 外部との連携先を洗い出す。会社の外に何が漏れているか

社内で完結しているように見えるシステムでも、実際には社外の会社・サービスと何らかの形でつながっているケースが多くあります。この連携先の把握を怠ると、思わぬところで業務が止まったり、想定外のところにデータが送られていたりするリスクを見逃すことになります。

洗い出すべき連携先の例です。

• 外部のクラウドサービスとの自動連携(APIを使った自動的なデータのやり取り)
• 保守を委託している開発会社(誰がこのシステムの保守を担っているか。契約書・見積書・請求書から特定する)
• データの送信先(取引先や関連会社に自動でデータが送られる仕組みがないか)
• 外部からのアクセス経路(VPNやリモートデスクトップなど、社外から社内システムにアクセスできる経路が開いていないか)

もし保守を担っている会社が見つかれば、真っ先に連絡を取ることをおすすめします。開発会社側にシステムの構成資料が残っている可能性がありますし、たとえ資料がなくても、担当していた技術者の記憶から手がかりが得られることがあります。連絡を取る際は、次のような聞き方が効果的です。

「前任の担当者から引き継ぎが受けられておらず、現在システムの構成を一から調査しています。御社で保管している設計資料や、当時のやり取りの記録があれば共有いただけますでしょうか」

保守契約の内容によっては、こうした情報提供が契約の範囲内で対応してもらえる場合もあれば、追加の作業として費用が発生する場合もあります。契約書に記載された対応範囲を確認したうえで問い合わせるとスムーズです。保守契約の内容が不明瞭な場合は、その事実自体も記録しておいてください。

権限・アカウントの構造も同時に確認する

システムの機能そのものだけでなく、「誰が何にアクセスできるか」という権限の構造も、この段階で必ず確認しておきたい項目です。仕様書がないシステムほど、権限設定も属人的に積み上げられていることが多く、誰がどこまでの権限を持っているか、担当者自身も把握していないケースが珍しくありません。

確認すべき項目です。

• 管理者権限を持っているアカウントは何個あり、誰が使っているか
• 退職済みの社員のアカウントが残っていないか
• 複数のシステムで共通のログインを使う仕組み(シングルサインオン（SSO）)が組まれていないか
• 外部の開発会社に付与されている権限の範囲

権限の調査で見つかった問題は、その場で修正したくなる衝動に駆られるかもしれませんが、いったん記録にとどめておくことをおすすめします。権限を急に絞ると、実は必要な業務でその権限を使っていた、という事態を招きかねません。まずは現状を正確に把握し、対応は全体像が見えてから計画的に進めてください。

段階6 分かったことを記録する。仮説と事実を明確に区別する

ここまでの調査で得られた情報は、必ず記録として残してください。口頭やその場限りの理解にとどめてしまうと、せっかくの調査が次の担当者(あるいは将来の自分自身)に引き継がれず、また同じ苦労が繰り返されることになります。

記録する際に最も重要なのが、「確認できた事実」と「まだ確認できていない推測」を明確に区別することです。仕様書のないシステムの調査では、断片的な情報から仮説を立てて動くことがどうしても避けられません。しかし、その仮説を事実であるかのように記録してしまうと、後から見た人が誤った前提で判断してしまう危険があります。

記録の型として、次のような区分を使うことをおすすめします。

• 確認済み: 実際に画面操作・ログ確認などで裏付けが取れたこと
• 推測(根拠あり): 直接確認はできていないが、状況証拠から高い確度で言えること
• 未調査: まだ手をつけられていない、今後の調査項目

この区分をつけて記録しておくと、後で自分自身が読み返したときにも、どこまでが確かな情報でどこからが仮の理解なのかが一目で分かります。また、外部の専門家に相談する際にも、「ここまでは分かっている、ここから先が分からない」を正確に伝えられるため、無駄なく的確なアドバイスを受けやすくなります。

記録した内容は、システム管理台帳のような一覧形式にまとめておくと、後から見返しやすくなります。すでに社内システム管理台帳を作り始めている場合は、そちらに統合する形で追記していくとよいでしょう。

調査中によくあるつまずきとその対処

ここまで理想的な手順を説明してきましたが、実際の調査では想定通りに進まないことも多くあります。よくあるつまずきのパターンと、その対処法を整理しておきます。

つまずき1: パスワードが分からず、そもそもログインできない

管理者アカウントのパスワードが分からず、調査そのものが始められないケースです。まずは前述の通り、経理の支払い明細や過去のメールから手がかりを探します。それでも見つからない場合、多くのシステムには管理者向けのパスワードリセット手順が用意されているため、開発会社やサービス提供元に「管理者のため本人確認のうえパスワードリセットをしたい」と問い合わせるのが現実的な手段です。

つまずき2: 触ってよいのか分からず、調査自体が止まってしまう

「これを開いたら壊れるのではないか」という恐怖から、調査そのものが進まなくなるケースです。基本的に、参照・閲覧だけの操作(画面を開く、設定内容を見るだけ)であれば、多くの場合は安全です。危険なのは値の変更・削除・実行系の操作です。この線引きを意識しながら、まずは見るだけの範囲を最大限に広げることを優先してください。

つまずき3: 分かったつもりが、実は勘違いだった

限られた手がかりから仮説を立てて動いていると、後になって前提が間違っていたと判明することがあります。これ自体は珍しいことではなく、仕様書のない調査では避けられないリスクです。だからこそ前述の「確認済み/推測/未調査」の区分が重要になります。推測で止めておいた項目であれば、後で修正しても大きな実害にはつながりません。

つまずき4: 調査に時間がかかりすぎて、他の業務が回らなくなる

完璧な調査を目指すあまり、通常業務を圧迫してしまうケースです。優先順位をつけることが解決策になります。業務が止まると影響が大きいシステムから優先的に調査し、影響が小さいものは「未調査」のまま一覧に記録するだけにとどめて後回しにする、というメリハリが必要です。

契約不適合と保守範囲の問題にも触れておく

仕様書が存在しないという状況は、時に「開発会社が本来納品すべきものを納品していなかったのではないか」という疑問につながることがあります。この点について、法的な位置づけを簡単に整理しておきます。

システム開発の契約において、仕様書や設計書の納品が契約上の成果物として明記されていた場合、それが提供されていなければ契約不適合責任の問題として扱われる可能性があります。一方で、契約書に仕様書の納品が明記されていない場合や、そもそも口頭ベースで進められた古い契約の場合は、法的に請求できる範囲が限定的になることもあります。

この論点は個別の契約内容によって判断が大きく変わるため、この記事の範囲で一般論として断定することは避けます。もし当時の契約書が見つかり、かつ現在もその開発会社と関係が続いている(あるいは連絡が取れる)のであれば、契約書の記載内容を確認したうえで、仕様書の提供を改めて依頼できないか相談してみる価値はあります。すでに契約が終了し、当時の担当者とも連絡が取れない場合は、この記事で解説してきた「動いているものからの逆算調査」が現実的な対応になります。

調査が一段落したら。次にやるべきこと

ここまでの手順を経て、システムの全体像がおおむね見えてきたら、次のステップに進みます。焦って一気に全部を終わらせようとせず、優先順位をつけて着実に進めることをおすすめします。

• 未調査の項目を優先順位順に一つずつ潰していく(業務影響の大きいものから)
• 老朽化(レガシー化)が進んでいる部分について、延命するか作り直すかの方針を検討する
• 見つかった単一障害点について、冗長化や代替手段の必要性を検討する
• 今回作成した記録を、正式な社内システム管理台帳として整備し直す
• 保守契約が不在・不明瞭だった部分について、今後の体制を検討する

これらは、今回の調査で分かった事実をもとに、腰を据えて取り組むべき中長期の課題です。調査そのもので燃え尽きてしまわず、分かったことを次のアクションにつなげる意識を持ってください。

一人で抱え込まないための考え方

最後に、心構えの話を加えておきます。仕様書のないシステムに直面すること自体は、あなたの落ち度ではありません。前任者、あるいはさらにその前の担当者、あるいは当時発注を受けた開発会社が、本来残しておくべき記録を残していなかった結果として、今のあなたがその尻拭いをしている構図です。

だからといって、すべてを一人で解決しなければならないわけでもありません。次のような外部の力を借りる選択肢を、常に頭の片隅に置いておいてください。

• 保守契約のある開発会社に、通常の保守範囲を超えた「現状調査」を別途依頼できないか相談する
• 社内に詳しい人がいなくても、IT専門の相談窓口(商工会議所や自治体の窓口)を一次相談として活用する
• 複数の開発会社にセカンドオピニオンとして現状を見てもらい、判断材料を増やす

外部に相談する際、この記事で解説してきた「確認済み/推測/未調査」の記録が大きな武器になります。「何がどこまで分かっていて、何が分かっていないか」を言語化できているだけで、相談を受けた側も的確な提案をしやすくなります。逆に「全部分かりません、丸ごと見てください」という相談では、相手も見積もりの立てようがなく、結果的に割高な提案になりがちです。この記事の手順を一通り踏んでおくこと自体が、次の一手を有利に進めるための準備になります。

次に読んでほしい記事について

この記事では、仕様書が一切ない状態から社内システムを調査する手順を、外側から中身へ、そして外部連携へと順を追って解説しました。関連するテーマとして、次の記事もあわせて参考にしてください。

• 前任者の退職・異動直後、まず何をすべきかをまとめた記事(止血・可視化・応急体制づくりの最初の1週間)
• 属人化を防ぐための社内システム管理台帳の作り方(今回の調査結果を、平時の仕組みとして定着させるための記事)

今回の調査で分かったことを記録として残しておけば、それは単に自分自身の安心材料になるだけでなく、次に同じ立場に立つ誰かへの、今度こそきちんとした引き継ぎ資料になります。仕様書がないところからのスタートだったとしても、あなたの代でその状態を終わらせることはできます。