変更管理

Jira Service Deskを使用する IT チームのためのベストプラクティス

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

robots noindex

効果的なサービス デスクは、変更の計画や制御を実現し、ビジネスに影響を与えます。Information Technology Infrastructure Library (ITIL) の変更管理ワークフローは、変更作業を成功させることを目的としています。

IT Service Desk テンプレートには変更管理ワークフローが組み込まれています。このワークフローを使用することで、変更リクエストを記録、評価、承認、および実装することができます。既定のワークフローから開始して、ビジネス ニーズに合わせて適宜変更を加えることをお勧めします。

うまくいくと、変更管理プロセスによって、以下が実現されます。 

  • IT サービスの安定化
  • IT サービスの信頼性と予測可能性の向上
  • 進化するビジネス ニーズへの IT サービスの対応

リスク、停止、および障害を軽減することができます。そして、重複作業によって変更が失敗することを防ぐことができます。

このページでは、Jira Service Desk を使用して変更を管理するベストプラクティスをいくつか紹介します。ITIL の推奨事項を最適な形でビジネスに生かす方法を習得する正式なトレーニングを探すのもよいでしょう。

このページの内容

変更管理プロセス

IT Service Desk テンプレートは、特定のリクエストを変更ワークフローに接続します。このワークフローは、以下の変更管理プロセスを補完するため設定されています。ワークフローを使用して変更リクエスト レコードを以下の ITIL 推奨アクティビティに沿ってトランジションします。

  • レビュー
  • 計画
  • approvals
  • 実装

このワークフローから開始して、使用していく中でニーズに合わせて適宜変更を加えることをお勧めします。

ITIL 変更管理プロセス (要約):

  1. 内部 IT メンバーが変更をリクエストします。影響を受けるシステム、可能性があるリスク、および想定される実装などの詳細に注意します。
  2. 変更マネージャーまたはピアは、変更が成功するかどうかを判断します。このステップで詳細を尋ねる場合があります。
  3. レビュー後、チームは変更を適切に実施する方法を計画します。以下の詳細を記録します。
    • 期待される成果 
    • resources
    • タイムライン
    • テスト 
    • 変更をロールバックする方法
  4. 変更とリスクのタイプに応じて、変更承認委員会(CAB)はプランをレビューする必要がある場合があります。
  5. チームは変更の実装に取り組み、手順と結果を文書化します。
  6. 変更マネージャーは実装された変更をレビューしてクローズします。それが成功したか、タイムリーか、正確に見積もられているか、予算内か、およびその他の詳細に注意します。

Jira Service Desk の既定の変更ワークフロー

リクエスト タイプを使用して、変更 と呼ばれる課題タイプに変更リクエストを関連付けます。これによって、課題が推奨される変更リクエスト ワークフローに位置付けられます。

このワークフローは上記の基本的なプロセスにしたがっています。これをカスタマイズして、ビジネスのニーズに合わせて応用できます。

変更ワークフローのカスタマイズ

  1. サービス デスク プロジェクトで、[プロジェクト設定]() > [ワークフロー] を選択します。
  2. Jira Service Desk 用の変更管理ワークフローというタイトルの項目で、編集アイコン (鉛筆) を選択します。
  3. ワークフロー エディターを使用して、ステップとトランジションを追加または編集します。

ワークフローの編集に関する詳細を読む

変更レビューで承認ステップを強制する

変更管理ワークフローには 2 つのレビュー ステージがあります。変更管理者または同僚によるレビューと、変更諮問委員会 (CAB) によるレビューです。既定では、テンプレートではこれらのステップに対する承認は強制ではありません。すべてのサービス エージェントまたは管理者はレビューを行うことで課題をトランジションできます。   

厳格な承認を強制することは簡単で、1 人以上の特定のチームメンバーによるレビューを義務づけることができます。たとえば、次に示すのは、ワークフロー内の変更諮問委員会によるレビュー ステージに承認を追加する手順です。

  1. 上記のステップにしたがって、Jira Service Desk 用の変更管理ワークフロー をカスタマイズします。 
  2. ワークフローで CAB による承認待ち ステップを選択します。
  3. 承認の追加 チェックボックスにチェックを入れ、設定 を選択します。
  4. 承認の取得先 ドロップダウンメニューから CAB を選択します。
  5. 作成を選択します。
  6. ワークフローを公開します。

