SharePoint Online のサイトページやニュースは更新履歴をビジュアル確認できるようになりました(この機能は現在ロールアウト中)。
操作などの詳しくは下記のビデオを参照してください(音声なし)。
ビデオを見るとわかりますが、どの部分をどのように変更したかがビジュアル的にもひと目で分かりやすくなっています(Wordの変更履歴に似ている)。
次に展開される予定の多言語対応の機能でもこの機能が応用されることになっています。一つ段階が進んだとみていいでしょう。現在開発中にの多言語対応の機能は昔はバリエーションと呼んでいた機能の後継にあたります。新しい多言語機能がどの程度使いやすくなったのか、ロールアウトされるのが待ち遠しいです。
SharePoint Online ではモダンサイトになっていれば、一般ユーザー(閲覧権限があれば)でもサイトの利用状況が閲覧できます。
改めて詳細を確認すると、見落としている点もいくつかあったので、備忘録を含めまとめておきました。
いくつかのファイル拡張子はレポートから除外されています(外部ユーザーとの共有レポートは除く)。具体的には以下の通りで、画像ファイルやスタイルシートが主です。
このサイトの利用状況が最新になったのは 2018年2月からとなっていて、比較的最近と言えば最近です。なおゲストユーザーおよび匿名ユーザーの閲覧や訪問数が含まれるようになったのは、2019年3月以降となっています。こちらは、まだ1年経っていませんね。
モダンサイトのニーズが高まっては来ているものの、モダンサイトにアクセスしたことがない方も少なくないと思います。まず画面上部ではユニーク閲覧者とサイトの訪問数を確認できます。それぞれ最近7日間、30日、90日の3つのトレンドが確認できるようになっています。
ユニーク閲覧者では何人がアクセスしているかを把握できます(一人で何回もアクセスするのは含まない)。一方のサイトの訪問数は単純に閲覧数です。同一のユーザーが複数回アクセスした場合にもカウントされます。
いずれも、ページ、ドキュメントおよびニュースの閲覧数です。リストアイテムは含みません。
1時間ごとのアクセストレンドを表示します。色が濃いほどアクセス頻度が高い時間帯であることが分かります。
英語では Popular Platform です。基本的にはデスクトップ、モバイルWeb, モバイルアプリ、タブレットの4種類のうちどれがよく利用されているかが分かります。いずれにも該当しない場合はその他というカテゴリも用意されています。
このレポートは "User Agent" ヘッダーをもとに生成されているとのことで、Microsoft のルールで4つに分類しているようです。ただし、「その他」と判定された場合は、具体的にどの User Agent ヘッダーだったのかといった情報は入手できないため、あくまでも全体的な傾向を把握する程度にとどめるのがよさそうです。
最近一週間のうち、他にもユニーク訪問者が多いコンテンツや参照回数の多いコンテンツがTop10で表示されます。
一番最下部には去年後半に追加された「外部ユーザーとの共有」があります。社外ユーザーに共有しているファイルがあれば、それを CSVへエクスポートしてみることも可能です。エスポートできるのは、こちらも直近の90日分までです。次のような属性が含まれます。
いずれにしても言えることは、リストはこうした利用状況分析には含まれないということ。ドキュメントライブラリまたはサイトページが対象です。
クラシックサイトで「お知らせ」リストを掲示板として利用してきたところは、利用状況の分析をする意味でも「ニュース」機能に置き換えていくことを考えてみましょう。
[参考]
View usage data for your SharePoint site
SharePoint Online ではルートサイト を任意のコミュニケーションサイトに入れ替えられるようになっています。
ルートサイトとは、たとえば、contoso.com というドメインの場合は、https://contoso.sharepoint.com がルートサイトです。このルートサイトは Office 365 テナント契約時に SharePoint Online 側に自動的に用意されるサイトであり、クラシックなチームサイトが作られます。ですが、モダンサイト化を行う際には本来はコミュニケーションサイトで作り直したい。こうしたニーズにこたえるため、ルートサイトのURLを別のサイトと入れ替えることができるようになっているのです。
入れ替えを行う場合の注意事項などは下記の記事を参照してください。
Modernize your root site - SharePoint Online
When SharePoint is set up for an organization, a root (or top-level) site is created. Before April 2019, the site was created as a classic team site. Now, a communication site is set up as the root site for new organizations.
さて、この入れかえ機能は最初に PowerShell コマンドが用意されました。Invoke-SPOSiteSwapというコマンドです。コマンドの詳細は下記に掲載されています。
とはいえ、PowerShellに慣れていないと少し不安があるもの(管理者は慣れるべきではありますが)。そこで、GUI ベースの設定も用意されています。具体的にはSharePoint Online 管理センター(新しい方)で操作します。2019年12月末時点では私の利用しているテナントにはこの機能はまだ Rollout されていませんでしたが、2020年2月2日現在、利用できるようになっていました。私が管理しているテナントは ターゲットリリースのテナントであるため、テナントによってはまだ利用できない可能性があります。
使い方ですが、「サイト」> 「アクティブなサイト」から置き換えたいルートサイトのサイトを選択し、コマンドメニューから[サイトの置き換え]をクリックします。
すると次のような画面が表示されます。入れ替えたいコミュニケーションサイトのURLを指定します。
さて、このとき気を付けるべきは元のサイトのURLがどのように置き換わるかです。スクリーンショットにあるように /sites/archive-日付 という形式のURLに変更されます。どうやら SharePoint Online 管理センターから操作する場合は変更後の URL を指定する手段が用意されておらず、既定値を受け入れるだけになているようです。ちなみに、PowerShellの場合は、任意のURLに変更できるため覚えやすいURLに設定できます。
操作方法の簡単さは SharePoint Online 管理センターが上回りますが、PowerShell をつかった方が柔軟性はあります。SharePoint Online の本格利用がこれからでルートサイトには殆どコンテンツがない場合は SharePoint Online 管理センター を使うほうがよいでしょう。ですが、既に利用しており、ユーザーが元のサイトのコンテンツにアクセスする必要性があるような場合は覚えやすいURLに越したことはありません。先々の運用をにらんで手段を選ぶようにしたいですね。
モダンサイトでは、ファイルやページごとに閲覧数が表示できるようになっています。確認するにはドキュメント ライブラリまたはサイトページ ライブラリ内の各ファイルのリンクをマウスホバーすることで表示されるホバーカードを見ます。具体的な手順は次のビデオを確認してください(音声はありません)。
ここに表示されるのは既定では閲覧数のみです(もちろん、閲覧数だけではなく、いいねの数、コメントの数も確認できます)。
Japanese
English
しかし、ある設定を有効にすることで、誰がいつ閲覧したのかまで確認できるようになります。
Japanese
English
こうした表示を有効にするにはSharePoint Online 管理者が組織全体に対する設定をまずは有効にしておく必要があります。具体的に説明しましょう。SharePoint Online 管理センターに下記のような設定があります(ポリシー>共有)。
Japanese
English
この中の「サイトの所有者が、SharePoint でファイルまたはページを表示したユーザーの名前を表示するかどうかを選択できます(Let site owners choose to display the names of people who viewed files or pages in SharePoint)」というチェックボックスがあり、これがオンになっている必要があります。もし、オフになっていると以下の手順を行っても閲覧者情報は表示されません。表示されるのは相変わらず閲覧数だけです。
この設定が有効になっていれば、各サイトの所有者(厳密には Full Control アクセス許可レベルを持つユーザー)は、「サイトの機能」の一つである
「SharePoint 閲覧者 (SharePoint Viewers)
サイトのメンバーにサイトのファイルまはたページを閲覧したユーザーの名前を表示します。(Display to site members the names of people who viewed files or pages on their site)」
をアクティブ化することで、上記のようにホバーカード(Hover Card)に表示されるようになるのです。
Japanese
English
ちなみに、こうした機能があることがわかると、日本人は回覧板的に使えるのでは? ときっと思うと思います。「誰が見ていないか確認できるように一覧を出せ! 」といった話になりそうな予感がしていますが、標準機能として閲覧者のダウンロード機能は今のところありません。
※海外の方もこちらのブログを閲覧することがあるようなので、念のため英語と日本語の両方のスクリーンショットを掲載しています。
SharePoint サイト上でファイル共有を行っている組織は多いと思います。最近ではMicrosoft Teams の導入も盛んにおこなわれていますが、Teams 上でのファイル共有もSharePointが中心となっています。
ところで、ファイル共有といっても組織全体で見た場合は至極大雑把に言えば、次の2種類に分類できるでしょう。
前者については Teams を利用することでメールやファイルサーバーでのやり取りに比べれば利便性が向上すると思われます。そうした意味で、こちらに関してはさほど課題意識は持たれないのではないでしょうか。
多くの方が、課題として捉えているのは圧倒的に後者でしょう。手順書、手続き、契約書のテンプレートなどなど。なんといってもファイルが見つけづらいというのが共通した課題です。
今回の話は特定の業務に特化した話ではなく、管理部門が抱えるファイル管理に焦点を当てています。SharePointを使ってファイル管理のポータルをいかに作っていくべきかという話です。
SharePointはよくも悪くもファイルサーバーに似た使い方ができるため、フォルダー構造に依存したファイル共有を行うことが少なくありません。が、ファイルサーバーに依存した使い方というのは、次の特徴があります。
フォルダーで仕分けるというのは、ファイルを仕舞う側からしてみれば、決まった場所に保存するルールを覚えればいい。そのため公開する立場からすれば比較的運用しやすいのですが、公開されたものを使う側はそうではありません。理路整然とファイルがフォルダーで整理されていはるが、フォルダーを開いてみないとわからないし、よく使うファイルが別の場所に格納されているということもあります。また、公開場所がよくわからず困り、直接担当者に聞くと「公開しているんだから、探してよ」と言わんばかりの対応になってしまうことも。逆に、担当者側も毎回同じような質問が来るので困るという話もあったり。さらには、公開しているのに、それを周知できていなくて、あまり使ってもらえない、など。
考えなくてはいけないのは、業務においては「思考をなるべく分断しないこと」を重視することです。何かやろうしているから情報を探すのに、必要な情報がすぐには見つからないというのは、やろうとしていた何かに関する思考を分断してしまいます。一方でいつも問い合わせを受ける側としては、他の業務を行っているさなかに、こうした問い合わせで考えが中断されるのも、やはり非効率です。一旦、考えを中断されると元にもどるまでに最大23分かかるとか(MyAnlayitcsに教わった内容の受け売りですが)。
そうした意味で、情報を見つけやすくするという仕組み作りは重要です。ファイルに様々な情報が書かれているのであれば、やはり見つけやすくする仕組み作りは重要だということになります。
SharePointはファイルを探しやすくする仕組みをいろいろと持っています。ファイルサーバーのイメージのみで利用すると、SharePoint の特色を生かし切りないことが少なくありません。たとえば、分類方法にはライブラリに列を追加することで、メタデータによる仕分けができますし、バージョン管理機能は標準でもっている。メタデータをうまく使えば一覧しやすくなります。
たとえば、下図のようにライブラリに列を追加し、色分けして整理している。さらにグループ化表示でフォルダーに似た表示も可能です(研修でのデモ用のもの)。
検索機能を使えば検索によって格納場所がバラバラでも一覧できます。Microsoft Search を使えば、Teams, Yammer, SharePoint, OneDrive for Business から横断的なファイル検索もできますし、他にも Power Automate , Power Apps, Power BI などの Power Platform との連携などもできるのも魅力です。
SharePointでのファイル管理ポータル作成の話に戻りましょう。
SharePoint上でのファイル管理には2段階あると考えています。まずは、とにかくSharePointを使ってもらい情報を蓄積することが先決です。そのため、ファイルをどんどん格納してもらいながらカテゴリ分けするというのが第一段階です。ライブラリやフォルダーで仕分けたりしていけばいいでしょう。高度になるとメタデータも活用できれば、検索機能もいろいろと生かせるようになります。ただし、これで終わってしまうことが多い。第二段階目は業務プロセスでファイルを整理することです。
リンク集などを作ることにはもちろん意味がありますが、ユーザーからすれば一覧が見たいのではなく、なんらかの業務プロセスの中でファイルを参照する必要があることも少なくありません。業務ストーリーがあってファイルにたどり着けるようになるという、もう一歩先の仕組みが本来だと欲しいところ。
これはファイルに限らずポータルサイトのリンク集にもありがちなことです。ファイルやシステム、ページなどのリンクがきれいにカテゴリ分けされているものの、それで終わってしまう。これではもったいないなぁと思うのです。カテゴリ分けしたら、次に可能な限り業務の流れに落とし込みたい。
私が思い描いているイメージを具体化したいと思い、デモシナリオをいろいろと考案中ですが、その一つが下記の昨年 Twitter にも投稿した Power Apps 連携のシナリオです(※お陰様で珍しく「いいね」を80件以上いただいているようです)。
明日の研修用のデモが完成✨#SharePoint + #PowerApps + #MicrosoftFlow + #Word
— Ai Hirano | Microsoft MVP Office Apps & Services (@ai_yamasaki) October 17, 2019
住所変更届を PowerApps で入力させて、Flow を使って Word ファイルの自動生成。日本では印刷文化がまだまだ根強いケースも多く。そのためのシナリオ例。 pic.twitter.com/l05SvoJRYw
このデモでお伝えしたいのは作り方以前に、この背景にあるコンセプトの方です。
通常であれば、住所変更届のファイルが届け出ファイル一覧にあり、そこから入手することになるでしょう。ですが、本来住所変更届が必要になるのはまず「きっかけ」があり、そこから「何をすべきか」という流れになるはずです。この例では「引っ越し」がきっかけであり、すべきことが「住所変更届の提出」となるようにしています。
このシナリオでは「届け出」のフォーマットはあえてWordにしました。日本では一般的に Excel ファイルで定型化していることが多いと思いますが、どこに何を書けばいいかを明確にするには専用の入力フォームにした方がよいでしょう。そこで Power Apps で入力フォームを作成しています。入力したデータの保管場所は SharePoint ドキュメントライブラリです。無論、SharePoint リストに蓄積するのでも構いません。ただ、多くの組織に対してヒアリングしてみると、承認には印刷物を使っている組織もだまだ多いようです。そうなのであれば、Office ファイルに格納してみようと考えたわけです。ビデオではわかりませんが、届け出の提出と同時に関係者にメールが自動送信されるよう Power Automate も組み入れています。といってもデモですから、あくまでもコンセプトが理解できればという程度までしか作りこんでいません。
先ほどのデモではファイルを保存するという流れでした。しかし、何でもかんでもファイルにして保管しているというのも時に課題になります。たとえば、ダウンロードはさせたくなく、閲覧だけにしたいというニーズがよくありますが、SharePoint のサイトページで作成しておけば、閲覧権限のみ与えることでダウンロードはそもそもできなくなります。「それ、本当にファイルでないといけないんでしたっけ? SharePoint のページでもよいのでは」という話です。
モダンサイトのSharePoint 上のページ(サイトページ) は、画像のドラッグアンドドロップなどもでき、ビデオも簡単に埋め込めます。モバイルなどを意識すると、レスポンシブなWebページの方が閲覧もしやすいはずです。もちろん、印刷を重視するのであればファイルになるとは思います。
こうしてみると、結局、ファイル管理は「業務の整理整頓」に他になりません。
なんらかの業務プロセスの中で生まれるファイル群ですから、業務プロセスを意識したファイル整理が必要ですし、どのファイルをどういったときに使うのかという意識をもったファイル整理ができれば、かなり情報は見つけやすくなるのではないでしょうか? また何でもかんでもファイルにするのではなく、時にはWebベージにしたり、Power Apps などのローコーディングツールで入力画面を作ったり、といった新しいアプローチも織り交ぜていくことも大切でしょう。また、Microsoft Teams のチームには任意のライブラリのURLをタブとして追加できます。複数チームで共有する情報であれば、チームのタブとしてSharePoint のドキュメントライブラリのリンクを追加することも、広い意味で業務プロセスにファイルの参照を組み込んでいくことになります(この場合、Teams も含めモダンサイト構造を生かしたサイト設計も重要です)。
ちなみに、こうした業務の流れがある程度整理してあれば、一部に関しては、将来的にチャットボットに次の手続きを促してもらうというような効率的な業務支援も行える可能性もでてきます。
業務シナリオを作って整理するというのは、それなりに時間のかかるものです。ですから、勿論、全てのファイルにシナリオを持たせるというのは、現実的ではないでしょう。ですが、少なくとも多くの従業員が必要とする情報に関しては、ファイルを整理したら、そもそもファイルであるべきかという議論もしつつ、必要があれば業務シナリオベースのページにおとしこむようにしたいところです。
Office 365 だけでも、いくつかのツールの組み合わせ方や使い方があるのですが、何をどう使えるのかナレッジがないという場合は、弊社などを含め、ノウハウを持っているコンサルティングができるところに相談してみるのも一つでしょう。ただし、その場合には対象となるファイル群とその課題を明確にしておかないと、漠然と数あるファイル整理について相談されても、アドバイスもやはり漠然としがちです。
ちなみに、SharePoint でファイル検索する場合、検索結果の上位に上がってくるファイルには、ファイルの種類ごとに優先度(重みづけ)が設定されており、Word, PowerPoint, PDF の方が、Excel よりは優先度が高くなっています。報告書でも、ちょっとした画像共有でもなんにでも Excel を使っているのは日本人くらいのものなようですし、こうした使い方は世界的に見ればマイノリティ的な側面があり、SharePoint の検索システムの仕組みから見て、何でもExcel ファイルで共有するのは効率が悪いといえ、SharePoint利用者にはお勧めしていません(Excel が絶対ダメというわけではもちろんなく、表、テーブルなどの生成にはもちろん利用しますが)。