Microsoft 365 ロードマップに上がっていた「スケジュールされた会議を作成する際に、会議の出席者として配布リストや Microsoft 365グループを指定できるようになる機能」のロールアウトが 2020年6月26日付で完了したようです。

Microsoft Teams のチームにはチャンネルごとに Wiki を追加して利用できるようになっています。5月のイベント時もそうでしたが、この Wiki の使いどころに悩んでいる方も少なくないようです。そんな質問をいくつかいただきました。

そこでこの記事では Wikiの使いどころや実体について少し掘り下げてみようと思います。

Wiki の使いどころを考察する

Wiki は「必ずこうして使いましょう」という決まりはありません。ただ、特徴を捉えることができれば、うまく活用できるだろうと思っています。

Teams 内では会話重要な要素の一つです。すなわちリアルタイムコミュニケーションが重視される "会話" では、最後に書かれたメッセージが優先的に表示されます。それは、新しいメッセージだったり、既存のメッセージへの返信だったり。会話だと、表示場所が頻繁に入れ替わるのです。これの利点としては最新の活動状況などが比較的に把握できるわけです。

ですが、最新のやり取りに左右されずに情報をまとめてどこかに固定しておいておきたいという場面も多い。

そんな時に利用できる仕組みの一つが Wiki です。

たとえば、前回ご紹介した Microsoft 365 Virtual Marathon でも Teams を使って関係者との連絡を行っていたのですが、イベントの概要や告知に使うハッシュタグ、イベントのコンセプトなど運営側に伝えたい情報は Wiki 上にまとめていました。これはうまい使い方の一つですね。場所が[Wiki]というタブに固定されているので、検索などしなくてもすぐに探せる。ちなみに類似した使い方として SharePoint ページを[タブ]として追加しておくというのもあります。SharePoint ページは情報をまとめるのは得意とするところで、手軽に見栄えよくページに情報をまとめられます。その点、Wikiは豊富な Webパーツが用意されているわけではないので比較すると表現力は限定的ですが、軽量化されていて手軽に書き込めるというのが何よりも魅力です。

余談ですが、SharePoint も Wiki の機能を持っていて研修や書籍でもたびたび「Wiki」の説明をしてきました。Teams の Wikiとは機能的には異なりますが、コンセプトは類似しています。肝心なのは、そもそも "Wiki" って何? という話です。この言葉の意味をご存知ない方も多いと思いますし、そんなところに注目していなかったという方もいらっしゃるでしょう。 Wikiシステムの代表でもある Wikipedia で調べてみるとわかりますが、言葉の由来はハワイ語で「速い」を意味する wikiwiki (ウィキウィキ) から来ており Webブラウザー上から素早く共同編集できるというのが特徴です。つまりは「専用ツールがなくても、手っ取り早く文書を書いておける」ところが魅力だと言えます。

• Wiki (英語)
• ウィキ(日本語)

それでもTeams が登場したばかりのころは、文字を箇条書きするくらいのもので、現在は当初と比べれば格段に表現力は上がっています。しかし、つまるところ、SharePointページの表現力を求めているわけではなく、手軽さ重視という点を考えると現状のシンプルな機能のままで温存されるのではないかとも思います。

とはいえ、Wiki にも難点もあります。次の点を考慮して運用する必要がありますね。

• 新規作成しても、更新しても目立たないので気づいてもらえない
• 書いた内容をチャットで引用するなどしない限り、Wiki単独では検索でヒットしない

Wiki の実体はどこに?

Wiki の実体はどこにあるのか? 気になる方もいらっしゃるでしょう。とはいえ、この辺は管理者の方が知っていればいいことだとは思うので、あくまでご参考まで。

少々、Deep Dive します。

実体は SharePoint で管理されています。あぁ、それなら知っているという方もいるかもしれませんが、それを Team Wiki Data 内のデータだと思っていませんか? 実態はリストであり、これは実は直接は使われていません。調べてみると、結構、奥が深いのです。

その裏付けとして、私の実験結果を共有しておきましょう。ちなみに、調査には SharePoint Designer 2013 をところどころで使っています。

まずは SharePoint サイト側にある Teams Wiki Data という名前のドキュメント ライブラリを確認しましょう。

この中には チーム内のチャネルごとにフォルダーが生成されます。とはいっても、チャネル上で Wikiが一度も使われたことがなければフォルダーは生成されません。またプライベート チャネルを作っている場合も対応するWikiフォルダーは作られません。

実験のために一般チャネルの Wiki に次のようなコンテンツを追加しました。

