 |
||||||||||||
|
||||||||||||
| 1 2 3 次のページ | ||||||||||||
|
||||||||||||
| 社内SNSの価値 | ||||||||||||
|
本連載の最終回となる今回は、TISで社内SNSを導入し運営してきた経験の振り返りと、そこから得られた発見、そして次の展開に向けてのアクションについて説明します。また、自社に導入しようと考えている方のために、改めて社内SNSの価値について解説します。 |
||||||||||||
| 運用実績 | ||||||||||||
|
まずTISの社内SNS運用実績を紹介します。ユーザ数の推移は以下のグラフになります（図1）。  図1：TISにおける社内SNSのユーザ数の推移 （画像をクリックすると別ウィンドウに拡大図を表示します） これまで社内SNSを運用してきて、休日や早朝などの営業時間外に行ったバージョンアップ作業で数時間ほど計画停止したことはありましたが、それ以外に営業日で利用できなくなってしまうといった障害は起きていません。もちろんパフォーマンスが著しく低下する、登録されていたデータがロストするような障害も発生していません。 このことは「Ruby on Rails」という比較的新しいフレームワークを使った事例としては、1つの実績になるのではないかと思います。 コンテンツに関しては、社内SNSのグループ機能を観察してみると、作られたコミュニティのカテゴリが、業務利用のものが40ほど、会社生活のためのものが40ほど、趣味のためのコミュニティが30ほどということで、半業務・半オフというコンセプト通りに、うまくバランスがとれているようです。 社員の利用状況に関しても、業務時間と休憩時間を意識した使われ方をしていることがわかります（図2）。  図2：利用状況の分布 （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||||
| 利用者の声 | ||||||||||||
|
社内SNSは今まで社内に存在しなかったサービスなので、利用者自身も戸惑い、そして使い方を探りながら利用されてきました。そういった利用者の声を一部紹介します。
表1：社内SNS利用者の声（抜粋） ここで紹介した利用者の生の声自身も、社内SNSのQ&A機能を利用して集めたものです。こうした利用者と運営者のコミュニケーションができることも社内SNSの良い点だといえるでしょう。 |
||||||||||||
| 社内SNS導入の効果と反省点 | ||||||||||||
|
社内SNSを導入したことで、以下のようなプラスの効果がでてきました。
表2：社内SNS導入の効果 どれも定性的なものになってしまいましたが、ここにあげたような効果は着実に出ていることは事実なのです。 |
||||||||||||
| 社内SNSの弱い点 | ||||||||||||
|
しかしその一方で、未解決な課題も残っています。それは社内SNSでは公式な資料などの公開には向かないということです。 社内SNSを導入した際の最初の狙いが「個人が抱えているノウハウなどを共有したい」というものだったので、社内の標準資料や全社的に配布される資料や理路整然と整理されたノウハウなどについては、社内SNSの機能で公開して共有するのには向いていませんでした。 一般的に、情報は「ストック」と「フロー」に分類されます。「ストック」というのは、時間を超えて蓄積され続ける情報のことです。例えば、Wikipediaの情報はストックとして考えられます。 「フロー」は時間によって次々と現れては流れていくような情報のことです。これはメールやメッセンジャー、ブログで流れる情報も一種のフローと考えることができます。社内SNSで取り扱っている情報の多くはフローです。 社内の公式資料などは、確実に「ストック」として扱うべき情報なので、その置き場所が社内SNSにはありません。TISではすでにグループウェアを導入しており、これまではそれで管理してきました。しかし全文検索機能がないことや、更新情報を複数の資料にわたって一度に見ることができないなどの課題がありました。 そこで社内SNSとは別のサービスとして社内における「ストック」の情報を配置することのできるシステムを構築することにしたのです。このプロジェクトを開始したのが、社内SNS運用を開始してちょうど1年目の2006年末のことでした。 |
||||||||||||
|
1 2 3 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
