Japan SharePoint Group 勉強会 #25 で登壇しました!(SharePoint Frameworkについて)

2月11日(土)に東京で行われた「Japan SharePoint Group 勉強会」に登壇させていただきました。
http://jpsps.com/event/20170211/

今回は「SharePoint Frameworkを触ってみた」という題目で
SharePoint Onlineの新しい開発モデルである「SharePoint Framework」について発表させていただきました。

SharePoint Framework を触ってみた from Kosuke Kuromiya
正直いって、実際に触って動かしてみるまでは
従来のJavaScript (JSOM) での開発と似たような感じかと思っていたのですが
全く違っていて、焦りました (汗)。
開発ツールについても、オープンソースでよく使われてる(?)ものが採用されているようですが
私はほとんど初見で、これも戸惑いました。
私と似たような、.Net Framewok & Visual Studio での開発になれた人間にとっては
スキルや作法的に新たに学ぶ必要がありそうです。

とはいえ、この開発モデルが必要になるSharePointの「新しいUI (Modern UI) 」の導入状況を考えると
(会場でも「従来のSharePointに戻す」をクリックしてる派が多かった気が…(苦笑) )
今すぐに実際の開発現場で採用されることはまだ先のことになるんじゃないか、というのが個人的な予想です。

ただ、逆にいつまでも様子見していると
いつのまにかスキル習得の時間を取れないような事態になってしまいそうな気もするので
少しずつキャッチアップしていきたいと思います。

SharePoint Online の「新しいUI」を従来のUIに戻す方法いろいろ

この投稿は Office 365 Advent Calendar 2016 に参加しています。

なんと、前回の投稿が昨年のOffice 365 Advent Calendar参加の投稿だったので、
正真正銘の一年ぶりの投稿になります (滝汗)

で、その間にSharePoint Online 色んなアップデートがたくさん多すぎありました。
なかでも、新しいリストとドキュメントライブラリのUI(画面)は
見た目にすぐ分かる変化でしたので、気になった方も多いかと思います。
(Surfaceなんかでのタッチ操作に適した画面なのかな?)

※参考サイト:
ドキュメントライブラリの新しい UI について – マイクロソフトコミュニティ
[SharePoint の未来] モバイル、モダン UI、新ワークフローへの対応強化でさらにインテリジェントなプラットフォームへ(Microsoft Partner Network ブログ)
Update on Modern Document Libraries and Extensibility – Microsoft Office Dev Center

ただ、操作感が前の方が気に入ってた*とか、
よりクリティカルには、JavaScript等でカスタマイズを入れてた場合は
「前のUIに戻したい」というニーズが結構あるのではないかと思います。
*ちなみに個人的にはリストの複数行(拡張リッチテキスト)フィールが、
編集アイコンをクリックしてからでないと入力できないようになってしまったのが
地味に気になっています。
なので、今回のネタは 「新しいUIになったリストやライブラリを従来のUIに戻す方法」 です。
(年の瀬も近いので過去を振り返る的なノリで(笑) )
変更する対象範囲別に下記の3パターンがあります。

  1. テナント全体
  2. 個々のリスト または ライブラリ単位
  3. サイト または サイトコレクション単位

1. テナント全体

Office365のテナント全体≒SharePoint Online全体で「新しいUI」を使わなくする設定がコレです。

まず、Office365の管理センタからSharePoint管理センターの画面を開きます。

2016-12-14_234547

2016-12-14_234620
そして、SharePoint管理センターのサイドメニュー「設定」を選択します。
すると開く設定メニューの中に 「SharePoint リストおよびライブラリのエクスペリエンス」 という設定メニューがあります。
おそらく、デフォルトでは「新しいエクスペリエンス (自動検出) 」というメニューが選択されているかと思いますが
これが リスト・ライブラリを「新しいUI」にする設定です。
なので、ここで「クラシック表示のエクスペリエンス 」を選択すれば
そのSharePoint Online環境にあるすべてのリスト・ライブラリが従来のUIに変更されます。

2. 個々のリスト または ライブラリ単位

1のように、全てを従来のUIに戻してしまうのではなく、
特定のリスト・ライブラリのみを戻して、他は「新しいUI」にしたいという場合は
テナントの設定は「新しいエクスペリエンス」にしておいて
個々のリスト・ライブラリ単位で設定を変更することができます。
1と比較して、テナント管理者でなくても実施できる*のも利点かと思います。
*リストの管理者権限は必要

個々のリスト・ライブラリ単位で戻す方法には二通りあります。

一つ目は、対象のリスト・ライブラリを開いたときにサイドリンクバーの下部(画面左下)に表示される
「従来のSharePointの表示に戻す」リンクです。
2016-12-14_233044
新しいUIになっているリスト・ライブラリでこれをクリックすれば、一発で以前のUIに戻りますので
これが最も簡単な方法だと思います。

