レガシーコードから設計書を自動生成する

レガシーシステムのモダナイズ案件では、現行仕様書が不足していたり、実装と設計書の内容が一致していなかったりすることがあります。古いJavaやCOBOLで書かれたソースコードを読み解き、影響範囲を調べ、設計書にまとめる作業は、提案や開発の初期段階で大きな負担になりがちです。

開発AIエージェント Jiteraを活用する場合、既存ソースコードやDBスキーマなど、利用を許可された情報をコンテキストとして整理し、現行システムの理解に必要な設計書、図、テスト観点の草案作成を支援できます。実際に参照できる情報や生成可能な成果物は、製品の機能、環境設定、契約条件、対象データによって異なります。本記事では、仕様書が十分に残っていないモダナイズ案件で、解析からチーム共有までを進める際の一般的な方法を解説します。

生成物は現行仕様を理解するための草案です。AIがコードから確認できない業務ルールや運用上の制約を正しく補えるとは限りません。実際の改修、移行、テスト、リリースに利用する際は、開発担当者・運用担当者・業務担当者・品質保証担当者によるレビュー、テスト、承認を行ってください。

仕様書が不足したレガシー案件の典型的な問題

古いJava・COBOLのコード読解に工数が消える

レガシー案件では、ソースコードが現行仕様を知るための主要な資料になっていることがあります。特に次のような状態では調査工数が膨らみます。

• 古いJavaやCOBOLのプログラムが大量に残っている
• 共通部品や外部プログラムの呼び出しが複数階層に分かれている
• 変数名やテーブル名から業務上の意味を判断しにくい
• 改修の積み重ねにより、同じ業務処理が複数の場所に分散している
• コメントが少なく、例外処理や暫定対応の背景が記録されていない

影響調査・設計書作成でスケジュールが崩れる

モダナイズ案件では、既存機能を新しい構成へ移す前に、現行システムの動作を整理する必要があります。仕様書が不足していると、関連プログラムの調査、呼び出し関係の確認、DB参照・更新箇所の調査、設計書への書き起こしが連続して発生します。影響範囲の見落としは、後工程での追加改修やテスト範囲の拡大につながる可能性があります。

属人化したコード知識が引き継げない

長年保守してきた担当者が、設計書に書かれていない情報を持っていることがあります。こうした知識が個人の記憶や手元のメモにとどまると、異動や退職の際に引き継ぎが難しくなります。

まず整理すべき対象

Jiteraでソースコードを解析し、設計書の草案を作る手順

Step 1：既存資産と生成する成果物を決める

ソースコードだけでは処理の目的や運用上の制約が分からないため、利用を許可された関連資料も合わせて整理します。生成する成果物も先に決めます。「現行仕様の把握」と「移行先の設計」では、必要な出力項目やレビュー基準が異なるためです。

Step 2：ソースコードとDBスキーマをコンテキストとして整理する

登録する情報には、対象バージョン、更新日、管理担当、利用目的、アクセス権限を付けます。顧客情報、認証情報、秘密情報、個人情報などは、社内規程と契約条件に従い、登録可否とマスキング方法を確認してください。

Step 3：プログラム概要と依存関係を整理する

各プログラムについて、目的、起動条件、入出力、呼び出し元・先、参照・更新テーブル、条件分岐、エラー処理を整理します。コード上で確認できない内容や、コメントだけでは裏付けられない内容は無理に補わず、「要確認」として出力させます。AIの解析結果だけで依存関係の完全性を保証できるとは限らないため、担当者が原コードや実行環境と照合します。

Step 4：基本設計書を生成する

生成する設計書には、確認できた情報と推定・未確認の情報を分けて記載させます。コードに根拠がない業務ルールをAIが推測して補うことを防ぐためです。

基本設計書の構成例：

• 機能概要・対象業務と利用者
• システム構成上の位置づけ
• 入力条件・処理の流れ
• 業務ルールと条件分岐
• データの参照・更新・外部システムとの連携
• エラー処理とリカバリ
• 未確認事項と追加ヒアリング項目

Step 5：画面遷移図とデータフロー図を生成する

生成指示の例

架空の「青葉契約管理システム」について、登録済みのソースコード、DB定義、画面項目定義だけを参照してください。

