システム変更の承認・手順書・作業記録を一気通貫で紐づけ未承認変更と手順逸脱を防ぐ方法

システムの変更作業やメンテナンスを行うとき、承認申請はワークフローシステム、手順書はファイルサーバーやWiki、作業後の記録はまた別のツール、という状態になっていないでしょうか。この3つが分断されていると、承認された内容と実際に行った作業が本当に一致しているのか、誰も検証できません。結果として、未承認の変更や手順を飛ばした作業が見過ごされ、障害やコンプライアンス違反につながります。

この記事は、従業員50〜500名規模の企業で、情報システム部門の担当者やインフラ運用チームのリーダーを想定しています。変更管理の仕組みを整えたいが、ITILのような大規模フレームワークを本格導入するほどの予算や人員はない、という方に向けた内容です。読み終えると、承認から作業実施、記録までを1本の線でつなぐ実務ワークフローを自社に導入するための具体的な手順と設定の方針が手に入ります。大規模エンタープライズ向けの全社ITSM導入計画や、個別ツールの網羅的なレビューは扱いません。

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

読み終えた時点で、承認申請・手順書・作業記録が変更管理番号で紐づいた一気通貫のワークフロー設計図と、各ツールの設定方針が手元にそろっている状態になります。

Workflow at a glance: システム変更の承認・手順書・作業記録を一気通貫で紐づけ未承認変更と手順逸脱を防ぐ方法

• Step 1: 変更申請を起票し承認を得る (ServiceDesk Plus) (インフラ・セキュリティ関連)
• Step 2: 承認済み番号に紐づく作業手順書を準備・参照する (Confluence) (ナレッジマネジメントツール)
• Step 3: 作業を実施し記録と突合チェックを行う (ServiceDesk Plus) (インフラ・セキュリティ関連)

なぜ承認・手順書・作業記録がバラバラだと問題が見えなくなるのか

3つのシステムが分断される構造的な原因

多くの企業では、承認申請にはワークフローシステム、手順書の管理にはWikiやファイルサーバー、作業後のログ記録にはExcelや監視ツールの画面メモ、というように、それぞれの目的に特化したツールを個別に導入してきた経緯があります。これらは導入時期も管理部門も異なるため、相互に連携する設計になっていません。

承認申請には申請番号が振られますが、手順書にはその番号が記載されておらず、作業記録にも承認番号が転記されないケースがほとんどです。つまり、ある変更作業について承認→手順参照→実施記録という一連の流れを後から追跡しようとしても、人の記憶やメールの検索に頼るしかありません。

ビジネスへの具体的な影響

この分断が引き起こす問題は3つあります。1つ目は、未承認変更の見逃しです。承認を取らずに作業してしまった場合、それを検知する仕組みがないため、障害が起きて初めて発覚します。2つ目は、手順逸脱による障害です。承認された手順と異なる作業を行っても、比較する手段がなければ逸脱に気づけません。3つ目は、監査対応の工数爆発です。内部監査やISMS審査で変更管理の証跡を求められたとき、3つのシステムから情報をかき集めて突合する作業に膨大な時間がかかります。ある企業では、年1回の監査対応だけで担当者が丸2週間拘束されていたという事例もあります。

重要な考え方：すべての変更作業を1つの変更管理番号で串刺しにする

この課題を解決する原則はシンプルです。変更管理番号という1つの共通IDを決め、承認申請・手順書・作業記録のすべてにこの番号を付与するだけです。

変更管理番号が果たす役割

変更管理番号とは、たとえばCHG-2025-0042のような、変更作業ごとに一意に振られるIDのことです。この番号を承認申請のタイトルに含め、手順書のページにタグとして付け、作業記録のチケットにも記載します。こうすることで、どのツールからでもこの番号で検索すれば、承認内容・手順書・作業記録が即座に見つかる状態になります。

番号の自動採番と転記を仕組み化する

ここで重要なのは、番号の付与を人の手作業に頼らないことです。ワークフローシステムで承認申請を起票した時点で自動的に番号が採番され、その番号が後続のツールに自動で引き渡される仕組みにします。手動転記に頼ると、番号の付け忘れや誤記が必ず発生し、串刺しの仕組みが形骸化します。

事後の突合チェックで逸脱を検知する

番号で紐づけた後は、定期的に突合チェックを行います。承認済みの変更管理番号の一覧と、実際に作業記録が存在する番号の一覧を突き合わせ、承認はあるが記録がないもの、記録はあるが承認がないものを洗い出します。この突合を月次で回すだけで、未承認変更や作業漏れを早期に発見できます。

承認から作業記録までを1本の線でつなぐ実践ワークフロー

ステップ 1：変更申請を起票し承認を得る（ServiceDesk Plus）

変更作業が必要になったら、まずServiceDesk Plusで変更リクエストを起票します。ServiceDesk Plusには変更管理モジュールがあり、起票と同時にCHG-2025-XXXXという形式の変更管理番号が自動採番されます。

申請時に記入する項目は、変更の目的、対象システム、作業予定日時、影響範囲、リスク評価、承認者の6つです。これらを入力すると、事前に設定した承認フローに従って、上長やセキュリティ担当者に承認依頼が自動で飛びます。

承認フローは、影響度に応じて分岐させます。たとえば、本番環境に影響する変更は部長承認を必須にし、検証環境のみの変更はチームリーダー承認で完了とする、といった設定です。ServiceDesk Plusの変更管理モジュールでは、この承認ルートをテンプレートとして複数パターン用意できます。

承認が完了すると、ステータスが承認済みに変わり、次のステップに進めるようになります。この時点で、変更管理番号・承認者・承認日時がすべて記録されます。

ステップ 2：承認済み番号に紐づく作業手順書を準備・参照する（Confluence）

