visant-preflight

Visant Preflight

プロジェクトは、実行段階で失敗することはめったにありません。失敗するのは前提の段階です。最初から間違っていたデータに基づいて仕事をうまく仕上げても、やり直しに何日もかかります。

大きな仕事を始める前に、必ず済ませておくことが2つあります。質問ラウンドへの回答と、5つのチェックがすべて緑になること、または明示的に免除されることです。

プリフライト全体にかかる時間は15分です。これで防げるミスは、どれもすでに1日以上のコストを生んでいます。詳しい事例はreferences/cases.mdをご覧ください。

実施するタイミング

失敗すると痛手になるほど大きなタスクに取りかかるときに実施します。新規サイト、リデザイン、モックアップを含む提案、キャンペーン、ブランドの補強、移行などが対象です。最初のクライアントフィードバックまでに、半日以上の作業が発生するものが目安です。単発の微調整には不要です。小さなタスクにプリフライトを適用するのは官僚的な手続きであり、やがて（当然ながら）実施しなくなります。

---

パート1：質問ラウンド

このパートは任意ではなく、自動化もできません。 最もよく抜け落ちるパートです。

何かをデザインする前に、以下の質問を仕事の責任者（クライアント、アカウントリード、プロジェクトオーナー）に尋ね、回答を書き留めてください。回答がないものとして進めます。「何でもいい」と答えられたら、「何でもいい」と書き留めてください。それも回答です。暗黙の賭けではなく、明示的な自由になります。

選択肢が限られている質問にはハーネスの質問ツールを使い、自由回答の質問には会話を使います。質問は1回でまとめて行い、作業中に小出しにしないでください。作業中に尋ねた質問への回答は、その質問が防げたはずのやり直しが発生した後にしか返ってきません。

1.1 賭け

• この仕事が証明すべきことを、1文で言うと何ですか？ 1文に収まらないなら、スコープはまだ確定していません。
• どのビジネス指標を動かすものですか？ コンバージョン、リテンション、客単価、商談あたりのコストなどです。どれも動かさないなら、それは装飾です。装飾には注意を払う必要があります。
• 相手は誰で、どの認知段階で訪れますか？（Schwartzについては、revenue-centric-designを参照してください。）見出しは現在の段階に訴え、証拠によって次の段階へ進めます。
• やらないことは何ですか？ 最も時間を節約できるのに、誰も尋ねない質問です。

1.2 参考資料と好み

• クライアントがすでに承認したもの（レイアウト、制作物、キャンペーン）で、一から作り直さず引き継ぐべきものはありますか？ デザインを始める前に確認してください。
• 嫌いなものはありますか？ 好きな参考資料を10個聞くよりも重要です。
• このブランドで変えてはいけないものは何ですか？ ブランド独自のグラフィック表現を一般的なものに置き換えた「すっきりした」バージョンは、ひと言で元に戻されます。
• 情報量はどの程度で、今回のラウンドに写真を入れますか？ 「テキストが多すぎる、画像がない」という理由で3つの提案を作り直すのは、この確認を省いたときによくあるコストです。
• いくつの案を見たいですか？ 仕上げた1案か、方向性の異なる3案か。必要な作業が違うため、先に合意すれば形式の選択を誤らずに済みます。

1.3 公開を妨げるもの

• まだ第三者に依存しているものは何ですか？ コピー、写真、数値、法務確認、ドメインなどです。
• そのうち、クリティカルパス上にあるのはどれですか？ これによって作業順が決まります。誰にも依存しないものから始めてください。
• 規制上の制約はありますか？（専門職団体、保健機関、証券関連、LGPDなどのプライバシー法。）レイアウトが完成してから判明すると、レイアウトを作り直すことになります。

1.4 完了の定義

• どこで見られるものですか？ 公開リンク、PDF、Figma、電話での確認などです。すべてが変わります。
• 公開するものですか、それとも提案ですか？ 提案なら、noindexを設定し、機密性のある実データは使わないでください。
• フィードバックの打ち合わせはいつですか？ これによって作業の深さが決まります。

