
Conclusion
この記事の結論
利用者から受けた完了報告を起点に、管理側で版を確認できた端末を別に集計します。
スマートフォンのアプリ更新を利用者に依頼すると、操作した本人と管理画面が異なる時点の状態を見ていることがあります。「更新済み」という一つの欄に両方を上書きすると、後からどの端末の状態を実測できたかが分からなくなります。
今回の対応
10月27日、社用スマートフォンのFalcon for Mobileについて更新を案内し、利用者から更新を終えたとの報告を受けました。今回確認できたのは、その報告があった範囲です。
報告時刻と観測時刻を並べる
例えば午前中に利用者から完了連絡が届いても、管理側の最終報告が前日なら、その表示は更新後の版を示す資料として使えません。再度更新を依頼する前に、報告が新しくなったかを見ます。これは判断の例で、10月27日に全端末の版を照合したという意味ではありません。
状況別の判断と次の対応
| 観察した状態 | そこから判断できること | 次に確認すること |
|---|---|---|
| 更新を案内した | 連絡が届く状態にした | 対象と案内日を残す |
| 利用者から完了報告 | 利用者側の操作が終わった | 報告日時を残し管理側の次の観測を待つ |
| 更新後の版を観測 | その時点・その端末で版を確認できた | 版と観測日を対にして完了にする |
台帳に必要な最小項目
対象、目標版、利用者からの連絡日、管理側で確認した版と時刻があれば、再案内が必要な端末を選べます。目標版の指定がなかった依頼について、後から別の最新版を基準に達成率を算出すると、依頼時の結果を正しく表せません。
- 01対象アプリを明記して案内する
- 02利用者の報告日時を残す
- 03管理側の新しい観測と照合する
確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認