変更管理者レビューまたは同僚レビューについても、同様の手順を実行できます。ワークフローの 変更管理者 / 同僚レビュー ステージについて同じプロセスを繰り返し、変更管理者 または チーム から承認を得るように選択します。

承認者の指定

上記の手順はレビュー承認を強制しますが、課題側では承認者がわかりません。対応する課題フィールドの承認者を指定します。

たとえば、次のように CAB メンバーを指定します。

  1. 課題に移動します。
  2. 編集を選択します。 
  3. CAB フィールドに CAB メンバーを入力します。

このプロセスは、変更マネージャー レビューまたは同僚/チーム レビューについても同様です。

承認を設定する方法に応じて、これらのメンバーのすべてまたは一部は、変更処理を実装待機中ステージに進める前に承認する必要があります。

CAB のメンバーシップをあまり頻繁に変更しない場合があります。その場合、変更要求タイプの設定時に自動的に承認者を指定することができます。

  1. サービス デスク プロジェクトで、[プロジェクト設定] () > [リクエスト タイプ] を選択します。
  2. 事前指定された CAB 承認者を追加する変更要求の横の編集フィールドを選択します。
  3. フィールドの追加を選択します。
  4. CAB の横のチェックボックスにチェックマークを付けて適用を選択します。
  5. 表示フィールドのリストに CAB が表示されます。CAB エントリーで、非表示を選択します。
  6. CAB メンバーを指定して設定を選択します。

同様に、各リクエストタイプについて、変更マネージャーまたは同僚レビュアーを事前指定できます。

自動承認の標準的な変更

ITIL は事前承認される要求として標準的な変更を定義しています。IT Service Desk テンプレートには標準的な変更を事前承認する自動化規則が組み込まれています。 

これは、変更タイプ標準に設定されている変更要求を調べて適用する仕組みになっています。同僚のレビュー/変更マネージャーの承認ステージから計画ステージを通じてこれらを移行します。

このルールは、自動化設定で無効化したり、調整したりすることができます。

  1. サービス デスク プロジェクトから、[プロジェクト設定] () > [自動化] を選択します。
  2. 標準的な変更要求の自動承認という名前の規則を編集します。

変更承認のためのカスタム規則はCAB 承認の待機中ステージでも作成できます。

自動化およびカスタム規則について詳細を読む

通常の変更のレビューに期限を設定する

IT Service Desk テンプレートには 通常の変更をレビューする期間を制限する SLA が含まれています。これを使用して変更のレビュー期間を追跡したり、レビュアー用に自動リマインダーを作成したりすることができます。

この SLA は、変更タイプ通常に設定されている変更に対して適用されるように設定されています。SLA では、承認者は処理期間として5 営業日与えられており、それを過ぎると達成失敗となります。承認ステージから承認結果までの期間がカウントされます。 

SLA の許容期間は、通常の変更の承認期限で変更できます。この SLA を編集または表示するには、

サービス デスク プロジェクト、[プロジェクト設定] () > [SLA] を選択します。

SLA について詳細を読む。

変更をレビュアーに自動的に通知する

多くの場合、承認者は多忙です。タイムリーな変更を確保するため、保留中の承認の期限が切れると承認者に通知される自動化規則を設定できます。

たとえば、CAB が通常の変更を承認するように CAB 向けのリマインダーを追加します。

  1. サービス デスク プロジェクトから、[プロジェクト設定] () > [自動化] を選択します。
  2. 規則の追加を選択します。
  3. カスタム規則を選択して、次へを選択します。
  4. 次の方法を使用するか適宜変更して利用します。
WHEN If THEN

SLA 残り時間

SLA:

通常の変更の承認期限

イベント:

達成失敗

課題が一致

詳細設定:

status = "待機中 
CAB の承認" AND 
issueType = 変更

コメントを追加

コメント:

CAB メンバーの皆様、変更レビューサイクルを時宜にかなった方法で完了できるようご協力をお願いします。まだ完了していない場合、本日レビューしてください。よろしくお願いします。

コメントタイプ:

パブリック

自動化について詳細を読む

