ファイルサーバーにはこんなに問題が

メールを捨ててSharePointを使おう！

2010年05月07日 09時00分更新

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

前回は、あるけど「ない」SharePointのコラボレーション機能の実体を紹介し、5つあるメールとファイルサーバーの問題点のうち1つを解説した。続いては、残る4つの問題点と解決策をみていこう。

問題点2●メールは本質的に「1対1コミュニケーション」のツールで、情報共有には向かない。

　メールには、宛先のみに届く「信書」の性質がある。1対1のコミュニケーション（たとえば人事部からの昇給辞令の送付）には適しているわけだ。だが、大人数での情報共有が進まないという点は、メールのデメリットとなる。本来全員に開示してもよい情報、たとえば課員の業務日報なども、課長あてにメールで送るとすべて1対1になってしまう。かといって、全員にCCすれば洪水になるのは前回紹介した通りだ。「同報メール」や「メーリングリスト」もあるが、これも本質的には1対1のメールを複数人に同時に送っているにすぎない。

　メールのもっと大きな問題は、送った瞬間に全員分のコピーができてしまうことだ。ファイルが添付されたメールを100人に送ったら、その瞬間100個のコピーができる。これはオリジナル性／最新性の問題を引き起こす。

　またこの特徴は、ITコストの面では悪夢のような負荷となる。たとえば、1MBの添付ファイルをつけたメールを1000人に送ったら、それだけで1000MBの容量となるわけである。実際には1000MBでは済まないはずで、メールサーバーやクライアントPCでバックアップやログを取っているから、企業全体でみると実際には4GBにも8GBにもなっているはずである。

　要するに、メールは構造的に情報共有には向かない、1対1のツールなのだ。

大量のメールが蓄積される現状をSharePointのチームサイトで解決

解決策2●ファイル共有はメールではなく、チームサイトにアップする

　SharePointのコラボレーション機能であるチームサイトを使うことで、この問題を改善できる。まず、「グループワークでは、ファイルのメール送信は原則禁止」という運用ルールを作る。最初は現場からの反発があるかもしれないが、反発はたいてい「これまで慣れてきたやり方を変えること」への心理的なものだ。メリットをきちんと説明すれば、現場も理解してくれる。そして、いったん慣れてしまえば、現場もそのメリットを享受するので、だんだんとワークスタイルとして定着していく。

　もちろん、チームサイト側の使い勝手をできるだけ改善しておくのも重要だ。とくに、メールとの連携を強化することは重要である。「サイトにアップしただけでは、そのことがリアルタイムにメンバーに伝わらない」という理由でメールにこだわる人が一番多いから、チームサイトにアップしたら「通知」メールが関係者に送られるように設定しておくとよい。さらに前回ご紹介したNintex Workflowによるワークフローを使うと、よりきめ細かなメール通知が可能なチームサイトも作れる。

　「通知メールでまたメール洪水が加速するのでは？」という声もあるだろう。しかし、通知メールは「捨ててもよいメール」であることが一目でわかるので、受信者の負荷は低い。捨ててしまっても、「本体」はチームサイトにあることがわかっているからである。それに何より、必要性を感じないなら「通知」を解除するなど、自身でコントロールできる点が大きなメリットだ。

　ファイルのコピーが1000個できてしまうこともないので、システムへの負荷も軽い。サイト上に保存されたデータがオリジナルだという運用ルールさえできれば、オリジナル性の問題もない。編集する時は、チェックアウト／チェックイン機能で二重更新を防ぐ。履歴管理機能を使えば過去ファイルも残るので、より安心だ。

問題点3●メールは本質的に「フロー」であり、流れていってしまう。

　メールの大きな弱点は、正式な履歴がどこにも残らないことだ。たとえば、あるお客様を担当するアカウントチームに途中から加わったメンバーには、それ以前のやり取りの経緯を知る方法がない。メールシステムのログはあくまでシステム監査や万一の不正などの際に掘り出して使うことができるだけで、一般ユーザーが使えるものではない。

　ある営業マンが、最近引き継いだ顧客から「2年前にもらったこの見積もりの件なんだけど……」と問い合わせを受けたとする。当時のやりとりがメールで行なわれていたら、後任者が確認するのは難しい。「なぜ、どういう経緯をへて、こんな破格の値引きを提示するに至ったのか？」といった経緯や背景は、提示額そのもの以上に重要な情報であることが多いが、「見積書」に残っているのは提示額だけだ。だれかがに過去メールを掘ってもらったとしても、そこにすべてのメールが含まれているという保証はない。

　また、検索ができないのも大きな問題だ。自分のメールボックスは検索できるが、他のユーザーがやりとりしていた過去の情報を探す手段がない。要するに、日々の仕事の履歴が会社として残っていないのである。

自分が参加しないやりとりが分からなくなるメールと、やりとりをストックできるチームサイト

解決策3●チームサイトを核にしたコミュニケーションで、フローをストック化する

　チームサイトは、こうした「長期間継続するプロジェクト」ではとくに有効だ。メールで行なわれているコミュニケーションの履歴を残しておくことで、非常に大きな効果を上げることができる。つまり履歴が残ることで、情報の共有と再活用が進む。

　途中からプロジェクトに加わったメンバーにも過去履歴が詳細にたどれるし、日々のやり取り自体が貴重な記録およびナレッジとして残る。プロジェクト上の経験やノウハウも、プロジェクト終了後もそのまま保存できる。また、プロジェクト進捗が「見える化」できるので、たとえば部長や管理部門も随時「見に来る」ことができる。そして情報はすべてサイト上にあるので、検索できる。やってみるとわかるが、この効果は絶大である。

