「 SharePoint のデザインは微妙!」という意見について

悲しいことに「 SharePoint はデザイン的に微妙。使いにくいから使ってもらえない。」って良く聞きますが、僕は必ずしもそうは思っていません。(もちろん、非の打ち所もないくらい素晴らしいとも思っていないし、不満も多々ありますが。)
少しトゲのある言い方ですが、良く学ばずにうまく構築できない・うまく利活用してもらえない人の責任転嫁だと思っています。

例えば、SharePoint の利用用途の大きな一つに「社内ポータルサイト」が挙げられると思います。 SharePoint を全社的に導入して社内ポータルサイトがない企業はなかなかないのではとも思っています。いわゆるイントラサイトという性質上、通常のWebサイトのように公開されておらず、多くの企業の担当者は「他社はどんな使い方をしているのだろうか…どんなトップページだろうか…」などモンモンとしているのではと思います。
SIerなどは業務の性質上、様々な企業の社内ポータルサイトを構築しているとは思いますが、 SharePoint 技術者がWebデザインにまで精通していない場合も少なくはなく、おのずと説得力のある提案ができずに、お客様の要件に従うだけの場合も少なくはなく、結果的に社内ポータルサイトという観点では SharePoint の成長は鈍化しているかもしれないです。
僕も長くユーザー企業側の人間だったのでモンモン組でしたが、過去に貴重な経験が数回あり、他社の社内ポータルサイトを拝見できる機会もありました。もちろん中には素晴らしいと思えるサイトもありましたが、多くは…悪口に捉えられるといけないのであまり語りませんが、…なサイトが多かったです。

通常のWebサイトとは目的が異なるのですが、やはり特に社内ポータルサイトであればIA・UXに(精通していなくとも)ある程度知識や意欲のあるメンバーが一人でも必要だと考えます。

