Jira Service Management における変更管理の仕組み
概要
変更管理 (変更の有効化とも呼ばれる) は、IT サービスのリスクや中断を最小限に抑えながら重要なシステムとサービスを変更できるように設計されている、サービス管理プラクティスです。変更とは、サービスに直接または間接に影響を与える可能性のあるものを追加、変更、削除することです。
変更の一般的なタイプ:
標準変更: リスクが低く、頻繁に実行され、文書化されたプロセスに従う事前承認済みの変更。たとえば、メモリやストレージの追加などです。
通常変更: 新しいコンテンツ管理システムへのアップグレードなど、CAB (変更諮問委員会) による追加レビューと承認を必要とする非緊急の変更。
緊急変更: 予期しないエラーや脅威から生じる変更で、直ちに対処する必要があります。セキュリティ パッチの実装やメジャー インシデントの解決などの例があります。
アトラシアンのプラットフォームは、コラボレーティブで統合されたツールセットによって、従来の変更管理プロセスから最新の変更管理プラクティスへの移行をサポートいたします。IT とソフトウェアの開発に 1 つのプラットフォームを使用することで、ITSM と DevOps のギャップを埋めることができます。これは、あなたのチームがリスクを管理し、コンプライアンスを維持しながら、ソフトウェアの提供をスピードアップするのに役立ちます。
Jira Service Management では直感的なサービス デスクと、リスク評価と承認ルーティングの自動化によって、簡単に変更を取り入れられます。サービス構成管理によって変更による下流への影響を軽減して、サービスとインフラストラクチャ間の依存関係をより明確に把握できます。
Jira Service Management を Bitbucket、Jenkins、GitHub などの CI/CD ツールと統合することで、ワークフローをさらに合理化します。コードがデプロイされると、変更リクエストが作成されてリスクが自動で評価されます。必要に応じて、追加レビューのために変更にフラグを付けられます。
Confluence を利用して、部門横断型の計画、変更計画のテンプレート、ピア レビューを行います。これにより、正式な CAB プロセスへの依存度が低くなり、関連するチームがコラボレーションし、共有の信頼できる情報源によって可視性を得られるようになります。
最後に、Jira Service Management の変更リクエストを Jira Software に直接リンクして可視化し、関連作業を追跡します。
変更管理プロセス
機敏でベロシティの高いチームの場合、変更管理プロセスは、時間のかかるレビューや技術以外の関係者の承認から離れつつあります。その代わりに、IT チームと開発チーム間の自動化された協調的なプロセスにシフトしています。これにより、リスクを軽減しながらアジャイルが向上します。
一般的な変更管理プロセスの概要は次のとおりです。
変更リクエスト: 誰かが変更をリクエストし、可能性があるリスク、予想される実装、影響を受けるシステムに関するメモを含めます。
変更リクエストのレビュー: 変更マネージャーまたはピア レビュアーが変更リクエストを評価します。成功する可能性はどれくらいありますか? リスクとリターンは正確ですか? 変更する価値はありますか?
変更計画: チームは変更のゲーム プランを作成します。期待される成果、リソース、タイムライン、テスト要件、必要に応じて変更をロールバックする方法を文書化します。
変更の承認: 適切な変更マネージャー、ピア レビュアー、または CAB の関係者が計画をレビューして変更を承認します。
変更の実装: 開発チームは変更をリリースして、その過程で手順と結果を文書化します。
変更のクローズ: 変更マネージャーは適切なタイミングで変更をレビューし、適切な場合は変更をクローズします。レポートには、変更が成功したかどうか、タイミングは適切だったか、見積もりは正確だったか、予算内だったかなどを説明する必要があります。
開発チームと IT 部門が協力して Jira Service Management で変更を管理する方法について詳しく知りたい方は、このウェビナーをご確認ください。
Jira Service Management で変更管理を開始する方法
ネイティブの変更管理ワークフローを使用する
Jira Service Management の IT サービス プロジェクト テンプレートには、変更管理ワークフローが組み込まれています。このワークフローによって、変更リクエストを記録、評価、承認、実装できます。プロジェクト テンプレートに組み込まれている既定のワークフローから始め、ビジネス ニーズに合わせて調整することをお勧めします。
初期設定では、変更リクエストのエージェント ビューにはいくつかのフィールドが含まれます。これらのフィールドは、変更の課題タイプを基にして作成されます。必要に応じて、カスタム フィールドを追加することもできます。
強制承認を設定する
初期設定では、すべてのエージェントまたは管理者は、レビュー ステージを通じて課題をトランジションする権限があります。ただし、変更課題がワークフローを進む前に、1 人以上の特定のチーム メンバーによるレビューを義務付けることで、承認を強制できます。Jira Service Management では、個々のユーザーとユーザー グループの両方からの承認をサポートしています。
リクエストの承認を要求するには、適切なフィールドが利用できることを確認する必要があります。次に、関連するワークフロー ステータスに承認ステップを追加する必要があります。
既定の個人/グループの承認フィールドを使用するか、承認者を入力するためのフィールドを作成する
ワークフロー ステータスに承認ステップを追加する
標準変更の自動承認
IT サービス管理プロジェクト テンプレートには変更リクエストを事前承認する自動化ルールが組み込まれており、変更タイプは標準に設定されています。
このルールは、自動化設定で無効化したり、調整したりできます。
サービス プロジェクトのサイドバーで [プロジェクト設定] > [自動化] の順に選択する
標準的な変更リクエストの自動承認という名前のルールを編集する
変更カレンダーで変更をスケジュールする
Jira Service Management の変更カレンダーによって、あなたのチームは計画された変更を 1 つの統一された変更カレンダーで予定し、表示できます。今後の変更を明確に可視化することで、あなたのチームがリスクを軽減し、変更管理プロセスを合理化できます。
カレンダーを確認するには、左側のナビゲーションから [変更カレンダー] を選択します。ここでは、次の操作を行うことができます。
予定されている変更リクエストの概要を日、週、または月別に表示する
今後の変更の要約を日付別にリスト形式で確認する
カレンダーで時刻を選択して、新しい変更リクエストを作成する
既存の変更リクエストの詳細を表示または編集する
サービス プロジェクト、ステータス、担当者、影響を受けるサービス、緊急度レベル、影響、または変更タイプ別に、カレンダーの変更リクエストをフィルタリングする
変更管理のベスト プラクティスとヒント
標準変更を新しい常識にする
多くの IT チームにとって、変更の大部分は "通常変更" と見なされ、変更の開始、計画、承認に長いリード タイムが必要です。
関連する通常変更を特定して標準の変更パスに移動することで、変更のバックログを縮小することを検討しましょう。最も一般的な変更をレビューすることで、チームは標準の変更パスによって事前承認および自動化できる通常変更を特定できます。
これにより、大多数の変更リクエストをスピードアップし、残りの通常変更に対する改善を優先する時間を作れるようになります。
セルフサービス ポータルで変更リクエストの取り込みを合理化する
Jira Service Management には、堅牢なセルフサービス フォームが用意されています。変更リクエストを取り込むために、これらのフォームを便利な方法として使用できます。
この例では、事前承認済みの保守の更新や、追加の計画とレビューが必要な本番システムのアップグレードなど、IT スタッフはさまざまな変更リクエストのタイプから簡単に選択できます。
自動化されたリスク モデルを変更に採用する
あなたのチームが変更のリスクを適切に評価するために必要な情報を確実に入手できるように、リクエスト フォームの質問を設定しましょう。Jira Service Management の自動化を使用すると、リスク レベルを自動的に計算し、変更リクエストに適切なリスク値を設定できます。
また、自動化を利用して次の操作も実行できます。
変更リクエストを「標準」、「通常」、または「緊急」に分類するか、サービス階層および依存関係に基づいて分類する
標準変更の事前承認や、リスクの高い通常変更の追加ワークフローなど、変更リクエストを適切なワークフロー パスに転送する
追加レビューが必要な、リスクの高い変更について、割り当てられた関係者に通知する
CI/CD ツールから変更リクエストを自動的に作成する
Jira Service Management を Bitbucket Pipelines、GitHub、Octopus、Jenkins、CircleCI などの CI/CD ツールと統合することで、開発チームが既存のワークフローから離れることなく変更管理プロセスを合理化できます。変更は Jira Service Management に自動で登録され、リクエストされた変更の完全監査証跡が作成されます。
デプロイ管理により、Jira Service Management は、影響を受けるサービス、変更リスク スコア、変更承認者など、CI/CD ツールから直接取得した関連情報を変更リクエストに自動でプルします。変更マネージャーは、変更の承認や追加レビューのリクエストに必要なすべてのコンテキストを保持します。また、開発者は CI/CD ツールから直接リクエストの進捗状況を追跡できます。
CI/CD ツールからのデプロイのゲーティング
さらに一歩進んで、Bitbucket Pipelines、GitHub、Jenkins などの CI/CD ツールにデプロイのゲーティングを設定しましょう。デプロイのゲーティングを設定することで、機密な環境へのデプロイを自動的に一時停止し、Jira Service Management で変更が承認されたらすぐにデプロイを再開することができます。
設定が完了すると、開発者は CI/CD ツールを離れることなくリクエストの進捗を追跡できます。承認された場合、デプロイを完了するためにそれ以上の措置を講じる必要はありません。変更が却下された場合は、Jira Service Management の変更リクエストをフォローアップして、承認者からのメモやフィードバックを確認できます。
複雑な変更をより小さな作業単位に分割する
複雑な変更をより小さな作業単位に分割すると、チームは小さな変更をより簡単に制御し、変更プロセスにおいて変更をより迅速に移行させ、リスク レベルを下げることができます。Confluence によって、IT、スタッフ、関係者は連携し、複雑な作業に取り組むことができます。チームとして変更ドキュメントを作成し、ピア レビューとフィードバックを行い、変更が実施されるまでリアルタイムで反復作業を行うことができます。
次の例では、チームが大きな変更を小さなタスクと事前変更に分割しています。Confluence ページから直接 Jira 課題、ストーリー、タスク、変更を作成し、変更リクエストへのリンクを追加することで、簡単に追跡できます。Confluence によって、チームはリアルタイムのコラボレーションを実行可能な作業に簡単に変えることができます。
変更メトリックと KPI で学習を加速させる
変更を測定してそこから学ぶために、Jira Service Management ではカスタム ダッシュボードを構築して共有する機能と併せて、すぐに使用できるレポートが用意されています。Jira Service Management を信頼できる情報源として利用して、変更、インシデント、サービス、コード全体のデータをまとめられます。
変更の有効化のパフォーマンスを測定する場合は、次のような学習と改善を向上させる指標に注目します。
変更は適切なタイミングと効果的な方法で実現されていますか?
サービスの変更による影響は?
変更に関連するガバナンスとコンプライアンスの要件を満たしていますか?
