MicroAd Developers Blog

マイクロアドのエンジニアブログです。インフラ、開発、分析について発信していきます。

チーム管理対象サービスプロジェクトの導入と比較 (Cloud 版 Jira Service Management)

f:id:cemaimai:20210708173830p:plain

はじめに

こんにちは、株式会社マイクロアドの IT 戦略グループでアーキテクトをしている米田(まいた)です。社内で Atlassian 製品の管理やスタッフトレーニングを行いながら、Atlassian 製品を活用したワークフロー整備やサポート業務管理、情報共有を推進しています。一般的には「コーポレートエンジニア」と呼ばれる職種です。

以前、「Cloud 版 Jira Service Desk の導入と社内ワークフローの整理」*1というタイトルでブログを投稿しました。 developers.microad.co.jp

前回のブログ執筆時点では Jira Service Management (以下、JSM) は企業管理対象 (旧称「クラシック」*2 ) サービスプロジェクトのみ利用可能でしたが、その後、チーム管理対象 (旧称「次世代」*3 ) サービスプロジェクトも利用可能になりました。

今回は前回のブログの続編ということで、下記について書きたいと思います。

  • 企業管理対象とチーム管理対象のサービスプロジェクトの違い
  • チーム管理対象サービスプロジェクトを利用して実現したこと

マイクロアドでの利用状況

マイクロアドでのライセンスなどの利用状況についてです。 Jira Software も利用していますが、詳細は今回は割愛します。

マイクロアドではクラウド版を利用することで、管理者がサーバー管理や製品のバージョンアップなどの保守・運用から解放され、製品の構成設計や管理・運用に注力できています。 また、クラウド版は新機能の追加などの対応がオンプレ版に比べて早いです。

Jira Service Management Cloud

  • Standard プランで利用
  • 総エージェント数 35人程度 (ライセンス必要) *4
  • 総カスタマー数 270人程度 (ライセンス不要) *5

Confluence Cloud

  • Standard プランで利用
  • 社内専用(匿名アクセス無し)と社外向け(匿名アクセス有り)の2つのインスタンスで利用
  • JSM 向けの用途としてはナレッジベース用のスペースを作成し、JSM のプロジェクトにリンクして利用

Jira Service Management について

企業管理対象とチーム管理対象のサービスプロジェクトについて詳しく書く前に、Jira Service Management について説明したいと思います。

カスタマーポータルは専用URLから

Jira Service Management の概要
Jira Service Management の概要

Jira Service Management の特徴として、エージェントは Jira Software と同様に Jira の画面でプロジェクトを構成したり、リクエストへの対応を行ったりしますが、カスタマーは専用の URL からカスタマーポータルにアクセスし、ナレッジベースを参照したり、リクエストを提出したりして利用します。

オープン/非公開設定でアクセス制御

また、サービスプロジェクトは「オープン」か「非公開」に設定できますので、「非公開」に設定し、アクセスさせたいカスタマーのアカウントを追加することでアクセス制限が可能です。「オープン」に設定した場合は、そのカスタマーポータルにアクセスできるすべてのカスタマーアカウントが利用可能になります。

サービスプロジェクトのオープン/非公開設定
サービスプロジェクトのオープン/非公開設定

自動化を利用して作業を効率化

Jira Software 同様、JSM でも自動化が利用できます。 マイクロアドでは以下のような自動化を JSM のサービスプロジェクトに設定しています。

  • カスタムフィールドの値に応じた担当者のアサイン
  • 別のチケット生成とリンク
  • 指定日数経過後に内部コメントの追加やステータスの変更
  • 毎日指定した時刻に指定した JQL *6 で返されたすべての課題に対して内部コメントを追加

自動化については、Atlassian 様のサイトで自動化テンプレートが公開されていますので、ご興味がある方はこちらをご参照ください。 www.atlassian.com

ナレッジベースで情報提供と自己解決の促進

Confluence のスペースを JSM のプロジェクトにリンクしてナレッジベースに設定することで、カスタマーは Confluence のライセンスが無くてもポータルサイトからこのスペース内のページを閲覧することが可能になります。 問い合わせの多い内容はナレッジベースに記事を作成して公開することで、カスタマーの自己解決を促進するとともに、問い合わせ件数削減によるエージェントの負荷軽減にも繋がります。

企業管理対象とチーム管理対象のサービスプロジェクトの違い

企業管理対象とチーム管理対象のサービスプロジェクトそれぞれの特徴を簡潔にまとめると、下記のように言えるのではないかと思います。

