2021年2月

2021年2月16日 (火)

Power Virtual Agents for Teams を使って手軽にチャットボットが作れることは下記で説明しました。

Microsoft Teams 用 Power Virtual Agents を使ったチャットボット作成を試そう - SharePoint Technical Notes (weblogs.jp)

このチャットボット開発ですが、基本的には質問に対する回答をフローロジック内に用意していかなくてはいけません。しかし、すでに FAQ などの情報を持っているとすると、これをロジック内に書き写していき、条件分岐をしていく作業は途方もないものです。

そんな時に組み合わせて利用したいのが QnA Maker です。Azure Cognitive Services が提供するサービスの一つであり、ボット作成を支援するものです。

QnA Maker

QnA Maker についてはネット上に多くの情報が見つかるので、ご存じなければ検索してみましょう。この QnA Maker ではあらかじめ質問と回答のペアを複数用意しておきます。これは手動で作成してもいいし、Excel や PDF, Word, Tsv 形式のファイルなどから読み込ませることができます。

下記の図は SharePoint に関する質問を書き溜めている QnA Maker 上に構築しているナレッジベースです。左側が質問、右が回答です。

QAMaker - KB

ボットはこの内容を一問一答で返すわけではなく、話し言葉で問いかけられると、AIによりその内容を推測し適切な回答を見つけ出してくれます。Power Virtual Agents はこのナレッジベースと組み合わせて、ユーザーからの質問に回答することもできるようになっています。

実際に実験した結果が次のビデオです。音声はありません。右が QnA Maker の KB (ナレッジベース) であり、左がチャットボットです。一問一答ではなく、自然に会話しながら内容を推測し、回答を提示していくれていることがわかると思います。

Power Virtual Agents から QnA Maker を呼び出して利用する手順は次の資料が参考になります。

チュートリアル:Power Virtual Agents との統合 - QnA Maker - Azure Cognitive Services | Microsoft Docs

だだし、この内容が Power Virtual Agents 用であり for Teams にはなっていないので少し読み替える部分があります。たとえば、QnA Maker の呼び出しはシステム フォールバックで設定するのですが、これは次のように設定します。

2021-02-16_1-17-42

また作成する Power Automate のフローは「Power Virtual Agents Flow Template」で作成すればよいです。このあたりの説明も少し違っています。

2021-02-16_1-27-25

以上のポイントに注意して、手順に従って QnA Maker と連携させてみてください!

 

 

2020年秋に Dataverse for Teams が登場したおかげでユーザーが手軽にチャットボットを作成できる Power Virtual Agents for Teams が利用できるようになりました。Teams 内で利用する分には追加のコストがかからないのが魅力です。

さて、この Power Virtual Agents  for Teams を手始めに利用してみようと思う方は、下記リンク先にあるクイックスタートガイドがお勧めです。

クイックスタート: Microsoft Teams でボットを作成して展開する - Power Virtual Agents | Microsoft Docs

この手順に従ってチャットボットを作成すると「休暇を取得したい」「休日を知りたい」といった質問にボットが答えてくれます。

実際に構築してみた内容をビデオにしています。音声はありませんが、ボットの会話部分を見ていただくと何ができるのかをイメージできると思います。

単に質問に答えるように構成するだけではなく、Power Automate と組み合わせることで、Teams 経由で担当者に連絡をつなぐように構成することもできます。

挙動がある程度わかったら、ぜひボット開発にチャレンジしてみてください! 

2021年2月15日 (月)

私が実施している SharePoint の研修では3年ほど前から「サブサイトを作らずに SharePoint ハブを導入しましょう」という話をずっとしてきています。また拙書の「ひと目でわかるOffice 365 導入・管理編」の書籍でもこのことに触れています(※ひと目~は2017~2018年にかけて書いた内容なので、あっという間に古くなってしまいましたが...) 。

が、よく考えるとこのブログでは SharePoint ハブについて触れていなかったなと思ったので、改めてここに書いておきたいと思います。

特にこれから SharePoint のモダンサイトの導入を検討している方は サブサイトは塩漬けにして新たに作るサイトは「SharePoint ハブを使わないという選択肢はない」という心づもりでいてください。すでに登場している様々な SharePoint ポータルの新機能群はサブサイトがあることを考慮していません。ハブサイトを使うことが前提です。ニュース Webパーツもしかりです。

これまでの SharePoint : サイトコレクションとサブサイト

SharePoint サイトを構築するときに、従来はサイトコレクションを作成してその中に複数のサブサイトを作成するという方法をとってきました。

従来のサイト構造

