作ったWebサービスが誰からも使われなくてさみしい問題を解決する（しない）意識低い方法論

個人開発でWebサービスを作ったものの、全然ユーザーが集まらなくて自然消滅、、というのはよくある話です。 おそらく個人開発者の一番の悩みは「作ったものが誰からも使われない」でしょう（当社調べ）。

この記事では、この問題に対するおそろしく意識の低い方法論を整理してみたいと思います。

めっちゃバズらせる・ヒットさせる方法論ではなく、あくまでバズらないWebサービスでもさびしく孤独死するのを避けたい…という後ろ向きなハックですのであらかじめご了承ください。

そもそも、なんでWebサービスは死ぬのか

いきなり哲学的な見出しになったけど、もちろん中身は意識低い話です。

Webサービスの死因

完全に私見ですが、「サービスの死」とは以下３つの状態を指します（断言）。

【死因①】ノーコンテンツ

コンテンツがメインの価値になるサイトで、コンテンツが圧倒的に少ない OR あっても全然更新されてないなどで、有用なコンテンツがない（あるように見えない）。

【死因②】動かないシステム

システムのエラーなどで、本来の機能を利用できない状態が放置されている。 （Twitterログインが機能していない、など）

【死因③】サイトの消滅

ドメインが切れてて、そもそもサイトにアクセスできない。サーバを解約して、もう何も動いていない。

狭義には③が完全な死ですが、①と②みたいなサイト見たときも、実質死んでるって判断しますよね。

よくある個人開発サービスの一生

上記の死因を踏まえて、個人開発でよくあるWebサービスの一生は、こんな感じでしょうか。

• サービスリリースしたけど全然使われず、がんばって自分で投稿したりする
• がんばって宣伝したりするけどやっぱり使われず、自分でも投稿しなくなり放置されだす（①ノーコンテンツ）
• ライブラリや連携外部サービスのアップデートに追従しなくなり、サービスが動かなくなる（②動かないシステム）
• ドメイン代がもったいなくて、更新をやめる（③サイトの消滅）

＿人人 人人＿

＞ 突然の死 ＜

￣Y^Y^Y^Y￣

身に覚えがありすぎて、書いてて動悸が激しくなってきた。。

恥を承知でさらすと、わたしのサービスもこんなのばっかりです。

☠失敗例☠ book loves music（ブック・ラブズ・ミュージック）

読書にぴったりの音楽をおすすめし合うサービス。2011年くらいに作ったデビュー作です。 ユーザーが本に合う音楽をセレクトすると、Youtubeのプレイリストとして再生できるというサービスでした。

サイトコンセプトが受けたのか、リリース直後には複数のメディアに掲載されるなどプチバズを経験。 しかし99％のユーザーは投稿されてるコンテンツをざっと見るだけで、誰もコンテンツを投稿したりはしてくれませんでした。

コンテンツがスカスカなので一度来てくれた方もそのまま離脱して戻らず、ますますサイトは過疎化の一途。 結局半年ほどは自分で投稿したりして運用を続けたものの、力尽きてそのまま死を迎えました。 あるある過ぎて泣けてきますね。。

「バズか死か」の二元論を避ける

ここまでWebサービスの死因とよくあるライフサイクルを整理してみました。 このパターンで一番問題なのは、モチベーションが続く間に軌道に乗らないと、ほぼ間違いなく死んでしまうということです。

誰も使わない状態を自分ひとりで支えてるので、モチベーションが尽きると更新も止まり、そのまま上記の死をすべて経験することになってしまうのですね。。 もちろんそれまでにサービスがバズって軌道に乗ればいいのですが、そうならないことも多い。

そしてどんなにテンション高くはじめても、モチベーションはいつか絶対に落ちます（断言）。 波があるのは当然なので、モチベーションが下がってもサービスが死なない設計・運用にしたい。

サービスリリースすると、ついつい「バズか死か」みたいな二元論で考えちゃうことが多いんですけど。 そうじゃなくて、死ににくい設計で長期運用を可能にし、モチベーションの波と付き合いながらのんびりサービスを育てていく。 そんな方法を考えてみるのが、この記事の目的です。

死なないサービスを作る（意識低い）方法論

