システムのドキュメントがない！仕様書なしのシステムを理解する方法

「前任者が退職したら、システムの仕様書が一切残っていなかった」——こういった状況に直面した情シス担当者やIT部門の方は少なくないだろう。ドキュメントがなければ何も動けない、そう思い込んでいないだろうか。仕様書なしのシステムを理解するための手順と、AIを活用した解析手法を整理する。

なぜシステムのドキュメントがなくなるのか

ドキュメントの欠如は、珍しい問題ではない。IIJ「全国情シス実態調査2024」をはじめとする複数の調査で、情シス部門の課題として「属人化している業務がある」が上位に挙がり続けている。

その背景にある構造的な問題は3つある。

• 人手不足による後回し：システムの運用・保守で手一杯で、ドキュメント整備に時間を割けない
• 口頭文化の定着：「この人に聞けばわかる」という属人的な解決が常態化している
• 改修履歴の未記録：システムに手を加えるたびにドキュメントを更新する習慣がない

経済産業省のDXレポートが警鐘を鳴らした「2025年の崖」問題の本質も、まさにこのブラックボックス化にある。老朽化・複雑化したシステムに関する知識が特定の担当者に依存し、その担当者が退職すれば維持すら困難になる——この構造が日本企業に広く蔓延している。

放置すれば最大12兆円/年の経済損失が生じるとも試算されており（経産省DXレポート）、個別企業レベルでも業務停止リスクに直結する深刻な問題だ。

仕様書なしで直面する具体的な困難

ドキュメントがない状態でシステムの担当者になると、どんな問題が起きるか。

障害対応の遅延が最も深刻だ。障害が発生してもシステムの構造を把握していなければ、原因箇所の特定に時間がかかる。「いつも〇〇さんに聞いていたのに、もうその人がいない」という状況は、現場の混乱を招く。

改修・機能追加の停止も引き起こされる。どこを触ったら他の機能に影響するかわからない以上、変更を加えることに強い恐れを感じるのは当然だ。結果として「塩漬け」状態になり、ビジネスの変化に対応できなくなる。

ベンダー依存の深化も問題だ。内製できず、外部ベンダーに全依存する構造になると、コスト・スピードの両面で競争力を失う。

仕様書なしのシステムを理解するための5ステップ

ドキュメントが存在しない状態から着手するための実践的な手順を示す。

ステップ1：現状の把握から始める

まず、何がわかっていて何がわからないかを整理する。以下を確認する。

ここで重要なのは、ヒアリング対象を「システムを使っている人」に広げることだ。開発者でなくても、業務ユーザーはシステムの機能や動作パターンを熟知していることが多い。

ステップ2：既存資料の徹底収集

「仕様書がない」と一口に言っても、断片的な情報が残っている可能性は高い。以下を探す。

• 過去のメール・チャット履歴（機能追加の経緯が残っていることがある）
• バグ報告書・障害報告書
• ベンダーからの納品物（テスト仕様書、構成図など）
• 会議の議事録
• コードのコメント・コミット履歴（Gitがあれば特に有効）

断片的であっても、これらを組み合わせることで全体像の輪郭が見えてくる。

ステップ3：ソースコードの静的解析

コードが手元にある場合、静的解析ツールを使って構造を把握する。

モジュール間の依存関係、データフロー、APIのエンドポイント一覧——こういった情報はコードから機械的に抽出できる。2024年時点でAIを活用したリバースエンジニアリングサービスが複数登場しており、東芝デジタルエンジニアリングの事例では20万ステップのコード解析を生産性2倍で実施したと報告されている（日経クロステック, 2024年）。

AI活用により最大70%の工数削減も報告されており、人力でのコード読解と比べて大幅に効率が向上している。

ステップ4：フロー図・構成図の作成

収集した情報をもとに、以下の順でドキュメントを作成する。

1. システム構成図（どのサーバー・DBが何をしているか）
2. 業務フロー図（ユーザーの操作と処理の流れ）
3. データフロー図（データがどこで生成・加工・保存されるか）
4. インターフェース仕様（外部システムとの連携点）

全部を一度に作ろうとせず、「最もリスクが高い部分から優先する」のが実務上の鉄則だ。

ステップ5：ドキュメントの維持・更新ルールを整備する

せっかく作ったドキュメントも、更新されなければすぐに陳腐化する。「コード変更時は必ずドキュメントを更新する」というルールと、それを担保する仕組みが必要だ。

📱 SysDock → 👉 詳細を見る

