Jira Service Management

Jira Service Management 導入ガイド:クラウド・Data Center 比較と設定手順

ⓘ本ページはプロモーションが含まれています

スポンサードリンク

1. Jira Service Management の概要と導入環境選択

JSM は ITIL ベースのサービスデスク機能を提供する Atlassian 製品で、クラウド版Data Center 版 の二つの配布形態があります。
本セクションでは、両者の基本的な違いと、導入時に検討すべきポイントを整理します。

1-1. クラウド版と Data Center 版の比較

以下の表は、公式ガイド(2024 年 10 月版)を元に主要項目を抜粋したものです。主観的な評価は避け、機能や運用上の要件で比較しています。

項目 Jira Service Management Cloud Jira Service Management Data Center
デプロイ形態 Atlassian が管理する SaaS(ブラウザだけで利用) オンプレミスまたはプライベートクラウドに自社でインストール
スケーラビリティ ユーザー数・データ容量は Atlassian のインフラが自動で拡張 ノードを追加して水平スケール。ハードウェア要件の調整が必要
カスタマイズ性 アドオン(Marketplace)や Automation は利用可。ただしサーバーレベルの OS/ミドルウェア変更は不可 プラグイン、ScriptRunner 等による高度な拡張と、カスタムスクリプト実行が可能
可用性 / SLA Atlassian が 99.9% の稼働率を保証(サービスレベル合意) 冗長構成やロードバランサー等、インフラ設計次第で可用性を決定
コスト構造 ユーザー数ベースの月額サブスクリプション。追加機能は別途アドオン課金 初期ライセンス費+年間保守料(更新時に適用)。ハードウェア・運用コストが別途発生
ライセンス/料金情報の注意点 価格は Atlassian のプラン改定に伴い変動する可能性があります。公式サイトで最新プランを必ず確認してください。 同上。Data Center はノード数によって価格が段階的に増加します。

※情報更新の目安
本表の内容は 2024 年 10 月時点のものです。ライセンス形態や料金体系は年2回程度改訂されることがあります。記事を公開後も、公式リリースノートや価格ページをチェックし、必要に応じて本文を更新してください。

1-2. 選定基準チェックリスト

導入形態の判断材料として、「導入スピード」「データ主権」「利用規模」 などの観点を整理しました。各質問に対する回答例と推奨判定を示します。

判断ポイント 質問例 推奨判定(目安)
導入スピード すぐにサービスを開始したいか? 短期間で利用開始できる Cloud が適しています。
データ主権・規制 法令や社内ポリシーでデータを自社サーバーに保持する必要があるか? データ保管場所の管理が必須の場合は Data Center が選択肢になります。
同時ユーザー数 エージェント数が 1,000 人規模になる見込みか? 大規模利用では水平スケール可能な Data Center が適しています(ノード追加で対応)。
カスタマイズ要件 ワークフローに独自ロジックや外部システム連携を組み込みたいか? 高度なプラグイン・スクリプトが必要な場合は Data Center が柔軟です。
予算計画 初期投資よりも運用コストで抑えたいか? 月額課金の Cloud は初期費用が低く、コスト管理がシンプルです。

活用ヒント
チェックリストはプロジェクト開始時に関係者全員でレビューし、合意形成を図ると意思決定がスムーズになります。


2. 無料サインアップからプロジェクト作成までのクイックスタート手順

JSM の導入は公式サイトからの無料トライアルで簡単に始められます。本章では、サインアップ → ライセンス取得 → プロジェクト作成 の流れをステップ別に解説します。

2-1. ライセンス取得と初期設定

まずは Atlassian のアカウントを作成し、JSM インスタンスを自動生成します。以下の手順で進めてください。

  1. 無料トライアル申し込み
  2. Atlassian の「Jira Service Management を無料で試す」ページにアクセスし、メールアドレスを入力してアカウント作成。認証メール内のリンクをクリックすると、クラウドインスタンスが即座にプロビジョニングされます(公式ガイド)。
  3. 管理者アカウント設定
  4. 初回ログイン時に管理者権限のユーザーを作成し、二要素認証(MFA)を有効化。これにより不正アクセスリスクが低減します。
  5. 基本情報入力
  6. 会社名・タイムゾーン・使用言語を設定し、組織全体で統一された時間管理基盤を確立します。

ポイント:トライアル期間は通常 30 日間です。期限が近づいたらサブスクリプションへの移行手続きを忘れずに実施してください。

2-2. サービスプロジェクト作成フローとテンプレート選択

プロジェクト作成時には、業務目的に合わせたテンプレートを選ぶことが重要です。以下の流れで設定します。

  1. 「プロジェクト作成」ボタンをクリック
  2. メインメニュー左側に表示されるので、対象の JSM インスタンス内で操作してください。

  3. テンプレートの選定(導入初期は IT Service Management が推奨)

  4. IT Service Management:インシデント・変更管理に最適化されたワークフローとキューが標準装備。
  5. Customer Service:外部顧客向けの問い合わせ対応を想定したテンプレート。
  6. HR Service Desk:社内従業員からのリクエスト(入退社手続き等)に特化。

  7. プロジェクト名とキーの入力

  8. 例)IT Support(プロジェクト名) / ITS(キー)。キーは他プロジェクトと重複しないよう注意してください。

  9. サンプルデータのインポート(任意)

  10. 作成完了後に「サンプルデータを追加」オプションが表示されます。デモ用キューやリクエストタイプが自動生成され、操作感覚を掴むのに有効です。

