投稿者: TAICHI

【1】「選択肢」で複数選択が可能なチェックボックス型で列を作成します。

【2】適当にアイテムを作ります。

【3】この「カテゴリ」という選択肢列でビューでグループ化をさせたくても、選択できません。

つまり、チェックボックスの選択肢列はグループ化ができない仕様です。

じゃ、ひねくれてこんな検証を…

【4】作成した「カテゴリ」列を編集でラジオボタンに変更します。

【5】投稿済みアイテムはすでに値は落ちているので、ラジオボタンだけど「A;B」という現象が。

【6】この状態だとラジオボタンなのでビューのグループ化で「カテゴリ」列は選択可能になります。

【7】結果

このスクショだけを見ると、チェックボックスの選択肢列はグループ化ができているように見えます。しかし、実態はすでにラジオボタンに設定変更をしているので、今後追加されるアイテムは複数選択できません。

じゃ、

【8】この状態で再度チェックボックスにすると？

【9】なんか壊れた！！！

【10】この状態でビューのグループ化を見るとグループ化されていない事になっています。

つまり、結局のところ、チェックボックスの選択肢列はグループ化ができないという結果でした。

■内部名の文字数の上限

長い列名を作成した場合でも内部名の長さは一定の長さから変わらなかったので、ちょっと検証してみました。

「内部名テスト」という列名で列を作成すると、内部名は以下のとおり。
_x5185__x90e8__x540d__x30c6__x30

内部名の場合、「_x****_」が一塊なので、

内＝_x5185_
部＝_x90e8_
名＝_x540d_
テ＝_x30c6_
ス＝_x30
ト＝

スの途中で切れているのでやはり上限があるようです。数えたところ、内部名の文字数の上限は32文字でした。ところが、厳密には違うようです。

【検証】

「test（4文字）」×8個＝32文字で上限ちょうどの列を作成します。同じリストに「test」のかたまりを更にひとつずつ追加した列を作ってみます。内部名は32文字で切られるので、このままだと同じ内部名ができあがってしまうと思いますが、内部名はユニークなのでどのような挙動になるでしょうか。

以下、
「列名」
「内部名」

testtesttesttesttesttesttesttest
testtesttesttesttesttesttesttest

testtesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest0

testtesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest1

testtesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest2

testtesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest3

testtesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest4

testtesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest5

testtesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest6

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest7

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest8

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest9

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest10

面倒くさかったけど検証終わりました。内部名が同じになってしまうと、自動でオシリに0から数字が振られるようです。10個目はどうだろうと思ったらオシリが2桁に増えました。100個列を作るのは時間がもったいないのでやめますが、この法則だと100個目はオシリが3桁になるんでしょうかね。（列が100個とか運営上は非現実的ですが。）

まとめると、内部名は文字列としては32文字が上限。同じ内部名になると33文字目から0から連番が振られる。

ここまで調べて思ったこと。
この情報、そんなに必要じゃないので時間の無駄だったかも。

SharePointのアプリは大別するとリストとライブラリの2種類ですね。で、色々な種類のリストやライブラリがあるわけですが、リストに関しては、いわゆる通達や連絡など掲示板的な利用目的の場合、カスタムリストを使うべきか？お知らせリストを使うべきか？というところで迷う事があると思います。

僕の場合はずっとお知らせリストを使っていました。理由は受信メール機能です。

オンプレのSharePoint2007を長いこと使っていたのですが、オンプレのSharePointにはメールでアイテムを投稿できる受信メール機能があり、これはお知らせリストだけの機能でカスタムリストには加えることのできない機能でした。
この機能、メールでアイテムを投稿できると知ると結構使う人が多かったんです。例えばメーリングリストのtoの中に受信メール用アドレスを突っ込めば、メールのバックナンバーが自然に作れるような使い方とか。
後で使いたいと言われた時に即対応できるようにお知らせリストばかりを使っていて、カスタムリストはほとんど使っていませんでした。

つい最近まで知らなかったのが、この受信メール機能はオンプレだけの機能で、SharePoint Onlineでは使えないようですね。お知らせリストにこだわる理由がなくなりました。

逆にお知らせリストが微妙なのが「有効期限」列の存在があります。カスタムリストはデフォルトでタイトル列のみですが（「更新者」列などは除いて）、お知らせリストには「本文」列と「有効期限」列がリスト作成時にすでに存在します。「本文」は大抵利用する列なので問題ないとして、「有効期限」列ですよ。
この「有効期限」列は、非常に微妙なんですよね。普通に考えたらここに日付を入れたら、期限が切れたアイテムは削除されるのかな？と思うじゃないですか。でもいつまで経っても削除されないんですよね。この列はただの日付を入力する列なんですよ。特別なにかアクションがあるわけじゃないんです。どこかで聞いた話では、有効期限列は、この列を利用して、例えばビューのフィルターで非表示にするなどご自由にお使いください的な意味だとか。もちろん情報管理ポリシーで設定すれば期限切れで削除したりもできますが。

「有効期限」列の厄介なのはこの列を削除できない事。

列の編集に削除ボタンがないんですよ。有効期限列があればユーザーは有効期限があると思うし、ここに日付を追加してしまうので、この列が機能していないのに存在するのは良くないですよね。

対処法はあります。リストの詳細設定でコンテンツタイプの管理を許可して、お知らせコンテンツタイプの設定から有効期限列を「非表示」にすれば、削除はされないけど、削除されたようなものにはなります。

▼お知らせコンテンツタイプの設定から有効期限を非表示に

▼有効期限列は削除はされないけど非表示になります。投稿画面で非表示になっているということは、利用されないので削除みたいなものかと思います。

