"Office 365 / SharePoint Online" にカテゴリー登録されている191 投稿

[SharePoint Online] ファイルやページを誰が見たのか確認しよう!

モダンサイトでは、ファイルやページごとに閲覧数が表示できるようになっています。確認するにはドキュメント ライブラリまたはサイトページ ライブラリ内の各ファイルのリンクをマウスホバーすることで表示されるホバーカードを見ます。具体的な手順は次のビデオを確認してください(音声はありません)。

解説

ここに表示されるのは既定では閲覧数のみです(もちろん、閲覧数だけではなく、いいねの数、コメントの数も確認できます)。

2020-01-29_22-11-44 Japanese

2020-01-29_20-59-02 English

 

しかし、ある設定を有効にすることで、誰がいつ閲覧したのかまで確認できるようになります。

2020-01-29_21-03-12 Japanese

2020-01-29_18-57-43English

 

設定手順 

こうした表示を有効にするにはSharePoint Online 管理者が組織全体に対する設定をまずは有効にしておく必要があります。具体的に説明しましょう。SharePoint Online 管理センターに下記のような設定があります(ポリシー>共有)。

2020-01-29_18-49-52 Japanese

English
 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)に表示されるようになるのです。

2020-01-29_21-00-51 Japanese

2020-01-29_21-01-50English

 

ちなみに、こうした機能があることがわかると、日本人は回覧板的に使えるのでは? ときっと思うと思います。「誰が見ていないか確認できるように一覧を出せ! 」といった話になりそうな予感がしていますが、標準機能として閲覧者のダウンロード機能は今のところありません。

※海外の方もこちらのブログを閲覧することがあるようなので、念のため英語と日本語の両方のスクリーンショットを掲載しています。


SharePoint でのファイル管理について考える

SharePoint サイト上でファイル共有を行っている組織は多いと思います。最近ではMicrosoft Teams の導入も盛んにおこなわれていますが、Teams 上でのファイル共有もSharePointが中心となっています。

ところで、ファイル共有といっても組織全体で見た場合は至極大雑把に言えば、次の2種類に分類できるでしょう。

  • 特定の一部のメンバーのみが頻繁に利用するファイル
  • 全従業員に広く共有すべきファイル

前者については Teams を利用することでメールやファイルサーバーでのやり取りに比べれば利便性が向上すると思われます。そうした意味で、こちらに関してはさほど課題意識は持たれないのではないでしょうか。

多くの方が、課題として捉えているのは圧倒的に後者でしょう。手順書、手続き、契約書のテンプレートなどなど。なんといってもファイルが見つけづらいというのが共通した課題です。

今回の話は特定の業務に特化した話ではなく、管理部門が抱えるファイル管理に焦点を当てています。SharePointを使ってファイル管理のポータルをいかに作っていくべきかという話です。

SharePoint でのファイル管理

SharePointはよくも悪くもファイルサーバーに似た使い方ができるため、フォルダー構造に依存したファイル共有を行うことが少なくありません。が、ファイルサーバーに依存した使い方というのは、次の特徴があります。

  • 分類方法がフォルダーのみ
  • バージョン管理機能がないため、ファイル名にメタデータを記載してバージョン代わりにする (作成日とか、いろいろ)
  • 一覧性に欠ける

フォルダーで仕分けるというのは、ファイルを仕舞う側からしてみれば、決まった場所に保存するルールを覚えればいい。そのため公開する立場からすれば比較的運用しやすいのですが、公開されたものを使う側はそうではありません。理路整然とファイルがフォルダーで整理されていはるが、フォルダーを開いてみないとわからないし、よく使うファイルが別の場所に格納されているということもあります。また、公開場所がよくわからず困り、直接担当者に聞くと「公開しているんだから、探してよ」と言わんばかりの対応になってしまうことも。逆に、担当者側も毎回同じような質問が来るので困るという話もあったり。さらには、公開しているのに、それを周知できていなくて、あまり使ってもらえない、など。

考えなくてはいけないのは、業務においては「思考をなるべく分断しないこと」を重視することです。何かやろうしているから情報を探すのに、必要な情報がすぐには見つからないというのは、やろうとしていた何かに関する思考を分断してしまいます。一方でいつも問い合わせを受ける側としては、他の業務を行っているさなかに、こうした問い合わせで考えが中断されるのも、やはり非効率です。一旦、考えを中断されると元にもどるまでに最大23分かかるとか(MyAnlayitcsに教わった内容の受け売りですが)。

