惚れさせ６６ 「跳ばせない」 : 地獄のミサワの「女に惚れさす名言集」
個人開発でWebサービスを作ったものの、全然ユーザーが集まらなくて自然消滅、、というのはよくある話です。 おそらく個人開発者の一番の悩みは「作ったものが誰からも使われない」でしょう（当社調べ）。
この記事では、この問題に対するおそろしく意識の低い方法論を整理してみたいと思います。
めっちゃバズらせる・ヒットさせる方法論ではなく、あくまでバズらないWebサービスでもさびしく孤独死するのを避けたい…という後ろ向きなハックですのであらかじめご了承ください。
目次
そもそも、なんでWebサービスは死ぬのか
- Webサービスの死因
- よくある個人開発サービスの一生
- 「バズか死か」の二元論を避ける
死なないサービスを作る（意識低い）方法論
- 【1】CGMじゃなくてツール型にする
- 【2】できるだけ何も作らない
- 【3】絶対に赤字にはしない
注意と言い訳
- 死なないだけだと、ただのゾンビ👻
- 最後は確率論なので、いっぱい作ろう😇
まとめ
そもそも、なんでWebサービスは死ぬのか
いきなり哲学的な見出しになったけど、もちろん中身は意識低い話です。
Webサービスの死因
完全に私見ですが、「サービスの死」とは以下３つの状態を指します（断言）。
【死因①】ノーコンテンツ
コンテンツがメインの価値になるサイトで、コンテンツが圧倒的に少ない OR あっても全然更新されてないなどで、有用なコンテンツがない（あるように見えない）。【死因②】動かないシステム
システムのエラーなどで、本来の機能を利用できない状態が放置されている。 （Twitterログインが機能していない、など）【死因③】サイトの消滅
ドメインが切れてて、そもそもサイトにアクセスできない。サーバを解約して、もう何も動いていない。
狭義には③が完全な死ですが、①と②みたいなサイト見たときも、実質死んでるって判断しますよね。
よくある個人開発サービスの一生
上記の死因を踏まえて、個人開発でよくあるWebサービスの一生は、こんな感じでしょうか。
- サービスリリースしたけど全然使われず、がんばって自分で投稿したりする
- がんばって宣伝したりするけどやっぱり使われず、自分でも投稿しなくなり放置されだす（①ノーコンテンツ）
- ライブラリや連携外部サービスのアップデートに追従しなくなり、サービスが動かなくなる（②動かないシステム）
- ドメイン代がもったいなくて、更新をやめる（③サイトの消滅）
＿人人 人人＿
＞ 突然の死 ＜
￣Y^Y^Y^Y￣
身に覚えがありすぎて、書いてて動悸が激しくなってきた。。
恥を承知でさらすと、わたしのサービスもこんなのばっかりです。
booklovesmusic | 読書にぴったりの音楽おすすめサービス
こちらは上記の死因②まで順調に消化しており、来年1月のドメイン更新をせずにこの世から消える予定です。 （むしろ今までよく更新してきたな。。）
「バズか死か」の二元論を避ける
ここまでWebサービスの死因とよくあるライフサイクルを整理してみました。 このパターンで一番問題なのは、モチベーションが続く間に軌道に乗らないと、ほぼ間違いなく死んでしまうことです。
誰も使わない状態を自分ひとりで支えてるので、モチベーションが尽きると更新も止まり、そのまま上記の死をすべて経験することになってしまうのですね。。 もちろんそれまでにサービスがバズって軌道に乗ればいいのですが、そうならないことも多い。
そしてどんなにテンション高くはじめても、モチベーションはいつか絶対に落ちます（断言）。 波があるのは当然なので、モチベーションが下がってもサービスが死なない設計・運用にしたい。
サービスリリースすると、ついつい「バズか死か」みたいな二元論で考えちゃうことが多いんですけど。 そうじゃなくて、死ににくい設計で長期運用を可能にし、モチベーションの波と付き合いながらのんびりサービスを育てていく。 そんな方法を考えてみるのが、この記事の目的です。
死なないサービスを作る（意識低い）方法論
というわけで死なないサービスを作る方法ですが、大きな死因が3つあるので、これを順番につぶしていけば必然的に死亡率を下げることができますね。さっそく見ていきましょう。
【1】CGMじゃなくてツール型にする
まず一番大きいのがこれです。 死因①の「ノーコンテンツ」はCGMだから起きる問題なので、CGMをやめるだけで大きな死因を１つ減らすことができます。
CGMはむずかしい
ここで「CGM（Consumer Generated Media）」とは、 「ユーザーの投稿コンテンツがサイトの中心的な価値となるようなサービス」のことを指します。 例は多すぎて不要かと思いますが、TwitterとかCookpadなんかが有名どころですかね。
CGMはコンテンツが集まると圧倒的な価値が出るのですが、最初のコンテンツ集めが難しかったりします。 コンテンツがないから人が集まらず、人が集まらないからコンテンツも増えないという「ニワトリ🐔・タマゴ🐣」問題ですね。
※もちろんCGMをうまく回す方法論もあるわけですが、それができる人はそもそもこんな記事読まないでしょうし、ここではあくまで意識低い方法を考えます。
ツール型にしたらいいじゃない
というわけで意識低い解決策としておすすめなのが、「ツール型」のサービスにすることです。 ここでツール型とは、「他のユーザーが誰も使っていなくても価値を提供できるサービス」と定義してみます。
拙作で言うと、こういうトーナメント作成サービスなんかはもろにツール型ですね。
これの何がいいかと言うと、仮に数年くらい誰も使っていなかったとしても、死んだサイトには見えにくい。 CGMだと寂れるとますます寂れるという負のループが働いてしまうわけですが、ツール型はその心配がありません。
実際トーナメントはもう運営4年目なのですが、2年目までは細々と使われる程度でした。 3年目くらいから利用が増えて、ありがたいことに有料の法人利用も増えてきています（感謝）。
その間はほぼ放置だったわけですが（今もだけど）、長期運用できたからこその成長でした。
SNS連携型もあるよ
また純粋なツール型とはちょっと違うタイプとして、質問箱からブームが続く「SNS連携型サービス」もあります。 これも他のユーザーがいなくても価値を提供できるタイプのサービスですね。
最近大流行したウェブ表彰。やさしいインターネットを作る世界観がとても好きです。
このタイプのサービスについては、質問箱を開発したせせりさんのこんな記事もあります。 blog.sesere.net
こちらでも同じように「ひとりから使えること」の重要性を指摘されてますね。 このSNS連携型だと、作ったコンテンツが拡散力を持ちやすいという点で、純粋なツール型より爆発力があります。
（補足）ツール型の弱点
とりあえずCGMをやめることで「ノーコンテンツ」による即死は避けれるわけですが、ツール型にも弱点があります。
まず純粋なツール型は、集客が弱くなりがちです。 トーナメント作成サービスとか見てもらうとわかりますが、バズる要素はまったくないですねw
基本的にツール型は検索流入を地道に拾うのがメインになります。 時間がかかるし爆発力もないですが、検索流入を取れればその後は安定したアクセスを期待できます。
またSNS連携型の方は拡散力がすごいのですが、初速で火がつくまで至らなかったときや、いったんブームが落ち着いて誰も使わなくなったときに、再度盛り返すのが難しいんじゃないかなーという気がしてます（作ったことないから知らんけど）。
マシュマロさんくらい常時使われる状態になれば、永遠にバズって新規開拓を繰り返せそうですが。。 marshmallow-qa.com
トーナメントは検索以外にも工夫した結果、多いときで月間150万PVくらいまで伸びてきました。 ツール型をどうやって成長させるかは、長くなるのでまたそのうち改めて整理できたらいいなと。 （いまも試行錯誤中ですが。。）
【2】できるだけ何も作らない
2つ目の死因は「動かないシステム」でした。
放置したシステムが動かなくなる危険性は、定期的にやってきます。 Twitterログインの仕様が変わる、使っている言語やフレームワークのバージョンがサポートされなくなる、など。。
生きているサービスはこれらの波を乗り越えて寿命を延ばし続けるわけですが、どこかで開発者がこの対応を諦めると、そこでシステムとして死ぬことになります。
めんどくささ vs モチベーション
この対応あきらめるかどうかの判断をとても頭が悪い式で整理すると、
対応あきらめるとき => モチベーション ＜ 対応のめんどくささ
となります。
ユーザーにすごく使われてる、売上が上がってるとかだと、問題が起きてもちゃんと対応しますよね。 そうじゃなくてもサービスつくった直後で気合が入ってるときなら、むざむざシステムの致命的なバグを放置しないと思います。
問題はリリースからしばらく経ったのにサービスが伸びてなくて、それでもメンテナンスに工数を取られるという状態です。 2年前に作って誰にも使われず放置してるサービスでRailsのメジャーバージョンアップしなきゃってなったら、やりたくないですよね。 （それなら最初から新バージョンで新しいサービス作りたいw）
作らなければ壊れない
この問題を完全に防ぐのは難しいのですが、ある程度対策することはできます。
まず前提として、モチベーションに期待するのはやめて、工数＝めんどくささを減らす方向で考えます。 障害はいつ来るかわからないのに、何年もモチベーション保ち続けるとかはムリゲーです。
じゃあどうやって致命的な問題の発生頻度を減らすかっていうと、「極力何も作らない」です。意識低い。。
この年表作成サービスは、開発から2年以上ほぼノーメンテですが、全然元気にご存命です。 ありがたいことに最近になってじわじわ利用も増えてきました（うれしい）。
このサービスでは一番大事な年表のデータを、自前で持たずにGoogleスプレッドシートに丸投げしています。。 これによって、スプレッドシートみたいな複雑なインターフェースを開発・維持する手間がごそっと省けています。
もちろんそれによる制約も多いので、本格的な成長フェーズに入ったら、ユーザーの要望を聞きながらどんどん改善するべきでしょう。 ちゃんと使われるサービスに育てばそれに応じたモチベーションも維持されてるはずなので、むざむざシステム死させることはないはず。
そういう意味では、ある程度使われてるけど全然儲かってないサービスが、一番モチベーション的にはジレンマになるかもしれないですね。。
【3】絶対に赤字にはしない
3つ目の死因は「サイトの消滅」でした。 これはドメイン切れやサーバの契約解除など、どちらもお金の問題が関わってきます。
いまは小規模な個人サービスで大きな赤字が出ることはないと思いますが、たとえ小さくても赤字の状態だと、どこかで支払うのをやめちゃう恐れがあります（経験あり）。
というわけでこれに対する対応はシンプルで、「絶対に赤字にしない」ことです。
サブドメインからはじめる
びっくりするくらい小さい話ですが、大事なところです。 これによってドメイン切れによる死を事実上なくすことができます。
ドメイン死で一番多いパターンは、ドメイン取得してサービス作って、全然使われなかったので1年後の更新をせずにそのまま終了、というやつですよね（何回もやった）。
サービスをサブドメインで始めることで、この悲劇は簡単に避けることができます。 自動更新してずっと使う主要ドメインを持って、新規サービスはそのサブドメインを使えばいいですね。
独自ドメイン取ってたら絶対更新してなかったであろうこんな一発ネタサイトも、サブドメインにしてるおかげでいまだに動いています。（自己紹介でのウケはいい）
最初にかっこいいドメインを取ってテンションを上げる「ドメイン駆動型」開発も好きですが、長生きさせたいならサブドメインから始めてもいいんじゃないかなと思いますよ。
順調に育ってきたら、あとから独自ドメインにしたらいいですからね（逆はむずかしい）。
サーバももちろん無料で
こちらも大事。 月数百円程度のサーバ代でも、数年前に作ってまったく使われてないサービスのためだけに払ってたりすると、そのうち解約したくなる日が来たりします。
わたしはHerokuやFirebaseを使うことが多いですが、他にも無料プランで使えるサービスも多いと思うので、ぜひ無料で始めましょう。 無料プランでも工夫すればけっこうな規模まで対応できます。
とはいえいまはFirebaseが尋常じゃなく便利なのでおすすめですよ。みんなFirebase使おう！
注意と言い訳
死なないだけだと、ただのゾンビ👻
というわけで、3つの死因を（ある程度）避ける方法を見てきました。 でもこれだけだと、確かに死んではいないけど、成功してるわけでもありません。
死因のところにも書きましたが、この記事で本当に目指したかったことは、リリースしてすぐに「バズか死か」の二択になってしまう状況を避け、長期的にサービスを成長させる体制を作ることでした。
死なないだけだとただのゾンビです。 目前の死を先送りにできたら、改めてサービスを成長させる方法を考えてみましょう（丸投げ）。
最後は確率論なので、いっぱい作ろう😇
また、サービスを延命させることで成長させるチャンスを増やせますが、 どんなに延命しても伸びないサービスは伸びません（かなしい）。
これについてはもう散々言われてるように、いっぱい作るしかないと思います。 とはいえスクラップ＆ビルドの繰り返しだと「バズか死か」に逆戻りなので、「ビルド＆ゾンビ」で長寿サービスをいくつも作って、じっくり芽が出るように育てるといいんじゃないですかね。
最近この「ブンゴウメール」というサービスを出したところ、ありがたいことにかなり反響をいただけました。 しかし実はこれ、2年前に一度リリースしたときは鳴かず飛ばずだったのです。。
前とはコンセプトを変えたとか、Twitterでお友達が増えて拡散しやすくなったとか、文豪系ゲームが増えて意外な反響があったとか、、、色んな要因があるんでしょうが、要は「わからん」と。
最後は確率論なので、あきらめずにいっぱい作りましょう（自戒も込めて）。
まとめ
思うところがありすぎて、ずいぶん長い記事になってしまいました。。 最後までお付き合いありがとうございます。
まぁ好みが分かれるところではあると思うのですが、こんなやり方もあるよということで誰かの参考になればうれしいです。
おしまい。