2010年2月17日水曜日

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

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

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


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

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

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

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

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

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

2010年2月13日土曜日

Twitterがもたらす害

ちょっと刺激的なタイトルにしてみました。

だいぶブームも落ち着いてきた感のあるTwitterですが、テレビや雑誌はネットより少し情報が遅れるということもあって、いまだ書店などで「コミュニケーションの革新」的なTwitter特集記事を目にします。
最近では企業のマーケティングで利用したり、有名人や政治家が積極的に活用するのは当たり前になってきました。

ハマコー、Twitterで大暴れ
http://ascii.jp/elem/000/000/496/496335/
楽天 三木谷社長、全社員にTwitter推奨
http://www.itmedia.co.jp/news/articles/1002/08/news059.html

私自身もTwitterを使っています。
その有効性は実感していますし、多くの評論家が記事で書いている通りだと思います。

が、ここはあえて世の中の流れに逆らって、最近感じている批判的な意見を。

Twitterの特徴のひとつは、1回の投稿での140文字という文字制限です。
これにより、まとまった意見や情報の投稿は、著しく制限されます。
そのため、Twitterの投稿をツィート、つぶやき、と言うとおり、投稿される情報のほとんどは言ってしまえば独り言に近いムダ話で、その場で読まなければ大した話題にもなりません。

これは、社会的に地位の高い、あるいは優秀と言われる方のTwitterでも同様です。
テレビでは経済情勢について小難しい意見を述べている人が、Twitter上では「お腹減った」だの、「家に新しい植木を置きました」だの、それがどーした、と言いたくなるつぶやきを連発します。
140文字しか書けないのだから、これはある意味仕方のないことなのですが、
この仕組みこそが、人から思考力をうばう罪だと考えています。

またこれは、なぜブログではなくTwitterで発信するのか?という疑問への答えにもつながります。

ブログでもやろうと思えば1行程度でムダ話を書き続けられますし、実際にアメブロで芸能人のブログを見ていると、そういう類のブログもあります。
しかし、ブログではなくTwitterで発信する理由は、情報が残らないから、でしょう。
Twitterは1日に何度も投稿されますし、人の投稿も同じページにどんどん上乗せされていくので、
誰かが昨日投稿した内容を探し出すのは結構大変です。
そもそも、Twitterに投稿された情報で、後日わざわざ探し出して再利用する価値のあるものは、前述の通りあまり多くないので、情報が残らないことには不便はありません。
一方でブログはその人の投稿だけが掲載され、検索性も優れているため、有効な情報は後々まで残り、いろいろな人に再利用されます。

まとめると、
ブログ:人にしっかり読まれて再利用されるので、気合を入れてしっかりと情報を書く
Twitter:たいしたことは書けず、情報も再利用されないので、何も考えずに書く
と言えるのではないでしょうか。

人間、楽な方が好きなので、同じ情報発信するなら、頭を使わずにできるTwitterを選んでしまうのは当然なのかと思います。
ブログは書くのが大変で続かないが、Twitterなら続く、という人は私の周りにもいます。

Twitterのようなツールがあることに問題はないのですが、これを企業内や学校内で積極的に使う、というのは注意が必要と考えます。
ただでさえ言語力が低下してきている昨今で、「文章を考えて書く」という機会を減らしてしまうことは絶対に避けなければなりません。
文章を書くことは、頭の中の漠然としたイメージを人に伝わるように組み立てるという、思考力や論理性、表現力を育てるトレーニングです。

コミュニケーションツールとして現場社員が利用する分には良いですが、会社として推奨すべきは、ブログのように文章を書く、情報をまとめるという作業を皆にやらせることのほうではないでしょうか。

2010年2月4日木曜日

BPOS と Windows Live ID

BPOS を契約する際は、Windows Live IDが必要です。
Live ID自体は、Hotmailを利用している人はそのアドレスとパスワードがそのままLive IDとして使えますし、持っていない人も自分の会社のアドレスなどですぐに作れます。
マイクロソフトのサービスはLive IDを認証に使うものが多く、一度作っておくと、いろいろなサービスで使いまわし出来ます。
https://accountservices.passport.net/ppnetworkhome.srf?lc=1041

が、BPOSに関してはこのLive IDが曲者でした。
ここ数日、弊社内で利用しているBPOSについて、マイクロソフトのサポートとコミュニケーションして分かったことを書いておきます。

1.購入情報はLive IDに紐付いており、それは消せないため、契約期間中に同じIDで別のBPOSの契約はできない

これは意外と不便です。
例えば、使っているExchangeやSharePoint環境でなんらか不具合が起き、新しくBPOSを契約しなおそうとしても、契約期間が終了するまではできません。
契約期間は1年間なので、使っていようといまいと1年間は課金され続けるハメになります。

2.異なるLive ID間でのデータ移行はできない

違うLive IDで作ったBPOS環境に、今使っている環境を移行することはできません。
BPOSの場合、試しに個人のIDで作ってみて、その後良ければ再度別のIDで契約、なんてことも少なくないと思いますが、「試し」の段階で作り込んでしまうと移行で泣きを見ます。


また、独自ドメインを使っていない場合は、ドメインも引き継ぐことはできません。

Exchangeを使われている方は独自ドメインがほとんどでしょうが、
SharePointだけですと自動で振られる長いURLのまま、という方が多いと思います。
その場合は、サイトのデータ移行は手動でやる必要があり、かつURLも変わってしまうという事態になります。

3.BPOSからSharePoint Onlineへのデータ移行はできるが、その逆はできない

当然、同一のLive ID内での話です。
これは前にも書いたのですが、そうなんです。
Exchangeはどうかというのは、すみません、分かりません。
SharePointがNGなら同じなんじゃないでしょうか。


Live IDというコンシューマの世界では便利な認証システムを使っていることで、企業で使う際には当然できてほしいことが出来ない、なんてことがあります。
BPOSは手軽に使い始められるのですが、後々になって移行や管理IDの変更やらを考えると、最初から注意いただくことをオススメします。