※ 営業用記事です。しばらくの後、別ブログに移動します。

MOONGIFTでは外部の会社様の自社Webサービスの立ち上げに対してプロデュースやアドバイスを行っています。うまくいくケースもありますが、逆にうまくいかず頓挫してしまうケースもあります。実際、関わっていないケースでも自社Webサービス開発を途中で延期してしまったという話は良くきかれます。

via Threesome on Flickr - Photo Sharing!

　

そこで今回は自社のWebサービスをいかに手早くローンチするかについて書いてみたいと思います。実際は色々な要素がありますが、これまでの経験上ではこれらの項目に気をつければある程度うまくいくのではないかと思います。手早く立ち上げれば初期コストの低減がのぞめますので、案件がペンディングになっている会社様やこれから立ち上げようと思われている会社様は参考にしていただければ。

なお、MOONGIFTではWebサービス立ち上げに関する企画、アドバイス業務を承っております。お問い合わせはinfo@moongift.jpまでお気軽にどうぞ。

詳細は以下。

1. ビジネスモデルをはじめから組み込む

Webサービスは無料で提供されるものが多いため、無料で提供しなければならないという雰囲気があります。そしてその中でビジネスモデルを組み立てようと思うと広告モデルなど固定化されたものになってしまいがちです。が、PVがビジネスになるまで伸ばせれば良いのですが、そう簡単にはいきません。

むしろ少ないPVであってもビジネスとして成り立つようにモデルを考える必要があります。ごくわずかであっても黒字化していれば追加投資を考えたり、人員を投入したりと言ったことができます。さらに言えば例え赤字であったとしても追加投資は考えられますが、全くビジネスモデルがない状態ではそれはまず不可能です。

プロジェクトが進んだ段階でビジネスモデルと考えると、それまでの議論が霧散する可能性があります。初期の段階からビジネスモデルは考えなければなりません。

　

2. オープンソースを活用する

プログラム言語、データベース、サーバ自体などオープンソースを極力活用することでプロジェクトを身軽にできます。もちろんコストをかけても良いのですが、実際運用を行ってみないとどれ位の反響があるかは読めません。初期投資を抑えることでスムーズなローンチが期待できます。

また、スクリプト言語を利用することでアジャイル的に開発を押し進められます。自社で始めるサービスに対してウォーターフォール型の開発を適用するのは勿体ないと思われる場面が多々あります。自社だからこそ知り得るユーザの動線、ニーズの変化、市場の変化をいち早くシステムに反映するためにも軽量な言語で取り組むのがベストです。

もちろんサービスの質によっても異なりますが、モックの段階はスクリプト言語で仕様の固まった段階から別な言語で構築するという二段階の方式も選べるかと思います。

　

3. 社外のリソースを使う

社内プロジェクトの場合、兼務で行われることが殆どです。自社の強みを活かして行うのは大事ですが、現状の業務を把握した上でないと進められないプロジェクトでない場合は社外のリソースを使った方が速い場合が多いです。

また社内のリソースでは知識も社内の割合が高く、もっと広くネットの世界の動き、世間の動きや法律などについても知識が十分でないとプロジェクトが小さく収まってしまう可能性があります。

開発会社の場合、開発を社内のリソースで行う場合もありますが、この際も兼務であるために現状のプロジェクトにスケジュールが引きずられてしまうことがあります。開発会社であったとしても、ローンチまでの開発やモック作成については外部に依頼（月単位などの契約で）してしまうのがお勧めです。

　

4. プロジェクトシートを作成する

立ち上げようとしているWebサービスについて、何が必須の要件で、どういったコンセプトかなどを記したものがプロジェクトシートになります。Producing Webでは34の項目を挙げましたが、最低限これらの項目について記すべき事項があるかないかのチェックは行うべきです。

これらの項目をチェックし、記述しておくことで口頭に比べてずっとメンバーに対して浸透しやすくなり、向くべき方向が一つになってきます。さらに軸がぶれる前、1週間に一度は見返して現在の作業とずれがないか確認すべきです。

　

5. ドキュメントを残す

小さなWebサイトであっても、ミーティングの内容や結論、すべき作業、デザインコンセプトなどドキュメントに残せるものはとにかく書き記しておきます。この際重要になるのは、フォーマットは気にしないということです。後で一覧し、検索したり参照できるのであれば体裁にはこだわってはいけません。社内用ドキュメントであれば、体裁にかける時間はプロジェクトの推進にかけるべきです。ドキュメントの内容としては箇条書きやグラフ、イラストを使ってできるだけ長文は避けるようにします（長文は読むのが面倒なので）。

ドキュメントについていちいち承認をもらう仕組みは個人的には賛成できません。内容を知らない人にタスクを振るのであれば確認は必要ですが、議事録などであれば基本的に全員予め承認を得ている前提で終わらせるべきです。よくメールで「確認してください」とプロジェクトメンバー全員に配信することがありますが、見ない人が何人もいます。

　

6. トップが参加する/反対陣営も参加する

プロジェクトメンバーにどのような人を組み込むかについてですが、賛成意見ばかり集まっても良いサービスが出来上がる訳ではありません。また、サービスがローンチした後に反対陣営の人たちに突っ込みを受け、うまく立ち上がらないこともあります。

トップが参加することで、予算的な問題やリソースの割り当てを上からの指示として承認を受けられるようにします。また、はじめから反対陣営に回りそうな人たちを巻き込むことで、運営をスムーズにする効果がのぞめます。

　

7. まず動くものを作る

アジャイル的なやり方とも共通しますが、議論の結果を素早くモックアップに反映していきます。これもドキュメント化を徹底しておけば技術者の方はミーティングに参加せずとも必要な機能を見つけ、実装できます。

　　

以下は特にミーティング関係になります。プロジェクトを進める上でミーティングを行うのは必要ですが、幾つか注意するだけでずっと効率的で意義のあるものになります。

8. 長い会議より短い打ち合わせ

サービスの立ち上げは会議室で行われる訳ではありません。長時間の会議を1本よりも、短い打ち合わせを数回行う方が効果的です。答えがつまってしまうようなことでも、次回のミーティングまでに答えを出すようにすれば考える時間も生まれてスムーズに議論が行えるようになります。

　

9. ミーティング中はパソコン・携帯電話禁止

ミーティング中にパソコンを議事録代わりに入力する方がいますが、画面が他の人からは見えないために実際はIMやメールを打っている可能性もあります。別作業を行っているとミーティングに集中できず、意見も出なくなります。これは携帯電話は特に顕著です。

そこでミーティングルームにはノートパソコンや携帯電話を持ち込まないようにしてしまえば議論に集中できるようになります。

　

10. ミーティング参会者は少なく

長い会議が生まれる原因として、全員の招集が容易でないということがあります。そのため、集まった機会を逃さず話す時間が長くなります。

そこで予めミーティングへの参加者を少なく設定しておけば、簡単に時間調整ができるようになります。他の人たちは議事録を確認したり、予め目を通すであろうアジェンダに意見を書いておくといった対応ができるようになります。

　

MOONGIFTでは御社のサービス立ち上げをサポートします。企画段階または途中の段階からでも参加可能です。ご用命はinfo@moongift.jpまでお気軽にどうぞ！