企業管理対象サービスプロジェクト Jira 管理者による高度なセットアップと構成が可能
チーム管理対象サービスプロジェクト プロジェクトメンバーがスピーディーにセットアップと構成が可能

機能比較

下表は Atlassian サポートの「Jira Service Management のチーム管理対象プロジェクトとは | Jira Service Management Cloud | Atlassian サポート」という記事から引用した「機能の一覧と比較」の表になります。

企業管理対象サービスプロジェクト チーム管理対象サービスプロジェクト
高度なセットアップと構成 簡単にセットアップできる、再設計された機能
クラシックなルック アンド フィール 新しいルック アンド フィール
Jira の高度なユーザーに最適 新しい機能の定期的な追加
高度な構成 素早く簡単にセットアップ
Jira 管理者が管理 プロジェクト メンバーが管理
詳細な権限 シンプルな権限
高度なワークフロー エディタ 使いやすいワークフロー エディタ
アセット管理 アセット管理
言語サポート 言語サポート
承認 承認
エージェント通知 エージェント通知 近日公開予定
カスタマー トランジション カスタマー トランジション 近日公開予定

チーム管理対象サービスプロジェクトは「他のプロジェクトと共用できるワークフローやカスタムフィールドの追加や管理」といった高度な構成ができない分、プロジェクトメンバーが自分たちで構成することが可能です。また、一部の機能は「近日公開予定」となっていますので、将来的には利用できるようになると思われます。

また同じ記事からの引用になりますが、チーム管理対象サービスプロジェクトの選択が推奨されているのは

  • チームで作業を素早く開始するために簡単なプロジェクト構成を利用したい場合
  • 組織内で互いに独立したプロジェクトが必要な場合
  • プロジェクト テンプレートを使用したい ESM (Enterprise Service Management) チームの場合

とあり、企業管理対象サービスプロジェクトの選択が推奨されているのは

  • チーム全体で一貫したワークフローが必要な場合
  • チーム管理対象サービスプロジェクトでは利用できない機能が企業管理対象サービスプロジェクトにある場合
  • IT サービス管理テンプレートを使用したい場合

とのことです。

実際に利用した私個人の感想を簡単にまとめると、下記のようになります。

チーム管理対象サービスプロジェクトの利用メリット

  • プロジェクトメンバーがカスタムフィールドやワークフローを構成・管理できる
  • 上記により Jira 管理者の管理コストが削減できる
  • プロジェクトメンバーが運用状況に合わせて既存のリクエストタイプを改修したり、新規に追加できる

チーム管理対象サービスプロジェクトの利用デメリット

  • カスタムフィールドが 1 プロジェクトで最大 50 フィールドまでという上限がある
    • ただし、上限が無いと闇雲にカスタムフィールドを追加して利用するメンバーがいそうなので、制限は必要だと思う
  • カスタマーがリクエスト画面でトランジションを実行できない
    • 企業管理対象では可能であり、チーム管理対象では「近日公開予定」とのことなので期待
  • 添付ファイルフィールドが必須にできない
  • 企業管理対象サービスプロジェクトでは利用できる特定のシステムフィールドが存在しない
    • そのシステムフィールドを使ってチーム管理対象サービスプロジェクト内のリクエストを検索できない

管理者がしっかりと管理・構成する必要がある場合は企業管理対象サービスプロジェクトを選択し、プロジェクトメンバーが中心となってスピーディーに管理・構成したい場合はチーム管理対象サービスプロジェクトを選択すると良いかなと思います。

実際の設定例

チーム管理対象サービスプロジェクトでの実際の設定例をいくつか紹介したいと思います。

カスタムフィールドの追加方法

チーム管理対象サービスプロジェクトではプロジェクト管理者がカスタムフィールドを追加することが可能です。 リクエストタイプの設定画面の「フィールドを作成」に表示されているアイコンから作成したいものをクリックし、必要な情報を設定するだけで利用できるようになります。このカスタムフィールドはこのプロジェクト内の他のリクエストタイプでも利用可能です。 リクエストタイプも「リクエストタイプを追加」をクリックするだけで、新しいリクエストタイプを追加することが可能です。

カスタムフィールドとリクエストタイプの追加
カスタムフィールドとリクエストタイプの追加

ワークフローの設定方法

チーム管理対象サービスプロジェクトではプロジェクト管理者がワークフローを追加することが可能です。 チーム管理対象サービスプロジェクトでリクエストタイプを作成すると、そのリクエストタイプにはデフォルトのワークフローが設定されています。 このワークフローはリクエストタイプ設定画面の「ワークフローの編集」をクリックすることで確認・編集が可能です。

ワークフローの編集
ワークフローの編集

表示されたワークフローはマウス操作で簡単に編集が可能です。

