【22の失敗例】マッチングサイト構築・新規サービス開発で失敗する原因と解決策、完全保存版

マレントのチーフエンジニアの宮崎と申します。

今日は、最近案件が多いため少しセンシティブな内容ですが、
構築・開発を考えている企業様にとっては重要なことと思い、無礼を承知で本気で助言させていただきたく書いております。

不躾な内容や表現もございますが、どうかお許しください。

新規サービスやマッチングサイトが失敗する理由は、開発技術が足りなかったわけではありません。
検討段階から失敗がはじまっていることが多いです。

企画、料金設計、集客、運営体制、開発会社の選定など、システムを作る前後の判断によって、公開する前から結末がほぼ決まっていることもあります。
ここでは、実際の新規サービスやマッチングサイトの相談で起きやすい失敗を、事業設計、資金、開発、運営、撤退判断に分けて紹介します。

事業設計の段階で起きる大きな失敗

1．そもそも顧客が本当に困っていない

競合との差別化や必要な機能を考える前に、まず確認しなければならないことがあります。そのサービスが解決しようとしている問題に、顧客は本当に困っているのかということです。

「まだうちの業界や分野にはマッチングサイトがない」「なんかやってみたくなった」という理由だけで、検討を始めるケースは少なくありません。

しかし、そもそも解決するほどの課題が存在しないことがあります。ユーザーが現在、特に大きな不満もなく問題を解決できているのであれば、新しいサービスへ移る理由はないのですが、そもそもがその声を聞くユーザーがいなかったりするのも問題ですが…

作る側には古くて非効率に見える方法でも、ユーザーからすれば、慣れていて特に困っていない方法です。新しいサービスを使うには、会員登録、プロフィール入力、操作方法の理解、場合によっては社内承認や支払方法の変更まで必要になります。今の方法より少し便利という程度では、その面倒を超えられません。

また、事前ヒアリングで「便利ですね」「完成したら使いたいです」と言われても、目の前で熱心に説明している相手へ、わざわざ「そんなものは使いません」と言う人は少ないからです。

本当に見るべきなのは、実際に会員登録するか、案件や商品情報を提供するか、面談を予約するか、申込書を書くか、お金を払うかです。

顧客が困っていると思っているのがサービスを作りたい側だけなら、どれだけ立派なシステムを作っても使われません。

2．最初から機能を作りすぎる

新規サービスの相談では、最初から機能を作りすぎるケースが非常に多くあります。ポイント、クーポン、AIレコメンドなど、「あった方がよい」と思った機能を次々と追加していきます。

しかし、実際には必要性を検証した機能ではなく、社長や担当者が一度やってみたかった機能を詰め込んでいるだけの場合も実際多いです。

結果として、市場に向けて作るはずだったサービスが、いつの間にか社長や担当者の独自サービスになってしまいます。いつのまにか、ユーザーが欲しいものではなく、自社が作りたいものを作ってしまっていることもあるあるです。

新規サービスで最初に確認すべきなのは、「この機能があれば便利か」ではありません。その機能がなければ、取引やサービスそのものが成立しないのかで判断する必要があります。

3．サービスが複雑すぎる

最初から機能を作りすぎる話ともつながりますが、サービスそのものが複雑になりすぎるケースもよくあります。

「これもできるようにしたい」「この場合にも対応したい」「将来的に必要になるかもしれない」と要望を足し続けた結果、ただただ使い方の分からないサービスが完成します。いわば、社長や担当者がやりたいことだけを詰め込んだ『自己満サービス』になってしまっていることもよくあることです。

作っている側は何か月も仕様を見続けているため理解できますが、初めて訪れたユーザーは同じ熱量でサービスを見ていません。ユーザーはサービスを勉強したいのではなく、自分の問題を早く解決したいだけです。

実際には、サービス構成は最初はシンプルに、
徐々に既存客のみで回していくため、機能を慎重に追加していくのが正解です。

作る側が30分かけて説明しなければ良さが伝わらないサービスを、ユーザーが自力で理解して使い続けてくれると考えるのは無理があります。

作る側の熱量と使う側の温度差を無視し、複雑な操作や長い説明を押し付ければ、当然使われずにサービスは死にます。

