個人開発のWebサービスは、なぜ失敗するのか。

つまずく場所は3つある — 層が違えば効く対策が違う

「個人開発が失敗した」とひとことで言っても、どこで止まったかで意味がまるで違う。まず自分がどの層の話をしているのかを分けてほしい。層を混ぜたまま対策すると、効かない打ち手に時間を使うことになる。

レイヤー1は AI自動コーディングで実際に改善した。1〜2ヶ月かかっていた実装が一晩で終わるようになり、「完成しないまま放置」は確実に減っている。

問題はレイヤー2と3が何も変わっていないことだ。むしろ完成するサービスの総数が増えたぶん、「動くけど使われないもの」の絶対数は増えている。以下はこの2層を扱う。

失敗の型1: 現場が元のやり方に戻る

最も多かった型。サービスは動いている。バグもない。それでもユーザーは使わなくなる。 理由は単純で、既存の手段のほうが速いからだ。

紙・電話・メモ帳・LINE は、機能では圧倒的に劣るが、起動が0秒で、学習コストがゼロという決定的な強みを持つ。Webサービスがこれに勝つには、ログインして画面を開いて操作するコストを上回る速度差が要る。

なぜ起きるか

• 作り手は「機能があること」を価値だと思っているが、使い手が見ているのは「今より速いか」だけ
• 比較対象を間違えている。 競合サービスではなく、紙とメモ帳が本当の競合
• 入力の手間を過小評価している。 1回30秒の入力でも、1日20回なら10分。それだけで元のやり方に戻る理由になる

回避設計

• 「今のやり方より速くなる工程」を1つ、具体的に言えるようにする。 言えないなら作らない
• 入力を減らす方向に機能を足す。 増やす方向の機能追加は速度差を縮めるので逆効果
• ログイン不要で成立するなら、しない。 起動0秒に一歩近づく

この型は、着手前に ✋ AI業務Webシステム化ツール のように「今の手作業の流れ」を先に書き出す形で設計すると、かなり潰せる。速度差が出ない工程は最初から対象外にできるからだ。

失敗の型2: 情報の入口が2つあって二重管理になる

分析では「顧客情報は入っているが物件との紐付けは手作業」「システムに入っていない顧客が多い」「登録された情報と個人ノートの内容がズレている」といった形で繰り返し出てきた。

構造はいつも同じだ。情報の入口が2つ以上あると、片方が必ず更新されなくなる。 そして一度ズレた瞬間から、ユーザーは「どっちが正しいか分からない」ため両方を確認するようになり、導入前より作業が増える。

回避設計

• 入口を1つに絞れないなら、その領域は作らない。 一部だけ置き換えるサービスは、ほぼこの型を踏む
• 「既存のやり方を消せるか」を先に問う。 併存を前提にした設計は、併存したまま片方が使われなくなる
• 取り込み(インポート)を軽く見ない。 既存データが入らないサービスは、入口を2つにするのと同じ

失敗の型3: 情報の鮮度が保てない

在庫・空き枠・掲載中かどうか — 「今どうなっているか」を表示するサービスは、鮮度が落ちた瞬間に価値がマイナスになる。古い情報は、無いより悪い。予約できると思って動いた人が無駄足を踏むからだ。

分析でも「予約したのに予約がない」「二重予約になった」「システムに載ってない物件がある」という形で、鮮度崩壊が独立に2回挙がっていた。

回避設計

• 更新が人手に依存する設計を避ける。 「忙しいときに更新されない」は前提として織り込む
• 鮮度が落ちうるなら、最終更新時刻を必ず出す。 古いかもしれないと分かれば、価値はマイナスにならない
• リアルタイム性が本質なら、それは初手として重い。 別の切り口に寄せられないか検討する

「更新されなくても成立する設計か?」は、着手前に一度だけ自問しておく価値がある。

失敗の型4: 例外処理で運用が溶ける

キャンセル・変更・取り消し・返金。正常系だけ作ったサービスは、最初の例外が起きた瞬間に手作業へ戻る。

分析でも「キャンセル待ちユーザーへの通知が手動メール」「キャンセル料金の請求漏れ」「システムからのメールと担当からの電話で重複連絡が来たという苦情」といった形で、例外系の運用破綻が挙がっていた。皮肉なことに、例外処理が無いせいで通知が二重になり、かえって迷惑をかけているのが典型的な壊れ方だ。

なぜ後回しになるのか

MVP を「最小限の機能」と解釈すると、例外系は真っ先に削られる。しかし MVP は「最小限の機能」ではなく「最小限で一周まわる体験」だ。申し込んで、変更して、取り消せて初めて一周する。取り消せないサービスは、一周していない。

回避設計

• 「作る/作らない」の線を、機能ではなく体験の一周で引く
• 例外系は MUST に入れる。 代わりに正常系の便利機能を SHOULD へ落とす
• 通知は必ず一元化する。 手作業の連絡と自動通知が併存すると、重複して信頼を失う

失敗の型5: 多機能化して誰にも最短経路がなくなる

「うちのやり方に合わない」と言われるたびに設定項目を足していくと、あらゆるやり方に対応できるが、どのやり方でも遠回りな画面が出来上がる。

分析では危険信号として 「管理画面の設定項目数が50を超えている」「ユーザーが『どの項目を設定すればいいか分からない』と言い始める」が明示されていた。件数としては2件だが、他の型を悪化させる増幅要因でもある。設定が増えるほど入力コストが上がり、失敗の型1(元のやり方に戻る) を引き起こすからだ。

回避設計

• 「合わない」と言われたら、機能を足す前に対象を狭める。 全員に合わせるより、合う人だけに絞るほうが個人開発では正しい
• 設定項目を足すときは、必ず何かを削る。 総量に上限を設ける
• WON'T(今回は作らない)を先に明文化する。 書いていない機能は、必ず後から入り込む

続けて読む

この記事は「作ったあとに失敗する理由」を扱った。前工程はこの2本にある。

• 作りたいものがない個人開発者へ — そもそも何を作るかが決まらない段階の解き方と、案を捨てる基準
• Claude Codeで何を作る? — 最初の1本の選び方、避けるべき初手、仕様書に何を書くか
• Webサービスの差別化と参入障壁 — 本記事の「〜のほうが早い」と同じ構文が、模倣耐性の診断16件でも出た話