- 仕様書がないシステムの引き継ぎが可能な理由
- ソースコード解析による仕様把握の具体的手順
- 引き継ぎ時に最低限作るべき5つのドキュメント
- 「ドキュメントがない」を二度と繰り返さない仕組み
仕様書がないシステムは珍しくない
「仕様書がない」「設計書が残っていない」——システムの保守引き継ぎで最も多い相談がこのケースです。実は、中小企業のシステムで仕様書が完全に整備されているほうが少数派です。
開発当時は口頭でのやり取りで進め、納品後にドキュメントを整備しなかった。担当者の退職時に引き継ぎ資料を作らなかった。開発会社が倒産してソースコードしか手元にない。理由はさまざまですが、「ドキュメントがないから保守できない」と諦める必要はありません。
システム保守引き継ぎの完全ガイドでも解説していますが、ソースコードさえあれば、専門のエンジニアがコードを読み解いてシステムの仕様を把握できます。
ソースコード解析で仕様を把握する5つのステップ
仕様書がないシステムの引き継ぎでは、ソースコードそのものが「生きたドキュメント」です。以下の手順で体系的に解析します。
ステップ1：技術スタックの特定
まず使用されているプログラミング言語、フレームワーク、データベース、外部サービスを特定します。package.json、composer.json、Gemfileなどの依存関係ファイルから全体像を把握。PHPのバージョンやフレームワークのバージョンも確認し、バージョン管理の状況を評価します。
ステップ2：データベース構造の解析
マイグレーションファイルやスキーマ定義からER図を作成します。テーブル間のリレーション、インデックスの状況、データの整合性を確認。これがシステムの「骨格」にあたります。
ステップ3：画面遷移とAPIの洗い出し
ルーティング定義（routes.phpやweb.phpなど）から、全画面・全APIエンドポイントを一覧化します。各URLに対応するコントローラーとビューを紐付け、画面遷移図を作成します。
ステップ4：ビジネスロジックの把握
コントローラーやサービスクラスを読み解き、主要な業務ロジック（料金計算、権限管理、外部API連携など）を特定します。条件分岐が複雑な箇所は特に注意深く解析し、テストコードがあればそれも参照します。
ステップ5：インフラ構成の確認
サーバー構成、デプロイ手順、環境変数、外部連携先を確認します。.envファイルやCI/CD設定、Dockerfileなどから運用環境の全体像を把握します。
引き継ぎ時に最低限作るべき5つのドキュメント
すべてを完璧にドキュメント化する必要はありません。以下の5つがあれば、別のエンジニアが翌日から対応できるレベルになります。
| ドキュメント | 内容 | 作成目安 |
|---|---|---|
| システム構成図 | サーバー、DB、外部連携の全体像 | 1〜2時間 |
| ER図 | データベースのテーブル関係 | 2〜4時間 |
| 画面一覧・API一覧 | 全URL、対応する機能の概要 | 2〜3時間 |
| デプロイ手順書 | 本番環境へのリリース方法 | 1〜2時間 |
| 障害対応マニュアル | よくあるトラブルと対処法 | 2〜3時間 |
合計10〜14時間程度の作業で、「誰も触れないシステム」から「別のエンジニアが対応できるシステム」に変わります。担当者退職時の引き継ぎでも、この最低限ドキュメントの重要性を解説しています。
リバースエンジニアリングで見つかる「隠れたリスク」
仕様書がないシステムの解析では、仕様の把握だけでなく、隠れたリスクの発見にも繋がります。
セキュリティリスク
SQLインジェクション対策の不備、ハードコードされたパスワード、期限切れの暗号化方式など。セキュリティアップデート放置のリスクで解説しているように、これらは即座に対応が必要なケースもあります。
技術的負債
コピーペーストされたコード、未使用の機能、パフォーマンスのボトルネックなど。放置するとシステム全体の品質が劣化していきます。
依存関係のリスク
サポートが終了したライブラリ、古いPHPバージョン、非推奨になったAPIの使用など。これらは計画的にアップデートする必要があります。
ドキュメント不備に加えてテスト環境も無い場合は、修正の検証自体ができないため対応の難易度がさらに上がります。テスト環境がないシステムを引き継いだ実例では、環境整備だけで半年を要したケースを紹介しています。
「ドキュメントがない」を二度と繰り返さないために
引き継ぎ完了後は、ドキュメントが再び陳腐化しないための仕組みが重要です。
- コードレビュー必須化：すべての変更をGitHub/GitLab上でレビュー。変更履歴がそのままドキュメントになる
- 月次レポート：保守作業の内容を毎月レポートで報告。対応履歴が自動的に蓄積される
- 2名体制での対応：メイン担当＋サブ担当の体制で、知識が1人に集中しない
- 四半期ナレッジ棚卸し：3ヶ月に1回、ドキュメントの完全性をチェックし更新漏れを是正
そもそも保守に最低限どんな資料が必要かは「システム保守に必要なドキュメント一覧と整備方法」で、11種類の資料と整備の優先順位を解説しています。
また、ドキュメント不足を理由に、そもそも委託先（開発会社）を変更するケースもあります。委託先を切り替える際に発注者側が準備すべき書類や、円滑な移行の進め方は「システム保守の委託先を変える時の引き継ぎ手順」で解説しています。
FUNBREWでは、保守契約のすべてのプランでこの仕組みを標準提供しています。詳しくは保守サービスページをご覧ください。
まとめ
仕様書がないシステムの保守引き継ぎは、決して不可能ではありません。ソースコード解析の5ステップで仕様を把握し、最低限の5つのドキュメントを整備すれば、保守可能な状態に持っていけます。
重要なのは、引き継ぎ後に「同じ問題を繰り返さない仕組み」を作ること。コードレビュー、月次レポート、2名体制、ナレッジ棚卸しの4つの仕組みで、ドキュメントの陳腐化を防ぎます。
「仕様書がない」「誰もシステムを理解していない」という状況でお困りの方は、システム引き継ぎサービスや無料相談をご活用ください。
相談の前に社内で何を探しておくと調査が早く進むかは、システム引き継ぎで用意する資料は何かにまとめています。古い資料でも出していただく意味があります。
引き継ぎ後、調査結果をドキュメントにするところから始める理由は保守を引き継いだ最初の1ヶ月に何をしているかをご覧ください。
この記事をシェア