4．片側だけ集めても成立しない。ロールが増えるほど難易度も上がる

マッチングサイトは、サービス・商品を提供する側と受ける側の2つの登場人物が必要です。
この役割をロールといいます。

対象となる複数のロールを同じサービス内へ入れなければ成立しません。
受注者を1,000人集めても、案件を出す発注者がいなければ仕事は発生しません。
反対に、発注者がいても条件に合う受注者がいなければ、依頼したユーザーは二度と戻ってきません。

重要なのは総会員数ではありません。同じ地域、同じカテゴリ、同じ時期、同じ価格帯で、実際に取引できる両側のユーザーがどれだけいるかです。

さらに、ロールが増えるほど難易度は一気に上がります。
たとえば、Uber Eatsのようなフードデリバリーは、マッチングサービス業界では最難関で新規参入はかなりの博打です。
注文するユーザー、商品を提供する飲食店、配達するドライバーという3つのロールを同時に成立させなければなりません。

注文者がいても加盟店がなければ使われず、加盟店がいても配達員がいなければ届けられません。
配達員を集めても注文がなければ報酬が発生せず、すぐに離脱します。

ロールが一つ増えるということは、画面が少し増えるという話ではありません。会員登録、権限、マイページ、報酬、決済、通知、キャンセル、管理画面、トラブル対応まで、それぞれ別に設計する必要があります。

ロールが一つ増えるたびに、事業がもう一つ増えるくらいの負担になると考えた方がよいでしょう。

5．競合が多いのに、サービスを選ぶ理由が薄いかあまりない

すでに競合が大量に参入している市場へ、特にコアもないまま参入するサービスも多くあります。
つまりあなたのサービスをわざわざ使う理由がないのです。

サイトを見ても、何がほかのサービスと違うのか、なぜ後発サービスを使う必要があるのか、誰に特に向いているのかが分かりません。

ここでよく起きるのが、対象を広げれば利用者も増えるという勘違いです。「法人も個人も使える」「全国・全業種に対応する」「発注にも受注にも使える」と広げた結果、誰のどの問題を解決するサービスなのか分からなくなります。

建設会社と映像制作会社では、案件項目も選定基準も契約方法も違います。法人発注者と一般消費者では、必要な信用、決済方法、問い合わせ導線も異なります。

それらを一つにまとめるほど、登録項目、検索条件、料金体系、説明文が増え、サービスそのものが複雑になります。市場を広げたつもりが、実際にはサービスのコアを薄めているのです。

「手数料が少し安い」「画面が新しい」「AIを使っている」といった程度では、既存サービスからユーザーは動きません。ユーザーからすれば、すでに会員や案件が多く、実績も信用もある既存サービスを使えばよいからです。

全員に使ってもらおうとした結果、誰にも選ばれない後発サービスになります。

競合が多い市場へ参入すること自体が悪いわけではありません。問題は、既存サービスからユーザーを動かすだけの明確なコアがないことです。違いの分からない後発サービスは、比較された時点で死にます。

6．他社が入れているので、同じ機能が必要だと思い込む

「〇〇のようなサービスを作りたい」という相談は多いものの、実際に話を聞いてみると、その競合サービスについて具体的にはあまり理解していないことがあります。

見えている画面や機能だけを見て、「同じものを作れば同じように成功できる」と考えているのです。

これは、よく分からないがディズニーランドを作りたいので、とりあえず見積もりをよこせと言っているようなものです。

ディズニーランドの建物やアトラクションの形だけを再現しても、ブランド、キャラクター、運営力、集客力、資金力まで再現できるわけではありません。

そもそも他社と同じサービスを作り、2つ並べた時点で、新規サービス側はすでに負けています。これを覆せるのは、大量の既存顧客を持っている企業や、圧倒的な資本を投入できる企業くらいです。

競合の画面はコピーできても、競合が何年もかけて作った信用、顧客、運用体制まではコピーできません。

7．どうでもよい機能や仕様に固執する

社長や担当者がどうしても付けたいと言った機能を、時間と費用をかけて実装します。ところが公開後、ほとんど使われません。

