
JSM Chatのテスト環境構築~動作検証(Halpとの差異確認)~
クララ、コーポレートITエンジニア(情シス)の山崎です。
本エントリーは、Atlassian User Community Tokyoのアドベントカレンダー2022の21日目の記事の関連エントリーとなります。
ヘルプデスク業務におけるチケット管理に関して、Slack上で運用できるツール「Halp」と連携する形で、メインのチケット管理にはJSM(Jira Service Management)を利用しています。
今年に入り、Halpに変わる新しい仕組みとして、「JSM Chat」がJSMの標準機能として追加提供されましたので、テスト環境を用意して、動作検証を行いましたので、そちらのご紹介となります。
※ 各画面キャプションの文字が英語表記になっていますが、各サービスのプロファイルの言語設定を日本語にした場合は、画面表示も日本語になります。個人的な習慣として、英語に慣れるために言語設定を英語にしているため、ご了承ください。
この記事の目次
テスト環境構築
検証用のJSMプロジェクトを作成
契約テナントにて、テスト用のSandbox環境にアクセスして、JSM(Jira Service Management)の新規プロジェクトを作成します。
プロジェクトの新規作成より、「サービス管理」を選んで、一般的な「ITサービス管理」のテンプレートを利用して、JSMのプロジェクトの新設。
適当なプロジェクトキー「JSMCHAT」を設定して、プロジェクトを作成。
JSMの新しいプロジェクトの作成が完了し、初期設定のリクエストタイプがそのまま使えそうでしたので、コレを利用して検証を進めます。
JSM「Chat」が管理メニューに追加されていました!
検証用のSlackチャンネルを作成
JSMと連携するSlackチャンネルは、2つ必要です。
1つは、ユーザーが問い合わせを行うリクエストチャンネル #tmp_test_jsm_chat_request を作成します。(チャンネル名は任意です)
もう1つは、問い合わせの応対をするメンバー(エージェント)が利用するトリアージチャンネル #tmp_test_jsm_chat_triage を作成します。
JSMとSlackの連携設定
JSM側の設定
JSMのChatの設定画面にて、Sign in with Slack
を実行
JSMからSlackの接続性が確保できると設定画面は以下のように変化して、次に、Slackと連携するJSMプロジェクト内のリクエストタイプを選択します。
今回の検証では、タイプ別、承認の有無で動作確認をしたいため、以下のリクエストタイプを選択しました。
- 課題タイプが「依頼」の
Get IT help
- 承認ステータスが含まれる「依頼」の
New mobile device
- 課題タイプ「インシデント」の
Report a system problem
Report a system problem
に含まれるカスタムフィールド(追加項目)の1つが連携サポート対象外と警告が出ていますが、検証ですので、そのまま処理を続行します。
連携する先のSlackチャンネルはすでに前段で作成してありますので、このままOKで先に進めます。
すると、Slack側でAssistボットからメッセージを送ったので、そちらからセットアップを続けるように案内メッセージが表示されますが、再度OKで一度、JSM側での設定を完了とします。
Slack側の設定
JSMとの中継を担うAssistボットより、DMが届いており、そこには、「トリアージ用に作成したプライベートチャンネルからAssistボットを追加して指示に従うように」と書かれていました。
トリアージチャンネル #tmp_test_jsm_chat_triage にて、@Assistでボットを招待
招待をすると早速、どの用途のチャンネルで利用するか選択させるボタンが表示されましたのでTriage channel
をクリックします。
さらに、どの「キュー」=「JSMのプロジェクト」と連携するか選択肢が出てきましたので、新設したJSMのプロジェクトを選択します。
「キュー」は、Halpを利用する場合にも出てきますが、仕様(仕組み)を理解する上で重要な概念になります。ただ、JSM Chatのココの設定個所で唐突に出てきましたので、若干違和感はありますが、捉え方としては、JSMのプロジェクトと、Slackのチャンネルを関連付けする中間・仲介するレイヤー(概念)と考えると良いと思います
また、新設したJSMのプロジェクトの選択肢以外に、Create a new queue
という選択肢があるのは、少々気になりますが、無視してよい選択肢と思われますので、ココではスルーします。
設定が完了すると、以下のように、続けて、リクエストチャンネルでも同様の操作をするように案内メッセージが出てきましたので、リクエストチャンネル #tmp_test_jsm_chat_request に移動して同様の設定を行います。
なお、問い合わせに応答するエージェントのメンバーをトリアージチャンネルに招待するといった付随操作も必要ですが、動作検証時には必要ありませんので、今回は割愛します。
設定が完了すると、トリアージチャンネルとの連携ができた旨の案内メッセージが表示されます。
再度、JSM側の状態確認
JSM側のJSM Chatの設定画面をリロード、あるいは、画面内のOKをクリックすると連携したSlackチャンネルの情報が表示されます。
他のタブを見てみますと… 連携しているリクエストタイプの一覧を見ることができます。
詳細な設定については、ドキュメントを参照してください。今回は、割愛します。
絵文字の設定では、初期設置として以下が設定されています。
- 「
:ticket:
」の絵文字によるスタンプでJSMのチケットを起票するアクション - 「
:eyes:
」の絵文字によるスタンプにより、チケットの担当者の引き取りのアクション
Add shortcut
より、絵文字によるアクションの追加が可能で、アクションを実行する絵文字スタンプの選択した後に、設定できることは以下の2点となります。
- トランジションの実行(ステータスの変更)
- 特定のフィールドの設定値の変更
今後、このあたりは実際の運用の中でカスタマイズをしていきたいと思います。
最小限のテスト環境の構築は以上となります。
動作検証
検証項目
日頃、HalpによるJSMとの連携で行っている操作が、同じようにJSM Chatの場合でも機能するかを確認します。
確認項目は、以下
-
複数のリクエストタイプから任意のタイプを選択して、Slackフォームからチケット作成できるか?
-
任意のカスタムフィールドがあっても、Slackフォームに反映されるか?
-
公開コメント、内部コメントの制御はできるか?
= トリアージ側での:mega:
絵文字を利用した公開コメントができるか? -
DMからチケットを作成できるか?
-
DMから作成したチケットに対して、トリアージから公開コメントを記入できるか?
-
リクエストポータルやJSMプロジェクト側で作成されたチケットがトリアージに反映されるか?
- [おまけ] 承認が必要なチケットをSlack上で承認できるか?
検証結果
細かな検証過程は省きまして、結論を書きますと「7」の承認以外は全て想定通りに操作ができました。
弊社の現在の運用であれば、HalpからJSM Chatに置き換えたとしても問題なく利用継続できると評価しています。
検証時の気づき
自動のチケット作成(Slackフォーム表示)の追加設定
リクエストチャンネルにメッセージを投稿した際に、自動的にチケットが作成されるようにするためには、JSM側の追加設定が必要で、以下のように、対象のリクエストチャンネルの設定編集にて、自動起票を有効化する必要がありました。
自動起票が有効な場合、メッセージを投稿すると Raise request
というボタンが出現し、そちらを実行すると作成するチケットのリクエストタイプを選択する画面が表示され、選択したタイプに応じたSlackフォームに遷移します。
Slackで承認するための追加設定
チケットに承認工程がある場合に、その承認のアクションをSlack上から実行できるとありましたが、そのためには、JSM側で追加の設定が必要です。
承認に関しては、こちらの設定を行ってもSlack側、Assistボットを通じて、認証の通知や、認証のアクションを取ることができませんでした。
Slack のチャット設定を管理する | Jira Service Management Cloud | アトラシアン サポート
既定では、チャットでのリクエストの承認は有効になっています。つまり、承認が必要なリクエストがあった場合、承認者は Assist からメッセージを受け取り、Slack から直接対応することができます。Jira Service Management での承認の詳細をご確認ください。
既定ではSlack上での承認が有効とありますが、今回の動作検証時は、既定が「無効」になっていましたので、何か設定の不備などがあるかもしれません。
本件につきましては、別途、調査をして問題解消したいと思います。
後記
以上で、動作確認の検証は終わりとなりますが、検証結果にも書きました通り、HalpをJSM Chatに置き換えたとしても、Halpの時と同様の操作ができましたので、JSM Chatへの移行については、全く問題ないと評価しています。
Halpの導入や運用の様子、JSM Chatへの移行検討につきましては、以下のエントリーにまとめていますので、あわせて、ご参照ください。