変更管理とインシデント管理の一元化でアジャイルなITを実現する「Jira Service Management」の全容

IT部門が抱える課題の抜本解消のために

新型コロナウイルス感染症（以下、コロナ）の流行というパンデミックを境に企業IT部門の業務負担は増大の一途をたどりつつある。

例えば、パンデミックの影響からリモートワークが活発化したことでクラウドサービスの新規導入が続いた。結果として、ビジネス現場の生産性は向上したものの、企業ITの構造は以前にも増して複雑化し、運用管理に要する手間は大きく膨らんでいる。

加えて、パンデミックを契機に企業のデジタルトランスフォーメーション（DX）の流れが一気に加速し、IT部門は新しいソフトウェア（プロダクト）のリリースと改善のサイクルを高回転で回していく必要にも迫られている。

このミッションを遂行することは簡単ではない。ただし、それを成し遂げることができれば、自社の事業をDXの潮流に乗せ、市場での競争力の維持・強化に結びつけることが可能になる。

例えば、自宅用のフィットネス機器とインストラクターによるオンライン指導をセットにし、サブスクリプションモデルのもとで提供している米国Peloton社は、パンデミックを境に顧客数を一気に2倍近く（94％増）に増大させた。その中で、ITチームはサービスの安定運用を実現し、同社の飛躍的な事業成長を支え続けたのである。

この成功の背景には、プロダクト強化のアイデア出しから設計、開発、運用に至る各プロセスにおいてソフトウェア開発チームとITのサポート・運用チーム（以下、ITチーム）が密接にコラボレートし、エンドツーエンドのアジリティ（俊敏性）を確保したことがあるとされている。

言うまでもなく、企業の多くは、Peloton社のようなDevOpsの体制を築けておらず、ITチームはソフトウェアのリリース／更新時の運用リスクを可能な限り引き下げようと、大がかりな検証・承認のプロセスを相当の時間をかけて踏もうとする。ところが、開発チームは自分たちの開発したプロダクトをいち早く市場に投入し、結果をつかみたいと望んでいる。そのような状況の中でプロダクトのリリース後に何らかのインシデントが発生すると、チーム全体の士気が低下することになる。

このような状況に陥ることを回避するには、ITチームがリスクを適切に管理しながら新しいプロダクトを速やかにリリースできるようにする体制と、その体制を支えるITソリューションが必要とされる。それがITサービス管理（ITSM）のソリューションであり、アトラシアンでは、ITSMツールの「Jira Service Management」を中心にしながら、ナレッジ管理の「Confluence」やインシデントコミュニケーションツールの「Statuspage」、対話型チケット管理ツールの「Halp」、さらには、IT資産管理ツールの「Insight」などによってITSMソリューションを構成し、提供している（図1）。

これらのツールを使うことで、プロダクトの変更やインシデント、チケットの背景にある文脈や各種情報を速やかに確認できるようになり、ITチームは的確で迅速な意思決定やインシデント対応が行えるようになる。

変更承認プロセスの自動化・効率化でチームメンバーの負担を低減

Jira Service Managementは、DevOpsの「CI（継続的インテグレーション）」と「CD（継続的デプロイ）」のパイプラインとの連携が可能であり、それによって変更承認プロセスを効率化することができる。

具体的には、リスクの低い変更については自動承認や自動デプロイを行い、リスクの高い変更については承認を待つ仕組みを構築することが可能となる。これによってITチームは、リスクの低い変更について逐一監査を行う無駄を排除し、リスクの高い変更に対してのみ監査や追跡をしっかりと行う機会を得ることができる。

ここで仮に、開発チームも、Jira Service Managementと同じアトラシアンの製品「Jira Software」を使用してプロジェクト管理を行っているとする。この場合、開発チームも、プロダクトの変更承認に要する手間と時間を大幅に削減することが可能になる。

例えば、開発チームがプロダクトに変更を加える場合、通常は冗長な登録フォームに必要事項を記入してレビューを待たなければならない。開発者によっては、この手間を面倒と感じて回避しようとするケースもあり、それが行われた場合、デプロイ後の運用リスクが高まることになる。

