「仕様書がないのですが、それでも移行できますか」。AIマイグレーションのご相談で、最も多くいただく質問の一つです。長年使ってきたシステムほど、改修のたびにプログラムだけが変わって設計書の更新は後回しになり、気がつけば仕様を知る人も社内にいない、という状態になっています。
結論から言えば、仕様書がなくても移行できます。ただし「まず仕様書を復元してから移行する」という順番にはしません。この記事では、仕様書の代わりにAIが何を読むのか、AIに復元できるものとできないものは何か、そして復元できない部分を誰がどう決めるのかを、当社の進め方に沿って解説します。
仕様書がないのは珍しいことではない
10年以上稼働しているシステムでは、構築時の設計書は残っていても、その後の改修が反映されておらず、現物のコードとは別物になっていることがよくあります。そこに担当者の退職やベンダーの撤退が重なると、動いてはいるものの中身は誰も説明できない、いわゆるブラックボックスになります。
仕様書がない状態は、従来の移行では最初の難所でした。人がコードを読み解いて仕様を起こす現行調査に時間がかかり、調査は最初の工程であるため、その遅れがそのまま全体の遅れになるからです。工程ごとの内訳はシステムマイグレーションの期間で解説しています。だからこそ多くのベンダーは、移行の前にリバースエンジニアリングで設計書を作り直す工程を提案します。
「先に仕様書を完成させる」順番にしない理由
ただ、この順番には落とし穴があります。設計書を復元する作業そのものに数か月かかるうえ、復元した設計書も完全にはなりません。コードに書かれていない業務上の意図は、コードをいくら読んでも出てこないからです。時間をかけて作った設計書をもとに移行を進め、テストの段階で「設計書にない挙動」が次々に見つかる、というのが典型的な失敗パターンです。
AIマイグレーションでは順番を変えます。仕様書を完成させてから移行するのではなく、AIがコードから読み取った暫定的な仕様をもとに変換とテストを進め、その過程で見つかった不明点を確認して仕様を確定していきます。移行前と移行後で同じ動作をすることは、新旧の動作を突き合わせる比較テストで担保します。仕様書はこのプロセスの成果物として、最新のコードに対応した状態で出てきます。
仕様書の代わりにAIが読む4つの情報源
では、仕様書がない状態でAIは何を手がかりにするのか。当社では主に4つの情報源を組み合わせます。
ソースコード。 最も情報量が多く、処理の流れ、条件分岐、入出力、他の機能との呼び出し関係はすべてここに書かれています。実装と一致しない古い設計書より、コードのほうがよほど正確な仕様です。
データベース構造。 テーブル定義、項目の型や制約、テーブル間の関係からは、システムが何を管理しているかの全体像が読み取れます。コードだけでは見えにくいデータの意味を補う情報源です。
画面と帳票。 実際に動いている画面や出力される帳票は、利用者から見た仕様そのものです。項目の並びや必須チェック、帳票のレイアウトなど、コードから起こすと抜けやすい部分を実物で確認します。
ログと利用実績。 アクセスログや処理履歴からは、どの機能が実際に使われているかがわかります。長年の改修で残った機能の中には、もう誰も使っていないものが含まれています。使われていない機能を移行対象から外す判断材料になります。
AIはこれらを突き合わせて、機能一覧、画面・帳票ごとの仕様、データ項目の定義、処理フロー、外部システムとの依存関係を暫定仕様書として書き起こします。従来のリバースエンジニアリングツールが出力するのは、呼び出し関係やCRUD図のような構造情報でした。生成AIはそれに加えて「この処理は受注金額から得意先ごとの割引率を差し引いている」といった処理の意味まで文章で説明できます。人手の調査と大きく違うのはここです。
AIが復元できるもの、できないもの
ただし、AIに復元できるのは「コードに書かれていること」までです。ここを正しく理解しておくことが、仕様書がないシステムの移行では最も重要です。
コードに書かれているのは、何をしているかです。この条件のときにこの処理をする、この項目をこのテーブルに書く、という動作はすべて復元できます。一方、コードに書かれていないのは、なぜそうなっているかです。
たとえば、納品日が受注日より前でも登録できてしまうシステムがあったとします。これは入力チェックの漏れ、つまり不具合なのか。それとも、先に納品して後から受注を起票する業務が実際にあり、意図してそうしているのか。コードを見ただけでは判断できません。同じように、特定の区分値だけを一覧から除外している処理が今も必要なのか、画面の表示と帳票で端数処理が違うのはどちらが正しいのか。こうした「事実上の仕様になっている挙動」は、どのシステムにも必ずあります。
よくあるご質問でもお答えしているとおり、当社ではAIがこうした箇所を自動的に「正しそうな形」へ直すことはしません。勝手に直すと、業務で必要だった挙動が消えて本番切替後に問題になるからです。AIの役割は、判断が必要な箇所を見つけて確認事項として抽出するところまでです。
不具合か仕様かを、誰がどう決めるか
抽出した確認事項は一覧にして、お客様に判断をお願いします。選択肢は3つです。現行の挙動をそのまま再現する、正式な仕様として整理して残す、移行を機に修正する。次の図は、この確認事項一覧のイメージです。
※実案件のものではなく、当社で作成したサンプル資料です。
ここで大切なのは、依頼側に「業務上の正解を判断できる人」がいることです。仕様書は不要ですが、この判断だけはお客様にしかできません。開発の経験は必要なく、その業務を実際に回している担当者の方で十分です。逆に言えば、この判断ができる体制があるかどうかが、仕様書の有無よりも移行の成否を左右します。
確認は最初にまとめて行うのではなく、変換とテストを進めながら見つかった順に行います。不明点の多くは新旧の比較テストの差異として浮かび上がるため、机上で仕様書を読み合わせるより、実際の動作をもとに具体的に確認できます。判断の記録は移行後の仕様書に反映し、「なぜこの仕様なのか」が残る形にします。
当社の事例: 設計書が十分に残っていない約25万行の基幹システム
当社が手がけたFuelPHPからLaravelへの基幹システム移行は、まさに設計書が十分に残っていない状態からのスタートでした。約25万行のコードをAIが解析して仕様を把握し、従来手法の見積もりと比較して金額・工期とも約60%の削減で移行を完了しています。仕様の把握に人手をかけずに済んだことが、削減幅の大きな部分を占めています。プロジェクトの背景と進め方はFuelPHPからLaravelへの移行事例で紹介しています。
移行が終わると、最新の仕様書が残る
仕様書がない状態で始めた移行の終わりには、変換後のコードに対応した仕様書・設計書、テストケース、そして確認事項に対する判断の記録が揃います。当社ではこれらを納品物に含め、自社での内製保守、既存の保守ベンダーへの引き継ぎ、当社での継続保守のいずれにも対応できる状態にしています。
仕様書がないことは、移行できない理由ではなく、移行によって解消される問題の一つです。
移行はせず、既存システムの仕様書化だけを依頼できるか
移行の予定はまだ決めていないが、ブラックボックスのまま保守を続けるのは不安なので、まず現状の仕様を文書として持っておきたい。保守ベンダーの切り替えや監査への対応で、既存システムの仕様書が必要になった。移行するかどうかを判断する材料として、中身を把握したい。こうしたご相談には、解析と仕様書化を単体でお受けしています。
進め方は移行のときと同じです。ソースコード・データベース構造・画面と帳票・ログから、機能一覧、画面・帳票ごとの仕様、データ項目の定義、処理フロー、外部システムとの依存関係を起こし、業務上の意図が読み取れない箇所は確認事項として一覧にします。違いは、新旧の比較テストがないことです。移行では復元した仕様の正しさを新旧の動作比較で裏づけますが、仕様書化だけの場合は、現行システムの動作確認と業務担当者への確認で裏づけることになります。
仕様書化の成果物はそのまま移行の土台になるため、先に仕様書化だけを行い、移行は後から判断するという進め方もできます。AIで仕様書を作る具体的な手順と、できること・できないことはソースコードからAIで仕様書を作る方法で解説しています。
仕様書がないシステムの解析・仕様書化にかかる費用
解析と仕様書化の費用は、対象の規模と、求める仕様書の粒度で決まります。規模はソースコードの行数や、画面・帳票・バッチ処理の数です。粒度は、機能一覧と処理の概要までで足りるのか、画面・帳票ごとの項目定義や処理フロー、データ項目の定義まで起こすのかで、同じシステムでも工数は大きく変わります。移行の判断材料がほしいのか、保守の引き継ぎに使うのか、監査に出すのか。目的から粒度を決めるのが先です。
当社では、規模と目的により数十万円から数百万円の範囲でお受けしています。移行を前提にご相談いただく場合は、無料診断の段階でソースコードの一部から規模と構成を解析し、仕様書化を含めた移行全体の概算をご提示します。仕様書化だけをご希望の場合も、同じ解析で規模を測ったうえでお見積りします。見積の内訳と根拠の読み方はマイグレーションの見積方法で解説しています。
まとめ: 仕様書の準備は不要、判断できる人は必要
仕様書がなくてもAIマイグレーションは進められます。AIがソースコード・データベース・画面・ログから仕様を復元し、コードに書かれていない業務上の意図は、確認事項としてお客様に判断いただく。この分担が、仕様書のないシステムを移行する現実的な方法です。
自社のシステムがこの方法で移行できる状態かどうかは、実際のコードを見れば判断できます。DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえシステム概要とソースコードの一部をお預かりし、現状リスクと移行可能性をまとめた診断レポートと概算費用を無料でご提示しています。仕様書・設計書のご準備は不要です。
よくある質問
Q. 仕様を知る担当者がすでに退職しています。それでも進められますか？
進められます。仕様の大半はコードから復元できます。ただし、不具合か仕様かの判断は必要になるため、現在その業務を回している方に確認へ加わっていただきます。開発の知識は不要です。
Q. AIがあまり知らない古い言語で書かれていても、仕様は復元できますか？
言語の知識量よりも、実行環境を再現できるか、新旧の動作比較ができるかが難易度を左右します。難易度が高いと見込まれる場合は、まず仕様書化と依存関係の整理を行い、そのうえで移行可否を診断します。
Q. Accessのように、画面の設定にロジックが埋まっている場合はどうなりますか？
コードとして取り出せる部分は解析できますが、画面上にしかないロジックや独自部品は個別に確認が必要です。実際の動作を確認しながら、人が代替方式を決めます。
Q. 移行後の仕様書は、自社や既存の保守会社で引き継げる状態になりますか？
変換後のコード、仕様書・設計書、テストケース、移行時の判断記録を整備して納品します。移行後の保守は、自社での内製、既存の保守ベンダー、当社への委託からお選びいただけます。費用の考え方はシステムマイグレーションの費用相場もあわせてご覧ください。