“あらゆるチームの潜在能力を解き放つ”　アトラシアンが刷新したITSMソリューションで企業デジタル化の再創造に取り組む

DXを進めるための3つのポイント

皆川宜宏氏（以下、皆川）：みなさまこんにちは。アトラシアンでソリューションエンジニアを務めている皆川です。私からはITSMの再創造、「ITSM Re-imagined」ということでお話しします。

これまで多くのみなさまに愛用されてきたJira Service Deskに、この度Opsgenieが同梱され、Jira Service Managementとして生まれ変わりました。このJira Service Managementを中核として、ITSMの再創造をどのように実現するか、高速かつ革新的なデジタルを駆使した企業となるための変革をどう支援するのか、刷新されたアトラシアンのITSMソリューションについて、私からお話ししたいと思います。

さて現在、IT部門は自社のデジタルトランスフォーメーションのイニシアチブを支援するために、大きなプレッシャーにさらされています。

みなさまも次の3つのポイントを、さまざまなバージョンで、よく耳にしているかもしれません。1つ目は、迅速なサービスの提供。IT部門はビジネスにリスクをもたらすことなく、デジタル製品やサービスの迅速な提供を支援する必要があります。そして、そのサービスが常に稼働していること。業務への深刻な影響を避けるために、クリティカルなビジネスアプリケーションとサービスを、常に確実に稼働させる必要があります。そして、シームレスなサポートの提供。従業員とお客さま、その双方に完璧なサービス体験を提供する必要があります。

しかし、このような目標を達成することは、簡単ではありません。これは、IT部門による業務の支援方法が根本的に変わってきているためです。まず、ITチームは業務要件を満たすために、これまでよりもはるかに動的なインフラストラクチャーが必要だと認識しています。多くの企業が、より動的になった業務要件やコストの削減要件を支援するために、アプリケーションやサービスを、ファイアウォールの背後からクラウドに移行させています。

次に、製品やサービスを素早く提供しつつ、ビジネスの変更や障害に即座に対応するニーズを満たすため、ITサポートや運用チームがアジャイル方式に則り、エンジニアリングチームとさらに綿密に連携する必要があります。北米とヨーロッパでは、インフラストラクチャーの意思決定者の68パーセントが、自身の組織でDevOpsイニシアチブを実装しているか、実装済み、あるいは拡張やアップグレードを行っている段階であると報告されています。

Gartnerによる興味深い予測があります。組織内の他部門でアジャイル方式の採用が増えていることを受け、アジャイルな方式での作業を採用していないITSMチームの80パーセントが、今後無視または回避されると予想しています。これを受け、さまざまな企業がインフラストラクチャーと運用チームの組織方法を見直しています。開発、運用チームとの連携を密なものにするか、開発またはエンジニアリングチームを、ITSMおよびIT運用チームに組み込むということが多いようです。

そして、もう1つ着目すべき点として、顧客による期待、お客さまからの期待がどんどん上がり続けています。シンプル、かつ私生活で慣れているコンシューマレベルのサービス体験が業務でも期待されています。

さらにリモートワークの広まりによって、世界はニューノーマルにシフトしており、企業は新しい作業方法を模索することを強いられています。

従業員が行き詰ったときに、誰かのデスクに立ち寄り、ちょっと相談するようなことができなくなってきました。お客さまについても同様です。お客さまと、やり取りを行う方法も変わってきました。ITチームは、内部および外部のお客さま、顧客に対してどのようにサービスを提供・運用し、そしてサポートするのかを再定義する必要が出てきています。

しかし、多くのお客さまから既存のツールが制約になっているという話を聞いています。既存のツールによって、新しいビジネス要件の柔軟な導入が妨げられるという話です。このようなツールが知識のサイロ化につながり、エキスパート、つまり専門家がお休みを取ってしまうと、いきなり業務が止まってしまうことを促しています。

サイロ化された、あるいは日本で特に目にする属人化されたツールと業務プロセスが、開発、ITおよびビジネスチーム間にギャップをもたらしています。このようなチームは、ビジネスの変更に対応できず、問題を素早く解決するための必要なコンテキスト情報を十分に得ることができません。

