SharePoint :今は新しい表示(モダンUI)ではページからサイトの設定へのリンクがない

クラシックUIの場合、

▼ページの歯車メニュー内に「サイトの設定」があります

▼モダンUIでは歯車メニュー内に「サイトの設定」がない!

以前はあったんですけどねぇ…

じゃ、どこから行けるの?と困っている方がいらしたらのために、記事を書きました。

■サイト 情報 経由で移動

▼歯車メニュー内にある「サイト 情報」をクリック

▼右からパネルが出てきます。

▼拡大してみるとこんな感じ。

非常に目立たないというかテキストリンクだとわかりづらいけど、この「すべてのサイト設定を表示」をクリックすると、サイトの設定に遷移します。

■サイト コンテンツ 経由で移動

▼同じく歯車メニュー内の「サイト コンテンツ」をクリック(サイドリンクバー内にもリンクあります)

▼赤矢印の部分に「サイト設定」のリンクがあります。

▼サイト コンテンツ ページにこのリンクがあるのは SharePoint 2013 からなので、クラシックUIにもリンクはあります。

古くは SharePoint 2007 は右上に「サイトの操作」メニューがあり、 SharePoint 2010 ではそのサイトの操作メニューが左上に移動し、 SharePoint 2013 では歯車アイコンとして右上に戻るという変遷はあったものの、いずれのバージョンでもその中に「サイトの設定」のリンクはあったので、モダンUIの場合いずれの方法も2クリックしなければいけないのは若干ダルいです。

モダンUIはリスト・ライブラリも設定画面に行かずに、ビュー内で列の管理やビューの管理ができるようになり、極力設定画面を経由させない事で簡単に管理ができるように!という想いがあるのかもしれないです。同じくサイトの設定画面もなるべく経由させないように考えており、その表れとしてサイトの設定画面やリスト・ライブラリの設定画面にモダンUIがないのかなと思いました。そう考えると今後更に設定画面を経由しないUIになっていくのかもしれないですね。あくまでも僕の浅い考えの予想ですが…。ただ、過渡期である今はうまくモダンUIとクラシックUIを使いこなさないとですね。

SharePoint :用語セットの並び順は変えられる!

用語セットの並び順は昇順です。

▼作成時は作成した順番に並びます。ここまででは追加した順番通りに表示されると思ってしまいます。

▼しかし一度設定ページを終了してもう一度設定を見ると昇順に並び変わっています。

▼この用語セットを使った管理されたメタデータ列はアイテム作成時も昇順に並び変わっています。

▼なので任意の順序に並べ替えたい場合は、以前は用語の頭に連番を振って対応したりしていました。

でも、実は目立たないところに並び順を変更できる設定があるんですよね。結構気がついていない方も少なくなかったので記事にしました。

▼用語セットを選択すると上に目立たないタブがあり「ユーザー設定の並べ替え」なんてタブが!

▼「ユーザー設定の並べ替え順序を使用する」にチェックをすると並べ替えができます。

▼このように順番が任意の順番になりました。

▼ちなみに、設定を変更した後に、用語を追加すると…(F、Dの順番で追加)

▼追加分に関してはまた昇順で追加されるので、毎回並べ替え順序を変更する必要があります。(F、Dの順で追加したのに順番はDが4、Fが5になっています。)

これを知っていると知らないとでは大違いですね。連番で管理するのは大変だし余計な文字が増えて邪魔ですからね。

SharePoint :ページの表示速度が遅い場合に簡単にできる一度疑ってみるとイイ事(透明人間が悪さをしている場合が!)

SharePoint に限らずページの表示速度が遅い事はユーザーの利活用促進を阻みます。オッサンになって更に記憶力が悪くなったので正確な情報ではありませんが、たしか通常のWebサイトではページの表示が2秒だか3秒以上かかると、ユーザーの離脱率がグンと上がるようです。なので、パフォーマンスについての対策は検討すべきかと思います。

パフォーマンスについては様々な原因があるのですが、ここではページを編集できる権限レベルでも調査できる、ページの表示速度が遅い原因を紹介します。

▼対象のページを表示します。(デモでは極端にWebパーツをゼロにしました)

▼編集モードにして、表示されているWebパーツの数を正確に数えます。(ゼロ個)

▼編集モードを終えて、URLの末尾に「?contents=1」を入力します。

▼このページが持っているWebパーツの一覧画面が表示されます。

ここで先ほど数えたWebパーツ数とここの一覧の数が一致しているかを確認してください。(表示上はゼロ個だったのに対し、こちらでは4個あります。)

