•タイトル: この改修作業のタイトル（例: 売上集計ツール改修）
• 件名: 不具合・改修内容の件名（例: 集計結果が誤っている問題の対応）
• 打ち合わせ参加者: 打ち合わせや確認作業に参加したメンバー（例: 山田、鈴木）、所属部署
• 不具合状況の確認
• 不具合内容の具体的な確認: どの操作や入力でどのような不具合が発生しているか？
• 発生場所の確認: どのファイル、シートやセル、操作に関して問題が発生しているか？
• 再現性の確認: 不具合が特定条件で毎回起きるのか、一時的なものか？
• 期待値
• 期待する結果の確認: 正常に動作した場合、どのような結果が表示されるべきか？
• 条件別の期待値の確認: 特定の条件において期待される結果がどう変わるか？
• 期待値の根拠: 業務ルールや仕様書など、期待する結果の根拠を確認
• 納期
• 完了期限の確認: 対応を完了しなければならない期限はいつか？
• 納期の根拠: 納期が設定されている理由（他の業務スケジュールや報告日など）
• 優先事項の確認: 納期に合わせるため、必須の修正項目と後回しにできる項目を確認
• やってはいけない操作
• 禁止操作の確認: 絶対に行ってはいけない操作はあるか？
• 変更禁止のデータ範囲の確認: 重要なデータが含まれるセルや範囲はどこか？
• データの保護: ロックや保護がかかっているか？
• フロー図による事前確認
• フロー図の作成: 改修内容やロジックの流れをフロー図にまとめたか？
• 関係者との確認: フロー図を基に依頼者や関係者と事前に確認し、認識のズレがないかチェック
• 変更点の合意: フロー図の確認に基づき、改修内容やロジックに対する合意を得ているか？
• テスト用データ
• テストデータの必要性確認: 不具合解消確認のため、テスト用データが必要か？
• テストデータの提供依頼: 必要な場合、依頼者からテストデータを提供してもらえるか？
• データのバリエーション: 異なるパターンのデータが必要か？
• 改修対象ツールの場所
• ファイルパスの確認: 改修対象のファイルがどこに保存されているか（例: ネットワークフォルダやクラウドストレージのパス）
• 実環境での改修か: 実際の運用環境でのみ動作するものなのか、コピーしてローカル環境で改修できるのか？
• コピーの可否: コピーして改修が可能な場合、実ファイルへの影響を避けるためにコピーして作業するか？
• 実環境でのみ動作する場合のリスク対策
• バックアップの確認: 実環境での改修が必要な場合、作業前にバックアップを取得しているか？
• 動作確認タイミングの調整: 実環境での動作確認を行う場合、運用に影響が少ないタイミングを選定しているか？（例: 業務終了後、休日など）
• ロールバック手順の確認: 万が一問題が発生した場合に備え、元の状態に戻す手順（ロールバック）が確立されているか？
• バージョン値の変更
• バージョンアップの種類: 改修内容が「メジャーバージョンアップ」（大きな機能追加・変更）か「マイナーバージョンアップ」（小規模な改修）かを確認
• バージョン番号の記録: 改修後のバージョン番号を設定し、ファイルやコード内に記録しているか？
• バージョン履歴の管理: 変更履歴として、旧バージョンと新バージョンの内容を記録しているか？
• 報告
• 中間報告の必要性: 進捗を依頼者や上司に報告する必要があるか？報告頻度はどうするか？
• 最終報告の内容: 問題解決後、どのような内容で報告するか確認
• 報告方法の確認: 報告はメール、チャット、口頭など、どの手段で行うか
• 不明点がある時の確認先
• 質問先の確認: 技術的な疑問や業務内容について確認する担当者は誰か？
• 不在時の対応: 質問先が不在の場合、他の確認方法（他の担当者、仕様書確認など）はあるか？
• 連絡手段
• 通常の連絡方法: 通常時に利用すべき連絡手段は何か？（メール、チャット、電話など）
• 緊急時の連絡方法: 緊急の場合の連絡手段と、優先すべき連絡方法は何か？
• 連絡のルール: 特定の時間帯に適した連絡手段や、緊急連絡の優先順位について確認しているか？
• その他改修時の注意点
• 影響範囲の把握: 改修箇所が他の機能やシートに与える影響を把握しているか？
• 一時的なロジック追加の可否: デバッグや検証のための一時的なコードやログ出力を追加しても良いか確認（本番環境で一時的な処理を入れる場合は特に注意）
• 元のコードの保存: 改修前のコードやシートの状態を保存しているか？
• 作業の記録: 作業内容や変更点を簡潔に記録する
• 複数人での改修確認: 大規模な変更やリスクが高い場合、他のメンバーと改修内容を確認するダブルチェック体制を設けているか？
