ソフトウェア開発エージェント
変更を、確かめられる差分として進める。
開発を支援するAIを使うときも、何を変えるのか、なぜ必要なのか、どう確かめたのかが判断の材料です。要件から変更内容、テスト結果までを追える作業の流れを考えます。
期待する振る舞いを共有する
実装を依頼する前に、変更のきっかけとなる操作や入力と、期待する結果を明らかにします。既存の挙動で維持する点や、対応しない範囲も整理してください。
コードを変更する作業と、その変更を採用する判断は分けます。担当者が差分、検証結果、残る制約を確認できる形を、作業の出力として考えます。
要件からレビューまで
- 対象と影響範囲を調べる
関連するコード、設定、既存の検証方法を確認します。説明と実装が異なる場合は、その違いを先に整理します。
- 確認できる単位で変更する
目的に必要な範囲へ変更を絞り、何を変えたかを説明できる状態にします。複数の独立した課題は分けて考えてください。
- 実行結果を添えて確認する
変更に応じた型検査、テスト、実画面などで確認します。実行していない検証や、まだ確かめられない条件も記録します。
作業権限を工程ごとに分ける
| 作業権限を工程ごとに分ける | 検討する作業 | 別に確認する判断 |
|---|---|---|
| 調査と提案 | 構成の調査、変更案やテスト案の作成 | 要件の採用、設計上の前提、影響範囲 |
| 検証環境での変更 | コードの編集、実行、修正 | 変更内容のレビュー、確認結果と残る制約 |
| 共有・本番への反映 | 反映手順と対象の準備 | 共有ブランチへの取り込み、本番への反映、戻す場合の判断 |
レビューへ渡す情報
- 目的
- どの入力や操作で、どのような振る舞いを変えるか。
- 変更
- 修正した範囲と、関連する設定やデータへの影響。
- 確認結果
- 実行した検証、結果、確認できなかった条件。
- 反映時の条件
- 必要な準備と、変更を戻す場合に参照する情報。
自動の確認だけで採用できますか
テストが通れば、そのまま本番へ反映できますか。
テストは確認した条件の結果です。要件との一致、画面や操作への影響、実行していない条件も確認し、反映する担当者が判断する流れを用意してください。