SlideShare a Scribd company logo
1 of 156
Download to read offline
SharePoint で始める
情報共有とそのアプローチ
(Version 1.0)
”Office 365 を使い始める/使い倒す“ シリーズ
”Office 365 を使い始める/使い倒す“
シリーズについて
本シリーズの資料は、
Office 365 のサービスを使い始めたい / 使い倒したい
という時に見て頂く “読み物” です。
サービスの仕様などは公開されておりますが、
使う前にどのようなことを考えておけば良いのか?
という資料がなかったため、ご要望を良く頂くテーマごとに
シリーズとして徐々に増やしていく予定です。
また、テーマごとの資料も更新予定です。
”Office 365 を使い始める/使い倒す“
シリーズの公開予定のテーマ
SharePoint で
始める情報共有と
そのアプローチ
情報共有ツールの
使い分け
情報共有ツールで
変革の夢を見る人達へ
の
ラブソング
使ってみよう
OneDrive
for Business
Teams を
展開して使い倒す
情報共有ツールの
費用対効果を考える
2月末~3月中旬予定本資料
2月末~3月中旬予定
まとめきれたら出ます2月末~3月中旬予定
ファイルサーバーを
SharePoint に
移行するための
アプローチ
2月末予定 3月中旬~4月上旬予定
各資料の Version UP はちょこちょこしていきます
このシリーズの資料の特色として、再利用を可能としております。
Creative Commons の 「表示 4.0 国際 (CC BY 4.0)」です。
以下にどんな利用条件なの?という説明があります。
https://creativecommons.org/licenses/by/4.0/deed.ja
https://creativecommons.org/licenses/by/4.0/legalcode.ja
資料の再利用・編集は実施して頂いて構いませんが
元の資料の意図から明らかに外れてしまうような使い方だけ避けて頂ければと思います。
差し支えなければ元の資料の URL を引用した形でご利用頂けると利用者が広がるので幸いです。
本資料のアイコンおよび図形についても再利用および編集可能な状態の版権となっております。
(一方で、スクリーンショットは版権の観点があるので利用していません。
また、ライセンスに関連するところなどは変更の可能性も踏まえて参考 URL を
記載するようにしている点についてはご了承ください)
この資料の再利用について
本資料について
本資料は、 Office 365 の 1 つのサービスである SharePoint Online を
• 使い始めるためにはどのようなアプローチをすれば良いか?
• どのような点に注意を払う必要があるのか?
ということを考えた時に参考となる資料となります。
少しだけ補足(というか言い訳)
こちらの資料は、私の過去の経験と弊社含めたいくつかの事例を基に、
基本的な考え方と利用するための考え方をこのように考えておけば良いのでは?
という資料ですので、使えるところを使って頂き、皆様の会社の状況という視点を加えて頂き、
本資料をご活用いただければと思います。
(表現がゆるいのは、気軽に読んで頂きたいという思いだとお考え下さい)
2018年1月時点の情報をもとに本資料は作成しております。
Customer Success Marketing 担当:Masaru SUMI
本資料の効果的な使い方
• わかっている部分は飛ばしてください
• 基本的な構成は
考え方 → 機能的なこと → まとめ
という順序で記載していますので、
とりあえず “まとめ” だけ見て頂いても役に立てば構いません
• SharePoint は機能や設定が多くて複雑で理解できないということを
聞きますが、まずはこちらの資料を読んで頂ければある程度は
クリアになります(と信じています)
本資料でカバーしている領域
• SharePoint とはなんぞや?
• SharePoint 使い始めたいけど。。。よくわからない
• SharePoint をどうやって使えば良いの?
(ほかのサービスとの関係を含めて)
• 設計をどう考えれば良いの?
• 運用ってどうすれば良いのか?
などをまとめている資料となります。
本資料の構成について
• SharePoint とは?
• SharePoint の利用を始める前に
~ ポータルとしての SharePoint へのアプローチ ~
• SharePoint の中身はどうなっているの?
• 社外のユーザーと利用する
• ポータルの中身を作る
• SharePoint の運用を考える
• SharePoint の監査は?
• まとめ
SharePoint とは?
SharePoint は情報の入り口です。
皆様良くご存知の Yahoo、 Amazon、Wikipedia などは
一般的に “ポータルサイト” と呼ばれます。
SharePoint を “ポータルサイト” を簡単に作るものであり、
社内向けの “情報の入り口” を作るものと考えてください。
この前提で考え始めると、 SharePoint のそれ以外の機能についても
うまくまとまることが多いです。
今後考える上での一番のポイントはユーザーが “情報を探す” 際に、
「あ、あのポータルサイト(= SharePoint)に行ったら情報がありそう」
というものを用意してあげることがポイントです。
ポータルサイトを利用することのメリッ
ト?
ポータルサイトは “見られてなんぼ” の仕組みですので、
特定のテーマに関する “情報を集約しておくこと” が重要です。
その結果として、ユーザーが探したい情報を効率良く探すことができ、
“ポータルにアクセスする価値” を見出すことができる状態を創ることができれ
ば、
ポータルサイトとしては成功となります。
なので、ポータルサイトを用意する時には、
“ユーザー目線を常に考える”
必要があります。
(なぜか SharePoint の設計時にはこれが忘れられることがあるんです)
ここまでの説明とここからの説明
SharePoint は
“ポータルサイト(情報の入り口)” / “情報を集約しておくこと”
がポイントになります。そして、
“ユーザーが利用する状態にならないと意味がない”
ということを説明しました。当たり前のことなのですが
一番重要なことが忘れられることが多いので敢えて説明をしました。
ここからは
• ポータルサイトとしての SharePoint をどう考えるか?
• “ポータルサイトだけではない” SharePoint を使うか?
を説明していきます。
補足ですが
上記のスライドの説明の本質は
“何かをするには効果を出す必要がある”
という企業にとっての当たり前の方程式である
“利益 = 売上げ ー コスト” における
“コストを削減する=ユーザーの作業の効率化”
を実現することになります(この話の詳細は別シリーズの資料で取り上げ
ます)。
SharePoint の利用を
始める前に考えること
~ ポータルとしての
SharePoint へのアプローチ ~
まずはここから
SharePoint を利用する際には、
まずは “ポータルサイトとしての SharePoint” からの
アプローチをすれば OK です!
なので、まずは少し情報の整理をはじめにしていきましょう。
ポータルサイトを用意する際のポイントは以下の 2 つの視点です。
• 組織視点
営業部とか人事部などのおなじみの組織です
• 機能視点
組織以外のものが対象と考えてください。
“製品” や “組織を跨るタスクフォース” のようなものを指します。
“組織視点” と “機能視点” のイメージ
“組織視点” の例
これはまさしく部門カットです
“機能視点” の例
これは組織以外のものが該当します。
“部門またがるチーム” や
“販売している製品” などが該当します
法務部門
経営企画部門
人事部門
営業部門
IT 部門
広報部門
内部監査部門
経理部門
総務部門
働き方改革チーム
新製品開発チーム
製品の情報
イベントチーム
セキュリティ委員
会
本資料では機能視点で作成されたポータルを
“機能ポータル” と名付けます
本資料では組織視点で作成されたポータルを
“組織ポータル” と名付けます
どのようなポータルサイト
=情報の入り口が必要?
法務部門
経営企画部門
人事部門
営業部門
IT 部門
働き方改革チーム
新製品開発チーム
社長室
製品提案資料
製品価格資料
製品仕様資料
広報部門
FAQ
就業規則
IT サポート
クラブ活動
社内掲示板
経理部門
総務部門
セキュリティ委員
会
ポイントは各ユーザーにとって欲しい情報の入り口が違う
とりあえず分類分けをしてみましょう
組織視点 機能視点(組織以外)
法務部門
経営企画部門
人事部門営業部門
IT 部門
社長室
広報部門
経理部門
総務部門
働き方改革チーム
製品提案資料製品価格資料
FAQ
就業規則
IT サポート
クラブ活動
社内掲示板
セキュリティ委員
会
新製品開発チーム
製品仕様資料
ポイントは “情報の入り口” が欲しい人の数も異なる
製造部門
さらにポータルを考える上で
なんとなく、ポータルを作る上で必要な “情報の入り口” の
イメージが出てきたと思います。そしてここから進める上では
• 各ユーザーにとって欲しい情報の入り口が違う
• “情報の入り口” が欲しい人の数も異なる
がポイントになり、そしてもう 1 つ重要な概念があります。
それが、“階層” です。
“情報の入り口” の階層を考える
何故か? という回答についてはものごとを考える際に、
意識をしないで “階層” で頭の中を整理することが多いからです。
たとえば、ファイルサーバーやメールの仕分けを考えて頂くと
イメージがつきやすいかもしれません。
ユーザーは、ポータルサイトにアクセスする際に、無意識に “階層” を意識して
ポータルサイトを探すので、ほかのポータルサイトへの導線(後述)を
仕掛ける際にも重要な概念となります。
あと、SharePoint の場合は情報の発信や運用管理が
になる場合があるのでこの時点で階層を意識しておきます。
まずは組織視点のポータルから
組織視点 機能視点(組織以外)
こちらから
お話しします
“組織視点” の “ポータルサイト” の階層
ポータルサイトの場合は、部門に加えて
“全社員共通のポータルサイト” を置きます。
なぜなら、冒頭説明した通り、 “ユーザーの視点” で
考えた際に、全社員に共通の情報発信があるからです。
“階層” という概念がものごとを
捉える傾向があるため、ポータルサイトの
導線を考える上で “階層” を考えます。
法務部門
経営企画部門
人事部門
営業部門 IT 部門
総務部門
地区
販売店 A 販売店 B
全社
法務 人事 営業
・
・
・
“階層” を作ってみよう
まずは、一番上の全社ポータルから一番下の階層まで作ってみます。
一番上と下の階層はイメージがしやすいのです
が、
実際に階層を作っていくときれいな階層に
ならないこともあります。
また、ポータルの場合は “粒度” を
どのようにするかも一つのポイントになります。
一番下の階層のイメージは簡単ですが、
どこまで細かくするかが以外に難しいことがある
ここら辺
が難しい
・・・・・・
販売拠点
全社
作って見ると気づくことも
• 自分の会社の部門がわからない
• 自分の会社の組織の上下関係がわからないものがある
• 組織なんだけど、部門を跨る機能的な組織がある など
この時点で、上記のことに回答を出す必要はありません。
というのは、階層分けなどはテクニカルにある程度対応が
できるということと、とりえあず組織単位で情報の入り口を
作っておくことで大きな手戻りは発生しません。
なので、さらに具体的に詰めていきます。
“情報の流れ” と “種類” を考える
ポータルが得意なのは1方向の集約・整理された情報発信が得意という性質を持っています。
あたりまえですが、一般的には以下の傾向があります
上
階
層
構
造
下
広
い
狭
い
情報を提供する対象
SharePoint は様々な種類の
メディアをポータルに表示可能なので
対象の広さと伝えたい情報の内容によ
り
情報を伝えるメディアの候補も
想像しておくと実際のポータルの
レイアウトも作りやすい
地区
販売店 A 販売店 B
・
・
・
・
・
・
・
・
・
全社
法務 人事 営業
ユーザーの視点とポータルサイトの管理
情報を提供する対象
この粒度のポータルは
ポータルでの集約した情報を
提供すると効率が良いので
だいたい作ります。
まぁ、数千~数百なら
合っても良いかも
10人ぐらい...いる?
50人ぐらい...ん~
この頃のトレンドはこのレイヤーに
ポータルがいらないのでは?が
増えてきています。
作りたかったら場所は用意するので
勝手に作ってくださいが多いです。
(補足をするとメールとか Teams で
業務連絡ができれば良くない?と)
情報が集まるか?ということと
わざわざアクセスさせるための
情報があるか?で判断をします。
また、無理にほかのサイトの情報と
同じものを載せて混乱することは NG
広
い
狭
い
地区
販売店 A 販売店 B
・
・
・
・
・
・
・
・
・
全社
法務 人事 営業
このタイミングでユーザーの視点で情報を考える必要があります。
迷う点があるとすると、
部門横断の戦略的な位置づけの
組織がある場合ですが、
それは組織視点のポータルとして
考えて問題なく、導線だけあとで
考えればOKです。
(補足)分類わけについて 1
なにかを分類分けする際に、皆様は MECE を目指しますが、
コミュニケーションツールの領域において完璧な回答はありませ
ん。 例)メールでフォルダ分けを考える
お客様 A
お客様 B
パートナー様 A
パートナー様 B
パートナー様 A と
パートナー様 B が
協業ソリューションを作成
パートナー様共通の施策で
パートナー様 A/B と協業するが、
ターゲットとしてお客様 A/B が出てくる
パートナー共
通
パートナー様 A
パートナー様 B
OR
お客様 A
お客様 B
(某会社では、製品がまとまったり、横連携があり、製品資料のサイトに対してどの製品のカテゴリに入れるかで苦労しています)
パートナー共通
お客様共通
最初は
途中からは
… 内容によってバラバラの
フォルダに入れることにな
る
(補足)分類わけについて 2
結論
検討時点で、 統計的に多くのユーザーが想定する分けの結果を
想定して分類分けするしかない
こ
こ
分類分けで迷ったときは
→ ユーザーの意見をもらうしかない!
やってはいけないこと
→ きれいに分類分けができたけど範囲が細かい
(ユーザーからみて混乱を招くものは意味がない)
腹をくくること
つくりなおすこともある > 組織や仕事は変わるのであきらましょう。
組織視点の場合は、部門で作っておけばまぁ問題ないです。
機能視点の場合が迷うケースがでてくると思います。
次は機能視点のポータルから
組織視点 機能視点(組織以外)
今度はこちらの話
機能視点のポータルのポイントは以下
機能視点の例
これは組織以外のものが該当します。
“部門またがるチーム” や
“販売している製品” などが該当します
働き方改革チーム
新製品開発チーム
製品の情報
イベントチーム
機能視点のポータルは以下のように
カテゴライズする
永続的に必要な機能ポータル
→ 考慮が必要なのは階層
ここでは、 “永続機能ポータル” としておきます
一定期間必要な機能ポータル
→ 考慮が必要なのは運用
ここでは、 “一時的機能ポータル” としておきます
永続型機能ポータルはカテゴライズが重要
製品提案資料
製品価格資料
製品仕様資料
製品契約資料
全製品ポータル
OR
製品A
提案
仕様
製品A
提案
仕様
契約
価格
これが失敗すると本当に使いづらくなります!
(→ ユーザーへのテストが重要であり、方法は後述)
使う人の視点を考えると価格と契約は
別のカテゴリでまとめた方が良い?
まとめてみる
同じ “製品” というテーマでまとめれると
ユーザーへの利便性は上がりそう!
全製品ポータル
製品A
契約
価格
価格と契約ポータル
一時的機能のポータルは運用が重要
ポータルなのになぜ運用が入るの?
と、思われた方もいると思います。
「なぜなら SharePoint だからです」が回答です。
ということで、これは後述します
“組織ポータル” と “永続型機能ポータル”
を作っておこう
仮置きで作ってみてください。わからない・判断に迷う場合は
何がわからないかをメモとして残し関係者に聞くようにしてくださ
い。
以下を補足しておきます。
• “一定期間機能ポータル”はあとで OK です。
• 一番下の階層を考えた際に、まとめれなかったものは
メモをとりあえず残しておくで OK です。
そもそもポータルがいるか?という話があるので
参考例
組織ポータル 永続機能ポータル 粒度の小さい組織ポータルの
候補だったもの
製品A
提案
仕様
契約
全製品ポータル
…
…
価格
札幌支援
地区
販売店 A 販売店 B
・
・
・
・
・
・
・
・
・
全社
法務 人事 営業
仙台営業所
柏店
エリア統括
・
・
・
SharePoint の中身は
どうなっているの?
SharePoint のポータルは
見た目上はほかのポータルと同じように、いろんなところに
整理された様々な情報を表示させることが可能です。
そのほかのポータル製品も同じですが、
WYSIWYG (専門知識がなくても大丈夫)
ポータルを作れて、“何のコンテンツ”を
“どこに表示する”などは簡単に作成可能です。
では、SharePoint でポータルを作ると
何が嬉しいの?ということをこれから説明しま
す。
SharePoint のポータル表示層と
裏の仕組みの関係
ポータルの表示の裏は以下のようになっています。
ポータル上に
“Web パーツ”
を経由して各種データを表示します。
また、 “Webパーツ” などの
SharePoint の専門用語抜きでは
説明が難しくなってきたので、
良いタイミングなので SharePoint の
全体のアーキテクチャを説明します。
3rd Party
その他サービスのデータ
Web
パーツ
各データを
表示する窓
Web パーツで
表示できるもの
SharePoint 内のデータ
まずは全体の構造を
サイトコレクション
サイト
サイト
ファイルを保管
テキストデータ
左図の構造になっており
階層的に設定などが
管理される仕組みです。
それでは、ここから
階層の下から上へ
“SharePoint 用語の定義” を
説明していきます。
テナント
…
SharePoint の言葉の定義 1
SharePointアプリ
データベースとビューで
構成されるアプリケーション
ビュー
+=
データベース
Web
パーツ
SharePoint 内のデータ
SharePoint 内にデータを保存し、
ファイルを保存、お知らせなどの用途に
合わせて利用できるようにしたものを
“SharePoint アプリ”
という名前で提供
SharePoint アプリ
ファイルを保
管
ドキュメント
ライブラリ
お知らせを作
成
お知らせ
リスト
ニュースを作
成
ニュース
ライブラリ
SharePoint の言葉の定義 2
まずは構造に関する SharePoint の言葉の定義をまとめます。
複数のサイトをまとめて、1つの管理範囲にしたものを
“サイトコレクション” と呼びます。
このまとまりを “サイト” と呼びます。
階層の一番上ある
“サイト” を
”TOP サイト“ と呼びます。
“TOPサイト“ の
下にあるサイトを
“サブサイト” と呼びます。
ビュー
+=
データベースSharePoint アプリ
SharePoint アプリ
そのほか
もろもろの
管理機能 など
サイトコレクションの中に
TOP サイトだけを使うこともある
SharePoint の言葉の定義 3
“サイトコレクション” を基に 3 種類の派生した仕組みがあります。
サイトコレクション
Office 365 Groups
(Teams)
OneDrive
for Business
用途はポータル 用途はチーム作業用の
ポータル
(こちらは後述)
個人のファイル置き場
(本資料では
一度忘れて OK )
派生
こんな種類があるんだという理解でここではOKです。
これからの説明の中で何をどう利用していくかを説明しますので難しく考えなくて構いません!
プライベートサイト
コレクション
…
…
…
サイトコレクションの種類と利用用途
項目 プライベートサイトコレクション Office 365 Groups(Teams) OneDrive for Business
対象ユーザー
1 ~
(上限値は SharePoint の設計に依存)
1 ~ 20
(MAX: 2,500)
1
コミュニケーション 一方向 双方向 双方向
利用単位 全社・部門 プロジェクトチーム、部門 個人
Office 365 Groups
(Teams)
プライベートサイト
コレクション
……
…
OneDrive for Business
さて、ここからは構造を決めていきます。
構造を考える際のポイントは以下です。
• サイトコレクションの切り方
• Office 365 Groups(/Teams) の適用範囲
なんで、ここで Groups? というか Groups? って何?
Teams という単語まで出てきてるし。。。
まずは説明をさせてください。
実は “Office 365 全体を使いこなす”ということと、
このポータルの設計では重要な役割を占めます。
(あと、新しい概念が出てくるのはこちらで最後となります)
Office 365 Groups とは?
Office 365 Groups が出てきた背景は
“チーム作業をできる場所を簡単に作る”
という背景から出てきたサービス(仕組み)となります。
たとえば、チームで働くには、メーリングリストがあると便利だし、
チームの予定表も欲しいし、チーム内で共有できるファイル置き場とかもほしい。
長期的なプロジェクトならポータル、人が入れ替わってもコンテンツ引き継げる
など
でも、それを用意するには全部依頼して運用で使い方も工夫が必要。。。
これをワンクリックで簡単に用意します!というのが Office 365 Groups です。Office 365 Groups の参考情報
https://support.office.com/ja-jp/article/office-365-%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%81%AE%E6%A6%82%E8%A6%81-b565caa1-5c40-40ef-9915-
60fdb2d97fa2#ID0EAACAAA=%E6%A9%9F%E8%83%BD%E3%81%A8%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9
Office 365 Groups の中身は?
Office 365 Groups の中に SharePoint があるのがポイントであり、
全体として Office 365 を使いこなすという点で今までの話にからめる必要がある。
Office 365 Groups の中で
サイトコレクションが 1つ作成され、
ポータル機能やファイル管理機能などを提供
(SharePoint の機能で提供がされるが、
一部設定機能に差異あり)
1 Click すると
Groups の中には
サイトコレクションが存在
チームに参加するユーザー
活動を可視化する
ダッシュボード
(PowerBI)
簡易タスク管理
(Planner)
ポータル
(SharePoint)
チームの
メーリングリスト
(Exchange)
チームの予定表
(Exchange)
Office 365 Groups
ファイル共有
(SharePoint)
Office 365 Groups はわかるけど
なんで Teams が出てくるの?
理由を説明するまえに、 Teams とはなんぞや?ということをまとめると
コミュニケーションという点でグループで永続的なチャットを
利用するということで作業効率を高めるという前提で作られた製品です。
チームでチャットを
利用して早く・効率的な
会話で業務を促進
会話の流れから
Web 会議を実施し
議事録・タスクを管理
など さらにからの
ほかのサービスを
組み合わせて
用途に合わせて
業務を集約
ツールの使いわけについては
別の資料で説明をしております。
会話の流れから
ファイルを共有して
同時に作成
Teams の裏の仕掛けは
Teams はインタフェースとしては永続型のグループチャットのインタフェー
スを用意しているだけで裏のリソースは Office 365 Groups と共有してい
る Office 365 Groups
Microsoft Teams
リアルタイムのコミュニケーションに
焦点を充てたインターフェイス
利用する用途ごとに構造化および
最適化されたインターフェイス
上記のような仕掛けで動いています。 一部のリソースを共有しており、作り方によっても機能差(後述)が出ますが
この資料ではポータルを考える資料なので、こんな仕組みになっているんだという理解で OK です。
活動を可視化する
ダッシュボード
(PowerBI)
簡易タスク管理
(Planner)
ポータル
(SharePoint)
チームの
メーリングリスト
(Exchange)
チームの予定表
(Exchange)
ファイル共有
(SharePoint)
チャット
(Teams)
Web 会議
(Teams)
永続機能ポータルは SharePoint or Office
365 Groups どちらで作る?
前提として “組織” の観点は入らないですが、組織の運営上は
ずっと必要になるテーマには “コミュニケーション” という観点で
SharePoint なのか Office 365 Groups なのかを決めてください。
コミュニケーションが片方向 コミュニケーションが双方向
SharePoint
製品情報の発信、など
Groups
ヘルプデスクなど
ここで言うコミュニケーションとが双方向とは、
“サポートする人“ と ”サポートされる人” に加え
て
“サポートする人” 同士でもコミュニケーションが
発生するため
サポートデスクメンバー内の世界
例)サポートデスク
Office 365 Groups と Teams でサポートデスクをする場合
簡易タスク管理
(Planner)
サポートポータル
(Office 365 Groups)
ファイル共有
(Office 365 Groups)
チャット
(Teams)
サポートデスクの
メーリングリスト
(Office 365 Groups)
FAQ を確認
サポートメン
バー
同士の相談
過去の問い合わせを
FAQ として
ポータルにまとめて表示
サポートメンバー内の
タスク管理と負荷状況の確
認
サポートメンバーが
作成したドキュメントを保管
サポート
デスク
エンド
ユーザー
チームの予定表
(Office 365 Groups)
サポートメンバーの
全体スケジュール
メーリングリストで
問い合わせを受け付け
この構図はいろんなところで利用できます。また、ここに Yammer、 PowerApps, Flow などを
組み合わせると結構いろいろなことができますが、それはまた別の資料で
ポータルという観点でのまとめ
あとは、階層がある場合に、どのように構成をするかを考えれば OK です!
組織ポータル
機能ポータル
永続 一時的
イメージ
テーマごと 個人のファイル置き場 プロジェクト
関連する項目 SharePoint
SharePoint/
Groups(Teams)
OneDrive
SharePoint/
Groups(Teams)
例 組織の部門
製品情報
ファイルアーカイブ
ヘルプデスク など
個人用ファイル置き場 短・中期間のプロジェクトなど
Office 365 Groups
(/Teams)
SharePoint
Office 365 Groups
(/Teams)
SharePoint…
…
…
階層をどのように実現するか?
階層の作り方は考え方として 2つあります。
階層を作るという点では何が異なるのか?というポイントですが
• ユーザー目線ではあまり差異がありません。 というのはサイトからどういう導線作るかだけな
ので
• 運用管理の点が主に変更があります。
1つのサイトコレクションに
サブサイトを作っていく
複数のサイトコレクションを
リンクで階層とする
運用管理にどのような違いがでるかの違いを知るために
サイトコレクションで何が管理できるかを説明します
…
…
…
サイトコレクションという単位での管理
サイトコレクションという単位で管理できること
• 容量の管理単位(サイト単位では容量管理は不可)
• SharePoint グループの利用範囲(後述)
• サイトコレクション内の
TOPサイトからサブサイトへの権限の継承
• Feature の有効化範囲
などなどがありますが、もう 1 つ重要な観点があります。
それは現在存在するポータルの 2 つの種類に関係しています。
OR
…
…
…
SharePoint のポータルの種類
ポータルを大きくカテゴライズすると 2 種類存在しています。
• クラシックサイト
SharePoint Server 2007 以降から
現在まで SharePoint Online 含めて提供
• モダンサイト
SharePoint Online / SharePoint Server 2019(予定) で利用可能
(テクニカルな観点での クラシック との違いは後述)
こちらの選択は、サイトコレクションレベルの範囲で影響します。
共通していること
今まで説明した以下の点は変わりません
• WYSIWYG でポータルを作れる(専門知識がなくても大丈夫)。
• Web パーツと呼ばれる部品を張り付けてポータルのコンテンツを作る
クラシックサイトとモダンサイトの主な
違い
項目 クラシックサイト モダンサイト
Responsive デザイン
(画面サイズに合わせての
自動レンダリング)
なし
あり
画面サイズが異なる PC / タブレット /
モバイルからポータルを参照する際におすすめ
サブサイトの作成 クラシックのサブサイトを作成可能
“チームサイト”のサイトコレクションテンプレートの場
合
サブサイトの作成不可
“コミュニケーションサイト”の
サイトコレクションテンプレートの場合は
モダン のサブサイトを作成可能
Web パーツ クラシック用の Web パーツ
モダン 用のパーツ
レンダリングやデータ表示の処理が異なる
また、よりリッチなコンテンツと
外部のサービスとの連携に対応
PBI の Web パーツはモダンのみなど
他のサイトコレクション/サイトの
データの取得
可能
ただし、サイトコレクション内と外で実現方法に差が
出る
より柔軟に取得可能
UI の変更 SharePoint Designer
業界標準ツールでの対応
(難易度は高い)
Office 365 Groups(/Teams) との関係 クラシックサイトは使われない
モダンサイトが使われる
(“チームサイト”のサイトコレクションテンプレート)
モダンサイトコレクションのテンプレー
ト
“チームサイト” のテンプレートの
サイトコレクションテンプレート
サイトコレクションの作成と同時に
Office 365 Groups が作成される
“コミュニケーションサイト” の
サイトコレクションテンプレート
従来のSharePoint と同じだが、
サイトはすべてモダンサイトになる
…
…
…
サブサイトの
作成不可
(参考)サブサイトの作成制御
とにかくサブサイトでの運用をしたくない!
という場合は以下のメニューで制御可能です。
サブサイト
サイトの所有者(およびサイトを作成するためのアクセス権を持つその他のユーザー)が
サブサイトを作成できるかどうかを管理します。これは、[サイトのコンテンツ]ページの
[新規]メニューに[サブサイト]コマンドを表示するかどうかを制御します。
〇 [サブサイト]コマンドを非表示にする
〇 クラシックサイトに対してのみ[サブサイト]コマンドを表示す
る
⦿ すべてのサイトに[サブサイト]コマンドを表示する。
他のサイトコレクション/サイトのデータ
の取得の補足
項目 クラシックサイト モダンサイト
~
他のサイトコレクション/サイト
の
データの取得
可能
ただし、サイトコレクション内と外で実現方法に差が出る
より柔軟に取得可能
SharePoint アプリのデータを
サイト/サイトコレクションの違いを
意識せずに活用しやすい仕組みが多い
~
の話の続きですが、
これからポータルを作成するのであれば、ユーザーの利用という
観点を重きに置くとモダンの利用が基本となります。
クラシックサイトの時はほかのサイトコレクションの情報の活用にも
制限があり、利用する場合は事前に工夫が必要でした。
階層の作成方法によるメリット・デメ
リット
メリット
モダンサイト(コミュニケーションサイトテンプレートのみ)およ
び
クラシックの場合
サイトコレクション内のサイトで権限の継承が可能
モダンサイトおよびクラシックサイトの場合
• ファイルやリストアイテムの数が大量で
大容量になる場合に管理がしやすい
• サブサイトで管理するより、サイト(TOPサイト)の
関連付けが柔軟に構成が可能(組織変更による階層変更など)
モダンサイトの場合
ハブサイトが利用でき、共通の設定の簡素化、情報の利活用、情報をを見つけやす
い
デメリット
モダンサイト(コミュニケーションサイトテンプレートのみ)およ
び
クラシックの場合
• 組織の変更などがあり、階層という観点で、
“サブサイトがTOPサイトになる” /
“ほかのサイトコレクションのサブサイトになる” という
変更が技術的に難しい
• 容量の管理がサイトコレクションとなるため、
サイト単位での容量把握が難しく対応も難しい
クラシックの場合のみ
サイトコレクションをまとめるという観点の機能が存在しない
上位からの権限の継承が利用できない
(ただ、そもそも組織のポータルで権限を継承するのは
全社員の表示権限だけのことが多いので、
ユーザーの使いやすさを優先すると誤差になると考えても良いかもしれません)
まとめると、初回の一時的な設定がサブサイトの時よりは多くなりますが、
全体でみるとそのメリットは誤差であり、
今後はサイトコレクションで階層を作る=管理する方が良いかもしれません。
アクセス権の継承によるメリットと
は?
A 部門向けサイト B 部門向けサイト C 部門向けサイト
全社員向けサイト
読み取り権限を全社員につける
ファイルサーバーのように
権限が自動的に継承される・
また、ファイルサーバーと同じように
権限の継承を切ることも可能です。
組織ポータルの範囲では、全社員が読み取り権限が付くことが多いため
楽に見えるかもしれませんが、たいていの場合は部門固有の権限の制御のため
権限の継承を切ることになるので、メリットが享受できるのは一部の場合となります。
アクセス権の継承の補足
サイト
ドキュメント
ライブラリ
リスト
1 レコード
アイテムと呼ぶ
=
1 ファイル
アイテムと呼ぶ
=
継承の階層は基本は 3 つ ドキュメントライブラリは
ライブラリの中でフォルダ階層を
作成することが可能であり、
フォルダの権限はフォルダ下のファイル
に
権限が継承され、権限の継承を切ること
も
ファイルサーバーと同様に可能です。
SharePoint
アプリ
アイテム
データベースの
1 レコード
サイトコレクションで階層を
作る場合のシナリオ
この階層の形式で有効なシナリオは以下があります。
前提として、格納するファイルの数が将来的に
多くなりそうなシナリオです。
• 自社製品の情報をまとめるポータル
• サイトコレクション同士の関連付けが柔軟になるため
組織の変更、製品の編成などのカテゴライズなどの変更
に柔軟に対応可能
• ファイルサーバーの移行先(こちらは後述) など
こちらの構成を取る場合は、モダンサイトを
利用することが推奨です。理由は、
• モダンサイトの Web パーツは表示に関する
データ処理のロジックが違う
• サイトコレクションを越えたデータを取る
Web パーツが充実している
モダンサイトをまとめて管理する仕組み
サイトコレクションで階層を管理する場合、
モダンサイトのサイトコレクション同士をグルーピングする
“Hubサイト”という機能が用意されています。
参考情報
https://support.office.com/ja-jp/article/sharepoint-hub-%E3%82%B5%E3%82%A4%E3%83%88%E3%81%A8%E3%81%AF-fe26ae84-14b7-45b6-a6d1-948b3966427f
製品情報ポータルTOP
製品A 製品D製品B 製品C
• Hub サイトでまとめられたニュースのロールアップ
例) 全社サイトのニュースの一部を特定部門サイト
で
表示する
• Hub サイトでまとめられた検索結果の表示
例) 例えば左記のように構成することで、検索結果
が
左記の範囲内のコンテンツなのかどうかが
検索結果でわかるにように表示される
サイトコレクションの切り方関連で
よくあるQA
質問 回答
サイトコレクションを分けるとサイトコレクションのデータ
を
参照するのが大変ではないですか?
モダンサイト用 の“強調表示されたコンテンツ Web パーツ”
を
利用すれば簡単にお互いのコンテンツを相互参照可能です。
サブサイトは使わないのですか?
使うことは運用の観点のメリットが十分にある場合は
利用すべきです。たとえば、組織ポータルで
人事、法務や総務など部門として間違いなく残り続ける部門
は
サブサイトで管理したほうが効率が良くなる可能性が高いで
す。
ただし、以下の場合は向かないかも。。。
• モダンサイトの“チームサイト”のテンプレートではサブサ
イトをそもそも作ることはできない
• 大量のファイルを保存する可能性があるならTOPサイトだ
けで運用したほうが運用管理的には楽になります。
• 階層の構成がある程度頻繁に変わることが想定される場合
サイトコレクションを分けると、権限の継承やSharePointグ
ループの有効活用という観点で運用管理が大変になるので
確かにそうなる場合はあります。
ただし、組織ポータルという観点では、
権限設定する手数の大小が最初の設定に影響しますが、
運用に入ればある程度は自動化が可能です(後述)
組織のポータルのまとめ
数千~数百人
Groups / Teams を前提としたモダンサイト
(チームサイトのサイトコレクションのテンプレート)で良いと思います。
ポータル内のコンテンツをちゃんと作成するかはまとめる意味があれば
作るぐらいでも良いですし、ポータル内のコンテンツ作成自体も
権限移譲するケースが近年は多いです。
ポータルを作った場合もモバイルでチェックできることはこの規模だと重要
まとめて情報を発信するのがわかりやすい形 MECE に区切れず、
量も中途半端になる場合は作らない方がユーザーにとっては嬉しい
全社員向け
モバイル利用を視野に入れるとモダンサイトがおすすめ(これから作る場合は特に)。
リッチメディアでの情報発信もモダンのほうが制御しやすいため。
また、モダンのサイトコレクションのテンプレートとしては、
コミュニケーションサイトで構成
10~50人
地区
販売店 A 販売店 B
・
・
・
・
・
・
・
・
・
全社
法務 人事 営業
組織のポータルのまとめ 2
・
・
・
・
・
・
・
・
・
…
…
…
運用効率が良く、かつ将来にわたり
階層が変わることや大容量の
ファイルなどを管理する必要が
ない場合もしくは、組織内のみの
情報管理するなどの用途の場合は
サブサイトを利用
サイトコレクションを分
けた方が良い条件に合致
する
場合は分ける
永続機能ポータルにおけるポイント
大量のファイル管理が今後発生するかしないかだけを考慮する。
今までの話から新しいことはありません。
すなわち考慮することは以下の右側のパターンを選択しておくこ
と
こちら
ポータルという観点でのまとめ
組織ポータル
機能ポータル
永続 一時的
イメージ
テーマ 個人 プロジェクト
利用する
テンプレート
クラシックサイト:
プライベートサイトコレクション
モダンサイト:
コミュニケーションサイト
クラシックサイト:
プライベートサイトコレクション
モダンサイト:
コミュニケーションサイト
OneDrive
クラシックサイト:
プライベートサイトコレクション
モダンサイト:
チームサイト
関連する
サービス
SharePoint
SharePoint/
Groups(Teams)
OneDrive
SharePoint/
Groups(Teams)
例 組織の部門
製品情報
ファイルアーカイブ
ヘルプデスク など
個人用ファイル置き場 短・中期間のプロジェクトなど
Office 365
Groups
(Teams) SharePoint
社外のユーザーと利用する
外部招待の対象は?
外部招待を利用する可能性があるものは下記の赤枠が対象
組織ポータル
機能ポータル
永続 一時的
イメージ
テーマ 個人 プロジェクト
利用する
テンプレート
クラシックサイト:
プライベートサイトコレクション
モダンサイト:
コミュニケーションサイト
クラシックサイト:
プライベートサイトコレクション
モダンサイト:
コミュニケーションサイト
OneDrive
クラシックサイト:
プライベートサイトコレクション
モダンサイト:
チームサイト
関連する
サービス
SharePoint
SharePoint/
Groups(Teams)
OneDrive
SharePoint/
Groups(Teams)
例 組織の部門
製品情報
ファイルアーカイブ
ヘルプデスク など
個人用ファイル置き場 短・中期間のプロジェクトなど
Office 365
Groups
(Teams) SharePoint
外部共有の設定の範囲
テナント範囲での設定と、各サイトコレクションの範囲での設定の
2 つを組み合わせて設定を実施
テナント全体の外部共有設定
組織外との共有
ユーザーが組織外ユーザーとコンテンツを共有する方法を制御します。
● 組織外の共有を許可しない
○ 組織のディレクトリに既に存在する外部ユーザーとの共有のみ許可します
○ ユーザーに認証済み外部ユーザーの招待および共有を許可する
○ 認証済み外部ユーザーとの共有と匿名アクセスリンクの使用を許可する
社外と共有する
ユーザーが組織外のユーザーを招待してコンテンツにアクセスできるようにする方法を
制御します。
● 組織外の共有を許可しない
○ 組織のディレクトリに既に存在する外部ユーザーとの共有のみ許可します
○ 共有への招待を承認する外部ユーザーを許可し、認証済ユーザーとしてサインインする
○ 匿名アクセスのリンクを使用して、すべての外部ユーザーとの共有を許可します
プライベートサイトコレクション単位の設定
SharePoint の
サイトコレクション
単位での設定
OneDrive 全体への
共通の設定 /
個別の設定
Groups / SharePoint の
サイトコレクション
単位での設定
テナント
テナントでの設定
…
…
…
テナント全体の外部共有設定と
サイトコレクションの外部共有設定の関係
パターン テナント全体の設定
左記の設定で SharePoint のサイトコレクションの設定可能な項目 /
OneDrive for Business の設定可能な項目
パターン1 外部共有なし 外部共有なし
パターン2 既存の外部ユーザーのみ(サインインが必要)
外部共有なし
既存の外部ユーザーのみ(サインインが必要)
パターン3 新規と既存の外部ユーザーのみ(サインインが必要)
外部共有なし
既存の外部ユーザーのみ(サインインが必要)
新規と既存の外部ユーザーのみ(サインインが必要)
パターン4 誰でも(匿名ユーザー含む)
外部共有なし
既存の外部ユーザーのみ(サインインが必要)
新規と既存の外部ユーザーのみ(サインインが必要)
誰でも(匿名ユーザー含む)
テナントの設定
サイトコレクションの設定
テナントの外部共有設定がサイトコレクションの外部共有設定より上位の設定となっている必要
がある
□ 匿名アクセス リンクの有効期限が切れるまでの日数:
匿名アクセス リンクを使うと、受信者が次の事を実行できます。
ファイル:
フォルダー:
テナントレベルで制御する項目
外部との共有を許可している状態で以下の項目を設定可能
• セキュリティグループを利用して、外部招待を利用できるユーザーを制御
• そのほか代表的な設定項目
• 招待可能なドメインの設定
• 各種通知
□ 選択したセキュリティ グロープ内のユーザーにのみ承認済み外部ユーザーとの共有を許可します
□ 選択したセキュリティ グループ内のユーザーにのみ、承認済み外部ユーザーとの共有および匿名リンクの使用を許可します
表示と編集
<
表示、編集、アップロード
表示
表示
<
• 匿名アクセス利用時の有効期限と公開レベル
外部共有設定と招待できるユーザーについて
外部共有の設定 招待(権限付与)可能なユーザー
外部共有なし
社内ユーザーに限定可能
※ 他サイトコレクションで招待済みの外部ユーザー
(Azure AD に外部ユーザーとして登録済みの外部ユーザー)は、
ユーザー選択時に候補として表示されない
既存の外部ユーザーのみ
(サインインが必要)
• 社内ユーザー
• 他サイトコレクションで招待済みのユーザー
新規と既存の外部ユーザーのみ
(サインインが必要)
• 社内ユーザー
• 他サイトコレクションで招待済みのユーザー
• 新規外部ユーザー
誰でも(匿名ユーザー含む)
• 社内ユーザー
• 他サイトコレクションで招待済みのユーザー
• 新規外部ユーザー
• 匿名アクセス用リンクの生成によるアクセス
利用可能なユーザーの種類:上記の “サインイン” が必要というのは ID と PW が必要ということで、下記の “認証ユーザー” のこ
と
• 匿名ユーザー:ファイル、フォルダに対して一意の複雑なURL を利用してコンテンツを公開
• 認証ユーザー:以下のアカウントを利用して、設定された範囲内で通常の Office 365 内のアカウントと同様に利用可能
• Microsoft アカウント:alias@outlook.com / alias@Hotmail.com など
(個人単位でビジネスメールアカウントを Microsoft アカウントとして利用することも可能
• 組織アカウント:Azure Active Directory 上で既に存在している ID のこと
例)
• 別テナントの Office 365 アカウント
• そのほか Microsoft の SaaS サービス( Azure AD、Dynamics、Power BI など)
匿名ユーザーと
認証ユーザーの組織アカウント?
組織アカウントとは?匿名ユーザーとは?
1 つのファイルに対して
一意のURLを作成
そのURLでのみ
アクセス可能になる
オプションとして以下の設定が可能
• 有効期限
• ワンタイムパスワードでの共有
• ダウンロード禁止
Azure Active Directory Azure Active Directory
自社内の
ユーザー
ゲストユーザーは自分の会社の ID/PW で、
招待された SharePoint にログイン
社内のユーザーは
自社で利用している
ID/PW でログイン
・・・
SharePoint
一度でも招待されると
”外部ユーザー(ゲスト)” として残る
Azure Active Directory は Office 365 で利用しているクラウドの認証基盤のこと
https://azure.microsoft.com/ja-jp/pricing/details/active-directory/
自社内に
招待したユーザー
ID/PWID/PW
連携
招待された
社外のユーザーは
あくまでゲストアカウントで動作
サイトコレクションの範囲での
外部共有に関する代表的なそのほかの設定
招待は誰でも可能だが、
サイトコレクションの管理者の承認が必要
外部のユーザー
外部のユーザー
承認が必要
@company.com
特定の取引先などの
特定のドメインのみ許可す
る
Office 365 Groups(/Teams) の
社外との利用について
Office 365 Groups の中でサイトコレクションに対して
SharePoint として外部招待をすることは可能だが、
管理上複雑となるためそのような使い方は非推奨。
あくまで、Office 365 Groups(/Teams)の
標準機能として用意されている
外部ユーザーを制御する機能を利用する。
社内のユーザー 社内のユーザー
Office 365 Groups のロールと
外部ユーザー招待
テナントレベルで外部招待のオン/オフを設定
ロール グループの種類
ユーザー管理 グループの設定
組織内ユーザーの
追加
外部ユーザーの
招待
メンバーの
削除
組織外のユーザーへの
メール送信設定の変更
プライバシーの変更
(グループの公開・非公開)
グループの削除
メンバー
パブリック
グループ
〇
〇
(所有者の
承認が必要)
× × × ×
プライベート
グループ
(所有者の
承認が必要)
〇
(所有者の
承認が必要)
× × × ×
所有者
パブリック
グループ
〇 〇 〇 〇 〇 〇
プライベート
グループ
〇 〇 〇 〇 〇 〇
…
Office 365 Groups に
参加したメンバーは
以下の 2 つのロールのどちらかを設定
メンバー所有者
OneDrive for Business の管理
OneDrive の外部共有の設定について
管理センターで用意されている標準メニュー(UI で設定という意味)での外部共有の設定は、
すべての OneDrive に対して許可をするかしないかです。
https://tenantname-my.sharepoint.com に対して外部共有の設定をすると
すべての OneDrive 反映されます。
特定の個別の人に許可をしたい場合は全体の外部共有を禁止にして、
PowerShell で個別に許可する必要があります。
OneDrive からユーザーの管理者権限をはく奪する
OneDrive は各ユーザーが、各サイトコレクションに対して管理者権限を保有しますが、
これをたまに制御したという話を聞きますが、止めてください。
また、こちらから管理者権限を削除することにより Delve などの機能が利用できなくなることに
加えて、厳密にやろうとすると利便性の高い “共有メニュー” も制御する必要があり、
運用設計や、ユーザーが利用できそうに見えるメニューが動作しないなど
副次的な影響が多いため、実施しない方が無難です。
外部共有の設定のシナリオ 1
テナント全体の設定としては匿名アクセス含めた外部共有を許可をし、
サイトコレクション単位で外部共有の制御を実施するシナリオ
外部共有の設定 外部共有禁止
認証ユーザーのみ
共有可能
認証ユーザーのみ
共有可能
匿名ユーザーとの
共有可能
特定の取引先との
機密度の高いプロジェクトポータ
ル
取引先全体に対して
情報を公開するポータル
個人のファイル
置き場
テナントレベル:外部共有許可
社内向けの製品情報や
契約関連の情報をまとめたサイ
ト
…
…
…
…
…
…
外部共有の設定のシナリオ 2
シナリオ 1 に “特定ドメインの拒否” の設定と
“サイトコレクションの所有者のみが外部ユーザーを招待可能” という設定を加えたシナリ
オ
外部共有の設定 外部共有禁止
認証ユーザーのみ
共有可能
認証ユーザーのみ
共有可能
匿名ユーザーとの
共有可能
ドメインの
制限
N/A
domainB.com のみを招待可能
(テナント全体の設定により
domainA.comとの共有は禁止)
取引先のドメインのみ
(テナント全体の設定により
domainA.comとの共有は禁止)
(テナント全体の設定により
domainA.com との共有は禁止)
外部
ユーザーの招待
N/A
所有者権限を
保有するユーザーのみ招待可能
特に制限なし
テナントレベル:外部共有許可+競合である domainA.com との共有は禁止
特定の取引先との
機密度の高いプロジェクトポータ
ル
取引先全体に対して
情報を公開するポータル
個人のファイル
置き場
社内向けの製品情報や
契約関連の情報をまとめたサイ
ト
…
…
…
…
…
…
Office 365 Groups(/Teams)の
招待するユーザーのドメイン禁止/許可
参考情報
https://docs.microsoft.com/ja-jp/exchange/recipients-in-exchange-online/manage-group-access-to-office-365-groups
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-lifecycle
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-settings-cmdlets#template-settings
“許可リスト” または “ブロック リスト” の
2 つの種類で設定が可能ですが、
両方の種類のリストを設定することは不可となります。
社内のユーザー
contoso.com を拒否
特定の Office 365 Groups
(/Teams)だけ外部招待を許可する
参考情報
https://docs.microsoft.com/ja-jp/office365/admin/create-groups/manage-guest-access-in-groups?view=o365-worldwide
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-settings-cmdlets#template-settings
社内のユーザー 社内のユーザー
そのほか考えること
上記のシナリオ以外にどのような設定を一般的に考慮すると
そのほかポイントとなる設定を
次スライド以降でいくつかご紹介しておきます。
SharePoint で特定のユーザーに
外部招待をさせない
SharePoint ( OneDrive 除く) のサイトに外部ユーザーを招待するには、
ユーザーに管理者権限が必要となっています。
ただし、外部共有が可能な状態である場合に、管理者権限を保有していなくても
ドキュメントやリスト、ライブラリについては “共有” 機能を利用すると
外部のユーザーにそれらを共有することが可能となります。
たとえば、
• 派遣・契約社員には共有をさせたくない
• 管理者権限を持っているユーザーであったとしても、外部招待をさせたくない
(こちらはなかなか全体で整合性取るのは難しいかも)
これらを検討する対象
外部共有が対象の一時的機能ポータルや Office 365 Groups (/ Teams ) です。
そういう時にはテナント単位で以下の設定で制御することが可能です。
組織外のユーザーと共有できるユーザー
□選択したセキュリティ グループ内のユーザーにのみ、認証済み外部ユーザーとの共有を許可します
□選択したセキュリティ グループ内のユーザーにのみ、認証済み外部ユーザーとの共有および匿名リンクの使用を許可し
ます
SharePoint/OneDrive で
IP アクセス制限を利用した場合
SharePoint Online は単体サービスの機能として
IP を条件としたアクセス制御を実装することが可能です。
ただし、こちらを設定すると外部ユーザーも対象になるため注意が必要
参考情報
https://docs.microsoft.com/ja-jp/sharepoint/control-access-based-on-network-location
SharePoint のポータルの
コンテンツを作る時のポイント
一般的なポータルと同じように以下の 2 つがポイントです。
• ほかのコンテンツのへ導線をどうするか?(今まで説明した階層もその 1
つ)
• コンテンツの配置(統一感)
SharePoint としては SharePoint アプリの “属性情報” が大事
ライブラリ
リスト テキストベースの RDB
ファイルを軸とした RDB
ビュー
+=
データベースSharePoint アプリ
SharePoint アプリでの属性情報の利用
ビューを利用して、いろいろな角度から情報を表示
タイトル 作成者 作成日時 公開可否
タイトル A 作成者 A 作成日時 A 可
タイトル B 作成者 B 作成日時 B 不可
タイトル C 作成者 C 作成日時 C 不可
タイトル D 作成者 D 作成日時 D 可
公開可否 タイトル 作成者
不可 タイトル B 作成者 B
不可 タイトル C 作成者 C
可 タイトル A 作成者 A
可 タイトル D 作成者 D
タイトル 公開可否
タイトル A 可
タイトル B 不可
タイトル C 不可
タイトル D 可
製品名 地区 A 地区 B 総売上
平均= ¥283 平均= ¥510 平均= ¥793
製品 A 130 650 780
製品 B 270 330 600
製品 C 450 550 1,000
計算をする
特定の列を表示
特定の列を利用し、
グループ化して情報を表示
(参考)モダンサイトの便利な Web
パーツ
使うシーンがたくさんある Web パーツ
チーム作業で利用すると
便利な Web パーツ
• 強調表示されたコンテンツ
• ヒーロー
• イベント
• リスト
• ドキュメント ライブラリ
• ニュース
• Office 365 コネクタ
• リンク
• Bing マップ
• ファイルビューアー
• Stream
• Yammer
• PowerBI
• カウントダウンタイ
マー
• YouTube
• Microsoft Forms
• PowerApps
• サイトの利用状況
• Microsoft Planner
• グループ予定表
(Office 365 Groups のカレンダ)
参考情報
https://support.office.com/ja-jp/article/SharePoint-ページで-web-パーツを使用する-336e8e92-3e2d-4298-ae01-d404bbe751e0#bkmk_availableparts
黄色背景色の Web パーツは使いこなすと、より便利にインタラクティブなポータルが作れます
サイトコレクション間での共有
特に、階層で管理されるポータルでは、
これがうまく設計できると非常に運用が楽になる
ハブサイトや
強調表示された
Web パーツを
うまく使いこなす
共有可能
部門Aの
ニュース
全社向けの
ニュースの
一部を表示
全社サイト
部門A サイト
ポータルのコンテンツの配置を成功させ
る
• 階層がある程度きれいに作ることができていると、
各サイトに表示するコンテンツの種類はある程度簡単に決まりま
す。
• 各ポータルのコンテンツの配置は、ユーザーの声を聴いておくこと
重要です。ポータルのメインは “ユーザーに情報を伝える” /
“ユーザーが効率よく情報を探せる” ことがメインなので。
• ポータルのTOPサイトとかは意外と簡単にコンテンツの配置は
決まります。難しいのは階層が下にさがっていくと、
各部門によって何が重要かはその部門の人しか知らないからです。
・・・そりゃそうだよね。 ということは皆様同じ
コンテンツの中身と配置を決めるために
• SharePoint で作る必要はありません!
• PowerPoint の紙芝居とか手書きで OK です。
• フィードバックについては、本当はユーザーにヒアリングが
できれば良いですが、そんな時間がない時は Forms などで
アンケートを取るでOK!
・何の情報が欲しいかと、それを踏まえたレイアウトで2 段階でとると良いです。
(この資料では触れませんが、組織として / チームとして ”こうありたい“ という
内容の要素もコンテンツとして考えておくことが本当はあったほうがよいです)
難しく考える必要はありません!
以下のアプローチで OK です。
ここで注意
過去の経験上のお話しです。
たまに “みかけのデザイン” が良くないと使われないということで、
そこから始めてしまうケースがありますが、まぁ、失敗するケースが多いです
ね。
仕事で使うので ”情報が得られることが最優先“ で ”日常無理なく使える“ が
どこかに行ってしまうケースが多いです。
1. 必要な情報の内容
2. 色と文字が見やすい(Accessibility)
3. Perceived Affordance や感情に訴えることなどを考慮
なので、 “アート” と “デザイン” は別ということです。
コンテンツ配置の紙芝居の例:全社ポータ
ル 全社ポータ
ル
広報ポータ
ル
総務ポータ
ル
法務ポータ
ル
・
・
・ 天気
全社員向けお知らせ
社長の Blog /
ビデオメッセージとか
チャットボットに聞いてみる
問い合わせ TOP10
XX ポータル(ロゴ)
よく利用するリンク集
導線が上にくるパターンもありますが、だいたいこんな感じになります(夢がなくてすいませ
ん)
コンテンツ配置の紙芝居の例:部門ポータ
ル
天気
部門のお知らせ
自分に割り当てられたタスク
とか
部門イベントスケジュール
とか
関連する Yammer の画面を
表示させる
全社ポータル 広報ポータル 総務ポータル 法務ポータル
今日の社食とか
XX ポータル(ロゴ)
全社ポータルのお知らせから
重要度の高いものなどを一部
ドキュメント関連
部門になると業務がより、具体的になるのでコンテンツはより重要です。
あと、1 つぐらいお楽しみというか業務に関係ないコンテンツがあっても良いかもです。
コンテンツ配置のポイント
• 導線を表すものは各ポータルの同じ場所にあったほうが良いです。
• 視覚は、色が濃いもの / 動いているものに最初は焦点が合います。
• 当然最初開いた際に、表示される領域には重要度が高いもの
• マルチデバイス利用下では、“スクロール” が前提になる。
昔のように、お知らせを表示し、未読・既読を管理することや、
タスク一覧をポータルに表示させても必ず表示されるとは限らなくなったため、
“別の仕組みを併用” や “通知を出す“ ようなことも考慮する
• アンケートや Feedback はいつでも受けれるようにつけておく
• “みかけ” のデザインのせいでコンテンツの中身と配置が
容易に変更できなくなるのは避ける
参考情報
https://spdesign.azurewebsites.net/
ポータルのレイアウトの昔と今
今=モダンサイトの利用時の主流
今は画面の大きさが異なる
PC/Mac タブレット モバイル
画面をスクロールすることが前
提。
↓
上部により必要な情報が集結す
る。
昔=クラシックサイトの利用時の主流
昔は画面の大きさに合わせて
コンテンツをつめていた。
モダンサイトのレイアウトのフレーム
ワーク
レイアウトに
Webパーツを設定する
セクション
セクション
セクションの中の
レイアウトを決める。
…or or
2段組み1段組み
…or or
2段組み1段組み
モダンサイトのレイアウトの表示
セクション
セクション
Webパーツ
A
C D
B
E
DのWebパーツがな
い時はこのスペー
スが空白となる。
モバイルの画面
セクションの
レイアウトの切れ目
セクションの
レイアウトの切れ目
E
A
C
D
B
PCの画面
…
セクションの
レイアウトの切れ目
レイアウト レイアウト
レイアウト
Web パーツ内で
表示サイズに合わせて
自動的に表示内容を変更
ポータル利用時のパフォーマンスについ
て確認頂きたいいくつかの注意点まとめ
全体の概要は以下にあります。
SharePoint Online のパフォーマンス チューニングの概要
https://docs.microsoft.com/ja-jp/office365/enterprise/introduction-to-performance-tuning-for-sharepoint-online
また、以下に特にご確認頂きたい内容について記載されているコンテンツがありますのでご確認ください。
Office 365 のための CDN とネットワークの要考慮事項について
https://social.msdn.microsoft.com/Forums/ja-JP/04d5f483-7316-43e8-a055-5bd2af0158f2/office-365-12398123831241712398-
cdn?forum=sharepointsupportteamja
SharePoint Online の HTTP 調整 (応答コード 429) に関して ※負荷調整機構考え方
https://blogs.technet.microsoft.com/sharepoint_support/2018/07/23/sharepoint-online-http-throttling/
SharePoint Online で調整またはブロックを回避する
https://docs.microsoft.com/ja-jp/sharepoint/dev/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online
構造ナビゲーションやコンテンツクエリ Web パーツ利用がパフォーマンス影響するケース対応
https://blogs.technet.microsoft.com/sharepoint_support/2018/06/25/spo-performance-tuning/
階層の下の方はポータルが必要?
ここの話です
こんなことが
簡単にできる
世界になりました。
Teams
全社ポータルや販売店のポータル
コネクタ
で、階層の下にあるところはTeams を使う?
という話がありました。 この時に、以下のことを
実現してあげるとユーザーもより便利に!
地区
販売店 A 販売店 B
・
・
・
・
・
・
・
・
・
全社
法務 人事 営業
ポータルで
お知らせが追加される
参考情報
https://docs.microsoft.com/ja-jp/microsoftteams/office-365-custom-connectors
(参考)ポータル利用なしの場合のお知
らせポータルを作るほどでもない規模の場合にも、当然業務上のお知らせみたいのを
全員に向けて通知したいことがあると思います。メールでもよいですが、
Teams で “一般(既定で 1 つ作成される)”以下のような使い方ができます。
チームの設定 → メンバーアクセス許可 □ チーム 1
一般
お知らせです。
新規 N件の返信
返信
経費精算して下さい。
新規 N件の返信
返信
…
…
一般チャネル:
● 誰でもメッセージを投稿できます
〇 誰でも投稿できます。投稿が全員に通知されることを示すアラートが表示さ
れます(大規模なチームに推奨)
〇 所有者だけがメッセージを投稿できます
□ チーム 2
一般
…
コンテンツの公開をまじめにやる
~ お知らせ、ニュース、ファイルなど
~
…
…
全社員が閲覧権限
権限の設定
お知らせやニュースを作る
ユーザーだけに追加で
お知らせのアプリに
編集権限を付与する
…
承認 コンテンツ責任者
マイナーバージョン 0.1
(下書き)
マイナーバージョン 0.2
(下書き)
マイナーバージョン 0.8
(下書き完成)
承認依頼の申請
メジャーバージョン1.0
(公開される。
閲覧権限がある人に
見えるようにする)
コンテンツの公開プロセス
サイトの権限を継承するの
で
お知らせのアプリも
全社員が閲覧権限を持つ
…
参考情報
https://docs.microsoft.com/ja-jp/business-applications-release-notes/april18/microsoft-flow/request-sign-off-flow-built-into-sharepoint
IRM ライブラリを利用して、
守るべき情報を守る
参考情報
https://docs.microsoft.com/ja-jp/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-service-description
ダウンロードしたタイミング
で
ライブラリの権限に合わせて
自動的に暗号化及び
ファイル操作の制御がかかる
保存不可、印刷不可など
ライブラリの中に
アップロードされた
ファイルはこの時点では
暗号化されていないので
全文検索の対象になる
…
ライブラリに権限が
ないユーザーが
ファイルを開こうとして
も
ファイルを開くことが
できない状態
コンテンツの内容に合わせた
適切な管理と保護を事前に実施(DLP)
DLP を設定することで本来保護されるべき
ファイルを自動的に検知し、企業が決めた
ポリシーに準拠していない場合は
ユーザーがファイルを見れなくする
ポリシーに沿った
適切な処理をすると
再び表示される
クレジットカード / 銀行口座 / セミナー参加者の個人情報など
の情報がたくさん入っているファイルがいろいろな場所に
点在するリスクがある。本来は特定で適切に保護されていないといけない
…
ブラウザで表示した際のファイルを
ローカルに保存させない
ブラウザ上でファイルの表示、編集はできるが、とにかくファイルを
ダウンロードさせないでポータルを利用して情報を共有することができま
す。
こちらは条件付きアクセスと組み合わせ、社外の IP から参照する時などの
条件を付けることや、社外の特定の人たちのグループなどの
条件と組み合わせるイメージです。
参考情報
https://docs.microsoft.com/ja-jp/sharepoint/control-access-from-unmanaged-devices
https://blogs.technet.microsoft.com/cbernier/2017/09/11/azure-ad-premium-conditional-access-and-session-controls/
https://docs.microsoft.com/ja-jp/azure/active-directory/conditional-access/overview#session-controls
セッションをハンドリングするこ
とで
ダウンロードを禁止にする仕組み
運用を考える
SharePoint をどう運用する?
組織ポータル
機能ポータル
永続 一時的
イメージ
テーマ 個人 プロジェクト
サイトコレクショ
ンを用意する人
IT 管理者
SharePoint
IT 管理者 or ユーザーオンデマンド
Office 365 Groups(/Teams)
IT 管理者 or ユーザーオンデマンド
IT 管理者
(自動作成)
SharePoint
IT 管理者 or ユーザーオンデマンド
Office 365 Groups(/Teams)
IT 管理者 or ユーザーオンデマンド
階層を決める人
全体
IT 部門主体で各部門に
“階層を分けるポイント” を確認後に決定
各部門
各部門内が主導で確定。
テクニカルな観点のアドバイスは
IT 部門が実施
関係者で確定
テクニカルな観点のアドバイスは IT が実施
関係なし 関係なし
外部共有の設定 IT 部門で設定(通常は設定なし)
SharePoint
IT 管理者が作成する場合は
設定後に担当者に引き渡し
ユーザーセルフで作成する場合は、
IT管理者に依頼
Groups(/Teams)
IT 管理者で一律設定
IT 部門で設定
SharePoint
IT 管理者が作成する場合は
設定後に担当者に引き渡し
ユーザーセルフで作成する場合は、
IT管理者に依頼
Groups(/Teams)
IT 管理者で一律設定
モノによって、運用は変わりますがまずはこんな感じです。
Office 365 Groups
(Teams)
SharePoint
SharePoint の運用管理の世界
既存で Active Directory がない場合は
クラウド上の運用管理になるため、
どのように管理するかはクラウドのみ注目
クラウド上でユーザーの属性情報に
基づいた動的なグループの管理が可能
(下記参考情報を参照)
既存で Active Directory などを
利用している場合は“組織のポータル”と
同じスコープでソフトウェアの世界の管理や
メーリングリストを作っている場合があるため
それらをクラウドの世界でも利用する方が効率が良い
(AD 上では属性情報などで自動的に
グループの更新は可能)
参考情報
https://azure.microsoft.com/ja-jp/pricing/details/active-directory/
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-dynamic-membership
Office 365 Groups の
グループはクラウドのみに存在
Azure Active Directory
SharePoint Online
ファイル
サーバー
の
権限
セキュリティグループ
(配布グループ)
Azure AD connect
(Active Directory の
データをクラウドに
同期するサーバー)
↑クラウドの世界
↓ソフトウェアの世界
…
…
アプリケーショ
ン
サーバーの権限
Active Directory
SharePoint グループとは?
Azure Active
Directory
グループ
Azure Active Directory で作成したグループ
SharePoint で作成したグループ
→ グループにアクセス権限が紐づ
く
SharePoint
グループ
Azure Active
Directory
読み取り権限を持つグループ
編集権限を持つグループ
1
1
2
2
Azure Active Directory から
ユーザーとグループを登録
※セキュリティグループのみ
各サイトで
SharePoint グループ作成
…
…
1
2
…
…
効率的な権限の運用管理を目指して
Azure Active Directory のグループのスコープ
≒ SharePoint グループのスコープにできると便利になる
運用負荷高
運用負荷低
SharePointサイトの運用負荷
1 回の登録作業が必要
回の登録作業が必要
12 回の登録作業が必要
SharePoint グループ
SharePoint
グループActive Directory グループ
Azure Active
Directory
グループ
Azure Active
Directory
7 回の登録作業が必要
効率的な運用を目指して
~メリット・デメリット~
運用負荷低 運用負荷高
運用負荷高 運用負荷低
メリット
人事異動の場合は、AD / AAD 側でユーザーの
グループを変更するだけで、SharePoint サイトの
権限も適切に変更される場合が多い
“大幅な組織の変化” や
“プロジェクト単位で利用する SharePoint サイト” の
権限設定にも柔軟に対応が可能な場合が多い
(一時的機能ポータルはこちら)
デメリット
• 組織が大幅に変更してしまうような場合は、
すべてのグループの設計をやり直す必要がある
• セキュリティグループが多い場合、ユーザーと
セキュリティグループを関連づける作業のミス
が誘発され、SharePoint サイトの不適切な権限
設定により、情報漏えいが起きる可能性がある
• 人事異動の場合は、 “AD 側の設定でユーザーと
セキュティグループの関連付け” および
”SharePoint 側の設定でサイトの権限設定
(ユーザー単位の権限変更の比重が多くなる)” という
二重の権限設定が必要となる
• 一度に大量の組織変更があった場合、
SharePoint サイトの権限設定が手動であることを考えると、
手続き処理の遅延による情報漏洩が起きる可能性がある
(後述する動的にグループを構成する仕組みの利用は可
能)
SharePoint サイトの運用という観点から見た運用負荷
Active Directory(AD) / Azure Active Directory(AAD) の運用という観点から見た運用負荷
(ユーザーとセキュリティグループを関連づける負荷)
サイトを利用する
ユーザーのスコープと
合致したセキュリティ
グループが多い
サイトを利用する
ユーザーのスコープと
合致したセキュリティ
グループが少ない
セキュリティグループ作成の基準
作成したほうが良い場合
• ソフトウェアとクラウドで同じスコープで利用する
部門の範囲など(メールも有効なセキュリティグループだとさらに効率が良い)
• グループの存続期間が長い
全社員、部門や、そのほか特定のテーマなど
• グループ対象者数が多い
グループがない場合、設定負荷が増えるなど
• セキュアに情報を分けたい場合
契約書を見ることができるのは法務関係者のみなど
作成しないほうが良い場合
(こちらの該当するものは Office 365 Groups を推奨)
• グループの存続期間が短い
セキュリティグループの編集・削除などの負荷が増えるなど
• ユーザーの異動が頻繁に行われる場合
ユーザーとセキュリティグループの関連付け作業の増加など
該当項目が多い場合は
セキュリティグループの
作成を推奨
該当項目が多い場合は
セキュリティグループの
作成は非推奨
• 組織ポータル
• 永続機能ポータル
一時的機能ポータル
うまくスコープを設定できると?
A 部門所属社員 B 部門所属社員 C 部門所属社員
Azure Active
Directory
グループ
SharePoint
グループ
図はサブサイトの例ですが
サイトコレクションの時も
同様のイメージです
A 部門向けサイト B 部門向けサイト C 部門向けサイト
全社員向けサイト
Azure Active
Directory
…
…
…
…
…
…
………
用途別のサイト構成例(事例)
部門サイトのほかにお客様の情報を管理するサイトを利用
A 部門 B 部門 C 部門 お客様A お客様B
全社員向けサイト
部門向けサイト お客様情報サイト
セキュリティ面
各部門・各お客様サイトの情報漏洩を
防ぐため、不必要な情報を公開禁止
運用面
情報漏洩を防ぎつつ、サイト管理者の運用負荷を
最大限低下げることができるようにグループを構成。
お客様の関連する情報を部門に表示させるため、
1 つのサイトコレクションを利用
A B A B A B A A A B B B
A A A
B B B
Azure Active
Directory
グループ
SharePoint
グループ Azure Active Directory
A A A
B B B
図はサブサイトの例ですが
サイトコレクションの時も
同様のイメージです
A 担当のお客様
用途別のサイト構成例(事例)
部門サイトのほかにプロジェクトサイトを利用
A 部門 B 部門 C 部門 プロジェクト A プロジェクト B
全社員向けサイト
部門向けサイト プロジェクトサイト(外部含
む)
セキュリティ面
各部門・各お客様サイトの情報漏洩を
防ぐため、不必要な情報を公開禁止
運用面
各プロジェクト用のサイトをホストするサイトコレクションを
用意
プロジェクトと部門の情報は共用しないことと、クォータの設
定を
A B A B A B A A A B B B
Azure Active
Directory
グループ
SharePoint
グループ
Azure Active Directory
A A A
B B B
A 担当のプロジェクト
アクセス権限の委譲による運用
サイト
管理者
部門向けサイト
編集権限読取り権限所有権限
リストや
ライブラリなど
SharePointアプリ
レベルでの権限移譲
地区
販売店 A 販売店 B
・
・
・
・
・
・
・
・
・
全社
法務 人事 営業
こちらはチームで
権限移譲をして利用
サブサイトを利用した
サイトコレクション
例)お知らせを作成投稿 / 正式な文書を作成公開
ユーザーオンデマンド?
機能ポータル
永続 一時的
テーマ 個人 プロジェクト
SharePoint
IT 管理者 or ユーザーオンデマン
ド
Office 365 Groups(/Teams)
IT 管理者 or ユーザーオンデマン
ド
IT 管理者
(自動作成)
SharePoint
IT 管理者 or ユーザーオンデマン
ド
Office 365 Groups(/Teams)
IT 管理者 or ユーザーオンデマン
ドユーザーオンデマンド=ユーザーが自分が必要なタイミングで作成すること
SharePoint および Office 365 Groups(/Teams) それぞれに
ユーザーオンデマンドの機能が用意されています。
ソフトウェアの時代はリソース管理と運用管理の管理から
制御することが多くなりましたが、活動を活発化させるという意味
で
Office 365 Groups
(Teams)
SharePoint
サイトの作成
ユーザーが新しいサイトを作成できるように、SharePointホームページおよび
OneDrive のサイト一覧に[サイトの作成] コマンドを表示します。
最初のオプションを使用すると、ユーザーはOffice365グループに
接続されているチームサイトまたはコミュニケーションサイトを作成できます。
Office365グループを作成するアクセス権がないユーザーでも、
Office365グループなしで新しいチームサイトを作成することが出来ます。
サイトコレクションを自由に作らせる?
外部共有の設定は?
テナントで外部共有の設定を許可していた場合でも、既定は外部共有が Off になっているので、
外部共有の設定については IT 管理者などに依頼をするという運用が必要となります
(SharePoint & Flow & PowerApps などで)。
もう少し細かく言うと、モダンサイトの “チームサイト” のテンプレートの初期設定は外部ユーザーとの
共有が可能という設定になっていますが、もちろんテナントレベルで外部共有を不可にしている場合は問題ありませ
ん。
(←サイトコレクションのこと)
サイトコレクションの作成の制御(以下のメニューがあります)
サイトコレクションの管理
ソフトウェアと違い使われていないサイトコレクションを削除する設定がないというのが
SharePoint Online の難点です。ただ、この頃はオンデマンドで作成するのは
Offic3 365 Groups (/ Teams )が主流です
(←モダンサイトのこと)
〇 [サイトの作成]コマンドを非表示にする
⦿ [サイトの作成]コマンドを表示する
ユーザーが[サイトの作成]コマンドを選択すると、
次のコマンドが作成されます:
⦿ 新しいチームサイトやコミュニケーションサイト
〇 クラシックチームサブ サイト
Office 365 Groups を
自由に作らせる?
運用管理のパターン例
• すべての社員が自由に Office 365 Groups を作成可能
• 役職の範囲で作成権限を委譲:管理職が
Office 365 Groups を作成可能
• 特定の部門で Groups の権限管理を委譲
• IT 部門でガバナンスを利かせた状態での
Office 365 Groups の公開
• (複数の会社が利用している場合)各会社の IT 部門に
対してグループの作成権限を委譲
上記のパターンで一番合っているものを選択事
+
前の設定(クォータ、グループ名など)
IT管理者
営業部門
管理職
企画部門
管理職
IT 管理者が運用ポリシーの遵守を
前提に Office 365 Groups 作成権限を委譲
IT管理者
子会社
IT 部門
グループ会社
IT 管理者
親会社の IT 管理者が運用ポリシーの遵守を
前提に子会社の IT 部門の管理者に
Office 365 Groups 作成権限を委譲
Office 365 Groups の運用管理についての例
1. チームを作成
作成者
2. 必要に応じてメンバーや
設定を管理
チーム メンバー
作成者
3. 必要な資料などの
移動を依頼
チーム メンバー
作成者
4. チームの削除
もしくは一定期間の保存が
必要ならば管理者に連絡
作成者
ユーザーが自由に作成する場合
利
用
前
利
用
中
利
用
後
Office 365 Groups 利用後の状態
IT部門
(所有者)
※ IT 部門の管理者は
Exchange 管理者もしくは
グローバル管理者の役割が必要
チームメンバー
(ゲスト)
Office 365 Groups の状態
申請者
(所有者)
追加の管理者
(所有者)
チームメンバー
(ゲスト)
Office 365 Groups の状態
申請者
(所有者)
追加の管理者
(所有者)
Office 365 Groups の状態
申請者
(所有者)
Office 365 Groups の運用管理についての例
IT 部門で作成および利用後の管理を実施した場合
1. Office 365 Groups の
利用申請
2. Office 365 Groups を作成し、
申請者を保有者に設定し、
必要な初期設定を実施
IT 部門の管理者
IT 部門の管理者
申請者 /
Office 365
Groups 所有者
3. 必要に応じてメンバーや
所有者を追加
IT 部門の管理者
4. 利用完了後は、
IT 管理者だけを残し
運用ルールに則り管理
初期設定の例
• サイトのサイトコレクションの
管理者の変更
• Office 365 Groupsの
外部共有の設定 など
利
用
前
利
用
中
利
用
後
Office 365 Groups 利用後の状態
IT部門
(所有者)
※ IT 部門の管理者は
Exchange 管理者もしくは
グローバル管理者の役割が保有
Office 365 Groups の状態
申請者
(所有者)
チームメンバー
(ゲスト)
Office 365 Groups の状態
申請者
(所有者)
追加の管理者
(所有者)
Office 365 Groups の運用管理についての例
IT 部門で利用前・中・後を管理する場合
1. Office 365 Groups の
利用申請
2. Office 365 Groups を
作成し、申請者を保有者に
設定し、必要な初期設定を
実施した後に申請者に連絡
IT 部門の管理者
IT 部門の管理者
3. 必要に応じてメンバーの
追加や削除などを依頼
IT 部門の管理者
4. 利用完了後は、
IT 管理者だけを残し
運用ルールに則り管理
利
用
前
利
用
中
利
用
後
※ IT 部門の管理者は
Exchange 管理者もしくは
グローバル管理者の役割が必要
IT 部門の管理者
Office 365 Groups 利用後の状態
IT部門
(所有者)
Office 365 Groups の運用時の状態
チームメンバー
(ゲスト)
申請者
(ゲスト)
IT部門
(所有者)
Office 365 Groups の初期設定の状態
申請者
(ゲスト)
IT部門
(所有者)
Microsoft Teams の展開パターン例
Team を
任意のユーザーが
自由に作成
Team を特定のユーザーのみが作成
Team の作成権限を IT 部門で一元的に管理
Team の所有者は管理職 Team の所有者は IT 部門のみ
新しい Team の作成 任意に可能 IT 部門のみ IT 部門のみ
社内ユーザーの追加
パブリック グループ :
Team 内メンバーが追加可能
パブリック グループ :
Team 内メンバーが追加可能
パブリック グループ :
Team 内メンバーが追加可能
プライベート グループ :
Team 内の所有者の承認が必要
プライベート グループ :
Team 内の所有者 (管理職) の承認が必要
プライベート グループ :
Team 内の所有者 (IT 部門) の承認が必要
社内ユーザーの削除 Team 内の所有者 Team 内の所有者 (管理職) IT 部門のみ
Team の削除 Team 内の所有者 Team 内の所有者 (管理職) IT 部門のみ
Team の設定変更 Team 内の所有者 Team 内の所有者 (管理職) IT 部門のみ
Team 内チャネルの追加 Team 内のメンバー全員 Team 内のメンバー全員 Team 内のメンバー全員
Team 作成直後の状態
運用中の例
メンバーの追加:任意
ロールの設定:任意
メンバーの追加:管理職
ロールの設定:管理職が
責任をもって別の所有者を追加
メンバーの追加:IT 部門
ロールの設定:IT 部門によって制御
IT部門
(所有者)
申請者
(所有者)
作成者
(所有者)
運用の仕方は、Office 365 Groups と同じ
( Office 365 Groups を作成し、それをもとに Teams を作成するか、
最初から Teams を作成するかの違いは後述
Office 365 Groups(/Teams)の
オンデマンド作成ユーザーを制限
1. 全社でチーム作成を禁止し、Office 365 管理者のみ PowerShell からチームを作成
Office 365 管理者 管理者以外のユーザー
Office 365 Groups(/Teams)
作成可能
Office 365 Groups(/Teams)
作成不可
2. 特定のユーザーのみ (IT 部門、管理職など) チームの作成権限を付与
参考情報
https://blogs.technet.microsoft.com/exchangeteamjp/2017/10/03/manage-guest-access-to-office365-groups/
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-settings-cmdlets#template-settings
作成許可を制御するセキュリティ グループ
テナントに対して1 つのみ指定可能
Office 365 管理者 ユーザー ユーザー
Office 365 Groups(/Teams)
作成可能
Office 365 Groups(/Teams)
作成可能
特定のユーザーだけ Office 365 Groups(/Teams) を作成可能にするには
以下の 2 つのパターンがあります。
作成が許可されたユーザー
Office 365 Groups(/Teams)の
自動削除を利用した場合
詳細および参考情報
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-lifecycle
https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/groups-settings-cmdlets#template-settings
180 日前 30 日前 15 日前 1 日前
削除
30 日後
完全削除
自動削除 30/15/1 日前に
Office 365 Groups(/Teams) の
所有者全員にメールで通知が届く。
更新処理をした日から
新しい有効期限が 180 後に設定される
更新処理後
更新日から 180 日の期限を再セット
自動削除後30日以内に
Office 365 Groups(/Teams) の
所有者全員にメールが届き
完全削除前であれば復元が可能
(管理者サイトからの復元も可能)
≈
≈
≈
オンデマンド利用時のそのほか事前の設定例
SharePoint Office 365 Groups(/Teams)
外部共有の設定 外部共有の設定
Office 365 Groups で利用するドメイン名
Office 365 グループを作成するときに使うドメインを選ぶ
URL:https://support.office.com/ja-jp/article/7cf5655d-e523-4bc3-a93b-
3ccebf44a01a
クォータの設定
PowerShell で Office 365 グループを管理する
URL:https://support.office.com/ja-jp/article/aeb669aa-1770-4537-9de2-
a82ac11b0540
チーム作成時の名前付けポリシー設定
Azure Active Directory での
Office 365 グループの名前付けポリシーの強制 (プレビュー)
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/groups-
naming-policy
削除した Office 365 Groups(/Teams)の復
元
Office 365 Groups(/Teams)を削除されてから
30 日以内であれば復元することが可能です。
Exchange 管理センターから 実施可能です。
こちらは Teams の場合も同様です。
127
参考情報
https://docs.microsoft.com/ja-jp/office365/admin/create-groups/restore-deleted-group?redirectSourcePath=%252fja-jp%252farticle%252fb7c66b59-657a-4e1a-8aa0-
8163b1f4eb54&view=o365-worldwide
SharePoint の権限の種類について
サイトの所有者の SharePoint グループ
フルコントロール
サイトのメンバーの SharePoint グループ
編集権限
サイトの閲覧者の SharePoint グループ
閲覧権限
既定では、サイト内の権限
は
そのまま、同じ権限が
サブサイト、アプリ、
アプリ内のファイルなどの
アイテムに継承されます
今までの説明で、権限の種類について説明がなかったので、
ここからは、権限の種類を含めた運用管理の話に移りたいと思います。
上位のフルコントロールの権限を保有するユーザーのみが
下位に対してフルコントロールおよび権限の変更ができる
サイトのフルコントロー
ル
SharePoint アプリのフルコントロール
アイテムのフルコントロー
ル
SharePoint では、既定では 4 つの種類の権限と
3 つのSharePoint グループを利用します。
サイトコレクションの管理者(ユーザー単
位)
サイトコレクションレベルのフルコント
ロール
サイトコレクションのフルコントロール
SharePoint と
Office 365 Groups/Teams の権限の関係
“サイト”の所有者
“サイト”のメンバー
Teams 内の役割SharePoint グループOffice 365 Groups の
役割
所有者
メンバー
所有者
メンバー
“サイト”の訪問者
Office 365 Groups / Teams の役割にもとづき、自動的に
既定の SharePoint のグループに振り分けられる
Office 365 Groups / Teams のメンバーに SharePoint の “表示権限” が割り当たることはない
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ
SharePoint で始める情報共有とそのアプローチ

More Related Content

What's hot

SharePoint モダン ポータル 徹底解説 !
SharePoint モダン ポータル 徹底解説 !SharePoint モダン ポータル 徹底解説 !
SharePoint モダン ポータル 徹底解説 !Ai Hirano
 
SharePoint Online へのアクセスを制限しよう
SharePoint Online へのアクセスを制限しようSharePoint Online へのアクセスを制限しよう
SharePoint Online へのアクセスを制限しようHirofumi Ota
 
SharePoint Online モダンサイトの設計 - SharePoint の利用計画 - #‎MSInteract19‬ #PR05
SharePoint Online モダンサイトの設計 - SharePoint の利用計画 - #‎MSInteract19‬ #PR05SharePoint Online モダンサイトの設計 - SharePoint の利用計画 - #‎MSInteract19‬ #PR05
SharePoint Online モダンサイトの設計 - SharePoint の利用計画 - #‎MSInteract19‬ #PR05Hirofumi Ota
 
にぎやか 3 人組が選ぶ Microsoft 365 注目アップデート 7 選
にぎやか 3 人組が選ぶ Microsoft 365 注目アップデート 7 選にぎやか 3 人組が選ぶ Microsoft 365 注目アップデート 7 選
にぎやか 3 人組が選ぶ Microsoft 365 注目アップデート 7 選Hirofumi Ota
 
SharePoint Online 「アクセス権」を理解する
SharePoint Online 「アクセス権」を理解するSharePoint Online 「アクセス権」を理解する
SharePoint Online 「アクセス権」を理解するKazuhiko Nakamura
 
Teams の”チーム”と Office 365 グループを理解して Power Platform を活用せよ
Teams の”チーム”と Office 365 グループを理解して Power Platform を活用せよTeams の”チーム”と Office 365 グループを理解して Power Platform を活用せよ
Teams の”チーム”と Office 365 グループを理解して Power Platform を活用せよYugo Shimizu
 
SharePoint Hub Sites について学ぶ
SharePoint Hub Sites について学ぶ SharePoint Hub Sites について学ぶ
SharePoint Hub Sites について学ぶ Ai Hirano
 
SharePoint Online 外部共有を考える
SharePoint Online 外部共有を考えるSharePoint Online 外部共有を考える
SharePoint Online 外部共有を考えるTeruchika Yamada
 
Azure API Management 俺的マニュアル
Azure API Management 俺的マニュアルAzure API Management 俺的マニュアル
Azure API Management 俺的マニュアル貴志 上坂
 
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)NTT DATA Technology & Innovation
 
