運用手順書の更新が実態に追いつかない問題を変更管理と文書管理の連携で解消する方法

運用手順書と実際の作業内容がずれている。この問題は、情報システム部門であれば誰もが一度は経験しているはずです。システム変更や障害対応のたびに現場の手順は変わっていくのに、手順書の更新は後回しになり、気づけば手順書の内容と実態がまったく別物になっている。新人や異動者が古い手順書を信じて作業した結果、本番環境で誤操作が発生し、障害につながるケースは珍しくありません。

この記事は、従業員50〜500名規模の企業で、情報システム部門の運用担当者やインフラチームのリーダーを想定しています。専任のドキュメント管理者がいない環境で、変更管理と手順書更新を兼務しているような方が対象です。読み終えると、システム変更が発生してから手順書が更新されるまでの流れを仕組み化し、手順書の陳腐化を防ぐ具体的なワークフローを自社に導入できるようになります。なお、数千名規模のエンタープライズ向けのITIL完全準拠の変更管理プロセス設計や、個別ツールの網羅的なレビューは扱いません。

本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、変更申請から手順書更新・承認までを一気通貫でつなぐワークフロー設計図と、各ステップの担当者・頻度・判断基準が手元に揃います。

Workflow at a glance: 運用手順書の更新が実態に追いつかない問題を変更管理と文書管理の連携で解消する方法

• Step 1: 変更申請と影響範囲の特定を行う (Jira Service Management) (カスタマーサポートツール)
• Step 2: 手順書の該当セクションを更新し版管理する (Confluence) (ナレッジマネジメントツール)
• Step 3: 更新承認後にチケットをクローズし週次で棚卸しする (Jira Service Management) (カスタマーサポートツール)

なぜ手順書の更新は後回しになり続けるのか

変更管理と手順書管理が別の世界に住んでいる

多くの現場では、変更管理の承認記録はServiceNowやRedmineなどのチケット管理ツールに、手順書はファイルサーバー上のWordやExcelに、版管理は共有フォルダのファイル名に日付を付けるだけ、という状態です。変更を実施した人と手順書を更新する人が同一とは限らず、変更完了後に手順書を直すタスクが自動的に発生する仕組みもありません。結果として、変更は完了したのに手順書だけが古いまま残るという状態が常態化します。

更新しなくても目の前の業務は回る

手順書の更新は、目の前の障害対応やリリース作業と比べると緊急度が低く見えます。更新しなくても今日の業務は回るため、優先度が下がり続けます。しかし、この負債は確実に蓄積します。ある日突然、異動してきたメンバーが3世代前の手順書でバッチ処理を実行し、データ不整合を起こすといった形で表面化します。

版管理の不在が信頼を壊す

ファイル名に日付を付けるだけの版管理では、どのバージョンが最新なのか、誰がいつ何を変えたのかが分かりません。複数人が同時に編集して上書きしてしまうこともあります。こうなると、手順書そのものへの信頼が失われ、ベテランは手順書を見ずに自分の記憶で作業するようになります。属人化がさらに進み、手順書を更新する動機がますます薄れるという悪循環に陥ります。

重要な考え方：変更チケットを閉じる条件に手順書更新を組み込む

手順書の更新が後回しになる根本原因は、更新作業が変更管理プロセスの外にあることです。変更チケットのクローズ条件に手順書の更新完了を含めれば、更新しない限り変更作業が完了扱いにならず、自然と更新が実行されます。

更新を意志の力に頼らない

手順書の更新を個人の責任感や習慣に頼ると、忙しい時期に必ず抜け落ちます。仕組みとして、変更チケットがクローズされる前に手順書更新タスクが自動生成され、更新が承認されるまでチケットが閉じられない状態を作ることが重要です。

更新の粒度を最小にする

変更のたびに手順書全体を見直すのは現実的ではありません。変更チケットに影響範囲として対象の手順書のセクション番号を記載し、そのセクションだけを更新する運用にします。更新範囲が明確になれば、1回あたりの作業は15分程度で済みます。この粒度の小ささが、更新を継続できるかどうかの分かれ目です。

週次の棚卸しで漏れを拾う

仕組みを作っても、軽微な変更や緊急対応時には手順書更新が漏れることがあります。週に1回、変更チケットの一覧と手順書の更新履歴を突き合わせて、未反映の変更がないかを確認する棚卸しを行います。この棚卸しは15分で終わる程度の軽い作業ですが、漏れを早期に発見する最後の砦になります。

変更発生から手順書更新完了までの実践ワークフロー

ステップ 1：変更申請と影響範囲の特定を行う（Jira Service Management）

システム変更が必要になった時点で、担当者はJira Service Managementに変更チケットを起票します。チケットには、変更内容の概要、影響を受けるシステムやサービス、そして影響を受ける手順書のセクション番号を必ず記載します。手順書のセクション番号は、後続の更新作業の範囲を限定するために不可欠な情報です。

チケットのカスタムフィールドとして、対象手順書名と対象セクション番号の2つを追加しておきます。変更の承認者はこのフィールドが空欄のままではチケットを承認できないルールにします。これにより、変更申請の時点で手順書への影響が必ず検討されます。

承認が完了し、変更作業が実施された後、チケットのステータスを変更実施済みに移行します。この移行をトリガーとして、次のステップの手順書更新タスクが自動生成されます。