以上です。

ここまでは過去に類似した記事を投稿済みです。

SharePoint :ページにWebパーツを追加すると1つしか表示していないのにWebパーツのタイトルに[1]が表示される

ただ、この時では気がついていなかったのですが、この一覧で「ページで開く」が「はい」になっているWebパーツは、実は表示上は消えているけど裏で生きている透明人間のような存在で、なんとソース上ではレンダリングされているんです。
この透明人間Webパーツが、表示速度が遅い原因である場合があるんです。

例えば…

▼このような「lib001」というライブラリがあるとします。事前に「search_test01」がある事を確認してください。

▼先ほどの見た目はWebパーツが1つもないページ

▼ただしこのように透明人間Webパーツが多々あり、この中に「lib001」ライブラリも含まれています。

さて、この状態で該当ページのソースから「search_test01」を検索します。

▼このようにソース上ではレンダリングされているんです。

この透明人間Webパーツが単体動作する軽量なWebパーツなら良いですが、数千アイテムあるアプリをフィルターかけていない状態でアプリパーツとして配置している場合、しかもそれが数個あった場合は、パフォーマンスに影響はあると考えます。

なので、上述の調査で数が一致しなかった場合は、透明人間Webパーツを削除してみましょう。

実際に、表示速度が遅い悩みのあるページで、上述の方法で調査した結果、透明人間Webパーツが大量にあり、一覧ページから完全抹殺したところ、劇的に表示速度が速くなった例もあります。

もちろんこれは原因のほんの1つなのですが、調べ方は簡単なので調査する価値はあるのかなと思います。

SharePoint: コンテンツ エディター Webパーツの「コンテンツへのリンク」の活用例

SharePoint 2007 から何かとお世話になることの多い「コンテンツ エディター」Webパーツ。ただし、僕個人的にはこのWebパーツを本来の使い方である「リッチテキストコンテンツ…」として利用した事はあまりありません。SharePoint 2010 からはWikiページになって、コンテンツ エディター Webパーツを使わなくても、コンテンツエリア内に直接リッチテキストを作成する事ができてしまいますからね。(コチラの方がコンテンツ エディター Webパーツよりも色々制約がありますが…)

コンテンツ エディター Webパーツの利用の大半は、そのページに適用したいCSSファイルやJSファイルのリンクを埋め込む事。これで結構重宝しました。SharePoint 2013 からはこの役割を「スクリプト エディター」Webパーツも行えるので、コンテンツ エディター Webパーツの利用頻度は減ってきたような気がします。

その他で僕がコンテンツ エディター Webパーツを利用してきた中で、本題の「コンテンツへのリンク」をよく使っていました。これはライブラリにアップロードしたテキストファイルのURLを指定すると、テキストファイル内のテキストが表示される機能です。

▼このようなテキストファイルを作成します。文字コードはUTF-8で保存しましょう。

▼アクセス権限だけ気にしてどこでも良いのでライブラリにアップロードします。URLを控えましょう。

▼表示させたいページにコンテンツ エディター Webパーツを配置し、「コンテンツへのリンク」にURLを指定。

▼コンテンツ エディター Webパーツには、テキストファイル内のテキストが表示されます。

【注意】
▼文字コードはUTF-8にしてください。文字化けします。

う~ん、テキストファイルなのでプレーンテキストを表示するだけでしょ?コンテンツ エディター Webパーツの中に直接リッチテキストコンテンツとして入力した方が装飾できるので、今のところ特に「コンテンツへのリンク」のメリットがない。

直接コンテンツ エディター Webパーツの中にリッチテキストコンテンツとしてテキストを入力するのと何が違うかというと、サイトコレクション内で使いまわせてコンテンツが一元管理できる点です。(サイト内ではなくサイトコレクション内です。ただ、別サイトコレクションは指定するとエラーになってしまいます…残念。)

つまり、複数ページに同じテキストを表示させ、更新などの管理を全ページで一括で行いたい場合、「コンテンツへのリンク」を使えば、指定したテキストファイル内のテキストを変更すれば、一括で全ページが更新されるというわけです。

若干メリットが出てきました。

で、テキストファイルなのでプレーンテキストだけしか対応しないと思うじゃないですか。でも実はこのテキストファイル内にHTMLを記述すれば、コンテンツ エディター Webパーツにはソースが表示させるのではなく、ちゃんとレンダリングされて表示されます。

▼さっきのテキストファイル内をこんな感じでHTMLを記述して更新します。