ブラックボックス化したシステムの解析に課題を感じているなら、SysDockが選択肢になる。AIマルチエージェントがソースコードや設定ファイルを自動解析し、フロー図・構成図を生成する。人手でのコード解読に1か月かかっていた作業を、約1週間に短縮した事例もある。料金は¥15万〜。

AI解析ツールを使ってフロー図を生成する方法

近年、AIを活用したリバースエンジニアリングが急速に実用化されている。SHIFTの「AIドキュメントリバース」では2024年12月時点で31言語に対応し、CRUD図・シーケンス図・フローチャートを自動生成できる。

AIによるコード解析の流れは次の通りだ。

1. ソースコードをツールに読み込ませる
2. AIがコードの依存関係・ロジック・データ構造を解析する
3. フロー図・構成図・テーブル定義などのドキュメントが自動生成される
4. 生成されたドキュメントをエンジニアがレビューし、補足する

全自動で完璧なドキュメントができるわけではないが、「どこから手をつければよいかわからない」という最初の壁を突破するには十分な精度が出ている。

生成AIを使ったリバースエンジニアリングは「エンジニアの知見に左右されない解析」が可能になるため、担当者のスキルレベルに依存しにくい点も現場では評価されている。

ドキュメントがないまま放置するリスク

「今は動いているから問題ない」と考えている組織も多いが、潜在的なリスクは確実に積み上がっている。

障害時の復旧時間が長くなる。構造がわからなければ、どこを修正すれば直るかの判断に時間がかかる。サービス停止が長引けば、顧客への影響や機会損失が発生する。

セキュリティリスクが見えにくくなる。脆弱性のある箇所を特定するためには、システムの構造把握が前提になる。ドキュメントがなければ、セキュリティ監査も困難だ。

システム更新・マイグレーションが進まない。クラウド移行やシステム刷新の検討にあたり、現状のシステムの全体像を把握していることは必須条件だ。ドキュメントがなければ、RFP（提案依頼書）すら作れない。

採用・育成コストが増大する。新しいエンジニアが入っても、システム理解に膨大な時間がかかる。ドキュメントがあれば1週間で概要を把握できる内容を、口頭伝達に頼ると3か月かかるケースも珍しくない。

中小企業・情シス1名体制での現実的なアプローチ

「大企業のような専任チームを組める体制ではない」という声は多い。1人情シス、あるいは兼任情シスという環境では、どう優先順位をつければよいか。

コアシステムから着手するのが原則だ。全てを同時に整備しようとすると何も進まない。「これが止まったら業務が止まる」というシステムを最優先にする。

外部ツール・AIに任せられる部分は任せる。コードの読解、図の描画、ドキュメントのフォーマット作成——これらはAIツールが大幅に省力化してくれる。人が判断すべき部分に集中する。

少しずつ積み上げる。完璧なドキュメントを一気に作ろうとせず、障害対応や改修作業のたびに「ついでに記録する」習慣をつくる。1年後には大きな資産になっている。

まとめ

仕様書がない状態からのシステム理解は、確かに困難だ。しかし、適切な手順と現代のAIツールを組み合わせれば、思った以上に早く全体像を把握できる。

要点を整理する。

• 現状把握→断片資料の収集→静的解析→フロー図作成→維持ルール整備、という順序で進める
• AIリバースエンジニアリングツールを活用すれば、フロー図生成を1週間程度に短縮できる事例がある
• ドキュメントなしを放置すると、障害対応・セキュリティ・人材育成の全てにコストが増大する
• 中小・1人情シス体制でも、優先順位を絞ってAIに任せることで現実的な整備が可能だ

「ドキュメントがないから何もできない」ではなく、「ドキュメントを作るための最初の一手を打つ」ことが、今この瞬間から始められる対策だ。

📱 SysDock → 👉 詳細を見る

姉妹サービスの関連記事

GenbaCompassの姉妹サービスでも、現場改善に役立つ記事を公開している。

• レガシーシステムのリスクと対策
• 技術継承AIツール比較

現場改善に役立つ関連アプリ

GenbaCompassでは、SysDock以外にも現場のDXを支援するアプリを提供している。

参考資料

• 経済産業省「DXレポート」レガシーシステムモダン化委員会総括レポート（2025年5月）
• IIJ「全国情シス実態調査2024」
• 日経クロステック：東芝系がリバースエンジニアリングに生成AIを活用（2024年）
• ソフトクリエイト「情報システムの現状とIT活用実態アンケート2024」