SharePoint を理解する為の7つのポイント

ネタは沢山あるのになかなか更新がおっつかずにもどかしい SharepointManiacs です。いや、ウチの会社、ようやくノーツから SharePoint の移行が本格化しましてね。それはそれで良いことなのですが、も~やること多くて目が白黒気味^^;

2013/4/25
この情報は SharePoint 2007 の頃のものですので、最新情報を踏まえてアップデートしました。
初心者向け SharePoint を理解するための 10 のポイント 1/2
初心者向け SharePoint を理解するための 10 のポイント 2/2
----------

さて、それはさておき。

今日は、やや今更感もありますが、山崎愛さんによる「SharePoint Server 2007 活用/導入の考え方と、その落とし穴 (後編) 」をご紹介します。

前回の続きで、SharePoint を理解する上で必要不可欠な要素、

・サイトの階層構造
・アクセス権の継承
・リスト
・ライブラリ

をぎゅ!っと濃縮して説明されています。
前回比、三倍のページ数です。

しかし、流石の愛さんも、SharePoint をこのページ数で語りきることは出来なかったか…というのが正直な感想かな?

間違った内容は一切ありませんし、MOSS を理解する上で重要なポイントが網羅されています。しかし、SharePoint 検討中のユーザさんにはどうなんですかね。きっと、半分も理解できないんじゃないかな…。

これは、愛さんがどうの、と言うよりも、やっぱり SharePoint 自体が判りにくいんですね。その判りにくさから逃げずに、正面から解説してるので、やっぱり判りにくい。そうだ、製品が悪いんだ(笑)

もっとも、人様が書いた文書にミソをつけるだけ、というのは私の流儀ではありませんので、記事を補足する形で、私なりの「理解する為のポイント」をまとめてみたいと思います。

↓ここから↓

【SharePoint を理解する為の7つのポイント By SahrePoint Maniacs】

SharePoint を理解する上で、まず押えるべき要素は次の7点だと思います

1.「サイトコレクション」
2.「サイト(サブサイト)」
3.「ライブラリ」
4.「リスト」
5.「フォームライブラリ(Infopath)」
6.「Webパーツ」
7.「アクセス権の継承」

この要素は、数字の順序で覚えていくのが、一番判りやすいです。
順番にご説明していきます。

1.サイトコレクション

SharePoint は大雑把に言えば「Web系なコンテンツの器」です。
その全体をまとめて「サイトコレクション」と呼びます。
WWW で言うと、ドメインに相当します。

例えば、マイクロソフト は、複数のコンテンツを含んだ、ひとつの「サイトコレクション」です。
なお、この「サイトコレクション」については、Microsoft社内でも用語の統一が十分に出来ていないようで、テキストによっては「サイト」と誤表記されていることがあり、余計に解りにくくなっています。

2.サイト/サブサイト

「サイトコレクション」内に存在する、各コンテンツの器を「サイト」と呼びます。

「サイトコレクション」には、必ず起点となるはじめの「サイト」が存在し、その配下に複数の「サイト」をつくることができます。この最初のサイトは、特別に「ルートサイト」「トップ」などと呼ばれ、WWW における「ホームページ」に相当します。

例えば、http://www.microsoft.com/ は、このサイトコレクションにおけるルートサイトです。
そして、http://www.microsoft.com/downloads/ は、その配下の「サイト」です。
※実際には、多言語対応のため、複数のトップが存在しているのですが、ここでは割愛。

「サイト」は階層構造で管理され、ひとつの「サイト」配下には複数の「サイト」を作成することが出来ます。
このことから、サイト間には上下の階層関係が存在し、下位のサイトを、上位サイトに対する「サブサイト」と呼びます。

例えば、次のような場合

【サイトコレクション】
 SiteA(ルート)
  └SiteB
  └SiteC
     └SiteF
     └SiteG
 └SiteD
 └SiteE

SiteB は SiteA に対して「サブサイト」であり、SiteF は SiteC の「サブサイト」です。
「サブサイト」はサイト間の関係性を表す用語なので、「サイト」も「サブサイト」も実質は同じ「サイト」です。
※なお、この「サイト」も、Microsoft は時々「WEB」と表記します。統一してくれ…。

3.ライブラリ

