Microsoft Fabric 導入ロードマップ: ユーザーサポート

[アーティクル]
11/20/2023

Note

この記事は、"Microsoft Fabric 導入ロードマップ" シリーズ記事の一部です。シリーズの概要については、「Microsoft Fabric 導入ロードマップ」を参照してください。

この記事では、ユーザーサポートを取り上げます。主に問題の解決について説明します。

この記事の最初のセクションでは、組織の内部で制御できるユーザーサポートの側面に焦点を当てます。最後のトピックでは、使用可能な外部リソースに焦点を当てます。

社内の Fabric ユーザーコミュニティに提供されるスキルメンタリング、トレーニング、ドキュメント、共同開発支援など、関連トピックの説明については、「メンタリングとユーザーの有効化」を参照してください。これらのアクティビティの効果により、公式なユーザーサポートリクエストの量を大幅に削減し、全体的なユーザーエクスペリエンスを向上できます。

ユーザーサポートの種類

ユーザーに問題が発生している場合に、解決するためにどのようなオプションがあるか把握していますか?

次の図は、組織で成功裏に採用される一般的な種類のユーザーサポートを示しています。

Diagram shows the four types of internal Fabric user support, and the two types of external support, which are described in the table below.

上の図に示す 6 種類のユーザーサポートは次のとおりです。

Type	説明
	チーム内サポート (内部) は非常に非公式です。サポートは、チームメンバーが自分の仕事の自然な過程で互いに学ぶときに発生します。
	社内コミュニティサポート (内部) は、非公式、公式、または両方で編成できます。これは、同僚が社内コミュニティチャネルを介して互いに対話するときに発生します。
	ヘルプデスクサポート (内部)は、正式なサポートの問題やリクエストを処理します。
	拡張サポート (内部) には、ヘルプデスクからエスカレートされた複雑な問題の処理が含まれます。
	Microsoft サポート (外部) には、ライセンスを保有しているユーザーと Fabric 管理者のサポートが含まれます。包括的なドキュメントも含まれます。
	コミュニティサポート (外部) には、専門家、Microsoft Most Valued Professional (MVP)、およびフォーラムに参加してコンテンツを公開する愛好家の世界規模のコミュニティが含まれます。

一部の組織では、チーム内サポートと社内コミュニティサポートがセルフサービスデータとビジネスインテリジェンス (BI) に最も関連しています (コンテンツは、分散されたビジネスユニットで作成者と所有者によって所有および管理されます)。逆に、ヘルプデスクと拡張サポートは、技術的な問題とエンタープライズデータと BI のために保持されます (コンテンツは、一元化された BI チームまたはセンターオブエクセレンスによって所有および管理されます)。一部の組織では、4 種類のサポートすべてが、任意の種類のコンテンツに関連している場合があります。

ヒント

ビジネス主導のセルフサービス、管理されたセルフサービス、エンタープライズデータと BI の概念について詳しくは、「コンテンツの所有権と管理」の記事を参照してください。

この記事では、上に紹介した 6 種類のユーザーサポートについて詳しく説明します。

チーム内サポート

チーム内サポートとは、チームメンバーが毎日の作業中に互いに学び、助け合う場合を指します。エキスパートとして登場するセルフサービスコンテンツの作成者は、支援したいという本質的な気持ちを持っているため、このような非公式なサポートの役割を自主的に引き受ける傾向があります。これは非公式のサポートモードですが、過小評価すべきではありません。一部の推定では、仕事での学習の大部分がピアラーニングであることが示されています。これは、ドメイン固有の分析ソリューションを作成するアナリストにとって特に役立ちます。

Note

チーム内サポートは、部署内で唯一のデータアナリストである個人にはうまく機能しません。また、組織内でまだあまり多くのつながりを持っていない人には効果的ではありません。頼れる親しい同僚がいない場合は、この記事で説明されている他の種類のサポートが重要になります。

社内コミュニティサポート