とはいえ、いちいちこんな設定をするのは面倒ですよね。

なので、オンプレで受信メール機能が利用できる環境なら、上述のメリット・デメリットを考慮して使い分ける必要がありますが、SharePoint Onlineであれば、個人的には何も考えずにカスタムリストから作る事になるかな。

■内部名について

列には列名と裏側に内部名が存在します。列名・内部名ともにアプリ内ではユニークです。基本機能のみで利用している場合は内部名を気にする必要はありません。
列名は作成後に変更する事ができますが、内部名は変更できません。裏を返せば、Webパーツの開発などで、特定の列を参照したい場合、列名だとリストに権限さえあれば列名を変更できてしまうので、その後Webパーツが正常に動作しなくなります。
内部名なら列の作成後は変更できないので、列名を変更してもWebパーツも修正する必要なく正常に動作します。メンテナンス性を考慮すれば内部名を使った方が良いですね。

■内部名の調べ方

列の内部名の調べ方は、列の編集ページのURLを見ればわかります。
例えば以下は「タイトル」列のURLのサンプルです。
http://****.sharepoint.com/****/_layouts/15/FldEdit.aspx?List=*****&Field=Title
このField=より後ろが内部名です。つまり「タイトル」列の内部名は「Title」です。

■列名を日本語にして列を作成すると…

例えば「商品」という列名で列を作成すると、内部名をURLから取ってくると、
_x5546__x54c1_
これが「商品」列の内部名です。なんか気持ち悪いですね。

これを回避する方法として、列の作成時に列名を英数半角で一旦作成後、列名を日本語に編集する手があります。

▼「product」という列名で列を作成すれば、内部名も同じく「product」です。

▼その後、列の編集で列名を「商品」に変更します。

▼列名は「商品」だけど、内部名は「product」のままです。

※ただし…英数半角と書きましたが、例外がチラホラあるようです。例えば、「1」という列名で作成すると内部名は「_x0031_」でした。列名の頭に半角でも数字を入れるとこうなるようです。また、「col1」という列名で作成すると内部名は「_x0063_ol1」になりました。これに関しては法則がよくわからないです。深入りしない事にします…。

SharePointで社内ポータルサイトや部門サイトやチームサイトを運営されているケースが多いと思いますが、SharePointのデザインは昔から評判良くないです。特にSharePoint2013では時代がフラットデザイン化されてきている流れからか、シンプルに拍車がかかってきました。
SharePointは知っての通り国産製品ではないので、文化の違いから日本ではシンプルデザインをなかなか受け入れられない傾向にあると思います。欧米ではシンプルなデザインが好まれる傾向にあるようなので。
そこでデザインカスタマイズを検討されるかと思いますが、十分に検討をしてください。

SharePointで「見栄え」という意味でのデザインに凝る必要が本当にあるのかどうか？

日常、従業員同士の情報共有に利用される場合がほとんどかと思います。不特定多数のお客様に製品などを買っていただきたくて公開しているようなインターネット上のサイトとは用途やゴールが違うんです。

見栄えを良くすれば社内ポータルなどの利活用が促進されると安易に考えている方が結構いますが、例としては悪い例ですが「美人も三日で飽きる」です。カスタマイズ後のアクセス数は増えると思います。ただ、それも数日です。

利用用途を考えるとデザインよりもコンテンツのクオリティの方を重視すべきです。見栄えをよくするくらいなら、社内ポータルトップページに社員食堂のメニューを貼り付けた方が、よっぽどアクセス数は伸びます。
チームサイトなどは、デザインなんかにお金をかけるなら、メンバーにトレーニングをして便利さをアピールした方がよっぽど利活用促進されます。

もちろん予算が潤沢である場合は別です。見栄えを良くして損はありません。ただ、こんなご時勢ですし、費用対効果やお金をかけるべきポイントを考えるなら、SharePointでデザインカスタマイズをする際に重視すべきところは、見栄えよりも、ユーザビリティやアクセシビリティという観点です。

例えば、ナビゲーション部分をよりクリックされやすく工夫をしたり、ただのテキストなのか？リンクテキストなのか？が視認できるように工夫したり。

もちろん、カスタマイズする事による中長期的な管理面での影響やコストも検討事項です。

ノーマルのSharePointのデザインの印象が悪くても、使っていればそのうち慣れてきて気にならなくなるもんだと思います。

SharePoint の運営は、

「シンプルイズベスト！」

これに尽きると思います。

費用対効果はもちろん、手を加えるほど複雑になり、管理が行き届かなくなり、セキュリティやバージョンアップなどのリスクも高まります。運営ガイドラインもなく各サイトコレクションの管理者に自由に運営を任せてしまうと、中には仕様書などを全く残さずにカスタマイズしまくり、挙句の果てにはその本人はすでに退社…なんて事も。ブラックボックス化されたSharePoint をおそるおそる運営していくようになり、案の定、バージョンアップ時にトラブル続出…というシナリオは容易の想像できるかと思います。

業務上どうしても実装しなければいけない要件以外は極力実装しない方向に持っていくのも一つのテクニックかと思います。カスタマイズのスキルがあるほど陥りやすいのが、実は基本機能を工夫すれば実装できるようなものまで、すぐカスタマイズしてしまったり。

カスタマイズも開発も極力せず、SharePoint の基本機能で構築し、基本機能も極力機能を絞り、アクセス権限もシンプルに。

特に情報共有がメイン用途であれば、極端な話、1サイトに1リスト・1ライブラリさえあれば、十分かなぁとも思っています。

中長期的な運営を考慮するのであれば、SharePoint はシンプルイズベストなんだと思います。