問題点4●メールは社外コミュニケーションにおいては不安定な技術である。

　社外の相手とのコミュニケーションにおいて、メールはとてつもなく便利だ。宛先を指定するだけで、世界中のだれとでも通信できる。この利便性は絶大だ。一方で、意図しない相手への誤送信、相手に届いている保証がないなど、さまざまなリスクをはらんでいる。

　まず危険なのが、意図しない相手への送信だ。宛先を簡単に指定／追加できることから、「間違いメール」「誤送信」はしばしば発生する。とくに、多人数のプロジェクトでTOやCC欄に何十人もの20人ものアドレスが入っている場合だ。これだと、うっかり誰かひとりのアドレスが抜けていても誰も（本人も）気づかない。逆に、対象でないアドレスが混ざってしまうこともあるだろう。この場合も、気づくのは難しい。

　また、メールには、相手も正しく届くという保証はない。最近は「インターネット上で紛失」はほぼなくなったが、かわりに出てきたのが「迷惑メールフィルタ」である。送信側はまさか自分のメールがスパム扱いされているとは思わないから、「なかなか返事が来ないなあ……。」と待っている間に、数日をロスすることはよくある。

　たとえ無事に届いたとしても、大量のメールを読み流し、読み飛ばし、ガンガン消すという習慣がついている人も多いから、うっかり「読まずに削除」されてしまっている可能性もある。相手先企業によっては、添付ファイルのサイズ制限を2～3MBに設定していたり、特定の拡張子（exeとかzipとか）を問答無用でブロックしたりすることもある。

　さらに、よく誤解されているのだが、メールはセキュアな伝達手段ではない。メールは基本的に暗号化されておらず、インターネット上の通信を盗聴することで、第三者に読まれてしまう可能性がある。しかも、盗聴されたことに気がつく手段はない。

　メール本文や添付ファイルの暗号化もだんだん広まってきているが、送信相手も対応が必要であったりと、まだ使えないケースも多い。もちろん、メールによるウイルス感染の脅威も依然なくなっていない。

　メールは、こうしたリスクは承知のうえで、細心の注意を払って利用するしかない。しかし外注先や取引先など固定した相手との長期的なコミュニケーションなら、メールを使わないほうがよい。

到達が保証されないメールと、確実に伝えられるチームサイト

解決策4●社外コラボレーション用にもチームサイト

　社外の相手とのコラボレーションでも、チームサイトは非常に有効である。社外からも使えるようにSharePointを設置し、ユーザーID管理を行なうという手間はあるが、こうしたインフラさえ整っていれば、あとはセキュアで確実な情報共有ができる。メールでは送れないサイズのファイルをやり取りすることもできる。

　最近はクラウド（SaaS）的にSharePointサイトを提供するベンダーも出てきているので、社外コラボ向けはそうしたサイトを使うというのも手だ。

問題点5●ファイルサーバーは「情報共有」には向かない

　続いて、ファイルサーバーの問題点をみてみよう。はっきりいってファイルサーバーは、情報を「共有」するには向いていない。情報の「蓄積」、つまり置いておくためのものだ。以下、ファイルサーバーの問題点を簡単に列記する。

「蓄積」と「表示」が分離されていない（つまり「ビュー」がない）: フォルダに蓄積した状態がそのまま唯一の表示ビューなので、情報を蓄積した本人には便利だが、本人以外が情報を探そうとなるとまず「フォルダ体系」から理解しなくてはならない
ファイルの属性情報（プロパティ）がない: ファイル名、最終更新日、サイズ、といった最低限の情報しかないため、プロパティを使った管理ができない。とくに、文書オーナーがわからないので、「捨ててよいか？」を問い合わせる先がない
本質的に「溜める」だけで、「捨てる」ための機能がない: だれも管理していないので、だれも「捨ててよい」と判断できないというケースが大半。かくして、容量の大半がゴミのまま、だれも捨てられない、という状況が発生しがち
アクセス管理が弱い: アクセス履歴が取れないため、だれが参照したか、ダウンロードしたかがわからない。こっそり削除やうっかり削除／上書きされても気づかない可能性が高い。また利用状況がわからないので、よく使われているのか、まったくのゴミなのかも判断しづらい

ファイルサーバーの問題点もチームサイトで解消できる

解決策5●チームサイトによる、高機能なファイル共有サイトを構築

　チームサイトを使って、上記の問題点をそっくり裏返す。つまり出し手と受け手で異なるビューを使わせることも可能なので、受け手にとって使いやすいビューを設計することで情報共有を促進する。豊富なプロパティが使えるので、適切なプロパティづけとアクセス管理を行なう。とくに「捨てる」時のことを考慮してアクセス履歴を管理し、最終更新日などをトラックすることで「ごみ溜め化」をふせぐ。

★

　いかがであろうか。冒頭で「チームサイト導入の課題は単なるITツールの話ではなく、全社員にそのメリットを伝え、教育・啓蒙して、日々の仕事で有効に使ってもらえるかを考えなくてはならないから、確かに大仕事だ。」と書いた意味をご理解いただけたであろうか。

　ただしこれは、確かに大仕事ではあるが、非常に重要な仕事でもある。社員をメール洪水とファイルサーバー墓場から救い出し、総人件費の数％、数億円にあたる改善が見込める。ぜひ前向きに取り組んでいただきたい。