その後ユーザーへアンケートを取ると、実際に必要とされていた機能とは、まったく見当違いだったことが判明します。よくある話です。

作る側は、機能単体を見て「便利そう」と判断します。
しかしユーザーは、機能の数ではなく、自分の目的をどれだけ早く達成できるかでサービスを評価します。

社内会議で何度も議論した機能だからといって、利用者に必要とは限りません。

ユーザーが欲しい機能より社長が欲しい機能を優先した時点で、サービスは市場から離れていきます。

8．無料にすれば使ってもらえると思っている

新規サービスでは、とりあえず無料プランを作ろうとするケースが多くあります。

しかし、ユーザーはそこまで馬鹿でも暇でもありません。
無料だからという理由だけで会員登録し、プロフィールを入力し、何度もログインし、継続して使うわけではありません。

無料でも必要のないサービスは使われません。

むしろ無料ユーザーばかりを集めると、登録だけして利用しない、メッセージへ返信しない、プロフィールを更新しない、サポートだけ要求するといった問題も起こります。

もちろん、サービスを体験してもらう、供給側を先に集める、有料機能へつなげるなど、明確な目的を持って無料プランを設計するなら問題ありません。
しかし、「一応、無料プランもあった方がよいと思って」という程度で、無料にする意味を説明できないのであれば、やめた方がよいでしょう。

9．一回しか使わないサービスなのに、月額課金にしたがる

経営者は継続的な売上が欲しいため、何でも月額課金（サブスク）にしたがります。
「ざぶとん商売（ビジネス）」とよく言いますが、これがやりたいがためにサービス始める人もいます。

しかし、そもそもユーザーが一回しか使わないサービスもあります。
引っ越し、結婚式、事業承継、大型工事、専門家探しなど、利用頻度が低いサービスで毎月料金を取ろうとしても、利用が終われば解約されるのは当然です。

年に一度しか利用しないユーザーへ、「毎月5,000円払ってください」と言っても普通は払いません。

月額課金が成立するのは、毎月継続的に価値が発生する場合です。サービス提供側が安定収益を欲しいからという理由で、ユーザーへサブスクリプションを押し付けてはいけません。

料金モデルは、自社がどう儲けたいかではなく、ユーザーがどの瞬間に価値を感じるかに合わせる必要があります。

資金と集客で起きる失敗

10．ばら撒き金がないのに、サービスを始める

新規サービスは、「サービスを始めました」と告知するだけでは広がりません。
大きく成長しているサービスは必ずと言っていいほど、ばら撒き金を用意しています。
ばら撒き金の事例でいうと、メルカリ、アキッパ、ココナラ、LUUP、Go、Uber、PayPay… もう数え切れません。

サービスは「初動が一番大切である」ことを彼らは知っています。
短期間で利用者を集めたサービスを見ると、最初に分かりやすいばら撒き金を用意しています。

• 登録キャンペーン
• 初回無料
• ポイント付与
• 出品手数料無料
• 招待報酬
• 初回取引保証
• 広告出稿

ここを用意できないのが、日本の新規サービスに多い特徴でもあります。
「登録無料」「掲載無料」というところで止まっていますが、無料はユーザーにとって得ではありません。単に支払いがないだけです。

ユーザーが時間を使って登録し、今までの方法を変えてまで利用するには、最初の明確な動機が必要です。
サービスのローンチ時は、最も注目を集めやすいゴールデンタイムです。
その初動で宣伝費もキャンペーン費も出せず、誰にも使われないまま終わります。

別にそこまで目指していないケースもあるでしょう。
中途半端なサービスは埋もれていずれ死にます。

いずれにせよ、サービス開始時点の初動ですでにサービスは死んでいるのです。

11．開発費で資金を使い切り、宣伝費が残っていない

初手のシステム開発に資金をすべて使い切り、完成した時点で宣伝費が残っていないケースも多くあります。

立派なシステムは完成しました。
大変満足です。
しかし、広告を出せない、営業担当者を置けない、キャンペーンもできない、コンテンツも作れない、ユーザーサポートも雇えない状態です。

この時点で、ままごとサービス確定です。

サービスは作っただけでは利用されません。
むしろ、完成後にユーザーを集め、取引を成立させ、問い合わせやトラブルへ対応し、改善を続ける方が金も時間もかかります。

