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

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

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

■アイテムごとの権限

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

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

■検索

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SharePoint アンケートの集計をする際の注意点

SharePoint のアンケートリストは気軽にアンケートをとれるので意外と利用されると思います。反面、運営方法次第だと色々トラブルの元にもなりかねません。当ブログでも過去にアンケートに関しては記事を書いてきました。

今回記事にするのは集計の際の注意点です。

実際に何度かあったトラブルなのですが、トラブル内容は、「集計したスプレッドシートが集計直後には表示されたが、今開いたらエラーで開けない。」というトラブルです。
実際にトラブルを再現してみます。

【トラブル再現】

▼こんなアンケートを作りました。(低レベルの質問で恐縮です)

▼4件の回答があります。

▼スプレッドシートにエクスポートします。

▼エクスポート直後にowssvr.iqyを開きます。(見慣れない拡張子ですよね)

▼しっかり4件集計されたデータが表示されました。

ここまでは問題ありません。ここから数日経過したあと、あらためて集計しようとしたところ…

▼同じowssvr.iqyを開くとエラーで開けませんでした。

こういう流れです。

【原因】

原因は「該当アンケートリストを削除」したことです。

通常、アンケートを運営していて、その性質上、長くデータは保管したくないので、集計が終わったらアンケートリスト自体を削除する事は普通のことかと思います。

では、なぜアンケートリストを削除した後にowssvr.iqyを開くとエラーになるのか?それはowssvr.iqyの中に回答データがないからです。つまりowssvr.iqyはアンケートリスト内のデータをその都度表示させているだけなんです。だからアンケートリストを削除すると、表示させるべきデータが削除されているのでエラーが出るわけです。試しにowssvr.iqyをテキストエディタで開いてみましょう。

▼回答データは一つもなく、接続する際の情報が記載されているだけです。

【対処法】

原因がわかれば対処法もわかります。

アンケートリストを削除する前に、owssvr.iqyを開いてxlsx形式などで別名保存すればOKです。もしくは回答データをコピーして、新規ファイルにペーストするなど。つまり、実データとして保存すればOKです。

【考察】

SharePoint に精通している方はこれらを把握しているかもしれないので、アンケートの作成から集計といった管理を SharePoint の運用・運営部門が一括して行っている場合は良いですが、SharePoint に精通していないユーザーに相応の権限を付与して作成から集計まで行ってもらっている運営をしている場合は、事前にマニュアルに記載しておくなどで教えておいたほうが良い内容かもしれません。トラブルが起きた際にアンケートリストがごみ箱に残っていれば良いですが、ごみ箱からも消えていたら、折角のアンケートがパァになりますからね。

Office 365 内の「アプリ」という言葉の定義がフワッとしている…

下記のQ1について自分が疑問に思ったところからスタートしました。Office 365 のそれぞれに関して、世間では「ソフト」「製品」「サービス」「アプリ」など、様々な言い方で呼んでいますね。

【Q1】これらを総称してなんと言いますか?

【A】「アプリ」です。(↓該当部分のソースです)

【Q2】SharePoint のこれらを総称して、なんと言いますか?

【A】「アプリ」です。(いろんなところにアプリと記載が。)

【Q3】SharePoint ストア のこれらを総称して、なんと言いますか?

【A】「アプリ」です。(お勧めのアプリと記載が)

【Q4】App Store のこれらを総称して、なんと言いますか?

【A】「アプリ」です。

Q4のApp Storeのアプリに関しては会社が違うので仕方ないにせよ、Q1~Q3に関しては若干ややこしいですね。

Q2とQ3は同じとも解釈できますが、Q3の SharePoint ストア にあるアプリは、Q2の意味のリストテンプレート的なアプリもあれば、サイトの機能みたいな商品などもあり、全体的にはQ2とは全く同義とは思えません。

さて、アプリという言葉がフワッとしたところがわかったところでどうにもならず、会話の中で利用したりマニュアルや資料内で記載する場合は、どのアプリを意味しているのかを明確にしていく必要がありますね。