それに対して、Jira Softwareを使用すると、当該の変更に関連した各種の情報が自動的に取得され、変更リスクが自動的に判定される。これによって開発チームは、プロダクトの変更／デプロイ時に必要とされてきた多くの事務作業から解放されることになる。

また、リスク判定によって変更リスクが高いと見なされ、デプロイ前に承認が必要になった場合も、承認のためのステップが自動生成され、承認者が自動的に割り当てられる。このとき、Jira Softwareには変更の影響範囲や関連する依存関係の情報も集まっているので、承認者は変更リスクを容易に判定することができ、かつ、のちの変更計画やメンテナンス期間なども確認することができる。

さらに、この承認ステップで変更が承認されると、その後のプロセスは自動化され、CDパイプラインが承認を認識して自動的に本番環境へのデプロイを実行することになる。

容易なインシデント管理によってビジネスへの影響を低減

以上のようなかたちでソフトウェアの変更管理をしっかりと行っていても、リリース後のインシデントの発生を100％回避することはできない。そこで重要になるのが、インシデント管理の徹底となる。

ここで言うインシデント管理とは、予期せぬサービスの停止やパフォーマンスの低下といったインシデントが発生した際に、サービス（プロダクト）を再び運用可能な状態に戻すためのプロセスを指している。

ご承知のとおり、重大なインシデントの発生によってプロダクトがダウンするたびに、多大な経済的損失を被ることがある。その損失を可能な限り小さくするうえでは、インシデント管理のプロセスを明確にしておくことが大切であり、そうすることで、万が一インシデントが発生した場合でも、被害を最小限に食い止められる可能性が高まる。

そうしたインシデント管理のプロセスを効率化する機能がJira Service Managementには備えられている（図3）。

まず、Jira Service Managementを活用することで、インシデント管理の計画策定からソフトウェアのテスト、デプロイ、インシデント対応、分析といった各段階における管理の手間を可能な限り少なくすることができる。加えて、Jira Service Managementは、インシデント発生時に必要な情報を自動的に収集し、担当者の割り当てを自動化する機能も備えている。ゆえに、ITチームや開発チームのメンバーが、担当者の割り当てやインシデント対応のために自ら情報を収集する必要はなくなる。

Jira Service Managementでは、インシデントが組織全体に与えている影響を即座に把握できるよう、インシデントを引き起こしたサービスのみならず、関連サービスやIT基盤の情報を確認できるようにしてあるほか、顧客に対するインシデントの報告や顧客の最新状況の確認も簡単に行えるようになっている。

また、インシデントへの対応においては、組み込みの「インシデントコマンドセンター」機能を利用することができる。ここには、チャットツールやビデオ会議ツールが用意されており、関係者との間でインシデント対応のための意見交換も即座に行えるようになっている。さらに、インシデントへの対応時には、開発チームやITチームだけでなく、ステークホルダーにもその状況を逐一伝える必要があるが、そのための仕組みとして「ステークホルダーアラート」と呼ばれる機能も備えられている。

インシデントへの対応が完了しても、それでインシデント管理のプロセスが終了したわけではなく、チームが再び集まりインシデントのレビューを行い、次回への教訓としなければならない。その観点から、Jira Service Managementには、インシデント対応後のレビュー用テンプレートが用意されている。このテンプレートでは、インシデントの内容や関与したユーザー、応答時間や解決時間、タイムラインなどが自動的に入力され、タイミングやアクティビティのレポートも添付される。これを元に、プロダクトの改善に向けた開発チームのタスクを作成したり、のちの学習用にインシデント内容を関係者間で共有したりする作業を効率化することができる。

アトラシアンではかねてから、ITチームと開発チームが単一のプラットフォーム上で作業することで、それぞれのアジリティを高められるだけではなく、安全で、かつ信頼できるプロダクトが提供できるようになると考え、その考えを体現する製品としてJira Service ManagementとJira Softwareを提供し、革新的なテクノロジーによる機能強化を進めてきた。これらの製品を使った開発チームとITチームの一体化によって、安全、かつハイスピードでのプロダクトのリリースと改善が可能になると確信している。