多くの場合、コミュニティのメンバーからの支援は、実践共同体に特化して設定されたディスカッションチャネルまたはフォーラムでのメッセージの形式を取ります。たとえば、DAX 計算の動作に問題があるというメッセージを誰かが投稿し、インポートすべき適切な Python モジュールを探しているとします。その後、組織内の他のユーザーから、提案またはリンクを含む回答を受け取ります。

ヒント

社内 Fabric コミュニティの目標は自己維持であり、それは公式なサポートの需要とコストの削減につながる可能性があります。さらに、純粋に一元化されたアプローチと比較して、より広範な規模で行われる管理されたセルフサービス型のコンテンツ作成が推進される可能性もあります。ただし、社内コミュニティの監視、管理、および育成が常に必要になります。具体的なヒントを 2 つ示します。

T-SQL、Python、Data Analysis eXpressions (DAX)、Power Query M 数式言語のような難しいトピックでは、複数のエキスパートを養成してください。コミュニティのメンバーが専門家として認識されると、支援の依頼が多すぎて過度の負担がかかる場合があります。
特定の種類の質問 (レポートの視覚化など) には多くのコミュニティメンバーがすぐに回答できるのに対し、その他の質問 (複雑な T-SQL や DAX など) に回答できるメンバーは少なくなります。 COE は、コミュニティに応答の機会を与える一方で、未回答の質問を迅速に処理することが重要です。ユーザーが繰り返し質問しても回答が得られない場合は、コミュニティの成長が大幅に妨げられる可能性があります。この場合、ユーザーは質問に対する回答を得られないと、離れて戻ってこない可能性が高くなります。

社内コミュニティのディスカッションチャネルは、通常、Teams チャネルまたは Yammer グループとして設定されます。テクノロジの選択は、ユーザーが既に作業している環境に基づいて行い、アクティビティが自然なワークフロー内で行われるようにする必要があります。

社内ディスカッションチャネルの利点の 1 つは、元の要求者が会ったことのないユーザーから回答を得られることです。大規模な組織では、実践共同体によって共通の関心を持つ人々が集められます。これによって多様な視点が確保され、互いに助け合ったり、全般的な知識を学ぶことが容易になります。

社内コミュニティのディスカッションチャネルを利用することで、センターオブエクセレンス (COE) では、ユーザーがどのような質問をしているかを観察できるようになります。これは、ユーザーに発生している問題を COE で把握する 1 つの方法です (一般的にはコンテンツの作成に関連していますが、コンテンツの使用に関連している可能性もあります)。

ディスカッションチャネルを監視すると、これまで COE に知られていなかった他の分析の専門家や潜在的なエキスパートを発見できる可能性もあります。

重要

新たなエキスパートを継続的に特定し、彼らと協力して同僚をサポートする体制を整えることがベストプラクティスです。実践共同体に関する記事で説明されているように、COE ではディスカッションチャネルを積極的に監視して、誰が役立っているのか確認する必要があります。 COE では、意識的に彼らを奨励し、サポートする必要があります。また、適切と判断される場合には、彼らをエキスパートネットワークに招待する必要があります。

ディスカッションチャネルのもう 1 つの主な利点は、検索可能であり、他のユーザーが情報を発見できることです。ただし、ユーザーにとって、プライベートメッセージや電子メールではなくオープンフォーラムで質問することは、習慣を変えることです。ここで十分に注意しなければならないのは、このような公開された方法で質問することに抵抗感を抱く人もいるということです。知らないことを率直に認めることになり、恥ずかしく感じるためです。この消極的な考え方は、自信を与える友好的で有益なディスカッションチャネルを促進することによって、時間の経過につれて軽減される可能性があります。

ヒント

