初心者向け SharePoint を理解するための 10 のポイント 2/2
前回からの続きです。SharePoint がどうも良くわからない!という方を想定して、私の経験から最重要と思われるキーワードを、できるだけ簡単にご説明します。なお「ざっくり」説明のため厳密にはちょっと違う、という内容もあります。この内容を把握した後は、ぜひより専門的な書籍をあたってください。
それでは、後半です。
2013/5/7 追記:エンタープライズサーチナウさんが、このエントリを受けてその「次」を書いてくださいました。こちらも是非。→チーム サイト 3 分クッキング
5.リスト
「リスト」はアプリの一種です。「ライブラリ」が SharePont にファイルをアップロードして格納するのに対し、「リスト」は SharePoint に直接情報を書き込む掲示板タイプです。
管理者は、まず入力項目であるフィールド(列)を定義します。閲覧/入力フォームは自動生成です。ユーザーがこのフォーム入力して保存すると、情報は「アイテム」という単位で SharePoint に格納されます。この情報は、やはり管理者が定義した一覧画面(ビュー)に表示されます。
リストは概ね、インターネットにおける、CGI や PHP で作成された掲示板、各種入力フォームに相当します。見方を変えれば、簡易データベース機能と言えるかもしれません。
タイトル列だけがあらかじめ用意された「カスタムリスト」が最も基本的なリストです。その他、お知らせ掲示板、ディスカッション、アンケート、予定表、タスク、連絡先など、利用目的に応じた特殊機能が組み込まれたリストが用意されています。
リストの利点は、完全にブラウザベースだということです。クライアントが不要のため、動作が速く、PCの環境に依存しません。また、管理者が入力項目(列)を自由に設定し、そこから情報のフィルタ、ソート、グループ化での表示など、情報の「取り回し」が容易です。
入力項目(列)には、リッチテキスト、日付、ユーザ名、ドロップダウン選択、計算式など様々な書式を指定できます。他リスト情報の参照や、添付ファイルも可能です。
一方、リストのデメリットは次のような点です。
1.複雑な入力フォームが作成できず、印刷に適さない
2.分類項目のカスケードができない
3.権限やロールによる項目(列)の表示/非表示ができない
(1)SharePont が自動生成するのはあくまで「簡易フォーム」です。全ての入力項目が縦にフラット表示され、並び順以外の変更はできません。いわゆる「○×申請書」のような帳票レイアウトが苦手です。カスタマイズ手段は用意されていますが、エンドユーザー向けとは言えません。また、印刷もブラウザ標準機能になるため、お世辞にも綺麗とは言えません(印刷専用レイアウト機能はありません)。
(2)いわゆる大分類→中分類→小分類の連携構造がつくれません。分類そのものは幾つでも定義できるのですが、すべて個別の値という扱いにになります。一応「管理されたメタデータ」という特殊機能で対応できるのですが、この機能もあまり使い易くありません。企業内設置(オンプレミス)であればアドオン製品で対応することはできるのですが、クラウドの Office365 ですと厳しいです。
(3)これもノーツが得意な機能ですが、そもそも SharePointには「ロール」という概念がありません。フォームを条件に応じて動的に変化させる機能は在りません。こちらも企業内設置(オンプレミス)であればアドオン製品で対応することはできます。
6.組み込みアプリ
組み込みアプリは、ライブラリでもリストでもないアプリすべてです。大抵は上記の枠に治まらない特殊機能を提供します。例えば、サイトにメールボックスを作成してメールを受信/蓄積できるようにする「サイトメールボックス」アプリ等です。
その他に、前述の SharePoint App Store で組み込みアプリを追加購入したり、独自開発した組み込みアプリをインストールすることも可能です。SharePoint の業務システムとしての可能性をより高めもの、と言えるでしょう。
7.フォームライブラリ(Infopath)
「フォームライブラリ」は、名前の通りライブラリの亜種です。Microsoft Office の Professional 版にのみ付属するアプリケーション「Infopath(インフォパス)」に特化しています。
Infopath は Office アプリケーションとしては知名度が低く、「何が出来るの?」と言う質問をしばしば頂きます。この製品は本来的には「 GUI ベースの XML エディタ」なのですが、SharePoint 視点では、ライブラリやリストが苦手とする「帳票」機能です。
Infopath はリストのようにフィールド(列)を定義し、それを自由に配置して帳票を作成し、Word や Excel のようにファイルとして保存します。フォームライブラリはその Infopath によるデータ管理に特化しており、リスト同様に入力項目をビューに表示、分類できます。ロール制御、動的にフォームの内容を変化させることも可能。
SQLサーバや、ACCESSなどのデータベース、それに SharePoint のリストやライブラリ、更には Webサービスに接続して、必要な情報を取得させることが可能で、かつ VB、C# によるコーディングにも対応しています。
つまり、実にノーツライクな活用が出来る訳です。簡単な例ですが「フォームを開いたら、自動的に名前と所属が入力されている」等、リストやライブラリでは実現が難しい機能を比較的簡単に実装できます。
また、Enterprize ライセンス契約があれば Infopath で開発したフォームを ASP.net のWEBアプリケーションに変換し、Webベースで利用することが可能です(Infopath Form Service)。総合すると、ノーツからの移行を考える方には、必須の機能と言えます。
一方、Infopath の弱点は:
1.大人数での共有には向かない
2.すこし重め
3.重要な情報がことごとく英語
4.やりすぎに注意
(1)Office 製品のため、Word や Excel 同様、ネットワーク上では排他制御されます。つまり誰かが開いている場合、後から開いたユーザは「読み取り専用」になります。必然的に、大人数が参照するようなデータには不向きです。
(2)クライアント版については、Word や Excel と同じように、立ち上がる迄にすこし時間がかかります。また製品の役割上、どうしても設計的に込み入った構造や、重いデータになりがちです。すると非力なパソコンではフォームが開くまで数十秒、なんてことも…。
(3)欧米では非常に知られた製品ですが、日本国内での認知度は低く、そのため日本語の情報が殆どありません。Infopath の存在すら知らない SE さんも少なくありません。ある程度の英語力がないと、開発や障害対応は辛いかも。
(4)これは長所でもありますが、GUIベースでいろいろできるために、ノーツと同じ弱点を抱えています。つまり複雑な設計を作り込みすぎ、フォームの動作が不安定になったり、作成者本人以外にはだれもメンテナンスできなくなってしまったり。
8.Webパーツ/アプリパーツ
意外に理解しにくいのがこの「Webパーツ」。簡単に言うと、Webページにおける「ガジェット」または「ウィジェット」です。サイトの画面に配置するデザインパーツ類にあたります。
Webパーツには2種類あり、この混在がややこしい原因です。なお、SharePoint 2013 からは(2)を「アプリパーツ」と呼ぶようになりました。アプリパーツもWebパーツの一種なので[Webパーツ ⊇ アプリパーツ]という関係に成ります。
1.それ自体が何かの機能を持つ(Webパーツ)
2.リスト/ライブラリへの入口(Webパーツ/アプリパーツ)
(1)はシンプルです。RSS機能、リンク集、画像表示、など、サイトの外観(機能)をデザインする為に用いられます。
(2)はちょっとだけややこしい。サイトにアプリ(リスト/ライブラリ)を作成しても、その時点ではコンテンツはただ「サイト内に存在する」だけで、一般のユーザの目に触れることはありません(画面左側のナビゲーションにリンクが表示される、検索にはかかる、だけ)。
そこで、コンテンツの内容を抜粋表示しつつ、ユーザの動線として「入口」になるのが、Webパーツ(アプリパーツ)の役割です。
アプリパーツはそれ自体がアプリの「ビュー」なので、管理者が表示項目を自由に設定することができます。例えば、新着5件だけを表示させる、更新順で10件を表示させる、特定の分類のみ表示させる、等々。
また、アプリパーツとコンテンツは、必ずしも1対1である必要がありません。ひとつのリストについて複数のアプリパーツを配置して表示形式を分ける、例えば パーツA はステータスが「申請中」のアイテム、パーツB は承認済みのアイテムを表示mということも出来ます。
9.アクセス権の継承
SharePoint では、ファイルサーバーと同様、下位要素は上位要素のアクセス権設定をそのまま引継ぎます。これを「アクセス権の継承」と呼びます。
例えば、次のような場合、サイトAに管理権限をもつユーザーは、その配下すべて(サイトB~G)に同じ権限をもちます。
----------
[サイトコレクション]
サイトA(ルート)
┣ サイトB
┗ サイトC
┣ サイトF
┗ サイトG
----------
この関係性はサイト内コンテンツに対しても働きます。サイトCのリスト/ライブラリはサイトCの権限をそのまま引き継ぎます。ライブラリ内のフォルダはライブラリの、フォルダ内のファイルはフォルダのアクセス権限を継承します。
この「アクセス権の継承」ルールを変更するのが 「権限の継承を中止」です。親要素からの継承を中止した後、個別のアクセス権限を設定します。上の例であれば、サイトCで「継承を中止」して独自権限を設定した場合、以降はサイトCの権限が、配下のサイトF、サイトGに適用されます。親であるサイトAのアクセス権限に変更があっても、継承していないサイトCには影響しません。
SharePoint において、アクセス権を付与する単位はユーザ個人、Active Directory のセキュリティグループ、それに SharePoint 内で独自に定義する「SharePoint グループ」になります。特に SharePoint グループはエンドユーザーにメンテナンスを任せられるため、とても便利なのですが、グループにグループを含む(入子)ことが出来ない、すぐグループが氾濫する、等の欠点も在ります。
また、注意点として、SharePoint では「このグループ・組織からこのユーザだけアクセス不許可」という排他的アクセス権限は設定できません。あくまで「アクセス権限を持つユーザ・グループ」を指定することになりますので、特にノーツ移行では留意が必要です。
10.独自開発とアドオン製品
SharePoint は Microsoft 技術の「寄木細工」です。そのため、 MS 技術(特に .Net や C#)に明るい開発者なら、SharePoint を開発基盤として利用して、ビジネスアプリケーションを構築できます。
データベース設計こそ非公開ですが、SharePoint には大量の API が用意され、かつ比喩でなく「読み切れない程の」技術情報が公開されています。そのため、各ユーザー企業は独自に自社業務に最適化したアプリケーションを設計できますし、また同じ理由から Microsoft 以外のサードパーティ製アドオンも数多く存在します。こうした点が、恐らく他グループウェア製品と SharePoint の最大の違いかと思います。
クラウドの Office 365(SharePoint Online)については、残念ながら開発、アドオンともに大きく制限されます。しかし、将来的には、Azure との連携や、SharePoint App Store の立ち上げなど、これから開発環境は大きく広がると見込まれています。
もちろん、開発は常に諸刃の刃です。SharePoint がバージョンアップした際には、カスタム開発箇所もきちんと検証する必要があります。場合によっては全面的な再開発が必要でしょう。そのため「やりすぎ」には常にに注意が必要です。もっとも、この匙加減は実に難しいのですが…
おわりに
以上、できるだけ短くまとめるつもりでしたが、やはり予想通り長文になってしまいました。
前回も書きましたが、この内容については著書「Office 365 チームサイト活用ガイド SharePoint Online で情報共有!」でより詳しく解説していますので、そちらも参考にして頂けると嬉しいです。ちなみに、この本は SharePoint 2010 ベースのため、現在 2013 ベースに改定すべく鋭意執筆中です。
ユーザー視点で見ると、確かに SharePoint にはひとつ間違ると ク○システム 言われかねない側面もあります(苦笑)それは、SharePoint が日本人好みの「いたせりつくせり」システムではないからです。ぜひより広い視点、つまり「企業全体の業務と情報をどのように整理して、それに必要な情報基盤を維持するか」という観点から SharePoint を活用してみてください。全く違った世界が見えてくる筈です。
もし検討にあたり、外部のアドバイスが必要でしたら、是非、弊社までお声かけ下さい。いわゆるコンサルティングですが、単発(例えば1ミーティングのみ等)でもお受けしています。
最後にひと言。「ノーツと同じように SharePoint を使うのは愚の骨頂。それならノーツを使えば良い」。
ありがとうございました。
初心者向け SharePoint を理解するための 10 のポイント 1/2
SharePoint担当者におすすめする書籍一覧
チームサイト3分クッキング
login