「設計書がないシステムは危険だ」——そう言われると、情シス担当者は不安になる。しかし実態を見ると、設計書がないまま10年以上問題なく動き続けているシステムは珍しくない。一方で、設計書があるにもかかわらず、引継ぎや刷新で大きな混乱が起きるケースも多い。「設計書がある」ことと「システムの実態を把握できている」ことは、必ずしも一致しない。この記事では、「設計書がない」という状況を正確に評価し、実際に何が問題で、何が問題でないかを整理する。「設計書がない」が問題になる場面、ならない場面まず前提として、設計書がないこと自体は問題ではない。問題になるのは、特定の場面に限られる。問題になりやすい場面：担当者が交代するとき。前任者の頭の中にあった知識が引き継がれず、後任者が「何もわからない」状態からスタートするシステムを刷新・改修するとき。現行の仕様が文書化されていないため、要件定義の起点となる情報がない障害が発生したとき。どこに何があるかわからないまま対応することになり、復旧に時間がかかるベンダーを変更するとき。新ベンダーに引き継ぐべき情報が言語化されていない問題になりにくい場面：現在の担当者が継続して運用しているとき。知識が属人化していても、その人がいる間は機能するシステムの改修頻度が低いとき。変更が発生しなければ、仕様を参照する機会も少ない業務とシステムの対応関係が安定しているとき。業務が変わらなければ、ドキュメントの陳腐化も起きにくいつまり「設計書がない」が本当の問題になるのは、変化が起きるときだ。担当者が変わる、システムを触る、業務が変わる——そのタイミングで初めて、設計書のなさが致命的なリスクとして現れる。本当の問題は「設計書がない」ではなく「現状が把握できない」こと設計書がなくても、以下の情報が関係者の間で共有されていれば、実務上の問題は大きくない。どのシステムが何の業務を担っているかどのシステムとどのシステムが連携しているかデータはどこに格納され、どう流れているか定期的に発生する作業と、その手順はどこにあるかベンダーの連絡先と、何をどこまで任せているかこれらが整理されていれば、それは「設計書」という形式でなくても機能する。Excelでも、共有フォルダのメモでも、担当者間の口頭合意でも——形式よりも「把握できている状態か」が本質的な問いだ。逆に言えば、設計書が存在していても、それが古くて実態と乖離していたり、誰も参照していなかったりすれば、設計書がないのと変わらない。設計書なしのシステムとどう付き合うか設計書がないシステムを抱えた情シス担当者がまず取り組むべきことは、「設計書を作ること」ではない。「現状を把握すること」 だ。ステップ1：システムの棚卸しから始める「何があるか」を一覧にする。サーバー・SaaS・ネットワーク機器・契約しているサービスを問わず、まず存在を把握する。完璧である必要はない。「わかっているもの」から始めて、抜け漏れは業務の中で補っていく。ステップ2：業務との対応関係を言語化する「このシステムが止まると、どの業務が止まるか」を整理する。これが明確になると、優先度の判断ができる。すべてのシステムを同じ粒度で管理する必要はなく、業務影響が大きいものから重点的に把握する。ステップ3：属人化している知識を引き出す設計書がないシステムで最も失われやすいのは、担当者の頭の中にある「暗黙の知識」だ。なぜこの設定になっているのか、この処理はどういう経緯で追加されたのか——こうした背景情報は、担当者がいる間にしか取り出せない。担当者が在職中に、ヒアリングを通じてこれらを言語化しておくことが、実質的な「設計書の代替」になる。AI仕様解析という選択肢設計書がないシステムの現状把握には、これまで多くの時間と工数がかかっていた。ソースコードやログを読み解き、動作から仕様を推定するという作業は、高い技術力と長い時間を要する。しかし近年、AIを活用してソースコードや設定ファイルから仕様を解析するアプローチが現実的な選択肢になってきている。設計書がないシステムに対して、ゼロから文書を起こすのではなく、AIが実装から仕様を読み取り、構造化するというやり方だ。「設計書がないから現行調査ができない」ではなく、「設計書がないからこそ、AIを使った解析から始める」という発想の転換が、刷新・引継ぎの起点を変える。あわせて読みたい：現行調査で何がわかるのか——調査結果として「手に入る情報」を具体的に解説する——設計書なしの状態から始める現行調査の進め方システム保守の引継ぎ資料はなぜ機能しないのか——使える引継ぎ資料に必要な5つの要素「情シス担当がひとりだけの会社」で起きること——属人化が問題になるタイミングと備え方設計書がないシステムの現状把握を、どこから始めればよいかわからない場合は、現行調査サービスからご相談ください。