コミュニティからの最も一般的で簡単な質問の一部を処理するボットを作成したくなるかもしれません。ボットは、"ライセンスを要求するにはどうすればよいか"、"ワークスペースを要求するにはどうすればよいか"などの単純な質問に対応できます。このアプローチを採用する前に、ユーザーエクスペリエンスを悪化させるのではなく向上させるような、日常的で予測可能な質問が十分にあるかどうかを検討してください。多くの場合、よくできた FAQ (よく寄せられる質問) の方がうまく機能し、開発も速く、保守も容易です。

ヘルプデスクサポート

ヘルプデスクは、通常、IT 部門が担当する共有型のサービスとして運営されます。なるべく公式なサポートチャネルを利用しようとする傾向が強いのは、次のようなユーザーです。

経験の少ないユーザー。
組織に新しく入った。
社内ディスカッションコミュニティへのメッセージ投稿に消極的。
組織内のつながりや同僚が不足している。

場合によっては、IT 部門が直接対応しないと完全には解決できない技術的問題も発生します。コンピューターが IT 部門で管理されている場合のソフトウェアのインストールや、アップグレードの要求などです。

多忙なヘルプデスク担当者は、通常、複数のテクノロジのサポートに専念しています。そのため、解決策が明確で、ナレッジベースで文書化できるようなタイプの問題には、きわめてスムーズに対応できます。たとえば、ソフトウェアインストールの前提条件の問題などです。

組織によっては、非常にシンプルな障害対応の問題のみをヘルプデスクに担当させている場合もあります。また、組織によっては、ヘルプデスクに反復性のある問題を担当させている場合もあります。たとえば、新しいワークスペースの要求、ゲートウェイのデータソースの管理、新しい容量の要求などです。

重要

Fabric ガバナンスの決定は、ヘルプデスクのリクエスト量に直接影響します。たとえば、テナント設定でワークスペースの作成アクセス許可を制限すると、ユーザーがヘルプデスクチケットを提出することになります。これは正当な意思決定ではありますが、リクエストにきわめて迅速に対応するための準備を整えることが必要になります。この種のリクエストには、1 ～ 4 時間以内に対応する必要があります (可能な場合)。対応が遅すぎると、ユーザーは既にあるものを使用したり、要件を回避する方法を見つけたりします。状況にもよりますが、これは理想的なシナリオとは言えません。特定のヘルプデスクリクエストでは、迅速さが重要です。 Power Apps と Power Automate を使用した自動化を検討してください。これにより、一部のプロセスを効率化できる可能性があります。詳しくは、「テナントレベルのワークスペース計画」を参照してください。

時間の経過とともに、ヘルプデスクの担当者が Fabric のサポートに関する知識と経験を深めるにつれて、トラブルシューティングと問題解決のスキルがより効果的になります。最も優れたヘルプデスク担当者は、ユーザーが何を達成する必要があるのかを十分に把握しています。

ヒント

純粋に技術的な問題、たとえば、データの更新の失敗や、ゲートウェイのデータソースに新しいユーザーを追加する必要性などには、通常、サービスレベルアグリーメント (SLA) に関連付けられている単純な対応が行われます。たとえば、障害となっている問題に 1 時間以内に対応し、8 時間以内に解決するという SLA がある場合があります。一般に、データの不整合などのトラブルシューティングの問題に関する SLA を定義するのは、より困難です。

拡張サポート

COE は、Fabric が組織全体でどのように使用されているかについての詳細な分析情報を持っているため、複雑な問題が発生した場合の拡張サポートに最適です。サポートプロセスに COE を参加させる場合は、エスカレーションパスを使用する必要があります。

多くの場合、COE メンバーはビジネスユーザーによく知られているため、リクエストを純粋にヘルプデスクからのエスカレーションパスとして管理することは困難です。適切なチャネルを使用する習慣を奨励するために、COE メンバーは、ヘルプデスクチケットを提出するようにユーザーを誘導する必要があります。これにより、ヘルプデスクリクエストを分析するためのデータ品質も向上します。

Microsoft のサポート

この記事で説明されている内部ユーザーサポートのアプローチに加えて、ユーザーと Fabric 管理者が直接利用できる、見落とさないようにする必要がある重要な外部サポートオプションがあります。

