※本記事は、Benjamin Patonが2022年3月13日に公開した英語記事「Choosing the right approach to Customer Management in Jira Service Management」を翻訳したものです。内容に相違が見受けられる場合、英文ページの内容を正とします。
カスタマーはあらゆる企業の心臓部と言えます。JSMにおけるカスタマーエクスペリエンスはサービスデスクの成功において非常に重要です。このため、効果的なカスタマー管理戦略はあらゆる管理者にとって最重要事項となっています。企業はそれぞれで異なり、個々の企業で抱えるカスタマーもまた異なります。このため、要件に応じて適切なカスタマー管理戦略を選定することが重要です。
カスタマー管理戦略の中核として、カスタマーがどのような立ち位置になるかの理解があります。
-
内部カスタマー: 一般に自社の従業員です。社内で1つまたは複数のチームが社内のメンバーにサービスをオープンに提供します。
-
外部カスタマー: 社外のユーザーです。多くの場合は一般大衆の一部です。自社が外部の個人やグループ (クライアント、顧客) にサービスを提供します。
-
ハイブリッドカスタマー: 内部カスタマーと外部カスタマー両方の組み合わせです。一部のチームが社内のメンバーにサービスを提供し、他のチームは社外のメンバーにサービスを提供します。
カスタマーの種類に応じ、サインアップ、アクセス、権限に対するアプローチが異なります。また、アトラシアン製品のユーザーが管理およびプロビジョニングされる方法を理解しておくことも重要です。Atlassian Accessはライセンスを持つユーザーの管理ツールとしてよく知られていますが、内部カスタマーの管理にも有用であり、SSO機能を内部カスタマーに拡張するためにも利用できます。
この記事では、各戦略のベストプラクティスを紹介します。現在ご利用いただける機能と、エクスペリエンス改善につながる将来的に追加予定の機能を整理します。
アカウントの種類
|
Atlassianアカウント
|
ポータル専用のカスタマーアカウント
|
|---|
|
✅ 複数のアトラシアン製品を横断して同じアカウントをコラボレーションに利用可能
✅ ユーザーはビジネスアカウント (Google、Microsoft、Slack、Apple) を利用してサインイン可能
✅ 権限管理のためにグループに追加可能
✅ パスワードポリシーを適用可能
✅ すべてのアトラシアン製品やサイトに一回のログインでアクセス
✅ 高度なユーザー管理やメトリクス (Accessを利用)
❌ 組織のユーザー基盤の最大サイズに制限される (現在75,000*)
|
✅ カスタマイズ可能なログインエクスペリエンス
✅ 無制限
✅ 個々のJSMサイトに一意
❌ 複数のサイトを横断した再利用は不可能
❌ グループへの追加は不可。組織への手動追加のみが可能
❌ メールアドレスとパスワードの組み合わせの認証方式のみが利用可能
|
* ご利用の組織でこの制限が問題になる場合は担当のアカウントマネージャーにご相談ください。
内部戦略
この戦略は、すべてのカスタマーが社内の従業員、契約社員、あるいはステークホルダーである組織に向いています。外部カスタマーがヘルプセンターに招待されることはありません。カスタマーがJSMや他のアトラシアン製品のユーザーであることも多々あります。
よくある例: ITSMチーム、HRチーム、法務チーム、財務チーム
重視されるポイント: スムーズなアクセス、セキュリティ、シングルサインオン、コスト効率
この戦略では内部カスタマーアカウント (Atlassianアカウント) の利用をおすすめします。Atlassian Accessの利用は必須ではありませんが、ベストプラクティスの提供につながります。
この方法で設定された、製品ライセンスを持たないカスタマーは、Atlassian Accessを含むどの製品においてもコストを発生させません。
|
手順
|
内部カスタマー (Accessを利用)
|
内部カスタマー (Accessなし)
|
|---|
|
カスタマーのプロビジョニング
|
自社のIdPを接続して、内部カスタマーアカウント (Atlassianアカウント) として自動的に同期するグループを選択できます。
|
Jira/Confluenceの製品アクセスにドメインに基づいた許可リストを利用することで、内部カスタマーのサインアップを自動承認できます。
|
|
ヘルプセンターのセキュリティ設定
|
ポータルのサインアップは無効化します。
|
ポータルのサインアップを有効化する必要があります。
匿名のポータルアクセスは許可しないことを推奨します。
|
|
製品アクセスの制御
|
Atlassian Access経由で同期されたユーザーにはデフォルトの製品アクセスが付与されます。意図せぬコストを防ぐため、デフォルトで付与する製品ライセンスを検討します。
デフォルトでは製品アクセスを提供せず、その後グループの機能を活用して個々の製品アクセスを付与することが推奨されます。
|
ヘルプセンター経由で作成された内部カスタマーにはデフォルトの製品アクセスが付与されます。意図せぬコストを防ぐため、デフォルトで付与する製品ライセンスを検討します。
|
|
権限の管理
|
非公開にするべきサービスデスクを除き、サイトにアカウントを持つ全員がサービスデスクにアクセスできるようにします。
|
非公開にするべきサービスデスクを除き、サイトにアカウントを持つ全員がサービスデスクにアクセスできるようにします。
|
外部戦略
この戦略は、すべてのカスタマーが自社の外部にいる組織に向いています。カスタマーには、クライアント、エンドユーザー、見込みクライアントなどが考えられます。社内でのやり取りはありません。ヘルプセンターを外部に公開することもよくあります。
よくある例: カスタマーサポートチーム、セールスチーム
重視されるポイント: シームレスなアクセス、柔軟性、ブランディング、メール機能
この戦略では外部カスタマーアカウント (ポータル専用カスタマーアカウント) の利用をおすすめします。Atlassian Accessでは、現在外部カスタマーアカウントを管理することはできませんが、エージェントのプロビジョニングや管理を行えます。外部カスタマーアカウントは常に無料かつ無制限です。
|
手順
|
外部カスタマー
|
|---|
|
カスタマーのプロビジョニング
|
セルフサインアップとエージェントアカウント作成の組み合わせが推奨されます。
|
|
ヘルプセンターのセキュリティ設定
|
ほとんどの外部サービスデスクではカスタマーにアカウント作成を許可する設定が推奨されます。
カスタマー基盤に応じて、ログイン不要でアクセスを許可、事前作成済みのアカウントを持つユーザーにのみアクセスを許可など、さまざまなレベルの制限が適用できます。
|
|
製品アクセスの制御
|
外部カスタマーアカウントに製品アクセスを付与することはできません。外部カスタマーアカウントはヘルプセンターにのみアクセスできます。
|
|
権限の管理
|
多くの場合、外部サービスデスクはWeb全体からアクセスできるようにします。制限が必要な場合はカスタマーを組織にまとめ、それらの組織を利用してアクセスを付与することをおすすめします。
|
ハイブリッド戦略
この戦略は、内部カスタマーと外部カスタマーの両方が共存する組織に向いています。多くの場合、カスタマーは2つの独立したディレクトリ内に存在します。外部サービスデスクで起票されたリクエストに内部サービスデスクで対応することも珍しくありません。
よくある例: アドミッションチーム、採用チーム、製品チーム
重視されるポイント: セキュリティ、住み分け
この戦略では内部と外部両方のカスタマーアカウントの利用が必要です。Atlassian Accessは必須ではありませんが、内部カスタマーアカウントの管理を大幅に簡素化するのに役立ちます。成功を実現するには、厳密な権限や堅牢なグループ/組織メンバーシップが必須です。
|
手順
|
内部カスタマー
|
外部カスタマー
|
|---|
|
カスタマーのプロビジョニング
|
内部カスタマーのプロビジョニングにはAtlassian Accessが推奨されますが、管理者がカスタマーを手動でプロビジョニングしたり、他のアトラシアン製品経由でドメインに基づくサインアップを活用することもできます。
内部カスタマーアカウントは接続済みのIdPからグループに基づいて同期できます。
|
外部カスタマーアカウントはAtlassian Accessを利用しないため、セルフサインアップとエージェントアカウント作成の組み合わせを利用する必要があります。
|
|
ヘルプセンターのセキュリティ設定
|
ほとんどのハイブリッドサービスデスクで、カスタマーにアカウント作成を許可することが必要になります。
内部カスタマーアカウントを事前にプロビジョニングしておくことで、サインアップによる競合を防ぐことができます。
|
外部カスタマーは、ヘルプセンターにサインアップまたはメール送信できる必要があります。唯一の例外として、エージェントが外部カスタマーを手動でプロビジョニングする場合があります。
|
|
製品アクセスの制御
|
Atlassian Access経由で同期されたユーザーにはデフォルトの製品アクセスが付与されます。意図せぬコストを防ぐため、デフォルトで付与する製品ライセンスを検討します。
デフォルトでは製品アクセスを提供せず、その後グループの機能を活用して個々の製品アクセスを付与することが推奨されます。
|
外部カスタマーアカウントに製品アクセスを付与することはできません。外部カスタマーアカウントはヘルプセンターにのみアクセスできます。
|
|
権限の管理
|
内部カスタマー用のサービスデスクは、エージェントと管理者が追加したカスタマーに制限する必要があります。このような権限を管理するうえでもっとも効果的な方法はグループの利用で、これは企業管理対象プロジェクトで [管理] > [ユーザー] メニューから行えます。
|
外部カスタマーがリクエストを起票できるよう、少なくとも1つのサービスデスクがweb全体からアクセスできる必要があります。
例外として、すべての外部カスタマーが手動でプロビジョニングされ、個々の権限が設定されることがあります。
組織への手動追加を行うことで、サービスデスクを一部の外部カスタマーに制限できます (サービスレベル、有料契約を持っている顧客や顧客グループの差別化に有用)。
|
|
複数のカスタマーアカウントによる競合
内部カスタマーがヘルプセンターに初めてアクセスしたときに内部カスタマー用のアカウントが事前にプロビジョニングされていないと、外部カスタマーアカウントが生成されます。
このようなユーザーが将来的に内部カスタマーアカウントを作ると、以降は元の外部カスタマーアカウントにアクセスすることはできなくなります。
|
カスタマー管理のビジョン
私たちの目標は、あらゆる種類のビジネスにおいてカスタマーを管理できるような包括的なソリューションの提供です。
具体的には次のようなものがあります。
-
内部のサービス組織用にセキュアかつシームレスなサインインエクスペリエンスを作成
-
外部サービス組織において、すでにIDをお持ちのカスタマーに二重サインインを行わせる労力を無くす
-
複数のユーザーディレクトリの同期を実現し、内部カスタマーと外部カスタマーを効果的に差別化できるようにする
上記のベストプラクティスでは、私たちが今後対応予定のギャップをハイライトしています。以降ではそれらの機能の詳細や、大まかなタイムラインをご紹介します。私たちのねらいは、このようなトピックについて、コミュニティグループ内で幅広い議論を促進することです。
内部カスタマーのドメインに基づくサインアップ
リリース済み - 2022年3月 - 詳細情報
ベストプラクティスでご説明しているように、内部カスタマーにはAtlassianアカウントが最適です。Atlassian Accessを持たない組織でこのアプローチを適用することは難しいでしょう。
この機能では、メールドメインに基づき、カスタマーのセルフサインアップ経由でAtlassianアカウントを作成できるようになります。これは、Jira SoftwareやConfluenceで現在利用されている方法と同様のものです。
機能を有効化すると、ご利用のサイト/組織でドメインに基づくサインアップ対象として追加されたドメインに一致するメールドメインを持っているユーザーを対象に、内部カスタマーアカウント (Atlassianアカウント) が自動的に生成されます。
外部カスタマー用のドメインに基づく許可リスト
リリース済み - 2022年5月 - 詳細情報
特定のグループ/企業と業務を行うお客様の要件を満たせるよう、外部カスタマーアカウント (ポータル専用のカスタマーアカウント) のセルフサインアップを、指定したメールドメインの一覧に制限する方法を提供しています。
これは、お客様の組織で有料契約をお持ちの顧客にのみサポートを提供するようなシナリオで便利です。このような顧客は多くの場合、特定の組織に属します (例: acme.orgとの契約)。このシナリオでは、個々のカスタマーは既知の企業の未知の個人になります。セルフサインアップをacme.orgの任意のユーザーに制限することで、ヘルプセンターを保護しながらお客様のための柔軟性を引き続き提供できます。
外部カスタマーの作成を無効化してセキュリティを向上
リリース済み - 2022年5月 - 詳細情報
Jira Service Managementを内部カスタマーのためだけに利用していると、組織外のユーザー用にプロジェクト管理者やエージェントが外部カスタマーアカウントを作成できる機能はセキュリティ上の懸念になります。この機能により、組織では外部カスタマーアカウント (ポータル専用のカスタマーアカウント) が不要な場合にそれらの作成を無効化できます。
内部カスタマーアクセスをユーザーに明示的に付与
リリース済み - 2023年5月 - 詳細情報
現在、ご利用のアトラシアン組織のユーザー基盤に追加されるすべてのユーザーが、ご利用の各Jiraサイト内で内部カスタマーになります。大規模な組織ではこの仕組みのために制御性が制限されます。
内部カスタマーによるヘルプセンターへのアクセスを付与するためのユーザーロールにより、管理者は各JSMサイトでカスタマーアクセスやエージェントアクセスを付与するユーザー、あるいはそれらを付与しないユーザーを選択できるようになります。
メールドメインに基づき、カスタマーを組織に自動追加
近日提供 - 2023年6月 - https://jira.atlassian.com/browse/JSDCLOUD-4519
外部カスタマーのグループ化には組織 (ご利用のアトラシアン組織とは異なります) が使われます。組織は、権限付与や外部カスタマーアカウント (ポータル専用のカスタマーアカウント) での共有に利用できます。現在、組織へのカスタマー追加は手動でのみ行なえます。
この機能により、管理者/エージェントは組織に自動追加するメールドメインを定義できるようになります。つまり、カスタマーがサインアップしたときに、カスタマーのメールドメインがいずれかの組織と一致すると、対象の組織に自動的に追加されます。
これにより、個々のサービスデスクのアクセス制御が簡単になります。
サービスデスク権限の管理/グループやチームとの共
近日提供 - 2023年12月 - https://jira.atlassian.com/browse/JSDCLOUD-4867
企業管理対象プロジェクトでは、[プロジェクト管理] > [ユーザー] ページで、サービスデスクへの内部カスタマーアクセスにグループを利用できます。これはチーム管理対象プロジェクトでは行えません。この機能をカスタマーページに動かし、すべてのプロジェクトタイプで利用できるようにすることがねらいです。
この機能の提供に向けて、現在の組織と同じように、1つのグループ内のカスタマー間でチケットを共有できるようにしたいと考えています。
ここにはチームへの機能拡張も含まれます。
外部カスタマーアカウントのSAML/SSOオプション
近日提供 - 2023年7-9月 - 詳細情報 - https://jira.atlassian.com/browse/JSDCLOUD-630
現在、Atlassian AccessによるSAML/SSOは内部カスタマー (Atlassianアカウント) でのみ利用できます。この機能を外部カスタマーアカウント (ポータル専用のカスタマーアカウント) に拡張します。
ここでの目標は、Atlassian Access内のアイデンティティプロバイダー (IdP) 設定で、グループを外部カスタマーアカウントに委任できるようにし、その後それらのカスタマーグループをJira Service Managementサイトに紐付けることです。
最終的には、組織が自社のユーザーディレクトリを利用して自社のカスタマーをシームレスに認証できるようにしたいと考えています。
