SNS構築、後々問題になりやすい6つのトラブル発生ポイント／実績500以上のガイアックス

SNSについて知る　（SNS構築を考える際のティップス集）

後々問題になりやすい、6つのトラブル発生ポイント

本ページでは、SNSの企画・構築・運営を検討される方向けに、SNS構築プロジェクトで後々問題になりやすい、トラブル発生ポイントを、6つご紹介しておりおります。

これまで、SNS構築経験のない方、またこれまでにご経験がある方にもお役立て頂き、つまずくことなくプロジェクト進行して頂けますよう、TIPSとしてまとめました。

6つのトラブル発生ポイント

1. 戦略・企画立案

2. 運営企画

3. 体制（クライアント側、ベンダー側双方）

4. コンペ、ベンダー選定

5. 社内でのプロジェクト化

6. セキュリティ

以下にて、もう少し詳しく、ケーススタディー形式でご説明します。

1. 戦略・企画立案

【ケース1】目的・KPI・ターゲットへ提供する価値が曖昧なまま、企画が進んでしまった。

　目的・KPI・ターゲットへ提供する価値など、プロジェクトの背景をドキュメント化し、常に意思決定の判断基準にしておかなければ、途中途中の思い付きで方向性が変わり、当初の目的が果たせない事になってしまいます。

　また、ベンダーとのコミュニケーションにおいても、「何のために？」という意思統一の拠り所があるほうがスムーズに進みます。

【ケース2】SNSの成長ロードマップが描けていなかった。

　SNSには独自の成長ロードマップがあり、その各過程で行わなければいけない設計・運営企画が変わってきます。

　その成長ロードマップに沿った企画、機能、運営企画、ビジネスモデルの検討をする必要があります。

【ケース3】初期リリース時の機能ボリュームが必要以上に多くなってしまった。

　特にSNSの運営経験が無い会社様の場合ですが、企画検討の段階で、他社サービスをベンチマークしながら、網羅的に機能を含めたり、メンバーの思い思いの機能を含める傾向があります。

　初期リリース時に機能ボリュームが多くなる事により、「投稿先の分散」や「サイトの文化形成スピードの鈍化」につながってしまいます。

2. 運営企画

【ケース1】サイトはリリース出来たが、盛り上がらなかった。

　成長ロードマップの初期段階の注意点として、「どのように遊ぶかの文化形成を行う」「ナビゲーターや仕込みを用意し、盛り上がり感を演出する」などといった方法を検討しなければいけません。

　また、そういった事も考慮に入れた企画・設計も行う必要があります。

【ケース2】プロモーションをかけたので新規ユーザーは獲得出来たが、定着してくれなかった。

　SNSを利用するユーザーの目的は、「他者とのコミュニケーション」であり、「反応を感じる」ことです。その結果として、所属意識が高まり、ゆくゆくは活発に投稿を行ってくれる優良ユーザーになっていきます。

　優良ユーザーに育て上げるには、「反応を感じさせる」仕掛けを運営企画で準備する必要があります。

【ケース3】ナビゲーターはおこなったが失敗し、逆にユーザー離れにつながってしまった。

　アクティブ化を行うためには、「ユーザーとの距離感」や「投稿の粒度」、「異性間のコミュニケーションバイアス」に注意する必要があります。この3点に失敗してしまうと、ユーザーは居づらさを感じ、サイトから離れてしまいます。

3. 体制（クライアント側、ベンダー側双方）

【ケース1】運用・運営に必要な体制を想定出来ていなかった。ベンダー側からも適切なアドバイスを貰えなかった。

　SNSの実装機能、運営企画内容にもよりますが、クライアント様側では専任のご担当者様が必要になるケースも多くございます。但し、社内事情で専任のご担当者様をつけられない場合は、ベンダー側でのご支援体制を敷く必要があります。

　そのためには、ベンダー側には、「必要な業務内容/体制のノウハウ」・「運用/運営支援が可能なサービス」が揃っている必要があります。

【ケース2】プロジェクトに、SNSの企画・PM経験者が参加していなかったため、リリース後、問題となる仕様が多く発見されてしまった。