Microsoft 365 グループ 生まれた経緯とそのコントロール MICROSOFT 365 VIRTUAL MARATHON 2022
Microsoft 365 グループ 生まれた経緯とそのコントロール MICROSOFT 365 VIRTUAL MARATHON 2022Microsoft 365 グループ 生まれた経緯とそのコントロール MICROSOFT 365 VIRTUAL MARATHON 2022
Microsoft 365 グループ 生まれた経緯とそのコントロール MICROSOFT 365 VIRTUAL MARATHON 2022mokudai masayuki
 
これからはじめる Power Platform
これからはじめる Power Platformこれからはじめる Power Platform
これからはじめる Power PlatformRie Okuda
 
初心者のためのTableau0→1
初心者のためのTableau0→1初心者のためのTableau0→1
初心者のためのTableau0→1OWL.learn
 
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介Junichi Kodama
 
Power Appsのギャラリーを使いこなそう
Power Appsのギャラリーを使いこなそうPower Appsのギャラリーを使いこなそう
Power Appsのギャラリーを使いこなそうkorune ☆
 
実録Blue-Green Deployment導入記
実録Blue-Green Deployment導入記実録Blue-Green Deployment導入記
実録Blue-Green Deployment導入記Hiroyuki Ohnaka
 
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)Trainocate Japan, Ltd.
 