▼このようにソースが表示されずに、ちゃんとレンダリングされます。

夢が広がってきました。

過去にこれを使った例としては、トップリンクバーやサイドリンクバーは利用せずに、複数ページのコンテンツエリア内に独自のナビゲーションを配置させるのに利用しました。

▼軽くナビゲーションを作ったテキストファイルです。CSSも対応されます。

上で紹介した同じ方法でライブラリにアップロードし、表示させたいページにコンテンツ エディター Webパーツを追加し、「コンテンツへのリンク」にURLを設定します。

▼このようにテキストファイルに記述したナビゲーションが表示されました。

4ページ作成し、同じ位置に同じ設定をします。(1ページ作成し、 SharePoint Designer でコピーしても可ですね。)

▼このように4ページに全て同じナビゲーションが表示されます。

これで、この4ページはこのナビゲーションで自由に遷移する事が可能です。更に一括管理できるメリットを試してみます。この状態でテキストファイルを更新してみましょう。

▼テキストファイルを更新しました。

▼テキストファイルを上書きアップロードすれば、同時に全てのページで更新が適用されます。

今回はデモなので4ページのみですが、ページの量が増えるほど、一括管理できるメリットが活きるのかなと思います。

こういう機能があるんだという事を知っておくと、何かの時に役立つかもしれないですね。

SharePoint 「サイトコレクションの管理者」と「トップレベルサイトのフルコントロール権限」は全然違う

「サイトコレクションの管理者なのに、サイトの設定画面に表示されていないメニューがある!」

という問い合わせを過去に数回受けた事がありました。この場合、ほぼ100%このユーザーは「サイトコレクションの管理者」ではない事が原因です。

上長からの任命などで「このサイトコレクションの管理者になった」という役割名の意味の「サイトコレクションの管理者」と、SharePoint の設定上の「サイトコレクションの管理者」に追加されたユーザーでは大きく異なります。つまり、問い合わせしてきたユーザーの「サイトコレクションの管理者」とは、前者のただの役割名の意味だったという事です。

会社によって SharePoint の運営方針は異なりますが、中には「サイトコレクションの管理者」はIT部門以外のユーザーは追加しない方針もあるかと思います。この場合、いわゆるサイト管理者にはトップレベルサイトに対してフルコントロール権限を付与する形が多いかと思います。(もしくはオリジナルのアクセス許可レベル。)

トップレベルサイトに対してフルコントロール権限があれば、トップレベルサイトの様々な設定が可能で、更にサブサイトを作成する事も可能なので、サイトコレクション全体にフルコントロール権限が付与されたと思いますし、言葉通りとればそれは事実です。
そもそもアクセス権限(アクセス許可レベル)とは別に「サイトコレクションの管理者」という設定というか存在が SharePoint 上にあるという認識は、実際にサイトコレクションの管理者にならないとなかなか知る由もない事です。

▼このメニューは実際にサイトコレクションの管理者じゃないと表示されないので。

▼そしてサイトコレクションの管理者じゃないと表示されないサイトの設定のメニューはたくさんあります。

トップレベルサイトにフルコントロール権限が付与されているだけなのに、説明では「サイトコレクションにフルコントロール権限を付与しました」という若干曖昧な言い方をしてサイトコレクションを提供してしまうと、もらった方は最高権限をもらったと思ってしまい、その後ネットで検索した情報を元に設定しようと思ったらメニューがなかった…なんてストーリーがあり、冒頭の問い合わせにつながります。

わかりやすいかは置いといて(置いとくなって感じですが…)イメージ図を作ってみました。

▼サイトコレクションの管理者の設定範囲

  • サイトコレクション内の全ての設定が可能です。
  • サイトコレクションの管理者は、各サイトの権限設定に影響されません。

通常、ユーザーに何の権限を付与しないとURLからアクセスしてもエラーで閲覧すらできませんが、「サイトコレクションの管理者」に追加されたユーザーは、各サイトのアクセス権限を一切付与していなくても、全ての操作が行えます。

▼トップレベルサイトにフルコントロール権限を付与されたユーザーの設定範囲

画像右下の前提条件があった場合、

  • サイトコレクションの設定は一切できません。
  • トップレベルサイトの設定はできます。
  • サブサイトBの設定もできます。
  • 各サイトの権限設定に影響されるので、この例ではサブサイトAは設定どころか閲覧すらできない。

このように大きな違いがあります。

