間違いその1: 一文ではなく仕様書を書いてしまうこと
過去に質の悪いソフトウェアで痛い目に遭った人ほど、ビルダーを開いて長々と文章を打ち込みがちです。採点方式、単位の好み、オフラインモード、配色——最初の返答が返ってくる前に、すべてを先回りして詰め込んでしまう。それは責任感のある行動に思えます。しかし実際は違います。ビルダーはあなたの一文を読み取り、おそらく意図しているであろう内容を推測し、およそ15秒でプランを返してきます——「クライマー向けのトレーニングログ」は、セッションログ、グレード追跡ビュー、ダッシュボードへと展開され、デフォルトにはVスケールのボルダリングとYDSのルートが選ばれます。それが実際に多くのクライマーが使っているものだからです。ビルダーは何を選んだのかをそのプランの中できちんと示すので、あなたが例外であれば一行で修正できます。先に長文を書いても、このステップを飛ばせるわけではありません。結局プランは提示され、それを読む必要があり、しかもプランがどのみち示してくれたはずの制約を——あなたのビルドにとって本当に重要な順序ではなく——入力するのに3分を費やしただけということになります。
このプランは、空欄を埋める形式のフォームではありません。文章であり、あなたも文章で答えます。「実際にはフォントグレードにして、私はヨーロッパにいるので」は、それだけで完結した修正です。「パートナー/ビレイヤーのログ欄を追加して、いろいろな人と登っているので」も同様です。修正のたびに再生成されるのはプランであって、ビルドそのものではありません——コストのかかる工程が始まる前に方向を調整しているだけです。プランを承認することが、あなたに求められる最後の決定です。それ以降はすべて生成と検証です。
間違い その2:止まった端末を見つめるようにフィードを眺める
ビルドはサーバー側で実行され、ここでの「壊れた」という不安はほとんどの場合、単なる誤報です。誰かが静かなアクティビティフィードを2分間見つめて、止まっていると思い込んでしまう。実際は止まっていません——毎秒目に見える出力を生成しないフェーズにいるだけであり、フィードにはまさにこの理由から今どのフェーズにいるかがラベル表示されます。タブを完全に閉じても構いません。実行はあなたのブラウザの中で動いているわけではないからです。
実際に期待すべき所要時間は、ビルドの形によって大きく変わります。クライミングログ——数ページ、ローカルなデータモデル、外部APIの呼び出しなし——は3分未満で完了します。これは「記録して、グラフ化して、一覧表示する」程度のものであれば典型的な速さです。ビルドに本格的なバックエンド、認証、リレーションを持つデータベース、バックグラウンドジョブが必要になった瞬間、8〜12分は見ておく必要があります。スキーマの生成とマイグレーションが加わり、検証パスもマークアップだけでなくサーバーコードに対してもう一度実行されるためです。ゲームはさらに時間がかかります。スプライトや効果音といったアセット生成が必要で、最初の試みが意図したサイズでうまく見えない場合は、2回目のビジュアルパスが必要になることもあります。そしてネイティブパッケージング——シェルに包まれたWebビューではなく、実際にインストール可能なAPK——は、本物のツールチェーンに処理を引き継ぎます。Gradle、署名、そのすべてです。この工程だけで、他のすべてに加えてさらに5〜10分かかることがあり、静かなフィードがトラブルではなく、ツールチェーンが本来の仕事をしていることを意味する唯一のフェーズです。
このモデルの正直なコストは、コードがエディタに1文字ずつ流れ込むのを見るという、即時的でリアルタイムなフィードバックを失うことです。その代わりに得られるのは、あなたのノートパソコンがスリープしても、Wi-Fiが切れても生き延び、スマートフォンから確認でき、あなたが見ていようがいまいが動き続けるシステムです。90秒のビルドであれば、このトレードオフはほとんど気になりません。しかし12分かかるバックエンドのビルドでは、端末に張り付いているかコーヒーを取りに行けるかの違いになります。
間違い その3:「生成された」を「完成した」と勘違いする
これは高くつく部分だ。素早く終わるビルドで、まだチェックされていないものは完成したビルドではない――たまたま動いているだけの下書きだ。この2つの違いこそが、多くの高速サイトビルダーが悪評を買う原因になっている。サニタイズのないフォームや、キーボードで到達できないボタンを平気で出荷してしまうのだ。このプラットフォームが何かを「完了」と呼ぶ前に、独立した検証エージェントがレビューを行う――コード、セキュリティ、リンク、SEO、アクセシビリティ、そしてあなたが承認したプランへの適合性。これは本当に別のパスであり、同じエージェントが自分の出力を読み返して頷いているだけではない。
セキュリティチェックは、実際に本番環境で人を噛みつく地味な問題を探す。クライアント側コードにコミットされたAPIキー、サニタイズなしで入力を受け付けるフォーム、セッションから導出せずクライアントが指定したユーザーIDを信頼するエンドポイントなど。アクセシビリティチェックはコメントで黙らせられるリンターではない――実際のコントラスト比や、インタラクティブ要素がキーボードで到達可能かどうかをチェックしている。
適合性チェックは最も過小評価されがちなものだ。生成パスが、あなたが頼んだこと――たとえばプラン編集にあったパートナー/ビレイログのフィールド――を、誰も削除を決めたわけでもないのに、ビルドの途中でこっそり取りこぼしてしまうことは簡単に起こる。適合性チェックはあなたが承認したプランを実際の出力と照らし合わせて再読し、そのギャップを発見する。見つかった場合は、修正が自動的に適用・再チェックされる――やることリストを渡されるのではなく、気づかないうちに修正されているか、そもそも問題がないかのどちらかだ。各検証エージェントが何をチェックしているか、そして2回連続で失敗した場合に何が起きるかの仕組みは「ビルドはどう自己検証するか」にある。このセクションから持ち帰ってほしいことは一つ――「完了」とは合格したことであって、生成されたことではない。この2つを同じものとして扱うと、いずれ露出したキーや到達不能なボタンを出荷することになる。
3つのミスをすべて回避すると得られるもの
- クリックして操作できる本物のプレビューにある、実際に動く製品――あなたのデータが実際に組み込まれた稼働中のインスタンスであり、完成イメージのスクリーンショットではない。
- それに紐づくチャットスレッド。「ヘッダーを暗くして統計ページを追加して」と伝えると、バージョン1の隣にバージョン2が生成される。旧バージョンは消えず、新バージョンがライブプレビューを引き継いでいる間、フォールバックとしてそこに残る。
- 実際に機能するボタン群――本番公開、コードのダウンロード、ネイティブインストーラーのビルド、ストアへの出荷。ボタンの姿をしたアップセルモーダルではない。
その「コードをダウンロード」ボタンは、じっくり見る価値がある。それこそが、実物を託せるツールと、使い捨てのプロトタイプにしか使わないツールとを分ける境界線だからだ。コードが本当に自分のものとして持ち出せるなら――読みやすいファイル構造で、実際に頼んだ以上の奇妙なロックインがなければ――そのプラットフォームは、あなたがすでに抜け出せなくなっていることにあぐらをかくのではなく、次のセッションでも選んでもらえるよう努力し続けなければならない。