というわけで死なないサービスを作る方法ですが、大きな死因が3つあったので、これを順番につぶしていけば必然的に死亡率を下げることができますね。さっそく見ていきましょう。

【1】CGMじゃなくてツール型にする

まず一番大きいのがこれです。 死因①の「ノーコンテンツ」はCGMだから起きる問題なので、CGMをやめるだけで大きな死因を１つ減らすことができます。

CGMはむずかしい

ここで「CGM（Consumer Generated Media）」とは

ユーザーの投稿コンテンツがサイトの中心的な価値となるようなサービス

のことを指します。 例は多すぎて不要かと思いますが、TwitterとかCookpadなんかが有名どころですかね。

CGMはコンテンツが集まると圧倒的な価値が出るのですが、最初のコンテンツ集めが難しかったりします。 コンテンツがないから人が集まらず、人が集まらないからコンテンツも増えないという「ニワトリ🐔・タマゴ🐣」問題ですね。

※もちろんCGMをうまく回す方法論もあるわけですが、それができる人はそもそもこんな記事読まないでしょうし、ここではあくまで意識低い方法を考えます。

ツール型にしたらいいじゃない

というわけで意識低い解決策としておすすめなのが、「ツール型」のサービスにすることです。 ここでツール型とは

他のユーザーが誰も使っていなくても価値を提供できるサービス

と定義してみます。

💡具体例💡 THE TOURNAMENT（ザ・トーナメント）

Web上で簡単にきれいなトーナメント表が作れるという超絶地味なサービスです。 4年前にリリースしてから一度もバズったことはないですが、検索で着々と利用者数を増やし、現在では有料の法人利用も増えてきています（感謝）。

このトーナメントは典型的なツール型で、最初の2年くらいはごく少数の方に細々使われる程度でした。 しかし誰も使っていなくてもサイトの有用性に影響はないため、時間をかけてゆっくり検索流入が増えるのを待つことができました。

CGMだと寂れるとますます寂れるという負のループが働いてしまうわけですが、ツール型はその心配がありません。 またサイトが育つまでほぼ放置していただけなので、その間は他のサービスの開発に時間を使うことができました。

SLOT777 : Links Situs Slot Online Apk Daftar Agen Slot Gacor Hari Ini Pasti JOKIJP

SLOT777 Merupakan salah satu partner kolaborasi bersama jokijp yang merupakan salah satu situs resmi terpercaya hingga saat ini dengan berbagai ragam permainan gacor 777 lainnya.

the-tournament.jp↗

SNS連携型もあるよ

また純粋なツール型とはちょっと違うタイプとして、質問箱からブームが続く「SNS連携型サービス」もあります。 これも他のユーザーがいなくても価値を提供できるタイプのサービスですね。

ウェブ表彰 | 気軽に誰かを称賛しよう

ウェブ表彰は手軽に表彰状を作成出来るサービスです。スゴいと思ったものや頑張ってる人を気軽に褒め称えましょう。

hyou.show↗

最近大流行したウェブ表彰。やさしいインターネットを作る世界観がとても好きです。

このタイプのサービスについては、質問箱を開発したせせりさんのこんな記事もあります。

こちらでも同じように「ひとりから使えること」の重要性を指摘されてますね。 このSNS連携型だと、作ったコンテンツが拡散力を持ちやすいという点で、純粋なツール型より爆発力があります。

（補足）ツール型の弱点

とりあえずCGMをやめることで「ノーコンテンツ」による即死は避けれるわけですが、ツール型にも弱点があります。

まず純粋なツール型は、集客が弱くなりがちです。 トーナメント作成サービスとか見てもらうとわかりますが、バズる要素はまったくないですねw

基本的にツール型は検索流入を地道に拾うのがメインになります。 時間がかかるし爆発力もないですが、検索流入を取れればその後は安定したアクセスを期待できます。

またSNS連携型の方は拡散力がすごいのですが、初速で火がつくまで至らなかったときや、いったんブームが落ち着いて誰も使わなくなったときに、再度盛り返すのが難しいんじゃないかなーという気がしてます（作ったことないから知らんけど）。

マシュマロさんくらい常時使われる状態になれば、永遠にバズって新規開拓を繰り返せそうですが。。

