10月も近づき、ようやく秋っぽい天気になってきました。3連休は台風接近とタイミングが悪かったですが、コロナの感染状況も落ち着いてきたので行楽に良い時期になってきたと感じます。

さて、今回はドキュメントについて取り上げたいと思います。弊社の運用自動化ツールも、いわゆるRBA=Runbook Automation（手順書自動実行ツール）のカテゴリーにも入る製品で、作業手順書などが完備されている前提になっております。

業務の自動化プロジェクトを進める際に、これらの作業手順書について改めての見直しを行ってくださいと、セミナー等でお話しています。これは先週の本メルマガでお送りした、不要な業務プロセスの削除や自動化に向いた作業手順への組み換えといった観点もあります。ただ、現場によってはそもそもの作業手順書に課題があるケースもございます。ここでは幾つか作業手順書に関して見直しのポイントを列挙していきます。

1. ドキュメントが存在していて、分かりやすい場所に保管されているか

さすがに本番環境での作業を手順書なしで実施することは無いと思いますが、手順書がローカル環境にあり担当者にメールなどで配布しているだけといったケースはありませんか？

作業がトラブルが発生した際の手順の調査や、後日に似た作業をする場合に使うなど。ドキュメントを後日に必要とするケースが出てきます。

特別な事情が無い限り、チームのメンバーが参照できるような分かりやすい場所に公開しておきましょう。

2. レビュー、テストされているか

ドキュメントも人が作成するものですので、ミスは起こりえます。内容のレビューやステージング環境でのテスト実行は必要でしょう。

またレビューにかけることで作業手順やノウハウがチームメンバーに共有されます。

3. 確認ステップが用意されているか

作業を行った結果が問題ないことを確認するステップを用意します。この際に確認の手順を具体的に記載します。

例えば、「＊＊＊が正しいことを確認すること」といった記述では、どのような状態が「正しい」のか解釈の余地が生まれます。

– 確認コマンド

– 想定出力

– 「＊＊が＊＊になっていること」「＊＊が＊＊以上、＊＊以下になっていること」

のように、機械的に確認できるようにすべきです。

4. 問題発生時の手順が用意されているか

コマンドの実行を行った結果、想定外の挙動をした場合や、コマンドの入力ミスなどで誤操作を行った場合など、さまざまなトラブルに遭遇する可能性があります。このような場合に備えて、作業者が迷わないように、想定ケースと具体的な対応方法を一覧化しておきます。例えば、

– バックアップからのリストアを行う。

– サービスをメンテナンスモードに切り替え、作業を中断してエスカレーションする。

– 予備環境に切り替える。

いろいろな対策が考えられますが、作業者がパニックになる場合もありますので、なるべく作業者が迷う要素を減らし、機械的にトラブルシュートを試行できるように準備します。

現場判断の要素が増えると、作業者のスキル・経験値によっては問題の影響が拡大・悪化する場合もあります。

具体的な手順（実行コマンド）やトラブル発生時の対処方法などがドキュメントに落とし込めたら、これらの作業を自動化することは比較的容易です。逆に「アプリAをデプロイする」「ファイヤーウォールの設定変更を設定する」など、大まかに記載されている手順に関しては、作業者の経験やスキルに依存しており、属人化の温床ともなります。

ドキュメントを作成するのが面倒などで軽視される場合も多々ありますが、そこから作業自動化まで持ち込めば将来的には楽できるようになりますので、上手に作り込んでいっていただければと思います。