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

Note

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

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

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

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

ユーザー サポートの種類

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

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

上の図に示す 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 やスクリプトの使用など)。

関連するコンテンツ

Microsoft Fabric 導入ロードマップ シリーズの次の記事では、システムの監視と管理のアクティビティについて説明します。