システム開発費だけを事業予算だと思っている時点で、予算設計を間違えています。

12．補助金で始めた案件は、大体死ぬ

補助金を使ったサービスが、すべて失敗するわけではありません。
しかし、補助金をきっかけに始めたサービスが死にやすいのには、心理的にも経済的にも理由があります。

本来であれば自己資金を出してまで始めないアイデアでも、「ちょっとやってみたい」「補助金がある！！」となると、一気に始めるハードルが下がります。

自分で負担する金額が少なく見えることで、事業判断が甘くなります。
これは、損失の一部を外部へ移転することで判断が緩くなる、モラルハザードに近い状態です。

ローンチが2024年で1年後にはサービスが終了しています

補助金でマッチングサイトを構築し失敗した事例

さらに、補助金の申請期限に合わせて計画を作るため、本来の順番が逆になります。

本来の順番は、需要を検証する、事業計画を作る、資金を用意する、です。

ところが補助金ありきになると、補助金を見つける、締切までに事業計画を書く、とりあえずサービスを作る、という流れになります。

採択されると、「国や審査機関に認められた事業だから、うまくいくのではないか」という錯覚も生まれます。しかし、書類審査に通ることと、ユーザーがお金を払うことはまったく別です。

申請準備に予想以上の時間がかかり、採択されるか分からない段階で、書類代行会社へ数十万円を支払うこともあります。申請から入金まで半年から1年かかる場合もあり、それでも受かる保証はありません。

制度や交付条件によっては、途中でやめると返還や手続きの問題が生じる可能性もあります。その結果、すでに死んでいるサービスを仕方なく続けることになります。

サウナ事業を補助金でやったケースと同じです。
サウナも一時期、補助金で作ったものの赤字だけど、補助金の返還と天秤にかけてやむなく続けている赤字続きのサウナが多くなり、市場にはサウナ事業のM&Aが出回っています。

これは、使った時間や金を無駄にしたくないサンクコストと、損失を確定したくない損失回避が合わさった状態です。

IT導入補助金全盛期のときにやっておけばよかった、という話は別として、そもそも血税です。
法人の補助金あるあるですが、補助金を取りにいことが醍醐味になっているケースも多く、完全に間違っています。
あるのだから使わないと損？
そうですね、しかし失敗する可能性が高いものかどうかは見極めが必要です。
それを認可した行政にも問題があるといえます。

補助金を使うなとはいいませんが、その事業が成功する確率は下がった状態でスタートするのは間違いなく、補助金があるから始める程度のサービスなら、最初からやめた方がよいでしょう。

SaaS・システム開発で起きる失敗

13．SaaSで始めた結果、失敗したら何も残らなかった

SaaSは初期費用を抑えやすく、始めやすい方法の一つです。
しかし、新規サービスがうまくいくか分からない状態では、毎月のランニングコストが次第に重く見えてきます。

売上がないのに、毎月数万円から数十万円が引き落とされます。
すると、「まだ利用者もいないし、一度止めよう」「このまま支払い続けるのは厳しい」となり、サービスを断念します。

しかし、SaaSを解約すればシステム自体も残りません。
それまでかけた費用も、設定した内容も、場合によっては蓄積したデータも、全部パーなわけです。
（パッケージといいつつ、月額が最後に発生しますと小さく書かれているサービスもあります）

失敗したときに支払いを止められるというメリットはあります。
その一方で、何も資産として残らないという現実も理解しておく必要があります。
システムは基本パッケージかスクラッチですが、スクラッチだと一からになるので、現在はパッケージ＋AI開発でCursorなどでカスタマイズしていくのがベストな開発方法です。

14．SaaSが駄目な本当の理由は、成功しても地獄だからである

SaaSの問題は、サービスが失敗した場合だけではありません。
むしろ、うまくいった場合にも地獄が待っています。

表面的な機能だけなら、SaaSでもそれなりのサービスを作れます。
しかし、利用者が増えれば、アクセス負荷、データ量、検索速度、画像容量、メッセージ数、決済処理、セキュリティ、障害監視など、インフラの問題が出てきます。

