アプリ改修で残す機能を伝える方法｜変更前後の確認表を作る

アプリへ新しい機能を加えるときは、追加する内容だけでなく、残す機能と操作を一覧へ記録します。変更後には、その一覧に沿って動作と表示を確かめます。

私もアプリの改善後、以前のタブが見当たらないことについて確認した場面がありました。画面にないことだけで、データが消えた、機能が削除されたという原因までは断定できません。ここでは、変更前後を比較する表を紹介します。

変更する範囲を明記する

「全体を改善する」という依頼でも、すべてを作り直すと決まったわけではありません。画面、データ、実行処理のそれぞれで対象を整理します。

維持する操作を実行条件で書く

「検索を残す」だけでなく、どの入力と操作で、何ができる状態を維持するかを書きます。

機能名：
開始する画面：
入力する条件：
行う操作：
期待する表示：
保存データへ影響するか：

確認用の条件には、必要な範囲で説明用のデータを使います。実際の登録や送信を含む場合は、影響を確かめてから試します。

画面の移動と機能の削除を分ける

タブの統合や項目の移動を行うなら、新しい入口を記録します。以前の場所にない場合も、別の場所へ移っているかを確認します。

入口、操作、データの保存先を別々に見て、どこが変わったかを整理します。見つからない状態を、保存データがなくなった状態へ置き換えて報告しないようにします。

変更後の確認表

テストしていない項目を問題なしとしません。必要な端末や入力条件を確認できなければ、未確認として範囲を残します。

AIへの改修依頼文

以下の追加・修正を行い、維持する機能の一覧を変更前後で確認してください。削除が必要だと考えた場合は、対象と理由を示してください。動作確認した操作と、まだ確認できていない操作を分けて報告してください。

修正箇所そのものの伝え方は、変更点と残す部分を分ける修正依頼に整理できます。問題を見つけたら、再現手順を添える不具合報告へ記録します。

まとめ

改修時には、追加、修正、維持、削除、未決を分けます。変更後に何を確認するかも、作業前に用意します。

以前の機能が見当たらない場合は、入口、操作、データの状態を調べます。確認した範囲を明示し、未実施のテストまで成功したと扱わないようにします。