この概念はさかのぼると オンプレミスの SharePoint Server 2007 から始まったものです。それから10年が経ち、このサイト構成の抱えている課題を新たなアプローチで解決していこうという取り組みの一つが「SharePoint ハブ」なのです。ですから、SharePoint ハブって何がいいの? と思った方は現在サイトコレクション構造について問題はないのか、一度考えてみてください。

サイトコレクションとサブサイトの構造が抱える課題について考える

課題について考えるために、よくある問題を取り上げてみましょう。

いったん作成したサブサイトは別のサイトコレクションに手軽に移動することができません。これをやろうとすると、3rd パーティの管理ツールを購入するとか、自前でプログラムを書くとかして既存サイトの内容を別のサイトコレクションのサブサイトにコピーしなくてはいけません。これは非常に大がかりです。仮に移動できたとしても既存のコンテンツへのリンク切れが発生することもあるでしょう。権限も一から再設定する必要があります。どれくらいの時間とコストと労力が必要になりそうか、なんとなくイメージできるのではないでしょうか。

ところで、そもそもサイトの移動が必要になるのは、どんなニーズなのか。たとえば、サイトコレクションの分け方のルールが業務にあたる人の作業動線にあっていないケースなどがありますし、組織改編も少なからず影響します。

たとえば、IT部全体が提示するルールとして本社と関連会社とでサイトコレクションを分ける決まりにしていたとします。業務内容を吟味してサイト構造を考えていくのではなく、あらかじめ決めたユーザーの種類(この例では本社のひとか関連会社のひとか)で分けるルールにとりあえず乗っかってしまう。ですが、実際には2つのサイトで実は同じ業務を実施しなければいけないことが分かった。具体的には関連会社も含めて社内研修の実施を管理するような場合があげられるでしょう。研修の申し込みの手続きや研修のレポートの提出などの流れは、実はどちらも一緒なのにサイトが複数に分かれてしまう。これにより社内の研修担当の方は複数のサイトを管理しなくてはならなくなります。

このようにサイトをとりあえず分けたのはいいけど、実際に使い始めると、一緒に管理したほうがいいな、ということは少なくありません。

また同一サイトコレクション内にサブサイトを作っていく場合も、SharePoint Server 2007 で得た教訓として「サブサイトの階層が深くなりすぎると管理が煩雑になる」というのがわかっているので、SharePoint Server 2010 のころから(2010年あたりから) たいていはトップレベルサイトの配下の2階層目に複数のサイトを作成していくという構成をとってきました(このように提案するコンサルタントが多かったはずです)。どう管理が煩雑なのか? たとえば、階層が3階層あるとして、2階層目のサイトが不要になったとします。不要なサイトは削除したい。ですが、2階層目は3階層目にサイトがぶら下がっているので削除できません。また、3階層目のサイトを2階層目に格上げしようとしたとします。これは簡単な設定で格上げできたのですが、課題としてはURLが変わるのでリンク切れが起きやすいこと。そして、設定によってはアクセス権限が変わる可能性がある。サイトは親子関係にしている場合は親サイトから権限の継承ができるためです。

もちろん最初からうまく柔軟性のあるサイト構造の計画が立てられればいいのですが、実際にはやってみないと分からないことも多いのです。そこで大事になるのが「サイト同士の構成を柔軟に変更できる」という考え方です。SharePoint ハブではこの課題を少ない手間で克服できる仕組みが用意されています。

ちなみに、従来のサイト構造の考え方には、「なるべく関連するサイトは同一のサイトコレクションの中にサブサイトを作ることでまとめあげていく」とうものがありました。これによる恩恵の一つは、同一サイトコレクション内ならナビゲーションが共通化しやすい点が挙げられます。特に 「SharePoint Server 発行インフラストラクチャー」という機能をアクティブ化することで、サブサイトを容易にナビゲーションに追加できるようになっていました。しかし、モダンサイトではどうでしょう? 前述したサイトコレクションのフィーチャーである「SharePoint Server 発行インフラストラクチャー」のアクティブ化はサポートされません。発行機能は新しい仕組みが標準搭載となり、レガシーな発行機能は使う必要がなくなったためです。ナビゲーション構造も SharePoint ハブという新しい概念により、前述のフィーチャーに頼らなくてもよくなっています。

サブサイトを作成せずにハブで構成するメリットとは?

ここでそろそろ本題に入りましょう。

SharePoint ハブは、SharePoint の検索エンジンの大幅増強の恩恵を受け満を持して登場した仕組みです(ちなみに、SharePoint の検索エンジンは現在、Microsoft Search という上位概念の一部として位置づけられています)。