そうした意味で、情報を見つけやすくするという仕組み作りは重要です。ファイルに様々な情報が書かれているのであれば、やはり見つけやすくする仕組み作りは重要だということになります。

SharePointはファイルを探しやすくする仕組みをいろいろと持っています。ファイルサーバーのイメージのみで利用すると、SharePoint の特色を生かし切りないことが少なくありません。たとえば、分類方法にはライブラリに列を追加することで、メタデータによる仕分けができますし、バージョン管理機能は標準でもっている。メタデータをうまく使えば一覧しやすくなります。

たとえば、下図のようにライブラリに列を追加し、色分けして整理している。さらにグループ化表示でフォルダーに似た表示も可能です(研修でのデモ用のもの)。

2020-01-18_0-14-17

検索機能を使えば検索によって格納場所がバラバラでも一覧できます。Microsoft Search を使えば、Teams, Yammer, SharePoint, OneDrive for Business から横断的なファイル検索もできますし、他にも Power Automate , Power Apps, Power BI などの Power Platform との連携などもできるのも魅力です。

SharePointでのファイル管理ポータル作成の話に戻りましょう。

SharePoint上でのファイル管理には2段階あると考えています。まずは、とにかくSharePointを使ってもらい情報を蓄積することが先決です。そのため、ファイルをどんどん格納してもらいながらカテゴリ分けするというのが第一段階です。ライブラリやフォルダーで仕分けたりしていけばいいでしょう。高度になるとメタデータも活用できれば、検索機能もいろいろと生かせるようになります。ただし、これで終わってしまうことが多い。第二段階目は業務プロセスでファイルを整理することです。

リンク集などを作ることにはもちろん意味がありますが、ユーザーからすれば一覧が見たいのではなく、なんらかの業務プロセスの中でファイルを参照する必要があることも少なくありません。業務ストーリーがあってファイルにたどり着けるようになるという、もう一歩先の仕組みが本来だと欲しいところ

これはファイルに限らずポータルサイトのリンク集にもありがちなことです。ファイルやシステム、ページなどのリンクがきれいにカテゴリ分けされているものの、それで終わってしまう。これではもったいないなぁと思うのです。カテゴリ分けしたら、次に可能な限り業務の流れに落とし込みたい。

私が思い描いているイメージを具体化したいと思い、デモシナリオをいろいろと考案中ですが、その一つが下記の昨年 Twitter にも投稿した Power Apps 連携のシナリオです(※お陰様で珍しく「いいね」を80件以上いただいているようです)。

このデモでお伝えしたいのは作り方以前に、この背景にあるコンセプトの方です。

通常であれば、住所変更届のファイルが届け出ファイル一覧にあり、そこから入手することになるでしょう。ですが、本来住所変更届が必要になるのはまず「きっかけ」があり、そこから「何をすべきか」という流れになるはずです。この例では「引っ越し」がきっかけであり、すべきことが「住所変更届の提出」となるようにしています。

2020-01-17_23-24-11

このシナリオでは「届け出」のフォーマットはあえて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 が絶対ダメというわけではもちろんなく、表、テーブルなどの生成にはもちろん利用しますが)。


Office 365 のエンドユーザー教育向けのサイト - Microsoft 365 learning pathways

今回「Office 365 Advent Calendar 2019」に参加しており、この記事は 12/23 付けです。

Microsoft 365 learning pathwaysとは?

Microsoft 365 learning pathways とは簡単に言うと組織内でのMicrosoft 365 の利活用を推進するための E-learning サイトソリューションです。

ちなみに、2019/5/21 までは Custom Learning for Office 365 という名前で提供されていました。現在はアップデートされ名前も変更されています。前から試そうとは思っていたのですが、なかなか時間が取れず試せずにいたので Advent Calendar に参加するというのを好機ととらえて試しに構築してみました。【宣伝】弊社の「オフィスアイ ラーニング ポータル」をご契約を頂くと、どなたでも実物を試せます。

さて、本題に戻りましょう。

このサイトは SharePoint Online 上に構築することになるのですが、SharePoint Online Provisioning Service というサイトのリモート展開機能を利用するため、組織内に出来合いの教育ポータルを素早く作成できます。出来上がるのは コミュニケーションサイトがベースとなったサイトです。ここに、教育用に用意された SharePoint Framework を使った Webパーツが複数利用できるようになっています。