Q2のSharePoint のリスト・ライブラリをアプリと呼ぶようになったのは SharePoint 2013 から急に出てきましたよね。これらを未だにアプリと呼ぶのは浸透していないような気がするので、これまで通り「リスト・ライブラリ」と言い換えた方が伝わりやすそうですね。

と、過去に「リスト・ライブラリ」の事を資料内で「アプリ」と記載したら、SharePoint ストア のアプリと勘違いして、「え?なんか買わなきゃいけないの?」と思われてしまうと指摘された事がありました。

IT部門がユーザーに説明する際にも、開発会社がお客様に説明する際にも、やはり言葉が正確に伝わる事は大事な事かと思います。

言葉って難しいですね。

IME 「ローマ字入力」がいきなり「かな入力」になった際の対処法

急に暗号文!?

たまにありますよね。普段ローマ字入力でタイピングをしているのに、いきなり かな入力 に変わっていて焦る現象。「あ」をタイピングしようとしてAキーを押したら「ち」って出てビックリするヤツ。

しかも元に戻す方法が結構わかりづらく、ググろうとして検索キーワードを入力しようとしたら かな入力 だった事を忘れていて、キーワードを入力するのに苦労したり、観念してスマートフォンでググったり。

で、結局IMEのツールバーを表示して「KANA」をクリックして元に戻す方法がわかり、何度かそれを繰り返すうちに、IMEのツールバーはタスクバーに表示させるようにしていました。

ただ、ノートPCなどデスクトップが狭い場合はIMEのツールバーは邪魔ですよね。で、探したところ「Alt」+「カタカナひらがな」がショートカットキーのようです。

もし、いきなり かな入力 になってしまった場合は、このショートカットキーで即戻ります。ただ、そこまで頻発する現象ではないので、次に起きた際、このショートカットキーを忘れて、またググってそうですが。

 

と、急に SharePoint に関係ないネタをぶっこんでみました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SharePoint 基本機能内で管理されたメタデータ以外で2階層のカスケード分類を実現させる方法

「カスケード分類」とは?

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

です。
選択肢の数が少なければ問題ないけど、例えば上述の説明だと全都道府県の市区町村だとかなりの数になるので、ユーザーに毎回そこから選択してもらうのは酷ですよね。そこでカスケード分類が必要になってきます。
これをSharePoint 内で実現させる方法として、SharePoint 2007 では、サードパーティー製品を利用したりカスタマイズが必要になります。SharePoint 2010 から登場した「管理されたメタデータ」を利用すると、カスケード分類ができるようになりましたが、まだ出始めた機能である事とクセがあったりしてなかなか利用されなかったりします。(今はどうなんだろう?)

そんな中、基本機能内の管理されたメタデータ以外でカスケード分類を実現させる方法を考えてみましたが、コンテンツタイプを利用すると2階層までなら実現できそうだなという感じです。以下、都道府県→市区町村ではなく、食べ物のジャンル→メニューを例にサンプルを作成してみます。

サンプルなので数は少ないのですが、ユーザーにメニューを選択させたい場合、メニューの数が100個もあったら選択が大変なのでジャンル分けしてカスケード分類を行います。

【1】サイト列で列を登録

サイト コンテンツ タイプを利用したいので、列もサイト列として登録します。「和食」「洋食」を選択肢列として登録します。

【2】サイト コンテンツ タイプを登録

「和食」「洋食」で親コンテンツ タイプはリスト コンテンツ タイプのアイテムで登録します。それぞれのコンテンツ タイプに【1】で登録したサイト列を追加します。「和食」コンテンツ タイプには「和食」列だけを追加、「洋食」コンテンツ タイプには「洋食」列だけを追加、です。

【3】リストを作成

【4】リストの設定

  • コンテンツ タイプの管理を許可するを「はい」にする。
  • 「既存のサイト コンテンツ タイプから追加」から【2】で登録した「和食」「洋食」サイト コンテンツ タイプを追加する。
  • 既存の「アイテム」コンテンツ タイプを削除する。

以上です。これによりコンテンツタイプでジャンルを選択し、該当ジャンルのメニューを選択する流れで、カスケード分類っぽい雰囲気になります。
では、作成したリストに投稿してみます。

