LPはテスト先行で作る。手戻りゼロを実現した新サービス公開の舞台裏

LP、テスト先行で作りました。

新サービス「Reworkless AI」のランディングページを作った際、私たちはデザインカンプを先に描きませんでした。代わりに最初に手を付けたのは、テストでした。見た目が何もない段階で、「このページはこう振る舞うべきだ」という約束事だけを先にコードとして書き、それから初めて画面を組み立てていったのです。

制作会社の常識からすれば、これは順番が逆に見えるかもしれません。しかし実際にやってみると、この逆転こそが手戻りを消す鍵でした。

見た目より先に、テストを書いた

通常のLP制作は、まずデザインが決まり、そのビジュアルに合わせてコーディングし、最後に「思っていたのと違う」といった調整が入る、という流れをたどりがちです。今回はこの順番をあえて崩しました。

具体的には、ページがどう動作すべきかを定義した36行のテスト契約を最初に用意し、それに実装を合格させる形でLPを組み上げていきました。見た目のトーンや配色よりも先に、「問い合わせボタンはここに存在するべきだ」「このセクションは必ず表示されるべきだ」という振る舞いの約束を固めてしまう。デザインはその約束を満たす器として後から作られる、という順序です。

曖昧なLPほど作り直しになる理由

なぜこんな回り道めいた手順を選んだのか。理由はシンプルで、LP制作の手戻りの大半は「要件が曖昧なまま画面を作り始めること」から生まれるからです。

「とりあえずデザインを見てから決めましょう」という進め方は、一見スピーディーに見えて、実は判断の先送りにすぎません。デザイン案を見た担当者が「やっぱりこの訴求も入れたい」「ここの導線が足りない」と言い出すたびに、コードとデザインの両方を作り直すことになります。見た目という多情報な成果物を先に出してしまうと、そこに引っ張られて本来詰めるべき要件の議論が後回しになるのです。

私たちが先に固めたのは、ページに何を持たせるべきかという設計そのものでした。144行の設計ドキュメントで、このLPが誰に何を伝え、どんな行動を促すのかを言語化し、続けて322行の実装計画で、その設計をどんな手順・構成でコードに落とすかを具体化しました。デザインの手触りではなく、ページの果たすべき役割を先に固定する。ここが決まっていれば、後工程でどれだけ手を動かしても方向がぶれません。

設計書・契約・実装、迷いを減らす順序

設計書144行、実装計画322行、テスト契約36行、そして実装357行。この行数の流れそのものが、実は手戻りを減らす仕掛けになっています。

設計書で「何のためのページか」を定め、実装計画で「どう作るか」の道筋を描き、テスト契約で「完成の基準」を数値・条件として固定する。この三段階を経てようやく実装に入るため、コードを書く段階では「これで合っているか」を都度考える必要がなくなります。テストが合格するかどうかが、そのまま完成の判断基準になるからです。

この順序がもたらす最大の効果は、各工程での判断量を減らすことです。デザイン起点の制作では、実装者は「見た目」「動き」「文言」のすべてを同時に判断しながら手を動かさなければなりません。しかし契約を先に固めておけば、実装者はテストに合格することだけを考えればよく、357行の実装は驚くほどまっすぐに進みました。判断のタイミングを前倒しにして、実装というもっとも手を止めたくない工程では判断を最小化する。これが今回のやり方の核心です。

テストの置き場所で足をすくわれた話

もちろん、うまくいったことばかりではありません。実装が一段落したあと、テストの配置に関する不具合が見つかりました。使用しているWebフレームワーク（Astro）のルーティング領域の中にテストファイルを置いていたため、本来ページとして扱われるべきでないファイルまでビルド対象に含まれてしまっていたのです。修正は2ファイル・行数にして19行の追加と19行の削除という小さな規模で済みましたが、見過ごしていれば公開後の挙動に影響しかねない問題でした。

ここから得られる教訓は地味ですが重要です。テスト駆動でどれだけ丁寧に契約と実装を積み重ねても、テストの置き場所というインフラ的な取り決めを誤ると、その努力ごと足元をすくわれます。ロジックの正しさだけでなく、「テストがどこにあり、ビルドにどう影響するか」という周辺のルールまで含めて設計する必要がある、ということです。テスト駆動開発は魔法ではなく、周辺の約束事とセットで初めて機能する、という当たり前の事実を再確認させられました。

作って終わりにしない導線設計

LPが完成し、テストにも合格した。ここで終わりにしないのが今回のもう一つのポイントでした。単体のページとして公開しても、そこへ人が辿り着く道筋がなければ意味がありません。

公開後、私たちはサイト全体からReworkless AIへの導線を追加しました。変更は6ファイルにおよび、78行の追加と2行の削除という規模です。トップページやナビゲーション、関連コンテンツの各所から新しいLPへリンクを張り巡らせることで、初めて「作ったページ」が「見つけてもらえるページ」に変わります。

LP単体の完成度をどれだけ高めても、サイト全体の中で孤立していては成果につながりません。制作の最後の一手として導線設計を組み込むかどうかが、公開後の数字を左右する分かれ目になります。

自社の制作フローに持ち帰るなら

今回の一連の流れから、自社の制作プロセスに持ち帰れる判断ポイントは三つあります。

一つ目は、デザインより先に「何を約束するページか」を言語化する順序を試す価値があること。曖昧な要件のまま見た目から入ると、修正の連鎖に巻き込まれやすくなります。

二つ目は、完成の基準をテストという形で先に固定する発想です。感覚的な「良さそう」ではなく、条件として合否を判定できる基準があれば、実装段階での迷いが激減します。

三つ目は、公開して終わりにしないことです。ページ単体の質を上げる労力と同じくらい、サイト全体からの導線をどう張るかに時間を割く。ここを省略すると、せっかく作ったページが誰にも見つけられないまま埋もれてしまいます。

どの工程を先に固め、どこで判断を前倒しにするか。自社の制作フローを見直す際、まずはこの順序の入れ替えから検討してみてはいかがでしょうか。