このページの本文へ

前へ 1 2 次へ

今さら聞けないSharePoint超入門 第4回

必要な機能を追加するための方法を学ぼう

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

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

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

  • この記事をはてなブックマークに追加
  • 本文印刷

前回までで、SharePointの基本機能である「ポータル」と「データストア(リストとライブラリ)」を取り上げた。今回はSharePoint製品そのものではなく、SharePointをより業務ニーズに密着した動的な基盤として利用する上で必要となる、アプリケーション開発とアドオン製品について説明したい。

 SharePointは、製品の標準機能に加え、それをさまざまな形で拡張して使うことが可能なように作られている。機能拡張のためのツールやAPIが提供されており、またそれを利用したアドオン製品もサードベンダー各社から発売されている。

 アドオン製品はSharePoint単体では不足する機能を補うことでSharePointをより有効活用できるものもあれば、さらにSharePointにはない機能を追加するものもある。それでも不十分な場合には独自アプリケーションの開発も可能だ。

SharePointはアプリケーション開発のためのドキュメントも用意されている

 ちなみに、筆者の経験上「SharePointが単体でユーザー要件を100%満たすだけの機能を提供している」という管理者は、ほぼいない。もとより概念論だし人によって表現は違うが、「80点」という人も入れば「90点」「70点」などいろいろだ。裏返すと、不足する10点ないし30点分を何らかの「機能拡張」でおぎなって使うことが、半ば前提であると考えたほうがよいのだ。

 では、具体的にはどのような機能拡張の方法があるのだろうか。詳しくは後述するが、SharePointの機能拡張には大きく3つの手段がある。

  1. SharePoint DesignerによるSharePointのカスタマイズ
  2. アドオン製品を購入して利用
  3. 独自アプリケーション(プログラム)の開発

である。そして実際、大半のSharePointユーザー企業は、3種類のいずれかまたは全部を併用している。

SharePointのカスタマイズを行なうSharePoint Designer

 ただし、この3種は「並列」ではない。それぞれ特徴があり、メリット/デメリットがある。そしてSharePointユーザーの間では、「できるだけアドオン製品を活用し、独自アプリケーション作り込み開発は極力避けよう」という意識が強い。これからSharePointワールドに足を踏み入れようというみなさんは、ぜひこの背景や狙いを理解しつつ検討に入っていただきたい。

「脱・コーディング開発」の流れ

 BP研究会の会員企業さんと話をさせていただいていると、SharePointユーザーの間では「コーディング(プログラムを手書きすることによるアプリケーション開発)はできるだけ避けるべきである」という共通認識がほぼでき上がりつつあると感じる。これは、バージョンアップに泣かされた過去の教訓からであろう。

 Lotus Notes/DominoやSharePointのようなグループウェア系のパッケージ製品は、10年以上前から「エンドユーザーコンピューティング(EUC)」を謳い文句にしている。「ユーザー部門に開放しておけば、情報システム部門の手間をかけずとも、ユーザーが自ら業務ニーズに合うものを開発してくれ、満足度も上がりますよ」というわけだ。

大手企業などで広く使われるロングセラーのグループウェア「Lotus Notes/Domino」。Dominoがサーバ、Notesがクライアントだ

 これは、基本的には正しい。業務ニーズをもっともよく知っているエンドユーザーが自分でアプリケーションを開発し改善していけば、より使いやすいものになっていくのは確かだからだ。問題は、それを「コーディング」という形で行なってしまうと、数年後のバージョンアップの際に多大な追加コストが発生するところにある。

 パッケージ製品は、バージョンアップの際の基本的な互換性をベンダーが保証する。そのため、バージョンアップしても設定値などは基本的に引き継ぐことができ、コストも抑えられる。たとえば、SharePoint 2007で作成したポータルやライブラリ、リストなどの設定情報は、基本的にSharePoint 2010に引き継ぐことができる(完全に、とはいい切れないので注意が必要だが)。

 ところが、「コーディング開発」した部分については、当然ながらパッケージベンダーは保証してくれない。ユーザー企業が再度コストと手間をかけて新バージョンでの稼働を確認し、必要なら改修しなければならない。その数は、EUC積極派企業では数千個に上ることもあるから、1つ1つの改修規模はさほど大きくなくても、企業全体としては莫大なコストとなる。「これまで快適に動いていたのに、バージョンアップという他人の都合で、なぜテストしたり改修したりしなくてはいけないのか?」とユーザー部門からの不満も大きい。

(次ページ、「「開発」から「設定」へ」に続く)


 

前へ 1 2 次へ

カテゴリートップへ

この連載の記事
  • 角川アスキー総合研究所
  • アスキーカード