カレンダーで変更を調整する 

Confluence では、変更をスケジュールすることができます。チーム カレンダーを使用して、変更を追跡したり、ビジネス イベントに合わせて変更をスケジュールしたりすることができます。無料の Confluence でチーム カレンダーを試してみてください。

Confluence のチーム カレンダーで変更カレンダーをセットアップする方法

  1. Confluence でチームのスペースに移動します。
  2. サイドバーから、カレンダーを選択します。
  3. カレンダーの追加を選択します。
  4. カレンダーを表示し、イベントの追加を選択します。
  5. イベント タイプ ドロップ ダウンを選択し、JIRA 課題日付を選択します。
  6. 表示で、JQL(詳細)をクリックし、以下を入力します。
    project = "<IT サービス デスクのプロジェクト名>" AND issuetype= Change
  7. 日付範囲で、開始日と終了日の追加を選択します。開始日として変更開始日を選択します。終了日として変更完了日を選択します。
  8. OK を選択します。

カレンダーは自動的に変更要求の開始日と終了日をご使用のサービスデスクから取得しますその後カレンダーにこれらの日付を配置します

変更リクエストの既定のフォーム フィールド

Jira Service Desk を使用することで、カスタマーから収集した情報のフィールドをカスタマイズできます。さらに、エージェントが使用する情報のフィールドもカスタマイズできます。Jira Service Desk は課題タイプのフィールドと画面を通じてこれを実行します。フィールドは、レポートまたはクエリのためにエージェントがリクエストを評価、承認、および分類するのに役立ちます。

既定では、エージェントの変更リクエストのビューには次のフィールドが含まれます。必要に応じてカスタム フィールドを追加できます。Jira のフィールドについて詳細を参照してください

フィールド名

説明

要約 リクエストの短い説明。
報告者 リクエストの送信者。
コンポーネント リクエストに関連する IT インフラストラクチャーのセグメント。たとえば、「課金サービス」または「VPN サーバー」などです。これらはラベル、分類、およびレポートに使用されます。
添付ファイル リクエストに追加されるファイルまたは画像。
説明 リクエストの長く詳細な説明。
紐づく課題 リクエストに影響を与える、またはリクエストの影響を受けるその他のリクエストのリスト。ビジネスでその他の Atlassian 製品を使用している場合、このリストに、リンクされている開発課題が含まれる場合があります。
担当者 リクエストの作業に割り当てられているチーム メンバー。
優先度 リクエストの解決状況の重要性は、通常、ビジネスのニーズと目標に関係しています。優先度が影響力と緊急性によって計算されることもあります。
ラベル レコードの分類またはクエリに使用される追加カスタム ラベルのリスト
リクエスト参加者 リクエストに参加している追加のカスタマー(他のチームやベンダーの人々など)のリスト。参加者について詳細を参照してください
承認者 リクエストを承認する責任を持つ担当者のリスト。通常は、ビジネス、財務、または技術の連絡窓口担当者
組織 要求の解決状況に関心のある顧客グループのリスト。Jira Service Desk 内の組織ついて詳細を読む
影響 変更の影響。通常は、サービス レベル アグリーメントに関連。
緊急度 ビジネスがリクエストの影響を受けるまでに利用可能な時間。
変更タイプ 変更のカテゴリ(通常は標準通常、または緊急)。たとえば、標準の変更は、変更マネージャーからのアクションは必要ありません。通常の変更の場合は必要です。
変更理由 報告者が変更を必要とする理由を示す短い説明またはコード。
変更リスク 変更諮問委員会で判断された変更の実装のリスク。通常、複雑さ、スコープ、テスト、リカバリ、タイミングなどに基づきます。
変更開始日 変更の実装がスケジュールされた日付。
変更完了日 変更の実装が完了した日付。
変更諮問委員会(CAB) 変更の評価、承認、およびスケジュールを担当する個人のリスト。
保留中の理由 変更が進行していない理由を示す短い説明またはコード。

IT サービス マネジメント(ITSM)について

ITSM を成功させるために多くのヒントやコツを参照し、ワンランク上のサービス デスクを実現する方法を習得しましょう。「IT アンプラグドの ITSM リソース」を参照してください

最終更新日 2019 年 7 月 2 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.