プロンプトとビルドの間に表示される、あの30秒の画面――プランカード――の扱いを誤った3人を見てきましたが、それぞれ違う代償を払っていました。一人は作り直しで、一人は無駄な入力時間で、もう一人は本当に必要な機能が欠けた製品で。プランカードは、プロセス全体の中で気が変わったときの修正コストが最も安く済む瞬間なのに、なぜかそれゆえにあっさり見過ごされてしまいます。
失敗その1：思考停止で承認する
これがよくあるパターンです。骨組みが正しそうに見えたら承認してそのまま進む――私も痛い目に遭うまで何週間もこれをやっていました。その習慣を断ち切ったビルドは、Stripeのチェックアウトが静的サイトに組み込まれて返ってきたもので、そのサイトにはStripeが必要とするアカウント状態を保持する場所がありませんでした。プランには製品タイプ：静的サイトとはっきり平易な文字で書かれていたのに、ページ一覧が問題なさそうに見えたのと、急いでいたのとで読み飛ばしてしまったのです。
この失敗の後始末は、いつも同じ形をしています――プラン以降の工程はそのプランを前提とすればすべて正しいので、失敗はエラーとして表面化せず、構造的に間違った「動くビルド」として現れます。何も壊れていないので誰も気づかず、チェックアウトボタン付きの静的サイトは黙って間違った動作をするか、実際のユーザーが「支払う」を押した瞬間だけ失敗します。それに気づくのはレビュー時――最もコストのかかる発見場所です。
失敗その2：二度目のラウンドを避けようと過剰に指定する
逆の失敗は一見より責任感があるように見えますが、実際はそうではありません。失敗その1で痛い目を見た人の中には、行き過ぎて、プラン段階で正確な要件を段落単位で書き込むようになる人がいます――正確な文言、余白の好み、絶対に入れるべき機能・入れるべきでない機能を、まるで仕様書のように書き連ねるのです。私もこれをやったことがあります。今詳細を省くと後で「無駄」になるという漠然とした不安からです。
これは順序が逆で、理由はこうです。プランは、実際のページを見た後にどのみち再度修正されます。最初にどれだけ丁寧に書いたかは関係ありません。そして修正される際、変更点の差分がもらえるわけではなく、あなたの編集を織り込んだ新しいカードがまるごと返ってくるだけで、パッチノートは一切ありません。つまり、1回目に書いた正確さは、そのまま2回目に持ち越されるわけではなく、結局全部読み直すことになります。「いや、こうしたい」を2〜3回繰り返す方が、1回の網羅的なブリーフより――書いている最中は効率的に感じるとしても――実時間で見ればより良い結果に、より速くたどり着けます。
実際に効果のある平易な言葉での編集は短いものです。
- 「ブログを外して、料金ページを追加して」――ページ一覧をきれいに入れ替えます。
- 「シングルプレイヤーではなく2人プレイにして」――見た目以上に大きな変更です。データモデルにも影響し、1人ではなく2人の参加者を追跡するようになるかもしれませんが、修正後のプランはその波及効果を隠さずに示してくれます。
- 「これにはユーザーアカウントが必要」――現在のプランが静的サイトなら、この一文が製品タイプの問題を否応なく浮き彫りにします。
失敗その3：製品タイプを軽い項目として扱う
これが最もコストの高い失敗です。というのも、カード上のそれ以外のものは実質的にすべて後から取り戻せるからです。ページ構成、推測された機能、ほとんどの選択分岐――これらはビルド完了後にバージョンの反復で修正可能です。しかし製品タイプはそうではありません。バケットは4つあります。
| プロダクトタイプ | 意味するところ |
|---|---|
| 静的サイト | シンプルで、サーバーロジックなし。 |
| インストール可能アプリ | PWA風――オフライン対応、ホーム画面に追加可能、ただしサーバーロジックはなし。 |
| フレームワークビルド | React/Next風で、クライアント側のインタラクティブ性がより高いが、永続的なバックエンドはなし。 |
| サーバー連携アプリ | 4つの中で唯一、実際のデータベースとアカウントシステムを背後に持つもの。 |
静的サイトのプランを承認し、3バージョン後にログイン機能が欲しくなった場合、それは単なるバージョンアップではなく、異なる製品タイプからの作り直しであり、他のすべてで得られていたバージョン履歴の連続性を失うことになります。
この点を見誤る人は2通りいます。まず、自分のプロンプトをこの項目と照らし合わせない人――もしプロンプトに「アカウント」「ログイン」「保存」「更新されるダッシュボード」「支払い」「複数ユーザーが同じものを編集する」といった言葉があり、カードにサーバー連携（server-backed）と書かれていなければ、それは承認前に修正すべき唯一の点であり、例外はありません。次に、インストール可能アプリとフレームワークビルドを混同する人――どちらも日常会話では「アプリ」に感じられるからです。両者は互換ではありません。インストール可能アプリは、すべての状態がユーザーの端末に存在するツール向け――チップ計算機やワークアウトタイマーなどです。フレームワークビルドは、よりインタラクティブでコンポーネント構造もありますが、それでもセッションや端末をまたいでサーバー側に何も保持されません。どちらも、アカウントとデバイスをまたいで持ち歩けるデータを持つという意味での「アプリ」ではありません――それに該当するのはサーバー連携だけです。そして、ポートフォリオサイトやドキュメントページに対して「念のため」サーバー連携を過剰に用意するのも安全な選択ではありません――後で格下げするのは、格上げするのと同じくらい作り直しになります。
この3つをやめると、残るものは何か
製品タイプの行を読み飛ばさず、プラン段階で仕様書を書かず、自分のプロンプト中のアカウント・データ・支払いに関する言葉を交渉可能なものとして扱わなくなれば、残るのは素早く狭い範囲のチェックです。
- 製品タイプを読む。
- それを自分のプロンプトと照らし合わせる。
- 推測された機能一覧に、見た瞬間に却下したいものがないかざっと確認する。
この一覧が存在するのは、まさに「美容室向け予約ツール」のようなプロンプトが、あなたが書いていないものまで引き寄せるからです――カレンダービュー、SMSリマインダー、顧客リストなど。その一部は意図した通りかもしれませんが、一部は統計的に一緒に現れがちだからとモデルが加えたスコープの膨張です。ビルドされた後ではなく、一文の中でこの段階で不要なものを刈り取りましょう。
それ以外のもの――コピー、余白、アクセントカラーの色合い、ボタンが「Get Started」か「Try It Free」か――は意図的にカードに一切含まれていません。それらは動くビルドの上で見て直すのが安価なので、カードはそこにあなたの注意を無駄遣いさせません。あなたもそうすべきです。それが、カードを読む30秒のうち、実質的な判断が必要な約15秒です。