Azure App Service Overview
Azure App Service OverviewAzure App Service Overview
Azure App Service OverviewTakeshi Fukuhara
 
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション 【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション 日本マイクロソフト株式会社
 

What's hot (20)

情報共有ツールの 投資対効果を考える
情報共有ツールの投資対効果を考える情報共有ツールの投資対効果を考える
情報共有ツールの 投資対効果を考える
 
SharePoint モダン ポータル 徹底解説 !
SharePoint モダン ポータル 徹底解説 !SharePoint モダン ポータル 徹底解説 !
SharePoint モダン ポータル 徹底解説 !
 
SharePoint Online へのアクセスを制限しよう
SharePoint Online へのアクセスを制限しようSharePoint Online へのアクセスを制限しよう
SharePoint Online へのアクセスを制限しよう
 
SharePoint Online モダンサイトの設計 - SharePoint の利用計画 - #‎MSInteract19‬ #PR05
SharePoint Online モダンサイトの設計 - SharePoint の利用計画 - #‎MSInteract19‬ #PR05SharePoint Online モダンサイトの設計 - SharePoint の利用計画 - #‎MSInteract19‬ #PR05
SharePoint Online モダンサイトの設計 - SharePoint の利用計画 - #‎MSInteract19‬ #PR05
 