以上の事を考慮すると…
立場上の概念的な名称として、そのサイトコレクションを管理する人の事を「サイトコレクションの管理者」と呼ぶ事は非常に紛らわしく、例えば「サイトコレクションオーナー」とか設定上の名称と概念的な名称は差別化した方が、今後の様々な意思疎通を行う上で齟齬や認識違いが発生しないのかなと思います。

SharePoint では情報の一元管理を徹底しよう!

※長文の文章のみとなります…。

■例えば

「部門ポータルの掲示板(リスト)に掲載したアノ情報だけど、全従業員にも見てもらいたいから社内ポータルの掲示板にも掲載しておいて!」
上司からそう命じられて、部門ポータルのリストに投稿したアイテムと全く同じ情報を、コピペで社内ポータルのリストにも投稿しました。

よくある話だと思いますが、実際にトラブルにつながる可能性があります。

■トラブル事例

「掲示板に掲載されていた自社製品情報をお客様にお伝えしたところ、後日、それが古い情報で損害が出たとのクレームを受けた。」
信頼に関わるトラブルですね。調べてみると、部門ポータルと社内ポータルに両方に同一タイトルのアイテムが投稿され、その後情報が変更された際に、部門ポータルのアイテムは更新されていたが、社内ポータルは更新されていなかった。投稿者に話を聞くと、両方に掲載した事を失念しており、部門ポータルのみを更新したとの話。

十分ありえる話ですよね。

■問題は?

ここでの問題は社内ポータルの更新を失念した更新者…もありますが、投稿を多数行っている人にその問題を押し付けるのはかわいそうですね。運営面から考えると、同一情報を複数個所に掲載しているという点です。これはメンテナンスが大変だし、トラブル事例のようにヒューマンエラーの可能性が上がります。特に、投稿者が退職などすると余計ありえますね。

■どうしたら?

※以下は、あくまでも解決のための一例です。

ここでタイトルの通り、情報の一元管理が大事です。ただし、部門ポータルに掲示した情報を社内ポータルにも掲示するな!という事は言いません。

まず考えるべきはその情報をどこに保管するのが一番ふさわしいか?です。
今回はまず部門ポータルに掲載されたことからも、またその部門発信という事からも、またその部門がサイトを所有しているということからも、部門ポータル内に情報を掲載する事で良いと思います。

次に一元管理しつつ全従業員にも見てもらうには?
社内ポータルの掲示板を利用しても良いと思いますが、大事なのは掲載方法です。ここでコピペで同じ情報を掲載すると二重になってしまいます。ただ、Webの醍醐味は「リンク」なので有意義に使いましょう。つまり、社内ポータルに掲示する本文には詳細内容を記載せず、概要のみと部門ポータルに掲示したアイテムのURLのリンクを起きましょう。そうすれば、リンク先の部門ポータルの掲示したアイテムのみをメンテナンスすればOKなので、更新し忘れはなくなります。

■リンクを活用するデメリットは?

例で考えると、社内ポータルの掲示板のアイテムにアクセスしたユーザーには、更にワンクリックを強要してしまう事になります。Webサイトの場合、ユーザーアクションをいかに減らす事を考慮しますが、ただし SharePoint に関してはWebサイトの考えがそのまま当てはまるわけではありません。つまりユーザーにとって本当に重要な情報であれば、離脱せずにワンクリックするからです。クリックされないならそのユーザーにとってはその程度の情報なのです。そういう意味でも大きなデメリットとは思えません。

次に、情報源であるリンク先のアイテムを移動したり削除されたら?
たしかにリンク元からはデッドリンクになり情報にたどり着きません。ただ、しつこいようですが本当に必要な情報であれば、リンク元アイテムの投稿者に連絡するなりします。更新し忘れて誤情報を元にトラブルになるリスクを考えれば、デッドリンクになった方がまだリスクは低いと考えます。もちろん、ユーザーからデッドリンクになっている連絡が来たら、投稿者がリンク先を更新すれば良いだけですし。

■リンクを利用して情報を一元管理する副産物

ユーザー目線で考えてみましょう。社内ポータルの掲示板を従業員が読んだとして、その情報が自分にとって必要と判断すれば読むでしょう。そこにリンクがついていればリンク先に行きます。例えばそこで「こんな部門ポータルもあったんだ!」と気づく場合もあります。自分に関連する情報であれば他の情報も気になる可能性もあります。そうすると初めて訪れたその部門ポータルの別のコンテンツも見る可能性もあります。つまり、利用者が増える可能性があがるわけです。

 