承認が下りたら、作業手順書をConfluenceで準備します。Confluenceのページタイトルに変更管理番号を含め、たとえばCHG-2025-0042 データベースサーバーパッチ適用手順のように命名します。さらに、ページのラベル機能で変更管理番号をタグとして付与します。

手順書には、作業前の確認事項、具体的な作業手順（コマンドや操作画面のスクリーンショットを含む）、作業後の確認事項、切り戻し手順の4つを必ず含めます。この構成をConfluenceのページテンプレートとしてあらかじめ作成しておくと、毎回ゼロから書く手間がなくなります。

ServiceDesk Plusの変更リクエスト画面には、関連URLを記載するフィールドがあります。ここにConfluenceの手順書ページのURLを貼り付けることで、承認申請と手順書が双方向でリンクされます。作業者はServiceDesk Plusの変更リクエストを開くだけで、承認内容の確認と手順書の参照がワンクリックで行えます。

手順書の更新履歴もConfluence上で自動的に残るため、承認後に手順書が改変されていないかを後から検証することも可能です。

ステップ 3：作業を実施し記録と突合チェックを行う（ServiceDesk Plus）

作業当日、担当者はServiceDesk Plusの変更リクエストを開き、ステータスを実施中に変更してから作業を開始します。作業中は、Confluenceの手順書に沿って作業を進め、各ステップの完了をServiceDesk Plusのワークログ（作業メモ）に記録していきます。

作業が完了したら、作業結果（成功・一部失敗・切り戻し実施など）、実際の作業時間、手順からの逸脱があった場合はその内容と理由をServiceDesk Plusに記入し、ステータスを完了に変更します。

ここで重要なのが、月次の突合チェックです。ServiceDesk Plusの変更管理モジュールでは、カスタムレポートを作成できます。承認済みだがステータスが完了になっていない変更リクエスト、および完了しているが承認ステータスが承認済みでないリクエストを抽出するレポートを作成し、毎月1回実行します。このレポートに該当するものがあれば、未実施の変更や未承認の変更が存在するということです。

さらに、サーバーやネットワーク機器の構成変更を検知するために、ServiceDesk Plusの資産管理機能を活用します。管理対象の資産情報に変更があった場合、対応する変更管理番号が存在するかを確認する運用ルールを設けます。これにより、ツールを介さずに直接行われた未承認変更も検知できます。

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

ServiceDesk Plus：承認・記録・突合を1つのツールに集約できる

ServiceDesk Plusを中心に据える最大の理由は、変更管理・承認ワークフロー・作業記録・資産管理がすべて1つの製品内に含まれている点です。承認と作業記録が同じシステム内にあるため、変更管理番号による紐づけが自然に実現でき、外部連携の設定が最小限で済みます。

カスタムレポート機能で突合チェックを自動化できるのも大きな利点です。承認済み一覧と作業完了一覧の差分を抽出するレポートを一度作れば、毎月ボタン1つで実行できます。

一方で、ServiceDesk Plusは多機能であるがゆえに、初期設定の項目が多い点は注意が必要です。変更管理モジュールの承認フロー設定、カスタムフィールドの追加、レポートの作成には、導入初期に1〜2週間の設定作業を見込んでおく必要があります。また、オンプレミス版とクラウド版で機能差があるため、クラウド版を前提に検討することをおすすめします。

Confluence：手順書の版管理と検索性を両立できる

手順書の管理にConfluenceを選ぶ理由は、ページの版管理（バージョン履歴）が自動で残る点と、ラベルによる検索性の高さです。変更管理番号をラベルとして付与しておけば、番号で検索するだけで該当の手順書が即座に見つかります。

また、ページテンプレート機能により、手順書のフォーマットを統一できます。作業前確認・手順・作業後確認・切り戻しという4セクション構成をテンプレート化しておけば、記載漏れを防げます。

注意点として、Confluenceは自由度が高い分、運用ルールを決めずに使い始めると、ページの命名規則やラベルの付け方がバラバラになりがちです。導入時に命名規則とラベルルールを明文化し、テンプレートに組み込んでおくことが成功の鍵です。また、Confluenceの無料プランは10ユーザーまでという制限があるため、チーム規模によっては有料プランが必要になります。

Recommended tool list

結論：変更管理番号という1本の串を通すだけで承認と記録の分断は解消できる

承認・手順書・作業記録の分断という課題は、高価なITSMツールを導入しなくても、変更管理番号で串刺しにするという原則を徹底するだけで大幅に改善できます。ServiceDesk Plusで承認と記録を一元管理し、Confluenceで手順書を版管理付きで整備し、月次の突合レポートで漏れを検知する。このサイクルを回すことで、未承認変更や手順逸脱を早期に発見できる体制が整います。

まず最初の一歩として、ServiceDesk Plusの変更管理モジュールを有効化し、直近で予定している変更作業1件を使って、起票から作業完了までの一連の流れを試してみてください。1件通してみるだけで、自社に必要な承認フローの分岐条件や、手順書テンプレートに含めるべき項目が具体的に見えてきます。

Mentioned apps: ServiceDesk Plus, Confluence

Related categories: インフラ・セキュリティ関連, ナレッジマネジメントツール

Related stack guides: 業界標準の改定内容を自社システムへ漏れなく反映し監査不適合を防ぐ方法, パートナーとのトラブル発生時に証跡を即座に集約し原因究明と再発防止を加速する方法, 育児・介護休業の案内から申請・社会保険手続きまでを仕組み化し人事担当者の個別対応と手続きミスをなくす方法, 危機発生時にブランド方針と広報対応のズレをなくし初動遅れと二次炎上を防ぐ方法, 過去の分析資産が再利用されず同じ分析を繰り返す問題をなくし分析工数を半減させる方法