Microsoft ドキュメント

すべてのお客様に幅広く影響を与える高優先度の問題については、Fabric サポート Web サイトを確認してください。 Microsoft 365 のグローバル管理者は、Microsoft 365 ポータル内で追加のサポート問題の詳細にアクセスできます。

包括的な Fabric ドキュメントを参照してください。これは、トラブルシューティングや情報の検索に役立つ、信頼できるリソースです。ドキュメントサイトからの結果に優先順位を設定できます。たとえば、サイトを対象とした検索要求を Web 検索エンジンに入力します (power bi gateway site:learn.microsoft.com など)。

Power BI Pro と Premium Per User のエンドユーザーサポート

ライセンスを持つユーザーは、Microsoft にサポートチケットを起票する資格があります。

ヒント

社内ヘルプデスクに技術的な問題を報告するかどうかを、社内のユーザーコミュニティに対して明確にしてください。ヘルプデスクがそのワークロードを処理する機能を備えている場合は、一元化された社内エリアにユーザーの問題を収集することにより、ユーザーが各自で問題解決を試みるよりも、ユーザーエクスペリエンスを向上させることができます。サポートの問題を可視化して分析することも、 COE に役立ちます。

管理者のサポート

Fabric 管理者には、利用できるサポートオプションがいくつかあります。

Microsoft 統合サポート契約を締結しているお客様の場合は、ヘルプデスクと COE のメンバーに Microsoft Services Hub へのアクセスを許可することを検討してください。 Microsoft Services Hub の利点の 1 つは、ヘルプデスクと COE のメンバーがサポートリクエストを提出および表示できるように設定できることです。

世界的コミュニティのサポート

この記事で説明されている内部ユーザーサポートのアプローチと、前述の Microsoft サポートオプションに加えて、世界規模の Fabric コミュニティを活用できます。

世界規模のコミュニティは、ドメイン知識がなくても質問を簡単に理解できるとき、かつ機密データや機密性のある内部プロセスが関与しないときに役立ちます。

一般公開されているコミュニティフォーラム

公開されているコミュニティフォーラムがいくつかあり、ユーザーはそこで問題を投稿して、世界中のユーザーから応答を受け取ることができます。誰からでも、どこからでも回答を得られるということは、非常に強力で有効な手段となります。ただし、どのパブリックフォーラムでもそうですが、フォーラムに投稿されたアドバイスや情報を検証することが重要です。インターネットに投稿されたアドバイスは、自社の状況には適さない可能性もあります。

一般公開されているディスカッションエリア

Fabric に関する技術的な質問がソーシャルメディアプラットフォームに投稿されることはよくあります。ディスカッション、投稿アナウンス、およびユーザーが互いに支援する様子を見ることができます。

コミュニティのドキュメント

Fabric グローバルコミュニティは活発です。毎日、Fabric のブログ記事、記事、ウェビナー、ビデオが多数公開されています。コミュニティの情報に基づいてトラブルシューティングを行う場合は、次のことに注意してください。

情報は最近のものか。公開日や最終更新日を確認するようにしてください。
オンラインで見つかった解決策の状況とコンテキストが、自分の状況に本当に適合するか。
提示されている情報の信頼性。評判の良いブログやサイトを利用するようにしましょう。

考慮事項と主なアクション

チェックリスト - 以下は、ユーザーサポートのために実行できる考慮事項と主なアクションです。

チーム内サポートを改善する:

活動を表彰し、激励する: 実践共同体に関する記事で説明されているように、エキスパートにインセンティブを提供しましょう。
貢献者を評価する: 有意義な草の根的取り組みが行われているのを見たら、それを評価し、称賛しましょう。
正式な役割を定める: チーム内での非公式な取り組みでは十分に対応できない場合は、必要な役割を公式に規定することを検討しましょう。必要であれば、期待される貢献と責任の内容を人事部門の職務記述書に明記するようにしましょう。

