変更管理
Effective service desks plan and control changes and they understand their impact on their business. An Information Technology Infrastructure Library (ITIL) change management workflow aims to make your change efforts successful.
IT Service Desk テンプレートには変更管理ワークフローが組み込まれています。このワークフローを使用することで、変更リクエストを記録、評価、承認、および実装することができます。既定のワークフローから開始して、ビジネス ニーズに合わせて適宜変更を加えることをおすすめします。
変更管理プロセスを適切に実装すると、以下を実現できます。
- IT サービスの安定化
- IT サービスの信頼性と予測可能性の向上
- 進化するビジネス ニーズへの IT サービスの適応
リスク、システム停止、および不具合を軽減することができます。また、変更の失敗に起因する作業の重複を回避できます。
このページでは、Jira Service Desk を使用して変更を管理するためのいくつかのベスト プラクティスを紹介します。ITIL の推奨事項をビジネスに最適な形で活かす方法を習得するため、正式なトレーニングをお探しいただくこともおすすめします。
変更管理プロセス
IT Service Desk テンプレートは、特定のリクエストを変更ワークフローに接続します。このワークフローは、次の変更管理プロセスを補完するためにセットアップされています。ワークフローを使用し、変更リクエストのレコードを、次の ITIL 推奨アクティビティに沿ってトランジションします。
- レビュー
- 計画
- 承認
- 実装
このワークフローで使用を開始して、ニーズに合わせて適宜変更を加えることをおすすめします。
ITIL の変更管理プロセス (要約):
- 内部 IT メンバーが変更をリクエストします。影響を受けるシステム、考えられるリスク、および想定される実装などの詳細情報を記録します。
- 変更マネージャーまたはピアは、変更が成功するかどうかを判断します。このステップでさらなる追加情報が求められる場合があります。
- レビュー後、チームは変更を反映する方法を計画します。次の情報の詳細を記録します。
- 期待される成果
- リソース
- タイムライン
- テスト
- 変更をロールバックする方法
- 変更のタイプとリスクに応じ、変更承認委員会 (CAB) でプランをレビューする必要がある場合があります。
- チームは変更の実装に取り組み、手順と結果を文書化します。
- 変更マネージャーは実装された変更をレビューしてクローズします。変更が成功したかどうか、タイミングは適切か、見積りは正確だったかどうか、予算内か、およびその他の詳細を記録します。
Jira Service Desk の既定の変更ワークフロー
リクエスト タイプを使用して、変更 と呼ばれる課題タイプに変更リクエストを関連付けます。これによって、課題が推奨される変更リクエスト ワークフローに位置付けられます。
このワークフローは上記の基本的なプロセスにしたがっています。これをカスタマイズして、ビジネスのニーズに合わせて応用できます。
変更ワークフローのカスタマイズ
- In your service project, select Project settings (
) > Workflows. - Jira Service Desk 用の変更管理ワークフローというタイトルの項目で、編集アイコン (鉛筆) を選択します。
- ワークフロー エディターを使用して、ステップとトランジションを追加または編集します。
変更レビューで承認ステップを強制する
変更管理ワークフローには 2 つのレビュー ステージがあります。変更管理者または同僚によるレビューと、変更諮問委員会 (CAB) によるレビューです。既定では、テンプレートではこれらのステップに対する承認は強制ではありません。すべてのサービス エージェントまたは管理者はレビューを行うことで課題をトランジションできます。
厳格な承認を強制することは簡単で、1 人以上の特定のチームメンバーによるレビューを義務づけることができます。たとえば、次に示すのは、ワークフロー内の変更諮問委員会によるレビュー ステージに承認を追加する手順です。
- 上記のステップにしたがって、Jira Service Desk 用の変更管理ワークフロー をカスタマイズします。
- ワークフローで CAB による承認待ち ステップを選択します。
- 承認の追加 チェックボックスにチェックを入れ、設定 を選択します。
- From the Get approvals from dropdown menu, select CAB.
- 作成を選択します。
- ワークフローを公開します。
変更管理者レビューまたは同僚レビューについても、同様の手順を実行できます。ワークフローの 変更管理者 / 同僚レビュー ステージについて同じプロセスを繰り返し、変更管理者 または チーム から承認を得るように選択します。
承認者の指定
上記の手順はレビュー承認を強制しますが、課題側では承認者がわかりません。対応する課題フィールドの承認者を指定します。
たとえば、次のように CAB メンバーを指定します。
- 課題に移動します。
- 編集を選択します。
- CAB フィールドに CAB メンバーを入力します。
このプロセスは、変更マネージャー レビューまたは同僚/チーム レビューについても同様です。
承認を設定する方法に応じて、これらのメンバーのすべてまたは一部は、変更処理を実装待機中ステージに進める前に承認する必要があります。
CAB のメンバーシップをあまり頻繁に変更しない場合があります。その場合、変更要求タイプの設定時に自動的に承認者を指定することができます。
- In your service project, select Project settings () > Request types.
- 事前指定された CAB 承認者を追加する変更要求の横の編集フィールドを選択します。
- フィールドの追加を選択します。
- CAB の横のチェックボックスにチェックマークを付けて適用を選択します。
- 表示フィールドのリストに CAB が表示されます。CAB エントリーで、非表示を選択します。
- CAB メンバーを指定して設定を選択します。
同様に、各リクエストタイプについて、変更マネージャーまたは同僚レビュアーを事前指定できます。
自動承認の標準的な変更
ITIL は事前承認される要求として標準的な変更を定義しています。IT Service Desk テンプレートには標準的な変更を事前承認する自動化規則が組み込まれています。
これは、変更タイプが標準に設定されている変更要求を調べて適用する仕組みになっています。同僚のレビュー/変更マネージャーの承認ステージから計画ステージを通じてこれらを移行します。
You can disable or fine-tune this rule in your automation settings:
- In your service project, select Project settings () > Automation.
- Edit the rule named Auto-approve standard change requests.
変更承認のためのカスタム規則はCAB 承認の待機中ステージでも作成できます。
通常の変更のレビューに期限を設定する
IT Service Desk テンプレートには 通常の変更をレビューする期間を制限する SLA が含まれています。これを使用して変更のレビュー期間を追跡したり、レビュアー用に自動リマインダーを作成したりすることができます。
この SLA は、変更タイプが通常に設定されている変更に対して適用されるように設定されています。SLA では、承認者は処理期間として5 営業日与えられており、それを過ぎると達成失敗となります。承認ステージから承認結果までの期間がカウントされます。
SLA の許容期間は、通常の変更の承認期限で変更できます。この SLA を編集または表示するには、
In your service project, select Project settings () > SLAs.
変更をレビュアーに自動的に通知する
多くの場合、承認者は多忙です。タイムリーな変更を確保するため、保留中の承認の期限が切れると承認者に通知される自動化規則を設定できます。
たとえば、CAB が通常の変更を承認するように CAB 向けのリマインダーを追加します。
- In your service project, select Project settings () > Automation.
- 規則の追加を選択します。
- カスタム規則を選択して、次へを選択します。
- 次の方法を使用するか適宜変更して利用します。
| WHEN | If | THEN |
|---|---|---|
SLA 残り時間 SLA: 通常の変更の承認期限 イベント: 達成失敗 | 課題が一致 詳細設定: status = "待機中 CAB の承認" AND issueType = 変更 | コメントを追加 コメント: CAB メンバーの皆様、変更レビューサイクルを時宜にかなった方法で完了できるようご協力をお願いします。まだ完了していない場合、本日レビューしてください。よろしくお願いします。 コメントタイプ: パブリック |
カレンダーで変更を調整する
Confluence では、変更をスケジュールすることができます。チーム カレンダーを使用して、変更を追跡したり、ビジネス イベントに合わせて変更をスケジュールしたりすることができます。無料の Confluence でチーム カレンダーを試してみてください。
Team Calendars for Confluence で変更カレンダーをセットアップするには、次の手順を実行します。
- Confluence でチームのスペースに移動します。
- サイドバーから、[カレンダー] を選択します。
- [カレンダーを追加する] を選択します。
- カレンダーを表示し、[イベントを追加] を選択します。
- [イベントの種類] ドロップ ダウンを選択し、[Jira 課題日] を選択します。
- 表示で、JQL（詳細）をクリックし、以下を入力します。
project = "<IT サービス デスクのプロジェクト名>" AND issuetype= Change
- [期間] で [開始日と終了日を追加...] を選択します。開始日として [変更開始日] を選択します。終了日として [変更完了日] を選択します。
- OK を選択します。
The calendar automatically picks up the start and end dates of change requests from your service desk. Then, it plots them on the calendar.
変更リクエストの既定のフォーム フィールド
Jira Service Desk を使用することで、カスタマーから収集した情報のフィールドをカスタマイズできます。さらに、エージェントが使用する情報のフィールドもカスタマイズできます。Jira Service Desk は課題タイプのフィールドと画面を通じてこれを実行します。フィールドは、レポートまたはクエリのためにエージェントがリクエストを評価、承認、および分類するのに役立ちます。
既定では、エージェントの変更リクエストのビューには次のフィールドが含まれます。必要に応じてカスタム フィールドを追加できます。Jira のフィールドについて詳細を参照してください。
フィールド名 | 説明 |
|---|---|
| 要約 | リクエストの短い説明。 |
| 報告者 | リクエストの送信者。 |
| コンポーネント | Segments of your IT infrastructure that relate to the request. For example, "Billing services" or "VPN server". These are used for labelling, categorization, and reporting. |
| 添付ファイル | リクエストに追加されるファイルまたは画像。 |
| 説明 | リクエストの長く詳細な説明。 |
| リンクされた課題 | A list of other requests that affect or are affected by the request. If your business uses other Atlassian products, this list may include linked development issues. |
| 担当者 | リクエストの作業に割り当てられているチーム メンバー。 |
| Priority | リクエストの解決状況の重要性は通常、ビジネスのニーズと目標に関係しています。優先度が影響と緊急性によって計算されることもあります。 |
| ラベル | レコードの分類またはクエリに使用される追加のカスタム ラベルの一覧 |
| リクエスト参加者 | リクエストに参加している追加のカスタマー（他のチームやベンダーの人々など）のリスト。参加者について詳細を参照してください。 |
| 承認者 | リクエストを承認する責任を持つユーザーの一覧。通常は、ビジネス、財務、または技術担当者。 |
| 組織 | リクエストの解決状況に関心を持っているカスタマー グループの一覧。Jira Service Desk の組織の詳細を読む。 |
| 影響 | 変更の影響。通常は、サービス レベル アグリーメントに関連。 |
| 緊急性 | ビジネスがリクエストの影響を受けるまでの時間。 |
| 変更タイプ | 変更のカテゴリ (通常は標準、通常、または緊急)。たとえば、標準の変更では、変更マネージャーによるアクションは不要です。通常の変更の場合は必要です。 |
| 変更理由 | 報告者が変更を必要とする理由を示す短い説明またはコード。 |
| 変更リスク | 変更諮問委員会で判断された変更の実装のリスク。通常、複雑さ、スコープ、テスト、リカバリ、タイミングなどに基づきます。 |
| 変更開始日 | 変更の実装がスケジュールされた日付。 |
| Changecompletiondate | 変更の実装が完了した日付。 |
| 変更諮問委員会 (CAB) | 変更の評価、承認、およびスケジュールを担当する個人の一覧。 |
| 保留理由 | 変更が進行していない理由を示す短い説明またはコード。 |
IT サービス管理 (ITSM) について
ITSM を成功させるために多くのヒントやコツを参照し、ワンランク上のサービス デスクを実現する方法を習得しましょう。「IT アンプラグドの ITSM リソース」を参照してください。