あらゆるチームの潜在能力を解き放つ

アトラシアンのミッションは「あらゆるチームの潜在能力を解き放つ」ことです。そしてそれは、開発チームのみならず、すべてのチームの潜在能力を解き放つことに向かっています。「アジャイル」という用語、これはソフトウェア開発のチームから始まったものですが、それが今では大きく組織の在り方として適用されてきています。それには、チームによる作業の計画や追跡の支援が必要です。

続く、DevOpsソリューションは、開発者やSREチームがコードをリリースに向けて進めることを支援しています。これに、さらに続くかたちとして、アトラシアンではインフラストラクチャーおよび運用チーム、サポートチーム向けに、デプロイメント後の機能を備えたITサービス管理ソリューションを充実させています。

Jira Service Managementは、チームのためのITSMを支援する、チームのためのサービス管理プラットフォームです。チームとプラクティスを1つの環境に集約し、自社の作業方法に合わせて最適化できます。

Jira Service Managementには、さまざまな活用例が考えられます。星が付いているのは、Jira Service Managementが特に焦点を当てている分野です。

これまで説明したように、Jira Service ManagementをITSMツールとして使用し、既存の高価なツールを置き換えながら、IT部門と開発部門の間のコラボレーションが改善できます。またJira Service Managementは、社内のエンジニアリング部門をサポートするためにも使用できます。

Jira Service Managementを使用して、社内からのフィードバックや報告を整理しつつ、実際の作業を行うJira Softwareを連携させることで、リクエストと対応する作業を直感的に管理できます。もちろん、社内の施設（ファシリティ）、あるいは人事、法務などについてのリクエスト、これらの状況を改善する、いわゆるエンタープライズサービス管理にも使用できます。

ソリューションは非常に簡単に拡張できるため、1つの部門から他部門への展開をすぐに行えます。他にもカスタマーサポート、テクノロジービジネス管理としての使用が考えられています。

Jira Service Managementの3つの柱

さてJira Service Managementは、次の3つの柱を掲げています。1つ目が価値を素早く提供、2つ目は作業の可視化、3つ目は流れるDevOpsです。順番に見ていきます。まずは、価値を素早く提供するために実装されている機能です。

Jira Service Managementでは、予め用意されたテンプレートを活用してIT、人事、マーケティング、財務、法務など、あらゆる部門が、簡単にサービスチームとしての運用を開始できます。チームはサービスの提供方法に合わせて、フィールド、ワークフローおよびプロセスを簡単に柔軟にカスタマイズできます。

そして作業の可視化。コラボレーションや作業が簡単に行えることで、チームを横断する作業の視認性を改善しています。オープンなコラボレーションを促進するプラットフォームは、素早く効果的な意思決定に役立つ、十分なコンテキストをもつリッチな情報を提供します。例えばJira Service Managementでは、インシデントマネージャーが障害に対応して、それを素早く解決するために、よりリッチなコンテキスト情報を活用できます。

影響を受けるサービスを素早く表示し、このインシデントに関連するすべてのリクエストを確認できます。さらに、このインシデントの根本の原因を確認するために、より詳細な情報も確認できます。

最後に、開発チームとIT運用チームが、変更を本番環境に素早く適用し、真の高速チームとして機能するために役立つ機能です。Jira Service Managementは、Jiraプラットフォーム上に構築されています。これにより、開発チームとITチームが共同で作業を行うための、シームレスな連携が実現されます。ここからコラボレーションや作業を加速できます。

例えば、一般的なCI/CDツールと、Jira Service Managementの間に、綿密な連携機能を構築し、低リスクの変更については素早く自動承認やデプロイを行います。一方、高リスクの変更については承認を待つようにします。これによって、開発チームの障壁を取り除くとともに、IT運用チームは、コンプライアンスやリスクの面でもクリティカルな変更のデプロイを完全に管理下に置くことができます。さらに、監査して追跡する機会を提供します。すべて、Jira Service Managementひとつで実現可能です。

