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