1. 保守開発の基本フロー
保守開発では、既存コードへの影響を正確に把握することが最優先です。
初回調査（広く浅く）
変更対象のヒントを与え、影響する可能性のある経路を粗く整理します。この段階では網羅性を優先し、深掘りはしません。
詳細化調査（狭く深く）
初回調査の結果を元に、機能名・使われ方・業務ルールの情報を加えて粒度を上げます。
設計整理
影響範囲の結果を詳細設計レベルに整理します。修正が成立するために一式揃えるべき対象を経路全体で明確にします。
修正チェックリスト作成
設計整理の結果を元に、修正対象を行単位で管理できるチェックリストを作成します。
実装（Agent主導 + 人が承認）
チェックリストを起点にAgentが実装を主担当します。人は変更方針の承認と最終判断を担い、Agentは実装・レビュー補助・テスト生成まで一貫して担当します。
テスト設計・実行
調査結果と設計情報からテスト観点を起こし、テストを実装・実行します。NGは収束するまで繰り返します。
横断確認
セッションを変えて設計・実装・テストの整合を横断的に確認します。
2. 影響範囲調査
2.1 初回調査（広く浅く）
変更対象の「流れ」を把握することを目的とします。存在箇所の列挙ではなく、値がどこから入りどこで使われるかを追います。
| 調査観点 | 確認内容 |
|---|---|
| 入口 | 画面入力・外部連携・ファイル取込・バッチ処理など、値がどこから入ってくるか |
| 中間処理 | 保持・変換・計算・判定・条件分岐など、値がどこで変わるか |
| 出口 | DB保存・画面表示・外部連携・帳票出力・CSV出力など、値がどこで使われるか |
| 類似処理 | 同じ意味の処理が他の経路にないか（対称性の確認） |
「今は初回調査フェーズです。〇〇の変更に伴い影響する可能性のある処理経路を広く浅く整理してください。 深掘りはせず、まず全体像を把握することを優先してください。不明点は推測で埋めず確認を求めてください。」
2.2 詳細化調査（狭く深く）
初回調査で特定した経路に対して、機能名・使われ方・業務ルールの情報を加えて粒度を上げます。
- 各処理の具体的なクラス名・メソッド名・ファイルパスを特定する
- 業務ルール（条件分岐・計算式・上限値など）を明確にする
- 類似ロジックとの対称性を確認する
- 依存関係（呼び出し元・呼び出し先）を整理する
- DBのカラム変更が必要かを確認する
3. 設計整理
影響範囲の結果を、後工程がそのまま使える粒度へ整理します。単なる列挙ではなく、判断と作業につながる形に落とし込みます。
| 観点 | 考え方 |
|---|---|
| 一式整合 | 部分修正ではなく、経路全体で整合を取る。入口を修正したら出口も確認する |
| 漏れ防止 | 漏れやすい箇所（SQL・テンプレート・設定ファイルなど）を独立した確認項目にする |
| 計算対称性 | 同じ意味の計算は経路間（画面系・取込系・バッチ系など）で対称性を保つ |
| 後段独立 | 再表示・出力・連携を入口修正と切り分けて確認する |
| 依存順序 | 前提条件が満たされる順で検討を進める（DBが先、Entityが次、など） |
4. 修正チェックリスト
設計整理の結果を元に、修正対象を行単位で管理できるチェックリストを作成します。 工数管理より修正漏れ防止の粒度を優先した構成にします。
| No | 区分 | 対象 | 修正内容 | 実装 | 確認 | レビュー | 備考 |
|---|---|---|---|---|---|---|---|
| DB-01 | DDL | テーブル名 |
新項目列を追加する | 未着手 | 未着手 | 未着手 | 型・桁・NULL可否を決める |
| UI-01 | Entity | モデルクラス |
新項目のプロパティを追加する | 未着手 | 未着手 | 未着手 | |
| UI-02 | 画面 | 画面ファイル |
入力欄を追加する | 未着手 | 未着手 | 未着手 |
5. 実装
チェックリストを起点に実装を進めます。Agentへの指示は1項目ずつ、または関連する小グループ単位で行います。
| 指示のポイント | 内容 |
|---|---|
| チェックリストのNoを指定する | 「チェックリストのDB-01を実装してください」と番号で指定する |
| 既存コードのパターンを示す | 「既存の〇〇と同じパターンで実装してください」と参照先を明示する |
| 変更禁止ファイルを明示する | 「今回は〇〇ファイルは変更しないでください」と制約を明示する |
| 実装前にプランを確認する | 「実装前に変更内容の概要を提示してください」と承認フローを入れる |
6. テスト
テストは設計・実装の妥当性を収束させる工程です。NGは収束のシグナルとして扱い、原因を切り分けて対処します。
既存機能へのデグレードがないこと・変更前後の値の整合・類似処理との対称性・ 全ての入口経路での動作確認
7. 横断確認
全工程が完了したら、セッションを変えて成果物全体の整合を横断的に確認します。
| 確認観点 | 確認内容 |
|---|---|
| 設計と実装の整合 | 設計書に記載された内容が実装に反映されているか |
| 実装とテストの整合 | 実装した処理に対応するテストケースが存在するか |
| 設計とテストの整合 | 設計書のテスト観点がテスト仕様書に反映されているか |
| チェックリストの完了 | 全チェック項目が完了しているか、保留項目の理由が明示されているか |
| 経路全体の整合 | 入口から出口まで一貫して変更が反映されているか |
8. 保守開発でのmdファイル整備
保守開発でも、変更内容をmdファイルに整理してからAgentを動かすことで品質が向上します。
| ファイル | 内容 | タイミング |
|---|---|---|
影響範囲調査.md | 初回調査・詳細化調査の結果。変更対象の経路・影響箇所・業務ルール | 調査完了後 |
詳細設計.md | 修正内容の詳細設計。変更前後の仕様・業務ルール・テスト観点 | 設計完了後 |
修正チェックリスト.md | 修正対象一覧・実施順・ステータス管理 | 設計完了後〜実装中 |
テスト仕様書.md | テスト観点・テストケース・期待値・実施結果 | テスト設計完了後 |
9. 修正チェックリスト サンプル構成
以下は保守開発での修正チェックリストの典型的な分類構成です。案件に応じて調整してください。
| 分類 | 典型的な修正内容 | 実施順の目安 |
|---|---|---|
| 物理DB変更 | DDL（列追加・型変更・インデックス追加） | 1番目（後続の前提） |
| モデル/Entity | 新項目のプロパティ追加・型定義 | 2番目（受け口） |
| 画面表示 | 入力欄・表示欄・変更検知・バリデーション | 3番目 |
| ビジネスロジック | 計算ロジック・判定ロジック・null補正 | 4番目 |
| データアクセス | SQL（SELECT/INSERT/UPDATE）・ストアドプロシージャ | 3〜4番目 |
| 外部連携/IF | 連携項目の追加・ID変更・マッピング修正 | 3番目 |
| 出力系 | 帳票・CSV・帳票フォーム定義 | 5番目（受け口確定後） |
| 機能確認 | 個別機能の整合確認・派生値確認 | 6番目 |
| 横断確認 | 全経路の整合・テスト観点の網羅確認 | 最後 |