にぎやか 3 人組が選ぶ Microsoft 365 注目アップデート 7 選
にぎやか 3 人組が選ぶ Microsoft 365 注目アップデート 7 選にぎやか 3 人組が選ぶ Microsoft 365 注目アップデート 7 選
にぎやか 3 人組が選ぶ Microsoft 365 注目アップデート 7 選
 
SharePoint Online 「アクセス権」を理解する
SharePoint Online 「アクセス権」を理解するSharePoint Online 「アクセス権」を理解する
SharePoint Online 「アクセス権」を理解する
 
Teams の”チーム”と Office 365 グループを理解して Power Platform を活用せよ
Teams の”チーム”と Office 365 グループを理解して Power Platform を活用せよTeams の”チーム”と Office 365 グループを理解して Power Platform を活用せよ
Teams の”チーム”と Office 365 グループを理解して Power Platform を活用せよ
 
SharePoint Hub Sites について学ぶ
SharePoint Hub Sites について学ぶ SharePoint Hub Sites について学ぶ
SharePoint Hub Sites について学ぶ
 
SharePoint Online 外部共有を考える
SharePoint Online 外部共有を考えるSharePoint Online 外部共有を考える
SharePoint Online 外部共有を考える
 
Azure API Management 俺的マニュアル
Azure API Management 俺的マニュアルAzure API Management 俺的マニュアル
Azure API Management 俺的マニュアル
 
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
AWS Organizations連携サービスの罠(Security JAWS 第26回 発表資料)
 
