Failure Patterns — 失敗しやすいパターン

「まだ事故になっていないが構造的に危ない」ものも含める。事故ってから書くのでは遅い。

FP-001 顧客検証の前に作り込む

• 症状: ユーザー0人の段階で、正典1,604行・ADR6本・状態機械15段・価格設定まで到達する。
• なぜ起きるか: 0→1で作る作業そのものが楽しく、設計を詰める行為が「前進している感」を強く出すため。
• 早期警告サイン: ①ドキュメントの整合作業（番号振り直し等）を始めたら黄信号 ②「あと1機能だけ」が2回続いたら赤信号
• 対処: 実ユーザー1人に当てるまで新機能を書かない、というルールで止める。
• 観測: 2026-08-14 seicho-tasukeru

FP-002 スコープの逐次膨張

• 症状: 動くものを見た直後に、設計思想から外れる機能を次々追加する。
• 観測: 2026-08-14 mise-list（「決めるためのアプリ」に、貯める側の機能を7分で4件追加）
• 対処: 追加要望はその場で実装させず、ideas.md に落として翌日判断する。

FP-003 自分向けだけ安全基準が緩む

• 症状: 顧客・ユーザー向けには構造で守るのに、自分の作業環境では「注意」で済ませる。
• 観測: 2026-08-14（禁止語・状態機械まで作った同じ日に、自分の環境の送信/デプロイ系を無言承認化）
• なぜ危険か: 事故は自分側から起き、しかも顧客の信頼を直撃する。
• 対処: 月1で「顧客に課しているルールを自分にも適用しているか」を機械的にチェックする。
• 是正済み（2026-08-14 同日）: auto-approve hook を3層化。メルマガ配信＝deny、外部送信・本番デプロイ＝ask。指摘から是正までが同日というのは良い反応速度。ただし「作る前に安全境界を考える」段階には至っていない。

FP-004 運用設計（ログ・リトライ・監視）の先送り

• 症状: デプロイまでは到達するが、障害時の設計を1行も書かない。
• なぜ起きるか: north-star.md §3 で本人が「説明できない」と自認している領域＝苦手だから後回しになる。
• 前例: minutes-agent の6日間沈黙事故（2026-05-19）。ハートビート監視を後付けした。
• 対処: 新しい cron / 常駐処理を作った日は、その日のうちにハートビート登録まで完了させる（既存ルール）。
• 観測: 2026-08-14（外部依存4つ増、監視設計ゼロ）

FP-005 顧客接点ゼロの日を作る

• 症状: 丸1日稼働して、新規・既存いずれの顧客とも接触しない。
• なぜ危険か: 営業6年・全国トップセルという最大の武器が、その日1ミリも使われていない。作る力だけが伸び、売る力が止まる。
• 対処: 「今日の顧客接点は？」を daily の必須項目にする（→ §13 A の判定）。
• 観測: 2026-08-14

FP-006 並列数の上限を決めずに走る

• 症状: 待ち時間ゼロを追求して、自分が状態を把握できる本数を超える。
• 観測: 2026-08-14（15セッション、取り違え1回）
• 対処: 「同時に把握できるのは案件3件まで」など、実測で上限を決める。まだ上限を測っていない。