SharePointサイト内にWikiページを組み込む

小ネタです。

SharePoint Server 2007には、標準でWikiを作成できる機能があります。
Wikiはサイトやページのテンプレートとして搭載されており、WYSIWYGやページへのリッチテキスト書込みなど、独自の機能を持っています。

Wikiを何に使うかによって設計の方法は異なるものの、やっかいなのはWikiが独自テンプレートのため、他のWebパーツと組み合わせて使うことができないという点です。
たとえばプロジェクトサイトを作り、チームメンバーでスケジュールやドキュメントの共有に加え、Wikiページを1枚作って、そこにアイディアや各種データを記入していく使い方をしたい場合。
プロジェクトサイトのサブサイトとしてWikiサイトを作るとサイトが別になってしまいますし、サイト内にWikiページを作ってもリンクでつなぐという方法になってしまいます。（↓こんな感じ）

これはこれで悪くないですが、内容を確認するにはいちいちリンクを開く必要があり、あまりスマートとは言えません。

そこで、Wikiページを簡単にサイト内に組み込む方法です。
イメージとしては以下のような感じです。

ちなみに、他のWebパーツと並べて内容を確認できるだけでなく、編集もすぐにできます。（右に小さく表示されている編集アイコン）

これは実はビューの切り替えだけで出来ます。
まず、Wikiを作りたいサイトで、「作成」→「Wikiページライブラリ」で、Wikiを作ります。

注）この際、サブサイトからWikiを作るのはNGです。
SharePointに詳しい方ならご存知の通り、サブサイトといえどもサイトが分かれると、Webパーツとして情報を表示することが難しくなるからです。

組み込みたいページに、作成したWikiページライブラリをWebパーツとして追加します。
以下のように表示されたかと思います。

この追加したWikiページライブラリの「共有Webパーツの変更」を行い、「現在のビューの編集」をクリックします。
ビューの列項目から、「Wikiコンテンツ」と「編集（編集アイテムへのリンク）」のみを選択し、OKします。

これで、Wikiの内容をページ内に表示できます。
なお、Wikiページが複数ある場合、ブログのように記事が連続で表示されます。

Wikiの内容が増えて見づらい場合は、Wikiを別ページにしてタブで切り替えられるようにしても良いでしょう。

ファミレス化した社内ポータル

社内ポータルの利用者（エンドユーザー）の方に話を聞くと、

「うちにはファイルサーバーもあるし、メールもかなり使ってるし、このポータルの位置付けがよく分からない」といった声をよく聞きます。

こういった声の多いポータルは、そもそも提供側である情報システムの担当者も、ポータルと他のシステムの区分けを明確にされていないことがほとんどです。

メールやファイルサーバーと違って、ポータルというのは定義が難しいツールです。
「企業内のさまざまな情報の入口」、というのが基本的な概念であり、社内システムや各種情報へのリンクやナビゲーションを提供するはずなのですが、実際には入口として機能していないものも多々見受けられます。
リンクが大量に並んだサイトを使おうという気にはならないですし、リンクをクリックしたら別ウィンドウでいつものシステムが開くのであれば、いままでのグループウェアやイントラネットと何が違うのでしょう。
しかし、それは何もかも作り手が悪いわけではなく、そもそも企業内にある多くの情報やシステムすべてへの入口を作ることは非常に困難で、企業規模が大きければ大きいほど不可能に近くなっていくものです。

したがって、情報の入口としてポータルを構築しても、現実的には一部の情報を統合する程度にとどまり、利用側は相変わらずさまざまなシステムを用途ごとに使い分け、ポータルの位置付けは不明確なままに運用されていくことになります。
利用者にとっては、ポータルの価値を感じることは難しいでしょう。

社内の多量な情報へのリンクやナビゲーションを集約したポータルは、ファミレスに近いものがあります。
ジャンルの違う情報がポータルというメニューに統合されており、利用者はそこから良いと思うものを探すというスタイルです。
多くの社内ポータルは前述のとおり、ファミレス化しています。

ファミレス化したポータルがすべて悪いわけではありません。
実際に、インターネット上のYahoo!やMSNも、まさにファミレス化したポータルサイトですが、いまだ国内ではトップクラスのアクセス数を維持しています。