トーナメントは検索以外にも工夫した結果、多いときで月間150万PVくらいまで伸びてきました。 ツール型をどうやって成長させるかは、長くなるのでまたそのうち改めて整理できたらいいなと。 （いまも試行錯誤中ですが。。）

【2】できるだけ何も作らない

2つ目の死因は「動かないシステム」でした。

放置したシステムが動かなくなる危険性は、定期的にやってきます。 Twitterログインの仕様が変わる、使っている言語やフレームワークのバージョンがサポートされなくなる、など。。

生きているサービスはこれらの波を乗り越えて寿命を延ばし続けるわけですが、どこかで開発者がこの対応を諦めると、そこでシステムとして死ぬことになります。

めんどくささ vs モチベーション

この対応あきらめるかどうかの判断をとても頭が悪い式で整理すると、

対応あきらめるとき　=>　モチベーション　＜　対応のめんどくささ

となります。式にする必要あった？

ユーザーにすごく使われてる、売上が上がってるとかだと、問題が起きてもちゃんと対応しますよね。 そうじゃなくてもサービスつくった直後で気合が入ってるときなら、むざむざシステムの致命的なバグを放置しないと思います。

問題はリリースからしばらく経ったのにサービスが伸びてなくて、それでもメンテナンスに工数を取られるという状態です。 2年前に作って誰にも使われず放置してるサービスでRailsのメジャーバージョンアップしなきゃってなったら、やりたくないですよね。 （それなら最初から新バージョンで新しいサービス作りたいw）

作らなければ壊れない

この問題を完全に防ぐのは難しいのですが、ある程度対策することはできます。

まず前提として、モチベーションに期待するのはやめて、工数＝めんどくささを減らす方向で考えます。 障害はいつ来るかわからないのに、何年もモチベーション保ち続けるとかはだいぶしんどいです。

じゃあどうやって致命的な問題の発生頻度を減らすかっていうと、一番いいのは「極力何も作らない」こと。意識低い。。

💡具体例💡 ブンゴウメール

青空文庫の名作小説を1ヶ月で読み切れるように小分けして、毎日少しずつメールで配信してくれるサービスです。

ありがたいことにリリース後にTwitterで大きな反響をいただき、メディアなどにも多数取り上げていただきました。

作ってるときはちゃんと使われる自信なんて全然なかったのですが、自分がほしいサービスだったので、仮に流行らなくても長く使い続けられるよう極限までシンプルな作りにしています。

その結果、リリース時はフレームワークなど何も使わない、わずか150行のRubyスクリプトになりました。 ローカルで実行すると、指定した作品を分割して1ヶ月分予約配信するというだけの超ミニマムプロダクトです。

ここまで小さいと滅多に不具合も出ないし、仮に何かあってもすぐに直せます。 いわゆるMVP（Minimal Variable Product）という考え方ですが、MVPの状態で長期運用できるように設計しておくと、芽が出るまで放置して育てることができますね。

【3】絶対に赤字にはしない

3つ目の死因は「サイトの消滅」でした。 これはドメイン切れやサーバの契約解除など、どちらもお金の問題が関わってきます。

いまは小規模な個人サービスで大きな赤字が出ることはないと思いますが、たとえ小さくても赤字の状態だと、どこかで支払うのをやめちゃう恐れがあります（経験あり）。

というわけでこれに対する対応はシンプルで、「絶対に赤字にしない」ことです。

サブドメインからはじめる

びっくりするくらい小さい話ですが、大事なところです。 これによってドメイン切れによる死を事実上なくすことができます。

ドメイン死で一番多いパターンは、ドメイン取得してサービス作って、全然使われなかったので1年後の更新をせずにそのまま終了、というやつですよね（何回もやった）。

サービスをサブドメインで始めることで、この悲劇は簡単に避けることができます。 自動更新してずっと使う主要ドメインを持って、新規サービスはそのサブドメインを使えばいいですね。

最初にかっこいいドメインを取ってテンションを上げる「ドメイン駆動型」開発も好きですが、長生きさせたいならサブドメインから始めてもいいんじゃないかなと思いますよ。

