Art-Break .log : Taichi Nakamura

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

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

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

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

■選択肢

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

■参照

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

■管理されたメタデータ

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

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

---

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

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

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

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

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

---

以上です。

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

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

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

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

SharePoint は多機能なので使いこなせば便利ですが、その場合、IT部門やサイト管理者がSharePoint に詳しいだけではダメで、このブログ内では何度も書いていますが、利用者の中でも大半を占める投稿者・閲覧者に対しても、最低限の教育をしなければいけないと思っています。

その中で投稿者が機能を把握していないがために起きたトラブルを紹介します。実際に様々な場面で見かけていますが、投稿者が悪いわけではありません。

■トラブル

「ライブラリにファイルをアップロードしているが、本人以外は表示されない！」
という問い合わせがありました。実際確認したところ、知らずに1年以上合計数十ファイルをアップロードしたが共有できていない事が判明しました。

---

これは必須の設定をしている列のあるライブラリに起きやすいトラブルです。
実際に検証してみましょう。

▼ライブラリに「コメント」という列があり、必須に設定しています。

▼エクスプローラーからファイルを選択する方法の場合は

▼アップロードする前に必ずプロパティを埋めるよう促されるので問題ありません。※1

▼この場合はファイルはアップロードされ、投稿者以外にもファイルが表示されています。

▼ファイルをビューに直接ドラッグをした場合

▼必須列に入力を促す警告もなく、アップロードが完了いたしました。ただし、本人以外のユーザーがアクセスしても該当ファイルは表示されません。
※画像が小さくて申し訳ないですが、投稿者以外のビューには１つしか表示されていません。

▼このままアップロードし続けるも、結果的に本人以外には共有されていない状態です。

これは、必須列が未入力だとチェックインができない仕様で、チェックインされないと本人以外には表示されない事が原因です。

ビューに直接ファイルをドラッグするとアップロードさせる仕組みはたしか SharePoint 2013 から実装された機能かと思いますが、Windowsのエクスプローラーのように複数ファイルを1度にアップロードできたりして便利なので、この方法でアップロードするユーザーは多いと思います。

リストを作成したサイト管理者が、ファイルをアップロードしたら必ず入力して欲しい意図があり必須と設定した列があったが、直接ドラッグしてファイルをアップロードするとこのような挙動になることまでは把握せず、特に投稿者に意図を説明しませんでした。

チェックアウト状態であるとドキュメントのアイコンの右下に矢印の付くアイコンになりますが、SharePoint をよく知らないユーザーがこれだけでこのトラブルに気がつくとは思えません。

困った事に、チェックアウト状態はサイトコレクションの管理者であっても、本人でなければ表示されないので、この違和感を本人以外が気がつきにくいこともあります。
※たとえサイトコレクションの管理者であっても、アップロードした本人でない場合は、ビューの表示は右側です。

さて、どうしたらトラブルを避けられるか？

■リスト作成時

• 本当に必要でなければ必須列をつくらない。
• 必須列をつくった場合は、投稿者に周知させる。

■投稿者への教育

• このような事がある事を教える。
• チェックアウト状態のアイコンを教えて日ごろから注意してもらう。

■サイト管理者の日常

• 管理しているサイト内のライブラリを例えば以下の方法でたまに確認する。
• サイト コンテンツページの個数と実際のライブラリ内の個数が一致していない。
• ライブラリの設定で「チェックイン バージョンが存在しないファイルの管理」をチェック。

などなど、複合的にトラブルを避けられる方法がありますが、それぞれの環境に合わせて出来る範囲で回避策を実行すれば良いと思います。

しかし、日本企業にありがちですが、やはりIT部門やサイト管理者などが色々苦労して社員（投稿者・閲覧者）を楽にさせようとするのは、最終的には社員のIT（SharePoint）リテラシーの鈍化につながるので、個人的には好ましくないです。
IT部門やサイト管理者などが開発や管理などで対応する苦労の工数（費用）をかけるなら、その工数を社員の教育に使った方が、将来を考えるとよほど建設的な工数のかけ方かと思いますが、いかがでしょうか。

---

※1
この状態で「キャンセル」をクリックしたら、チェックインされない状態でアップロードされます。

いつの間に列の設定画面にこんな設定があったんだろう？とりあえず良く分からない設定はそっとしておいて、そのまま忘却していました。

で、おもむろに気になったのでググってみました。すると、とにかくアホでも理解できる説明が出てこないんです。「値に一意性を適用する…」一意性とか普段使わないし。とにかくよくわかりません。ただどうやら SharePoint 2010 からの機能らしい。よくわからないなら検証してみましょう。