では、このチャンネルに対応する General フォルダーを開いてみましょう。次のように画像と mht ファイルが作成されています。

mht ファイルをダウンロードして中を開いてみます。すると次のようなHTMLが書かれていることが分かります。通常は、ここまでで Wiki の実体はこれだと思うはずです。

このファイルの中の html タグの属性である "data-list"を覚えておきましょう。19:1c4da～で始まっているIDが指定されています。

さて、このリストですが、SharePoint Designer 2013 からアクセスしてみます。実はこのIDを持つリストが内部的に作成されていることが分かります。このリストは既定ではサイトコンテンツページには表示されないように設定されているので、通常は気づきません。

ではこのリストのプロパティを変更して、サイトコンテンツ ページに表示できるように設定してみましょう。「ブラウザーに表示しない」チェックボックスをオフにして、保存します(余談ですが、このように隠しリストを表示できるように設定変更すると、検索結果にも Wki の内容が表示されるようになります。ただし、SharePoint 上からの検索時の話)。

では Webブラウザーに切り替えて、サイトコンテンツ ページをのぞいてみましょう。すると「19:1c4da～」で始まるリストが表示されるようになったことが分かります。

早速リスト内を確認してみましょう。Wiki, Page, Section の3つのアイテムが作成されています。ちなみに、ページを新規に追加すると Page と Section が追加されていくという挙動になっています。

試しに Page アイテムをクリックしてみると次のような内容が確認できます。Wiki のタイトル、作成者、タイムスタンプが書き込まれています。ちなみに、作成元は Skype Teams となっていますね。

今度は Section アイテムをクリックしてみましょう。本文が書かれています。

ではこの Section アイテムを編集してみましょう (といっても、あくまでも検証目的で自己責任で行っています。Microsoft の動作保証はされないと思いますので、決して運用環境で試してはいけませんし、おすすめもしません)。

wikiContent の本文を編集し、保存すると、すぐに Teams 内のチャネルに反映します。しかし、先ほど説明した mhtファイルはそのまま更新されることはありません。

もちろん、Teams 側から Wikiを編集するとmhtも更新されます。Wikiからページを削除すると、mht も削除されます。しかし、実は先ほどの隠しリスト内のアイテムは自動的に削除されることはないようです。過去の Wiki コンテンツが残っています。Teams 上から Wikiを編集するとリストが更新されると同時に mhtも更新されるが、削除はされない。フラグが立つだけ。そのフラグが、 wikiDeleted 列です。

つまり、過去のコンテンツはリストに残りますが、wikiDeleted 列が "はい" となるので Teams 内からは利用できないようになるということ。

では、この "wikiDeleted" を"いいえ" 変えたら、Wikiコンテンツは復活するのか? 実験です。これも自己責任でやっているので、皆さんは試さないでくださいね。

さて、以上確認してきたように、Web 版、デスクトップ版、モバイル版とすべてで検証してみましたが、mhtは実際には使われておらず、リストが利用されているようです。

結局 mht はWiki内のデータを手軽にダウンロードできるようにしているのかもしれまないというのが、勝手な推測です。

とまぁ、興味本位でいろいろと調べてみたことをついでに書いてみました。

何かの参考になれば幸いです(トラブルシューティングなどには役立つかも?)。

前回の投稿の補足としてフローボットを作成してみるときの注意点を共有しておきます。

• Microsoft Teams 内で Flow ボットを使って機密保持契約書を送付する

Flow ボットは手動で開始できるようになっていますが、Run flow コマンドで開始するには次のお約束があります。

• 既定の環境にフローを作る
• 入力がないフロー、またはスケジュールに基づいて実行されるフローであること

このあたりのことは Flow ボットに "Learn more" コマンドを送信すれば教えてくれます。

それでは! ということで早速上記のルールにのっとって作成するわけですが、手っ取り早いのはモバイルのFlow ボタンにある「手動でフローをトリガーする」トリガーを使ったフローです。

これを利用するのですが、Flow ボタンのトリガーを使って作成しても、List flows にフローが出てこないケースがあるのです。

順を追って説明します。

Flow のトリガーを追加し、コードのプレビューをしてみましょう。

これを見ると次のように入力が空なのが分かります。

このままフローを構築すればいいわけですが、途中のアクションでフローの作成者情報を取得しましょう。例えば次のようにトリガーしたユーザー名を変数に格納してみます。

この状態で再び「手動でフローをトリガーします」のコードビューを確認してみましょう。次のように変化しているはずです。

つまり、トリガーしたユーザーの情報を取得するために入力パラメータが生成されてしまっているのです。

このようになると Flow bot からは呼び出せなくなります。