　SNSは、ユーザーと共に作り上げていくサービスです。ユーザーの動きを想定し、「盛り上げるためにはどうしたら良いか？」、「御社としての事業目的を実現するにはどうしたら良いか？」という事を意識しながら、企画・設計を進めていく必要があります。

　経験者でなければ、ユーザーの動きを想定しきれず、必ず不用意な仕様となってしまいます。（また、クライアント様側でSNS構築・運営のご経験が無い場合は、要件定義フェーズでベンダー側へのチェックが行き届かないため、特に問題が多くなる事が予想されます。）

【ケース3】プロジェクトメンバーとして複数社が関与しているため、意思伝達と管理に、必要以上の時間がかかってしまった。

　SNSの運営には、常に改善が求められます。但しその改善も、当初の「目的」「KPI」「ターゲットに提供する価値」などの判断基準を拠り所として行わなければいけません。

　特に、運用・運営に多くの会社が関与してしまいますと、意思伝達と管理に時間がかかり、本当に考えなければいけない事に時間を割けなくなってしまいます。

4. コンペ、ベンダー選定

【ケース1】ベンダー選定の基準が不明確で、結局、見積り金額が安いという理由が決め手で、現在のベンダーを選定してしまった。

　SNSの成功要因は、「戦略・企画」「設計」「運営企画」にあります。単純に「機能の開発工数」だけを比較してしまいますと、サイトを作る事が目的の短命のプロジェクトになってしまう危険性があります。

【ケース2】複数社に見積り依頼を出したが、各社とも見積り前提が違い比較検討出来なくなってしまった。

　競合見積りでは、見積り前提が違うために金額に大きく差が出てしまう事があります。

　その場合、正しい意思決定が出来ず、結果的にやりたい事を実現するために、追加コストの発生につながってしまいます。

　　（▼見積り前提に入っていないために、後々トラブルになりやすい機能要件▼）
　　　　１．管理画面（ユーザー管理用、投稿監視用）／２．KPIの効果測定に必要なDB設計／３．各機能の連携

　　（▼見積り前提に入っていないために、後々トラブルになりやすい業務分担▼）
　　　　以下の表をご覧下さい。（拡大版は、本ページ末よりダウンロード出来る資料をご覧下さい。）

【ケース3】ベンダー側に提案力が無かったため、クライアント様側での要件検討や、指示出しの負担が重くなってしまった。

　受託開発という事業モデル上、ベンダー側にはシステム開発部隊だけしか抱えていない会社も多くあります。

　そういったシステム開発寄りの会社ですと、「仕様書に沿って作ればよい」というスタンスでプロジェクトに取り組まれるため、一つ一つの仕様・要件を決める際にも、クライアント様側に指示を仰ぎながら進める事になります。

5. 社内でのプロジェクト化

【ケース1】運営・運用に必要な業務内容が抜けたまま、予算取りとベンダー選定をしてしまった。

　SNSの運営・運用には、静的なサイト以上に必要な業務があり、クライアント様側だけでは対応しきれない事がほとんどです。

　最初からそういったところを想定せず、予算取り・ベンダー選定をしてしまいますと、後から自社でもベンダーでも対応出来ない事態に陥ってしまいます。

【ケース2】いずれのベンダーにも相談せず、リリーススケジュールを引いてしまっていた。

　SNS構築のプロジェクト必要期間は、企画からテストまで含めて5～6ヶ月になる事が多くございます。

　クライアント様の事業計画上リリースまでのスケジュールを短い状態でご相談をされる場合もありますが、その場合、ベンダー側は、クライアント様の意向次第で、短期間での構築を進めます。

　但し、構築期間を短くする事によるしわ寄せはサービスに出てしまいます。（スケジュール優先になるため、企画・要件に妥協が生まれてしまいます。）

6. セキュリティ

【ケース1】個人情報漏洩やセキュリティに対するリスク対策が出来ていなかった。

　世には表立って情報が出ませんが、日々何かしらの個人情報流出の事件が発生しています。一度個人情報を流出してしまいますと、サービス・クライアント様の信用度が落ちてしまいます。

　また、損害賠償が発生してしまう可能性もあり、その金額は膨大です。ベンダー側ではそういったリスク対策をする必要がありますが、対策を講じれていないベンダーもまだまだ多く存在します。

（参考：『Security NEXT』　http://www.security-next.com/）