次の図が出来上がったサイトです。

Learning pathways home

特徴は次の通りです。

  • 幅広いエンド ユーザー トレーニング コンテンツを提供
  • インストールが簡単
  • 常に最新のコンテンツを利用できる 
  • カスタマイズも容易にできる
  • 独自のトレーニングのプレイリストも作成できる

誰が提供しているのか?

オープンソースのプロジェクト(SharePoint PnP がベース)であり、GitHub を通じてサポートされます。そのため Microsoft のサポート契約でカバーされているわけではありません。それでも、自前でコンテンツを用意する時間と労力がない場合は、こうした仕組みを利用してみるのは大いにありだと思います。

どうやってセットアップするのか?

セットアップ自体は簡単で数クリックで出来上がります。ただし、前提条件があります。ということで、次の通りです。

  • learning pathways をセットアップする(プロビジョニングする) ユーザーはそのテナントのテナント管理者であること
  • テナントのアプリカタログが利用できるようになっていること
  • learning pathways をプロビジョンする人はテナントのアプリカタログのサイトコレクションの所有者であること

セットアップ手順

セットアップ手順は次の場所に公開されています。

Provision Microsoft 365 learning pathways

ですが、せっかく試したので手順を書いておきます。

最初に次の SharePoint provisioning service のURLにアクセスします。

SharePoint provisioning service

このサイトには色々なサイトのサンプルが用意されており、今回の learning pathways 以外にも社内ポータルのサンプルなどもあります。ただし、英語がベースになっていますし、日本人が求める社内ポータルのニュアンスとは文化の違いもあるのでそのまま使ってすぐにイメージできるものは少ないようにも思います。あくまで学習用途には向いていると思いますが。

 

さて、このページから下記のような順番で learning pathways のページにアクセスしましょう。

How to set up Microsoft 365 learning pathways -1

表示されるページにはサイトのイメージと、どんな機能が使われているかなどが書かれています。

How to set up Microsoft 365 learning pathways -2

大事なのはスクロールダウンしたところです。

How to set up Microsoft 365 learning pathways -3

資料へのリンク集やシステム要件が記載されています。システム要件を要約するとテナントのアプリカタログに公開されるのでテナントの管理者である必要があるということが書かれている他、サイトの既定の言語は English です。English とはいえ、出来上がったサイトはモダンサイトなので、既定で第二言語はすべて選択されている状態です。メニュー等は日本語で表示できます。が、当然コンテンツはすべて英語。必要があれば、ローカライズしなくてはいけません。

では一通りの手順をビデオでどうぞ(音声付き:風邪ひいていて声がかれ気味です。すみません)。

ビデオ内でも説明しましたが、サイトのプロビジョニングには10分ちょっとかかったように思います。準備ができると下記のようなメールが、セットアップ時に指定したメールアドレスに送信されてくるので気長に待ちましょう。

How to set up Microsoft 365 learning pathways -4

準備ができたらサイトにアクセスします。プロビジョニングしたユーザーがサイトの既定の所有者になっています。サイトはカスタマイズ可能であり、いくつかカスタマイズしたらユーザーに公開することになりますが、これは一般の SharePoint サイトと同様に単純にアクセス権限を付与するだけです。

実際にアクセスしてみたところは次の通り。メニューだけ日本語化してみました。各ページは基本的にエンドユーザー向けのガイダンスであるMicrosoft サポート情報サイトのページをポータル上に組み合わせています。ページのレイアウト変更やプレイリストのカスタマイズは可能です。

補足

現在 プロビジョニング サービスのサイトからセットアップできるのは v3.0.0 ですが、最新版は 3.0.2 です。アップデート方法は次のURLに掲載されています。アップデートしておきましょう。

https://github.com/pnp/custom-learning-office-365#updating-the-solution

課題

一通り試してみましたが、課題はやはり日本語化です。一部は日本語化できます。

2019-12-23_21-00-54

ですが仕込んであるリンクの一部は英語のサイト情報を持ってきます。一応、カスタム作成したコンテンツ パックというものを適用できるので、これでどのように対応できるかを確認したいところですが、今日はそこまでの時間が取れないのでここまで。今後、ローカライズをどうやるかはもう少し研究してみます。

参考資料

この記事は下記のビデオを参考にしています。詳細はビデオをどうぞ。