▼「+新規」をクリックすると出現するメニュー内に追加したコンテンツタイプ「和食」「洋食」が表示されるので、どちらかを選択します。(モダンUIだと「リンク」というメニューもあり、これは消せなさそう。)

▼「和食」を選択すると和食列が表示されます。

▼「洋食」を選択すると洋食列が表示されます。

さて、これで完了かというとそういうわけにはいきません。登録時のカスケード分類っぽいものは出来ましたが、アイテムを登録した後のビューを見てみると微妙です。

当然ですが「和食」「洋食」と列が分かれます。「メニュー」として最終的にはマージした形で表示したいです。この場合は集計値列を利用します。

▼集計値で「メニュー」列を作成。数式は「 =洋食 & 和食 」でOKです。

▼「メニュー」列として和洋がマージされて表示されます。

まだまだ完了ではありません。次にビューにジャンルも表示させたいです。

▼ビューの設定で「コンテンツ タイプ」も表示させます。(この時点で「和食」「洋食」列は非表示にしてスッキリさせます)

だいぶスッキリしました。これでも良いのですが、列名が「コンテンツ タイプ」だと気持ち悪いのと、例えばジャンルでグループ化したくとも「コンテンツ タイプ」はグループ化できません。なので、もうひと工夫します。

▼集計値で「ジャンル」列を作成します。

数式は苦手ですが…この場合だと以下でうまく動きました。
=IF(NOT(和食=””),”和食”,IF(NOT(洋食=””),”洋食”,””))

▼列名も「ジャンル」でスッキリです。

▼「ジャンル」列でグループ化します。

▼グループ化したので列表示からは「ジャンル」列を外してスッキリ。

これでビューも完成です。
このようにコンテンツタイプを利用して2階層のカスケード分類っぽい事を実現でき、集計値列を利用して見た目もスッキリさせられます。全て基本機能です。サードパーティー製品や開発などで余計なお金はかかりません。

ただ…実は難点があります。
選択肢列って一度選択しちゃうと未選択状態にできないんですよね。今回のサンプルを例にすると、和食で寿司を選択して登録したけど、洋食のハンバーグに修正したい、といった更新時に厳しいんです。

▼寿司を選択したアイテムを編集画面にし、コンテンツタイプを洋食にすれば洋食メニューを選択できます。(コンテンツタイプを切り替える前)

▼コンテンツタイプを「洋食」に切り替え、オムライスを選択し、保存します。

▼更新したアイテム…メニューが「オムライス寿司」という奇怪な食べ物に…

寿司が選択されている状態でコンテンツタイプを変えても、和食列が洋食列に表示が入れ替わるだけで、その際に和食列の値がリセットされるわけじゃないんですよね。しかも、選択肢列は未選択状態に戻せないので、通常の編集画面ではコンテンツタイプを変える前に「寿司」を未選択にする事ができず、クイック編集じゃないと未選択状態にできません。

なので、更新の際に難ありです。
例えば更新はしない、更新する場合は削除して新規登録する、更新はクイック編集で行う、など、そういう運用でカバー系でもOKな場合は大丈夫ですね。
あと今回紹介はしませんが、SharePoint Designer などが利用できるのであれば、ワークフローと組み合わせれば解決できそうですね。

以上、イマイチよくわからない「コンテンツタイプ」とやらを利用すると、こんな事も基本機能でできてしまうんだぞ、というお話でした。

【 SharePoint Online 限定】 サイドリンクバーで「ごみ箱」や「最近使った項目」をCSSで非表示にする方法

※オンプレのSharePoint 2013 では通用しません。現在のSharePoint Online が対象です。ご利用環境に応じて参考にしてみてください。

SharePoint のサイドリンクバーで「消したい!」と良く言われるリンクが、「サイト コンテンツ」「ごみ箱」「最近使った項目」の3点セットかと思います。

■「サイト コンテンツ」を非表示にしたい背景

