Productパイプライン

出力はVision Board(VIS-ID)とPR-FAQ(Amazon Working Backwards形式。プレスリリースを先に書く手法)の2文書です。

• Vision Board: Vision(目指す姿)・Target Group・Needs・Product・Business Goalsの5要素と、Mission(実現の仕方)・Values(判断の軸)。
• PR-FAQ: プレスリリース(見出し→サブ見出し→要約→顧客の言葉での課題→解決策→引用とCTA)に加え、外部向けFAQ(価格・機能・購入・サポート)と内部向けFAQ(市場規模・競合・ユニットエコノミクス・リスク・Go/No-Go基準)。ここで書くGo/No-Go基準は装飾ではなく、validate-assumptionsが実際に強制するゲートになります。
• Domain Vision Statement: コアドメイン(最も価値を生む領域)を1段落で名指しする文書(VIS-IDの一部)。後続のmap-domainsがCoreドメイン分類の判断根拠として引用し、この文書が名指ししていないCoreがあればfindingとして報告します。

出力はNSM-IDの成功指標文書です。North Star Metricを1つ選び(売上の先行指標で、顧客が受け取る価値を表すもの。生の売上や見栄えだけの指標にはしません)、チームが直接動かせる入力指標を3〜5件選んでAARRRまたはHEART(どちらか1つのユーザー行動モデル)にマッピングします。各指標に測定方法・目標値・ガードレールを添えます。このNSM-が、後段のRICEのImpactや収益仮説の基準になります。

出力は市場概観(TAM/SAM/SOM、原則ボトムアップで算出)・競合マトリクス・Kano分類(Must-be→PoP/パリティ、Delighter→PoD/差別化)・戦略提言です。すべての数値・競合・主張に出典(名称+URL)を添えます。

出力はREV-IDの収益モデル文書と、再計算可能な収益評価テンプレートです。Lean Canvas(不確実性の高い新規事業向け)またはBMCの9ブロックで収益モデルを選び、LTV・CAC・LTV(目安3以上)・CAC回収期間・ROI/NPVは数式のまま出力します。価格やCACは確定値ではなく「TBD-assumption(検証すべき仮定)」として扱い、「Xを出せば指標Yがある期間内にZ%動く」という形の価値仮説をNSM-と結びつけて書きます。

出力はCON-IDの制約一覧(予算・締切・技術・法規制・組織)とSCP-IDのスコープ定義です。In-Scope/Out-of-Scopeの表(「やらないことリスト」は必須。スコープが際限なく広がるのを防ぎます)・MoSCoW分類・RICEスコア(NSMがあればImpactの根拠に使う)を作ります。

出力はASM-IDの仮説一覧・検証計画・Go/No-Go判定です。Phase 1の直後に必ず通る検証ゲートです。

出力はNAM-IDのプロダクト名候補集です。Vision・Values・差別化要因・ドメインの語彙から頭文字ごとの英単語バンクを作り、各候補に「短く発音しやすい文字列」と「1文字1単語のフル展開」をセットで示します。命名基準(識別性・短さ・発音しやすさ・適切さ・展開可能性・保護しやすさ)で採点し、3件の絞り込みと1件の推薦をVIS-IDに紐づけた理由とともに出します。商標などの利用可否確認はOpen Questionsとして残し、確認済みとは主張しません。

出力はJOB-IDのジョブストーリー(「[状況]のとき、[目的]したい。それによって[結果]を得たい」という形式。機能的/感情的/社会的の3側面をカバー)と、PER-IDのペルソナカード(アーキタイプ・状況と行動・JTBD・Pains・Gains・生の声の引用)です。実データに基づかない場合は[proto]と明記します。デモグラフィック情報や引用を創作することはありません。

出力はJNY-IDのジャーニーマップです。主要ペルソナごとに、ステージ(認知→検討→購入→オンボーディング→利用→更新→推奨)×レイヤー(タッチポイント・行動・感情の生の声と曲線・痛み・機会)の格子を作り、Moment of Truth(ZMOT/FMOT/SMOT。評価が決まる決定的瞬間)を感情曲線が落ち込む箇所に立てます。実質的な出力は優先順位付きの機会リストです。

出力はPOS-/HOOK-IDのポジショニング文書です。