ただし、これは一時的な変更で、
サインアウトなどして再度そのリスト・ライブライにアクセスすると「新しいUI」に戻ってしまっています。
また、どうやらログインユーザー単位の設定のようで
「従来のSharePointの表示に戻す」クリック直後に、別のユーザーが同じリストにアクセスしても
新しいUIが表示されることもあるようです。

個々のリスト・ライブラリに対して、
継続して(どのユーザーがアクセスしても)従来のUIで表示するためには別の設定をする必要があります。

変更したいリスト・ライブラリ開いて、画面右上の歯車メニューから
「リストの設定 (またはライブラリの設定)」を選択します。
2016-12-15_001018
そして、設定メニュー「詳細設定」を開くと、「リストの表示」という設定メニューがあります。
2016-12-15_001250
「管理者が設定した既定の動作」は、上記1のテナント全体の設定に依存することになります。
このリスト・ライブラリ単位で従来のUIを使用したい場合は「クラシック表示」を設定します。
これで、そのリスト・ライブラリは従来の表示のままになります。

3. サイト または サイトコレクション単位

「テナント単位の設定だと大きすぎて、個々のリスト・ライブライ単位での設定だと細かすぎる」というケースもあるかもしれません。
たとえば、「このサイト内にあるリスト・ライブラリは全部「従来のUIにしたいけど、リストが沢山あって一つずつ変更していくのは面倒すぎる!」というような状況です。

このような場合は、サイト(サブサイト) または サイトコレクション単位で、
デフォルトとして「従来のUI (クラシック表示) 」を使うように設定することができます。
ただし、この設定変更だけはこれまでの方法と違ってサイト画面(ブラウザ)からは変更すことはできず
Windows PowerShell を使ってサイトのデフォルト設定を変更する必要があります。

その詳細手順はここで書くと少し長くなってしまうことと、
下記サイトにサンプルコードまで載ってるので、そちらをご参照ください (汗)。
リストまたはドキュメント ライブラリの既定の環境を新しい環境またはクラシック環境に切り替える の
「(管理者向け) Windows PowerShellを使用してサイトとサイトコレクションレベルで既定の環境を変更する」 の
「サイトとサイト コレクションの既定の環境を変更する」セクションの「DocLib.ps1 」という名前で説明されている部分がそれに当たるかと思います。

※抜粋
…サイト コレクションまたはサイト レベルでドキュメント ライブラリ用に既定の環境を変更するには、CSOM (クライアント側のオブジェクト モデル) ラッパーで次のように Windows PowerShell を使用する必要があります。
…(略)…

# To apply the script to the site collection level, uncomment the next two lines.
 $site = $clientContext.Site;
 $featureguid = new-object System.Guid "E3540C7D-6BEA-403C-A224-1A12EAFEE4C4"

# To apply the script to the website level, uncomment the next two lines, and comment the preceding two lines.
 $site = $clientContext.Web;
 $featureguid = new-object System.Guid "52E14B6F-B1BB-4969-B89B-C4FAA56745EF"

# To turn off the new UI by default in the new site, uncomment the next line.
 $site.Features.Add($featureguid, $true, [Microsoft.SharePoint.Client.FeatureDefinitionScope]::None);

※詳細は上記サイトをご確認ください。

ちなみに余談ですが、上記サイトのタイトルは
少し前までは「ライブラリの…」だったのですが、いつの間にか「リストまたは…」にアップデートされてました。

 