▼カスタムリストのタイトル列の「固有の値を適用する：」を「はい」にしてみます。

▼なんかよくわからないけど「強制的」とか怖そうな文章のダイアログが表示されますが、
問答無用で「OK」をクリックしてみます。

▼とりあえず「テスト」というタイトルで投稿。問題なし。

▼もう一度投稿。今度も「テスト」というタイトルで投稿。しかし保存をクリックすると「この値は既にリストに存在しています。」というメッセージが表示され、投稿できませんでした。

なるほど。つまり、
「同じリストの同じ列に同じ値で投稿する事をできなくする」
という事ですね。
それを理解した上で「固有の値を適用する」という意味がなんとなくわかりました。

じゃ、疑問。
すでに同じ値で投稿済アイテムがある列に適用したらどうなるんだろう？

▼「タイトル」列に「テスト」で投稿したアイテムが2件あります。

▼タイトル列の「固有の値を適用する：」を「はい」にします。

▼なんと！

という事で、列に同じ値を使えなくさせたい場合は、「固有の値を適用する」を「はい」にすれば良いようです。

ちなみにサポートされていない列の種類もあるようです。

列の値における一意性の適用
https://msdn.microsoft.com/ja-jp/library/office/ee536168(v=office.14).aspx

■トラブル事例

以下、サイト管理者（Q）と SharePoint 運用部門（A)のやりとりです。

• Q「選択肢列の値を変更したのですが、投稿済アイテムの値が変更前のままなのですが？」
• A「はい、選択肢列の値を変更しても、投稿済アイテムの値が連動して変更されないのは仕様です。」
• Q「そんなの聞いてないよ！500件ほど対象アイテムがあるんだけど、どうするの？」
• A「はい、手作業で変更するしかありません。フィルターをかけてクイック編集すれば比較的楽に…」
• Q「いやいやいや、それだと更新日時や更新者の名前が変わっちゃうよね？」
• A「はい、そうです。」
• Q「それじゃ困るんだよね！なんとかならないの？？」
• A「そう言われましても…」

知っている人にとっては SharePoint あるあるなのかもしれませんが、選択肢列の値を変更しても、投稿済アイテムの値が連動して変更されません。つまり、選択肢列の設定の値はマスターデータではなく、選択して投稿した際に、その値がそのままアイテムのデータとしてスタンプされるわけです。

実際に検証してみます。

▼「選択肢」列に「AAAA」「BBBB」「CCCC」という値を設定しました。

▼実際に投稿します。

▼投稿後に「選択肢」列の「AAAA」を「ああああ」に変更します。

▼投稿済アイテムは「AAAA」のままです。

これを「クソ仕様」だと言う人もいたけど、選択した時の値を保持したいニーズもあるので、クソではないと思います。

▼想定される選択肢の仕様で後々トラブルになりやすい条件

• 投稿数は結構多い事が予想される。
• 更新日時や更新者の情報は大事である。
• 選択肢列の値を変更する事がある。

例えば、そのようなニーズがあるリストを作成する場合は、選択肢列を利用する前に投稿済アイテムの値については確認を取った方が良いですね。

では、値を変更した際に投稿済アイテムの値と連動させるような方法があるか？ありますよね。参照列を利用し、マスターデータを別リストで管理すれば可能ですね。また、管理されたメタデータでも要件は満たされると思います。ただし、参照列も管理されたメタデータもそれはそれで特色や仕様があるので、そちらにも注意して利用しないと、別のトラブルになりかねないです。
そういう意味でも、選択肢を実現させるには複数の列の種類がありますが、全ての特徴を表にしたりすると良いかもしれません。っていうか僕はそういう表を作っていました。忘れがちなので。

サイト管理者の SharePoint のスキルや経験次第なのですが、仕様を把握せずに作成して運営を開始すると、後々になってトラブルになる事もあります。
とはいえ、運用・運営部門でも SharePoint の細かな仕様はなかなか全ては把握できず、ましてやサイト管理者となれば仕方のない事かなと思うので、やはり経験を積んでトラブルなどはしっかり記録してナレッジとして蓄積させないとですね。

FacebookでHirofumi Otaさんの書き込みを見て知りました！

開発やカスタマイズNGの環境では、集計値列の式を利用してHTMLを生成する方法は小手先技だけど色々できる技だったのにぃ！なんだかこの利用方法での実行がブロックされたらしい！っていうかこれは正式な利用方法ではなかったんだ？