ひとつの「サイト」内には、多数のコンテンツを持つことができます。
コンテンツには三つの形式があり、それが「ライブラリ」と「リスト」そして「フォームライブラリ」です。
まず、理解しやすい「ライブラリ」についてご説明します。

「ライブラリ」はいわゆる(仮想)ドライブを SharePoint サイト内に作成するものです。
基本的な動作は、インターネット上に数多く存在するファイルアップローダと同じで、フォルダを作成し、その中に各種ファイルをアップロードして保管することが出来ます。

U/I が Webベースなので、実ドライブに比べるとやや使いづらい面もありますが、[WindowsExplolerで開く] か、「ネットワークドライブの割当」を行うことで、通常の(ネットワーク)ドライブと同じ操作感で利用することが可能です。
デスクトップからのドラッグ&ドロップも可能。

更に、SharePoint 独自の利点として、次のような機能があります。

1.バージョン管理
2.ユーザによるフォルダ・ファイル単位でのアクセス権メンテナンス
3.・チェックイン/チェックアウト
4.フォルダを無視してファイルを一覧表示
5.ファイルに独自プロパティ項目を用意し、それに応じて分類・グルーピング
6.メール経由でのファイル登録
7.Outlook によるレプリケーション(Outlook2007のみ)
8.一定期間更新の無いファイルを自動削除(情報管理ポリシー)

一方、SahrePoint の欠点は、次のような点です。

1.ライブラリの総容量が判らない
2.ライブラリの上限容量(クォータ)を指定できない
3.登録時にアクセス権を指定できない
4.ファイル名自動生成機能がない

(1) は、通常のドライブなら[右クリック→プロパティ] 判る情報です。
SharePoint にも調べる方法はあるのですが、エンドユーザが簡単できる方法がありません。
(2) SharePoint は、サイトコレクション全体に対してしか、クォータの設定が出来ません。
管理者はこの点について留意が必要です。
(3) ファイルは登録された時点では、その箱(ライブラリ)と同じアクセス制限が付与されます。
つまり、あるライブラリで「このファイルだけは厳しくアクセスを制限したい」と思ったとしても、登録してからアクセス権を変更するまでの間、セキュリティ的にはザル状態なのです。
ノーツでは普通に出来る機能ですので、特にノーツからの移行を考えている方は要注意点。
(4) ローカルドライブを個人で利用する限り大きな問題ではないのですが、大人数で共有する SharePoint のライブラリ場合、この機能が無いのが地味に不便です。
同じファイル名で登録すると、当然ながら上書きされます。
せめて上書きを回避する設定が欲しかったところです。

4.リスト

SharePont にファイルをアプロードして格納する「ライブラリ」に対し、SharePoint に直接情報を「書き込む」のがリストです。

管理者が定義した「列(フィールド)」をユーザが入力し、[保存]すると、その情報は「アイテム」という単位で、SharePoint の「リスト」内に格納されます。
ネットにおける、CGI や PHP で作成された掲示板や、各種入力フォームに相当します。
簡易データベース機能、と言ってもいいかもしれません。

「リスト」の利点は、完全にブラウザベースで、クライアントを必要としないため、動作が速いことです。
また、様々な入力項目(列)を管理者が自由に設定し、それを元に情報のフィルタ、ソート、グループ化が出来ます。
入力項目(列)には、リッチテキスト、日付、ユーザ名、ドロップダウン選択、計算式など様々な書式を指定できます。
添付ファイルも可能です。

一方、「リスト」の欠点は、次のような点です。

1.複雑な入力フォームは作成できず、印刷に適さない
2.分類項目のカスケードができない
3.権限やロールによる項目(列)の表示/非表示ができない

(1) SharePont が自動生成するのは、あくまで「簡易フォーム」で、全ての入力項目は縦にフラットに表示されます。いわゆる「○×申請書」のような、凝った帳票レイアウトは作成できません。
印刷も、ブラウザ標準の印刷機能ですので、お世辞にも綺麗とは言えません。
いわゆる印刷専用レイアウト機能はありません。
(2) 分類を定義する際、大分類→中分類→小分類 のように、階層化(カスケード)させたくなりますが(例えば国→地方→都市)、SharePoint にはその機能がありません。
分類そのものは幾つでも定義できますが、すべて独立したフラットな分類になります。
(3) これもノーツが得意な機能ですが、そもそもリストには「ロール」という概念がありません。
フォームをユーザの権限や、選択された値に基づいて動的に変化させることはできません。