出力はペルソナ×主要ジョブごとのSTORY-IDドメインストーリーです。特定のペルソナ(PER-)がジョブ(JOB-)を達成する手順を、ジャーニー(JNY-)の順に沿って1本のハッピーパスとして書きます。各ステップは後段のgenerate-ui-mockで画面に変換されます(1アクティビティ=1画面操作)。

Domain Storytelling(業務の流れを図にする手法)の3要素——Actors(登場人物。ペルソナ本人と関わる人・システム)・Work Items(取り扱う対象。ジャーニーやジョブの語彙から命名)・Activities(番号付きの行動)——で構成します。architect側にも同名のスキルがありますが、そちらはレガシー経路の既存アクター定義を起点にする点が異なります。

--mode=event-stormingを指定すると、Process Modeling(ステップごとにイベント・コマンド・実行者・リードモデル・ポリシーを書く)という別の進め方に切り替わりますが、書き出すSTORY-IDやレジストリは変わりません。

出力はdesign-system/{name}/配下に個別管理されるデザインシステムです。パイプラインの1回の実行とは別に、再利用・バージョン管理・入れ替えができるように独立して置かれます。

• トークン: tokens.json(DTCG形式)+tokens.css。色・文字・間隔・角丸・elevation・モーションの生の値と、意味づけされた別名(color.bg/fg/primary/dangerなど)。
• コンポーネント一覧(CMP-ID)・ガイドライン(アクセシビリティ基準を含む)・マニフェスト・プレビューHTML。

ポジショニングやペルソナから新規に組み立てる(build)か、既存のTailwind/DTCG/Figma Tokens/CSSテーマを取り込む(--import)かを選べます。ここで作った「見た目の言語」をgenerate-ui-mockが使います。

出力はreports/02_spec/ui-mocks/配下の、クリックで画面遷移できるナビゲート可能なHTMLモック(1画面=1ファイル、インラインCSS)です。

• 各画面は、対応するドメインストーリーの各アクティビティから導出されます(1アクティビティ=1画面操作)。優先度の高いジョブについては、2〜3案を簡単に比較して1つを選んだ根拠も記録します。
• 画面遷移は実際の<a href>で結線されているため、ストーリーの最初から最後までクリックで通しで確認できます。存在しないステップは無効化されたTBDリンクになり、リンク切れにはなりません。
• デザインシステムのtokens.cssが各画面に注入され、すべてのモックが同じ見た目の言語を共有します(midフィデリティならコンポーネントのスタイルも適用)。

出力はFEAT-IDの機能一覧です。UIモックの各画面操作をCommand(実行できる機能の単位)に変換し、スコープと突き合わせて(Out-of-Scopeの項目は最初から除外)、JOB-/JNY-/NSM-への根拠づけとMoSCoW優先度を付けます。UIモックが空の場合は実行を止めます。

同じfeature-list.mdにUser Story Map(ジャーニーのステージを背骨に、FEAT-をストーリーとして並べ、MoSCoWの帯をリリース区切りにした図)も書きます。新しい判断を加えるものではなく、既存の機能一覧を別の切り口で見せるビューです。

出力は機能(FEAT-)ごとのRULE-(業務ルール)・EX-(ルールの両側の具体例)・セッションで決着しなかったOQ-(Open Questions)です。4色カード(ルール/例/疑問/機能)によるExample Mappingセッションの進め方と、実例をどこから拾うか(既存の受入基準・ドメインストーリー・ペルソナの発言など)をrules/product/example-mapping.mdが定めます。

このRULE-/EX-は、generate-test-specsではRule:/Scenario:ブロックに、export-backlogでは受入基準に、design-aggregateでは不変条件の候補に、define-requirementsではFRの受入基準に、それぞれ変換されます。

出力はENT-IDのデータモデルとMermaid ER図です。

出力はgenerated/frontend/配下の、npm install && npm run storybookだけで動くReact + TypeScriptのフロントエンド一式です。UIモックが「各画面が何をするか」、デザインシステムが「見た目の言語」を決め、このスキルが両方を実際のコンポーネントに変換します。

• デザインシステムの各コンポーネント(CMP-)を、Atomic Designの適切な階層(atoms/molecules/organisms/templates)に配置します。コンポーネントごとに.tsx(型付きprops)・.module.css(トークンだけを参照。生の値は書きません)・.stories.tsxを生成します。
• 各UIモック画面が1つのPageコンポーネントになり、ストーリーの遷移(次へ/戻る)はreact-routerで実際のルーティングとして結線されます。