あなたのサービスが万人規模になったとき、SaaSの制約や料金体系に耐えられるでしょうか。

毎月のコストは上がっているのに、売り上げが吸い取られて利益があまりでない…
どうしたものかとなります。

多くの場合、どこかで独自システムへのリプレイス（作り替え）を考えることになります。
しかしリプレイスするには、現在使っている機能と同じものを、別のシステムでもう一度作らなければなりません。

新機能を作る前に、今ある機能を再現するだけでお金がかかります。
さらに、既存システムの要件を整理し直し、開発会社から見積もりを取り、会員データ、画像、メッセージ、決済情報、パスワードを移行できるかまで確認する必要があります。
正直にいうと、システムのリプレイス案件はシステム会社は嫌がります。
成功よりあらゆる失敗リスクの方が高いからで、新規サービスつくるほうがはるかにやりやすいです。

失敗すれば何も残らず、成功すれば大規模な入れ替えが待っている。

最初からこの問題を避けるなら、やはりパッケージかスクラッチ開発になります。
そのなかでも、始めやすいのは「パッケージ＋AI開発で部分カスタマイズ」でしょう。

15．最初の1～2回の打ち合わせで、何となく良さそうだから発注する

マッチングサイト構築は、難易度が高いシステム開発の一つです。

それにもかかわらず、「価格が安かった」「話しやすかった」「何となくいい感じにしてくれそうだった」という理由で、最初の1～2回の打ち合わせだけでその気になり、発注するケースがあります。

そして死にます。
これはザラにあります。

マッチングサイトでは、会員種別、権限、検索条件、メッセージ、決済、手数料、キャンセル、返金、評価、管理画面など、事前に整理すべきことが大量にあります。
「いい感じに作ってください」で完成するほど簡単ではありません。

ただし、半年や1年かけて検討すればよいわけでもありません。
始めると決めたのであれば、自分や自社のモチベーションを維持する意味でも、開発は短期で決着をつけるべきです。

半年、1年と寝かせ続ける程の案件なら、大企業であってもいますぐやめた方がよいでしょう。
長期間検討している時点で、担当者はリスキーなのが薄々見えているからです。

逆にうまくいく案件というのは、すべての問題がクリアになって、ピースがバチッ！としっかりトントン拍子で進んでいくときです。少しでも気にする部分があるのであれば、やめた方がよいでしょう。

勢いだけで発注することも、決断できないまま延々と検討することも、同じくらい駄目です。

16．完璧なシステムを作ろうとする

完璧なシステムはありません。完璧なサービスもありません。

この世に「あなた」という人間が一人しかいないのと同じで、完全に同じ条件、同じ要望、同じ使い方をするユーザーはいません。すべてのユーザー、すべての例外、すべての将来構想へ対応しようとすれば、いつまでたっても公開できません。

公開して初めて分かることもあります。
ユーザーがどこで離脱するか、どの機能が使われないか、どの問い合わせが多いかは、実際に運営しなければ見えません。

完璧にしてから出すのではなく、致命的な問題がない状態で出し、運営しながら改善するしかありません。

17．デザインに凝りすぎる

前提として、ある程度のレイアウトやUIは必要です。
使い方が分からない、文字が読めない、スマートフォンで操作できない状態では困ります。

しかし、最初からフルデザインをデザイン会社へ依頼し、それを一からコーディングで組み込む必要があるかは別問題です。

実は業界ではあまり言われませんが、オリジナルデザインの組み込みは、どの会社もかなり費用がかかる部分の一つです。

デザイン制作費だけでなく、各画面のコーディング、スマートフォン対応、細かなズレの調整、修正対応に工数がかかります。

果たして、立ち上げ初期からそこまでデザインに凝る必要があるのでしょうか。

たとえば、有名アーティストがあなたのサイトでしか購入できない限定チケットを販売したとします。
購入者は、デザインが5pxずれていることや、微妙なレイアウトの違い、フォントの細かな違いを気にするでしょうか。

答えはNOです。
そこでしか買えない商品があるなら、ユーザーは買います。
マッチングサイトやECサイトは、商品、案件、出品者、提供サービスが多いほど、それなりに動いているサービスに見えます。