5.フォームライブラリ(Infopath)

「フォームライブラリ」は、名前の通りライブラリの亜種で、Microsoft Office の Professional にのみ付属するクライアントアプリケーション「Infopath(インフォパス)」に特化しています。

Infopath で何が出来るのかと言うと「ライブラリ」や「リスト」が苦手とする「帳票」です。
リストのようにフィールドを定義し、それを自由に配置して帳票を作成し、Word や Excel のようにファイルとして保存し、リストのように入力項目を自由にビューに表示、分類できます。

ロール制御、動的にフォームの内容を変化させることも可能。
Jscript、VBscript、VB、C# によるコーディングにも対応しおり、ノーツライクな活用が出来ます。

SQLサーバや、ACCESSなどのデータベース、それに SharePoint のリストやライブラリ、更には Webサービスに接続して、必要な情報を取得させることが可能です。
例えば簡単な例ですが「フォームを開いたら、自動的に名前と所属が入力されている」等、リストやライブラリでは実現が難しい機能を比較的簡単に実装できます。

また、Enterprize CAL を契約すれば、Infopath で開発したフォームを ASP.net のWEBアプリケーションに変換し、ユーザのPCにクライアントがインストールされていなくても利用することが可能です(Infopath Form Service)

総合すると、ノーツからの移行を考える方には、必須の機能と言えるでしょう。

一方、Infopath の弱点は。

1.U/Iが洗練されていない
2.大人数での共有には向かない
3.ちょい重い
4.重要な情報がことごとく英語
5.Webベースでの機能制限

(1) まだ登場してまもない(OFFICE2003で初出)アプリケーションですので。
癖が強く、正直 U/I 周りがイマイチです(管理者・開発者にとって)
なんというか、開発していて、もどかしいシーンが沢山あります。

一例をあげると、Infopath2003では、一度登録したロールは判定順序を変更できません。
登録した順に判定されるので、後から変更したいと思ったら、最初から作り直しです…(涙)
※Infopath2007 にはロール判定の順序を変更する機能が実装されました。

(2) Office 製品ですので、Word や Excel 同様、ネットワーク上では排他制御がかかります。
つまり誰かが開いている場合、後から開いたユーザは「読み取り専用」になる訳です。
従って、大人数が参照するようなデータには向きません。

(3)クライアント版は、フォームのレンダリングにそこそ CPU 性能が要求されます。
低スペック PC では、フォームが開くまで数十秒かかることも。
もっとも、最近の PC ならあまり心配ないかもしれませんが。

(4)まだ国内での普及率・認知度が高くないので、日本語の情報が殆どありません。
Infopath の存在すら知らない SE さんが居るくらいです。
メインのソースは全て英語。
ある程度の英語力がないと、開発や障害対応は辛いかもしれません。
まあ、そこは割り切って、 Microsoft と MCS 契約を結んでサポートを求める、というテはあります。

(5) Infopath を Web ベースで利用する場合、機能制限があります。
例えばロールは利用できません。
一部のコンとローリも利用不可。スクリプトも一部の例外を除いて駄目。
クライアント側に Infopath がインストールされていなくても帳票を利用できるのは魅力ですが、あくまで入力支援ツール。「あまり凝ったことは出来ない」と
」と考えた方が良いと思います。

※個人的な意見ですが、Enterprize CAL は高額なので、この機能(Infopath Form Service)だけを目的に購入されることはお薦めできません。

6.Webパーツ

簡単そうで、意外に理解しにくいのがこの「Webパーツ」。
端的に言うと、Google における「ガジェット」
サイトの表面に配置する、デザイン用パーツ類です。

このパーツには2種類あり、
1.それ自体が何かの機能を持っている(ガジェットタイブ)←注:私命名
2.前述のコンテンツへの入口(Windowタイプ)←注:私命名
この混在が「Webパーツ」を判りにくくしています。

(1) は簡単で、RSS表示機能だったり、リンク集作成だったり、画像を貼り付けたりと、サイトの外観(機能)をデザインする為に用いられます。

