34
33

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

AtlassianAdvent Calendar 2015

Day 18

JIRA Service Deskを導入してみた

Last updated at Posted at 2015-12-20

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

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

JIRAを使って作業依頼を受付する際の面倒なところ

Service Deskを利用する前から、JIRAで作業を受付しておりましたが、以下の問題がありました。

Redmineの様に新規に依頼を起こすときにテンプレートを読み込む機能が無く、JIRAをカスタマイズせずに使ってる場合、依頼する側のリテラシーに頼る場面が多く発生します。場合によっては、作業依頼に必要な情報が足りず、確認が必要になり、依頼者と2,3往復確認作業をやりとりするなど、よくある話です。

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

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

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

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

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

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

ただこのやり方だと、

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

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

JIRA Service Deskの良いところ (以下、JSD)

管理者視点で以下の点が良いと思いました。

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

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

このフィールドを非表示にするには値を事前設定してください_-_RLS_JIRA.png

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

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

スクリーンショット_2015-12-20_17_00_25_1.png

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

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

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

JSD.png
フィールドの追加_-_RLS_JIRA.png

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

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

チケット管理を自動化することができる

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

私達のProjectでは、以下のような自動化設定を実施しております。 運用を効率的にするために設定しました。
アイディアや運用ルール次第でもっと効率的な方法があるかと思います。
貼り付けた画像_2015_12_20_17_20.png

R-Atlassianユーザサポート_-_RLS_JIRA.png

JSD導入してよかったこと

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

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

R-Atlassian_-依頼ポータル-_サービスデスク.png

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

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

実際の依頼フォーム
R-Atlassianアカウント依頼_-R-Atlassian-依頼ポータル-_サービスデスク.png

その申請ヘルプ
R-Atlassian申請ヘルプ_-R-Atlassianアカウント申請-R-Atlassian_サポート-_RLS_Confluence.png

JSDの困った仕様

Permission設定

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

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

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

梶原成親 @kajinari

34
33
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
34
33

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?