SharePointのチームサイトを作成すると、ディスカッション掲示板やタスクリスト、お知らせ、イメージライブラリなど様々な機能がついてきます。これらの多様な機能は、SharePointの統一的なコンテンツシステム上に構築されています。
SharePointにおけるコンテンツを知るには、管理画面からサイトコンテンツタイプを見てみます。
いろいろなコンテンツタイプがすでに登録されています。
例として、「お知らせ」のコンテンツタイプは以下のようになっています。
下のほうの「列」のところに「タイトル」「本文」「有効期限」の三つの列が登録されています。つまり、「お知らせ」とは、「タイトル」列、「本文」列、「有効期限」列を持つものであると定義してあるわけです。
列も多くのプリセットを持っています。
これらの列を組み合わせて、独自のコンテンツタイプを作ることができます。
コンテンツタイプは単一継承をサポートします。つまり既存のコンテンツタイプの列を引き継ぎながら新しい列を追加したコンテンツタイプを作成することができます。
「アイテム」は、タイトル列のみをもつルートコンテンツタイプです。Javaでいうならjava.lang.Objectのようなものです。(厳密にはアイテムの親として「システム」が存在しますが、SharePointのユーザーが「システム」コンテンツタイプを直接操作することはありません。僕の予想になりますが、システムは、コンテンツの作成者、作成日時、更新者、更新日時をSharePointが強制的に管理するための列を持ちます。)
コンテンツタイプで定義した型のインスタンスを保持するのはリストになります。例としてタスクのリストを張っておきます。
RDBと絡めてたとえるならコンテンツタイプをテーブル定義、リストをテーブル、リストアイテム(コンテンツタイプのインスタンス)をテーブルの行、といったところですが、SharePointのリストはRDBのテーブルと異なり、複数のコンテンツタイプを格納することができます。
これがタスクリストの定義です。コンテンツタイプとしてタスクとサマリータスクが紐づけられ、タスクが既定のコンテンツタイプとされています。
面白いことにタスクとサマリータスクにコンテンツタイプの継承関係はありません。タスクはアイテムを親としますがサマリータスクはフォルダを親とし、フォルダの親はアイテムです。列を確認すると、作成者、更新者の二つを除いた全ての列が共通となってはいます。それっぽく列が集まっていればよしとするようです。
このようにリストはかなりやわらかいコンテナです。その柔軟さのためにコンテンツタイプと紐づけずにリストを使うことも可能であり、実際によく見かけますが、コンテンツタイプを定義しておくとサイト内のコンテンツの見通しがよくなります。アドホックなリストは再利用性のないサーベイ等で利用し、普段はコンテンツタイプを定義するのがよいと思われます。
ファイルと紐づくアイテムはドキュメントを継承します。Wikiページ、Word、Excel、画像などが該当します。ドキュメントを格納するリストはライブラリと呼ばれる傾向があるようです。
リストとライブラリの機能的な違いはよくわかりません。リストであってもフォルダをもつツリー構造はもてるからです。たとえばサマリータスクはタスクのフォルダですが、タスクライブラリというものは見たことがありません。単純にユーザーがなじみやすい名称としてライブラリとしたのかもしれません。
ドキュメントライブラリは、Explorerライクのなじみやすいツリー構造を提供するためSharePointをファイルサーバのように使う人は後を絶ちませんが、僕はこれをアンチパターンと考えています。
SharePoint Designerは、SharePointをカスタマイズするための無料のツールです。
Microsoft SharePoint Designer 2010 (32 ビット版)
ワークフローをガリガリ作成するときにはほぼ必須です。また、aspxファイルやcssファイルをいじってサイトの外観をカスタマイズするのにも便利です。
この週末で勉強が進んだので、最近お熱のSharePointについて書いてみます。
SharePointはMSの企業向けCMSとでもいうべき製品です。Windows ServerとSQL Server上で動作し、Active DirectoryやOutlook連携はもちろんのこと、他のOffice製品とシームレスに連携可能なように作られています。たとえば簡易な経理であればExcel帳票でやってしまうような部署は世の中にはまだまだあると思いますが、そのようなOfficeドキュメントドリブンの業務を強力にサポートすることができます。(ただし素のSharePointはいまいち使いにくく、業務にあったカスタマイズが必要です。)
現在最新の SharePointは SharePoint 2010です。製品のラインナップには無償のSharePoint Foundation が存在するのですが、そもそもベースとなるWindows ServerとSQL Serverが有償なので、ハード・OS・ミドルウェアを入れる時間、コストを考えると万人におすすめできる製品ではないと考え、その機能に魅力を感じつつも僕はこれまでは距離をおいていました。
しかしクラウドベースのOffice365が登場してから状況が変わりました。
1アカウント月額600円からExchangeの行き届いたメール・カレンダー環境とSharePointがセットで手に入るのは価格破壊もいいところで、十人ちょっとの中小企業であればサーバ管理者をたてるよりお得でしょう。
これは僕が契約したOffice365のSharePointの画面です。デフォルトでMS Pゴシックが使われるのが嫌でスタイルに手をいれてメイリオにしてあります。
トップの画面は普通のWebページですが、ポータル用途のためにいろんなASP.NET Webパーツを配置することができます。上図ではOffice365のデフォルトでドキュメントライブラリや投稿フォームが配置されています。
Web上のCMSらしく、Wikiライブラリなんかも使えます。
編集はOfficeでおなじみのRibbonを使用します。
いわゆるWiki記法は他ページへのリンク程度しかサポートしませんが、スタイルによってWordライクな編集が可能になっています。カスタムスタイルを作成する方法はまだ調査中ですが、これができればWiki記法が無くてもそれなりにいい線いくのではと思います。
ライトウェイトな共有ドキュメントセットとしてのWikiはナレッジワーカーには必須なツールだと思いますので、Wikiのカスタマイズは今後も重要なテーマとして見ていきます。
“ファイル”を扱うドキュメントライブラリも当然のように使えます。
ドキュメントライブラリは一見すると単なるファイルサーバなので、ファイルサーバのように使ってしまうこともありますが、これはアンチパターンの一種です。ドキュメントライブラリに限らないことですがSharePointにはSharePoint流のデータの扱いというものがあり、その方法に則らないと単なる入力フォームとデータ置き場の塊になってしまいます。特にドキュメントライブラリはアンチパターンに陥りやすいので注意したほうがいいでしょう。
SharePointでは作業管理のためにタスクリストを使うことができます。
タスクリストの良い点は、Outlook上で進捗入力ができることです。
Outlookと連携することで、WebのUIから入力するわずらわしさを軽減できるだけでなく、期限が近づいたときのアラートなども上がります。
また、簡単なガントチャートであればSharePoint上で表示することができます。実プロジェクトで使用するような本格的なガントチャートの表示やリソース管理には、Project Serverが必要になります。
SharePoint上でリスト(タスクリストはリストの一種です)の入力・編集を高速に行いたい場合は、Access Web Datasheetコンポーネントを使用することができます。
Access Web Data Sheetコンポーネントは特に他のリストアイテムからコピペして入力したい時に威力を発揮します。Excel管理と大差ない速度で入力でき、重宝します。Access Web Datasheet コンポーネントは、その名前からAccessのインストールが必須に思われるかもしれませんが、なんらかのエディションのOffice2010クライアントが入っていれば良いようです。
時間ができたら以下のトピックについて続けて書きます。
三週間で8000行のコードを書いて、年末までに結合完了というミラクルなスケジュールでガツガツやってます。
徹夜・休出もしたけど体調不良で休んだりもしたので営業日ベースだと15日強。個人的には1日300行ぐらいが品質担保できる上限だと思っているので書きすぎましたね。リファクタリングで書き直し分も含めるとツールの自動生成分をいれても15000行は書いたのか…
というわけでつまりは火をふいております。
これだけの量を書くことができたという時点で、労働集約的なコーディングをしているんだなぁ、と反省。
プログラマの生産性はなかなか理解されません。
ずっとプログラマでご飯を食べていこうと思うと、給料の向上に見合う生産性の向上が必要です。しかしゼロから物を作る場合、それほど生産性は上がりません。
プログラマはそれを理解しているので、腕が上がるとライブラリやフレームワークを学び、出来あいのものを組み合わせることで生産性の向上を維持します。ライブラリやフレームワークは日々進化していきますから、ライブラリやフレームワークの進化を消化することで自身の生産性の向上を維持するわけです。
プログラマを活かせない組織はそのことを知りません。あるいは知っていても上記の枠組みを支援しようとしません。だから2011年にもなってJDK1.4のコードを各羽目になったり、commonsのような、もうあって当然レベルのライブラリであっても導入に難色を示されたりします。
まぁ、上記は余談として
できのいいフレームワークに精通すること以上の生産性を求める場合はどうしようかということを考えていて、出てきた結論は月並みで、CMSのようなモジュラー化の進んだプラットフォームに精通していくべきなんじゃないかと。blogや掲示板やwikiを簡単に追加できるアレですよ。
.NETerなので対象に考えてるのは orchard か sharepoint です。特にsharepointは Office365でも使われているので注目のプラットフォームだと思います。sharepoint2010はサンドボックスボードが追加されたので、Office365のようなクラウド環境でも各ユーザーがプラグイン突っ込めるんですよね。
商機を感じたのでoffice365のアカウントつくってみたんですが、遅いｗ。ユーザー数がどんどん増えているらしいけどさばけてないんじゃないですかMSさん。Windows Liveのほうがまだキビキビ動く気がしますよ。
⇒最近試したらそれなりに速くなってました。Office365いい感じ。
まぁ遅さはさておき、プラグインプログラマになろうということを考えているのでした。