Jira Service ManagementとSlackの連携をJira AutomationとGASを使って色々自動化

こんにちは。PITチームの田中です。相変わらず卓球しに出社してます(仕事もしてますよ!)。みんな入社当初は球に当てるのもおぼつかない感じなのですが、徐々に成長しつつある日を境に限界突破して急に強くなるんですよね。スポーツに限らず仕事にも通じるところかなと思います。

さて、前回の記事に引き続き、Jira Service Management(以下、「JSM」とします。)のお話です。前回のお話とPITチームの説明はこちらをご確認くださいませ。

JSMはAtlassian社のIT Service Management ツールで、当社ではIT Service Desk、HR Service Desk、Legal Service Deskとして使用し、日々のリクエストの管理・対応を行っております。

前回は、従業員からのリクエスト時にリクエストの承認者へSlackのメンション通知を行う方法についてご紹介しました。

今回は、Jira AutomationとGoogle Apps Script(以下、「GAS」とします。)を用いて、IT Service Desk の運用フローを効率化したことについてご紹介します。

コミュニケーションがSlack主体の会社での不都合

当社では大きく3つのHUBが存在しますが、私は勝手に、Service Hub、Information Hub、Colaboration Hub(まとめてSIC-Hub)とそれぞれ呼称してます。

当社では、Colaboration HubとしてSlackを主体的に使用しているため、サービスデスクを導入後、以下の問題が発生しました。

  • Slackのスレッドでコミュニケーションすることが大半なため、JSMからの通知やメッセージに気づかない。

  • 各種Atlassianサービスを利用していると大量の通知メールがくるため埋もれて気づきにくい(他の重要なメールに気づきにくくなるため、Atlassianからの通知メールを自動的にアーカイブ行きに設定しているユーザーもいる)。

  • Slack主体のコミュニケーションだと、サービスデスク上のステータス変更等のアクションがSlackに反映されないことからSlack上で同アクションに関するやり取りが発生して2度手間


改善案

上記を解消するための簡単な改善案としては、SlackのJira Cloudアプリを使用することです。また、有料のHalpを使用してもよいかと思います。

一方で、当社では

  • 各サービスデスクごとにSlack Botに対する要望が異なる。

  • SlackのJira Cloudアプリで通知されるチケットのリンクについて、サービスデスクエージェントしかアクセスできないURLのため、Slackのチャンネルに通知→申請者がリンクをクリック→ライセンスを持っていないためアクセスリクエストがJSMに通知→却下という対応が悪循環的に発生

  • 現段階では有料のHalpを入れる程ではない。

  • 自分たちに合わせた調整やカスタマイズをしたい。

といった当時の経緯から、Jira AutomationとGASを使用して解決することにしました。SlackのJira CloudアプリやHalpは、Slackを起点としてなるべくSlack上でチケット操作を完結する思想ですが、本件は、サービスデスクを起点としつつSlackでのコミュニケーションと両立することを思想としております。


導入によってもたらされた効果

下記にIT Service Deskの例をご紹介しますが、各種サービスデスクとSlackがシームレスにつながったことで、Slack主体のコミュニケーションを崩さないまま、サービスデスク上の運用もできるようになったことが1番の効果かなと感じています。

IT Service Deskの例

今回は、IT Service Deskで行った改善についてご紹介したいと思います。

下図は、当社でJira Cloudアプリを使用した際の課題です。改善事項としては、下図の課題に基づきJira Service Managementの操作がSlackに自動連携されることを重視しつつ、EX(従業員体験)の良さを考慮しました。


実装例


【リクエスト時の動作】

①リクエスト

 ユーザーは、Jiraのカスタマポータルからリクエストするか、Slackのチャンネル上でメッセージリクエストします。Slackからのメッセージリクエストの場合は、IT Service DeskチームがJira Cloudアプリを使用して起票します。

②起票通知

 起票されると、Jira AutomationとSlack のWebhookを使用して、自動でIT Service Desk用のチャンネルに起票されたことを通知します。また、承認者が設定されている場合は承認者もメンションするようにしたり、Slackから起票した場合は、元々のスレッド情報もこの起票通知用のスレッドに連携します。

このスレッドが、IT Service Deskチームとユーザーがやり取りする場となります。

③スレッド情報をスプレッドシートへ登録

 ②を起点として、Slackのイベントサブスクリプションを使用し、自動でスプレッドシートにスレッド情報(課題キーやタイムスタンプ等)を転記します。スプレッドシートをDBのように使用します。

④JSM上の操作をSlackのスレッドへ通知

 ステータスの変更やリクエストを他のユーザーへ共有すると、Jira AutomationとWebhookを使用してGASに情報を送り、GASは受取った情報とスプレッドシートを照合し、ステータスの変更やリクエスト共有されたことを、リクエスト時に通知された。Slackのスレッドに対して通知します。

この方式での運用して良かったこと

  • ユーザーにメンションが届くようになったのでSlackのスレッドを追いやすくなりました。

  • ステータスの変更が即座にスレッドに通知されるため、ユーザーとしては進捗の確認が分かりやすくなるとともに、IT Service Deskチームとしてもステータス更新の漏れが減りました(ステータス更新を忘れると、変なタイミングでスレッドに通知されることになるため)。

  • Jira Cloudアプリで運用していたころは、IT Service Deskチーム用のリンクがスレッドに通知されたため、ユーザーがこのリンクにアクセス⇒権限が無いのでJSMのアクセス権限がリクエストされる⇒IT Service Deskチームでこのリクエストを却下という悪循環があったのですが、カスタマーポータル用のリンクを通知することで解消されました。

  • ステータスが完了になると自動的に完了を示す絵文字を始めのスレッドに付けることにより、チャンネル上で一目でチケット未完了のリクエストを判別できるようになりました。

  • IT Service Desk用のSlackチャンネルがパブリックチャンネルである一方、カスタマーポータル内のやり取りはリクエストしたユーザー、IT Service Deskチーム及び共有したユーザーに限られることから、コミュニケーションはSlackで行いつつID/PW等オープンにすべきでない情報はカスタマーポータル内で行うことにより、機密区分に応じた対応ができるようになりました。

今後の展望

リクエスト対応の点においてはサービスデスクとSlackの連携は上手くいきましたので、次は、リクエスト管理の点として、チケット対応状況や定期リマインダーをサービスデスクチームにSlackで適時通知する仕組みを整備できればと思います。

本記事の実装についてご興味ある方

私自身は非エンジニアのためコードを掲載できる程うまく書けませんので省略しておりますが、実装にご興味ある方はお気軽にご連絡くださいませ。いわゆる車輪の再発明は時間がもったいないです。日本の情報システム部門全体のレベルが上がるよう、協力できるところは協力しあいましょう。

最後に

おかげさまで、当社は昨年12月に上場しまして、新たなステージを向かうフェーズとなり、PITとしてもこれに対応していくため、自動化/効率化やEX向上を進めていくコーポレートエンジニア及びコーポレートとプロジェクト/プロダクトの横断的なセキュリティ整備を行うセキュリティエンジニアを募集しております!


この記事が気に入ったらサポートをしてみませんか?