
Conclusion
この記事の結論
手順書の作成日と、センサーの導入を確認した日は別々に管理します。
配布手順書を作る際に抜けやすいのは、利用者が最後のボタンを押した後の工程です。インストーラーが終わる画面は利用者にしか見えず、センサーが管理対象として現れたかは管理側で確認します。手順書の最後に両者の受け渡しを一行入れると、問い合わせの往復を減らせます。
今回の対応
10月下旬から進めていたFalconの配布手順書について、11月2日に作成作業の完了を記録しました。今回の記録から確かめられるのは文書作成までで、利用者への配布状況や導入済み台数は別途確認する項目です。
末尾に記載する受付例
例えば利用者欄には「完了表示を見た時刻、または停止した手順を連絡」、管理者欄には「依頼対象と登録を照合し、最後の通信が導入後であることを確認」と書けます。登録が見つからない時点で同じ導入操作を繰り返す前に、対象の取り違えや通信前の状態を確認します。
状況別の判断と次の対応
| 観察した状態 | そこから判断できること | 次に確認すること |
|---|---|---|
| 文書が完成した | 説明と確認項目が用意できた | 文書の版と作成日を残す |
| 利用者が終了表示を報告 | インストール操作が終わった | 管理側の登録確認に進む |
| 管理側で登録と通信を確認 | 対象を運用開始後も追跡できる | 登録済み台数へ計上する |
手順書を試すときの観点
初めて作業する人が、正常終了の画面、途中で止まった箇所、問い合わせ先を判別できるかを確認します。11月2日の記録が裏付けるのは文書の作成完了です。この日付を手順書の配布日、承認日、全台の稼働開始日として転記するのは避けます。
- 01利用者側の終了条件を書く
- 02管理側で見る登録と通信を指定する
- 03不一致の連絡方法を手順末尾に置く
確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認
