📋 実物を触る前に書いたLPを全部捨てた——28ステップのオンボが教えた「約束の配線」

旅行パンフレットは、行ったことのない土地の写真でいっぱいです。

「絶景まで徒歩5分」と書かれた道が、実際には急な山道だったりします。

あなたは今、こうなっていませんか。

• 実物を触る前に、サービスの説明文（LP）を書いてしまっている • 「だいたいこんな機能があるはず」の想像で、紹介ページを完成させた • 完成後に修正しようと思いつつ、初稿のままリリースした • 約束した機能が本当に動くかどうか、自分でも確かめていない

先に結論を言います。実物を触る前に書いたLPは、触ってから全部書き直すことになります。

この記事では、実物を触る前に書いたLPを2回書き直した経験と、「実装→LP」の順番に変えた理由を書きます。

スワ活のLPを2回全文書き直した

これは、わたし自身の話です。スワ活というサービスを作ったとき、LPを2回、全文書き直しました。

スワ活はWebアプリとして作ったサービスで、ユーザーが登録してオンボーディングを終えると、実際に機能を使い始めます。

「オンボーディング」というのは、サービスを初めて使う人への最初の案内の流れのことです。

実装ゼロのまま3日で書いた初稿

最初にLPを書いたのは、Webアプリの実装がまだゼロの段階でした。

「こんなことができるサービスです」「最初にこの手順を踏むと使えるようになります」を、頭の中の想像だけで書きました。

LPというのは、ランディングページの略で、サービスを紹介してユーザーに「使いたい」と思ってもらうための1枚のページのことです。

それをわたしは、実物ゼロで書きました。

書くのに3日かかりました。

「これならいける」が一番危なかった

出来上がったとき、自分では「なかなかいい仕上がりだ」と思っていました。

ストーリーも入れて、読んだ人が「使ってみたい」と思えるような構成にしたつもりでした。

「問題提起→共感→解決策の提示→使い始め方」という、よく言われる流れで書きました。

書いていて気持ちが乗っていたし、何度か読み直して「これならいける」と感じていました。

今思うと、それが一番危ない状態だったんですが（笑）。

実物なしでも自信が持てた理由

なぜそこまで自信が持てたのか、あとから振り返りました。

答えはシンプルで、「反証する情報が手元に一切なかったから」です。

実物がなければ正しさを確かめられない

実物がないということは、「違う」と教えてくれるものも、まだ何もないということです。

書いた内容が正しいかどうかを確かめるには、実物が存在していなければなりません。

実物なしで書くと、正しさを確かめる手段が、自分の想像の中にしかないんです。

3日間、わたしは想像の中だけで書いていました。

内側から見ていると、矛盾には気づきにくいものです。

自分向けの整理とユーザーへの約束は別物

もうひとつ、「実物なしで書く」ことが起きやすい理由があります。

「LPを先に書くと、コンセプトが固まる」という考え方が広まっているからです。

これ自体は間違っていません。LPを書くことで、方向が整理されることはあります。

ただ、そのLPの役割は「自分向けの整理」であって、「ユーザーへの約束」ではないんです。

この2つは、目的がまったく違います。

前者はアイデアを確認するための内部メモです。後者は公開して読まれる文章です。

わたしは3日かけて内部メモを書いて、それをユーザー向けの約束として公開しようとしていました。

この2つを無意識に混ぜると、約束が宙に浮きます。

実装後に読み直したら全部違った

その初稿を、実装が完成した後に読み直したときのことです。「これ、全部違う」と思いました。

「3ステップ」と書いたのは28ステップ

実装されたスワ活のWebオンボーディングは、28ステップありました。

LPには「3ステップで始められます」と書いてありました。

完全に違います。

28と3では、同じ「ステップ」という言葉を使っていても、ユーザーが感じる重さが全然違います。

28ステップというのは、「次へ」を押す回数が28回あるということです。

スワイプで候補を選ぶ画面があって、出願リストと呼ばれる機能一覧を管理する画面もあって、各ステップに説明や入力欄がありました。

わたしはこれを触ったことがない状態で「3ステップで始められます」と書いたわけです。

どれも、想像で書いたLPには登場していませんでした。

逆に、LPに書いてある説明で、実装に対応するものがないものも複数ありました。

「あるはず」で書いた機能が、実際には存在していなかったんです。

宙に浮いた約束はユーザーへの裏切り

「宙に浮いた約束」というのを、このとき実感しました。

誰も履行できない約束が、トップページに並んでいる状態です。3日かけて書いたものが、読み返した瞬間に「全部捨て」になったので。

それだけじゃなくて、「自分が書いたLPを信じてサービスを使い始めたユーザーが、どう感じるか」を想像するとさらにしんどくなりました。

「3ステップで始められる」と思って登録したら、28ステップ待っている。それは、裏切りです。

でも捨てて良かったと思っています。公開してから気づくよりも、はるかにマシです。

たとえば「28ステップある」と知っていたら、「時間をかける価値があるかどうか」を最初に伝えられます。