Jira Service Managementを利用するお客さまは、ビジネス的な価値を導入初日から体験いただけます。従来のITSMからの切り替えで、平均して246パーセントのROIを実現します。高価な導入費用や使わない機能への投資から、純粋なライセンスコストのお支払いで済みます。

また、価値提供速度が改善されます。使いやすい製品、すでにJiraに慣れ親しんだチームが使うことにより、実装までの時間を平均で2ヶ月に短縮できました。最後に、ユーザーやエージェントは開発サポートおよび運用チームを横断して連携させる、柔軟かつ直感的なワークフローを通じ、生産性を向上させることができました。

新しいITSMのかたちを実現する製品

それでは、新しいITSMのかたちを実現する具体的な製品を紹介いたします。Jira Service Managementを中核として、Opsgenie、Statuspage、Confluence、Halp、Insightなどの製品群との連携で実現します。

アトラシアンは高速なチームを解き放つためのITSMを設計しました。開発、ITおよび業務部門をシームレスにつなぐサービスエクスペリエンスの提供、運用そしてサポートを支援します。では順に見ていきましょう。

まずはJira Service ManagementとConfluenceの組み合わせで実現する、セルフ解決型のサービスデスクです。ITチームのサービスデスクだけではなくて、非ITチームを含む、あらゆるチームが素早くセットアップできるようESM（エンタープライズサービス管理）テンプレートを組み込んで提供しています。

これらのテンプレートは、チームが自身のサービスデスクをセットアップするための時間や労力をなるべく軽減できるように設計されており、利用や運用を開始するためのキットを提供します。テンプレートは使いやすく、チームの要件に合わせて簡単に変更できます。

加えてアトラシアンでは、機械学習機能やスマート機能をサービス管理全体に含めることに取り組んでいます。2021年の後半には、次のような場合に役立つ新機能の提供を予定しています。リクエストまたはチケットの転送先を正確に予測する、受信したリクエストを適切なチームに転送できるように正確に分類する、メンションあるいは共有先をユーザーに提案する、などです。

実際に、サービス管理の画面をご覧ください。カスタマーが見るポータル画面になります。こちらのヘルプセンターのトップ画面では、それぞれのプロジェクトが表示されています。そして、この上部の検索バーで検索を行うことができます。

Confluenceをナレッジベースとして連携していると、検索した単語にもとづいて関係するナレッジ記事も提案されます。こちらのナレッジ記事でユーザーが自己解決できれば、それがベストなシナリオになります。

一方、ユーザーが引き続きリクエストを行いたい場合、こちらのカテゴリからリクエストタイプを選んでいきます。

選んだリクエストのフォームに内容を入力します。代理起票なんかも選べます。項目に入力すると、ここでもナレッジの記事が提案されていますね。2段構えの仕組みの提案です。必要な項目を記入したら、リクエストを送信し、完了となります。

では、エージェントの画面を見てみましょう。こちらがエージェント側の画面です。先ほどリクエストされたチケットのステータスを確認していきます。SLAなんかも見えていますね。こちらは担当者の割り当てとともに、SLAと、ワークフローも見ることができます。

このとおり、ワークフローのカスタマイズが可能になっています。そして、ユーザーとのコミュニケーションはコメント経由で行います。エージェント間あるいは社内のチームとのコミュニケーションも、必要な場合があります。その場合は、内部メモを使用します。専門のグループ宛てにメンションし、全員に通知もできます。こんな感じでお客さま、それから社内のメンバーとコミュニケーションが取れます。

リクエストの対応が完了したら、チケットを解決します。これが、一連の流れです。

例えば、今回の解決・対応内容を新たなナレッジとして記事に加えたい場合には、ここでナレッジベースの＋記号を押します。テンプレートを選んで記事の構成や粒度を揃えつつ、ナレッジが蓄積できます。

具体的には、Confluenceでナレッジベースに新しく1ページを作成しているかたちです。このように、エージェントが素早くナレッジを増やすこともできます。

対話型サービスデスク「Halp」