Microsoft 365 グループ 生まれた経緯とそのコントロール MICROSOFT 365 VIRTUAL MARATHON 2022
Microsoft 365 グループ 生まれた経緯とそのコントロール MICROSOFT 365 VIRTUAL MARATHON 2022Microsoft 365 グループ 生まれた経緯とそのコントロール MICROSOFT 365 VIRTUAL MARATHON 2022
Microsoft 365 グループ 生まれた経緯とそのコントロール MICROSOFT 365 VIRTUAL MARATHON 2022
 
これからはじめる Power Platform
これからはじめる Power Platformこれからはじめる Power Platform
これからはじめる Power Platform
 
初心者のためのTableau0→1
初心者のためのTableau0→1初心者のためのTableau0→1
初心者のためのTableau0→1
 
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
誰もがアプリ開発に携われる時代へ ビジネスを加速させるローコードプラットフォーム Power Platform のご紹介
 
Power Appsのギャラリーを使いこなそう
Power Appsのギャラリーを使いこなそうPower Appsのギャラリーを使いこなそう
Power Appsのギャラリーを使いこなそう
 
実録Blue-Green Deployment導入記
実録Blue-Green Deployment導入記実録Blue-Green Deployment導入記
実録Blue-Green Deployment導入記
 
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
 
Azure App Service Overview
Azure App Service OverviewAzure App Service Overview
Azure App Service Overview
 
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション 【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
【BS15】.NET アップグレード アシスタントで簡単にできます! .NET Framework アプリの .NET 6 へのマイグレーション
 