SharePoint 2007 の頃から「サイト コンテンツ」ページは閲覧・投稿者にあまり表示されたくないというニーズは良くありました。サイト管理者側からすると、例えば「サイトのリソース ファイル」や「スタイル ライブラリ」や配下のサブサイト一覧などは見られたくもないからです。SharePoint 2007 は、サイドリンクバーの最上部に「すべてのサイト コンテンツの表示」と2行に渡るリンクが存在し、削除できない仕様だったんですよね。なつかしい。

解決方法としては、CSSでこのリンクを非表示にしていました。固有のclassがあったので割と楽に非表示にできました。
SharePoint 2013 からは、標準機能で削除できるようになったのでカスタマイズは不要ですね。

■「ごみ箱」を非表示にしたい背景

SharePoint 2007 の頃からサイドリンクバーの最下部に「ごみ箱」へのリンクがありました。

たしかSharePoint 2013 からはサイドリンクバーから「ごみ箱」リンクが消えました。

が!どうやらSharePoint Online では今は復活してきているようです。×ボタンがないので削除できません。

さて、SharePoint 2007 の頃からこのごみ箱へのリンクを非表示にして欲しいというニーズが良くありました。というのもSharePoint にあまり詳しくないサイトのキーマンや管理者が、「他人が捨てたモノを見られたり復元されては困る。」と言うからです。大体それらの該当者は高いアクセス権限を付与されているケースが多いので気がつかないんですが、そもそもこのごみ箱リンクは投稿権限以上でないと表示されないし、ごみ箱の中身は通常自分が捨てたアイテムしか表示されないし、権限がなければもちろん復元する事もできないわけで、しっかり説明をすればニーズはなくなりました。

■「最近使った項目」を非表示にしたい背景


これはいつからでしたっけね?SharePoint 2010 からでしたかね。一定の条件でリスト・ライブラリを作成すると勝手に出てくるリンク。消す事もできるけど、リスト・ライブラリを作成する度に復活してしまうんですよね。なのでここを非表示にして欲しいというニーズもかなり多いです。


以上の背景やそれぞれの関係者のニーズを把握した上で、非表示(削除)したい場合、標準機能で削除できない、もしくは削除できるけど復活してしまうなどの場合は、何らかのカスタマイズをする事になると思います。
ググると色々なアプローチで非表示を試みている先人達がいました。特にナビゲーションの対象ユーザーを利用するのは基本機能のみだしアイデアだなと思いましたが、残念ながら発行機能が非アクティブのサイトでは実現できません。他にも今の僕には全く理解のできない難しい方法や、JavaScriptなどで実装している方々もいましたが、僕の場合はやはりCSSで検討してみました。

CSSでカスタマイズをするキモは、適用したい箇所に固有のidかclassが存在するかどうかなのですが、残念ながらサイドリンクバーの各リンクを構成する要素には固有のidやclassはないんです。
※現在のSharePoint Onlineにはliタグに固有そうなidがありますが、仕様が良く分からないのでないものとして、別のアプローチを試みます。

なので、苦肉の策として「:nth-child()疑似クラス」などchild系擬似クラスを利用して、リンクの上から何番目とか下から何番目を非表示にするなんて方法もありますが、これではリンクの場所を変えたりするとおかしくなっちゃいますよね。
僕が目をつけたのはリンクをリストにしているliタグではなく、その下のaタグです。ここを良く見るとtitle属性に必ずリンク名が入っているんです。

CSS3から追加された属性セレクタのうち、今回利用したのは「 E[foo=”bar”] 」です。これを適用させると、「 a[title=”ごみ箱”] 」なら、titleに「ごみ箱」と指定されているaタグに適用されます。「最近使った項目」はaタグではなくspanタグなのでちょっと変わります。
例えば、「ごみ箱」「サイト コンテンツ」「最近使った項目」全てを非表示にしたい場合は、

これで非表示になりました。

非表示にするだけなので、リンクの編集をすると透明のまま存在はするんですけどね。そこは仕方ないです。

