マニュアル: ビルドチャット

失敗その1：目的地を間違った単位で説明する

ビルドチャットで最も無駄になるラウンドは、狙う「高さ」を間違えることから生まれます。それも正反対の2方向で起こります。ある人は本来伝えたいことより少ない情報しか伝えません——「デザインを良くして」「もっと良くして」「なんか違う」。これらはすべて、ターゲットのない診断です。次のバージョンは推測になります——ヘッダーを暗くするかもしれないし、フォントを変えるかもしれないし、ナビを再構成するかもしれない。結果を見て「これは何だ」と首をかしげるまで、理由は分かりません。逆に伝えすぎる人もいます——セッションクッキーやCSSグリッド、ローディングスケルトンコンポーネントなど、少し知識があるために親切心から具体名を挙げてしまいます。この失敗はより静かですが、コストは同じくらい高くつきます。実装方法を指定した瞬間、たいていそれは間違った指定になっているか、良くてもあなた個人がすでに知っている範囲まで解決策を狭めてしまっています——現役の開発者でない限り、それはビルダーが自力で試すであろう範囲より狭いものです。そして、あなたが指定したライブラリやパターンが間違った選択だったと分かれば、それはあなたが持ち込んだバグになります。結果だけを起点に動いていれば、ビルダーが決して犯さなかったはずのバグです。

解決策はこの2つの失敗の間にあります。実現の仕組みではなく、今見ているものと見たい変化を名指しすることです。「アカウントを作らなくても予約できるようにしてほしい」は、セッションクッキーについての段落より優れています。なぜなら、あなたが本当に望んでいるのは摩擦をなくすことであり、そこに至る方法はおそらく考えもしなかった方法が3つはあるからです。「料金表が分かりにくい」だけではまだ薄すぎます——どう分かりにくいのか？——ですが、「年間プランがお得だと伝わっていない、割引を細字に埋もれさせずに価格の隣に出してほしい」なら、ビルダーが対処できる具体的な材料になります。修正がどんな見た目になるべきか分からなければ、それでも構いません。何が問題かだけ伝えて、形はビルダーに提案させましょう。うまくいかないのは、拠り所のない漠然とした不満だけです。それは以降のすべてのバージョンを当てずっぽうのゲームにしてしまいます。

失敗その2：バージョンそのものではなく、要約に反応する

2つ目のつまずき方は、実際の変更内容ではなく、チャットが要約した変更内容に対して反応することです。ある人は「スケジュールを専用ページに移動し、ヘッダーを暗くした」と読んで頭の中にイメージを作り、実際のサイトではなくそのイメージに対してフィードバックを書きます。「これは間違っている」という苦情の多くは、実は「まだプレビューを開いていなかった」だけだったと判明します——結果は問題なかった、あるいはほぼ問題なかったのに、異議の実態は思い込みに対するものだったのです。入力する前にクリックして確認するのに30秒ほどしかかかりませんが、このステップを飛ばすことが、本来存在しなくてよかったラウンドの最大の原因になっています。会議中にスマホからレビューする場合でも、まずプレビューをちらっと見てください——説明の説明に対するフィードバックは、誤差を急速に積み上げます。

関連する失敗は、無関係な要求を1つのメッセージにまとめてしまい、何が何を引き起こしたのか判別できなくなることです。関連する要求をいくつも積み重ねて、1つの新しいバージョンに全部反映させることは全く問題ありません——ヘッダーを直し、スケジュールを移動し、モバイルナビを引き締める、という一連の変更を一度に反映したビルドは、3つの別々の差分よりレビューしやすいです。動いているターゲットに対する3つの差分ではなく、サイトの1つの筋の通った状態を判断すればいいからです。問題が起きるのは、要求同士が無関係なときです。スケジュールページの大幅な見直しとグローバルなカラー変更を1つにまとめてしまうと、結果に何かおかしいと感じても、どちらが原因なのか本当に分からなくなります——新しいレイアウトのせいで読みにくくなったのか、新しい配色のせいなのか？それを切り分けるには、フォローアップのメッセージと変数を特定するためだけの、まるまる1ラウンドが必要になります。「スケジュールページに関するすべて」を1つのメッセージにまとめ、「配色の方向性」を次のメッセージに分けておけば、両方を組み合わせることを妨げるものは何もないのに、それぞれのバージョンがきれいな比較対象のまま保たれます。そして必要な1点だけを元に戻したり調整したりできます。1か所が外れたせいで他が良好なバージョン全体を捨てずに済みます。

失敗その3：各バージョンを使い捨て扱いする

3つ目の失敗は、バージョンカードが単なる領収書ではなく作業対象そのものであることを忘れ、そこに実際に用意されている機能を素通りしてしまうことです。完了した各ラウンドは、実際に動くプレビュー付きのカードを生成します——スクリーンショットではなく実際に稼働しているインスタンスなので、その中のボタンをクリックすれば、本番と同じ動作をします。コードタブでは変更されたすべてのファイルを閲覧できます。これは、技術的な理解があってピンポイントで何かを確認したい場合（このフォームは本当に正しいエンドポイントにPOSTしているか？）に、チャットの返信を待たずに済むので重要です。ダウンロードでは生のファイルを取得できます。そしてアクションメニューこそ、バージョンが単なる下書きから抜け出す場所です——本番公開、アプリならネイティブインストーラーのビルド、ストアへの配信、今後のビルド用テンプレートとしての保存、あるいはスタンドアロンでのデプロイができます。

これらすべてを飛ばしてしまう人は、旧バージョンでボタンが青かったかどうかを記憶に頼って思い出そうとする羽目になります——旧バージョンを開いて見ればいいだけなのに。カードを使い捨て扱いすることの弊害は、まさにこれです。ワンクリックで確認できることを記憶に頼ってしまうのです。バージョン7が公開されても、バージョン4はアーカイブされたり凍結されたりしません。そのプレビューは動き続け、コードタブも閲覧でき、アクションメニューも永久に動作します。2つのバージョンを比較するのは差分を読む作業ではなく、両方のプレビューを並べて開いて操作してみる作業です。カードにはそのビルドの検証記録も付いています——それが完了として渡される前に実際に動作することを確認する自動チェックのことで、その特定のバージョンに紐づいています。旧カードが残り続けることが重要な理由がもう1つここにあります。バージョン6は検証をクリアし、バージョン7はしなかったとすれば、あなたは「直しました」というチャットのメッセージを鵜呑みにする代わりに、両方を比較できるのです。

「ワークフローをざっと流し見して使わない」という同じ性質は、各ビルド後にチャットが提案するフォローアップ案を無視することにも現れます。それらは汎用的な埋め草ではなく、ビルド自体から導き出されたものなので、自分1人で見返しては見落としがちなものを拾い上げてくれます——誰もデザインしなかった空の状態、送信の確認をしないフォーム、デスクトップでは問題ないがモバイルでは窮屈なページ、などです。必ず採用する必要はありませんが、目を通すだけならコストはかかりません。すべてのページを自分でクリックして回る時間がない場合、それなりのQA代わりになります。