SharePoint ハブを利用するメリットとして押さえてもらいたいのは次のポイントです。

  • サブサイトという物理的な階層構造を取りやめ、複数のサイトコレクションを論理的にひと塊にできる
  • ひと塊といっても階層構造にはなり、ハブサイトとファミリーサイトという2階層構造になる
  • ひと塊にするときハブナビゲーションと呼ばれる共通ナビゲーションが利用できるようになる
  • 論理構成なので、手軽にサイトの階層構造が変更できる
  • 検索範囲として「ハブ」全体の検索もできる

SharePoint ハブの全体構成は車輪を想像すると分かりやすいでしょう。車輪のハブがあり、そこから放射線状に車軸がでます。

車軸

SharePoint でハブサイト構造にする場合は、まずは SharePoint 全体管理者または Microsoft 365 全体管理者が任意のサイトをハブとして設定します。このサイトはチームサイトでもコミュニケーションサイトでも、クラシックサイトでもモダンサイトでも構いません。といってもハブナビゲーションを利用できるのはモダン表示になっているサイトであるため、クラシックサイトでもサイトページやモダンリストやライブラリが構成されていることが望ましいといえます。このハブサイトに任意のサイトをファミリーサイトとして論理的に接続していきます。 SharePoint Hub

1つのテナント内で指定できるハブサイトの数は2,000サイトまでとなっています。ファミリーサイトには数の制限はありません。ファミリーサイトは、必ず1つのハブサイトを持ちます。複数のハブサイトを持つことはできません。ハブサイトを「親分」とするなら、各サイトはどのハブにも所属せず1匹狼でいるか、もしくはハブに接続して親分を1人持つかのいずれかになるということです。

サイトコレクション内のサブサイト構成というのは、物理的な構造でした。そのため柔軟性に欠けるところが少なからずあったわけです。一方でハブサイトでの構造は、サブサイトはやめてサイトコレクションを論理的に階層化しようというコンセプトです。論理的な接続構成なので、各サイトのハブの接続の解除も別のハブへの接続も一瞬です。アクセス権限はそのまま温存されます。サイトコレクションのトップレベルサイト同士を接続することになるので、URLはハブに入ろうが入るまいが変わりません。サイトの構造変化に強いということです。

このあたりの説明は実際のサイトでのデモをしたほうがわかりやすいと思うので、ビデオにしましたのでご確認ください。

サイトコレクションという概念はサイトをひと塊として扱うための仕組みです。しかし、新たな SharePoint ハブの登場によりサイトコレクションを使ったサイトの塊を作る必要がなくなりました。そのため SharePoint に関する公式資料でもサイトコレクションという言葉は徐々に使われなくなってきています。サイトコレクションといいつつ、サイトはトップレベルサイトのみ。1つしかないので、単に「サイト」という表現に変わってきています。現に、SharePoint 管理センターでも実質サイトコレクションの管理なのですが、「サイト」という言葉が使われています。

SharePoint 管理センター

Microsoft Teams と SharePoint の関係

新型コロナの感染拡大により、多くの組織で Microsoft Teams の導入が加速度的に進みました。このMicrosoft Teams ですが、この中には複数のチームを作成できるようになっています。業務チームによる業務遂行を効率化するために、これを使えるようになっているわけです。

各チームには、かならずチームごとに SharePoint のチームサイトが作成され接続されるようになっています。これを切り離すことはできません。

Teams と SharePoint

ここで作成されるサイトとはサイトコレクションです。つまり、チームの数だけサイトコレクションが増えていきます。サブサイトを作ることを当たり前に考えていたとしても、実際にはすでにサブサイトを使わない多くのサイトコレクションが存在しているわです。業務チームで何か仕事をしようとするとき、いちいちサブサイトを作って、権限設定をしてナビゲーションなどを整えて、、、なんてことをしている時間がもったいないし、ある程度 SharePoint の専門知識をもっていなければこうした作業ができません。ですが、ユーザーが思い立ったらすぐに仕事仲間に情報を連携できるようにすることを最優先に考えれば、すでに出来上がっているサイトを使うのが最善策です。効率よく仕事をしたいからです。

このようにサイトコレクションが多く作成されていくので、あとから関連があるサイトをひとまとめにしたいというニーズも出てくるはずです。関連する情報をアクセスしやすくする手段としてこうしたチームサイトをハブとしてまとめていくこともできるということです。

サイト構成を抜本的に見直そう

オンプレミスの SharePoint やクラシック SharePoint を使っている方は、従来のサイト管理の発想から大きく転換期を迎えていることをぜひ意識してください。以前の考え方とは大幅に異なります。

これまではサイトコレクションとサブサイトに縛られたサイト設計を強いられてきました。ですが、それは当時は最善だったものの、現在はよりよい方法として SharePoint ハブの概念が導入されています。このタイミングでサイトの仕分け方もぜひ一度、抜本的に見直してみてほしいと個人的には思っています。