補足:Data Center 版の場合はインストール後に管理コンソールからプロジェクト作成を行いますが、基本的な手順はクラウド版と同様です。


3. ポータルカスタマイズとリクエストタイプ設定

顧客ポータルはユーザー体験の入口です。ここではデザイン変更方法と、実務に合わせたリクエストタイプ設計手順を示します。

3-1. 顧客向けポータルの有効化とデザイン変更

ポータルはプロジェクト設定から簡単にオン/オフできます。以下の手順でブランディング要素を差し込みましょう。

  1. ポータル有効化
  2. 「プロジェクト設定」→「顧客ポータル」→スイッチを ON にします。

  3. ロゴ・テーマカラーの差し替え(ブランド統一のため)

  4. ロゴは 200 × 80 ピクセル程度の PNG を推奨。アップロード後、即座にプレビューが表示されます。
  5. テーマカラーは HEX コードで指定(例:#0052CC)。全画面のヘッダーとボタン色が自動的に反映されます。

  6. ヘッダー文言・フッターリンク

  7. 「ようこそ」「サポート時間」などの案内文を設定し、FAQ への外部リンクや連絡先情報も併記できます。プレビュー機能で公開前に確認してください。

ベストプラクティス:アクセシビリティを考慮し、コントラスト比が 4.5:1 以上になる配色を選択すると、WCAG に準拠したデザインになります。

3-2. リクエストタイプとフィールド構成

リクエストタイプは顧客が送信できる問い合わせのカテゴリです。業務フローに合わせて最適化しましょう。

リクエストタイプ 主な目的 標準フィールド例
インシデント サービス障害や不具合の報告 件名、説明、影響範囲、優先度
サービス要求 新規資産・アクセス権の取得 件名、説明、必要な権限、期日
変更依頼 システム構成や設定変更の承認申請 件名、変更内容、影響評価、実施日時

カスタムフィールド追加手順

  1. 対象リクエストタイプを選択
  2. 「プロジェクト設定」→「リクエストタイプ」→目的のタイプをクリック。

  3. 「フィールド」タブで「カスタムフィールドを追加」

  4. テキスト、プルダウン、日付、ユーザー選択など必要な入力項目を作成します。

  5. 必須設定・表示順の調整

  6. フィールドはドラッグ&ドロップで並び替え可能です。また、必須チェックボックスをオンにすれば、送信前に入力が求められます。

ヒント:フィールド数が多くなると顧客の入力負荷が増えるため、業務上本当に必要な項目だけに絞ることが推奨されます。


4. ワークフロー、権限、SLA の設計と自動化

サービス品質を担保するためには、ワークフローSLA を明確にし、権限管理で適切な担当者だけが操作できるようにします。ここではベストプラクティスと具体的設定手順を示します。

4-1. ワークフロー設計のベストプラクティス

ワークフローは「状態(ステータス)」と「遷移(トランジション)」で構成されます。以下の指針に沿ってシンプルかつ拡張性を保ちましょう。

  1. 最小限のステータスで開始
  2. 推奨パターン:Open → In Progress → Resolved -> Closed の 4 状態。業務上必要な場合は Awaiting CustomerPending Change を追加します。

  3. 遷移に条件とバリデーションを設定

  4. 条件:例)「ステータス変更は Service Desk Agent ロールのユーザーのみ実行可」
  5. バリデーション:例)Resolved へ遷移する際、必ず「解決策」フィールドが入力されていることをチェック

  6. Automation(自動化)で手作業を削減

  7. インシデントが High 優先度に変更されたら Slack に通知。
  8. SLA が期限切れになると自動的にステータス Escalated へ遷移し、全エージェントへメール配信。

設定手順は「プロジェクト設定」→「ワークフロー」→対象のワークフローを選択 → 「編集」で行います。Automation は同メニュー内の「自動化」から IF/THEN 形式で作成できます。

4-2. 権限スキーマとロール管理

権限は プロジェクトレベルグローバルレベル の二層構造です。最小権限の原則(Principle of Least Privilege)に基づき、必要な操作だけを許可します。

ロール 主な権限 推奨設定
Service Desk Administrator プロジェクト全体の設定変更・ユーザー管理 1〜2 名に限定し、定期的にレビュー
Service Desk Agent キュー閲覧・チケット更新・コメント投稿 「エージェント」グループへ所属付与
Customer ポータルからリクエスト作成のみ Browse Projects は除外し、閲覧は不可

過剰権限防止策

  • 権限スキーマのカスタマイズプロジェクト設定 → 権限 で各操作(例:Browse Projects, Edit Issues)をロール単位に割り当てます。
  • 定期レビュー:月1回、権限一覧レポートを出力し、不要なロールやユーザーがないか確認します。

