Jira Service Management（以下 JSM）を導入し、ひとまず「問い合わせはポータルやメールで受けてチケット化できるようになった」という組織は多いと思います。
一方で、
- チケットは溜まるが、チームとしての運用がまだ固まっていない
- メンバーごとのやり方にばらつきがある
- 利用者（社員や顧客）とのコミュニケーションが属人化している
といった悩みもよく聞かれます。
本記事では、Atlassian Community の学習パス
「Get the most out of Jira Service Management(英語)」
- JSM を使い始めたばかりの組織が
- チームでの運用と活用範囲をどう広げていけるか
という視点で整理してご紹介します。
- Jira Service Management とは何か：チームで「サービス」を届けるための土台
まず押さえたいのは、JSM が「単なる問い合わせ管理ツール」ではない、という点です。
レッスン「What is Jira Service Management?(英語)」では、JSM を次のように位置づけています。
- 顧客（社内外）がオンラインフォームやポータルからリクエストを送る
- エージェント（対応チーム）が、そのリクエストを「ワークアイテム」として受け取り、担当・優先度・進捗を管理する
- コメントを通じて顧客やチームメンバーとコミュニケーションし、リクエストを完了まで導く
特徴的なのは、IT サポートだけでなく、人事・法務・マーケ・経理など、あらゆる社内サービスチームが同じしくみでリクエストを扱える点です。
- IT: アカウント発行、PC トラブル、ソフトウェア利用申請
- 人事: 労務・福利厚生に関する問い合わせ
- 法務: 契約レビュー依頼
- マーケティング: バナー制作、キャンペーン支援依頼
- 経理: 購買申請、支払依頼
JSM を導入したばかりの組織にとっての第一歩は、「自分たちのチームにとっての『顧客』は誰か」「どんなリクエストを受け付けるのか」を明確にし、それをポータルとワークアイテムに落とし込むことです。
- ポータルとスペース：顧客とチーム、それぞれの「見え方」を理解する
JSM では、同じ仕事でも「顧客側」と「チーム側」で別の見え方をします。
レッスン「Start navigating Jira Service Management(英語)」では次のような用語が紹介されています。
- リクエスト（Request）
顧客側の視点での「依頼」。ポータルからフォーム入力して送るものです。 - ワークアイテム（Work item）
チーム側の視点での「作業単位」。担当割り当てやステータス管理の単位になります。
同じ1件でも、顧客には「リクエスト」、エージェントには「ワークアイテム」として表示されます。 - キュー（Queue）
条件でフィルタされたワークアイテムの一覧。
「未対応」「自分に割り当て」「本日期限」など、用途別に用意できます。 - スペース（Service space）
特定のチームやサービス領域をまとめる単位。
例: 「IT ヘルプデスク」「人事サポート」「マーケティング支援」など。 - ポータル（Portal）
顧客向けの Web 画面。
リクエストタイプごとにフォームを用意し、顧客はここから依頼を送ります。
導入初期のつまずきポイントは、「どこから何を探せばよいかわからない」状態になりがちなことです。
まずはチーム全員で、次を確認しておくのがおすすめです。
- 自分たちのチームに対応する スペース名・キー
- 主に見る キュー（例: すべてのオープン、Assigned to me）
- 顧客に見せている ポータル URL とリクエストタイプの一覧
これらをチーム内のオンボーディング資料や Wiki にまとめておくことで、新しいメンバーが迷いにくくなります。
- 顧客とやり取りしながらリクエストを完了させる
JSM を日常業務で使うメンバーにとって、もっとも頻度が高いのが「1件のリクエストを見て、顧客とやり取りしながら解決する」仕事です。
レッスン「Work with customers on requests in Jira Service Management(英語)」では、その際に押さえるべき要素が整理されています。
3-1. リクエストタイプとフィールドを理解する
同じ「問い合わせ」でも、内容に応じて リクエストタイプ を分けておくことで、必要な情報をきちんと集められます。
- 例:
- 「PC トラブル報告」と「新規 PC 申請」では入力してもらいたい項目（フィールド）が違う
- 法務の「契約レビュー」と「NDA テンプレート依頼」でも必要情報が異なる
顧客がフォームに入力するフィールドと、エージェントだけが見る内部用フィールド（例: 対応工数、影響度など）を分けられるのもポイントです。
「顧客には関係ないが、チームとして意思決定に使いたい情報」は、内部フィールドで管理するとよいでしょう。
3-2. コメントの種類を使い分ける
顧客とのコミュニケーションは、コメント が基本です。
- 顧客に見えるコメント（外部コメント）
- 進捗報告、質問、解決策の共有など
- 返信時は「Reply to customer」を選択
- チーム内部だけのコメント（内部メモ）
- 裏側の調整内容、判断の背景、他チームへの相談メモなど
- 「Add internal note」を使うと、顧客からは見えません
「チャットやメールで済ませがちな会話」を、できるだけチケット上のコメントに寄せていくことで、
- 過去の経緯が追いやすい
- 別のエージェントに引き継ぐときの「説明コスト」が減る
という効果が出てきます。
3-3. ワークフローとステータスで「今どこか」を共有する
各リクエストには、作成から完了までの流れ（ワークフロー） が設定されています。
「Waiting for customer」「In progress」「Resolved」などのステータスで、今どの状態かを可視化します。
- エージェント側:
- ステータスを見れば、そのリクエストで何が終わっていて、何がこれからかが分かる
- 顧客側:
- 管理者の設定によっては、ポータル上で簡略化されたステータスを確認できる
運用のコツは、チームとして「このステータスになったら何をしている状態か」を合意しておくこと です。
例えば、
- Waiting for customer = 「質問や確認事項を顧客に投げており、返答待ち」
- In progress = 「対応者が実作業に着手している」
- Resolved = 「解決策を提示済みで、顧客の確認待ち or 自動クローズ待ち」
といった定義をドキュメント化しておくことで、メンバー間の認識ずれを防げます。
- ロールと組織：誰がどう関わるかを設計する
JSM を少し本格的に使い始めると、「誰にどこまで見せるか」「どこまで操作させるか」というアクセスとロールの設計が必要になります。
レッスン「Explore roles for a service space(英語)」では代表的なロールが紹介されています。
4-1. 基本のロール
- Customer（顧客）
- ポータルやメール、チャットからリクエストを送る
- 自分のリクエストのステータス確認、コメント・添付の追加、ナレッジ記事の閲覧 など
- Agent（エージェント）
- ライセンスを持ち、JSM 上でリクエストを処理するメンバー
- キューを見て作業し、ステータス変更やコメント、フィールド更新などを行う
- Collaborator（コラボレーター）
- JSM ライセンスを消費せず、他の Jira 製品からコメントや閲覧だけ行う立場（構成による）
- Space admin（スペース管理者）
- キューやワークフロー、リクエストタイプ、ロールなどを設定・管理
また、チームのニーズに合わせて カスタムロール を作ることもできます。
例: 「IT マネージャーだけが SLA 設定やキュー作成を変更できる」など。
4-2. リクエスト参加者・承認者・組織
個々のリクエスト単位で関わる人たちもいます。
- Request participants（リクエスト参加者）
- 元の報告者以外にもリクエストの進捗を共有したい場合に追加
- 通知を共有し、コメントや添付の追加も可能
- Approvers（承認者）
- 購買や権限付与など、「承認」が必要なリクエストで使う
- 承認・却下のアクションを行い、その結果がワークフローに反映されます
- Organizations（顧客組織）
- 顧客をグルーピングする単位（例: 特定の法人顧客、部署など）
- 組織単位で SLA やレポートを見たり、組織メンバーが互いのリクエストを検索できるようになる
JSM では顧客数に制限がなく、複数のサービススペースに同じ組織を紐づけて運用できます。
サポート対象の企業や部署ごとに組織を作っておくことで、
- 「この顧客からどれくらいリクエストが来ているか」
- 「この顧客に対する SLA 準拠状況はどうか」
といった分析がしやすくなります。
- キュー・リクエストタイプ・SLA：日々の仕事を整理して捌く
レッスン「Organize your work in Jira Service Management(英語)」では、エージェントがどのように自分たちの仕事を整理していくかが解説されています。
5-1. キューを「日々見るホーム画面」にする
キューは、JQL ベースの条件によってフィルタされたワークアイテムの一覧です。
- 例:
- すべてのオープンリクエスト
- 自分に割り当てられたリクエスト
- 今週中に期限を迎えるリクエスト
- 特定のリクエストタイプ（例: インシデント）のみ
頻繁に見るキューは スター（★）を付けておく と、すぐにアクセスできます。
チームとして「毎朝このキューを見る」「当番はこのキューをモニタリングする」といったルールを決めておくと、抜け漏れが減ります。
5-2. Bulk action（複数一括操作）で時間を節約する
似たようなリクエストがたくさんある場合、1件ずつ操作するのは非効率です。
JSM では、キューから複数のワークアイテムを選択し、次のような 一括操作 ができます。
- ステータスの一括変更（例: まとめて「In progress」にする）
- 同じコメントを複数リクエストに投稿
- 担当者をまとめて変更
- 関連ワークアイテムのリンクをまとめて追加
- 承認 / 削除の一括実行
これにより、毎日のオペレーションの手間を大きく減らせます。
5-3. リクエストタイプ別のフィルタと SLA モニタリング
- リクエストタイプでのフィルタ
- 例: インシデントだけを抽出して対応エンジニアが見る、など
- 自分の役割に関係するリクエストタイプだけに絞ることで、ノイズを減らせます。
- SLA（サービスレベル目標）の可視化
- 「初回応答まで」「解決まで」など、リクエストごとに残り時間が表示される
- アイコンと色（灰色・黄色・赤）で、「まだ余裕」「そろそろ危険」「既に違反」を一目で把握可能
- 重要度の高いキューは「SLA が迫っている順」でソートしておくと優先順位が明確になります。
顧客には SLA 情報は表示されないため、あくまで内部の優先度管理の道具 として活用できます。
- 顧客とのコミュニケーションを「仕組み化」する
学習パスには、顧客とのコミュニケーションに特化したレッスン
「Communicate effectively with customers in Jira Service Management(英語)」も含まれています。
ここでは詳細テキストは公開されていませんが、学習パス全体の流れや他レッスンから、JSM でのコミュニケーションのベストプラクティスは次のように整理できます。
- こまめなコメント
- ステータス変更だけではなく、「今何をしているか」「次に何をするか」を短くコメントする
- 顧客側から見える情報量が増え、「放置されている」感を減らせます。
- 一括コメントの活用
- システム障害など、同じ内容を多くの顧客に伝える必要がある場合は、Bulk action と組み合わせてコメントを配信
- 手作業のコピペを減らし、メッセージ内容の一貫性も保てます。
- わかりやすい言葉で書く
- ナレッジベースと同様、専門用語の多用は避け、顧客の言葉で説明する
- 長文になりすぎないよう、「要約＋詳細」の構成を意識する。
- 定型文（canned responses）の活用
- よくある案内や説明は定型文化し、誰が対応してもトーンが揃うようにする
- 新任エージェントでも安心して対応できるようになります。
- ポータルへのお知らせ
- 障害情報やメンテナンス情報をポータル上に掲出しておくことで、問い合わせが来る前に情報を届けられます。
「人によって対応の質がバラバラ」という課題は、こうした仕組み化を進めることで、徐々に均質化していけます。
- ナレッジベースで「問い合わせゼロ」を目指す
レッスン「Create knowledge base articles(英語)」は、JSM と Confluence を組み合わせたナレッジ運用にフォーカスしています。
7-1. ナレッジベースの役割
ナレッジベース記事は、顧客が自分で問題を解決できるようにするためのコンテンツ です。
- 顧客側のメリット:
- 問い合わせをしなくても、すぐに解決策が見つかる
- チーム側のメリット:
- 同じ質問への対応回数が減り、より価値の高い業務に時間を使える
- 回答内容のブレが減る（いつも同じ記事を参照できる）
JSM のサービススペースに Confluence のナレッジベーススペースを紐付けることで、ポータルやエージェントビューから記事を直接検索・共有できます。
7-2. いいナレッジ記事を書くためのポイント
レッスンでは、次のようなベストプラクティスが紹介されています。
- テンプレートで統一感を出す
- Confluence のテンプレート機能を使い、記事の構成をパターン化する
- 顧客にとって「毎回同じレイアウトで読みやすい」状態を作る
- 顧客の言葉で書く
- 実際のリクエストやコメントからキーワードを拾い、タイトルや本文に反映する
- 検索に引っかかりやすくなり、自己解決率が上がります。
- 短い要約＋詳細な手順
- 冒頭に「この記事で解決できること」を短くまとめ、下に手順や補足を展開する
- 必要な人は詳細を読み、急いでいる人は要約だけで判断できます。
- カテゴリとラベルで整理する
- カテゴリ（大きな分類）とラベル（キーワード）を組み合わせて情報を整理
- ポータル上の検索性が上がり、「まずナレッジを探す」文化が育ちます。
ナレッジベースは、一度作って終わりではなく、定期的な棚卸しとアップデート が肝心です。
「問い合わせが多いのに記事がない領域」「アクセスは多いが解決に結びついていない記事」などを定期的に見直すことで、品質が高まっていきます。
- ダッシュボードで「チームの今」を一画面にまとめる
サービス運用が軌道に乗ってくると、「マネージャーや他チームが、今の状況を一目で知りたい」というニーズが出てきます。
レッスン「Create basic dashboards in Jira(英語)」では、ダッシュボードの基本的な考え方と作り方が説明されています。
8-1. ダッシュボードとは
ダッシュボードは、複数の ガジェット を組み合わせて構成する、カスタマイズ可能な画面です。
- 例:
- 自分に割り当てられた未解決リクエスト一覧（Assigned to Me）
- 特定キューの統計情報
- 最近更新されたリクエストのアクティビティストリーム など
ユーザーごとに見えるデータは権限に応じて変わるため、同じダッシュボードでも、見る人によって中身が少し違う 形で活用できます。
8-2. 基本の作成ステップ
- 「Dashboards」から「Create dashboard」を押し、名前と説明を設定
- 「Add gadget」で必要なガジェットを追加
- ドラッグ＆ドロップでレイアウトを整え、不要なガジェットは削除
- 必要に応じてフィルターや権限を設定して保存
チームとしてのおすすめは、
- エージェント個人向けダッシュボード（自分の仕事を整理する用）
- チームリーダー向けダッシュボード（SLA、件数、ボトルネックの可視化用）
の2種類を用意し、定例会議などで一緒に見る習慣を作ることです。
- 個人設定とショートカットで「毎日の使い勝手」を上げる
JSM の活用を組織に広げるうえで、意外と効いてくるのが「個人ごとの使い勝手」です。
ここが悪いと、「ツールとしてはいいけれど、ちょっと面倒」という印象になりがちです。
9-1. キーボードショートカットとコマンドパレット
レッスン「Work efficiently using commands and shortcuts in Jira(英語)」で紹介されているように、Jira には多くのショートカットがあります。
- よく使う基本ショートカット
/: クイック検索c: 新しいワークアイテム作成[: サイドバーの表示・非表示
- コマンドパレット（Cmd/Ctrl + K）
- 画面上部から任意のスペース、ワークアイテム、アクションにすぐ飛べる
- マウス操作を減らし、日常の操作を軽くできます。
ショートカットは ? を押すか、ヘルプメニューの「Keyboard shortcuts」から一覧を確認できます。
使わないメンバーには無理に強要する必要はありませんが、ヘビーユーザーには早めに紹介しておくと、ストレスが大きく減ります。
9-2. 個人設定とホーム画面
レッスン「Adjust your personal settings in Jira(英語)」では、個々のユーザーが自分で変更できる設定が紹介されています。
- 設定画面から変更できる例:
- 表示言語やタイムゾーン
- ホーム画面（推奨: 「For you」タブをホームに）
- テーマ（ライト / ダーク / ブラウザに合わせる）
「毎日最初に開いたときに自分の仕事が見える」「ダークモードで目が疲れにくい」といった小さな改善が、日々の体験に直結します。
9-3. 通知設計で「必要な情報だけを受け取る」
レッスン「Set your personal notifications in Jira(英語)」では、通知との付き合い方が解説されています。
- Jira 内の通知:
- 画面上部のベルアイコンから、Jira や Confluence など複数プロダクトの通知を横断的に確認
- メール通知:
- デフォルトでは多くのイベントでメールが飛ぶため、個人設定で不要なものはオフにする
- メールクライアント側でフィルターやラベルを設定するのも有効
- メッセージツールとの連携:
- Slack や Microsoft Teams と連携し、「特定チャンネルにだけ重要な通知を流す」といった設計が可能
- その場からコメント・ステータス変更などを行える連携もあります。
ポイントは、
「すべての通知を追う」のではなく、「必要なものだけを確実に受け取る」 という発想で設計することです。
10. おわりに：小さな運用ルールから、チームと組織の標準へ
「Get the most out of Jira Service Management(英語)」学習パスは、JSM の UI や機能の使い方だけでなく、
- 顧客とのコミュニケーションの持ち方
- チーム内の役割とアクセスの設計
- 日々の仕事を整理・優先順位付けする方法
- ナレッジベースやダッシュボードで、運用を「仕組み」として育てていく考え方
- 個人ごとの使い勝手を最適化して、ツールを「好きになれる」状態にする工夫
まで含めて、サービスチームとしての基礎体力を高める内容 になっています。
組織として JSM の活用を広げていくには、
- まずは1つのサービススペース（例: IT ヘルプデスク）で、
- ロール設計
- キューとリクエストタイプ
- コメント運用とナレッジベース
- ダッシュボードと通知設定
などの「小さな成功パターン」を作る
- そのパターンをテンプレートとして、他のサービスチーム（人事・総務・法務など）にも展開してみる
- 実際の運用から得られたフィードバックをもとに、ワークフローやルールを少しずつ改善していく
というサイクルを回していくことが重要です。