情報の一元管理が適切にでき、本来保管すべき場所に情報が鮮度を保たれて保管され、更に自分のサイトのPRにもなれる。
このような運営方針を投稿者レベルまで落とし込んで啓蒙しクセをつけてもらう事により、より安全な運営ができるのではないでしょうか。投稿者が多ければ多いほど、徹底させるのはなかなか難しいですけどね。

SharePoint 選択肢を実現する列の3種類の比較まとめ

いわゆる選択肢を実現したい場合の列の種類は、「選択肢」の他にも「参照」「管理されたメタデータ」と、合計3種類があります。この3種類にはそれぞれ特徴があるのですが、リスト作成時の全体的なニーズに対し、選択肢を追加する際にどの列の種類を利用するのが適切なのか?というのは、それぞれの列の種類の特色を把握していないとなかなか判断できません。
例えば、選択肢列以外の種類ではビューのフィルター条件の一部が利用できなかったり、集計値列で利用できない、など以外と忘れっぽい制限事項などがあり、後々できなくて困る事もあるかと思います。他にも過去の記事にこんな例もあります。

SharePoint 「選択肢」列で陥りやすいトラブル

トラブルにならないように3種類をまとめてみたいと思います。

まずは3種類の特徴を大まかに。

■選択肢

  • 名前がモロそのままなこともあり一番利用される。
  • ビューのフィルター条件での制限がない。
  • 選択肢の値を変更しても、投稿済アイテムの値は連動して変更されない。
  • サイト列として登録をすれば使いまわしも可能。
  • ドロップダウン形式の表示以外にもラジオボタンなどもある。

■参照

  • 参照元となる別リストを作成する必要があり、値の変更も参照元リストで行う。
  • 参照元リストの列を複数参照させる事ができる。※1
  • 参照元リストがあるサイト内でしか参照できない。

■管理されたメタデータ

  • カスケード分類が可能。 ※4
  • 用語ストアで登録すれば広範囲で使いまわしができる。
  • クイック編集時に難あり。 ※2

では、それぞれの機能を○×で表にしてみました。


※1
参照元リストの別の列をビューに表示させられるのは SharePoint 2010 以降。

※2
クイック編集内で別アイテムの値をコピペする事は可能だが、テキストファイルやExcelファイルなどからコピペはできない。(これは後日、別記事で紹介できればと思います。)

※3
既定で1時間インターバルのタイマージョブで変更されるため、最大で変更に59分かかる。

※4
カスケード分類とは?
「入力フォームでよくある、都道府県で神奈川県を選択すると、市区町村の選択肢は神奈川県内の市しか表示されなくなるアレ。」みたいに例えないと、未だに一発で理解できる用語が出てこない機能。SharePoint 界では「カスケード分類」があえて言うならメジャーな用語なのかもしれないけど、その「カスケード分類」と口にしても、未だに追加で都道府県の例えを話さないと理解してもらえない。

※5
利用できる参照元リストはサイト内のリストのみ。


以上です。

例えば、リストのフルコントロール権限は付与しても、選択肢の値の変更を許したくない場合は、選択肢列以外の利用が好ましいですね。参照を利用すれば、参照元リストの権限を閲覧にすれば解決ですし、管理されたメタデータであれば、用語ストアに登録し、その用語セットの権限でコントロールすれば解決ですし。

例えば、カスケード分類が必須であれば、管理されたメタデータのみですね。

例えば、大量の投稿がある事が予測されていて、かつ値は途中で変更する事があり、投稿済アイテムの値も変更に連動させる必要がある場合は、選択肢列は避けないと危険ですよね。(上述で紹介した記事を参照)

あらかじめそれぞれの特徴を把握していれば判断に怖くはありませんが、結構忘れちゃいがちなのでこのように表にしておくと良いと思います。

SharePoint アンケートリストの詳細設定で注意すべきポイント

前回の記事を含め、数回にわたりアンケートリストについて取り上げてきました。

とはいえ、なんだかんだ言っても気軽にアンケートをとるには良いんですよね。今回はアンケートリストの詳細設定で、初期設定の状態で注意すべきポイントを挙げます。必ずしもトラブルになるわけではなく、一つ一つのアンケート内容次第かと思います。
サクっとアンケートの質問を作成していきなりアンケートをスタートさせずに、一度設定をしっかり確認すると良いと思います。

■アイテムごとの権限

  • 読み取りアクセス権:すべての回答
  • 作成/編集のアクセス権:ユーザー本人の回答

