機能はあるのに、なぜ仕事が進まないのか

GOV.UKのユーザーストーリーは、利用者・必要なこと・目的の関係を記述します。「理由表示部品がある」は実装の説明です。「担当者が理由を把握し、修正して取込を進められる」は業務上の能力です。

画面上にボタンがあっても、キーボードで到達できない、狭い画面では隠れるなら、実行できません。発見しやすさ、操作可能性、業務上の権限は異なる条件ですが、すべて経路の成立に関係します。

業務基盤の別の変更記録では、一般的な作成処理へ確認機能を加えた後、利用者が実際に通る簡易作成の経路にも対応が必要だと判明しています。設計者が思い浮かべる入口と、日常の入口が一致していなかった例です。

入口を全部なくせばよいわけではありません。短い仕事に特化した画面には価値があります。ただし、入口ごとに意味や検証まで別物にせず、共通の能力を保ち、実際の入口を受入確認へ含めます。

共通APIやライブラリの棚卸しには、機能単位の確認が有用です。業務の受入では、そこから代表的な仕事をつないで実行します。毎回全画面を見るのではなく、変更した能力へ至る入口、権限、例外経路から範囲を選びます。

PBGでは、実装を増やす前に既存能力への経路を調べる判断に使えます。説明、導線、操作、ルールの変更は別の修正です。最初に切れる地点を見つけると、過剰な作り直しを避けられます。