逆に、(2)は少しややこしい。
サイトにどのようなコンテンツ(ライブラリ、リスト、フォームライブラリ)を作成した場合でも、その時点では、コンテンツはただ「サイト内に存在する」というだけで、一般のユーザの目に触れることはありません(検索にはかかりますけど)

そこで、ユーザの動線として、コンテンツに繋がる「入口」をサイトに配置するのです。

それが「(Windowタイプ)Webパーツ」の役割。
「(Windowタイプ)Webパーツ」は、入口であると同時に、それ自体がビューの役割を果たすので、管理者が自由に表示項目を設定することが可能です。
例えば、新着5件だけを表示させる、更新順で10件を表示させる、特定の分類のみ表示、等。

また、この「(Windowタイプ)Webパーツ」とコンテンツは、必ずしも1対1である必要もありません。
ひとつのリストに対し、複数の Webパーツ を配置して、表示形式を分ける(例えば WebパーツA はステータスが「申請中」のアイテム、WebパーツB は承認済みのアイテムを表示する等)ことも可能です。

7.アクセス権の継承

SharePoint では、下位要素は、上位要素のアクセス権限設定をそのまま引継ぎます。
これが「アクセス権の継承」です。

例えば、

【サイトコレクション】
 SiteA(ルート)
  └SiteB
  └SiteC
     └SiteF
     └SiteG
 └SiteD
 └SiteE

この場合、SiteA に管理権限を持つユーザは、下位サイト全て(BからG)に同様の権限を持ちます。
また、サイト内のコンテンツに関しても同様で、SiteC のリストやライブラリは、SiteC に設定された権限をそのまま引き継ぎます。
同様に、リスト内のアイテムはリスト本体の、ライブラリ内のフォルダはライブラリ本体の、フォルダ内のファイルはフォルダの、アクセス権限を継承します。

この「アクセス権の継承」ルールを変更するのが [アクセス権の編集] です。
親要素からの継承を無視し、独自のアクセス権限を設定することが可能で、この場合、親のアクセス権限に変更があっても、継承を切っているコンテンツは影響を受けません(これは良し悪しですが)
なお、一度、継承を切ったコンテンツも、再び [アクセス権の継承] を実施すれば元に戻ります。

注意点としては、愛さんも言及されていますが、「このグループ・組織からこのユーザだけアクセス不許可」という排他的アクセス権限はできないことです。
あくまで「アクセス権限を持つユーザ・グループ」を指定することになります。

SharePoint ではアクセス権限を付与する単位として、ユーザ個人のほか、AD のセキュリティグループ、そして、SharePoint 内で独自に定義する「SharePointGroup」を利用することが出来ます。。
特に「SharePoint Group」はメンテナンスが容易で、非常に便利です。

しかし、この SharePintGrpup にも欠点があります。
それは「グループにグループを含む(入子)は出来ない」という点です。
ノーツだと普通に出来るんですけど…残念。

あと、SharePointGroup 管理画面の出来があまりよろしくありません。
一覧表示は100件までで変更不可。検索機能なし。
正直、結構使い辛いです(苦笑)

─短く纏めるつもりが、思うままに書き連ねたらえらい長文になってしまいました(汗)
ここまで読んでくださった方に、感謝いたします。
少しでも皆様のお役に立てれば幸いです。

なお、内容の訂正、ツッコミ、追加情報、いずれも大歓迎です。
ぜひコメント欄にお寄せ下さい。