続いて、「Halp」による対話型サービスデスクの実現を考えてみようと思います。これまでご案内したとおり、弊社では会話形式のチケット対応を実現するための「Halp」という企業を買収しました。この「Halp」をJira Service Managementに統合する予定です。これにより従業員は、SlackまたはMicrosoft Teamsの任意のコラボレーションツールから簡単に支援を依頼し、サービスを受けることができるようになります。

リクエストは、解決に向けた支援を行う適切なエージェントおよびチームに転送され、返信はSlackおよびTeams内で従業員に素早く届きます。これまでにないシームレスなサービス体験になると思います。

画面左側のオレンジがエージェントで、チケット対応をする側です。そしてリクエストする側は、右側に表示されています。ここで、社内従業員であるリクエスターがSlackのメッセージを記入します。

「（パソコンの）調子が悪いです」ということで、このメッセージに対して、チケットの絵文字を付けます。（絵文字を）ポチッと押すと、Jira Service Management側でサービスリクエストチケットが作成され、Slackに表示されます。ここで引き続き、このチケットの通知にリクエスターがコメントをします。

すると、エージェント側でもリクエストが起票された時点で通知が表示されるので、エージェントが返信をします。エージェントからの返信ももちろん、Slack上でリクエストしたお客さまが確認できます。すでにサービスリクエストのチケットが作成されているので、私が対応し、解決します。チケットのクローズ作業もSlackから行えます。

ここで確認していただきたいことは、このサービスチケットにすでにJiraのチケット番号が付いている点です。これは、SlackがHalpと連携し、さらにHalpがJira Service Managementと連携することで実現されています。

Jiraでエージェント画面を見てみると、このとおり、カスタマーおよびエージェントからのコメントが入っています。今回はすべてSlack上でやりとりを行いましたが、例えば、リクエストを上げる側はSlack上で、エージェント側はすべてJiraで対応することも、もちろん可能です。

ですので、Jira側で入力されたコメントも、リクエスター側のチャットのスレッドに全部表示されます。以上、SlackやTeamsなどのチャット形式での、シームレスなサービスチケット化を見てもらいました。

その他の新機能

そして近日中に、Mindville Insightの機能をJira Service Management Premiumに含めることを予定しています。Mindvilleは、非常に柔軟なデータモデルを提供するため、ユーザーは、IT部門の外部である人事部門や財務部門を含むビジネス全体を横断して、すべてのアセットやインフラストラクチャーを簡単に追跡し、それらの情報を保管できます。

また、Mindvilleの新機能にも取り組んでいます。変更管理におけるCMDBの立ち位置については、みなさんご存知かもしれませんが、クリティカルなサービスが依存するインフラストラクチャーについての重要な情報を取得できるため、変更管理者は重要性の高い特定のサービス、いわゆるインフラストラクチャーへの変更による影響が限定できます。画面では、その例として請求サービスが表示されています。

そして次に、Opsgenieによるインシデントスワーミングです。インシデント報告から重大なインシデント作成、担当者へのオンコール、そして、インシデントスワーミングまでの一連の流れがシームレスに実現できます。

ユーザーから報告を受けてインシデントが発覚するというようなケースを想定してみましょう。こちらはJira Service Managementのポータル画面です。こちらからシステムの問題をレポートするリクエストを起票します。問題の要約と、詳細説明を記入し、ここで影響を受けるサービスというのを影響範囲として指定します。起票ができましたので、エージェント側の画面に移ってみようと思います。

こちらになります。エージェント側の画面を確認してみると、ご覧のとおり、また影響の度合い、範囲が記載されています。こちらは対応を開始して自分を担当者として割り当ててみます。ここで、今回のユーザー報告は重大なインシデントだったと判断したとします。

上部のボタンより、重大なインシデント（メジャーインシデント）を作成しましょう。こちらでも影響を受けるサービスと、優先度等を記入していきます。ここで重大なインシデントを作成すると、このJira側の先ほどレポートを受けたインシデントに対して重大なインシデントがリンクされます。

こちらの重大なインシデントは、Opsgenieのインシデント画面と連携しています。ここでオンコールが発動したような感じになります。そして、Opsgenieのこのインシデント画面には、インシデント対応に役立ついろいろな機能が付いています。1つがこのSlackチャンネルの作成ですね。インシデントが発生する度に専用のSlackチャンネルを作り、ここで関係者と対応を進めていくような特有のチャンネルを作成できます。