で、「最近使った項目」に関してはこれでは不十分です。追加されたリスト・ライブラリのリンクはこれでは非表示にならないからです。(上のスクリーンショットでは「list005」「list004」です。)
調べると、「最近使った項目」は見出しで、その見出し配下に追加されたリスト・ライブラリがリンクになります。HTML的には「最近使った項目」のspanタグと並列でulタグがあり、その中にli > aでリンクが配置されます。

ここで更に利用したのはこれまたCSS3から追加された「間接セレクタ(E ~ F)」です。これは親要素が同じになる兄弟関係の弟に適用されるセレクタです。つまりこの条件に合致するわけです。
加えるとこんなソースになります。

title属性に「最近使った項目」が入っているspanタグの後にあるulタグに適用、という事になります。

SharePoint Online で色々イジった後にSharePoint 2013 のソースを確認したら、全く違っていたので結果的にOnline のみの対応となってしまいましたが、CSSでサイドリンクバーから特定のリンクを非表示にするというより、CSSのセレクタも色々増えてきて各種ブラウザも対応されてきたので、CSSによるカスタマイズの幅が広がってきているんだなぁというところを体感してもらえたら良いかなと思います。CSSであればググればたくさん情報がありますからね。意外と色々とできます。

 

 

 

SharePoint 運用・運営部門は自ら積極的に利用しなきゃダメ!

結構多いと思います。SharePoint に限らず全従業員が利用するような社内システムをリリースしたとして、提供元の運用・運営部門がぜんぜん使っていないなんて事。
一応、最初は部門チームサイトを作るんですよね。でも中身は利用されていなく、テストで作成したアプリやWebパーツの残骸があるだけで放置。お知らせリストに「○○部門のチームサイトをオープンしました!」なんて数年前のアイテムが未だ表示されていたり。更にサブサイトにメンバーのテストサイトなんかが作成されたまま放置されていたり。
これどうなんですかね?リリースして利用を促している部署がこの有様で、果たして利用を促された人々はどう思うでしょうか?

別の例に置き換えてみると…

  • 「これ美味しいから食べなよ!僕は食べないけどね。」なんて言われて怪しい。
  • セールスマンが「利用しなきゃ絶対に損ですよ」と推してきた商品について「アナタは利用していますか?」と逆に聞いたら利用していないと言われた。
  • 風邪をひいて病院に行ったらお医者さんが風邪をひいていて不安に思った。
  • ダイエットサプリを開発した博士がデブだった。
  • ハゲの特効薬を開発した博士がハゲだった。

なかなか信用できないし利用したいと思えないですよね。そういう事なんじゃないかと思うんです。実際に利用して活用してそこからメリットがある事を、自らを事例として積極的にアピールするくらいじゃなきゃ説得力が全くないんですよね。
これ、SharePoint を売っていたり、開発をしていたりする会社も同じですよね。自社で利活用していないとお客様への説得力がないですよね。実際に営業に行くとお客さんから「御社ではどのような活用をされていますか?御社の社内ポータルサイトを拝見させてください。」などの質問や要望はあると思います。上のセールスマンの例と同じです。自信を持って説明しなければ信用してもらえませんよね。

Office 365 は色々な製品が追加されたり大幅な機能追加されたりしていますが、例えば、Yammer とSkype とTeams の使い分けは?SharePoint のライブラリとOneDrive はどうなの?Planner って何? Power BI って何? Sway って何? PowerApps って何? Flow って何?…などなど、ユーザーやお客様から問い合わせがあった場合、答えられますか?(恥ずかしながら僕も自信を持って答えられないので、自戒の念を込めた記事でもあります…。)
で、そういう問い合わせやトラブルを恐れて、もしくは面倒で、折角価格は変わらずに利用できる製品やサービスを、設定で使えないように封じ込めてしまったり、「これはここだけの話しオススメしませんよ。」なんて適当な言い逃れをしてしまいがちですが、これにより様々な人々の様々な可能性を潰してしまいかねません。

使い倒してはじめて特徴やメリット・デメリットがわかるものなので、とにかくまずは使ってみる事が大事かと思います。

