本内容は、SharePoint Server 2007 をベースに記載しています。(2008 年に記載したコラムです。コラム終了のため、こちらに移動しました . . .)
最新の SharePoint 2010 を使用した製品開発手法については、「SharePoint Server 開発 サンプル コード集 : 10 行コードで作る .NET アプリケーション」を参照してください。

ここでは、SharePoint を使用した製品開発について理解していただくためのコラムを連載します。(代表的な手法を中心に紹介します。次回以降、以下の目次にしたがって掲載をしていきます。)
今回は、その準備として、SharePoint で製品を開発することのビジネス上の意義について説明します。

SharePoint 開発の本質

• はじめに
• UI / Web パーツで見る「フィーチャー フレームワーク」
• ワークフロー フィーチャー
• フィーチャーのカスタマイズ
• インストーラとしてのソリューション パッケージ (wsp)

SharePoint が特徴としていることは多数ありますが、大きなメリットの 1 つは「作らずして必要な仕組みが手に入る」ことにあります。私自身も過去に ERP、CRM、PDM を始めとする業界のパッケージ製品の導入にいくつも携わった経験がありますが、コンピューター システムに関与する特にユーザー層 (利用者層) にとって多く求められることの 1 つは、わざわざソフトウェア開発などの発注を行うことなく、それでいて必要な (また、あるときには独自な) 仕組みを実現することにあります。財務業務、営業支援/顧客管理、流通業務、製造管理など多くの基幹系 (マイクロソフトではこれらを Line-of-Business, LOB と呼びます) の業務システムではそうした仕組みを実現できる多くの選択肢が提供されていますが、ふと身近な業務に目を向けると、まだまだ管理されるべき多くの企業資産が「管理されない状態」になっていることに気づかれるでしょう。例えば、CRM に登録する顧客データを一旦 Excel で加工して上長に確認している姿、企業内でのデータ収集を行うためのファイル共有をしている姿など、実にさまざまな形です。

SharePoint は、いわばこうした「日常的な」(普段着的な) 情報を管理するためのパッケージ製品のごとき役割を果たします。例えば、部内から従業員満足度に関するアンケート収集を行って毎期末に同じ集計処理をするといった場合、こうした身の回りの仕組みを実現するためにわざわざアンケート入力を行う Web アプリケーション (ASP.NET) の開発を外部に発注するようなことはしたくないでしょう。あるいは、専用のパッケージ製品を購入するというほど大げさな話でもありません。従来であれば、ユーザー部門のソフトウェア技術に長けた「エンドユーザー プログラマ」と言うべき、いわば現場の IT ヒーローにマクロ作成などを頼んでいたかもしれません。この IT ヒーローは、いつも身の回りの多くの人たちの世話で忙しくなっていたことでしょう。

SharePoint を使った場合には、次のようになります。

1. エンド ユーザーは、Office InfoPath 2007 を使ってマウスのドラッグ アンド ドロップ、プロパティ設定などを主体にフォームをデザインします (コードの記述はいっさい必要ありません)
   
2. 作成したフォームを SharePoint サイトに「発行」(Publish) します。これにより、デザインしたフォームのサーバーへの登録と、フォームに入力した結果を入れるいわばテーブルのようなもの (SharePoint では「リスト」と呼んでいます) が構築されます。
3. 上記で発行された InfoPath フォームのリストで、[スプレッド シートにエクスポート] を選択します。
   
4. Excel 上に登録されたデータの一覧が表示されますので、好みのグラフや集計処理を作成します。

補足 : SharePoint 2010 では、まずリスト (カスタム リスト) を作成し、そのあとで、リストのフォームを InfoPath でデザインできます。(むしろ、この方法でフォームをデザインしてください。)

作成が終わったら、InfoPath ブラウザ フォームの (入力フォームの) URL をメールで (部内全員に) 送信します。メールを受けたユーザーは、InfoPath を持っていなくとも、ブラウザさえあれば、メールのリンクをクリックして上記のブラウザ フォームに入力をおこなうことができます。管理部門 (人事部) では、Excel を使って常に SharePoint 上に集められた従業員満足度のデータと接続された状態で集計を行います (追加の登録があっても Excel 上のボタン 1 つで更新を反映させることができます)。つまり、エンド ユーザーによる「従業員満足度 収集・管理システム」が完成したわけです。

ログインしているユーザーに応じて氏名などの情報を自動で設定することもできます。入力は、InfoPath のブラウザ フォームではなく Word を使うこともできます (Word でも同様に、入力したデータをリスト上のデータとして登録させることができます)。他のさまざまなシナリオもあります。書けばきりがありませんが、SharePoint が優れているのは、こうした処理がいっさいのプログラム コードを記述することなく、ユーザー部門で実施できてしまうことです。