Similar to SharePoint で始める情報共有とそのアプローチ

SOMALパンフレット.pdf
SOMALパンフレット.pdfSOMALパンフレット.pdf
SOMALパンフレット.pdfMasato Okuwaki
 
DevLOVE関西2012 Drive 講演資料(iBook)
DevLOVE関西2012 Drive 講演資料(iBook)DevLOVE関西2012 Drive 講演資料(iBook)
DevLOVE関西2012 Drive 講演資料(iBook)広告制作会社
 
Tfad AgileDay MS 20100122
Tfad AgileDay MS 20100122Tfad AgileDay MS 20100122
Tfad AgileDay MS 20100122Kazumasa EBATA
 
新チームサイトの「ソーシャル」でできること チームサイトは社内Facebookになれるのか?
新チームサイトの「ソーシャル」でできること チームサイトは社内Facebookになれるのか?新チームサイトの「ソーシャル」でできること チームサイトは社内Facebookになれるのか?
新チームサイトの「ソーシャル」でできること チームサイトは社内Facebookになれるのか?Kazuhiko Nakamura
 
Office365を使った情報共有のご紹介
Office365を使った情報共有のご紹介Office365を使った情報共有のご紹介
Office365を使った情報共有のご紹介mokudai masayuki
 
SharePoint 2013/Office365の「ソーシャル」でできること。SharePointは社内Facebookになれるのか?
SharePoint 2013/Office365の「ソーシャル」でできること。SharePointは社内Facebookになれるのか?SharePoint 2013/Office365の「ソーシャル」でできること。SharePointは社内Facebookになれるのか?
SharePoint 2013/Office365の「ソーシャル」でできること。SharePointは社内Facebookになれるのか?Kazuhiko Nakamura
 
