#この記事を書いた理由#
ITとはちょっと外れてしまいますが、自分の仕事のやり方を固めていくために教えられたこと、考えたことを記載していきます。
#何が書かれていればいいのか・・・#
手順書を作るために欲しいもの
| 事項 | 説明 |
|---|---|
| 作業目的・概要 | 目的・概要が分からないと、実施することも分からないため。背景知識、用語も書かれているとよりグッド |
| 各手順の概要・目的 | 個別の手順が分かっていても、抽象化しないと何をやっているか掴みずらいため 例 実作業のための準備等 |
| 詳細手順 | 具体的な手順のこと。具体的じゃないと誰でも実施できないため。誰でもできるレベルに落とし込むこと。 例 コマンドを発行するなら、コマンド文まで書く |
| 工数 | どれくらいで終えられるか分からないと実施時間を報告できないため |
| 検証(手順) | insert,update,deleteなどのSQLを手順内で発行するなら、結果が正しいか検証すること |
| 事前確認点 | 作業をきちんと始められるかを確認するチェックリストのこと |
| 事後確認点 | 作業がきちんと終わっているかを確認するチェックリストのこと |
| 問題対応表 | 問題が起こったときの対処法を記録するもの。次回、問題が起こっても安心 |
| QA表 | 作業の疑問点を洗い出す。また作業者から質問されたときに答えるために使う |
| レビュー | 手順に抜け漏れ無駄があるか、誰でもできるレベルか、検証は成立しているか、を見てもらう |
詰まるようなら、何が問題なのか
| 現象 | 原因 | 対応策 |
|---|---|---|
| 作成に時間がかかる | 無駄な作業がある | すべての手順に画面エビデンスを使っていないか |
| 検証する手順が分からない | 検証の実現方法が分からない | どうやって検証すればいいかを聞く |