さて、このように記述すると、「SharePoint さえあれば今後まったく開発が必要でない」かのごとく誤解されるかもしれません。しかし、皆さんの会社で独自に開発したシステムや業界固有のパッケージ製品などとの併用、あるいは、特定の差別化された機能が必要なケースなどには、標準的な機能実装の域を越えて、プロフェッショナル開発者による部分的なカスタマイズが必要となってくることでしょう (例：Outlook から休暇申請を行うとバックエンドの経理システムにデータが転送される。製造業界で固有の形式のファイルを Word による設計書と共に扱う、専用のドキュメント管理システムを構築する。特定領域にニーズの高い差別化されたグループウェアを提供する。など)。つまり、上述のように一見万能のごとく記載した SharePoint であっても、すべての業界、すべての企業のテンプレートを組み込んでいるわけではありません。(このことは、SharePoint に限らず、すべてのパッケージ製品について言えることでしょう。)

こうしたニーズを実現する「開発」の手段としては、以下の 2 つの選択肢があります。

• 皆さんの企業で独自に作成したシステムや導入されている基幹系パッケージ製品などで、SharePoint と連携した処理を構築する
• 特定の業務などに固有の専門的な処理を SharePoint 上に実現する

パッケージ製品など、外部の企業が提供する購入ソフトなどとの組み合わせでは前者が適しているでしょう。一方、これから自社開発を予定しているもの、あるいは、皆さんの会社自身がそうした製品の提供者の場合などでは後者を選択することができます。無論、SharePoint をいっさい使わず、専用のシステムに SharePoint と同等の仕組みを構築してしまえば良いという選択肢もあります。しかし、例えば「表計算の仕組みが必要」となった場合に、結果的に仕様は膨らみ、Microsoft が長年に渡り膨大な費用を投じて開発を行ってきた「Excel」と同等の「第二の Excel」を作る羽目になるかもしれません。あるいは「第二の InfoPath」を作ることになったり、SharePoint が持っている Office ドキュメントの IRM (Information Rights Management) や監査の機能と同等の機能を作ることになるかもしれません。ケース バイ ケースでの方法の選択が必要となります。

SharePoint では、こうした機能実装のニーズを想定して、多段階のアーキテクチャを採用しています。例えばワークフロー作成を例にとると、現場の業務管理者などユーザー部門の管理者がワークフローを作成できるように SharePoint Designer 2007 を使用してコードを記述することなく実装できるようになっていますが、その一方で、情報システム開発者や製品開発者などは、Visual Studio で作成した独自のアクティビティをこの SharePoint Designer に組み込んだり、Visual Studio で構築したワークフロー テンプレートをユーザーが好みのリストで使えるように SharePoint に組み込んだりすることが可能になっています。ユーザー部門から見れば、こうした高度な開発者 (プロフェッショナル開発者) がプラグインした仕組みを組み合わせてビジネスを独自にデザインしていくことができるようになっています。

そして製品開発などに代表されるように、特に開発したものの再利用性が求められる場合は (例：ある業界に共通の機能、ある一般的によく利用される製品と連携した機能、など)、特定の SharePoint サイトへの一過的な機能実装ではなく、インストーラーなどで提供される完結したパッケージなども必要となるはずです。SharePoint では、「フィーチャー フレームワーク」と呼ばれる仕組みによって、こうしたエンドユーザーに公開される機能 (フィーチャー) の「完結的な提供」もできるようになっています。

ある製品では、SharePoint の Office 連携の仕組みは必要であってもユーザビリティは差別化すべき重要な要素であり、SharePoint が持っている “いまいちパッとしない UI” は隠ぺいしてしまいたいと思うかもしれません。またある製品では、SharePoint のいくつかの機能はそのまま欲しくても、ワークフローに関しては理解性と迅速性が求められる業務分野で、ワークフローのデザイナー (ワークフロー作成機能) だけはもっと業界のユーザーにとって使いやすいものに変える必要があるかもしれません。「どこをもらって、どこを捨てるか」は、その必要とする業態や業界によってさまざまです。

この連載では、次回以降、こうしたニーズを実現する 「SharePoint 上で実装する製品開発」のテクニックを順番にご紹介していきます。

関連ナンバー

• SharePoint 2007 開発 (SharePoint 開発の本質)
• SharePoint 2010 開発 (10 行でズバリ !)
• SharePoint 2013 開発 (SharePoint アドイン)