社内コミュニティのサポートを改善する:

質問を継続的に奨励する: 指定されたコミュニティディスカッションチャネルで質問するようにユーザーに勧めましょう。時間の経過につれて習慣が形成されると、それを最初のオプションとして使用することが常態になります。時間の経過と共に進化して、より自立したものになります。
ディスカッションエリアを積極的に監視する: 適切な COE メンバーが当該のディスカッションチャネルを積極的に監視するようにしましょう。回答されていない質問が残っている場合は介入したり、回答を改善したり、必要に応じて修正したりできます。また、既存のリソースの認知度を高めるために、追加情報へのリンクを掲載することもできます。コミュニティの目標は自立することですが、その監視と育成には専用リソースが引き続き必要です。
利用可能なオプションを周知する: ユーザーに、社内コミュニティのサポートエリアの存在を認識させるようにしましょう。リンクを目立つように表示したり、ユーザーコミュニティへの定期的な連絡にリンクを含めたりするのも有効です。 Fabric ポータルのヘルプメニューのリンクをカスタマイズして、ユーザーを内部リソースに誘導することもできます。
オートメーションを設定する: ライセンスを所有しているすべてのユーザーが、コミュニティのディスカッションチャネルに自動的にアクセスできるようにしましょう。グループベースのライセンスを使用して、ライセンスの設定を自動化できます。

社内ヘルプデスクのサポートを改善する:

ヘルプデスクの職務を規定する: ヘルプデスクが対応を担当する Fabric サポートトピックの初期範囲を決定します。
準備レベルを評価する: Fabric のサポート業務に対してヘルプデスクの体制が整っているかどうかを確認しましょう。対応力に不足がないかどうかを確認するようにしましょう。
追加のトレーニングを手配する: 知識移転セッションやトレーニングセッションを実施して、ヘルプデスクスタッフを訓練しましょう。
ヘルプデスクのナレッジベースを更新する: 既知の質問と回答を、検索可能なナレッジベースに格納します。時間の経過につれて新機能や機能強化を反映するために、ナレッジベースに対する定期的な更新を担当するユーザーを確保します。
チケット追跡システムを設定する: ヘルプデスクに送信されたリクエストを追跡するための適切なシステムが整っているかどうかを確認しましょう。
Fabric に関する問題への応答態勢を確認する: 必要に応じて、365 日 24 時間のサポート体制を規定します。
どのような SLA が存在するかを確認する: 特定のサービスレベルアグリーメント契約が存在する場合は、対応と解決のための体制を明確に文書化し、伝達するようにしましょう。
迅速に対応するための準備を整える: 特定の一般的問題については、きわめて迅速に対処できるように準備しましょう。サポートの対応が遅いと、ユーザーが回避策を探すことになります。

社内 COE による拡張サポートを改善する:

エスカレーションされたサポートの内容を規定する: ヘルプデスクでは直接処理できないリクエストのエスカレーションパスを決めましょう。必要な場合に COE (または同等の担当者) が介入できる体制になっているかどうかも確認しましょう。どこまでがヘルプデスクの責任で、どこからが COE 拡張サポートの責任かを明確に定義します。
COE とシステム管理者とのコラボレーションを促進する: COE メンバーと Fabric 管理者が Microsoft 365 や Azure のグローバル管理者に連絡するための直接的なエスカレーションパスを確保します。 Fabric の範囲を超える広範な問題が発生したときのために、伝達チャネルを設定することが非常に重要です。
COE からヘルプデスクへのフィードバックループを作成する: COE が新しい情報を得た際には、IT ナレッジベースを更新する必要があります。目標は、主要なヘルプデスク担当者が能力を継続的に向上させ、今後さらに多くの問題を処理できるようになることです。
ヘルプデスクから COE へのフィードバックループを作成する: サポート担当者は、冗長性や非効率性に気付いた場合に、その情報を COE に伝達することがあります。その場合は、COE がナレッジベースを改善したり、対応に参加したりする可能性があります (特に、ガバナンスやセキュリティに関連する場合)。

