SharePoint のカスタマイズについて思うこと。。。

SharePoint のカスタマイズについて、いつも思っていることがあるので、たまにはブログに書いておこうと思います。

私自身、SharePoint のカスタマイズを依頼された開発者の方などからの技術フォローを行ったりしていますが、「そんなカスタマイズ、ほんとうに必要かしら? 」と思うことが多いです。

まず、「使わせたくないから非表示にしたい」というケース。例えば次のようなことです。

  • SharePoint 2013 だと画面上部のスイートバー部分に表示される「ニュースフィード」「サイト」「OneDrive」へのリンクを非表示にしたい。
  • そもそもスイートバーを非表示にしたい
  • 使わないリボンメニューを非表示にしたい
  • [サイト コンテンツ]へのリンクを非表示にしたい
  • [サイト コンテンツ]へのリンクが非表示にできないので、リストやライブラリを非表示設定してしまいたい(閲覧権限は付与しておくけど) など

これらはSharePoint 上で行いたい業務を確実に妨げるから非表示にしたいというのではなく、「ユーザーに余計なことをさせたくない」「サポートを増やしたくない」「手順書を用意するのが大変」といった本質とは少し違った部分に理由があります。実は建設的な理由でないことが多いように思います。

基本的には私は「使わないのであれば、使わなければいいじゃない。間違ってクリックしても他に影響がなければ、問題ないし、そこは自己責任で」という考えています。ちなみに、[スイートバー] (SharePointサイトの上部の青い帯だったり黒い帯になっている部分)はカスタマイズはMicrosoftのドキュメント内でも非推奨です。[サイト コンテンツ]へのリンクが簡単に非表示になるような設定はありません(アクセス権限で「制限付き閲覧」にすれば非表示になりますが、リストやライブラリにアクセスできなくなります。あとはマスターページを修正して、、、とかですが、マスターページの修正を良しとしない組織もありますし)。

とはいえ、日本の文化ではユーザーが迷わないように手取り足取り丁寧にフォローするのが当たり前になっているので、どうしてもこうした依頼があると避けられないという方も多いのでそれは理解しています。しかし、開発者の方も「できるかどうか」の観点で請け負ってしまいがちで、その開発はコストをかけてまでやるべきことなのか、という原点にまずは立ち返ってほしいと感じています。ユーザーにとってもっと有益になる開発やカスタマイズの提案などに時間を割いてほしいなぁと。

SharePoint は「手になじむほど」カスタマイズするのはあまり適した使い方ではありません。ビジネスのスピードが非常に速い昨今、「手っ取り早くすぐに使えるものを使って情報共有を推進しよう」というのが基本スタンスであり、手になじむほどのカスタマイズするだけの、時間とコストをかけすぎることはあまり重要ではないのではないでしょうか? そう考えると、SharePoint は情報共有のためのパッケージ製品であり、すぐに使えるところに意味があります。もっとも、開発の拡張性はあるので、標準機能を踏まえたうえで、もっとビジネスニーズにあった使い方ができるようにコストをかけてカスタマイズや機能拡張していくのは意味のあることです。

しかし、本質的に達成したいことは「非表示」設定にしたい理由が別であることも多いのです。これを言っては「たられば」なのですが、サポート負荷が高まることを懸念して、こうしたカスタマイズに要求になることも多いことを考えると、そろそろユーザーのITリテラシーも組織として責任をもって向上させていく必要があるでしょう。また、IT部門やサポート部門も「ユーザーへのおもてなし」の負荷が増大していて疲弊しているように思え、もっとビジネス ユーザーが自立して利活用できるように促すべきではないかと考えています。うちもそうですが、専門で研修を行っているところもありますから、そういうところをうまく利用していただければ、ビジネス ユーザーの方のスキルアップは支援できます。

。。。と少し話がそれましたが、カスタマイズの要望の中には、本質的に達成すべき話とユーザーサポートの負荷のリスクヘッジ の話とが混ざり曖昧になってしまい、それによって開発期間が延びたりコストが上がったり、あまり意味のある開発と思えない要求に対応することで開発者が疲弊したりと、そういう現状もあることを知っていただければなと思います。

なんだか、読み返すと、だらだらですね。まぁ、たまにはこんな記事もということで。


SharePoint Designer 2013のダウンロードに関して

SharePoint Designer 2013 は後続バージョンがリリースされないことが決まっていますが、SharePoint 2016 でも引き続き利用できるようになったため延長サポート期間ものび、2026年まで利用できます。

ところで、このツールは無償提供されており、Microsoft のダウンロードセンターからダウンロードできますが、日本語版は公開日が 2012/10/30 となっています。韓国語版や中国語版も確認しましたが同様です。バージョンはいずれも 1.0。

2017-03-22_6-46-19

しかし、English 版は公開日が 2016/10/4 となっている!  何か違いがあるのかしら???