しかし、インターネット上のポータルと社内ポータルでは、大きく違う点があります。
それは、利用者がどのような目的でアクセスしているか、です。

社内でポータルにアクセスするとき、大半の利用者は明確に「○○を調べたい、○○の資料が欲しい」という目的を持っています。
いっぽうで、Yahoo!などにアクセスする利用者は、なんとなくアクセスして最新情報やニュース、コミュニティを見る、というように目的が決まっていない利用者が非常に多いです。

目的（食べるもの）が明確に決まっていないときには、ファミレスは便利でしょう。
ですが、目的が決まっている人にとってはどうでしょうか。
ラーメンが食べたいという人は、ファミレスよりラーメン屋を選ぶのではないでしょうか。

社内ポータルも同様です。
あれこもこれも薄く広く提供するより、ポータルに来るとこの情報が得られる、というように用途が決まっていたほうが、利用者側は迷うことなく使えます。
ポータルに限らず情報系のシステムは、かぶっている機能が多いため、使い分けや各ツールの用途を定義することは重要です。

なお、ファミレス化を目指すこと自体はダメではありません。
「何か探したいときにこのポータルに来ると見つかる」ことが実現できれば、それは利用者にとっても明らかにメリットを感じられます。
利用者が目的を持ってサイトに来ていることを踏まえて、適切な画面設計やナビゲーションを提供するだけでも、情報を探す行為を効率化できるでしょう。
その工夫をせず、多様なジャンルの情報をただまとめても、残念ながら利用する価値は低くなってしまいます。

SharePointで部門サイトを作るときの考慮点

全社ポータルの下に、各部門で使う部門サイトを作られている、あるいは作ろうと考えている企業って多いと思います。
ここ最近、全社ポータルはとりあえず安定稼働しているから、部門サイトを作ってみようというお客様から相談いただくことが増えています。
皆様いろいろとお悩みのようで、
中には「部門サイトという発想自体、正しいのだろうか」とお考えのお客様もいらっしゃいます。

お悩みの事項としては大体共通していて、
①アクセス権（管理権限）をどうするか
②組織変更があったときにどうするか
といった点です。


①については答えは無く、システム部門側の負荷と現場の自由度とのバランス、製品としてできる部分と運用でカバーしなければならない部分などを考慮して、お客様ごとに変わってくるでしょう。
納得できる解決策にたどり着くまでは多くの試行錯誤を繰り返すことになります。

私はさらにこれらに加えて、情報が分散するリスクについてもお話しています。

部門サイトを作ると、多くの場合、利用者は自分の部門サイトをメインの情報共有の場とし、
それ以外のサイトやポータルはほとんど見なくなる傾向にあります。
それはそれで活用が進んでいるので良い、という考え方もあるのですが、
これではファイルサーバーに部や個人のフォルダを作ってファイルを入れている状態と大差ありません。
ノーツのDB乱立とも一緒です。
SharePoint導入前に、こうした情報の分散や管理の煩雑さといった課題があり、
SharePoint導入後もまた同じ状態になってしまうのでは、導入した意味が薄れてしまいます。

では部門サイトは作らないほうが良いか？というと、そんなことは無いです。
利用者は全社ポータルに直接情報を投稿するのは嫌がるでしょうし、まずは部門内で必要な情報をやり取りするというのが、業務の大半でしょう。
そういった場として部門サイトは最適なのですが、
要は、部門サイト内で情報が完結しないように、情報の通り道を用意してあげることが必要なのです。

SharePointの機能では、別のサイトやリストから情報をさまざまな条件で抽出して表示することが可能です。
これはファイルサーバーやノーツでは出来なかったことです。
ただし、どんな情報をどんな形で抽出するのかは計画が必要ですし、適切な形で情報が格納されていなければなりません。
時間をかけるべきは、この情報格納方法と、情報の通り道の設計です。

さらに、SharePoint内では情報がキチンとまわっていても、それだけでは人に情報を届けることは不十分です。
SharePointはあくまで1つのツールであって、企業としてやりたいことを実現する1要素にしかすぎません。
情報を企業内でどのように流通させるか、ここが弊社で提供する社内マーケティングのサービスになります。