契約更新機能を対象に、次の成果物の草案を作成してください。
1. 基本設計書
2. 画面遷移図
3. データフロー図
4. コードから確認できない事項の一覧

基本設計書には、入力、処理、条件分岐、更新テーブル、外部連携、エラー処理を含めてください。
根拠が確認できない内容は推測で補わず、「要確認」と記載してください。
各記載について、参照したファイル名・定義・コード箇所を可能な範囲で示してください。

図や設計書の見た目が整っていても、内容の正確性を意味するとは限りません。図のノード、矢印、テーブル名、処理順序を原コード、定義書、実行ログ、担当者の知識と照合してください。

Step 6：単体テスト観点を整理する

テスト観点はテストケースの完成品ではありません。業務担当者が期待結果を確認し、テスト環境で実行して、必要な異常系・性能・セキュリティ・移行リハーサルの観点を追加します。

Step 7：影響調査の結果を設計レビューにつなげる

移行対象のプログラムやDB項目を変更した際に、どこへ影響するかを整理します。結果には、コードから確認できる直接的な依存関係と、業務担当者による確認が必要な関係を分けて記載します。移行、改修、リリースの判断は、影響調査の草案だけで確定しないでください。

チームの共有ナレッジ基盤として活用する

汎用AIコーディングツールだけではプロジェクト固有の知識が共有されにくい

汎用AIコーディングツールは、個人の実装やコード補完を支援する場面で役立ちます。一方で、顧客ごとの業務ルール、長年の改修経緯、過去障害、運用上の注意点などが、チーム全体へ自動的に共有されるとは限りません。

Jiteraのコンテキスト基盤でチーム共有を進める

Jiteraでは、利用を許可されたプロジェクト固有のソースコード、設計書、DB定義、規約、業務知識をコンテキストとして整理し、チームで参照できる状態を作る考え方を取ります。これにより、新任担当者のコード理解、既存機能の影響調査、設計書の初稿作成、レビュー指摘の再発防止を、同じプロジェクト情報をもとに進めやすくなります。ただし、登録範囲、参照権限、保持期間、利用できる機能は環境・契約・社内ルールに依存します。

コーディング規約・ドメイン知識の共有方法

登録情報を更新したときは、変更理由、レビュー者、適用範囲を記録します。古い設計書や廃止済みのルールを現行情報として参照しないよう、版管理と利用停止の手順も定めます。

導入事例・効果データを掲載するときの注意

個別案件の対象範囲、測定方法、レビュー条件、公開許諾の有無を確認せずに、一般的な効果やJiteraの保証値として掲載することはできません。公開記事に数値を掲載する場合は、顧客名の掲載可否、事例の公開範囲、測定期間、比較条件、算定方法、最新性を確認し、確認できない項目は記載しないでください。

PwCコンサルティング合同会社については、Jiteraの活用により、コーディング工数を平均約3割削減した公開事例があります（出典：PwCコンサルティング合同会社 導入事例）。これは当該事例における参考値であり、すべての案件で同じ効果が得られることを示すものではありません。公開ページの内容、掲載許諾、数値の表記を公開前に確認してください。

効果を測定する場合は、対象業務、対象期間、利用者、入力資料、成果物の品質、レビュー時間、再作業時間、工数の算定方法をそろえます。削減時間を後工程へ単純に詰め込むのではなく、設計レビュー、異常系テスト、ドキュメント整備、知識共有などへ再配分できたかも確認します。

まとめ

仕様書が不足したレガシー案件では、次の順序で進めると、解析とチーム共有をつなげやすくなります。

1. 対象業務、ソースコード、DBスキーマ、成果物の範囲を決める
2. 利用を許可された既存資産をコンテキストとして整理する
3. プログラム概要と依存関係を確認する
4. 基本設計書、画面遷移図、データフロー図を草案として生成する
5. 単体テスト観点と影響範囲を整理する
6. 開発・運用・業務・品質保証担当者がレビューする
7. 確定した知識やレビュー結果をチーム共有ナレッジとして蓄積する
8. 小さな対象で検証し、効果と課題を確認して適用範囲を広げる
9. 事例や効果データは、公開許諾と測定条件を確認してから掲載する