数字が伸びないと、個人開発者はコードに戻る
公開したサービスの数字が、伸びない。さて、次に何をするか ── 多くの個人開発者は、ここでコードエディタを開きます。新しい機能を足す。コードを整理する。UI を少し調整する。
文章を ── ランディングページの最初の一行を、登録ボタンの言葉を、機能の説明を ── 直しに行く人は、ずっと少ない。
これは、怠けているのでも、文章を軽く見ているのでもありません。数字が伸びないとき、個人開発者の手は、構造的にコードへ向かうようにできているのです。この記事では、その理由を 3 つに分けて見ていきます。なぜ手がコードに戻るのかが分かれば、そこから一歩、別の方向へ踏み出せます。
理由 1：コードには「やった感」がある
機能を 1 つ足せば、コミットが 1 つ増える。差分が出る。デプロイすれば、画面が目に見えて変わる。「今日は、進んだ」という手応えが、はっきり残ります。
一方、ランディングページの最初の一行を書き直しても、コミットは小さく、画面の見た目はほとんど変わりません。進んだ感が、薄いのです。
人は、手応えのある作業に引き寄せられます。だから、進捗の見えるコードへ手が伸びる。けれど、考えてみてください。「やった感」があることと、「数字が動く」ことは、まったく別のことです。手応えは、正しさの証明にはなりません。
理由 2：コードは得意分野で、文章はそうではない
個人開発者は、コードで物事を解決してきた人です。コードは、長く付き合ってきた、手に馴染んだ道具。文章は、多くの場合、そうではありません。
慣れない作業より、得意な作業に向かうのは、ごく自然なことです。問題は、その自然さが、問題の見え方そのものを変えてしまうこと。「金槌を持つと、すべてが釘に見える」と言われるとおり、得意な道具を握っていると、目の前の問題が、その道具で解ける形に見えてきます。
「数字が伸びない」という問題が、いつのまにか「機能が足りない問題」に見えてくる。本当は、文章の問題かもしれないのに、です。
理由 3：コードの問題は見える、文章の問題は見えない
バグには、スタックトレースがあります。エラーメッセージが「ここが問題だ」と、場所を教えてくれる。直すべき箇所が、可視化されます。
ところが、伝わらない最初の一行には、エラーが出ません。「この見出しは、初対面の人に価値が伝わっていません」と教えてくれるものは、どこにもない。問題が可視化されないので、文章は「特に問題はない」ように錯覚されます。
そして人は、見えない問題よりも、見える問題から手をつけます。コードには改善点がいくらでも見える。だから、そちらへ向かう。文章の問題は、見えていないだけで、ないわけではないのに。
本当の壁：放っておくと、手はコードへ行く
3 つの理由は、どれも個人開発者を責めるものではありません。手応えのある作業を選び、得意な道具を使い、見える問題から手をつける ── どれも、まっとうな判断です。
問題は、そのまっとうな判断の積み重ねの結果として、数字が伸びない本当の原因が、手つかずのまま残り続けることです。機能を足す。伸びない。また足す。やっぱり伸びない。このループの外側に、文章の問題が、一度も触られないまま置かれている。
抜け出す方法は、ひとつだけです。「数字が動かないときは、まず文章を疑う」を、意識的なルールにする。
意識的に、と書いたのには理由があります。放っておけば、手はコードへ行くからです。何も決めていなければ、3 つの理由が、毎回あなたをコードへ連れ戻します。だから、先にルールとして決めておく。数字を見たら、コードエディタを開く前に、まず自分のサービスの最初の一行を、初対面の人の目で読み直す。
なぜ作った本人ほど、その一行を読めないのか ── という構造は、別記事個人開発者のサービスが「素通り」される、たったひとつの構造的な理由に。反応のなさを「ニーズがなかった」と読んでしまう手前の話は、「ニーズがなかった」は、たいてい早すぎる結論にまとめています。
まとめ
コードを書くな、という話ではありません。機能の改善が必要なことは、当然あります。ただ、数字が伸びないときに 最初に 開くものを、コードエディタから、自分のサービスの文章へ ── 一度、入れ替えてみてほしいのです。
コピーライティングは、その「見えない問題」を、見えるようにして直すための技術です。スタックトレースの代わりに、どの一行が読み手を遠ざけているのかを、見えるようにする。見えれば、直せます。
「見えない文章の問題」を見えるようにし、AI を相棒に直していくところまでを 1 冊につなげたのが、下記の本です。個人開発者・インディー Web 作者・動画作者に向けて、ランディングページ・短い文章・メールの戦場別に、なぜ書くのかと、どう書くのかの両方を、実演を交えて書いています。