以前デモで作ったリストがあったので確認しました。
選択肢を選ぶとそれに応じたアイコンが表示される仕組みです。

マジかぁぁぁぁ…orz

たった数日前まではimg列にはキレイなアイコン画像が並んでいたのに、今確認したら見るも無残なソースの表示がぁぁぁ…。

これ裏技だったとは知らなかったけど、テクニックとしてはネット上に色々紹介されているので、利用されている会社も少なくはないハズ。結構困る人もいるのでは？？？

Handling HTML markup in SharePoint calculated fields
https://support.microsoft.com/en-us/help/4032106/handling-html-markup-in-sharepoint-calculated-fields

よく読むと、SharePoint Online は2017/9/10までは延長をリクエストできるそうですが、延命措置はそこまでで、9/10以降は完全にNGそうです。
オンプレミスの SharePoint 2013／2016 は、2017/6のPUで「CustomMarkupInCalculatedFieldDisabled」という新しいWebアプリケーション設定が含まれ、この設定により管理者側で特殊文字をエスケープするかどうかを設定できるとの事。小難しい事言ってるけど、つまり、オンプレは管理者の設定次第で免れるという事ですかね。

リストに対して閲覧権限を付与されたユーザーは、他人の投稿したアイテムを編集しようと思っても、ボタンがグレーアウトされてクリックできません。わかりやすいし罠の臭いも感じません。

次にリストに対して投稿権限はあるけど、リストの詳細設定の「アイテムごとの権限」の設定を変更した場合。ここにイジワルとも言うべき罠が潜んでいるんです。

初期設定では「読み取りアクセス権」「作成/編集のアクセス権」が共に「すべてのアイテム」になっています。

ここで問題なのは「作成/編集のアクセス権」を「ユーザー本人のアイテム」にした場合。

つまり自分以外のアイテムは編集できないという事です。
この設定がなぜ罠かというのは実際にやってみるとわかります。

▼この設定にして他人のアイテムをまずは開きます。ん？リボンの「アイテムの編集」ボタンはクリックできる？？　…とりあえずクリックします。

▼あれ？編集画面になった！編集できるんじゃん。編集しよう。

▼内容を編集して「保存」ボタンをクリックすると…このタイミングでNG！？

そうなんですよね。編集できそうに見せかけて最後の最後でやっぱできないんですよね。「編集できますよ！できますってば！ほら、やってみて！…うっそぴょ～ん！」というイジワルな声が聞こえそうな罠です。

このイジワル仕様による弊害は立場的には2点あります。

【1】リスト作成者の弊害

この仕様を知らないリスト作成者が、自分のアイテム以外を編集できない要件のあるリストを作成した際に、この設定を施します。その後、検証をしてみると編集ボタンはあるし編集画面に行けるから「あれ？うまく動作してない？」と勘違い。普通編集画面まで行けてしまった時点でうまく機能していないと思ってしまうから、そこから更に実際に「保存」までのアクションをテストせずに悩んだり調べたりしちゃいますよね。この仕様がわかった時に、無駄な時間をすごしてしまったと思っちゃいます。

実は実際に僕はこの罠に陥った一人です。ホント仕様を知った時に心の中で「orz」になりましたよ。

【2】投稿者の弊害

該当リストがそういう仕様だという事に気がつかずに、他人のアイテムを編集する機会があったとします。ボタンがグレーアウトしていたり事前にそういう仕様であると示唆するメッセージなどがないので、知らずにメッチャ気合い入れて編集し、保存ボタンをクリックしたら…。
俺の気合いを返せ！となります。

実は実際に経験談ですが、これで苦情を受けたこともあります。仕様なので仕方ないんですけど、苦情を入れたい気持ちもわかる。

アイテムごとの編集の設定を変更したら、リスト作成者はこの仕様を忘れずに。また、投稿者には何かしらの手段でしっかりアナウンスする必要がありそうです。

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

• SharePoint アンケートリストで匿名回答の設定がされていても回答者はわかってしまう
• SharePoint アンケートリストの回答者からのよくある問い合わせ「中断したアンケートの回答を再開できない！」
• SharePoint アンケートの集計をする際の注意点
• SharePoint アンケートリストのアクセス権限で注意すべきポイント

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

■アイテムごとの権限

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

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

■検索

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

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

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

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

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

• SharePoint アンケートリストで匿名回答の設定がされていても回答者はわかってしまう
• SharePoint アンケートリストの回答者からのよくある問い合わせ「中断したアンケートの回答を再開できない！」
• SharePoint アンケートの集計をする際の注意点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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