今すぐそのテスト商品を消して、実際の商品を100個しっかりいれてみてください。
自ずとあなたのサービスになっていきます。

デザインを磨くことばかりに金を使うより、あなたのサービスで取り扱う中身を集めることに注力してください。

運営・規制・信頼で起きる失敗

18．サイト内の規制に目を向けすぎて詰む

新規マッチングサイトでは、「ユーザー同士がサイト内で知り合い、外部で直接取引されたら困る」という相談も多くあります。

そのため、電話番号を送れないようにしたい、メールアドレスを検知したい、URLを禁止したい、メッセージをすべて監視したいという話になります。

しかし、弊社の運用経験上、意外と外部取引ばかりが起きるわけではありません。
もちろん一定数そういったユーザーは存在しますが、そういう利用者を大切な顧客として見ない方がよい場合もあります。

サービスへ入れてもすぐに抜け、手数料も払わず、トラブルだけ起こす可能性が高いからです。

経験が少ないと、最初からすべての抜け道を塞ごうとします。
しかし、不正利用者を止めるために正常なユーザーまで使いにくくすれば、サービス全体の成約率が落ちます。
これは社会の構図とちょっとにています。

ではどうするのか。
不正ユーザーは締め出すのみです。
だからマレントでは標準機能として、強制退会や停止機能などを盛り込んでいます。

外部取引だけでサービスが崩壊するのであれば、大手のマッチングサービスは存続できていません。

外部取引を完全に止めることより、決済保証、履歴保存、トラブル対応など、サイト内に残る理由を作る方が重要です。

19．トラブル時の負担を、すべてユーザー責任にする

多くの新規サービスは資金がないため、あるいは想定していない、トラブルが起きても費用を負担できず、利用規約へ「当社は一切責任を負いません」「当事者間で解決してください」と入れがちです。

法的な免責がどこまで認められるかという話以前に、ユーザーがそんなあなたのサービスを長く使いたいかという問題があります。

手数料は取る。月額料金も取る。
しかし、何か起きたときは一切関与しない。
それでは、ユーザーから見れば高いだけの無責任なサービスです。

資金力のある大手サービスでは、ローンチ初期に返金や補償の負担を運営側が吸収し、先に信用を作ることもあります。
たとえばメルカリです。

メルカリでは事務局処理という取引処理があります。
これは両方のユーザーが折り合いがつかないとき、事務局（運営）が間を取りもって、両方に報酬を与え、返金などもするという対応をとります。
最近では少し厳しくなったようですが、昔はUXを根づけようとかなり寛容な処理をしていました。

アマゾンも同じことが言えます。
寛容な返品処理のおかげで、ユーザーは安心な購買ができアマゾンの考える「短期間の反復購買」をさせています。

（アマゾンは想像以上に賢い運営なので、またの機会に深掘りして記事をかきたいと思います）

では、あなたの会社はどうするのでしょうか？

どこまで補償できるのか。どこから対応できないのか。トラブル時に誰が判断するのか。
ここを決めずに、利用規約だけで責任を切り離そうとしても、長く使われるサービスにはなりません。

20．リーガル関連を確認せずに始める

サービスの仕組みだけを先に考え、法律関係を後回しにするケースも危険です。

特に、ポイント、売上金、預かり金、チャージ残高、出金、送金、エスクローに近い仕組みを扱う場合は、資金決済法をはじめとした規制の確認が必要になる可能性があります。

「ほかのサービスもやっているから大丈夫だろう」では済みません。
各サービスによって法務ロジックが異なります。
あなたのサービスには当てはまりません。

公開直前や、すでに開発費を使った後に「この仕組みでは運営できません」と判明すれば、決済やポイントの設計から作り直しになります。
業種によっては、職業安定法、古物営業法、旅行業法、宅地建物取引業法など、別の規制が関係する場合もあります。

リーガル確認は、最後に利用規約を作る作業ではありません。そもそもそのビジネスモデルを実行してよいのか、開発前に確認する作業です。

※残念ながら多くのシステム会社は弁護士事務所ではないので、サービス法務はかならず弁護士の先生へ聞いた方が良いです。

撤退判断で起きる失敗

21．撤退基準を決めていない