順調に育ってきたら、あとから独自ドメインにしたらいいですからね（逆はむずかしい）。

💡具体例💡 スマホde百人一首

スマホde百人一首

スマホde百人一首は、みんなのスマホを取り札にして遊べる、 お正月にぴったりの百人一首サービスです。

karta.notsobad.jp↗

みんなのスマホを百人一首の取り札にして遊べるサービスです。お正月にでもぜひどうぞ🎍

独自ドメイン取ってたら絶対更新してなかったであろうこんな一発ネタサイトも、サブドメインにしてるおかげでいまだに動いています。（自己紹介でのウケはいいです）

作ってから4年以上放置してるし今後も改修の予定はありませんが、少なくともドメイン切れの心配はありません。 毎年ドメインを更新するかどうかで悩むことがないのはとても快適ですね。

サーバももちろん無料で

こちらも大事。 月数百円程度のサーバ代でも、数年前に作ってまったく使われてないサービスのためだけに払ってたりすると、そのうち解約したくなる日が来たりします。

わたしはHerokuやFirebaseを使うことが多いですが、他にも無料プランで使えるサービスも多いと思うので、ぜひ無料で始めましょう。 無料プランでも工夫すればけっこうな規模まで対応できます。

とはいえいまはFirebaseが尋常じゃなく便利なのでおすすめですよ。みんなFirebase使おう！

💡具体例💡 ゾラサーチ

ブンゴウサーチ | 青空文庫の作品を読了時間で検索できるサービス

ブンゴウサーチは、青空文庫の作品を目安の読了時間で検索できるサービスです。

search.bungomail.com↗

青空文庫の作品を目安の読了時間で検索できるサービスです。前述のブンゴウメールの姉妹サービスとして作りました。

ブンゴウメールは超ミニマムプロダクトとしてリリースしたのですが、ありがたいことにユーザー数と機能要望も増えたため、その後Railsアプリとしてリニューアルしていました。 その過程で青空文庫データが大量に蓄積されたので、それを活用しつつまたもや自分がほしかったサービスを作った感じです。

しかし極力管理の手間は増やしたくなかったので、このゾラサーチはブンゴウメールのRailsアプリにControllerを1つ追加することで実現しています。なんという省エネ。。

サーバももちろん相乗りする形になっているので、追加の費用はかかっていません。 ゾラサーチは売上のないサービスですが、この設計なら赤字にはならないので、サービスを閉じるか悩む必要がありませんね。

注意と言い訳

死なないだけだと、ただのゾンビ👻

というわけで、3つの死因を（ある程度）避ける方法を見てきました。 でもこれだけだと、確かに死んではいないけど、成功してるわけでもありません。

死因のところにも書きましたが、この記事で本当に目指したかったことは、リリースしてすぐに「バズか死か」の二択になってしまう状況を避け、長期的にサービスを成長させる体制を作ることでした。

死なないだけだとただのゾンビです。 目前の死を先送りにできたら、改めてサービスを成長させる方法を考えてみましょう（丸投げ）。

最後は確率論なので、いっぱい作ろう😇

また、サービスを延命させることで成長させるチャンスを増やせますが、 どんなに延命しても伸びないサービスは伸びません（かなしい）。

これについてはもう散々言われてるように、いっぱい作るしかないと思います。 とはいえスクラップ＆ビルドの繰り返しだと「バズか死か」に逆戻りなので、「ビルド＆ゾンビ」で長寿サービスをいくつも作って、じっくり芽が出るように育てるといいんじゃないですかね。

前述の「ブンゴウメール」はありがたいことにかなり反響をいただいたのですが、実はこれ、2年前に一度リリースしたときは鳴かず飛ばずだったのです。。

前とはコンセプトを変えたとか、文豪系ゲームが増えて意外な反響があったとか、、、色んな要因があるんでしょうが、要は「わからん」と。

最後は確率論なので、あきらめずにいっぱい作りましょう（自戒も込めて）。

まとめ

思うところがありすぎて、ずいぶん長い記事になってしまいました。。 最後までお付き合いありがとうございます。

まぁ好みが分かれるところではあると思うのですが、こんなやり方もあるよということで誰かの参考になればうれしいです。

おしまい。