ワークフロー編集画面
ワークフロー編集画面

ワークフローへの承認処理の追加も簡単で、承認処理を追加したいステータスをクリックし、右側に表示される「承認」の「+」をクリックすると設定することができます。

承認処理の設定
承認処理の設定

作成したワークフローは他のリクエストタイプでも利用することが可能で、他のリクエストタイプに設定したい場合は、編集画面右上の「…」をクリックし、「他のリクエスト タイプにコピー」を選択することで、同じサービスプロジェクト内の他のリクエストタイプにこのワークフローを設定することが可能です。

ワークフローのコピー
ワークフローのコピー

チーム管理対象サービスプロジェクトを利用して実現したこと

マイクロアドでは企業管理対象/チーム管理対象の両方のサービスプロジェクトを利用していますが、実際にチーム管理対象サービスプロジェクトを利用して実現したことを紹介したいと思います。

結論

マイクロアドではビジネスチームで自社プロダクトの社内スタッフ向けヘルプ業務とナレッジベースの提供を行っていますが、このヘルプ業務に JSM を導入したことで、下記のことが実現できました。

  • 問い合わせ窓口の一元化
  • ヘルプ窓口と同一環境でのナレッジベース提供
  • 業務の可視化
  • メンバー間での情報共有
  • ノウハウの蓄積

そして、特にチーム管理対象サービスプロジェクトを利用したことで、下記のことが実現できました。

  • メンバーによるサービスプロジェクトの構成・管理・運用
  • Jira 管理者の作業・管理コストの削減

以下、詳細を順に説明していきます。

管理者として感じていたこと

冒頭でも述べましたが、私は社内で Atlassian 製品の管理やスタッフトレーニングを行いながら、Atlassian 製品を活用したワークフロー整備やサポート業務管理、情報共有を推進しています。

前回のブログ執筆時点では、IT戦略グループや法務グループへの導入が完了し、社内での利用者数や認知度が増え、他の部署から JSM という製品に関する問い合わせや、JSM を利用した業務改善に関する問い合わせ・具体的な相談が届き始めていました。

当時、JSM の社内利用が進み、業務改善や可視化が進んでいく喜びを感じるとともに、今後、企業管理対象のサービスプロジェクトを複数構成していく場合、「プロジェクト数が増加していくと管理者(自分自身)が作成・変更・管理しなければならないワークフローやカスタムフィールドなどが増え、管理者の対応の遅れがサービスの低下を招いてしまう」というリスクも感じていました。

ディレクターとビジネスチームの問い合わせ窓口の運用開始

法務グループのサービスプロジェクト運用開始後、システム開発本部のディレクターユニットから「ビジネスチームとの問い合わせ窓口として JSM を利用したい」という相談があり、企業管理対象サービスプロジェクトを利用してこの問い合わせ窓口を構成し、運用を開始しました。ちなみに、この時点では「チーム管理対象サービスプロジェクト」の提供は開始されていませんでした。

ビジネスチームのメンバーは既に法務サービスデスクを利用していましたが、ディレクターへの問い合わせでこの窓口を利用するようになり、JSM に慣れていきました。

また、一部のビジネスチームメンバーは Jira Software も利用しており、コラボレーター*7としてこの窓口の Jira 側画面も利用していました。

ビジネスチームでの課題

その頃、ビジネスチームでは自社プロダクトの社内スタッフ向けヘルプ業務とナレッジベースの提供に関して、下記のような課題を抱えていました。

ナレッジベースの提供に関して

  • 既存のスタッフ向けナレッジベースを提供しているサービスには不安がある
  • 急な仕様変更でいままでできたことができなくなったり、将来的にサービスが継続するか不安

ヘルプ業務に関して

  • プロダクトによって運用方法がバラバラ
    • メールベースでの問い合わせと対応
    • Google フォームやスプレッドシートでの問い合わせと対応
    • チャットでの問い合わせと対応
    • 他の有料サービスを利用した問い合わせと対応
  • 問い合わせ管理や業務の可視化、メンバー間での情報共有が十分にできていない

ビジネスチームからの要望

こういった状況の下、ビジネスチームから自社プロダクト「UNIVERSE Ads」に関する以下のような相談がありました。

  • スタッフ向けナレッジベースを構成したい
  • スタッフ向けヘルプの提供を開始したい

また、要望として、以下が挙げられていました。

  • マイクロアドスタッフであれば誰でも利用できるナレッジベースであること
  • ヘルプ業務は JSM を利用して運用すること
  • JSM のプロジェクト管理は可能な限りプロジェクトメンバーが行えること