まぁ、そうは言ってもねぇ…ですよね。偉そうな事を言ったけど、僕も仕事は目の前の事が忙しいし、帰宅したら家族と過ごしたいし、趣味もたくさんあるので、結局よくわからないままな事が多いです。
このブログをやっていけるのも奇跡なのですが、今は過去に貯めた大量のテキストのストックからチマチマと軽く校閲しているので、ストックが尽きたら更新はどうなることやら。

ぐはっ…。

と、若干ネガティブな締めくくりでしたが、まぁ、がんばりすぎずにがんばっていきましょう!新しいオモチャを買い与えられた子供のように、新しい製品・サービスが出たらワクワクと楽しんで使えるようになれると最高ですね。

SharePoint ビューの「既定」スタイルをCSSで網掛けにする

前回の記事では、クラシック表示のビューのスタイルを「既定」以外にすると、ビューのフィルターで複数の値でフィルターをかける事ができないという事を書きました。

SharePoint ビューのスタイルを変更すると機能落ちする

ところで「既定」スタイルのビュー、つまりリストやライブラリを作成したデフォルトのビューでは、マウスホバー時にはその行の背景色が変わるので1行を読みやすいですが、マウスホバーをしないとテキストばかりになってしまい、読みにくいです。そういう意味もあって網掛けにしたい要望は少なくはありません。

それではビューの機能落ちなく網掛けにするには?CSSでカンタンに解決します。既定スタイルのビューでは、上から偶数行のtrに「.ms-alternating」というclassがあります。ビューで「ページの編集」をし、スクリプト エディター Webパーツなどに以下を記載すれば網掛けになります。(色は好きな色で。)

 

▼こうなります。

ただし、実はこれも一点デメリットが。
これはSharePoint 2010 からの問題なのですが、ビューを編集するとリボンタブが「参照」以外表示されなくなるんですよね。

▼本来なら「参照」の右に「アイテム」「リスト」タブが表示されるハズが。

ビュー内のアイテムなどをクリックするとすぐ復活するのでユーザーに周知されれば大きな問題ではないのですが、これは未だに直っていない問題です。

さて、このデメリットも回避しつつ網掛けにする方法もあるにはあります。
ビューに直接CSSを記述するのではなく、CSSファイルに記述し、代替CSSでそのCSSファイルを設定する方法です。これならビューを編集せずにCSSを適用させられるので、リボンタブが消えてしまう問題は解消されます。
ただし!そうです…これにも一点デメリットが。代替CSSで設定すると影響範囲はサイト全体です。つまり他のビューや他のリスト・ライブラリも網掛けになってしまいます。

代替CSSでも適用させたいリストを特定させる方法もなくはないのですが、色々面倒なのでないと言ったほうが良いかもしれないです。

結果として、標準機能とCSSカスタマイズではデメリットのない方法は見つからないのですが、網掛けをするのに標準機能の設定では1パターンしかなかったのが、CSSにより3パターンにまで増えました。それぞれのデメリットを考慮し、別にデメリットには感じないものがあったとしたら、そのパターンで実装すれば良いと思います。

  1. ビューの設定のスタイル「網掛け」を適用
    →デメリット:ビューのフィルター機能で複数の値でフィルターできない。
  2. ビューのページの編集でCSSを直接記述
    →デメリット:ビューのリボンタブが表示されない。(アイテムあたりをクリックすると表示される。)
  3. 代替CSSでCSSを記述したファイルを適用
    →デメリット:サイト全体で適用されてしまう。

以上です。複数の値でフィルターをかけられなくても良いのなら【1】で問題ないし、リボンタブをユーザーが利用しない、もしくは解決方法を周知させられるのなら【2】で問題ないし、サイト全体のビューが網掛けになってしまうのはむしろ大歓迎の場合は【3】で問題ないし、そもそも網掛けを諦めるというカードもありますよね。

要望が実現できないと業務に多大な影響があるかどうか?影響がないなら要望を諦める選択肢も十分あって良いと思います。

本当ならデメリットが一つもない方法を提示できればスッキリしたんですけどね。もちろんもっと他の方法でカスタマイズすれば良いのですが、CSS程度のライトカスタマイズにこだわりました。