「作成/編集のアクセス権」に関しては、アンケートの回答を共同作業する想定はほぼないと思いますので、初期設定の状態で問題ないかと思います。ちなみにここを「なし」にすると作成すらできない、つまり回答ができなくなります。
「読み取りアクセス権」に関しては、初期設定が「すべての回答」となっているので、アンケート内容次第では変更した方がよさそうです。他人の回答を見なければいけない・見せたいアンケートってあまりないような気がするので、基本は「ユーザー本人が作成した回答」に変更し、ニーズ次第で「すべての回答」で良い気がします。

■検索

  • このアンケートのアイテムを検索結果に表示する:はい

普段サイトを利用していて検索をした際に、結果にアンケートの回答が表示されるのはどうなんでしょうね。回答者も検索結果に表示されるなんてあまり想定していないと思います。アンケートとはいえ、例えば製品の有益な技術情報を含むようなアンケートであれば、回答を検索対象にしても良いと思いますが。これも基本は「いいえ」に変更し、ニーズ次第で「はい」で良い気がします。

総合すると、読み取りアクセス権がすべての回答で、検索結果に表示される初期設定のままだと、そのアンケートリストに権限のあるユーザーは、検索結果に自分も含めて他人のアンケートの回答が表示されるわけで、ちょっと気をつけたい設定かと思います。

SharePoint アンケートリストのアクセス権限で注意すべきポイント

↑実際起きたらおそろしい…

SharePoint のアンケートリストは簡易的にアンケートを実施するには手頃なので、アプリの中では割と利用頻度の高い部類かと思います。ただし、色々注意すべきポイントがあるので過去に記事にしてきました。

今回も(仮想の)トラブル事例を元に注意すべきポイントを書いていきたいと思います。

アンケート用のサイトがあったとします。詳細には以下のような設定です。

  • 全就労者対象や、(職種別など)組織を跨った対象にアンケートを開催したい要望が多いので、全社ポータルの配下にアンケート用サブサイトを作成した。
    (もしくは別途サイトコレクションでも可。つまりアンケートに特化したサイトがあるという事。)
  • アンケートサイト自体の管理は運営部門がおこなっているが、アンケートの作成・集計などの代行は行わない。
  • アンケート開催要望があると、希望者が自由にアンケートリストを作成できるよう「デザイン」権限をサイトに対して付与し、「アンケート作成者」と呼ぶ。
  • アンケート作成者は、永続的にアンケートを開催できるように、一度付与したデザイン権限は基本的に削除しない。
  • アンケートサイト全体には、全就労者に投稿権限を付与し、アンケートに回答ができるようにしている。
  • アンケート作成者には、マニュアルを付与し、自由に利用してもらう。
  • アンケートリストの詳細設定で、読み取りアクセス権を「ユーザー本人が作成した回答」に変更する事を必須とする。
    (もしくはその設定を施したカスタムリストテンプレートからアンケートを作成させるようにする。)

このような方法で運営をスタートし、アンケートリストの細かい不満は聞くものの、結構重宝され、運営する事数年経過…。最近とあるウワサを耳にしました。

「アンケートサイトは、回答内容が見放題らしいぞ!」
「○○さんの趣味は意外にもクラッシックバレエらしいぞ!アンケートサイトの回答に書いてあった。」
などなど。

このようなウワサが耳に入ってきたので、運営部門は徹底的に調べたところ、以下の事が判明しました。

  • 回答者は自分の回答以外は閲覧できない。(想定内)
  • アンケート作成者は、自分の管理するアンケートについては、集計するために全回答を閲覧できる。(想定内)
  • アンケート作成者は、自分が管理するアンケートに関わらず、アンケートサイト内全てのアンケートについて、全回答を閲覧できる!(想定外)

こんな感じです。
つまり、ひとたびアンケート作成者になりサイトに対してデザイン権限を付与されれば、読み取りアクセス権を適切に設定したところで、全ての回答が閲覧できてしまうんです。また、恐ろしい事に、アンケートリストの設定では、デフォルトで回答が検索対象なので、検索から他人の回答にたどり着いてしまう場合もあります。

上述のウワサについては、回答内容が見放題なのはアンケート作成者だし、○○さんの趣味がクラッシックバレエなのを見てウワサを流したのもアンケート作成者の誰かという事です。

人としてのモラルの問題でもありますが、秘密は垣間見たくなるのもこれまた人なので、やはりシステム的に制御しないとダメそうですよね。

これ、実はリストの詳細設定のアイテムごとの権限のところに、注意事項として記載されているんですよね。非常に見落としがちですが。