チーム管理対象サービスプロジェクト利用の提案

この時期、チーム管理対象のサービスプロジェクトが利用可能になっており、私は動作や機能の検証を行っていました。チーム管理対象サービスプロジェクトは企業管理対象サービスプロジェクトと比較すると利用できない機能がありましたが、徐々に機能追加されているという背景もあり、ビジネスチームの課題を解消し、要望を満たした形でナレッジベースとヘルプ業務環境を構成する方法として、下記を提案しました。

  • プロジェクトメンバーが自分たちで構成できる「チーム管理対象サービスプロジェクト」を利用する
  • Confluence に専用スペースを作成し、このプロジェクトにナレッジベースとしてリンクする

設計・構成とトレーニング

上記の提案をビジネスチームに賛同して頂き、以下の流れで構成を進め、運用を開始しました。

  1. 仕様設計 (プロジェクトチーム+管理者)
    • リクエストタイプとカスタムフィールドの設計
    • ワークフローの設計
    • その他、自動化などの必要な設定のリストアップ
  2. サービスプロジェクトの初期設定 (管理者)
    • チーム管理対象サービスプロジェクトでプロジェクトを作成
    • プロジェクトメンバーに必要なロールを付与 (「Administrator」や「Agent」)
    • ナレッジベースも必要であれば Confluence に専用のスペースを作成し、このプロジェクトとリンク
  3. トレーニング (管理者⇨プロジェクトの「Administrator」)
    • プロジェクトの設定方法や操作方法などをトレーニング
  4. プロジェクト設定 (プロジェクトの「Administrator」+管理者)
    • 必要なリクエストフォームやワークフローを仕様に基づいて構成
    • その他、自動化などの必要な設定を仕様に基づいて構成
    • わからない部分は管理者がサポート
  5. ナレッジベース作成 (プロジェクトメンバーで Confluence ライセンス所有者)
    • ナレッジベースとして必要な記事を作成
  6. トレーニング (管理者またはプロジェクトの「Administrator」⇨プロジェクトの「Agent」)
    • 管理者またはプロジェクトの「Administrator」からプロジェクトの「Agent」に操作方法をトレーニング

結論で先に述べましたが、チーム管理対象サービスプロジェクトを利用したことで、下記のことが実現できました。

  • メンバー自身によるサービスプロジェクトの構成・管理・運用
  • 上記により、管理者の作業・管理コストの削減

以上、マイクロアドでチーム管理対象サービスプロジェクトを利用して実現したことを紹介させて頂きました。

マイクロアドのカスタマーポータルには複数のサービスデスクとナレッジベースが集合していてますので、カスタマーはこのポータルサイト1箇所にアクセスするだけで複数のサービスに関して「情報の収集」や「リクエストの提出・管理」が可能になり、作業時間の削減にも繋がっています。

また、マイクロアドでサービスプロジェクトを導入する場合、以下のフローに沿って進めています。

サービスプロジェクト導入フロー
サービスプロジェクト導入フロー

まとめ

以上、JSM のチーム管理対象サービスプロジェクトとマイクロアドでの事例について紹介させて頂きました。 企業管理対象/チーム管理対象のサービスプロジェクトを使い分けることで、管理者の作業コストを削減できるだけでなく、社内スタッフの JSM に関する知識が深まり、社内導入のハードルを下げることも可能だと思います。

補足:Atlassian Web セミナーに登壇しました!

2021/06/29(火)に Atlassian Web セミナーに登壇し、マイクロアドでの事例を紹介させて頂きました。

こちらから当日の Webinar を閲覧可能ですので、ご興味のある方はご登録の上、御覧ください。 www.atlassian.com

セミナー当日にご参加くださった方々からの質問とその回答は Atlassian 中川様のまとめられたこちらのブログから確認可能です。 community.atlassian.com

また、当日の発表資料はこちらから閲覧可能です。

www.slideshare.net

以上になります。
最後まで読んでいただきありがとうございました!

参考リンク


*1:Jira Service Desk は Jira Service Management の旧称です。

*2:以前はクラシックプロジェクト (Classic Project) という名称でした。

*3:以前は次世代プロジェクト (Next-Gen Project) という名称でした。

*4:Jira Service Management の有料ライセンスを所有し、サービスプロジェクトで「エージェント」としてのロールを付与されているユーザー

*5:Jira Service Management の有料ライセンスは所有せず、サービスプロジェクトに「カスタマー」とし登録されているユーザー

*6:Jira Query L*anguage の略。

*7:Jira Software の有料ライセンスを所有し、サービスプロジェクトで「エージェント」としてのロールを付与されているユーザー