というわけで、従来のUIに戻す方法を説明してきたわけですが
当然のことですが、いずれは旧UIは無くなって新しいUIに統一されるとは思うので
早いうちに新しいUIを使い慣れておく方が良いかなぁとは思います (笑)。
(カスタマイズの問題は悩ましいですけどね…

 

Office 365 の「グループ」機能 をSharePoint Onlineで使ってみた

この投稿はOffice 365 Advent Calendar 2015に参加しています。

 

今回は、Office 365の新?機能である「グループ」機能(Groups)について
SharePoint Online のアクセス権限設定で使えるかを調べてみました。

なお、ここでは上記の機能を「Office 365 グループ」と書くことにします。
(どうやらコレが一般的なようなので)

※注意:本内容は2015年12月13日時点で私個人が動作確認したものです。
マイクロソフトからの公式情報としては出されていないものも含まれますので、
今後同じような動作をしなくなる可能性があります。 あらかじめご了承ください。

Office 365 グループそのものについての説明は、
もくだいさんが先日のAdvent Calendar 10日目の投稿でとても詳しく解説されているので、
ここでは割愛させていただきます。 是非そちらをご覧ください!

一応ざっくりとだけ説明しておくと、
Office 365 上で作成・使用できるグループで
メンバーで共通のメール(スレッド)・予定表・ファイル(OneDrive for Business)、ノート(OneNote)が使えるというものです。
2015-12-12_081944_2

 

さて、SharePointのアクセス権限設定で使用できるグループといえば
ActiveDirectoryの「セキュリティグループ(ドメイングループ)」と
SharePoint固有の「SharePointグループ」の2種類があります。
※参考サイト:概要: 権限を使ったユーザー アクセスの制御

これらと同じような使い方で、Office 365 グループがSharePointサイトのアクセス権限設定に使えるかをみてみます。

まず、SharePointサイトに「閲覧」の権限のみを持っているユーザーでサイトにアクセスすると
当然ながら、閲覧権限しかないので当然ドキュメントの追加などはできません。
2015-12-12_084119

 

このユーザーをOffice 365 グループのメンバーに追加します。
2015-12-12_083537
 ↓
2015-12-12_083556
そして、SharePointのサイトの権限設定画面(詳細)を開いて、
ログインユーザーをメンバーに入れておいたOffice 365 グループに
「アクセス許可の付与」から「投稿」の権限を付与します。
2015-12-12_094549

ちなみに、このユーザー選択ダイアログでの注意点として
Office 365 グループは日本語の名前では検索ヒットしませんでした(通常のユーザーはできる)
グループのID(…@xxx.onmicrosoft.com等の@より前の部分)でしか検索できないようです。

 

「共有」をクリックして設定を保存すると、一覧に「テスト用グループ」が追加されました。
2015-12-12_095347
(種類は「ドメイングループ」となっているのでADグループと解釈されているようですが、これについては後で少し触れます)

では、設定したアクセス権限が正しく動作するのかを検証してみましょう。
先ほど設定したOffice 365 グループのメンバーになっているアカウントで
SharePointサイトにサインインし直します。

すると、ドキュメントの投稿に関するメニューが操作可能になっていて
実際にファイルのアップロードもできました。
2015-12-12_095940

2015-12-12_112214
つまり、Office 365 グループに付与されたSharePointサイトへのアクセス権限が
正しく動作しているということになります!

念のため、このユーザーアカウントのSharePointでの「権限の確認」を見てみると
Office 365 グループ経由で付与されていることも確認できます。
2015-12-12_100835

 

なお、私が調べた限りではありますが(2015/12/13現在)、
公式情報として「Office 365 グループをSharePoint Onlineで使える」と明記したものを見たことがないので、
あくまで“現状は使える”という状況なので、本運用するのはまだ尚早かなと思います。
(ちなみに検証したのは「先行リリース」がONのテナントです)

また、
「今でもADグループとSharePointグループの二つあって使い分けとかよくわからないのに
さらに種類が増えたら余計にややこしい」
という意見もあるかもしれません(汗)。

ただ、Office 365 グループはそれ自体(メール・予定表・ファイル等)だけでも活用が期待され、
SharePoint Online で使うか否かに関わらず今後作らていく可能性は高いので、
「Office 365 グループを作ったけど同じメンバーで使うサイトを作りたい」といったシーンで
そのOffice 365 グループがそのまま使えるというのは、
わざわざSharePoint用にグループをまた作る手間が省けるので良いことだと、個人的には思います。

さらに、Office 365 グループの特徴(メリット)は
・SharePointグループはSharePoint内でしか使えないし、メールアドレスも持てない
・ADグループはSharePointユーザー側では管理しづらい
といった既存の2種類のグループの欠点を補える面があるのではと思います。

なので、これがプレリリース段階?で終わらずに
正式な機能として実装されることを期待しています(笑)

ちなみに、先ほどの「権限の確認」画面で
SharePointに設定されたOffice365 グループの内部IDのようなものが チラッと見えていました。
個人的には、この中に含まれている
「federateddirectoryclaimprovider」(Federated Directory Claim Provider ?) となっているのが
何を意味しているのか(どうゆう仕組みになってるのか)が、なんとなく気になってます。
(ちなみにADグループのこの部分は「rolemanager」)

が、それはまた別の機会にということで。

今回は以上になります。

Japan SharePoint Group 勉強会@名古屋で登壇しました!

Microsoftの SharePoint や Ofiice365 の技術情報や運用ノウハウなどを発信するブログを始めてみることにしました。
あまり気張り過ぎずに、徒然なるままに?書いていきたいと思います。皆様どうぞよろしくお願いいたします。

さて、そんなブログの最初の投稿は、このブログを始めてみようと思い立つきっかけにもなった、「Japan SharePoint Group 勉強会@名古屋」での発表スライドの紹介です。
http://jpsps.com/event/20140920/

先月の9月20日(土)に、初の名古屋での開催があり、僭越ながら私も発表をさせていただきました。
タイトルは『SharePoint Online 「外部ユーザー」の利用と注意点』で、下のがその発表スライドです。

実は、勉強会のような場で発表をするのが全くの初めてだったので、個人的には色々と反省点が多くあったのですが、主催者や参会者の皆さまから嬉しいフィードバックをいただけたりして、「アウトプットすることの意義」を感じられた、とても良い機会となりました。(関係者の皆さま、ありがとうございました)

そんなわけで、自分が今までSharePointに5年近く携わってきて得てきた些細な情報ではありますすが発信することを続けていきたいなぁと思い、このブログ開設となったわけです。

というわけで、初回はこんな感じで…。次回からはもう少し内容のあるものを書きたいと思います(汗)。

今後ともよろしくお願いいたします。