一般的な人が「Webデザイン」って言うと勘違いしがちなのが、Webデザイナーのセンスに依存するものだと思うこと。たしかにデザインと聞けば100%アーティスティックなイメージがありますが、特に企業サイトなどでは、Webデザイナーのセンスというよりは、デザインの一つ一つは非常にロジカルなんですよね。つまり、どこにどのようなコンテンツを配置したり、余白だったり、配色なども、全てデザイン・レイアウトは論理的に説明できるというわけです。逆を言うと説明できないといけないと思っています。そういう意味でもIA・UXの観点は大事で、だいたいそこを担当する人が不在な事が多く、社内ポータルの構築メンバー視点だけで構築を開始し、言い方悪いですが構築メンバーの独りよがりなサイトになってしまいます。
しかし、あくまでも利用するのは利用者です。UXが大事というのはそういう事です。(構築メンバーの思いと利用者の感想は往々にして剥離しているケースが多いと経験則から感じます。

通常のWebサイトはターゲットが大げさに言えばネットができる世界中の人々なのに対し、社内ポータルのターゲットはいくら広くしても全従業員、とかなり絞れるのでむしろ考えやすいと思っています。つまり、しっかり考慮して構築すれば効果は高いのではと思っています。

IA・UXを本業にしている人を導入するとなると敷居が高いですが、勉強して少しでも知識をつけるだけでも違うと思いますし、そういうのが楽しいと思える人がメンバーにいるだけでも違うと思います。また、SIerに依頼する際にはそういう観点からもSIerを選定する事も大事であると思うし、SIerも SharePoint の技術者やプログラミングだけでなく、IA・UXに明るい人材をもっと増やすべきだと思っています。

これ昔から思っているのですが、 SharePoint に限らず様々な業務システムが存在しますが、UXを全く考慮されていない使い勝手の悪いシステムが多いように思います。もっともっとIA・UXを重視しお金をかけるべきかと思います。それが結果として良い製品となり、品質も高くなるのではと思います。

例えば勤怠管理システムのようにそれを導入すれば即利用できるものと違い、 SharePoint はそれ単体だけでは何もできなく、そこから「勤怠管理用に」構築を経て始めて利用が開始できる製品なので、その構築の仕方で使いやすさも左右されるのは当然で、構築が未成熟なのに SharePoint がダメだとレッテルを貼るのは、まだ早いのかなと思います。

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

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

■例えば

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

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

■トラブル事例

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

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

■問題は?

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

■どうしたら?

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

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

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

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

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

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

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

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

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

 

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

SharePoint :コミュニケーション サイト をとりあえず10分ほど触ってみて気になった点:レスポンシブデザインの挙動

コミュニケーション サイトがようやく利用できるようになったので早速サイトを作ってみました。ワクワク!

色々触っているうちに気になった点があります。レスポンシブ対応だったと思ってブラウザの幅をウネウネと変えてみたんだけど、一般的なレスポンシブのWebサイトとどうも挙動が違うんですね。コミュニケーション サイトは幅を変えてからワンテンポ遅れてレイアウトが変わるんです。

▼幅を縮めるとこのような状態に。一瞬「え?これがレスポンシブ対応??」と疑ってしまいました。

▼1秒ほど遅れてサイズに合ったレイアウトになります。そりゃそうだよね、安心した!

開発者ツールでウォッチしてみると少しわかりました。定点しか見ていないので全体は把握できていませんが、例えばdivにstyle=”height:300px”など、CSSがインラインで書かれているんだけど、サイズを変えて1秒ほどするとその300pxの数値が変わるんです。 Nintex Forms のパネルの表示・非表示の挙動に類似しています。

Heroと呼ばれる画像がタイル状になっているパーツに関しては、ブラウザが広いとタイルですが、狭いとカルーセルに変わります。その際に隠れるタイルがdisplay:noneで消えるのかと思ったら、どうやらゴソっとHTMLが変化しているようです。

つまり、ブラウザサイズを変更するとHTMLやらCSSやら諸々が再描画される感じでしょうか。ちょっと普通のレスポンシブ対応とは違った感じです。あまり気にしなくても良いとは思うけど、パフォーマンスに影響はないでしょうかね。 Nintex Forms に関してはあまり1ページに多数のコントロールを配置すると一気にページの読み込みが遅くなるので。また一般的なWebのレスポンシブ対応とは異なるので、ここにさらにカスタマイズを加えようとすると、一筋縄ではいかないのかもしれないですね。

とりあえず10分くらい触ってみた時に気が付いた事でした。

SharePoint 管理されたメタデータはExcelなどからクイック編集で一括コピペができない

リストにアイテムを大量に追加する際に、一つ一つ投稿していたら大変なので、クイック編集で一括コピペしたい場合があります。クイック編集で「管理されたメタデータ」列に追加する場合、すでに投稿済みの他のアイテムの値からコピペする事は可能ですが、Excelなどからコピペができません。これ、あとから出来ない事に気がついて焦るケースもあります。

【検証1:他の値をコピペはできる】

▼こんな感じで管理されたメタデータを作成します。

▼1件は普通に投稿し、クイック編集に。管理されたメタデータ列の値を選択しコピー。

▼新しいアイテムの行にペーストをすると、問題なくペーストできます。

▼クイック編集を完了しても問題なく投稿されています。

【検証2:Excelからコピペはできない】

▼同じリストに以下のExcelのデータをコピペします。

▼なんだかビックリマークのエラーが出ています。

▼ビックリマークをクリックするとエラー内容が。

▼もちろんこのままクイック編集を完了しようとしても保存できません。

【なぜ?】

管理されたメタデータの値と同じ文字列なのになぜExcelからコピペができないのか?作成した管理されたメタデータを見るとわかってきます。

カスケード分類できる事からもフラットではなく階層を持つ事ができ、それぞれの階層には同じ文字列は登録できませんが、別の階層には登録できます。例では「八百屋A店」の中に「キュウリ」を2個登録はできませんが、「八百屋A店」と「八百屋B店」の中に同じ「キュウリ」が存在していることがわかります。つまり、この列に「キュウリ」という文字列を単純に入力したところで、A店のキュウリなのか?B店のキュウリなのか?の判定ができませんよね。なので、登録したままの値では受け付けないんです。

では、どのような構造になっているのか?

▼通常の投稿でA店のキュウリとB店のキュウリを入力しましたが、見た目はわかりません。

▼クイック編集にして二つのキュウリの値をコピーしテキストエディタにペーストしてみます。

キュウリ|2c5d590a-ded0-4477-a93b-095c1c3f5843
キュウリ|ca8e4e7a-b256-4e7c-a302-8b0cffa830c4

このように「表示名|内部名」でペーストされました。(この|以下の文字列が「内部名」という表現で正しいかは不明です。)UI上では見えませんが、このように内部名と紐付いて一意の値になっています。このような仕組みになっているので、Excelからコピーしたデータでは、管理されたメタデータ列ではペーストする事ができません。

ちなみに、

▼「表示名|内部名」でExcelのデータを作成し、

▼クイック編集でコピペをするとペーストできます。

▼しっかり投稿されています。

とはいえ、管理されたメタデータの全ての値の「表示名|内部名」を調べる必要があるし、それを元にExcelデータを作成するのもダルい作業ですよね。

リストを作成する際にニーズとしてExcelでまとめたデータからクイック編集で大量にアイテムを作成する想定がある場合、気をつけなければいけませんね。

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

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

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

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

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

■選択肢

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

■参照

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

■管理されたメタデータ

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

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


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

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

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

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

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


以上です。

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

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

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

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

SharePoint あるある:必須列のあるライブラリはファイルのドラッグには向いていない?

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

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

■トラブル

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

■リスト作成時

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

■投稿者への教育

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

■サイト管理者の日常

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

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

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


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

SharePoint 列の設定の「固有の値を適用する」って何??

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

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

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

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

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

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

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

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

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

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

▼なんと!

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

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

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

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

■トラブル事例

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

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

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

実際に検証してみます。

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

▼実際に投稿します。

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

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

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

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

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

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

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

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

SharePoint 集計値列の式を利用してHTMLを生成する方法がブロックされるとか無慈悲!

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アプリケーション設定が含まれ、この設定により管理者側で特殊文字をエスケープするかどうかを設定できるとの事。小難しい事言ってるけど、つまり、オンプレは管理者の設定次第で免れるという事ですかね。

SharePoint あるある:リストの詳細設定の「アイテムごとの権限」の罠!

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

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

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

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

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

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

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

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

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

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

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

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

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

【2】投稿者の弊害

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

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

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