判断の出発点
新しい要望は情報であり、そのまま開発指示になるわけではありません。合意した要件への不具合、新しく判明した要件、好みを分けます。それぞれ受入判定、費用、着手順への影響が異なります。
具体例で考える
架空の予約製品でキャンセルが合意済みだとします。キャンセルのリマインダー追加は新機能です。他人の予約まで消す不具合は修正対象です。調査で漏れた必須の承認ルールは、元の前提をどう扱うか決めます。
決定できる形に要望を整える
変更記録は複雑でなくて構いません。ID、依頼者、理由、対象の仕事、現在の約束、変更点と前後の例を記します。顧客自身の取り消し通知と、拠点の全取消を担当者へ伝える機能では、受取人、権限、通知の多さが違います。見積もり前に依頼者が解釈を承認することで、曖昧な大要望を具体的な変更にできます。
画面以外の影響を確認する
データ、権限、通知、集計、移行、運用説明まで追います。取消理由の追加なら既存予約、機密な理由の閲覧、過去記録を不明として集計する扱いも必要です。受入済みの試験を無効にしないか確認します。当面変更しない案も含め、結果付きの選択肢を出します。元の約束をどれだけ変えるかは事業責任者が判断します。
最新版の合意と受入をそろえる
承認後は範囲、受入例、見積もりを一緒に更新します。却下と延期も残し、忘れられた約束と誤解されないようにします。実演は最新の承認内容に合わせ、過去の理由は参照可能にします。緊急修正は事故記録とルール確認を伴い、修正へ新機能を紛れ込ませないことです。人が入れ替わっても双方が変更と理由を説明できる状態を目指します。
選択肢とその負担
理由、影響する利用者、最小限の許容案、依存関係、受入例を書きます。責任者は他の作業との交換、予算追加、延期を選べます。日程と価格と範囲がすべて変わらないなら、その根拠が必要です。
見落としやすい点
チャットに散らばる口頭承認を避け、現行の範囲と決定者に結び付けた変更記録を残します。重大な運用不具合を見た目の修正より後回しにせず、好みをすべて緊急扱いにもしません。
依頼前に確認すること
誰が承認するか。追加によって何を外すか。どの受入例を変更するか。開発パートナーと変更着手前に決めることで、元の目的を保ちながら計画を調整できます。