出力はドメインマップ(サブドメインをCore/Supporting/Genericに分類し、投資方針〈Coreは自作・Supportingは実用的に・Genericは購入〉を示す)・CTX-IDの境界コンテキスト(コンテキストマップ〈ACL・Open Host/Published Language・Shared Kernel・Customer/Supplier・Conformist・Partnershipという関係パターン〉と、粗い一貫性のヒント〈Strong/Eventual/TBD〉)・ユビキタス言語です。

一貫性のヒントはあくまで「ヒント」で、architect側のdefine-requirementsが業務プロセスごとの最終的なACID/Saga/ローカルトランザクションの判定を行います。architectにも同名のmap-domainsがありますが、そちらはanalyzeの分析結果からドメインを分類するもので、入力が異なります。

各境界コンテキストは9項目のBounded Context Canvasとして記述され、architect側で再設計された同じCanvasと項目ごとに比較できます。--mode=event-stormingを指定すると、Big Picture EventStorming(イベントの時系列を並べ、転換点となるイベントを境界の候補にする)という別の進め方で境界を見つけられます。

出力はAPI-IDのAPI設計文書です。System(CRUD)・Process(業務フローの調整)・Experience(チャネルごと)という3階層でAPIを分類し、Experience→Process→Systemの一方向の依存関係グラフと、各APIのOpenAPIスケッチ(主要なパス・メソッド・リクエスト/レスポンスの形)を作ります。再利用の最大化が狙いで、architect側のdesign-apiが後でこれを具体的なプロトコル・仕様に落とし込みます。

出力はSLA-/SLO-IDのサービスごとのSLI/SLO/SLA、エラーバジェット(1−SLO)とその運用方針、重要度階層(critical/standard/best-effort)です。目標は顧客の期待に合わせ、SLOはSLAより厳しく設定します。

出力はNFR-IDの非機能要件(可用性・レイテンシ〈p95/p99〉・スループット・エラー率・耐久性・RPO/RTO、必要に応じてスケーラビリティ/セキュリティ/可観測性も)です。各NFRには数値(またはTBD)と、導出元のSLOを明記します。

出力はARCH-IDのアーキテクチャ文書(ランタイム/コンテナ図・クリティカルパスのシーケンス図・デプロイ/スケーリング図)と、TECH-IDの技術適合性評価です。

Kong(APIゲートウェイ)・ScalarDB・ScalarDB Analytics・ScalarDB Saga・ScalarDLの5つについて、適合度(High/Medium/Low/None)・判断の根拠(引用元のID)・Adopt/Conditional/Rejectの決定・採用条件とリスクをそれぞれ評価します。ScalarDB Sagaは「コンテキストをまたぐ処理が結果整合でよい場合」または「外部システムを呼ぶステップがある場合」に検討対象になり、ScalarDB自体を採用したからといって自動的に採用されるわけではありません。

出力はreports/report/review.mdです。一貫性(IDの参照切れ・矛盾・用語のブレ)・トレーサビリティ(work/traceability.jsonと文書の対応、孤立参照)・拡張性(将来の機能に対するドメイン境界とAPI再利用性)・戦略(Visionとスコープの整合、ユニットエコノミクスの健全性、差別化の持続性)の4つの視点から、重大度(blocker/major/minor)・場所・具体的な直し方を伴うfindingsを出します。パイプラインの途中でも何度でも再実行できます。

出力はreports/report/full-report.htmlという自己完結型のHTMLレポート(Mermaid図もインライン)です。「重要な仮説と検証状況」を必ず先頭に置きます——ゲートの判定・未検証の仮説・すべてのTBD・Open Questionsをステータス別に並べ、「誰にも聞かれていない疑問」と「意図的に保留した疑問」を見分けられるようにします。その後にフェーズ順で各セクションが続きます。

出力は変更ログ・影響分析・更新済みの成果物です。work/traceability.jsonから影響範囲を計算し(下流への到達範囲の機械的な洗い出し → opusによる判断 → 人間への確認)、影響を受けたスキルだけを再実行します。architect側が持つIDへの影響は「報告するだけ」で、ここでは再実行しません。

productパイプラインを動かすために必要なディレクトリ構造と状態ファイル(work/pipeline-progress.json、トレーサビリティグラフなど)を作ります。既存の状態を--resetなしに勝手に破棄することはありません。

このスキルが依存関係の順にフェーズを実行してくれるので、個別のスキルを1つずつ呼ぶ必要はありません。