JIRA Service Deskを導入してみた

リクルートライフスタイルでAtlassian, Githubなどの開発者ツールの管理をしている梶原成親です。　Atlassian User Group TokyoのOrganizerもさせて頂いております。

社内でJIRA Service Deskを使い始めて、気づいた点をレポートさせていただきます。

# JIRAを使って作業依頼を受付する際の面倒なところ
Service Deskを利用する前から、JIRAで作業を受付しておりましたが、以下の問題がありました。

[Redmineの様に新規に依頼を起こすときにテンプレートを読み込む機能](https://oichinote.com/plus/2013/12/template-for-chicket-of-redmine.html)が無く、JIRAをカスタマイズせずに使ってる場合、依頼する側のリテラシーに頼る場面が多く発生します。場合によっては、作業依頼に必要な情報が足りず、確認が必要になり、依頼者と２，３往復確認作業をやりとりするなど、よくある話です。

そういった事を防ぐために、JIRA側をカスタマイズするのですが、作業に必要な事項などを定義すればするほど、JIRAのカスタマイズが多く発生し、管理者側の負担が増していました。

- 作業内容と同じ分だけの課題タイプの作成が必要（課題集計などで）
- 作業内容と同じ分だけの画面の設定が必要
- Issue作成時の必須項目を定義する分だけの作業内容が必要

と、いった形で、結構頭痛い内容です。

会社全体の作業依頼をJIRAで受付するとなると、その分だけの画面スキームやカスタムフィールドを調べる必要があります。

その負担を少しでも軽減するために、JIRA Service Deskを使う前は、以下のJIRA機能（Atlassian非推奨になっています。）と、Confluence側にJavaScriptsで作った依頼フォームを組み合わせて、依頼フォームを作っておりました。
この方法だと、最低限のカスタムフィールドを準備しておけば、管理者側でカスタマイズしなくても、ユーザ側でカスタマイズすることで依頼フォームを作成できました。

- [Creating Issues via direct HTML links - JIRA Knowledge Base - Atlassian Documentation](https://confluence.atlassian.com/display/JIRAKB/Creating+Issues+via+direct+HTML+links)


入力して欲しい項目や、必須項目や、初期値の設定など、JavaScripts側で持たすことができました。

ただこのやり方だと、

- ユーザ側でJavaScriptsを組むことが前提なので、バックオフィス系部署が対応出来ない。
- 依頼フォームを変えたい時にJavaScriptsを組む工数が無い。などといった問題も発生します。
- JIRAバージョンアップ時にケアすべき項目が増える

などと言った問題もあります。

# JIRA Service Deskの良いところ　（以下、JSD）
管理者視点で以下の点が良いと思いました。

## カスタムフィールドのデフォルト値を設定することができる。

この事によって、"申請タイプ”等の集計に使っているカスタムフィールドに確実な値を設定する事ができるようになります。　その他にはComponents設定等で担当者を割り振りをW/Fを使って制御している時に、常に正しいコンポーネントを選択することができるようになりました。

![このフィールドを非表示にするには値を事前設定してください_-_RLS_JIRA.png](https://qiita-image-store.s3.amazonaws.com/0/45733/7eee609e-032f-9e24-7ee1-963845490911.png)


## JIRAのカスタムフィールドと、依頼者が見ているフィールド名を変えることができる。

この事によって、文言が少し違うだけでのカスタムフィールド作成する回数が減らすことができるようになりました。

![スクリーンショット_2015-12-20_17_00_25_1.png](https://qiita-image-store.s3.amazonaws.com/0/45733/356fabca-6abf-7da3-a02e-17db1bfb3ef5.png)


## 入力して欲しい項目を定義することができる。

以前は各依頼毎に画面を作成しておりました。不要なカスタムフィールドがあると、入力者が混乱する事があるので極力不要なカスタムフィールドが残らないようにしておりました。

JSD側の設定で依頼に必要な項目を定義し表出しておく。　JIRA側の設定はJIRAプロジェクトに対してすべてのカスタムフィールドが入ってる画面をひとつ準備しておけば良い形になりました。

![JSD.png](https://qiita-image-store.s3.amazonaws.com/0/45733/22522e97-40e9-c80e-2b3a-591548bfac27.png)
![フィールドの追加_-_RLS_JIRA.png](https://qiita-image-store.s3.amazonaws.com/0/45733/24aae4f6-d4c0-f5a4-615f-cc3553c88be5.png)



## 必須 or オプションを設定できるが、Field Configuration設定とは分離して管理できる。

JSD側のフォーム設定で、必須、オプションを選ぶことができます。この設定はJIRA側のField Configurationと分離しているので、Field Configurationが増える事無くJSD側で完結できるので助かります。

## チケット管理を自動化することができる
以前のバージョンまでは自動化するには、JIRA Admin側でサーバに設定ファイルを配置するなどで実装可能でしたが、JSDではIFTTTと似たような設定をすることが可能です。

* [Automating your service desk - Atlassian Documentation](https://confluence.atlassian.com/servicedeskcloud/automating-your-service-desk-732528900.html)

私達のProjectでは、以下のような自動化設定を実施しております。　運用を効率的にするために設定しました。
アイディアや運用ルール次第でもっと効率的な方法があるかと思います。
![貼り付けた画像_2015_12_20_17_20.png](https://qiita-image-store.s3.amazonaws.com/0/45733/6faad3e2-1098-cf5d-ac1b-71ac6d4da667.png)






![R-Atlassianユーザサポート_-_RLS_JIRA.png](https://qiita-image-store.s3.amazonaws.com/0/45733/20be5d98-9a90-0151-d3bb-04e3059e8d9e.png)




# JSD導入してよかったこと

## 依頼したいけど、どこからどうやったらよいか分からないが減った。

下記は私のプロジェクトですが、解決策を検索するから検索するこができます。 依頼がJSDが集まればすべての作業依頼はここから検索すれば済むようになります。

![R-Atlassian_-_依頼ポータル_-_サービスデスク.png](https://qiita-image-store.s3.amazonaws.com/0/45733/ade1efb1-40d9-e191-948e-2bcb5166355c.png)




## 依頼時の内容の抜け漏れが減った

ヒアリング項目を定義し、依頼に必要な項目に絞られシンプルになったことで、間違いが減った様に思います。
また、依頼方法のヘルプをリンクすることができるので、ユーザ側で「依頼時に何を書けばよいか分からない。」が減りました。

*実際の依頼フォーム*
![R-Atlassianアカウント依頼_-_R-Atlassian_-_依頼ポータル_-_サービスデスク.png](https://qiita-image-store.s3.amazonaws.com/0/45733/5fd90472-5d30-8b9a-24d7-cab936e9fe08.png)



*その申請ヘルプ*
![R-Atlassian申請ヘルプ_-_R-Atlassianアカウント申請_-_R-Atlassian_サポート_-_RLS_Confluence.png](https://qiita-image-store.s3.amazonaws.com/0/45733/68b1df4a-16a9-cea3-47db-76c7919e07e1.png)



# JSDの困った仕様

## Permission設定
JSDで上げた依頼は依頼者とチームしか閲覧できません。　閲覧者を増やすにはリクエスト参加者にメンバーを追加する必要があります。
これでは、過去の依頼履歴や類似依頼が利用者間でシェアできないです。
また、利用者は依頼受け付けしているJIRAプロジェクトも閲覧する事ができなくなるので、運用チームの動きが見えなくなってしまい、Open化することができなくなります。
これはAtlassian側に改修依頼が幾つかでてるそうです。

皆さんの参考になれば幸いです！

ーーーーー
また、このような情報交換をAtlassian User Groupを定期的に実施しております。　ノウハウ交換やネットワーキングに是非活用ください。
**[Atlassian User Group Tokyo](http://augj.connpass.com)**

梶原成親 @kajinari