検証していて、非常に嵌ったところです。

皆さんも試すときには、何もパラメータのないトリガーに気を付けてフローを構築してみるようにしてください!

Microsoft Teams には Flow アプリを追加できるようになっています(テナントによっては不可になっていることもあります)。

このアプリ内ではフローの作成や管理はもちろん、自分と対話できるフローボットが利用できます。このフローボット自体 Power Automate を使って作成できます。

利用イメージがしやすいように、これを使って SharePoint に格納されている機密保持契約書を手軽に先方に送付するというシナリオをご紹介しましょう。このフローではTeamsのコネクターを使っていますが、いずれも現時点ではプレビューであり、フロー構築時にはいくつかの課題もあります。

構築方法については今回は深入りしませんが、まずはどんなことができるのかを知ってもらえれば、何か業務改善のヒントになることもあるのではないかと思っています。

詳しくはビデオを使って説明していますのでご覧ください。

基本的な flow bot の作り方はまた別の記事で紹介します。

Microsoft Teams 内の各チームには[ファイル]タブが用意されています。このファイルタブの実体は SharePoint サイトです。

もっというと、チーム内の[ファイル]タブは SharePoint サイト上にある「ドキュメント」ライブラリ内のチャネルごとに生成されるフォルダーが紐づいています。しかし、Teams の[ファイル]タブは、SharePoint の標準的な機能の一部が実装されていません。もちろん、あくまで[ファイル]タブ経由で利用するとという限定的な話であり、[ファイル]タブのコマンドバーから "SharePoint で開く" をクリックすることで、Webブラウザーから直接 SharePoint のライブラリにアクセスすれば、標準機能がフルに利用できます。

※補足 : Teams がリリースされて間もないころはSharePoint が持つファイル管理機能のごく基本的な機能のみしか提供されていなかったのですが、数か月前からだいぶ SharePoint のオリジナルの持つ機能に近づいては来ています。

そのため、今回のブログのタイトルにあるような Power Automate を使った承認フローを実装するには、少し工夫が必要です。

Webブラウザーから直接SharePointサイトを利用するときには、格納しているファイルに対して承認フローを開始する方法としてはファイルのプロパティを確認し、例えば "下書き" から "公開" といった値に変更したときに承認フローを自動的に開始できるようにすることも少なくありません。しかし、[ファイル]タブでは現時点(2020/4/18)ではプロパティを編集できません。さらに、手動でワークフローを開始するにもフローを手動開始するコマンドメニューがありません。SharePoint 標準では本来はできることです。

そこで、[ファイル]タブを使ってフローを開始するのであれば、手動開始とプロパティの値をトリガーにすることはあきらめる必要があります。「ファイルを新規に作成したら」という自動的にフローが開始されるトリガーを使うのが妥当でしょう。

例えば、[ファイル] タブ内の特定のフォルダーにファイルを移動したらフローが開始されるというような実装を考えます。ただここで問題なのが、SharePoint コネクターのトリガーによってはサブフォルダーからはフローが開始されないものがあるということ。[ファイル]タブはサブフォルダーに紐づいているので、ここが重要なのです。

以上のことから、トリガーには次のいずれかを使うようにします。このトリガーはサブフォルダーでも動作します。

• ファイルが作成されたとき(プロパティのみ)
• ファイルが作成または変更されたとき(プロパティのみ)

自動開始を前提とするので、フローを起動したときに承認者を選択させることができないので、最初から承認者を固定で指定しておくか、上司の自動取得をするなど何かしら工夫をしておく必要があります。

ところで、トリガーを設定するときですが、SharePoint サイトとの関係が把握できていないとどのフォルダーをトリガ―指定すればよいのか迷うところです。チャネルとフォルダーの関係を図解しておくと次のようになります。トリガーを構成するときには、この図を念頭に置いたうえで、チーム名と同じ名前の SharePoint サイトのURLとフォルダーを指定するようにしましょう。

なお、チャネルを最初に作ったときに(もっと正確にいうと、チャネルを作成後に[ファイル]タブに初回アクセスしたときに生成) SharePoint側にフォルダーが作成されるのですが、フォルダー生成後はチャネル名を変更しても既存のフォルダ名は変更されません。そのため、現在 Teams 内のファイルタブには関連づいているフォルダー名が表示されるようになっているので、これを手掛かりにするとよいでしょう。

以上を踏まえ、最もシンプルな承認フローを構築すると次のようになります。ここでは細かい設定については触れませんが、詳細は例えば、既存の承認用のテンプレートを使いトリガー部分を差し替えるなどしてみてください。