office365にまつわる怖い話し
office365にまつわる怖い話しoffice365にまつわる怖い話し
office365にまつわる怖い話しTeruchika Yamada
 
Agile Evangelist Patterns
Agile Evangelist PatternsAgile Evangelist Patterns
Agile Evangelist PatternsTomonori Fukuta
 
スモールリーダーシップ読書会ワークショップ
スモールリーダーシップ読書会ワークショップスモールリーダーシップ読書会ワークショップ
スモールリーダーシップ読書会ワークショップYukei Wachi
 
いまの Office 365 ってこんな感じ?
いまの Office 365 ってこんな感じ?いまの Office 365 ってこんな感じ?
いまの Office 365 ってこんな感じ?Hirofumi Ota
 
Teamsを真に活用するための秘訣を教えます
Teamsを真に活用するための秘訣を教えますTeamsを真に活用するための秘訣を教えます
Teamsを真に活用するための秘訣を教えますmokudai masayuki
 
今知っておきたい!最新「ビジネス理論」「フレームワーク」トレンド5選 先生:山田 案稜
今知っておきたい!最新「ビジネス理論」「フレームワーク」トレンド5選 先生:山田 案稜今知っておきたい!最新「ビジネス理論」「フレームワーク」トレンド5選 先生:山田 案稜
今知っておきたい!最新「ビジネス理論」「フレームワーク」トレンド5選 先生:山田 案稜schoowebcampus
 
