手順を作らせるとき、前提と完了条件を必ず書かせる

• 手順だけでは、始める準備が分からない
• 前提と完了条件を、必ず付けさせる
• 人に渡す手順ほど、前後が重要になる

作業の手順を作らせると、手順だけが並ぶ。それだけでは実際に進められないと分かり、形を決めた。

手順だけの問題

番号付きの手順が返ってきても、こうなった。

• 何を用意すればよいか分からない
• どういう状態から始めるのか不明
• 終わったかどうか判断できない

3つ目が最も困る。完了が分からないと、どこまでやるか決められない。

求める形

こう頼むようにした。

（作業）の手順を作ってください。

次の構成でお願いします。
【前提】始める前に必要なもの、状態
【手順】番号付きで
【完了条件】どうなったら終わりか
【確認方法】どう確かめるか
【うまくいかない場合】よくある詰まりと対処

5つ目を入れると、詰まったときに止まらない。

前提に書くもの

前提の項目を決めてある。

• 必要な権限やアカウント
• 事前に用意するファイルや情報
• どういう状態から始めるか
• 所要時間の目安

4つ目があると、着手の判断ができる。10分なのか半日なのかで、始める時機が変わる。

完了条件の書き方

判断できる形で書かせている。

• 曖昧 — 「正しく設定されていること」
• 明確 — 「管理画面に〇〇と表示されること」
• 見て分かる形にする

2つ目のように書かせると、確認した気になるのを防げる。

うまくいかない場合

これを入れるようになって、手順の価値が上がった。

• よくある詰まりを、3つ程度挙げさせる
• それぞれの対処も書かせる
• 該当しない場合の連絡先を、自分で足す

3つ目は自分で書く。どこに聞けばよいか無いと、そこで止まる。

人に渡す場合

自分用と、人に渡す手順では、求める精度が違う。

• 自分用 — 前提は省略してよい。分かっている
• 人に渡す — すべて明示する。聞き返せない
• 画面の写しを添える

2つ目が前提だ。渡された側は、書いてあることしか分からない。

自分で検証する

作らせた手順は、必ず自分でやってみる。

• 手順どおりに進められるか
• 抜けている操作が無いか
• 完了条件を満たせるか

2つ目がよく見つかる。自明な操作が、省略されていることがある。

手順の粒度

どこまで細かく書くかも決めた。

• 1手順で、1つの操作
• 画面が切り替わるところで区切る
• 10手順を超えたら、段階に分ける

3つ目が読みやすさに効く。長い手順は、途中で現在地が分からなくなる。

分岐がある場合

条件によって手順が変わる場合は、書き方を変えている。

• 最初に、どちらに該当するか判断させる
• それぞれの手順を、別に書く
• 1本の流れの中に、分岐を混ぜない

3つ目が読みやすさに効く。手順の途中に「〜の場合は」が挟まると、自分に関係ない部分まで読むことになる。冒頭で分けて、該当する側だけ読めばよい形にすると、迷いが消える。

所要時間を書く

前提に所要時間を入れるようになって、変わったことがある。

• 着手の判断ができる
• 途中で中断する場所を決められる
• 長すぎる手順は、分ける判断ができる

3つ目が設計にも影響した。1時間かかる手順は、30分ずつ2つに分けたほうが実行されやすい。所要時間を書くと、手順の長さそのものを見直すきっかけになる。

更新を前提にする

手順は古くなるので、更新しやすい形にしている。

• 作成日を書く
• どの版を対象にしているか書く
• 画面が変わったら、該当箇所だけ直す

3つ目のため、手順ごとに独立した記述にしている。前の手順に依存した書き方をすると、1つ直すと全部直すことになる。

まとめ

• 手順だけでは、準備と終わりが分からない
• 前提・手順・完了条件・確認方法・詰まったときの5つで構成する
• 完了条件は、見て判断できる形で書かせる
• 作らせた手順は、必ず自分でやってみる
• 人に渡すものは、省略せずすべて明示する