これまでのコメント

  1. 山崎愛 より:

    AGENT: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; GTB6; SLCC1; .NET CLR 2.0.50727; InfoPath.2; MS-RTC LM 8; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
    お疲れ様です。いつもコメントをありがとうございます! さすが、鋭いですね(^^ゞはい、ご指摘のように、実は思ったほどうまくはまとめられませんでした。。。で、あの長さになりまして。。。もう少し、練りたかったのですが時間的な制約もありまして。

    ただ、TechNetサイトなどとはまた違う視点で、どこかのタイミングで技術的にきちんと(Deep)にSharePointの根幹的な部分を説明したいと思っていたので、その思いは遂げられました。ただ結果的に後から読み返すと、内容がマニアックすぎちゃったとは思います(文書が下手なのがもちろんいけないのですが)。。。コラムなので前編のように、もう少しライトタッチにした方がよいかなあと色々迷ったのですが、まずは書いてみて反応を見るのもいいかなと思ってチャレンジしました。

    的確なフィードバックをいただけて助かりました。今後、参考にさせていただきます。

    また、別の視点で補足していただけて、そういう点も確かに不便だなと私も参考になりました。

  2. saruhiko より:

    AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)
    山崎様、コメントありがとうございます!
    またまた生意気書いてすいません(滝汗)

    実際書いてみて思いましたが、やはり、SharePoint を説明するのは難しいですね。

    さらに Microsoft 自信が
    、「何でも出来るWEBツール」的な宣伝をしているので余計わかりにくく…(苦笑)

    >SharePoint を導入すればすぐに何にで
    >も使えるという、都合のよい「魔法の箱」
    >ではありません。

    まさにこれが全て、という気がします。
    でもオフィシャルな文書でこれを言い切ってしまったのは、(少なくとも日本語のドキュメントでは)山崎さんが初めてじゃないですかね?(笑)

  3. じいさん より:

    シェアポイント使ってますが・・・使えば使うほど情報をシェアしたくなくなるのは私だけでしょうか。いやいや、多くの人がそう思っています。
    ほんとにマイクロソフトのシェアポイントは使いにくい。遅い。こんなひどいSaasをよく使っている人が、会社がいると呆れてしまいます。

    一例に過ぎませんが・・・ファイルのURLを他の人に送るのに、複数のファイルのURLを一回の操作で取得できない。しかもいちいち「リンクを電子メールで送信」 とやってOUTLOOKなどの電子メールクライアントが起動した後でないとURLを取れない。なんでこんな面倒なオペレーションしなきゃいけないんでしょうか???
    複数ファイルをチェックして、リンクをコピー、てやればコピーバッファにでも入ってくれればそれで済むんです。自分がすでに作成中のメールにコピペできればいいのですから。

    リボンメニューが使いにくいのは定評がありますね。それは、適切な操作をしないと関連メニューが表示されないからです(Word2010で罫線を引くことを選択しないと、既存の罫線を削除できない、というバカげた操作と同じです)。ファイル、アップロードしようとしても、フォルダを作成しようとしても、デフォルトのリボンメニューには表示されないので、よく知らない人には非常にわかりにくい。そのため「ドキュメントの追加」というリンクが表示されるようになっている(リボンメニューが表示されないもので、逆にこの「ドキュメントの追加」を消せないでいるのです。なんという矛盾でしょうか?)

  4. じいさん より:

    シェアポイントは、すでにシェアポイントの使いにくさをよく知っている人、かつ、他にいくらでも使いやすい情報共有のSaasがあることを知っている人だけが、うまく使える情報共有ツールですよね。
    よく知らない人、ITの一般ユーザは、なんだか使いにくいなあ、遅いなあ、と考えながら、毎日使うことになる、という呆れたツールです。
    正直言って、もう時代遅れの、無くなってもいい、ツールだと私は思っていますし、私の周りの人も日々、あきれながら使っています。

  5. 中村 和彦 より:

    じいさん、率直なご意見ありがとうございます。
    個々の具体的な不具合、使い難さについては、まったくご指摘の通りですね。私自身、いちユーザーとして(どうすんだこれ…)と暗暗たる気持ちに成ったことは一度や二度ではありません。

    しかし、そんなツールが何故、これだけ利用されているのか?むしろ利用が拡大しているのか?…その辺りも、ぜひお考え頂けると良いのかな、と思います。使い難いだけの製品が、マーケティングのみでこれ程伸び続けはしません。なにせ、SharePoint は企業製品。ビジネスはまさに結果がすべての戦場なのですから。

    SharePoint の何が良いのか?これはセミナー等でもたびたび話させて頂くテーマですが、このコメント欄はお話しするにはちょっと手狭ですので、ここでは上記に留めさせてください。

login

Author

中村 和彦(シンプレッソ・コンサルティング株式会社 代表)が「ユーザ視点の SharePoint 情報」を発信します。元大手製造業 SharePoint 運用担当。現SharePoint コンサルタント。お仕事のお問い合わせはこちらまでお願いします。当ブログにおける発信内容は個人に帰属し所属組織の公式発信/見解ではありません。
FB : 中村 和彦
blog: Be・Better!
MS MVP SharePoint 2009/10-2011/9
MS MVP Office 365 2012/10-2014/9