こうやって穴が存在している事に気がつかずに何年も運営されているなんて事は、ありえ…なくはないですよね。特にサイト管理者は往々にして自身にフルコントロール権限が付与されている事からも、各権限の挙動を検証しないで実装しがちで、気がつかない場合が多いです。

さて、今回の場合は、どのような対策をすれば解決されるでしょうか。これまた解答ではなく、考察とさせていただきます。

チェックアウトの取り消し権限というのはつまり…アクセス許可レベルの中でも「リストの動作を無視」という項目に該当すると思います。「デザイン」アクセス許可レベルではここがチェックされていました。

この項目をチェックから外したらどうでしょうか?これがダメなんですよね。
このチェックを外してしまうと、アンケート作成者は自分の管理するアンケートすら全回答が閲覧できなくなるので、スプレッドシートに保存をしても権限不足で集計ができません。

▼チェックを外した状態で自分のアンケートリストを見ると、本当は回答があるのに表示されません。

▼この状態でスプレッドシートに保存をしても、集計はされません。

こうなるとアクセス権限をサイト単位ではなくアンケートリスト単位で設定するしかなさそうです。そうなると結局サイト管理者の手間が増えます。
なぜかというと、アンケートリスト単位でアクセス権限を設定する場合、その設定はアンケート作成者では行えず、サイト管理者が行うしかないからです。

そもそも機微な情報を取得する目的でアンケートを開催する際には、たとえ社内であっても気軽にやれるものではない意識付けにもなるのかなとは思います。ポジティブに考えれば。

ただ、中には機微な情報ではないフランクな目的のアンケートもあるので、それも同じセキュリティレベル(手間)で運営しなくても良いかもしれません。そういう意味では、セキュリティレベルで運営方法を分岐させる方法もアリかもしれません。つまり、機微情報を含まないアンケートは今まで通りアンケート作成者が自由に作成・集計できるものとし、機微情報を含むアンケートの場合は、サイト管理者が個別の権限設定を施したアンケートリストを提供する。これなら機微情報を含むアンケートのみサイト管理者の手間が増えるだけなので、まだマシなのかなと思います。機微情報の有無を判断するのが難しい時もあるし、面倒だから機微情報が含まれているのに含まれていない方で実施されてしまう可能性もありますが、こうなるとさすがにモラルの問題かと思います。

このようにあくまでも一例ですが、このようなトラブルにつながりかねないという事と、解決方法も一つではなく様々な角度から検討し、最適解を探し出す必要があります。

アンケートはアンケートサイトではなく、各部門サイトやチームサイトの管理人に任せている場合も、その中のアンケートリストは、属しているサイトでデザイン権限以上のユーザーであれば、やはり他人の回答を見る事が可能だし。

とはいえ、Office 365 も色々なアプリやサービスが増え、ユーザーにとって色々な選択肢が増えたはいいけど、中には管理者が管理しきれないところもあり、アクセス権限を厳密・厳格に行う事は難しく、やはり利用者のITリテラシーやモラルにかかってくるのかなぁ?なんてスッキリしない感じで今回も〆させていただきます。

SharePoint 社内ポータルサイトの運営部門は「権力に屈しない!」「例外を認めない!」

社内ポータルサイトトップページのレイアウトは大事

「例外を認めない!」マイクロソフト社のイベントに参加するとセキュリティに関してよく聞くセリフですが、僕も昔から社内ポータルサイト運営においてこれが大事だと思っていました。

今回の例は社内ポータルサイトのトップページについて。ココは社内向け情報発信の一等地です。一等地は当然人気物件です。と同時にココは基本的には全就労者に向けた情報を発信すべきで、特定部門の特定チームに向けての情報発信をすべき場所ではありません。そういうのは部門サイトやチームサイトでおこなうべきです。

▼社内ポータルサイトのトップページに良く表示されるコンテンツ

  • 全社向け通達・連絡の新着情報
  • 福利厚生の新着情報
  • 規程集・社内Webシステム・部門サイトなどへのリンク集
  • 全社スケジュール
  • 社長・役員ブログ

などなど。
中には完全にリンク集のみに徹しているような社内ポータルサイトトップページもありますが、基本的には発信したい情報を盛りだくさんに掲載している会社が多いと思います。その際にトップページのレイアウトが非常に重要になってきます。盛りだくさんの情報から更に優先順位を検討して配置を考慮します。視線移動の法則でよくある「Fの法則」「Zの法則」などありますが、他にも「ブラウザの見開き1ページ内にスクロールなく全ての情報が表示されるのが理想」だとか「スクロールを発生しない事にこだわってWebパーツ内でスクロールさせる方法もあるけど、それってユーザーにとって本当に便利?」とか。
レイアウトというよりデザインにかかってきますが、多くの情報を掲載したい気持ちはわかるが、可読性を損なわないフォントサイズや余白の調整、など、それぞれこだわってレイアウトを決めると思います。ここをしっかり検討せずにレイアウトをおろそかにしてしまうと、利活用低下や発信した情報が読まれないなどがありますので、IA・UXに精通したメンバーがいると良いと思います。
ただそれだけでは失敗するケースが多いです。

