「半製品」のSharePointを補うアドオンと開発

2010年04月08日 09時00分更新

文● 村田聡一郎／リアルコム

「開発」から「設定」へ

　では、コーディングによる「開発」を極力避けるかわりに、どうしたらよいのだろう？それは製品が提供する機能に、「設定」を加えるだけで使うことだ。具体的には、SharePointの場合、4つの方向性がある。

SharePointの機能拡張ステップ

（1）そもそも開発させない。SharePointの標準機能だけで使わせる

　SharePointのUIからできる設定できる、パラメータの変更のみ行なっているケース。SharePointの機能は飛躍的に充実してきており、とくにSharePoint 2007ユーザーでは、この（1）を原則としている企業も多い。

（2）SharePoint Designerによる設定変更のみ認める

　SharePoint Designerは、マイクロソフトが無料で提供しているSharePointのカスタマイズ用ツールだ。UIからのパラメータ変更ではなく、SharePointという製品そのものに対するカスタマイズを行なえる。たとえば、SharePointのワークフローの設定などは、UIで行なえる範囲はごく限られており、事実上SharePoint Designerを使うことが前提となっている。

　SharePoint Designerで行なうことができるのは基本的には、「SharePointという製品」の枠内ではある。しかし、実現したい機能によっては下記（4）レベルに匹敵するコーディングが必要になるし、下手にいじるとSharePointを簡単に「壊して」しまうこともできる。そのため、エンドユーザーに自由に使わせるというわけにはいかない。こうしたことから、SharePoint Designerの利用は情報システム部門のみとしているケースが多い。

（3）SharePointに加えて市販のアドオン製品を使い、バージョンアップ対応はパッケージに吸収させる

　SharePointでは多数のサードベンダーがアドオン製品を販売しており、SharePoint単体では得られない付加機能を提供している。次回紹介する「Nintex Workflow」や、AvePointの「Doc Aveシリーズ」など、「これは本来アドオンではなく、SharePointが製品機能として標準で持っていてしかるべきなのではないか？」と思うような優れた製品も多い。

　価格も（とくにコーディング開発の人件費に比べると）リーズナブルに抑えられていることが多く、大いに検討の余地がある。さらに主要なアドオン製品は、たとえばSharePoint 2007から2010へのバージョンアップに追随して、機能差分を吸収してくれるので、バージョンアップの際のコストを大幅に抑えることが期待できる。

（4）.NETを駆使してフル・コーディングする

　これが最後の手段である。上記では実現できない業務ニーズであれば、自前で開発せざるを得ない。

　この4つは相反するものではなく、段階状になっているので、各社ともこの4つの使い分けポリシーを策定していることが多い。たとえば「原則は（1）＋（3）で、（4）は情報システム部門が必要と認めた場合のみ例外的に実施」、といった具合だ。

　一見面倒な話のように見えたかもしれないが、EUC後のバージョンアップという苦難を一度でも経験したことのある情報システム部の方であればすぐに納得していただけることだろう。少なくともBP研究会の参加企業の中では、バージョンアップに伴う苦労を二度と繰り返さないためにどうするか？をあらかじめ考えるのが常識になってきている。

　次回はSharePoint上でアクションとアクションの自動連携を実現する「ワークフロー」機能について説明するが、上述のワークフロー開発のアドオン製品「Nintex Workflow」を紹介し、「SharePointにおけるアドオン製品の位置付け」についての具体例としたい。