2017-03-22_6-47-14

 

 英語版と日本語版は同居できないため、手軽に違いを確認できないのが悩ましいところです。が、ダウンロードした実行ファイルの[デジタル署名]を確認すると英語版でもタイムスタンプは "2012年10月5日" となっており、中身は同じであるようです。

2017-03-22_9-25-03

ところでSharePoint Designer 2013 を入手してすぐに必要なのが SP1の適用です。原則、Windows Update で最新版には更新され、これが推奨されています。ダウンロードセンターからSP1を直接入手することもできます。

現在のバージョンを確認するには SharePoint Designer 2013 を起動したら、[ファイル]>[アカウント]の順にクリックし、[SharePoint Designer のバージョン情報]ボタンをクリックします。SP1 がインストールされていれば、15.0.4569.1506 以降になっているはずです(KB2817441)。

さて、英語版ですが別マシンを用意して試しにインストールしてみると既定ではバージョンが 15.0.4420.1017 となっており、SP1 は適用されていない状態となっています。結局日本語版と変わらずWindows Update によりアップデートして利用していく必要があるということですね。

2017-03-22_9-30-44 

 


SharePoint Designer 2013 内に表示されるSharePointのバージョン

SharePoint Designer 内に表示される SharePoint のバージョンはあまりあてになりません。

たとえば、SharePoint Online に接続している場合は SharePoint のバージョンは16.0.x.x. 台となるはずですが、手元の日本語版だと 15.0.0.4455 となっていたりします。

2017-03-22_6-49-18

16バージョン以降は認識していないようですね。

ちなみに、SharePoint Online で SharePoint のバージョンを確認したい場合は、次の URL を実行すればわかります。

・https://テナントのホスト名.sharepoint.com/_vti_pvt/service.cnf

 オンプレミスでも同じでサイトのURLの後に "/_vti_pvt/service.cnf " を付けてアクセスすれば表示されます。

バージョンに関しては本ブログの右側リンクに掲載している "お役立ち情報" からそれぞれの Build Number を確認してみてください。


"SharePoint ホーム" からサイトを作成するには

SharePoint Online で利用できる "SharePoint ホーム" には、アプリケーション起動メニューの[SharePoint]にアクセスします。

2017-03-04_10-33-31

このページはユーザーごとの情報が表示されるようになっており、次のような情報が得られます。

  • ユーザーがフォローしたサイト
  • 最近使用したサイト
  • お勧めのサイト

各サイトのアクティビティとして最近誰が何をしたかなども簡易に確認できます。

さて、ここに[サイトの作成]のリンクが表示されます。

2017-03-04_10-33-51

クリックすると次のような画面が表示されたりします。設定によっては一般ユーザーでも作成できます。

2017-03-04_10-34-16

[サイト作成]のリンクの表示有無やクリックしたときに挙動は、SharePoint Online 管理センターの[設定]ページで事前に設定しておく必要があります。

2017-03-06_12-56-17

ただし、ここで設定しても、いざユーザーが[サイト作成]をクリックしても "アクセス権がない" というエラーメッセージが出ることがあります。

2017-03-06_14-11-06

いろいろ確認したところ、ルートのサイトコレクションのトップレベルサイトへの閲覧権限を持っている必要があるようです。エラーになったのはいずれもルートサイトコレクションへの権限を持っていないユーザーでした。

ルートのサイトコレクションとはテナントのURL直下のSharePointサイトです。たとえば、Tenant1 というテナントだと

https://tenant1.shaepoint.com

をルートのサイトコレクションと呼びます。

https://tenant1.sharepoint.com/sites/team1 

https://tenant1.sharepoint.com/sites/team2

はルートではありません。

アクセス権を要求したときにはルートのサイトコレクションのトップレベルサイトへのアクセス権限が要求されるので、確認してみましょう。


SharePoint 2016 では検索の MaxDownloadSizeExcel の既定値が異なる

SharePoint 2013 / 2016 の検索コンポーネントではクロール時にダウンロードできる最大ファイルサイズが PowerShell から確認および設定できます。クローラ―は可能な限り最大値まで各ドキュメントをダウンロードしてきて、その後、コンテンツ処理コンポーネントに情報を渡してワードブレークなどの形態素解析を行い、インデックスを生成するわけです。

さて、SharePoint 2013 ではExcel 以外のドキュメントに対する最大ダウンロードサイズ : "MaxDownLoadSize" プロパティの既定値は 64MBであり、Excel の方の"MaxDownLoadSizeExcel" の値は 3MB となっています。PowerShell で確認してもそうなっています。

しかし、念のため SharePoint 2016 でも設定値を確認すると、"MaxDownLoadSize" プロパティの既定値は同じですが、Excel の方の"MaxDownLoadSizeExcel" の値が 4MB になっている! 

2017-03-05_8-19-56

TechNet の「Software boundaries and limits for SharePoint Server 2016」でも3MBが上限と書かれているのですけど、実際には違いますね。ドキュメントではなく実機の値が "正" でしょうね。