変更管理とは？

IT サービスに対して何らかの変更に対する業務を管理し、リスクや IT サービスの中断を最小限に抑え、IT サービスを円滑にするためのプロセスです。

ITIL ではこのプロセスを”変更実現”と呼んでいますが、Jira Service Management では変更管理としているので、このドキュメントではそれに従います。

変更は、以下の3種類のいずれかに分類されます。

変更のタイプ

標準変更：リスクが低く、あらかじめ承認されている変更。（例：メモリやストレージの追加など）
通常変更：文書化されたプロセスに従って評価、承認を行う必要がある変更。（例：サーバーの部品変更など）
緊急変更：可能な限り迅速に対処する必要がある変更。（例：インシデントの解決やセキュリティパッチの実装など）

変更管理プロセス

変更管理の大まかなフローは、以下の通りです。

変更リクエストの作成・記録
どのような変更を行うのかを明確にし、IT メンバーが記録します。変更リスクや効果、影響を受けるシステム、想定される実装等を決めておきます。
変更リクエストのレビュー
変更マネージャーまたはピアレビュアーが変更が成功するかどうかを判断します。
変更の計画
IT チームが変更を適切に実施するために計画します。主に、期待される結果やテスト、タイムライン、必要に応じてロールバックの手順を計画し、文書化します。
変更の承認
適切な変更マネージャー、ピアレビュアー、または変更諮問委員会（CAB）の関係者が計画をレビューし、変更を承認します。
変更の実装
承認された変更リクエストに対し、開発チームが変更を実装し、リリースします。手順と結果を文書化します。これは、リリース管理や展開管理の一環でもあります。
変更のレビューとクローズ
変更マネージャーは、承認された通りに変更が実施されたかを検証します。また、変更文書に変更内容や評価内容をまとめ、すべての処理が完了したら変更文書を完了にします。

Jira Service Management で変更管理をセットアップ

Jira Service Management の高度な IT サービス管理テンプレートには、変更管理プロセスを適切に進行するためにワークフローが既に用意されています。

既定のワークフロー

また、自動化するテンプレートが用意されているため、自動化された変更リスク評価、高度な承認ワークフロー等を利用し、変更管理のフローを簡素化できます。

問題の根本的な解決に IT システムの変更が必要となった場合を想定し、変更タイプは「通常変更」とし、変更菅理のフローに沿ってプロジェクトを作成してみましょう。

手順１-プロジェクトを作成する

[プロジェクト] > [プロジェクトを作成] を選択します。
サービス管理テンプレートより使用するテンプレートを選択し、[テンプレートを使用] を選択します。
以下の例では「高度な IT サービス管理」のテンプレートで作成します。

高度なインシデント管理機能は、Premium プランと Enterprise プランのみが利用できます

2024 年 10 月 16 日より、Jira Service Management の高度なインシデント管理機能（メジャーインシデントやインシデント事後レビューなど）は、Free プランや Standard プランではご利用できません。

プロジェクトの名前、プロジェクトキー、チームタイプ、チャネルアクセスを設定します。
[プロジェクトの作成] を選択します。

手順２ -変更の課題を作成する

リソースの割り当て変更やパフォーマンス調整のような小規模で予測可能な変更は、通常、標準変更に該当する場合が多いですが、今回の例では過去の実施履歴がない前提で通常変更としています。
会社や組織によっては、手順やポリシーにより、標準変更として扱うか通常変更として扱うかは異なります。

問題管理にて解決策が見つかり、 IT システムの変更が必要になった場合は、変更リクエストを作成します。
Change type、Impact、Change risk、Planned start date/end date や Change start date/completion date等必要な項目を入力します。

プロジェクトサイドバーにある変更カレンダーにて、すべての Jira Service Managment サービスプロジェクト全体の変更を表示したり、カレンダー上でスケジュールし管理できます。他の変更対応とバッティングを回避するために、事前に調整することができます。

また、チケットの起票者は、リスクインサイトパネルより、最近のインシデントや、競合する変更等を全体的に把握することが可能です。
リスクインサイトパネルを表示するには、[影響を受けるサービス]、[Planned start date]、[Planned end date] のフィールドが入力されている必要があります。リスクインサイトの詳細はこちらからご確認ください。

競合がある場合は、レビュワー（変更マネージャーまたはピアレビュアー）に事前に報告し、変更の計画日を見直す必要がある場合は、チケットのカレンダーアイコンより日程を変更します。
レビュワー（変更マネージャーまたはピアレビュアー）をチケットの担当者にアサインし、レビューを実施します。
レビューが完了したら、チケットのステータスを「計画」にトランジションし、IT チームのメンバーに担当者を割り当てます。
IT チームのメンバーは、変更を適切に実施するため、期待される結果やテスト、タイムライン、必要に応じてロールバックの手順について Confluence へ文書化します。チケット内の Confluence のアイコンから[ページ]を選択します。
Confluence ITSM の変更管理のテンプレートを活用し、記録していきます。
Confulence のページは自動的に Jira 課題にリンクされます。
適切な変更マネージャー、ピアレビュアー、または変更諮問委員会（CAB）の関係者が計画内容をレビューするため、チケットのステータスを「承認」にトランジションします。

承認ステータスにトランジションすると、「影響を受けるサービス」が紐づけされている場合は、承認者グループに自動的に「決済処理」サービスの"変更承認者"が割り当てられます。
サービスの内容や設定については、こちらからご参照ください。

決済処理サービスの設定内容

影響を受けるサービスを選択していない場合は、[承認者グループを追加]より承認者グループを追加します。
承認グループのユーザーは、「承認」または「却下」をします。
「承認」すると、チケットのステータスは、「実装待ち」に自動的にトランジションされます。「却下」の場合は、「レビュー」に変更されます。
チケットの担当者を開発チームのメンバーに割り当てするか、内部コメントで開発チームをメンションして連携します。開発チームは、チケットのステータスを「実装中」に変更し実装に取り組みます。また手順と結果を Confluence に文書化したうえでリリースします。
変更マネージャーにチケットを再割り当てします。変更マネージャーは、承認された通りに変更が実施されたかをレビューし、適切な場合は変更をクローズします。
変更文書に変更内容や評価内容を手順5. で作成した Confluence ページに記録します。
（例.変更が成功したかどうか、タイミングが適切か、見積もりが正確だったかどうか、予算内かなど）