「最初に少し時間をもらいますが、それをすることで○○が変わります」という書き方ができます。

「スワイプで選べる」と知っていたら、「感覚で直感的に選べるから、難しくないですよ」と書けます。

「テストみたいに正解を考えなくていいです」という安心を、先に届けられます。

でも実物を触る前には、そんな書き方はできません。

触って初めて、「何が価値で、何がユーザーの不安に見えるか」がわかるんです。

4日かけた書き直しと28ステップの明記

書き直しには4日かかりました。

最初の3日と合わせると、LPだけで合計7日使ったことになります。

書き直しのとき、「28ステップある」と正直に書くことに、少しだけ迷いがありました。

「多い」と感じさせてしまうんじゃないか、という不安です。

でも迷ったのは一瞬で、書くと決めました。

隠してもユーザーはいつか気づくからです。

最初から伝えれば、その量で構わないと思った人だけが来てくれます。

「時間をとられるのが嫌な方には向かないかもしれません」という一文も、一種の誠実さです。

この判断も、触るまではできませんでした。

書き直しの後はオンボーディングを整理

書き直し版でようやく「実物に基づいたLP」ができました。でも、それで終わりではありませんでした。

次にやったのは、オンボーディング自体のリファクタです。

「リファクタ」というのは、プログラミングの言葉で、外から見た動きは変えずに中身を整理し直すことを指します。

LPを書き直すために実物を触っているうちに、「このオンボーディング、ユーザー目線で見るとしんどいな」と気づいてしまいました。

「しんどい」と感じた理由が2つあって、それが今回のリファクタの軸になりました。

答えても結果が変わらない質問を落とす

1つ目は、「答えても何も変わらない質問が多い」ということです。

「どんな目的で使いますか？」

と聞かれても、どう答えても同じ次のステップへ進む質問がいくつかありました。

ユーザー側から見ると、「何のために答えているんだろう」という感覚になります。

これは、データを集めたかった開発側の都合と、ユーザーの体験の間にズレが出た状態です。

開発者としてデータを集めたい気持ちはよくわかります。

でもユーザーから見れば、「何を答えても結果が変わらない画面」は、意味なく時間を使わされているように感じます。

「答えを活かすか、聞くのをやめるか」——どちらかしかありません。

そう気づいてから、「結果が変わらない質問を落とす」という判断をしました。

28ステップのうち、いくつかはこれに該当しました。

取り除いただけで、オンボーディングがずいぶん軽くなった感覚がありました。

LPの約束がオンボーディングで体験できない

2つ目は、「LPで約束したことが体験できていない」ということです。

「出願リストで整理できます」とLPに書いてあるのに、オンボーディングを全部終えても出願リストがどこにあるかわからない、という状態になっていました。

これが「書いた約束を配線する」というリファクタの目的です。

「配線」というのは、LPの約束とサービスの体験をつなぐことです。

電源を入れたのに電球が光らないのは、配線が切れているからです。

LPが「明るくなりますよ」と約束しているのに、スイッチを押しても何も変わらない状態——それが「配線が切れている約束」です。

配線を入れることで、ユーザーは「確かに、LPに書いてあったとおりだ」と感じられます。

「約束→体験」がつながることで、初めて信頼が生まれます。

この感覚は、実物を触るまで完全に見落としていました。

配線が切れた約束を一つずつつなぐ

「配線が切れている」状態には、いくつかのパターンがあります。

LPに書いてある機能がオンボーディング中に一度も出てこない、というのが一番わかりやすいパターンです。

もうひとつは、機能はあるのに価値との接続がないパターンです。

ボタンはある。でもそのボタンが何のためにあるかが、使い始めてもわからない。

LPで「これが価値です」と伝えていても、実物の中でその価値がどこで体験できるかを示せていなければ、約束は届きません。

LPとオンボーディングを並べて確認する

配線の作業は、LPとオンボーディングを同時に開きながら進めました。

「LPにこう書いてある→この体験がオンボーディングの何ステップ目で出てくるか」を確認し、ない場合は追加か修正する、という判断をひとつひとつやりました。

地味ですが、ここが一番大事な作業だったと今でも思っています。

2つのリファクタで使い物になった

これら2つのリファクタで、オンボーディングが初めて「使い物になった」と感じました。

スワイプの画面は残しましたが、「なんのためにスワイプするのか」をオンボーディングの早い段階で伝えるようにしました。

出願リストも、使い始めてから3ステップ以内に見えるように変えました。

LPには、これらを実物に基づいて書き直しました。「宙に浮いた約束」は、1つもなくなりました。

ひとりで作るなら実装が先、LPが後

ここで少し、以前の仕事の話をします（1度だけ）。

マーケ時代は間に入る人がズレを埋めていた

マーケティング側にいたころ、「LP→制作依頼」という流れが当たり前でした。

LPを書いて、それを制作チームに渡して、チームが実装する。

