🚀

手順書と心理

2022/03/10に公開

技術ポエム

手順書

idea

手順書Nightの開催おめでとうございます。
とても参加したいのですが都合合わないため野良BoFブログとしてポエム2編をアップします。
一本目のこちらは人間系に注目した内容です。
二本目はツールや図式の内容を予定しています。

最初にものすごく普通の事言います

手順書には以下の内容が含まれていると抜かりないです。

作業対象機器の明記 (特に冗長化していて1台ずつやる場合など)
関係者連絡先(連絡手段, その際のTo, 場合によってはFromも)
成功/失敗の判定方法と切り戻り決断ポイント
切り戻し手順
大きい作業の場合は当日の体制。一人来られなかったらどうするかとか

詳しくは私の意見よりも2016年の神投稿をご覧ください。いつ見ても素晴らしい内容です。

あなたの手順書はどのポジ？

さてあなたのチームや組織では今手順書はどういった位置付けでしょうか。

(1)手順書が間違っていても作業は成功する

この場合、手順書について考えるのはやめて「もっと大事な何か」と向き合いましょう。
手順書をひな形からではなく前回の手順の置換で作成した場合などに置換漏れなどで発生しやすい状態ですが、

手順書が間違っているのに
(a) 別に見てないから
(b) 手順書よりも俺の腕前の方が信頼できるから
正しい作業が行われる、という場合手順書の存在価値はありません。

(a)の場合は記憶とフィーリングに依存して作業を行っているので近いうちに大きな事故を招くでしょう。
(b)の場合、手順書のリバイスやレビューが機能していないのでチームに何か問題があるでしょう。
「手順書より俺の腕前が信頼できる」っていう人が事故るといたたまれないですよね。

(2)手順書が合っているのに作業が間違える

(c)実施担当者のスキルやバイオリズムが足りなかった、もしくは手順書の要求する想定スキルに達していなかった
(d)「手順書よりも俺の腕前の方が信頼できる」と勝手な事をした
(e)たまにはそういうこともあるさ

(c)の場合アサインのミスでもあります。検証環境など練習の場が足りないのかもしれません。
(d)はこの作業実施者がレビューにコミットしていないと思われます。
　「手順ではsystemctl configtest httpdになってるけど俺はhttpd -tするぜ。タイプ数少ないし」
　「手順ではls -lになってるけど俺はllするぜ。タイプ数少ないし。なんでCommand not Foundなんだよ」
　「手順では/usr/localになってるけど/opt/localだろFHS的に」
レビュー時に言え。
(e)ごもっともですが改善を目指すならば計測は行いましょう。

関連して「作業実施者が手順書に無い行動をしている」時は手順書をリバイスするヒントになる場合があります。
「変更反映前にls -lAでファイルの存在を確認しないと心配」などです。
「1Play毎にls -lAをexecするPlaybook」というのは見たことないですが、作業を人が行う場合には作業者が安心して行える内容の手順書であることも価値になります。

(3)手順書が間違っていて作業をミスる

(f)レビューなどを経て手順書の信頼度が上がっている
(g)何かおかしい気がしても立ち止まったりお伺いたてたりすることが許されず手順書様に従うしかない

(f)はチームとして一発で作業を成功させられる状態に無かった、という意味でも有るので大変無念ですがレビューの精度を高め、必要な時はエスカレーションも行って次の成功につなげましょう。
(g)心中お察しいたします。トムデマルコの"ピープルウェア"の中でチーム殺しの方法の一つに「品質低減製品」というのがあります。気付いたのに質の低い作業成果をshipしないといけない状況をヨシとしている責任者をどうにかしましょう。

(4)手順書が正しいので正しい作業が行われる

いや、これが普通であるべきなんですよ？？

手順書の解像度

元記事が探し出せないのですが、10年以上前に確かオルタナブログでこんな内容が紹介されていました。
「ビジネス向けワークショップの課題で『ペットボトルの水を紙コップに注ぐ手順を書いてください』というものがあります。あなたは何ステップになりましたか？」

さあ何ステップになりましたか？

次に私が少々改造した内容を出題します。
「私はロボットです。私に『ペットボトルの水を紙コップに注ぐ』を達成できるように命令してください」

さあ何ステップ増えましたか？

手順書を読む対象読者によって前提として省略割愛できるものや内容量が変化することを実感できると思います。

ちなみにロボットの私はペットボトルを見つけましたか？どこまで探しに行きましたか？逆に目の前にペットボトルが2本あったらどうなりましたか？直前に他の人からの命令で注いでる途中だったんですけどどうなりましたか？前回のペットボトルの位置座標などの過去の記憶は最初にリセットしましたか？
(ロボットのセンサー有無など仕様を書いてない出題者が悪いんですよ)

手順書の解像度については暗黙知という視点で業務引き継ぎを読み解いたYou＆IさんによるSECIモデルの資料が素晴らしいです。この資料に感銘を受けてお話を聞きにOSC名古屋に行ったくらいです。

さあ

みんなで成功するための正しくて信頼されていて伝わる手順書を書いていきたい欲は高まったでしょうか？

私は、うん、いろいろ経験してきましたけどさ、そういうのメンドクサイんですよね。手順書書くのもメンドクサイし作業するのもメンドクサイ。あーあ、もっと楽をするためなら苦労は厭わないのに。

二本目ではBPMN図式化やツールについて述べる予定です。Twineで業務手順書を書くなどのネタをご用意しております。