そしてもう1つは、ICC（Incident Command Center）です。こちらはOpsgenieの中の組み込みのWeb会議で、Zoomとの連携も可能です。即座にこの会議を開始して関係者を招聘してインシデント対応にあたります。すぐにWeb会議を開くことができるので、インシデントに関するタイムラインを見ながら、関係者と一斉に取り組む「インシデントスワーミング」を実施できます。

インシデントの中には、タイムラインという項目で、インシデント発生からどのような対応を行ったのか、一連の流れを自動で記録することができます。さらにJiraとの連携機能です。インシデントの対応中であったり、あるいはインシデントの対応後に、何らかのタスクが発生する場合が多いかなと思います。これらをJiraの課題としてインシデントに紐づけ、トレーサビリティを高めることが可能になっています。

インシデントが解決したら、振り返りの時間が必要になるかと思います。Postmortemといわれますが、Opsgenieでは、このPostmortemの機能もデフォルトで入っています。あらかじめテンプレートが組み込まれていて、インシデントの解決までのメトリクスも添付されています。

対応までの時間や、諸々のメトリクスが収集・計測されて、自動的にこのPostmortemのレポートに添付されます。そしてPostmortemの画面でも、先ほど見ていただいたJiraの連携機能にアクセスできます。フォローアップタスクがある場合は、特定のJiraのプロジェクトに紐づけて新たなタスクをチケットとして起票します。

そして振り返りのレポートを公開して、さらにConfluenceにエクスポートすることも可能です。Confluenceをナレッジのハブとして活用するという意味で、Postmortemの内容も共有することを想定しています。いろいろなチームが他のチームでのインシデントのPostmortemを見られる意味というのは、かなり大きく、ITサービスマネジメントが今後発展する中で、この共有はかなり大事なポイントになると考えられます。

次に、変更管理についてです。DevOpsプラクティスを採用するエンタープライズ企業の数は増えつつありますが、これらの中には、特に変更管理においてDevOpsとITSMの組み合わせが困難になっている企業もあります。アトラシアンでは近々、CIツール連携を通じて、この領域に取り組むことを予定しています。

このような連携により、CIツールがJira Service Managementに自動的に変更リクエストを作成するので、開発チームがかなり解放されます。同時にIT運用チームは、デプロイされる変更の完全な監査を行うことができ、私はこの追えるという点が非常に大事だと考えています。これらがすべて、Jira Service Managementの中で行われます。

そして今お見せしている画面というのが、変更管理機能として追加予定の新機能の一部です。開発部門と運用部門が変更を追跡する、統合されたカレンダーを提供します。

こちらがデプロイゲートと呼ばれる、先ほどご案内した機能になります。実際に見てみましょう。今見ていただいているのがBitbucketのパイプライン機能になります。本番環境へのデプロイを実行するところになります。「デプロイ」をクリックすると、今回のデプロイに含まれるコミット、プルリクエスト、それからJiraの課題などが確認できます。

変更のリクエストをすると、元の画面に戻りますが、デプロイの実行が一時停止されている状態です。

また、Jira Service ManagementのチケットIDというのも、すでに表示されていました。なので、このJira Service Managementの画面に行くと、チケットが作られています。

デプロイの承認依頼をするために、このBitbucketのデプロイの画面からJira Service Managementにチケットが作られました。

この詳細を見てみると、このとおり、あらかじめ設定した承認権限のあるグループからの承認が必要なことがわかります。変更のインパクトや緊急性などを確認して設定し、問題がなければ、承認します。

Jira Service Managementで承認されると、Bitbucket Pipelineでのデプロイが可能になっています。

再度デプロイを実行すると、デプロイが可能になっているので実行されます。Jira Service Management側では、デプロイが始まるとステータスがImplementingになります。実施中ということです。そしてデプロイが完了すると、Completedに変更されます。このように、Bitbucket Pipelineも、追跡可能になっています。