「申請して、承認して、貸し出す」。この3箱だけの業務フローでは、承認者が不在のときや、承認後に備品が故障したときの仕事が見えません。各工程で、誰が何を受け取り、何が揃えば次へ渡せるかまで書くと、画面だけでは拾えない要件が見つかります。
この記事は、担当者をまたぐ業務をシステム化する人向けです。架空の社内備品貸出を使います。以下の状態や対応方法は記事側の提案であり、現場を調べずに採用するための標準手順ではありません。
現在の仕事と、変えたい仕事を分ける
GOV.UKの経験マップは、利用者が時間の流れに沿って経験することを表し、部署やサービス間の依存関係、困る箇所を理解するためのものです。複数の利用者の経験を集めて作ると説明しています。Creating an experience map
この記事ではその視点を借りて、業務の引き渡しを表にします。正式な経験マップそのものではありません。まず直近の貸出1件を担当者と振り返り、「メールで依頼」「口頭で承認」「紙で受け渡し」など、今行っている事実を書きます。次に、システム導入後の案を別の表にします。希望を現状に混ぜると、残す必要のある仕事を見落とします。
矢印に、受け渡す情報を付ける
| 工程 | 担当と受け取るもの | 次に進める条件 | 残す状態 |
|---|---|---|---|
| 利用申請 | 社員が備品・期間・用途を入力 | 必要事項が揃っている | 承認待ち |
| 利用承認 | 所属長が申請を確認 | 利用を認める判断が記録された | 手配待ち |
| 現物の手配 | 総務が申請と備品を確認 | 使える現物を割り当てた | 受取待ち |
| 受け渡し | 総務と社員が現物を確認 | 社員へ現物を渡した | 貸出中 |
| 返却確認 | 総務が返却品を確認 | 対象と状態を確認した | 返却済み |
この例では承認と現物の確保を分けています。承認済みでも、故障で渡せない場合があるためです。「承認済み」を「受け取れる」と案内すると、社員は窓口へ来てから困ります。逆に、申請時点で現物を確保する運用なら、表の条件自体を変えます。
例外は、戻り先と担当まで決める
正常な流れをたどれたら、各工程で「人がいない」「情報が足りない」「対象が使えない」を一つずつ試します。
| 止まる場面 | 作例での扱い | 決め忘れやすいこと |
|---|---|---|
| 所属長が不在 | 指定した代理承認者へ回す | 誰が代理を指定し、いつ解除するか |
| 用途が不明 | 理由付きで社員へ差し戻す | 同じ申請を修正するか、新規申請にするか |
| 承認後に備品が故障 | 手配待ちのまま総務が代替を相談 | 利用者への連絡と、取り消しを選べる期限 |
| 受取前に不要になった | 社員が取り消し、確保を解除 | 受け渡しと同時に操作された場合の扱い |
「エラーにする」だけでは、次に動く人がいません。総務への相談が必要なら、相談先、引き継ぐ申請番号、未対応を見つける一覧まで一緒に決めます。待ち時間の数値は現場の対応能力に合わせて合意し、想像で保証しないようにします。
同時に起こる出来事を一組だけ試す
社員が取り消すのと、総務が貸出を確定するのが重なったとします。作例では、サーバーで先に確定した状態を基準とし、貸出済みなら取り消しを受け付けず返却手順へ案内します。社員には古い「受取待ち」の画面だけで判断させません。
CucumberのGherkinは、前提・出来事・期待する結果で例を記述します。Gherkin reference この分け方を借り、「貸出が確定した後に取り消しが届いたら、貸出記録を残し、返却の案内を表示する」と確認メモにできます。実際の排他制御や整合性は開発担当による設計・検証も必要です。
現場と確認する5項目
- 各工程の担当は、部署名だけでなく担当の決め方まで分かるか。
- 次へ進める条件は、ボタンを押したこと以外で説明できるか。
- 差し戻した情報や、過去の判断はどこに残るか。
- 担当不在・故障・取り消しで止まった仕事を誰が見つけるか。
- 電話や窓口で行う仕事も、完了まで表に入っているか。
確認結果を画面ごとの条件にする際は受け入れ条件の書き方、代理承認の範囲を詰める際は権限設計の確認表を使えます。