運用手順書は“使う人のために作る”～考え方ひとつで品質は大きく変わる～

その運用手順書、使う人のことをどれだけ想定できていますか？

システム運用において担当者に関わらず業務の品質を維持するために運用手順書は欠かせないドキュメントです。
本記事では、そんな運用手順書を作成する際に持っておくべき考え方に焦点を当てたお話です。

目次

• はじめに
• 本記事の前提
• 運用手順書とは
• 運用手順書作成時に陥りやすい課題
• 品質改善に繋がる考え方
• まとめ
• 最後に

はじめに

この記事はアイソルート Advent Calendar 8日目の記事です。

こんにちは、運用コンサルティングソリューショングループのsaito.rです。
普段はシステム運用設計業務に携わり、運用開始前の運用保守業務に関する方針検討、ドキュメント整備などを行っています。
運用設計時に整備するドキュメントはいくつかありますが、その中に運用手順書があります。
運用設計という言葉に馴染みが無くとも、運用手順書は作成したことがあるという方は意外といらっしゃるのではないでしょうか。

今回は、そんな運用手順書について、私がこれまでに運用設計業務で携わったプロジェクトで抱えていた課題を例に、
ドキュメント品質の向上に繋がる作成時のポイントをお伝えします。

本記事の前提

• 記事は運用手順書作成担当者向けです。
  もちろん、手順書の利用者にとって参考になる観点もあるかと思います。
• 運用手順書は作成した本人以外も使用する想定です。

運用手順書とは

運用手順書とは特定の作業に関して、新人やシステムに初めて触れる人も含め、誰でも同じ品質で実施できるようにするためのドキュメントです。
よくマニュアルと同一視されることがありますが、マニュアルは業務概要を網羅的に理解するためドキュメントであって、作成目的や内容が異なります。

あくまで一例ですが、運用手順書は以下のような作業に対して作成します。

• システムの設定変更手順
• アカウントの追加・削除手順
• 申請手順

運用手順書作成時に陥りやすい課題

運用手順書が課題を抱えやすい背景に「作成者の想定不足」があります。
ここでは主に抜けてしまいがちな観点を２つ紹介します。

1. 内容が「出来る人」向けになっている
   最もよくあるのが、そのシステムを理解している前提の内容になっている運用手順書です。
   そもそもの作業実施の前提条件や注意事項が抜けていたり、画面キャプチャが不足していたりなど作成者の作業時の慣れにより情報不足になってしまうケースです。
   これにより、「読んでもわからない手順書」が生まれてしまいます。
2. 手順の実際の利用場面に即していない
   手順書の中には手順が上下を行ったり来たりするような構成のものがあります。
   手順を飛ばしたり、繰り返したりする場合にその作業に慣れている作成者は表現を省略してしまいがちです。
   このような構成では意図しない手順漏れが発生する原因になりかねません。

実際に私が運用設計対応で参画していた現場でも、作成された運用手順書が上記２つの課題を抱えており、有識者に逐一確認しながらでないと作業が進められず多大な作業コストがかかる現場がありました。
対応当時は運用手順書テストも既に有識者間で実施された後だったために課題が表面化せず、気が付いた時には修正をシステムリリース後に回さざるを得ない状況でした。

品質改善に繋がる考え方

陥りがちな課題を防ぐために必要なのが「手順書を使う人への思いやり」ですが、ただ気持ちをこめるのではなく、押さえておくべき明確なポイントがあります。
以下4つを押さえることで運用手順書の品質は各段にあがります。

1. システムを知らない人が使う想定で見る
2. 目的と前提条件を明確にする
3. 構成は「上から下に」を徹底する
4. レビュー担当やテスト担当をたてる

1. システムを知らない人が使う想定で見る
   画面が遷移するごとにキャプチャを載せる、クリック場所に印をつけるなど視覚的にわかりやすくします。
   また、どのような状態になれば次に進めるのか作業完了条件や注意事項を明確に記載します。
   初めてシステムを触る人を想像するだけでも、細かな観点で意識できるようになります。
2. 目的と前提条件を明確にする
   何をするための作業なのか、どのような時に必要な作業なのかを記載することで作業目的を明確にします。
   次に作業環境や作業準備などの前提条件を記載することで、作業実施前に報告や申請が必要な場合などの作業漏れを防ぐことができます。
3. 構成は「上から下に」を徹底する
   手順は上から下に行くにつれて作業が進むように作成し、
   作業が不要で次の手順に遷移する場合は、遷移条件と遷移先を明記し迷わないようにします。
4. レビュー担当やテスト担当をたてる
   レビューや手順書テストは作成者本人以外の誰かに対応してもらうことが基本ですが、可能であれば他のチームに見てもらうことが有効です。
   実際に使用してもらい、指摘、質問があればそこが作業時の躓く可能性のあるポイントになりますので、修正することで危ない箇所を削減します。
   ちなみに、レビュー実施者は上記1~3を意識しながら確認することで、より情報に抜け漏れのない内容にすることができます。

まとめ

今回は運用手順書を作成するうえで必要な観点をまとめてみました。
ここまで読んでいただいた方の中には「特別なことではない」と感じる方もいらっしゃるかもしれません。
私も特別なことではないと思いますが、その特別でないことを実際にドキュメントに落とし込むことが実は非常に難しいのだと考えています。

難しい理由には作成に対する意識不足だけでなく、時間や作業ボリューム、人員確保などのコスト的な課題を抱えている場合もあります。
だからといって運用時の見直しを前提とした手順書を作成してしまえば、いざ使おうという場面で使えず、一生使われないドキュメントになってしまいます。

「この手順書を使う相手にとって、本当に分かりやすい内容になっているか」を少し意識して作り切るだけでも、運用手順書の品質は各段にあがります。
手順書一つにかけるコストが少ない時こそ、より細やかな意識で作成することで後続のレビューやテストも効率的に進められ
結果的に作成コスト全体を押さえることにも繋がると考えられます。

ここで少し加えておくと運用手順書の見直しの実施は、どんなに品質が良くても必要です。
システムアップデート時や定期的な見直しを実施することで常に最新の状態をキープし、いつでも使用できる状態にします。
次の運用手順書の利用者が安心して業務を担えるようにするためにも、現在の手順書利用者は「正確な情報が記載されているか」という視点をもって
日々の運用の中で今度は更新者としての立場で品質を評価、改善することが大切です。