確認事項

以下のような質問を使用して、ユーザーサポートを評価します。

エンタープライズデータと BI ソリューションのサポートを担当するのは誰ですか? セルフサービスソリューションについてはどうですか?
重要な問題を効果的に検出して優先順位を付けるために、問題のビジネスへの影響と緊急性をどのように識別していますか?
ビジネスユーザーがデータと BI ソリューションの問題を報告するための明確なプロセスがありますか? エンタープライズとセルフサービスの各ソリューションの違いは何ですか? エスカレーションパスはどのようになっていますか?
コンテンツの作成者とコンシューマーは、通常、どのような種類の問題を経験しますか? たとえば、データ品質の問題、パフォーマンスの問題、アクセスの問題などを経験しますか?
解決されずに終了する問題がありますか? 現在、データ項目またはレポートに "既知の問題" がありますか?
データ資産の所有者がセルフサービス BI ソリューションの問題を COE などの中央チームにエスカレートするためのプロセスが設定されていますか?
データと既存のソリューションの問題の頻度はどのくらいですか? これらの問題のうち、ビジネスのエンドユーザーに影響を与える前に見つかった割合はどのくらいですか?
通常、問題の解決にはどのくらいの時間がかかりますか? このタイミングはビジネスユーザーにとって十分ですか?
最近の問題の例と、ビジネスへの具体的な影響はどのようなものですか?
エンタープライズチームとコンテンツの作成者は、Fabric の問題を Microsoft に報告する方法を知っていますか? エンタープライズチームはコミュニティリソースを効果的に活用して重大な問題のブロックを解除できますか?

注意事項

ユーザーサポートを評価し、リスクや問題を説明するときは、個人やチームを非難しない中立的な言語を使用するように気をつけてください。評価ですべてのユーザーの視点が公平に表されるようにします。コンテキストを正確に理解して説明するために、客観的な事実に焦点をあてます。

成熟度レベル

次の成熟度レベルは、Power BI ユーザーサポートの現在の状態を評価するのに役立ちます。

Level	ユーザーサポートの状態
100: 初期	• 個々のビジネスユニットが、相互にサポートする効果的な方法を見つけます。ただし、戦術や手順がサイロ化されており、一貫して適用されていません。 • 社内のディスカッションチャネルを利用できます。ただし、注意深く監視されてはいません。そのため、ユーザーエクスペリエンスに一貫性がありません。
200: 反復可能	• COE が、チーム内サポートとエキスパートネットワークの促進を積極的に奨励しています。 • 社内のディスカッションチャネルが活発です。質問やディスカッションのための既定の場所として知られるようになりました。 • ヘルプデスクが、テクニカルサポートの最も一般的な問題のごく一部を処理します。
300: 定義済み	• 社内のディスカッションチャネルがよく知られていて、おおむね自立しています。 COE では、ディスカッションチャネルを積極的に監視および管理して、すべての質問が迅速かつ正確に回答されるようにしています。 • サポートの頻度、応答のトピック、および優先順位を監視するためのヘルプデスク追跡システムが確立されています。 • COE が、必要に応じて適切な拡張サポートを提供しています。
400: 可能	• ヘルプデスクが十分に訓練されていて、既知の、または予想されるテクニカルサポートの問題に幅広く対応する準備が整っています。 • SLA が締結され、ヘルプデスクサポートの内容 (拡張サポートを含む) が定義されています。サポート内容は文書化され、すべての関係者に明確に伝達されています。
500: 効率的	• ヘルプデスクと COE の間に双方向のフィードバックループが存在します。 • 主要業績評価指標によって、満足度とサポート方法が測定されています。 • ヘルプデスクの対応を迅速化し、ミスを減らすために、自動化が設定されています (API やスクリプトの使用など)。