サービスオペレーションワークスペース での変更要求の作成

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間:12分
  • 変更要求を使用して、サポートされている構成アイテム (CI) への変更を追跡します。変更の理由、変更タイプ、優先度、リスクなどの情報を記録できます。

    始める前に

    必要なロール:itil または admin

    注:
    DevOps データを表示したり、変更要求に追加したりするには、sn_devops.viewer ロールが必要です。

    手順

    1. 新しい変更要求を作成します。
      ソース説明
      変更リスト
      1. 変更のリストに移動します。
        注:
        次のリストが利用できます。
        • オープン
        • クローズ済み
        • すべて
      2. [新規] を選択します。
      変更テンプレートから
      1. 変更のリストに移動します。
        注:
        次のリストが利用できます。
        • オープン
        • クローズ済み
        • すべて
      2. [新規] を選択します。
      3. [ テンプレート] を選択します。
      4. 必要なテンプレートを検索して選択します。
      5. [ 続行] を選択し、選択したテンプレートを使用して作成された新しい変更要求レコードを表示します。
      注:
      既存のテンプレートを選択すると、事前定義されたフィールドに情報が入力されます。テンプレートフィールドは、テンプレートの作成時に設定されたテンプレートフィールドポリシーに応じて、読み取り専用または必須のいずれかです。

      変更テンプレートの詳細については、「 サービスオペレーションワークスペースでの変更テンプレートの作成と提案」を参照してください。

      インシデント
      1. インシデントを開きます。
      2. インシデントレコードフォームで、[ 変更要求の作成] を選択します。
      インタラクション
      1. インタラクションを開きます。
      2. インタラクションレコードフォームの [ インシデントの作成 ] ドロップダウンリストから [ 変更を作成] を選択します。
      問題
      1. 問題を開きます。
      2. 問題レコードページの [ 問題タスクの作成 ] ドロップダウンリストから [ 変更要求の作成] を選択します。
    2. 作成する変更モデルを選択し、[ 続行] を選択します。

      変更タイプをフィルタリングして検索できます。

      次の変更タイプを使用できます。
      変更モデル 説明
      通常 事前承認済みの変更や緊急の変更ではないサービス変更です。
      標準 事前に承認されたリスクの低い変更で、比較的一般的で、指定された手順または作業指示に従います。
      緊急 グループおよびピアのレビューと承認をバイパスする緊急の変更で、CAB 承認グループによる承認のために認証状況に直接進みます。
      DevOps または DevOps Simplified DevOps 変更要求に使用される変更モデル。

      DevOps モデルを使用するには、 DevOps 変更速度管理 アプリケーションをアクティブ化する必要があります。

      詳細については、「変更モデル」を参照してください。

      注:
      インタラクションから変更要求を作成する場合は、事前承認済みの変更タイプのみを使用できます。
    3. [概要] タブで、フィールドに入力します。

      [概要] タブで、変更の初期詳細を入力する必要があります。

      フィールド 説明
      簡単な説明 変更の簡単な説明
      説明 変更の詳細な説明
      購入理由 計画された変更要求の理由。承認者が意思決定を下すのに役立ちます。
    4. [保存] を選択します。

      変更要求は、[スコープと影響][アサイン (Assignment)][スケジュール][リスク評価]、および [変更タスク] セクションとともに作成されます。

    5. 変更のスコープと影響の情報を入力します。
      1. [スコープと影響] セクションで [スコープを追加] を選択します。
      2. フォームのフィールドに入力します。
        表 : 1. [スコープを追加] フォーム
        フィールド 説明
        構成アイテム 変更が適用される構成アイテム (CI)。サービスオファリングを含む、任意のタイプの CI を変更の要求に関連付けることができます。また、SLA と可用性の要件への詳細なアクセスを可能にします。
        サービスオファリング 可用性、スコープ、価格設定、およびパッケージングに関して、サービスのレベルを一意に定義する 1 つ以上のサービスコミットメントで構成されています。サービスオファリングを使用すると、指定されたサービスのさまざまな機能とそのパフォーマンスレベルを受け取ることができます。
        サービス 変更要求に対して使用できるようにするビジネスサービス。
        カテゴリ 変更のカテゴリには、[ハードウェア][ネットワーク][ソフトウェア] [その他][DevOps] などがあります。
        注:
        [DevOps データを追加] セクション (この手順のステップ 8) は、カテゴリが [DevOps] として選択されている場合にのみ有効になります。DevOps モデルの場合、カテゴリは自動的に [DevOps] に設定されます。
        影響を受ける CI 構成アイテム (CI) を単一の変更要求に関連付けます。
        一括 CI 更新を提案 特定の CI クラスの CI セットに同じ更新を適用する
        単一の変更を提案 影響を受ける CI のリストから 1 つの CI への変更を提案します。
        影響するサービスの更新 影響するサービスをリフレッシュすると、[影響を受けるサービス/CI]、[ビジネスアプリケーション]、および [サービスオファリング] 関連リストが、影響を受ける CI に基づいて更新されます。各関連リストのレコードは、影響を受ける単一の CI からの影響である場合でも一意です。
      3. [Save (保存)] を選択します。
    6. 関連するユーザーまたはアサイン先グループに変更要求をアサインします。
      1. [アサイン (Assignment)] セクションで [アサイン] を選択します。
      2. フォームの各フィールドに入力します。
        フィールド 説明
        アサイン先グループ 変更にアサインされたグループ
        それぞれの構成アイテム (CI) で利用可能なサポートグループに基づいて、[アサイン先グループ] フィールドを自動的に入力できます。CI に変更グループがない場合は、サービスオファリングで利用可能な変更グループがフィールドに入力されます。ビジネスルール [CI/SO に基づいたアサイン先グループの入力 (Populate Assignment Group based on CI/SO)] は、インシデント、問題、または変更要求が作成または更新されたとき、および [アサイン先グループ] フィールドと [アサイン先] フィールドが空のときに機能をトリガーします。次のプロパティは、[アサイン先グループ] フィールドに値が入力されるフィールドを識別します。
        • com.snc.change_request.ci_assignment_group.field_name:この変更プロパティは、[アサイン先グループ] フィールドに入力される CI フィールドを識別します。
        • com.snc.change_request.service_offering_assignment_group.field_name:この変更プロパティは、[アサイン先グループ] フィールドに入力されるサービスオファリングフィールドを識別します。
        注:
        プロパティのデフォルト値は、それぞれインシデントまたは問題のサポートグループと変更要求の変更グループです。ビジネスルール [CI/SO に基づいたアサイン先グループの入力 (Populate Assignment Group based on CI/SO)] は、開発プラグイン ITSM CSDM Best Practice – Quebec プラグイン (com.snc.best_practice.itsm_csdm.quebec) の一部として出荷され、新規のお客様のみが利用できます。
        アサイン先 変更要求にアサインされたユーザー。アサインルールが適用される場合、変更が適切なユーザーまたはグループに自動的にアサインされます。
        作業メモ 変更の解決方法に関する情報、または変更の解決手順 (該当する場合)。このメモは内部で使用されます。作業メモ情報は顧客に表示されません。
      3. [Save (保存)] を選択します。
    7. 変更の実装をスケジュールし、検出された競合を表示します。
      注:
      [変更要求] フォームの [ 競合の検出から除外 ] チェックボックスがオンになっている場合、競合の検出機能は使用できません。詳細については、「」を参照してください。
      1. [ スケジュールの設定] を選択します。
      2. [スケジュール] ページで、開始予定日と終了予定日を入力します。
      3. [ 競合] タブの [ スケジュールと競合] セクションには、検出された競合が一覧表示されます。
        [ 前回の実行の競合 ] フィールドには、競合の検出が最後に実行された日付が表示されます。検出された競合の詳細は、[関連レコード] タブで確認できます。
        注:
        競合の検出プロセスが進行中の場合、[ 競合のチェック] ボタンが [ 進行状況の表示] に変わります。

        次の表に示す検出された競合の詳細が [ 競合] セクションに表示されます。

        フィールド 説明
        変更 競合が検出された現在の変更要求。
        タイプ 検出された競合のタイプ。

        次のタイプの競合が表示されます。

        • CI はすでにスケジュールされています
        • 親 CI はすでにスケジュールされています
        • 子 CI はすでにスケジュールされています
        • メンテナンス期間内にありません
        • 親がメンテナンス期間内にありません
        • 子がメンテナンス期間内にありません
        • 停電
        スケジュール 検出された競合が関連付けられているブラックアウトまたはメンテナンススケジュール。
        競合する変更 現在の変更要求と競合している変更 (存在する場合)。
        影響を受ける CI 検出された競合に関連付けられた CI。
        影響を受けるサービス 検出された競合によって影響を受けるサービス。
        最終確認 競合の検出プロセスが最後に実行された日付。
        詳細については、「競合の検出」を参照してください。
        注:
        [ 競合のチェック] を選択して、競合の検出プロセスを手動で実行することもできます。
      4. オプション: 競合がある場合は、現在の変更要求を再スケジュールします。
        1. [ スケジュール] ページに移動します。
        2. 現在のカード編集アイコンを選択します。
        3. 新しい開始予定日と終了予定日を選択します。

        または、[次の競合のないカード] で [スケジュール] を選択して、変更の実装を競合がない次の日時に再スケジュールすることもできます。

        変更スケジュール 次の競合のないカード

    8. オプション: [DevOps データ (DevOps data)] セクションで [データを追加] を選択して、DevOps データを変更要求に追加します。
      注:
      DevOps データを変更要求に追加したり、作成済みの変更レコード内の DevOps データを表示したりするには、sn_devops.viewer ロールが必要です。
      1. [関連性を選択] ステップで、以下の値を指定します。DevOps データタイプとその関連性を選択するステップ
        表 : 2. 関連性を選択
        フィールド 説明
        データタイプ

        変更要求に関連付けるデータのタイプ。

        • アーティファクトバージョン
        • リリースバージョン
        • ビルド番号
        • 作業アイテム
        データの関連付け

        変更要求に関連付ける特定のデータ。複数のアーティファクトバージョン、ビルド番号、アイテムを選択できます。

        [データタイプ (Data type)] として [ビルド番号] を選択した場合は、アプリケーション名、対応するパイプライン、およびビルド番号も指定する必要があります。[データタイプ (Data type)] として [作業アイテム] を選択した場合は、アプリケーションおよびプラン別に選択可能な作業アイテムのリストをフィルター処理できます。

        分岐名でビルド番号を検索することもできます。

      2. [次へ] を選択して、[データの確認] ステップを開きます。DevOps データを確認するステップ
      3. タブ間を移動して、関連するデータが正確にマッピングされていることを確認します。
        必要に応じて設定を更新します。
        • 作業アイテム
        • コミット
        • プル要求
        • テストサマリ
        • アーティファクトバージョン
        • ソフトウェア品質サマリ
        • セキュリティスキャンサマリ
      4. [送信] を選択します。
        注:
        [DevOps データ] セクションにコミットが追加されたら、[コミット] タイルに対応する [ ソースを表示 ] を選択して、パイプライン実行、分岐、リポジトリなどのコミットのソースの詳細を表示できます。
      5. オプション: 変更要求に関連付けられているデータを変更するには、[DevOps データを編集] を選択します。
        1. [関連性を選択] ステップでの DevOps データの追加元のデータタイプとその関連性を編集します。
        2. [データの確認] ステップで、この変更要求に関連付けられるか、この変更要求から削除される DevOps データを確認します。
        3. [送信] を選択します。
    9. 変更のリスクを評価するには、[リスク評価] を選択します。

      リスクが計算され、レコード情報に表示されます。

      最後に評価されたリスク値がタイムスタンプとともに表示されます。

    10. [変更タスク] セクションで [新規] を選択します。
      変更タスクの詳細については、「サービスオペレーションワークスペース での変更タスクの作成」を参照してください。
    11. オプション: 影響を受ける構成アイテム (CI) をリリースフェーズから変更要求にインポートします。
      このオプションは、変更要求が、そのリリースフェーズにマッピングされた構成アイテムを持つリリースに関連付けられた後に使用できます。
      1. [ 関連レコード] タブを選択し、[ 影響を受ける CI ] オプションを選択します。
      2. [ リリースフェーズから CI を追加] を選択します。
      3. [ はい ] を選択して、リリースフェーズから変更要求への CI の追加を確定します。
        関連するリリースのリリースフェーズから利用可能な CI が、影響を受ける CI として追加され、一覧表示されます。

        インポート操作は非同期で実行されます。操作が完了すると、通知が表示されます。リストを手動で更新して、新しく追加された CI を表示します。

    12. 変更要求が次のステータスに進む準備ができたら、[承認を要求] を選択します。
      変更要求のタイプに基づいてステータスが前に進みます。
      • 評価ステータス:通常の変更要求に対するグループレベル承認。承認レコードは、変更承認ポリシーに基づいて自動的に生成されます。提案された変更のピア レビューと技術レビューを行うことができます。
      • 承認ステータス:ビジネスステークホルダーまたは変更諮問委員会による承認が必要です。
      • スケジュール済みステータス:事前承認された標準的な変更。
      注:
      変更レコードをメールするには、コンテンツフレームで、その他のオプションアイコン ([その他のオプション] アイコン) をクリックして、[メール (Email)] を選択します。変更を要求したユーザーと、変更にアサインされたユーザーは、どちらも受信者のリストに自動的に設定されます。

      カレンダーを表示するには、変更要求フォームのタイトル バーにある [カレンダーを表示] を選択します。

    13. [保存] を選択します。