4-3. SLA 定義とダッシュボード作成

SLA(Service Level Agreement)は顧客期待値を数値化する重要指標です。JSM の SLA エンジンで目標設定・測定が可能です。

  1. SLA 目標の設定
  2. レスポンス時間:優先度 P1 → 15 分以内に最初の応答を行う。
  3. 解決時間:優先度 P2 → 4 時間以内に完了。

設定は「プロジェクト設定」→「SLA」から新規 SLA を作成し、対象ステータス(例:Open)と計測開始条件を指定します。

  1. 実績可視化ダッシュボード
  2. ガジェット例
    • SLA パフォーマンス:目標達成率(%)と残り時間のグラフ。
    • フィルタ結果:未解決インシデント一覧をリアルタイム表示。

ダッシュボードは「Jira → ダッシュボード」から作成し、全エージェントが閲覧できる共有設定にします。毎朝の自動メール配信も併せて有効化すると、KPI の定期的なモニタリングが容易です。


5. 通知・連携、レポート・運用チェックリスト

本章では、通知設定外部ツール連携、さらに 定例レポート作成と移行計画 の手順をまとめます。運用フェーズでのトラブル防止に役立ちます。

5-1. メールテンプレートと外部ツール連携

メールテンプレート編集

  1. 通知スキーマ選択
  2. 「プロジェクト設定」→「通知」から使用中の通知スキーマを開きます。

  3. イベントごとのメール本文カスタマイズ

  4. Issue CreatedSLA Breached など主要イベントに対し、プレースホルダー {issue.key}{assignee.displayName} を活用して動的情報を埋め込みます。

Confluence・Jira Software 連携

  • Confluence:Marketplace から Confluence アドオンをインストールし、チケットの「Link to Confluence page」機能でナレッジベースへ即リンク。
  • Jira Software:開発チームが利用中の場合は、リクエストタイプ Incident に対して「DevOps」トランジションを追加。これにより、インシデントから自動的に開発タスク(Story)を作成し、ステータス同期が可能です。

5-2. 分析ダッシュボードとモニタリング手法

KPI 計算式・取得元 推奨ガジェット
初回応答時間(平均) First response time の平均値(SLA データ) SLA パフォーマンス
解決率 完了チケット ÷ 期間内総チケット数 カスタムフィルタ結果
エスカレーション件数 Escalated ステータス遷移回数 バー・チャート

定期レポートの自動化

  • 毎週金曜に「Jira Service Management レポート」ガジェットを PDF で生成し、ステークホルダーへメール送信。
  • リアルタイムモニタリング:ダッシュボードをホーム画面にピン留めし、エージェントが常時閲覧できるように設定します。

5-3. 導入前テスト・トレーニング・移行計画

テストシナリオ例

ケース 内容 合格基準
1 高優先度インシデントの自動エスカレーションが正しく機能するか エスカレーションメールが送信され、ステータスが Escalated に遷移
2 顧客ポータルからのリクエストが指定テンプレートでメール通知されるか 受信したメール本文に正しい {issue.key} が含まれる

ユーザートレーニング

  • エージェント向け:30 分間の「JSM 基礎操作」ワークショップを実施し、チケットの検索・更新・コメント手順を体験。
  • 顧客側:ポータル利用ガイド(PDF)を配布し、FAQ へのリンクと併せてセルフサポートを促進。

移行チェックリスト

  • [ ] ライセンス数・ユーザー割当の最終確認
  • [ ] カスタムフィールド・スキーマの整合性検証(テスト環境でインポート実施)
  • [ ] SLA 目標値と測定ロジックのテスト実行
  • [ ] 通知メール送信先リストのレビュー
  • [ ] 本番移行前にバックアップ取得(データベース・設定ファイル)

注意:Data Center 版ではインフラ構成が異なるため、サーバー冗長化やロードバランサ設定も合わせて確認してください。


6. まとめと次のアクション

Jira Service Management はクラウド・Data Center の両形態で柔軟にサービスデスクを構築できるプラットフォームです。
本ガイドで示した 比較表、チェックリスト、設定手順 を活用し、以下の流れで導入プロジェクトを進めましょう。

  1. 要件整理 → 章 1 のチェックリストでクラウドか Data Center を決定
  2. トライアル実施 → 章 2 に沿ってインスタンスとプロジェクトを作成
  3. ポータル・ワークフローのカスタマイズ → 章 3・4 のベストプラクティスを適用
  4. 通知・レポート設定 → 章 5 で運用体制を整備
  5. テスト・トレーニング → 移行チェックリストを実施し、本番環境へ移行

導入後は、定期的に 権限レビューSLA パフォーマンスのモニタリング を行い、サービス品質の継続的改善を図ります。


本記事は執筆時点(2024 年 10 月)情報に基づいています。ライセンス形態や料金体系は Atlassian の公式発表に従って随時更新してください。

スポンサードリンク

-Jira Service Management