たった一回例外を認めただけで…

いくら検討に検討を重ね優れたレイアウトを固めても、例外を認めてしまい一つの例外で全てがダメになってしまうパターンもあります。その例外を認めてしまわざるをえない経緯は、運営部門が高い権力に屈してしまうという事が多いです。

例を挙げるなら、とある役員の一言で社内ポータルサイトトップページの最上部に特定部門に向けた情報発信スペースを大きく作れとの依頼が。抵抗はしたが運営部門の部門長でも逆らえず、結局スペースを作った。おかげで全社向け通達・連絡や福利厚生の新着情報がスクロールをしないと表示されなくなってしまい、各方面からクレームが殺到し、利用されなくなり、最終的にこれらの情報はメールで発信されるようになった。…なんて事が。
これ、一度でも例外を認めてしまうと、他部門からもお偉方を通して、ウチも!ウチも!となり、結局カオスで全就労者にとっては見るに値しない社内ポータルトップページになってしまいます。

じゃ、どうすれば良いか?
いくらその場で論理的に説明や議論をしたって権力には抗えない事が多いです。根本的に運営部門が「権力に屈しない」「例外を認めない」方針にすべきだと思います。いや、これ、言葉で言うのは簡単だけどかなり難しい事ですね。

過去にSharePoint ユーザー会に参加した際に、この議題で議論した際にも、なかなか白熱した覚えがあります。

  • IT部門が運営するのではなく運用に徹し、社内でも比較的発言権のある部門が運営をする。
  • 社長からお墨付きをもらい特別権限で運営をする。

など、権力に屈しない運営体制を整える事に注力すると、後々運営が楽になるかと思います。または、

  • 社内ポータルサイトトップページへ掲載する場合、1pxあたりでお金を取る。

なんてアイデアもありました。ただ、これでは売り上げをあげている部門なら何をしてもOKになってしまうので、結局全就労者が利用するスペースからは離れてしまいますね。

っていうか、部門で情報共有をしたいなら部門サイトで行えば良いハズです。だいたいこういう場合でも、実際に部門サイトはあるんですよね。それでも社内ポータルトップページは狙われるんです。
権力を使って、社内ポータルサイトのトップページに、限られた人向けの情報を掲載させるなら、同じ権力を使うにも、トップダウンで部門内メンバーに部門サイトをしっかりチェックするように指示してもらった方が良いと思うんです。

また、どうしても社内ポータルサイトに!という救済措置としては、発信したい情報は部門サイト内で掲載してもらう事には変わりないが、そこへのリンクをバナーなどで社内ポータルサイトのトップページに表示させる方法はアリかと思います。ただ、そのバナーエリアも数が増えると場所をとってしまうので、掲載を申請制にして掲載期間を設けたり、数の上限を決めてランダム表示にさせたり、場合によっては権限やステータスによって表示制御をする方法もアリかと思います。

結局は、そのサイトは誰に向けての情報を発信するサイトなのか?をハッキリさせ、それに基づいて例外なくレイアウトを設計し、例外なく運営していくべきかと思います。

通常のWebサイト制作の時もそうでしたが、制作を依頼してくるクライアント企業の目線で制作をしてしまいがちですが、そのWebサイトを利用するのは訪問してくるユーザーなんですよね。どちらの目線で制作をすべきかは言わずもがなです。
社内ポータルサイトや部門サイトやチームサイトも同じです。それぞれ役割があり目的があり訪問者もある程度予測できます。なら、その利用ユーザーの目線で情報設計をしていかなければいけません。通常のWebサイトの利用ユーザーは不特定多数が対象ですが、社内ポータルなどは利用ユーザーは特定多数なので、設計しやすいですね。

権力に屈しない・例外を作らない運営。
難しいけど目指したいですね。

まぁ、そもそも社内ポータルサイトが、もはや不要という見解もあります。たしかにOffice 365 の製品を使っているとそんな感じもありますが、まだまだそういう流れが主流になっていくには時間がかかるのではと思っています。