サイトは用途別で細分化していっていいです。増えても構いません。ハブという論理構成の登場により、分割されたサイトも柔軟にひと塊にできるようになりました。そして、前述したとおり SharePoint の検索機能は従来にAI の貢献もあり、比べて飛躍的によくなっています。「お知らせ」リストはやめて、ニュースを使って情報を共有していくようにします。ニュースの配信元のカテゴリはサイトです。総務とか経理とかといった組織単位でサイトを作るという固定観念に縛られないことです。業務シナリオに沿ってサイトを再構成することを検討してみてください。たとえば、出張に関する情報は「出張サイト」を作成する。ここから出張に関するニュースなどを配信する。おそらく総務が多くかかわるでしょうけれど、可能な限り業務内容によってサイトを分けてユーザーの動線も整理します。

サイトを分けると、情報発信する側がわからなくなるのでは? という心配する方もいますが、ご心配なく。ファイルサーバーの目的のフォルダーにファイルをしまうのと同じで、出張に関しては「出張」サイトにアクセスして、ニュースを書きます。福利厚生に関しては福利厚生サイトに行ってニュースを書きます。こうしてバラバラに発信されるニュースは検索機能の恩恵により、全社ポータルなどに集約表示できるようになっています。ナビゲーションはハブナビゲーションで共通化され、ユーザーが迷うことが圧倒的に少なくなります。

場所に縛られない情報公開ができるようになっているというのが、クラシックサイトを運営してきた方にとってはとても新しい発想だろうと思います。

SharePoint ホーム

ところで、ハブサイトは複数作成できるといいました。私が自分自身のノウハウ提供や研修で使用しているラーニングポータルのテナントには、イントラネットのデモ用ハブ、オフィスアイラーニングポータルハブ、演習用サイトのハブというように複数のハブを作っています。

こうした各ハブへのアクセスを一か所から行わせることはできるのか? この答えの一つが SharePoint ホームです。ホームとして指定できるサイトは任意のさいとですが、テナント内で1つだけという制限があります。ここを入り口に、複数のハブにアクセスできるようにリンクを持たせることができるようになります。

ラーニングポータルのテナントでは、会社のロゴにアクセスすると SharePoint ホームにアクセスできるように設定しています。このサイトに各ハブへのリンクを設定します。対象ユーザーの設定を使えば、各リンクを適切なユーザーに対して表示・非表示をコントロールできます。

ハブ構成の例

この SharePoint ホームを Microsoft Teams 内にも組み込んでいこう、というのがこれからの Teams との並行利用の方向性でもあります。業務は Teams を起点にするので、そこからいろんな情報にアクセスさせたい。全社的なアナウンスなどは SharePoint サイトで共有したい。ならば、Teams 内にアプリとして SharePoint ホームを追加しておこう。ここから、それぞれの情報サイト群にアクセスできるぞ、ということです。

関連ビデオ

モダンポータルに関して比較的手短に解説しているのが 2020年5月に実施した Microsoft 365 Virtual Marathon で行った下記のセッションです。以前もブログでご紹介しましたが、念のため再掲します。

すでにあるサブサイトはどうする?

すでに存在するサブサイトについては、既存のサイト構成は塩漬けにしてしまい、まったく新規に新しくポータルを作る方向で進めていくのがお勧めです。

そもそもポータルのリニューアルを掲げられれば、これを大義名分にしながら業務の見直しや断捨離を断行する絶好のチャンスとなります。併せて新しい仕組みを効率よく使ってもらうために、社内でのユーザーに対する勉強会の実施および教育する立場の人材を育成することも大切でしょう。新しい仕組みを取り入れていくことで業務効率が良くなれば、これはコストではなく人材育成への投資となるはずです。

最後に

効率が悪いと判断すれば古きを捨てて、新しきを取るというのが、業務効率化では必要です。SharePoint はモダンサイトを使い、ハブサイトの概念を生かした運用をぜひ考えてみてください。

古い仕組みに縛られていると、新しい取り組みや概念を導入する妨げになり、業務の効率化はずっと進まないままになるでしょう。世の中には「より業務効率を上げるにはどうしたらいいのか」を常に考えて新しいサービスや製品が登場しているわけです。つい考えることをやめ「使い慣れているから、それでいい」ではなく、「使い慣れているけど、現状に課題はないのか? 先々を考えて、このままでいいのか」という視点は常に持っておいて欲しいと願っています。

世の中は思っている以上にものすごいスビートで変わっています。いつの時代も変化にうまく対応していくことが求められています。