パート1で必須となる成果物： プロジェクトの.mdに回答を書き記してください。最初のコード行を書く前、または最初のフレームを作る前に済ませます。会話の中だけにとどまった回答は、翌週には前提になってしまいます。

---

パート 2：5 つのチェック

中間の 2 つ（フォントと写真）は自動化されています。

node ~/.claude/skills/visant-preflight/scripts/preflight-scan.mjs \
  --assets "<client files folder>" \
  --fonts "Display Family,Body Family" \
  --report PREFLIGHT.md

このスクリプトは依存関係のないシンプルな Node スクリプトで、Visant 固有の要件はありません。

フラグ	機能
--assets <dir>	任意のローカルフォルダー（同期済みの Drive、Dropbox、リポジトリの public/ など）を走査し、すべての .png .jpg .jpeg .webp .avif .gif .svg を幅、容量、対応する役割とともに一覧表示します。PNG、JPEG、WebP はサイズを測定し、SVG はベクターとして一覧表示します。ヘッダーを読み取れないファイルは、理由とともに「スキップ」リストに表示します
--fonts "A,B"	各フォントファミリーを Google Fonts と照合します（ネットワークが必要です。オフラインの場合は判定不能と表示されます）
--report <file.md>	出力を Markdown ファイルにも書き込みます
--strict	項目に不合格がある場合は終了コード 1 で終了します（2000px に達する画像がない、またはフォントが Google Fonts にない、もしくは確認できなかった場合）
--self-test	スクリプト独自のパーサーとしきい値を検証します

--assets または --fonts のいずれかが必須です。どちらも指定しない場合は使用方法を表示し、終了コード 2 で終了します。出力は英語です（Markdown レポートには写真の表、スキップ一覧、フォントの表が含まれます）。

1. ブランドの信頼できる情報源：複製されたデータは一致していますか？

再利用のためにブランドデータが保存されている場所（ブランド保管庫、トークンファイル、ガイドライン文書など。Visant の場合は Visant Labs の保管庫）は、信頼できる情報源ではなく、その複製です。複製は古くなったり、最初から間違っていたりします。クライアントに実際に納品したファイル（Drive 内のブランドフォルダーなど、保存場所を問わず）およびデザインファイル（Figma）と照合してください。

次の順番で確認します：タイポグラフィ、色、ロゴ、タグライン。内容が食い違う場合、保存された項目よりも、クライアントが受け取ったフォルダーのほうが強い証拠です。

Visant の保管庫を監査して調整するには、[[visant-brand-sync]] を読み込んでください。

ブランドが実際に納品したことのない書体が、数か月にわたって 3 種類の誤った書体として使われました。誰もクライアントのフォントフォルダーを開かなかったためです。references/cases.md を参照してください。

2. フォントは読み込まれますか？

スクリプトで自動化されています。Google Fonts にないフォントファミリーが、必ずしも間違いとは限りません。有料ライセンスの書体を使うことは正当な選択です。許されないのは、それがひそかに消えてしまうことです。ファイルを用意して next/font/local または @font-face で読み込むか、フォントファミリーを変更してください。

典型的な兆候：レイアウトは「正しい」のに、サイトが別のブランドのように見えます。

プロジェクトが Visant の @visant/brand-tokens を使う場合、トークンエンジンがソースでこのチェックをすでに行います。読み込み可能なものには @import を出力し、読み込みできないものは CSS の先頭で宣言します。

3. 写真はレイアウトに適していますか？

スクリプトで自動化されています。解像度と対応する役割を添えてすべての画像を一覧表示し、スキップしたものも明示します。

役割	ファイルの最小幅
全幅の帯	2000px
ヒーローのポートレート	1000px
グリッドのセル	700px
サムネイル	400px

トリミングを決める前に、解像度を基準に元画像を選んでください。順番を逆にしてはいけません。拡大は見てわかりますし、レイアウトの工夫で小さなファイルを補うことはできません。

そのため、スクリプトではフィルターをかけた結果を黙って隠さないというルールを設けています。隠してしまうスキャンは、実行されないスキャンよりも悪い結果を招きます。誤った安心感を生み、その誤った安心感が判断につながるからです。隠されていた 4562px のオリジナル画像の事例：references/cases.md。