Office365事例を調べてみた(NPO)
Office365事例を調べてみた(NPO)Office365事例を調べてみた(NPO)
Office365事例を調べてみた(NPO)Katsuhito Okada
 
ビジネスサイドが知っておくべきシステムの話
ビジネスサイドが知っておくべきシステムの話ビジネスサイドが知っておくべきシステムの話
ビジネスサイドが知っておくべきシステムの話Koyo 松本
 
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化についてDaisuke Nishino
 
sitTokyo2022_Dev_05_Kawanabe.pptx
sitTokyo2022_Dev_05_Kawanabe.pptxsitTokyo2022_Dev_05_Kawanabe.pptx
sitTokyo2022_Dev_05_Kawanabe.pptxssuser5bff5a
 
Enterprise Socialware faq_201304
Enterprise Socialware faq_201304Enterprise Socialware faq_201304
Enterprise Socialware faq_201304八木橋 パチ
 
テック業界のジェンダーギャップ解消のために、個人開発でどこまでできるか挑戦している話
テック業界のジェンダーギャップ解消のために、個人開発でどこまでできるか挑戦している話テック業界のジェンダーギャップ解消のために、個人開発でどこまでできるか挑戦している話
テック業界のジェンダーギャップ解消のために、個人開発でどこまでできるか挑戦している話DayoungHam
 
Tableau Serverを利用した組織レベルでのデータ分析
Tableau Serverを利用した組織レベルでのデータ分析 Tableau Serverを利用した組織レベルでのデータ分析
Tableau Serverを利用した組織レベルでのデータ分析 Hortonworks Japan
 

Similar to SharePoint で始める情報共有とそのアプローチ (20)

SOMALパンフレット.pdf
SOMALパンフレット.pdfSOMALパンフレット.pdf
SOMALパンフレット.pdf
 
社内ソーシャルFAQ
社内ソーシャルFAQ社内ソーシャルFAQ
社内ソーシャルFAQ
 
DevLOVE関西2012 Drive 講演資料(iBook)
DevLOVE関西2012 Drive 講演資料(iBook)DevLOVE関西2012 Drive 講演資料(iBook)
DevLOVE関西2012 Drive 講演資料(iBook)
 
Tfad AgileDay MS 20100122
Tfad AgileDay MS 20100122Tfad AgileDay MS 20100122
Tfad AgileDay MS 20100122
 
新チームサイトの「ソーシャル」でできること チームサイトは社内Facebookになれるのか?
新チームサイトの「ソーシャル」でできること チームサイトは社内Facebookになれるのか?新チームサイトの「ソーシャル」でできること チームサイトは社内Facebookになれるのか?
新チームサイトの「ソーシャル」でできること チームサイトは社内Facebookになれるのか?
 
Office365を使った情報共有のご紹介
Office365を使った情報共有のご紹介Office365を使った情報共有のご紹介
Office365を使った情報共有のご紹介
 
SharePoint 2013/Office365の「ソーシャル」でできること。SharePointは社内Facebookになれるのか?
SharePoint 2013/Office365の「ソーシャル」でできること。SharePointは社内Facebookになれるのか?SharePoint 2013/Office365の「ソーシャル」でできること。SharePointは社内Facebookになれるのか?
SharePoint 2013/Office365の「ソーシャル」でできること。SharePointは社内Facebookになれるのか?
 
office365にまつわる怖い話し
office365にまつわる怖い話しoffice365にまつわる怖い話し
office365にまつわる怖い話し
 
Agile Evangelist Patterns
Agile Evangelist PatternsAgile Evangelist Patterns
Agile Evangelist Patterns
 
スモールリーダーシップ読書会ワークショップ
スモールリーダーシップ読書会ワークショップスモールリーダーシップ読書会ワークショップ
スモールリーダーシップ読書会ワークショップ
 
いまの Office 365 ってこんな感じ?
いまの Office 365 ってこんな感じ?いまの Office 365 ってこんな感じ?
いまの Office 365 ってこんな感じ?
 
Teamsを真に活用するための秘訣を教えます
Teamsを真に活用するための秘訣を教えますTeamsを真に活用するための秘訣を教えます
Teamsを真に活用するための秘訣を教えます
 
今知っておきたい!最新「ビジネス理論」「フレームワーク」トレンド5選 先生:山田 案稜
今知っておきたい!最新「ビジネス理論」「フレームワーク」トレンド5選 先生:山田 案稜今知っておきたい!最新「ビジネス理論」「フレームワーク」トレンド5選 先生:山田 案稜
今知っておきたい!最新「ビジネス理論」「フレームワーク」トレンド5選 先生:山田 案稜
 
Office365事例を調べてみた(NPO)
Office365事例を調べてみた(NPO)Office365事例を調べてみた(NPO)
Office365事例を調べてみた(NPO)
 
ビジネスサイドが知っておくべきシステムの話
ビジネスサイドが知っておくべきシステムの話ビジネスサイドが知っておくべきシステムの話
ビジネスサイドが知っておくべきシステムの話
 
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
.NET用アプリケーション フレームワーク “Open 棟梁”のオープンソース化について
 
sitTokyo2022_Dev_05_Kawanabe.pptx
sitTokyo2022_Dev_05_Kawanabe.pptxsitTokyo2022_Dev_05_Kawanabe.pptx
sitTokyo2022_Dev_05_Kawanabe.pptx
 
Enterprise Socialware faq_201304
Enterprise Socialware faq_201304Enterprise Socialware faq_201304
Enterprise Socialware faq_201304
 
テック業界のジェンダーギャップ解消のために、個人開発でどこまでできるか挑戦している話
テック業界のジェンダーギャップ解消のために、個人開発でどこまでできるか挑戦している話テック業界のジェンダーギャップ解消のために、個人開発でどこまでできるか挑戦している話
テック業界のジェンダーギャップ解消のために、個人開発でどこまでできるか挑戦している話
 
Tableau Serverを利用した組織レベルでのデータ分析
Tableau Serverを利用した組織レベルでのデータ分析 Tableau Serverを利用した組織レベルでのデータ分析
Tableau Serverを利用した組織レベルでのデータ分析
 

More from 日本マイクロソフト株式会社

【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ 【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ 日本マイクロソフト株式会社
 
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発日本マイクロソフト株式会社
 
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!日本マイクロソフト株式会社
 
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101 【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101 日本マイクロソフト株式会社
 
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介 【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介 日本マイクロソフト株式会社
 
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること 【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること 日本マイクロソフト株式会社
 
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]日本マイクロソフト株式会社
 
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...日本マイクロソフト株式会社
 
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...日本マイクロソフト株式会社
 
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]日本マイクロソフト株式会社
 
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...日本マイクロソフト株式会社
 
S12_Azure AD 活用術!アプリケーション認証を ADFS から移行しましょう。 [Microsoft Japan Digital Days]
S12_Azure AD 活用術!アプリケーション認証を ADFS から移行しましょう。 [Microsoft Japan Digital Days]S12_Azure AD 活用術!アプリケーション認証を ADFS から移行しましょう。 [Microsoft Japan Digital Days]
S12_Azure AD 活用術!アプリケーション認証を ADFS から移行しましょう。 [Microsoft Japan Digital Days]日本マイクロソフト株式会社
 
S10_Microsoft 365 E5 Compliance で実現する機密情報の検出・分類・保護 - Microsoft Information P...
S10_Microsoft 365 E5 Compliance で実現する機密情報の検出・分類・保護  - Microsoft Information P...S10_Microsoft 365 E5 Compliance で実現する機密情報の検出・分類・保護  - Microsoft Information P...
S10_Microsoft 365 E5 Compliance で実現する機密情報の検出・分類・保護 - Microsoft Information P...日本マイクロソフト株式会社
 

More from 日本マイクロソフト株式会社 (20)

【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ 【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
【BS14】Blazor WebAssemblyとJavaScriptのインターオペラビリティ
 
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
【BS13】チーム開発がこんなにも快適に!コーディングもデバッグも GitHub 上で。 GitHub Codespaces で叶えられるシームレスな開発
 
【BS12】Visual Studio 2022 40分一本勝負!
【BS12】Visual Studio 2022 40分一本勝負!【BS12】Visual Studio 2022 40分一本勝負!
【BS12】Visual Studio 2022 40分一本勝負!
 
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
【BS10】Microsoft と GitHub の開発エコシステムで、開発にドライブをかけよう!
 
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101 【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
【BS9】モダン & クラウドネイティブなソフトウエア開発はじめよう ~ Azure DevOps & GitHub を使ったアプリ開発 DevOps 101
 
【BS7】GitHubをフル活用した開発
【BS7】GitHubをフル活用した開発【BS7】GitHubをフル活用した開発
【BS7】GitHubをフル活用した開発
 
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。 【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
 
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介 【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
【BS3】Visual Studio 2022 と .NET 6 での Windows アプリ開発技術の紹介
 
【BS2】.NET 6 最新アップデート
【BS2】.NET 6 最新アップデート【BS2】.NET 6 最新アップデート
【BS2】.NET 6 最新アップデート
 
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること 【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
【BS11】毎年訪れる .NET のメジャーバージョンアップに備えるために取り組めること
 
【BS6】 マイクロソフトの GitHub との取り組み
【BS6】 マイクロソフトの GitHub との取り組み 【BS6】 マイクロソフトの GitHub との取り組み
【BS6】 マイクロソフトの GitHub との取り組み
 
【BS1】What’s new in visual studio 2022 and c# 10
【BS1】What’s new in visual studio 2022 and c# 10【BS1】What’s new in visual studio 2022 and c# 10
【BS1】What’s new in visual studio 2022 and c# 10
 
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
N08_次世代通信キャリアの "Resilience" を支援する Microsoft Cloud [Microsoft Japan Digital Days]
 
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
S09_プライバシー規約準拠の基本! Amazon S3 やオンプレ SQL もサポートする Azure Purview による情報分類と管理 [Micr...
 
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
S18_ゼロトラストを目指し、Windows 10 & M365E5 を徹底活用した弊社 (三井情報) 事例のご紹介 [Microsoft Japan D...
 
S17_25 分でわかる!Windows 365 [Microsoft Japan Digital Days]
S17_25 分でわかる!Windows 365 [Microsoft Japan Digital Days]S17_25 分でわかる!Windows 365 [Microsoft Japan Digital Days]
S17_25 分でわかる!Windows 365 [Microsoft Japan Digital Days]
 
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
S15_標準 PC にさようなら!ニューノーマルの働き方に合わせたデバイスの選択 [Microsoft Japan Digital Days]
 
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
S13_レガシー ID 管理者でも分かる Verifiable Credentials のセッション [Microsoft Japan Digital D...
 
S12_Azure AD 活用術!アプリケーション認証を ADFS から移行しましょう。 [Microsoft Japan Digital Days]
S12_Azure AD 活用術!アプリケーション認証を ADFS から移行しましょう。 [Microsoft Japan Digital Days]S12_Azure AD 活用術!アプリケーション認証を ADFS から移行しましょう。 [Microsoft Japan Digital Days]
S12_Azure AD 活用術!アプリケーション認証を ADFS から移行しましょう。 [Microsoft Japan Digital Days]
 
S10_Microsoft 365 E5 Compliance で実現する機密情報の検出・分類・保護 - Microsoft Information P...
S10_Microsoft 365 E5 Compliance で実現する機密情報の検出・分類・保護  - Microsoft Information P...S10_Microsoft 365 E5 Compliance で実現する機密情報の検出・分類・保護  - Microsoft Information P...
S10_Microsoft 365 E5 Compliance で実現する機密情報の検出・分類・保護 - Microsoft Information P...
 

SharePoint で始める情報共有とそのアプローチ