見出し画像
Photo by ia19200102

システム運用手順書の考察

近藤 誠司

先日、手順書に関するツイートがプチバズりしました。

このツイートにコメントや引用リツイートがいっぱいついて、私の通知は2～3日の間手順書祭りになりました。（同時並行でRFP祭りにもなってましたが……）
今日はせっかくなんで、このツイートにまつわるエトセトラをまとめておこうと思います。

140文字って、難しいよね！

まずは140文字には収まらなかった、私のこのツイートの真意を書いておきます。
かっこの中は、ツイート上は文字数の関係で泣く泣く消した内容です。

（パブリッククラウドやSaaSが増えてきた昨今では）「誰でも作業できる手順書」って（オンプレ時代のアプリと違って勝手に画面が変わったり、勝手に機能が追加されたりするので）作成（と維持する）コストが高くなる。
（定型作業であっても、ある程度の）スキル前提を決めて、一定以上のスキルを持つ人たちが使える（CLIをベースとした）手順書を作った方がいい。
（じゃないと、変更が入った場合の維持管理コストも膨大なものになる。）「誰でも作業できる手順書」は、（極端な話をすると）小学生全員がその場で因数分解を解ける手順書を作るのと一緒。
それが無理なので解くためには（学校教育と同じで、段階を踏んで）教育が必要って話でもあります。

めちゃくちゃ説明臭くなりましたねｗ
ツイッターはどうしても文字数の関係で言い切りスタイルになってしまうので、ちょくちょく誤解を受ける場合があります。
まぁ、私はそもそもツイッターで議論を深めるのは無理だと思っているのであきらめていますが。
ただ、今回は140文字という言葉足らずのお陰で、いろいろな人の色々な意見が集まりました。
気になったものをいくつかピックアップさせてもらって考察を深めてみましょう。

誰でも作業できる手順書を書かないとレビューが通らない。

これはいくつかのパターンがあると思います。
人の入れ替えの激しい現場や、エントリーレベルの新人さんが多く来る現場であれば、品質を保つためにこのレビューは正しいと思います。
また、業種が官公庁や金融といった重要インフラ14分野の場合は、ワンミスが社会インフラを止めてしまう可能性があるので、手順書の精度を上げる必要があるでしょう。

ただ、この場合でも「スキルが高い人が作業した方が、ミスが少なくなるしトラブル発生時のリカバリも早くなる」という原則は変わりません。
なので、だれでも理解できる手順書を作ると同時に、メンバーのスキルを上げる必要があるのは変わらないと思います。

そもそも、手順書をちゃんと読まない人がいる。あと、日本語がちゃんと読めない人がいる。

これこそ、ちゃんと教育しないといけない気がします。
この手のオペレーション作業については、鉄道総合技術研究所がいくつか有用な論文を出しています。
「指差し呼称によるミス軽減」や「ダブルチェックによるヒューマンエラー軽減」や「トリプルチェックすると逆にエラーが増える」などのことを参考に正しく手順書を理解できる行動をとるように教育するべきでしょう。

大手メーカー工場では、だれでもわかる手順を作っている

これは私が門外漢なのでわかりませんが、おそらくそうなのでしょう。
これも人の入れ替わりが激しく、インプット情報が変わらない単純な定型作業が多いなら高いコストをかけて手順書を作成しても元が取れるでしょう。

全社員にパソコン作業の依頼は誰でもできる手順書が必要

これはたしかにそうだと思います。
ロースキルで大量の人に作業をしてもらう場合、画面ショットに赤枠をつけて、「ここをクリック」的な手順書が必要になります。
類似例としては、家電についてくるスタートアップ手順のようなものでしょう。
作っておくことで問い合わせ等の対応が大幅に減るのであれば、高いコストをかけて「誰でも作業できる手順書」を作ることも意味のあることだと思います。

誰でも作業できる手順書を書くことが出来れば、それは自動化できるはず

これは完全にYESとは言い切れませんね。
そもそも、何かの理由で自動化できないから手順書を書いている可能性があります。
あと、画面ショットに赤枠をつけて、「ここをクリック」的な手順書をそのままRPAで自動化した場合、画面構成が変わったりするので、自動化後のメンテが手順書と同じくかかってきます。
理想の自動化はCLIやAPIを使ってコード化することなのですが、CLIの手順を理解するためにはある程度のスキルが必要なので、やっぱり最低限のスキルを得るための教育が大事って話になります。

誰でもの基準がどうも高すぎではないでしょうか？

これは示唆に富んだ指摘だったと思います。
そもそも「誰でも作業できる手順書」の「誰でも」とは誰なんでしょうか？
その定義を決めた方が良い、というのが今回のツイートで本当に言いたいことだった気がします。

スキルある人には冗長になって逆にわかりにくくなるってのが大きい。

これも「誰でも作業できる手順書」の弊害のひとつかなと思います。
慣れた手順で、Word や PowerPoint にワンアクションずつ記載されている手順書ファイルをスクロールしながら作業するのは、けっこう時間がかかります。
それを回避するために、手順書とは別のチェックリストを作って作業することすらあります。
馴染みのある管理画面で操作をするなら、2画面の片方に全行程が分かるレベルのテキスト手順をおいて、順番に作業していく方が全体感が分かっていいと思います。
これもスキルや役割や作業難易度に合わせて手順書を作りましょうって話ですね。

公開範囲によるかな。

これはそうですね。
スキルレベルと合わせて、公開範囲もたしかに手順書粒度の重要な要素だなって思いました。

エディタに3~4行、作業用アカウント情報なし、ファイルパスなし、画面遷移の説明無し、執筆者退職済み、という個人メモレベルのものを「公式の手順書」として渡された

これは記載レベルの話ではなく、運用成熟度が低すぎるという話な気がします。
もはや運用ルール全体の話です。
運用ドキュメントのありかは別途決めておくべきですし、特権アカウントの情報は手順書に書くのかどうかも別途ルール化しておくべきでしょう。

その現場"特有の概念"についてはみんなちゃんと端折らずかきましょう。

これも運用設計全体の話ですね。
どこに何を書き残しておくのかを決めて、必要な情報が必ず見つけられる動線にする。
そのうえで、手順書に何を書くべきかを検討する必要があります。

下限の設定は大切。

今回の趣旨はたしかにスキル下限を決める話なのですが、大切なのは「下限以下を切り捨てる」ということではなく、「教育でスキルを上げてもらうという思考を持つ」というです。
誰しも最初は駆け出しエンジニアだったはずです。
私にも、恐る恐る「pwd」を打っていた若かりし頃があったのですよ。


まとめ

そもそも、このツイートは運用設計研修の以下のページを修正していた時につぶやいたものでした。

これもわかりやすく書いているので誤解を生みそうですが、別にオペレータが悪いという話をしたいわけではありません。
利用者と状況によって、作成する手順書の内容が変わってくるという話です。
手順書の話とは別に、業界全体としてはオペレータからエンジニアにステップアップできる教育体制を確立するべきだと思っています。

ということで、手順書でバズるという貴重な経験をしたのでまとめてみましたの回でした。

運用設計の教科書と運用改善の教科書という書籍を出しています。
ご興味のある方は、ぜひ手に取ってみてください。


いいなと思ったら応援しよう！