SharePoint リストの表示領域を拡大する

SharePoint リストの表示領域を拡大表示する機能が順次ロールアウト中です。

下図のようにリストの右隅にある矢印がそれです。ツールチップには「コンテンツを展開する」と書かれています。"展開する" という言葉はちょっとしっくりとこないので、この記事では「拡大表示」としています。ちなみに、画面はコミュニケーションサイトを利用しているためサイドリンクバーはもともとありません。

2019-12-03_0-01-43

クリックすると領域が拡大表示されます。

2019-12-03_0-02-22

非常に便利な機能ですが、クイック編集時にはこのメニューが表示されませんので注意しましょう。

2019-12-03_0-02-01

とはいえ、通常のビューで拡大表示したうえでクイック編集を行うことはできます。広い画面が欲しければ先に拡大表示してから操作するのがおすすめです。

 


Delve ブログが利用できなくなるかもしれない件について

Twitter 経由ではありますが、Delve ブログがリタイアするという情報を入手しました。具体的には下記の記事がソースです。

Delveブログって?

Delve ブログとは馴染みのない方もいるでしょう。Delve 内に個人ブログを作れる機能があり、そのブログ作成機能がなくなるという話。ご存知ない方のためにもう少し解説しておきましょう。次のスクリーンショットはDelve の[ホーム]にアクセスしているところですが、個人の自己紹介の下の部分に「ブログ」セクションがあるのが分かるでしょう。

Delve Blog

たとえば、ここで「新しい投稿」をクリックすれば、新規に記事をかけますし「すべての投稿」リンクをクリックすると過去に作成したブログ記事にアクセスできます。次のスクリーンショットは記事の例です。

2019-11-29_23-12-16

とはいえ、あくまでこの話の対象はブログであり、Delve 機能自体がなくなるという話題ではありません。

Microsoft 365 管理センターに通知が届いている?

さて話を戻しましょう。関連記事を読むと、いくつかの Microsoft の顧客に対して次のような内容のメッセージがMicrosoft 365 管理センターのメッセージセンターに届いているそうで主旨は以下の通り。

全ての顧客が対象となっている話であり、2019年12月18日から新たに Delve ブログは作成できなくなり、2020年4月17日には既存ブログは削除される

手持ちの複数の Office 365 テナントでも確認してみたのですが、そうしたメッセージは届いていません。これは本当に正しい情報なのか? 正しいとしたらメッセージが届いていない理由は?ということで正式なメッセージとして届いていない以上、フェイクニュースなどの線も疑ってみる必要があります。

問い合わせたところ。。。

ことの真相を探るべく、SRを作成してマイクロソフトに直接問い合わせしてみました。すると Delve ブログが削除されるという公式情報を社内では確認できなかったし、Microsoft 365管理センターにも確かにそうしたメッセージは届いていない、とのこと。

一応、公式にはこの情報は否定されたわけです。

Delve ブログは使うべきなのか?

ですが、こうした情報がなぜ出てきたのかという謎は残ります。リンク元を確認しても、そうフェイクニュースを作っているような方々でもないのです。ただ、思い当たる節もあり、改めて Delve ブログについて考えてみました。

そもそも Delve ブログは登場した当初は目新しく、弊社研修でもご紹介はしてみてはおりましたが、同じような機能は Sway や SharePoint ニュース記事でも提供されています(Sway のあと Delve ブログ、その後、ニュース機能の順に公開されたのですが)。むしろ、Delve ブログは投入当初から新機能などは全く追加されることなく数年が経過しています。こういった状況を考えると投資は凍結されているのだろうとみるのが、一般的な見方であり、別の新しい仕組みが出てくる可能性が高いものです。すると、Microsoft Docs に下記の記事が公開されているのを見つけました。

Creating a blog with communication sites and news posts

内容をかいつまむと、コミュニケーションサイトをブログ発信サイトとして見立てて、ニュース記事をブログ相当として利用するというものです。機能的には確かにこれで充足するでしょうし、ニュース記事として構成した方が SharePoint モバイル利用などを考えても将来的に社内の多くのユーザーが目にする機会は非常に多くなるため利点も大きい。

Delve ブログは今のところなくなるということはないようですが、個人的な見解としては、Delve ブログ自体機能もさほど充実しないままであるため、コミュケーションサイトでのブログ発信へと切り替えていく方が将来性があると考えています。