4. ブランドファイルは本当にありますか？

ロゴはプレゼンテーション用の PNG ではなく、ベクター形式（SVG/PDF）で用意します。ライト版とダーク版、ファビコン用の正方形アイコン、ブランド独自のグラフィック要素も必要です。

存在しない場合は、ブランドを描き直さず、提供を依頼してください。おおよその見た目を頼りに描き直したロゴは、最もコストの高い失敗であり、元に戻すのも最も困難です。

5. すべての数値に出典がありますか？

公開されるすべてのデータについて、コンテンツファイル内で、そのすぐ隣に出典を記載する必要があります。レイアウトから拾った数値は一次資料ではありません。保留中と明記して公開するか、公開しないかのどちらかです。

裏付けのない数値は証拠ではなく、責任問題になります。クライアントから出典を尋ねられたとき、答えはデータと一緒に提示できなければなりません。作成した人の記憶の中にあってはいけません。

---

パート 3：傷跡を残し、すでに潰したバグを再び持ち込まない

視覚的な不具合の修正は、その理由とともに、修正箇所のコード内のコメントとして残します。そして、その修正を失う具体的な方法があります。それはファイル全体を書き直すことです。書き直しは古いファイルではなく、新しい意図から始まるためです。

簡単に守れるルールは 2 つです。

1. ファイルを全面的に書き直す前に、そのファイルを読み、防御的なコメント（「不透明な背景が必要」「ブラウザーで測定済み」「置き換えないこと」「これがないと X が壊れる」などのコメント）を列挙します。それぞれを新しいバージョンに引き継ぐか、適用されなくなった理由を文書に記載します。
2. ブラウザーで見つかった修正はすべて、プロジェクトの .md の「傷跡」セクションに記載します。それが書き直しや担当者の交代を経ても残るものです。

## Scars
- The bar field belongs to the hero: the proof band needs an opaque `bg`, or the
  decoration cuts through the number. (measured, 08-13)
- Light nav over a light field disappears. Two-tone nav → logo + action only.
- Photo: choose the source by resolution BEFORE framing.

自動検出機能にしなかった理由： 行単位のルールでは、実際のケースと、正当な数多くの境界ケースを見分けられません。対象外のケースまで警告する検出機能は、いずれ無効にされます。傷跡を文書に残す手間は 1 行で済み、誤検知もありません。詳しくはこちら：references/cases.md。

---

レポート

プリフライトの最後に、プロジェクトの .md 内に次のブロックを記載します。

## Preflight: <date>

**The bet:** <the single sentence>
**Variable:** <what it moves>
**Not to be done:** <what was left out>
**Delivery format:** <link / proposal / PDF>, feedback on <when>

| Check | Status |
|---|---|
| Brand source of truth | ✅ / ⚠ <what diverged> |
| Loadable fonts | ✅ / ⚠ <family and plan> |
| Photo resolution | ✅ ceiling <N>px / ⚠ <what cannot be done> |
| Brand files | ✅ / ⚠ <what is missing> |
| Sourced numbers | ✅ / ⚠ <what is pending> |

**Critical path:** <what blocks publishing and who it depends on>

⚠ があっても、作業を始めることはできます。ただし、存在しないふりをすることはできません。また、順序も明確になります。ブロックされている項目に依存しない作業から始めます。

---

基本原則

ここにあるすべてのチェックは、実際に起きたミスから生まれました。 6 つ目を追加するのは、誰かの作業時間を 1 日奪う問題が起きてからです。1 年間まったく何も検出しなかったチェックは削除します。何も警告しないチェックリストがあると、内容を読まずに署名する習慣が身についてしまいます。

関連項目

• [[visant-brand-sync]]：プリフライトで不整合が見つかったときに、Vault を調整します
• [[visant-new-site]]：このプリフライトから始まるクライアントサイトのフローです
• [[revenue-centric-design]]：認知段階、ICP、証拠です
• [[visant-frontend]]：プリフライトに合格した後で、対象の種類を分類します
• [[visant-killer]]：最後の終了ゲートです。こちらは開始ゲートです