Jira Service Management のカスタマイズ全体像と6つのベストプラクティス

カスタマイズ全体像と推奨される 6 つの方法

Jira Service Management（JSM）を自社の業務フローに合わせて最適化するには、単なる画面装飾だけでなく リクエストタイプ・ワークフロー・ポータル UI・Automation・権限設計・テスト・移行 の 6 領域を体系的に整理することが重要です。本セクションでは、全体像と Atlassian が公式ドキュメントで示すベストプラクティスを概観します。

全体フロー概要

以下のステップは、要件定義から本番リリースまでの標準的な流れです。各フェーズで成果物を明確にし、次のフェーズへのインプットとすることで、変更リスクを抑えられます。

このフローは Atlassian の公式ガイド（Jira Service Management カスタマイズの概要）でも推奨されています。

公式が示す 6 つのベストプラクティス

各領域で実践すべきポイントを表にまとめました。下記は 「何を対象にするか」 と 「具体的なアクション」 の二軸で整理しています。

上記ベストプラクティスに沿って設定すれば、将来的な機能追加や組織変化にも柔軟に対応できます。

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

リクエストタイプは顧客がポータルから作成できる「チケット」の入口です。適切に設計すれば、入力ミスや処理遅延を防ぎ、ユーザー体験を向上させられます。

追加手順の概要

このセクションでは 「プロジェクト設定 → リクエストタイプ」 から新規タイプを作成し、カスタムフィールドと表示ロジックを同時に定義する流れを解説します。執筆時点では UI が公式ドキュメントと一致していますが、Cloud の UI は随時更新されるため、最新情報は Atlassian ヘルプをご確認ください。

1. リクエストタイプの作成
2. プロジェクト設定 → 「リクエストタイプ」へ移動

3. 「タイプを追加」ボタンで名称（例：ハードウェア障害）とアイコンを入力し保存

4. カスタムフィールドの定義

5. 「カスタムフィールド」画面で「シリアル番号」「保証期間」を新規作成

6. 各フィールドに対して必須・表示条件を設定（例：シリアル番号が入力されたときのみ保証期間を表示）

7. レイアウトの調整

8. 「レイアウト」タブでドラッグ＆ドロップし、ユーザーが最初に目にすべき項目を上位に配置

フィールド設定手順（H3）

以下はフィールド追加と条件付表示の具体的な操作です。

カスタムワークフローの設計と Problem Management の組み込み

業務プロセスに合わせた独自ワークフローは、承認や根本原因分析（Problem Management）まで一貫して管理できる重要な要素です。なお Problem Management は JSM Premium プランまたは「Jira Service Management for ITSM」アドオンが必要であることを明示します。

設計方針のポイント

• ステータスと遷移は最小限に：過剰なステータスは管理コストを上げるため、業務フローに必須なものだけを作成
• 条件付き承認：承認が必要な遷移にはロールベースの条件を設定し、不要な手戻りを防止
• Automation との連携：ステータス変更時に自動通知やリンク生成を組み合わせて、手作業を削減

ワークフロー構築手順（H3）

1. ワークフローエディタの起動

2. プロジェクト設定 → 「ワークフロー」 → 「新規作成」または既存テンプレートのコピー

3. ステータス追加

4. 必要なステータス（例：Open, Pending Approval, In Progress, Under Investigation (Problem), Resolved, Closed）をドラッグし、名称とアイコンを設定

5. 遷移線の描画と条件付与

6. 矢印で遷移を結び、条件（例：Approvers = currentUser()）や ポスト関数（自動通知・担当者割当）を追加

7. Problem Management ステージの組み込み

8. Under Investigation (Problem) を作成し、Automation ルールで「ステータスがこの状態になると、同一インシデントに紐づく Problem チケットを自動生成」する設定を行う（Automation の公式ガイド参照）

9. 承認フローの実装例

10. Open → Pending Approval に対し「承認者ロールのみが遷移可能」条件を付与
11. Pending Approval → In Progress で「承認済み」チェック（JQL: status = "Pending Approval" AND approvers IS NOT EMPTY）を必須化

Automation の活用例（H3）

これらの設定はすべて Atlassian が提供する Automation for Jira の UI から構成できます。

サービスポータル UI のカスタマイズ

ポータルは顧客が最初に触れる画面です。見た目と操作性を統一することで、問い合わせミスの削減やブランドイメージ向上につながります。

基本的なカスタマイズ項目（H3）

手順の概要

1. ポータル設定へ移動 → プロジェクトサイドバーの「ポータル」リンクをクリック
2. 「ブランド設定」タブでロゴとカラーをアップロード／入力し保存
3. 「カスタムコンテンツ」セクションで「HTML」ウィジェットを追加し、必要なコード（例：FAQ へのリンクや簡易検索ボックス）を貼り付け

注意：Cloud 環境ではサードパーティスクリプトの実行に制限があります。JavaScript を使用する場合は Atlassian の CSP ポリシーを必ず確認してください。

ロールベースアクセス制御（RBAC）と最小権限設計

適切な権限設定は情報漏洩防止と業務効率化の両立に不可欠です。JSM では プロジェクトロール と グローバル権限スキーム を組み合わせて RBAC を実現します。

権限設計の基本方針（H3）

• 最小権限原則：ユーザーが業務遂行に必要な権限だけを付与
• ロール単位で管理：変更や監査が容易になるよう、ロールごとに権限セットを定義
• リクエストタイプ別マッピング：機密フィールドへのアクセスはタイプごとに細分化

実装手順

例：ハードウェア障害リクエストのフィールド制御

• 保証期間 フィールドは Hardware Agent ロールだけが表示
• 他ロール（例：一般エージェント）は閲覧不可、編集もできないように設定

この設計は Atlassian の公式 RBAC ガイド（Jira Service Management 権限のベストプラクティス）と合致しています。

テスト環境での検証フローと本番移行、よくある落とし穴

実運用前にサンドボックスで動作確認を行うことで、ユーザーへの影響を最小限に抑えられます。ここでは 変更適用手順・デプロイ方法・トラブルシューティング をまとめました。

サンドボックスでの検証フロー（H3）

本番デプロイ手順のポイント（H3）

1. バックアップ取得

2. プロジェクト設定画面から「エクスポート」し、JSON ファイルを保存（※Cloud のエクスポートは設定情報のみ対象）

3. 変更点の適用

4. サンドボックスで確認した設定を手動で本番に反映（UI で同様の操作を実施）。差分インポート専用オプションは Cloud には存在しないため、必要な項目だけを個別に更新します。

5. リリースノート作成

6. 変更概要・影響範囲・担当者・ロールバック手順を文書化し、関係者へ共有

7. メンテナンスウィンドウで実施

8. 利用者への告知と合わせて、業務時間外にデプロイすることで影響度を低減

典型的なトラブルと対策（H3）

まとめ

Jira Service Management のカスタマイズは 「要件定義 → 設計 → サンドボックス検証 → 本番デプロイ」 という一連のフローで実施すれば、変更リスクを最小限に抑えながら業務効率化が図れます。

• 6 領域（リクエストタイプ・ワークフロー・ポータル UI・Automation・権限設計・テスト・移行） を体系的に管理
• Problem Management は Premium プランまたは対応アドオンが必要であることを明示
• 公式 Atlassian ドキュメントのみ参照し、サードパーティ製品へのリンクは控える

このガイドラインに沿って設定を進めれば、将来的な機能拡張や組織変化にも柔軟に対応できる堅牢な JSM 環境が構築できます。質問や不明点がある場合は、Atlassian コミュニティや公式サポートをご活用ください。