新規サービスを始めるときは、売上目標や会員登録数を決めます。
しかし、どの状態になったらやめるのかは決めていません。

そのため、利用者が増えなくても、「次の機能を追加すれば変わるかもしれない」「広告を増やせば認知されるかもしれない」「アプリ化すれば伸びるかもしれない」と追加投資を繰り返します。

本来は事業モデルに問題があるかもしれないのに、機能不足や広告不足の問題へ置き換えてしまうのです。

人は、すでに使った金や時間を無駄にしたくありません。
500万円使ったあとに成果が出なければ、「ここでやめたら500万円が無駄になる」と考えます。

さらに200万円を追加し、それでも成果が出なければ、「ここまで700万円使ったのだから、あと少し続けよう」となります。
これは典型的なサンクコストと呼ばれる心理現象です。

すでに使った金は、今後続けるかどうかの判断材料にはなりません。
見るべきなのは、これから追加する金と時間に対して、成果が出る可能性があるかです。

開始前に、何か月検証するのか、何件の取引が必要なのか、追加投資の上限はいくらか、どの仮説が否定されたら方向転換するのか、どの状態になったら完全撤退するのかを決めておく必要があります。

改善しているのか、死んでいるサービスを延命しているだけなのかは別の話です。

やめる基準がないサービスは、成功するまで続けられるのではありません。金が尽きるまでやめられないのです。

最も多い失敗

22．作って終わりで満足する

システム開発あるあるですが、作って終わり、運用せずに終了するパターンが一番多いと思います。

ホームページ制作は作ってもらって満足でそれでもいいと思います。
すでに24時間宣伝してくれるサイトが仕上がっているのですから。
（制作会社は運用が大事！といいそうですが笑）

システム開発中は定期的に打ち合わせを行い、社内でも盛り上がります。
紆余曲折を経て、完成してローンチした瞬間、社長や担当者は満足します。

そして本業へ戻ります。
サービスはできたのに後回しです。

広告は出さない。営業もしない。登録者にも連絡しない。数字も見ない。改善もしない。
作って稼ぐぞモードから、作って満足モードに、なぜかきりかわるわけです。

心理としてはわかります。
走り切ったランナーに山に登れと言っているようなものですから。

結果、立派なシステムだけが残り、サービスは動きません。

本業の息抜きとして、一度作ってみたかったサービスを形にしただけなら、それはそれでよいでしょう。
しかし、事業として成功させるつもりだったのであれば、本当にやりたかったのかと疑う案件もたまにあります。

システムを作ることは、新規サービスのゴールではありません。むしろ、そこからがスタートです。

根本的に一番多い失敗

結局、多くの新規サービスは、開発力や技術力が足りないから死ぬのではありません。

運営する覚悟や資金も、集客へ使う金も、改善を続ける体制もないまま、先にシステムだけ作ってしまうから死にます。

システムを購入すると、事業そのものまで手に入れたような感覚になります。
しかし、どの開発会社からも納品されるのは、会員登録、検索、決済、チャットなどのマッチングが動く仕組みだけです。

たとえるなら、納品されるのは百貨店の建物と設備であって、売り上げではありません。
会員登録や決済は、レジやエレベーター、売り場を動かすための設備にすぎません。

魅力のある商品をそろえ、出店者や販売員を集め、お客を呼び込み、売り場を回し、苦情や返品に対応し、売れ行きを見ながら品ぞろえや売り場を変え続けるのは、サービスを運営する側です。

百貨店が完成した日に記念写真を撮り、そのまま商品も店員もお客も入れなければ、売り上げが立つことはありません。
サービスも同じです。

ユーザーを集め、取引を成立させ、トラブルへ対応し、改善を続け、必要な広告費を投入する仕事は、ローンチ後から始まります。
作る前よりも、作った後の方が資金も時間も必要になります。

そこを理解せず、公開しただけで満足するのであれば、最初から事業を始めたかったのではありません。

自分の考えたシステムが画面の中で動くところを、一度見てみたかっただけです。

システムを所有することと、サービスを運営することは違います。

完成したシステムは、成功した事業ではありません。
まだ誰も乗っていない、エンジンをかけただけの乗り物です。