SNS・グループウェア技術レポート
SNS（ソーシャルネットワークサービス）
社会的ネットワーク（要は人間関係）をインターネット上に構築するサービス。
人間関係の構築を行うため、以下の機能を持つ。
プロフィール機能
ユーザ検索機能
日記（ブログ）機能
コミュニティ機能
メッセージ送受信機能
これらに加えグループウェアの機能を持つものもあるが本来の機能ではないため簡易版の場合が多い。（カレンダーなど）
グループウェア
グループ作業を行うために必要なツールとグループ管理の機能をまとめたもの。
一般的には以下の機能を持つ。
スケジュール管理
メール
掲示板
ワークフロー
ライブラリ
これらに加え組織という社会的ネットワークを構築するため、SNS的な機能を持つ場合もある。
一般的に高価なため機能は充実している。
【番外】WEB OS
WEB上にデスクトップを作ってそこで動くアプリを開発してグループウェア的な機能を実現しようという発想。
カスタマイズを最初から織り込んで作っているため面白そうではあるが運用法がまだはっきりしてないため今使うのは危険。
アイドレスでの利用
どちらもアイドレスで有用なのは間違いない。
グループウェアはそもそもグループ作業するためのツールだしSNSも人間関係を構築し円滑に流すためのツールなので人間関係のゲームであるアイドレスには向いている。
携帯参加者をカバーするなど、組織内での連携力を上げるならSNS、システムを画一化して調査などの作業効率を上げたいならグループウェアが向いている。
技術的な問題
種類を問わず大きな技術的問題は3つ
特にグループウェアに顕著で複雑すぎて使用やカスタマイズが難しい。掲示板のようにちょっといじってみましたというわけにはいかない。
設置環境がやたらと制限される。perlが動けば何とかなります。というわけにはいかず殆どの場合LAMP環境、場合によってはTomcatやRailsが必要となる。
2に関連するが、負荷が高く環境を選ぶので無料のサーバーにはまず設置できないのでランニングコストがかかる。
上記の問題はあるが、それさえクリアすればパッケージをほぼそのまま使う分には技術的には問題ない。
システムに強いですというアイドレスプレイヤーなら問題なく導入運用できると思われる。
問題はそのまま使えない部分がある場合＆良いとこどりしたい場合で、そもそも一番欲しいものはグループ作業機能が豊富なSNSかコミュニティ機能が豊富なグループウェアである。
が、どっちもそれぞれが本来作られた目的から微妙にずれているためパッケージでそういう機能を満たしたものは殆ど無い。（探した限りではなかった。）
今回特にワークフローとライブラリを搭載したシステムが少なかったが、URLだけ管理すればある程度既存の機能でなんとかなるライブラリに対して、
アカウントが連動して無いと都合が悪いワークフローに関しては連動部分で気を使わないといけないだけ手間がかかる。
気分的な問題
SNSはそもそも見た目のカスタマイズの概念が希薄、グループウェアは見た目が無愛想かつ操作・UIが独特なので恐らくしばらくは不満が出ると思われる。
無愛想な見た目は技族の活躍で解決できると思われるが、どちらにしろ画一的なシステムで縛る事になる。
そのため、ものすごく凝った藩国サイトを作っている場合、デザインが変わり気分的によろしくない。
価格的な問題
SNSはmixiっぽいopenPNEという定番があるが、グループウェアは企業向け、それも大企業向けに進化してきた背景があるため、オープンソースの定番は無くやたらと大規模で高価。
導入から運用まで数百万飛んで行くこともざらなので商業アプリを買ってインストールというのは難しい。
オープンソースはコストの問題からか機能が少ない。ワークフローやライブラリが無くてもグループウェアと銘打ってたりする。（というかそういうのがかなり多い）
技術的な問題を避けて解決するプラン
カスタマイズの難易度が高いのでAipo4とかでそのまま使えるというのが理想です。
が、以下そうもいかなそうな要素が多いのでその場合の開発プラン。
プラン1 Google的解決（連携）
参加環境としてのSNSを中心に置いて、周りをGMailやGoogleカレンダーで固める。
個々のシステムを開発する必要が無いので開発コストが低い。
単機能ごとなので作成や設置、カスタマイズがそれなりに楽。
外観や環境などの制約が無いので単体で見ると使い勝手が良い。
などの利点がある。欠点は、
それぞれ独立したシステムなのでユーザーの一意な判別が出来ない。よって名称変更するとやっぱり追跡が難しい。
全体的に見るとまとまりがない。
ただし、Google認証APIを使うなど接続部分にかなり気を使えばユーザーの判別は解決可能。
プラン2 CMS的解決（組み込み）
グループウェアにしてもSNSにしてもCMSの仲間なので、最近のアプリケーションは最初から拡張性が考慮されていたりする。
その機能を使って必要なモジュールを組上げていく。
一つのシステムとして運用できるため例えばユーザー情報は同じものが使えるので機能間の連携は有利。（名称変更で混乱を起こさないで済むなど）
全体でデザインや操作感が統一できる。
大抵SDK（作成キット）があるので新規開発は楽。
グループウェアは元々の機能が豊富なのでこの手法と相性が良い。逆にSNSは標準機能が少ないので返ってコストが上がる。
などの利点がある。欠点は、
ものによっては外側のアプリケーションの制約を受けて使い勝手が下がったりする。
開発言語や設置環境は外側のアプリケーションに依存するため、システムの選定は開発者と設置環境によって制限される。
全部1箇所に置くためサーバーに対する要求が少し高い。
＃特にオープンソースでこの仕組みを供えたものとなるとさらに狭まる。
まとめ
ライブラリ機能に関しては需要的な理由と携帯対応に都合が悪いという技術的な理由で簡単なテキストとファイル添付くらいしか出来ないものが殆どだった。
これに関しては無理矢理一つのシステムに収めるならXOOPSにWikiかそれに順ずるモジュールをつけるのが一番融通が効くと思われる。
分かれてても良いならページ自体は別で作ってURLなどの情報のみをライブラリで管理する方法が取れる。
カタログ上は（そして導入できるなら）Aipo4なら機能的には無改造で運用できる。
そうでない場合は、携帯対応などは後付けが難しいため、OpenPNE＋BIZ機能かXOOPSにワークフローとライブラリを組み込むか連携させる形が作業量的には現実的と思われる。
また、既存システムだと最低でもLAMP環境というのは避けられないため、データベースが使用できる環境が必要。
1から作るのはスケジュール管理やWEBメールなど個々の作成難易度の高さに加え、それを統合するアカウント管理の開発が難しいため、現実的でない。
システム比較
＊Aipo4の問題
動作環境がTomcat
アップデートが有償サポートを受けないと出来ない。