「返却予定日を1日だけ延ばせるようにしたい」。入力欄の変更に見えても、次の予約、通知、一覧の表示、すでに貸出中の記録へ影響するかもしれません。変更の大きさは画面の差分ではなく、そのルールを使っている場所から確かめます。
この記事は、運用中のサービスで要件変更を受ける企画・開発担当者向けです。架空の備品貸出を例に、変更を受ける前に揃える情報を示します。影響票は記事側の提案で、工数見積もりや全変更の網羅を保証する様式ではありません。
変更前と変更後を、一文ずつ書く
「延長できるようにする」では、利用者が勝手に何度でも延ばせるのか、総務が代理で直すのかが不明です。作例では次の案を置きます。
変更前：貸出後の返却予定日は変更できず、変更の希望は総務が別途受け付ける。
変更後の案：借りた本人が、返却予定日の前日までに、元の返却予定日の翌日に予約がない備品について、貸出1件ごとに1回だけ1日延長できる。
「1回」「前日」「翌日に予約がない」は作例の業務ルールです。時刻の境界を含め、正式な合意前には確定事項と区別します。変更理由も「窓口への依頼を減らしたい」と書くだけでなく、どんな依頼が何件あるかを確認する担当を置きます。まだ記録がなければ、効果は仮説です。
要件から、利用箇所をたどる
NASAの要件管理では、要件と設計・検証などの対応を保ち、変更が関連要素へ与える影響を評価する考え方を扱っています。6.2 Requirements Management ここではその考え方を、小さなWebサービスの変更確認に読み替えます。NASAの管理手続きをそのまま導入するという意味ではありません。
| 確認先 | この作例で変わる可能性 | 合意・確認する相手 |
|---|---|---|
| 業務ルール | 延長回数、締切、対象外の備品 | 貸出業務の責任者 |
| 権限 | 本人以外の延長、総務の代理対応 | 総務・開発担当 |
| データ | 延長前の予定日、延長回数、変更履歴 | 開発・運用担当 |
| 画面・通知 | 一覧と詳細、返却案内の予定日 | 画面・通知の担当 |
| 他の予約 | 次の利用者と期間が重ならないか | 予約機能の担当 |
| 既存記録 | リリース前に貸した備品も対象か | 業務責任者・移行担当 |
見つかった箇所に、要件番号や画面名、処理名への参照を付けます。今回は小規模なので1枚の表でも構いません。誰かの記憶だけに依存せず、次の変更でも元のルールへ戻れることが目的です。
成功例より先に、境界を一つ変える
GOV.UKはユーザーストーリーに、ニーズを満たしたかを確認する結果として受け入れ条件を付けることを説明しています。Writing user stories
この変更なら「延長できる」に加えて、境界の確認を用意します。以下は合意に出す案です。
- 元の返却予定日の翌日に予約がある場合、延長せず、元の返却予定日を残す。
- 延長画面を開いた後に予約が入った場合も、確定時に条件を確認する。
- 同じ貸出を1回延長済みなら、別の端末からでも2回目を受け付けない。
- 日本時間で予定日当日の00:00より前なら対象とし、00:00以降は受け付けない。
表示されたボタンの有無だけでは判定しません。変更後の予定日が一覧・詳細・通知の対象データで揃うこと、拒否された場合は元の状態が維持されることを確認します。条件を満たすかの判定と更新が競合する点は、開発側の設計・検証が必要です。
元に戻すとき、変更済みのデータはどうするか
公開後に問題が起き、新しい延長受付を停止する場面も考えます。機能を非表示にしても、すでに延長を受け付けた約束は消えません。この作例では、新規の延長だけ止め、確定した返却予定日は維持する案とします。変更済みの記録を特定でき、総務が利用者へ説明できる履歴を残します。
既存レコードには延長回数が記録されていないので、一律に「未延長」とみなすと過去の代理延長を見落とす可能性があります。移行できる情報を調べ、対象を新規貸出に限定する案とも比較します。
変更を受ける前の確認票
依頼者に返す票には、変更理由、変更前後、影響する場所、既存データの扱い、確認する結果、切り戻し時の扱い、未決事項の担当を残します。未決のまま進めるなら、どこまで着手できるかも明示します。
実装に入る前に、担当者がこの票から同じ変更内容を説明できるかを確かめてください。範囲の調整はスコープと優先順位、データの意味はデータ項目の定義に戻って確認できます。