その順番で動いていたのは、実装を触る人間とLPを書く人間が別だったからです。

制作チームが「この機能は難しい」と言えば、マーケターはLPの文言を調整する。

間に入る人間がいることで、LPと実装のズレが自然に埋まっていました。

でも自分だけで作る場合、間に入る人がいません。

実装の現実を知っているのも、LPを書くのも、全部自分です。

だからこそ、「LP→実装」ではなく「実装→LP」の順にしないと、約束が宙に浮くんです。

この順番の大切さを理解するまでに、11日かかりました。書き直しで7日、リファクタで4日です。

LPの代わりに3行のメモで十分

「でもLPを先に書かないと、方向性が決まらなくないですか？」という疑問があると思います。

わたしも最初はそう思っていました。

LPを書くことで、「何を作るか」を固める効果があると思っていたんです。

実際にやってみて気づいたのは、「LPではなく3行のメモで十分」ということです。

作る前に固めるべきなのは、「誰の、どんな問題を、どうやって解決するか」だけです。

この3行をメモに書いたら、実装に入ります。

実装して、触って、そこで初めてLPを書く。この順番にすると、約束が宙に浮かないんです。

メモに書くのは3点だけ

「3行」というのは、細かい仕様を書く必要はないということです。

「どんな人が」「何に困っていて」「使った後にどう変わるか」の3点だけです。

この3点さえあれば、実装の方向がぶれません。

機能の詳細な仕様は、実装しながら決めれば十分です。

LPは、その仕様が実際に動いてから書く。その方が正確で、誠実です。

触ってから書くと伝えることが変わる

今は「最小限だけ動く実物を作る→自分で触る→LPを書く」の順番を守っています。

この順番になってから、書き直しの回数が大幅に減りました。

触ると本当に伝えるべきことがわかる

実物を触ると、必ず「これは伝えないといけない」という発見があります。

28ステップというボリュームも、「最初の5ステップが一番大事」という構造も、触ったからこそ見えました。

逆に、「LPに書いたけど実は重要じゃなかった」という情報が浮かび上がることもあります。

触る前は「これが一番の価値だ」と思っていた機能が、触ってみると「実は補助的な機能だな」と気づいたりします。

LPに書くべき「本当に伝えるべきこと」は、触ることで初めてわかります。

これは、書き直しの無駄を省くためだけでなく、ユーザーへの誠実さのためでもあると思っています。

問いが「何が起きたか」に変わる

「触ってからLPを書く」を続けていると、書くときの問いかたが変わってきます。

「何を書けばよいか」という問いから、「何が起きたか」という問いへの変化です。

「何を書けばよいか」は、頭の中で考える問いです。答えが出ない日もあります。

「何が起きたか」は、実物を動かして確認する問いです。触れば必ず答えが出ます。

事実を書いたLPは、想像で書いたLPより、自然に具体的になります。

具体的なLPは、読んだ人が「これは自分に関係ある話だ」と感じやすくなります。

書くことの難しさが、少しずつなくなっていく感覚でした！

LPは実物を翻訳した約束にする

LPで「○○ができます」と書いた瞬間、その機能が実際に動くことを確かめる責任が生まれます。

これが「約束の配線」という考え方です。

配線が済んでいない約束は、読んだ人に届きません。

届かないどころか、届いた先で「思ってたのと違う」になります。

「思ってたのと違う」は、最も深刻なリスクだと思っています。

書き直しの7日間より、配線ミスのほうがよほど大きなダメージを残します。

LPは創作ではなく観察を書く翻訳

LPと実物にズレがある場合、問題はLPの「書き方」ではありません。

LPがどれだけうまく書けていても、実物がそれに追いついていなければ意味がありません。

逆に言えば、実物が先にあれば、LPはそれを忠実に翻訳するだけでいい。

「翻訳」と「創作」は、求められるものが違います。

創作は想像力を使います。翻訳は観察力を使います。

実物があれば、観察したことを書けます。

それが一番正確で、ユーザーに対して誠実なLPだと思っています。

迷ったら3行のメモと最小限の実物から

この記事を書こうと思ったのは、同じことで悩んでいる方を何人か見かけたからです。

「LPを先に書いたのに、なんかうまくいかない」という状態の方が、想像よりも多い気がしています。

うまくいかない理由が「書き方」でも「デザイン」でもなく、「順番」だったというのは、気づきにくいと思います。

わたしも、2回失敗してやっとわかりました。

もし今、実物を触る前にLPを書こうとしている方がいたら、少し立ち止まってみてください。

「3行のメモだけ書いて、まず最小限を動かす」から始めることをおすすめします。

約束の配線の仕組みをどう作っているか、もう少し詳しくまとめたものを有料記事に置いています。 気になる方は、フッターのリンクからどうぞ。

28ステップのオンボーディングを触った日から、2週間でリファクタが終わりました。

「配線する」という考え方があったからだと、振り返ると思います。

この考え方が、あなたの作るものにも少しだけ役に立てたらうれしいです。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順