ステップ 2：手順書の該当セクションを更新し版管理する（Confluence）

Jira Service Managementのチケットステータスが変更実施済みになると、Jiraの自動化ルールによってConfluence上の該当手順書ページにコメントが自動投稿されます。コメントには、変更チケット番号、変更内容の概要、更新が必要なセクション番号が記載されます。同時に、Jira側にはサブタスクとして手順書更新タスクが自動生成され、変更実施者にアサインされます。

変更実施者は、Confluenceで該当セクションを開き、実際に行った作業内容に基づいて手順書を更新します。Confluenceのページ履歴機能により、誰がいつ何を変更したかが自動的に記録されます。更新時には、ページのバージョンコメントに変更チケット番号を記載し、変更管理との紐付けを明確にします。

更新が完了したら、Confluenceのページ上でレビュー担当者にメンションを付けてレビューを依頼します。レビュー担当者は、変更内容と手順書の記載が一致しているかを確認し、問題なければ承認コメントを残します。

ステップ 3：更新承認後にチケットをクローズし週次で棚卸しする（Jira Service Management）

レビュー担当者がConfluence上で承認コメントを残したら、変更実施者はJira Service Management上のサブタスク（手順書更新タスク）を完了にします。サブタスクがすべて完了した状態でなければ、親チケットである変更チケットはクローズできないようにJiraのワークフローを設定します。これが、手順書更新を確実に実行させる仕組みの核心です。

週に1回、運用リーダーはJira Service Managementのフィルター機能を使い、過去1週間でクローズされた変更チケットの一覧を出力します。この一覧とConfluenceの手順書更新履歴を突き合わせ、更新漏れがないかを確認します。Jiraのダッシュボードに未完了の手順書更新サブタスクを表示するガジェットを配置しておけば、棚卸しは5〜10分で完了します。

漏れが見つかった場合は、該当する変更チケットを再オープンし、手順書更新を完了させてから改めてクローズします。

この組み合わせが機能する理由

Jira Service Management：変更管理と手順書更新タスクを構造的に紐付ける

Jira Service Managementを選ぶ最大の理由は、変更チケットとサブタスクの親子関係を使って、手順書更新をクローズ条件に組み込める点です。サブタスクが未完了なら親チケットをクローズできないというワークフロー制約は、Jiraの標準機能で実現できます。自動化ルールによるサブタスクの自動生成も、コーディング不要で設定できます。

一方で、Jira Service Managementは設定の自由度が高い分、初期設定に時間がかかります。カスタムフィールドの追加、ワークフローの編集、自動化ルールの作成を合わせると、初回のセットアップに半日から1日程度は見ておく必要があります。また、ライセンス費用が発生するため、すでにJiraを利用している組織でなければ導入のハードルは高くなります。すでにRedmineやBacklogを使っている場合は、同様の親子チケット構造とワークフロー制約が実現できるかを確認してください。

Confluence：版管理とレビューを手順書の中で完結させる

Confluenceを選ぶ理由は、ページ履歴による自動的な版管理と、Jira Service Managementとのネイティブ連携です。Jiraのチケットからワンクリックでリンク先のConfluenceページに飛べるため、変更内容と手順書の突き合わせが容易です。ページ内のコメント機能でレビューと承認のやり取りも完結します。

Confluenceの弱点は、Wordのような細かい書式設定には向かないことです。既存の手順書がWordやExcelで作られている場合、Confluenceへの移行作業が発生します。ただし、すべての手順書を一度に移行する必要はありません。変更が発生した手順書から順にConfluenceに移行していく段階的なアプローチが現実的です。また、Confluenceはページ単位の権限設定が可能なため、手順書の閲覧範囲を部署やチーム単位で制御できます。

Recommended tool list

結論：変更チケットのクローズ条件に手順書更新を組み込めば陳腐化は止まる

手順書の陳腐化は、個人の怠慢ではなく、変更管理プロセスと手順書管理が分離していることによる構造的な問題です。Jira Service Managementの変更チケットにサブタスクとして手順書更新を自動生成し、サブタスク完了をクローズ条件にすることで、更新しない限り変更作業が終わらない仕組みを作れます。Confluenceで手順書を管理すれば、版管理とレビューも自然に回ります。

最初の一歩として、今週発生する変更チケット1件に対して、手順書更新サブタスクを手動で追加し、クローズ前に更新を完了させるところから始めてください。この1件がうまく回れば、自動化ルールの設定に進む判断材料が揃います。

Mentioned apps: Jira Service Management, Confluence

Related categories: カスタマーサポートツール, ナレッジマネジメントツール

Related stack guides: 業界標準の改定内容を自社システムへ漏れなく反映し監査不適合を防ぐ方法, パートナーとのトラブル発生時に証跡を即座に集約し原因究明と再発防止を加速する方法, 育児・介護休業の案内から申請・社会保険手続きまでを仕組み化し人事担当者の個別対応と手続きミスをなくす方法, 危機発生時にブランド方針と広報対応のズレをなくし初動遅れと二次炎上を防ぐ方法, ツール導入後の社内問い合わせ対応が特定の社員に集中する属人化を解消し安定したサポート体制を構築する方法