予想されること: 変更のサンプル ライフサイクル
変更リクエストの表示方法と、変更管理ワークフローでどのように進行するかを示す例を次に示します。これは、プロジェクトに加える変更について理解するのに役立ちます。
ソフトウェア アップグレードのリクエスト – Jira Software
この例では、Jira Service Management のアセットとして存在する Jira Software インスタンスのソフトウェア アップグレードのリクエストを示しています。
| 実行すること | Jira における表示 |
|---|---|
アセット機能におけるアセットの表示 アセット機能で対象の Jira インスタンス (アセット) を見てみましょう。これはかなり古いバージョンなので、新機能、セキュリティ アップデート、その他のすべてのバグ修正を入手するためにアップグレードしたいと考えています。 最新の LTS リリース 8.13 にアップグレードするための変更リクエストを開きます。 |
|
ここで重要なのは、変更リクエストの動作に影響するアセットのいくつかのフィールドです。
|
|
変更リクエストの作成 変更リクエストを開いて、この Jira インスタンスを影響を受けるオブジェクトとして選択します。 |
|
変更を説明するフィールドに入力します。
|
|
| 今回は、プランの新しいフィールドを空にしておきます。誰が記入するかは、企業のプロセスによって異なります。通常は変更依頼者ですが、後でチーム全体を含めるようにしましょう。 |
|
変更リクエストのアセットを表示する 変更リクエストが作成されると、Jira インスタンスの詳細がリクエストに取り込まれます。自分自身を含む興味のある全ユーザーが表示できます。 ここに何が表示されるかを細かく設定できます。 |
|
| ...またはクリックして、詳細と依存関係を表示します。 |
|
| 変更リクエストはアセット機能でも対象の Jira インスタンスにリンクされています。このインスタンスを担当するシステム管理者には、すぐにアラートが届きます。 |
|
自動化ルールの効果を表示 便利な機能は他にもあります。自動化ルールでは、Jira は次のことを自動で実行します。
これは、承認者が変更を承認する際に必要な手順を踏むのに役立ちます。たとえば、日付を週末に移動して、この Jira インスタンスを使用するチームがスムーズに作業できるようにします。 |
|
どんな手順を踏んだのか 新しい自動化ルールを Jira Service Management に追加しました。ここでは次を使用しました。
|
|
| この場合、通常の変更はすべてのワークフロー ステップと承認を通過する必要があるため、自動化ルールは変更リクエストにそれほど影響しません。通常、プロセスは確立されていませんが、緊急事態ではないためこれらを確認する時間があります。 |
|
しかし、緊急事態においては話が変わります。自動化では緊急時の変更はいくつかのステップを省略できるので、何人ものユーザーに許可を求める必要なく、すぐに実装できます。 緊急時にはこうした対応が必要になります。 |
|
変更の計画 変更リクエストが計画段階にトランジションすると、チーム全体が集まって必要なすべての情報を収集できます。
手順をしっかり把握したうえで、必要な場合はロールバックできるように準備します。 |
|
変更カレンダーで変更日を確認する プロジェクトにおけるすべての変更を包括的に把握し、変更日がフリーズと保守の時間枠に対して適しているかどうかを評価します。
|
|
アセットの所有者による変更の承認 計画の準備ができたら、変更リクエストを承認ステップにトランジションして、そこで最初のレビューを受けられます。通常、これは変更マネージャー (Jira ユーザー ピッカー カスタム フィールドから取得) と、この Jira インスタンスの責任者、つまり適切なタイミングで適切な人物によって行われます。 |
|
通常は誰が変更マネージャーなのかを把握しているでしょうが、アセットの所有者と同数のアセット所有者を持てます。Jira はアセットとの関係に基づいて承認者として自動で割り当てるため、そのユーザーが誰であるかは把握不要です。 ソフトウェアやサーバーが異なると、所有者も異なります。また、アセットがそれほど重要でない場合は、所有者を持たない可能性もあります。 |
|
どんな手順を踏んだのか アセット オブジェクトに関連する承認者を使用しました。常に固定のユーザー グループであるとは限りません。変更リクエストで選択したアセットに基づいて変更されます。 Jira は次のことを行います。
|
|
リスクの評価: CAB レビュー 最初のレビューの後、変更は次の承認ステップに移されます。通常の変更にはプロセスが確立されていないため、適切に評価することをお勧めします。 ここでは、変更によるリスクを軽減して問題を回避するために、追加の専門家を含められる CAB (変更諮問委員会) によって評価されています。 |
|
変更の実装 変更が承認されたら、実装を開始できます。ここでは、すべてのチームが通知を受け取っており、このインスタンスをすぐにアップグレードできるとします。 |
|
オプション: オブジェクトのステータスを変更する この Jira インスタンスで何が起こっているのか疑問に思っているユーザーのために、作業を開始するとステータスが変更されるトリガーを利用できます。
これは、ワークフローに追加されたアセット事後操作によって実行できます。この場合、変更リクエストが特定のトランジションによって移動されると、オブジェクトの属性が変更されます。 これは変更管理の一部ではありません。使用する場合は、「Jira のワークフローにアセット機能を追加する」を参照してください。 |
|
変更を完了して閉じる Jira をアップグレードして作業が完了したら、変更を完了してすべてが再び緑色になっていることを確認します。 変更リクエストを閉じるときに、解決状況として [変更成功] または [変更失敗] を選択できます。 |
|
次のステップ 変更が完了すると、アセットとそれらに影響を与えた変更に関するアセット レポートも表示できます。 |
|
たとえば、アセットに対して発生した問題の数 (インシデント、問題、または変更の数) を確認できます。 この数が多すぎる場合は、新しいアセットの購入を検討する時期なのかもしれません。 |
|
準備できましたか?
変更に対してこのフローを使用する場合は「1. 変更管理ワークフローを更新する」をご参照のうえ、作業を開始してください。