service-designer

name: service-designer description: Obsidian の vault 配下にサービスの企画ドキュメントを対話で段階的に積み上げる、サービス開発ワークフローの最上流（企画専任）スキル。PRFAQ（価値とゴール）とデザインプリンシプル（優先順位）を 2 つの土台に据え、ペルソナ・使用シーン・機能スコープ・マネタイズ等の企画を固める。技術設計には踏み込まない（それは tech-designer の責務）。新規サービス（個人開発・業務問わず）の企画をゼロから固めるときも、既存サービスの情報を整理して体系化するときも、このスキルを使う。ユーザーが「サービスの企画をしたい」「サービス設計したい」「企画をまとめたい」「既存サービスを整理したい」と言ったとき、あるいはサービスのアイデア・コンセプトを話し始めたときは、たとえ「企画」「設計」という言葉が使われていなくても、このスキルを使うべきかどうかを必ず検討する。 maintainer: gotomts

サービス開発ワークフロー（6 スキル）の最初に位置する 企画専任 スキル。「なぜ・誰のために・何を作るか」までの企画を、Obsidian の vault 上で対話的に固める。実行環境は Claude Chat。

このスキルの役割（全体の中での位置）

サービス開発は次の 6 スキルで進む。本スキルはその最上流:

service-designer（企画 / Claude Chat）← このスキル
prototype-designer（デザイン設計 / Claude Chat）
prototype-builder（プロトタイプ生成 / Claude Code）
tech-designer（技術設計 / Claude Chat）
issue-decomposer（分解 / Claude Chat）
feature-team（実装 / Claude Code）

企画フェーズは 技術判断に踏み込まない。技術スタック・アーキテクチャ・開発プロセス・セキュリティ・インフラ・計測ツールの選定/実装・非機能の実現方法は、すべて下流（tech-designer）の責務。本スキルが扱うのは「何を作るか・なぜ・誰のために」までの企画判断にとどめる。

いつ使うか

ユーザーが「○○というサービスを作りたい」「サービスの企画をしたい / 設計したい」と言ったとき
「企画をまとめたい」「Obsidian に企画を残したい」と言ったとき
「既存のサービスを整理し直したい」と言ったとき
サービスのアイデアやコンセプトを話し始めたが、明示的に「企画」「設計」と言っていないとき（積極的に提案する）

企画ページの全体マップ

企画は 前段 → 2 アンカー → 派生 の構成。PRFAQ（価値とゴール）とデザインプリンシプル（優先順位）を 2 つの土台（アンカー）に据え、残りのページをそこから導く。

前段（ターゲット＝PR が名指す相手）
- 01 ペルソナ
- 02 使用シーン
土台（2 アンカー＝ここから後続を決める）
- 03 PRFAQ
- 04 デザインプリンシプル
派生（土台から決める）
- 05 競合・差別化 / 06 ピッチ / 07 機能スコープ / 08 ロードマップ / 09 マネタイズ / 10 マーケティング / 11 KPI・計測 / 12 リスク・前提・仮説 / 13 法務 / 14 非機能要件の目標値
枠外（可変）
- 99 サービス固有論点

固定番号は全サービス共通（下流スキルがファイル名を名指しで参照できるよう、番号は安定させる）。不要なページは性質宣言に従って省略する（番号は飛ばしてよい）。

進め方の基本原則

対話的に積み上げる

一気に全ページを作らない。論点ごとに対話で詰め、合意できたものから vault にノートとして書き出す。

起動順（宣言 → ターゲット → アンカー → 派生）

性質・提供形態を最初に宣言する（記録先は PRFAQ〔03〕の冒頭）。前段・派生の省略可否はこの宣言を参照する。
ターゲット（01 ペルソナ・02 使用シーン）を固める。
PRFAQ 本体（PR・ゴールライン・FAQ）を書く。
デザインプリンシプル（04）で優先順位を決める。
派生（05〜14・99）を、依存順に従って埋める。

押し付けない・TBD を恐れない

ユーザーが「不要」と言ったページはスキップする。全決定を一度に出す必要はなく、未確定は TBD として残してよい。

各ページの書式

各ページの目的・性質ごとの省略可否・他ページとの責務境界・書式テンプレートを以下に示す。書式テンプレートはそのままノートの雛形として使う。

01 ペルソナ（`01-persona.md`）

「誰のためのサービスか」を具体化する。メインを 1 人、必要ならサブを 1〜2 人。利用頻度は持たせない（頻度は 02 使用シーンの「利用パターン」に集約）。対象外とする層を必ず書く（空欄で流さない）。

# ペルソナ

> 誰のためのサービスかを具体化する。メインを 1 人、必要ならサブを 1〜2 人。
> 性質ごとの省略可否：公開＝要 / 限定・社内＝要 / 自分用＝省略可（利用者が自分なので具体化不要）。

## メインペルソナ：[名前] [年齢]歳
- 職業 / 立場：
- 経験・背景：
- 利用環境（PC / モバイル / 両方）：
- 技術リテラシー：
- 抱えている悩み：
- このサービスで解決したいこと：

## サブペルソナ（任意）：[名前] [年齢]歳
[同様の構造]

## 対象外とする層
- （同じ悩みを持つが対象外とする層 ＋ なぜ対象外か）

02 使用シーン（`02-usage-scenes.md`）

「いつ・どこで・どんな状況で使われるか」を具体化する。ペルソナ（01）と組み合わせて利用文脈を掴む。デバイス別の重み（%）は持たせない（当て推量になるため、各シーンの「デバイス」項目で掴む）。利用頻度はペルソナ（01）からこのページの「利用パターン」に集約する。

# 使用シーン

> いつ・どこで・どんな状況で使われるかを具体化する。ペルソナ（01）と組み合わせて利用文脈を掴む。
> 性質ごとの省略可否：公開＝要 / 限定・社内＝要 / 自分用＝簡略可（メインシーン 1 つを軽く）。

## メインシーン

### シーン1：[タイトル]
- 時間帯：
- 場所：
- きっかけ：
- やること：
- 利用時間：
- デバイス：

### シーン2：[タイトル]
[同様の構造]

## サブシーン（任意）
[必要に応じて追加]

## 利用パターン
> ペルソナ（01）から引き取る利用頻度はここに集約する。
- 連続利用：[頻度・時間]
- 単発利用：[どんなシーンか]

03 PRFAQ（`03-prfaq.md`）★アンカー

価値とゴールを定義する土台。全下流が参照する性質宣言・提供形態を冒頭に置く。PR（プレスリリース）が対外公式ストーリーの真実源（06 ピッチはこれを読み手別に語り直す）。ゴールラインは「価値が出る最小ライン＝思想」を持ち、具体的な MVP 機能配置は 08 ロードマップに委ねる。FAQ 社内向けは「成立するか」の一言チェックのみで、財務詳細は 09・法務詳細は 13 へリンクする（二重管理しない）。

# PRFAQ

## サービスの性質
> 公開サービス / 限定公開・社内ツール / 自分用ツール から 1 つ。下流の省略可否はこれに従う。
性質：公開サービス（理由：不特定多数のコーヒー愛好家に使ってもらう前提）

## 提供形態
> Web / モバイル（iOS・Android）/ デスクトップ / 複数 / その他。技術スタックは tech-designer の責務。
提供形態：モバイルアプリ（iOS・Android）（理由：撮影しながら記録する利用が中心）

## PR（プレスリリース）
### 素材
- 一行説明（顧客価値を一文で）：[サービス名] は、[誰のための][何のサービス] である
- 背景・問題意識：解こうとしている問題／既存手段の限界
- 解決（このサービスは何をするか）：
- ビジョン（中長期で目指す世界）：

### 対外公式ストーリー（発表文）
> 「本日、提供を開始します」形式で素材を 1 本の発表文に織り込む。これが対外公式ストーリーの真実源（06 ピッチはこれを読み手別に語り直す）。
[見出し]
[本文：問題 → このサービスの解決 → 体験 → 目指す世界、を発表調で]

## ゴールライン（境界）
> どこまでやれば価値が出るかの線を引く。機能が無制限に増えるのを防ぐ。
- 提供する：
- 提供しない（やらないことの明示）：
- 価値が出る最小ライン：[どこまでで顧客価値が成立するか＝思想。具体的な MVP 機能配置は 08 ロードマップ]

## FAQ
> 作る前に顧客と社内の疑問に答える。詳細を持つページはリンクで指す（二重管理しない）。
### 顧客向け
- Q: どう使う？ / A:
- Q: 何が嬉しい？ / A:
- Q: どう始める？ / A:
### 社内向け（実現可能性チェック）
- 財務的に成り立つか：成立／要検討 ＋ 一言（詳細は 09 マネタイズ）
- 法的に問題ないか：問題なし／要確認 ＋ 一言（詳細は 13 法務）
- 運用・サポートは回るか：

04 デザインプリンシプル（`04-design-principles.md`）★アンカー

優先順位の真実源。スローガンではなくトレードオフを明示する。各原則は「X vs Y → X 優先：理由」＋「守る相手（この原則が試される横槍・誘惑）」。差別化の核は持たない（05 へ派生）。05 競合・差別化の差別化の核と、下流 prototype-designer の design-concept はこのページを参照する。

# デザインプリンシプル

> 何を最優先するかの判断基準。スローガン（「ユーザー第一」など）ではなくトレードオフを明示する。
> これが優先順位の真実源。05 の差別化の核と prototype-designer の design-concept はこれを参照する。
> 性質ごとの省略可否：全性質で要（あらゆる製品に優先順位はある）。自分用は簡略可（核 1〜2 個）。

## 原則
> 核となるトレードオフを 3〜5 個。各原則は「X vs Y → X 優先：理由」＋「守る相手（この原則が試される横槍・誘惑）」。

1. 速さ vs 機能の多さ → 速さを優先
   - 理由：記録が一瞬で終わらないと習慣化しない。軽快さが価値の中心。
   - 守る相手：機能追加要望が来ても、記録完了までの速さを削るなら断る。

2. プライバシー vs 共有のしやすさ → プライバシーを優先
   - 理由：安心して記録を貯められることが前提。共有は後から足せるが信頼は戻らない。
   - 守る相手：拡散狙いの「全公開デフォルト」提案には倒れない。

3. [3 つ目]

05 競合・差別化（`05-competition.md`）

競合に対する立ち位置を、ピッチ・機能スコープより前に確定する。主役は「どこに立つか（ポジショニング）の言語化」。比較表は競合が複数いるときの任意セクション。差別化の核は デザインプリンシプル（04）の優先順位を競合文脈に当てはめた立ち位置 として書く（優先順位の本体は 04 のみ＝二重管理しない）。持続性（真似されにくさ）を問うなら 12 リスク・前提・仮説の仮説側で扱う。

# 競合・差別化

> 競合に対する立ち位置を、ピッチ・機能スコープより前に確定する。
> 主役は「どこに立つか」の言語化。比較表は競合が多いときの補助（任意）。
> 差別化の核はデザインプリンシプル（04）の優先順位を競合に当てはめた立ち位置（優先順位の本体は 04）。
> 性質ごとの省略可否：公開＝要 / 限定・社内＝任意 / 自分用＝省略可。

## 競合の俯瞰
- 直接競合:同じ課題を同じ手段で解く（例:◯◯）
- 間接競合:同じ課題を別手段で解く（例:紙のノート、Excel 代用）
- 競合不在のときは「なぜ不在か（市場が未成熟／ニーズが弱い等）」を 1 行で書く

## 自分たちの立ち位置（差別化の核）
- ひとことで:◯◯（競合がやらない／やれないどこに立つか）
- 理由:なぜそこで戦えるか・戦うか（1〜2 行）

## 競合比較（任意）
> 競合が複数いて頭の整理が要るときだけ使う。1〜2 社なら俯瞰と立ち位置で十分。

| 競合 | 強み | 弱み |
| --- | --- | --- |

06 ピッチ（`06-pitch.md`）

サービスの本質を外部向けに伝える 残り表現。対外公式ストーリーは PRFAQ（03）の PR が真実源なので、ここは井口型・カジュアルなど PR が兼ねない表現の語り直しに絞る。**書く過程それ自体が「企画が腹落ちしているかのテスト」**になる固有価値を重視する。ターゲット・KPI・マネタイズは 01 / 11 / 09 が真実源で、ここでは自分の言葉で語り直すだけ（書き写し・二重管理しない）。性質によらず全サービス共通で書く（省略可否を設けない。自分用では「対外公式」を「未来の協力者・採用候補に説明するなら」と読み替える）。

# ピッチ

> サービスの本質を外部向けに伝える残り表現。対外公式ストーリーは PRFAQ（03）の PR が真実源。
> ここは井口型・カジュアルなど PR が兼ねない表現を語り直す。書く過程が「企画の腹落ち」テストになる。
> ターゲット・KPI・マネタイズは各ページ（01 / 11 / 09）が真実源。ここでは自分の言葉で語り直すだけ。

## 使い分けガイド

| 型 | 読み手 | 使うシーン |
| --- | --- | --- |
| 井口型 | 対外公式（投資家・ステークホルダー・経営会議） | ピッチ資料、LP のヒーローコピー、30 秒説明 |
| 井口型 | カジュアル（友人・知人・SNS） | 「何作ってるの?」への簡潔な回答 |
| ストーリー型 | カジュアル（SNS・雑談） | SNS 投稿、自己紹介、動機を語る場面 |
| （ストーリー型・対外公式は PRFAQ の PR が真実源 → ここでは書かない） | | |

## パターン A：井口型

### A-1. 対外公式向け
> [ターゲット顧客] が抱える「[課題]」を解決する、[プロダクトカテゴリ] である [サービス名] です。これは [代替案] と違って、[主要な差別化要素] を提供します。

### A-2. カジュアル向け
> [何をするサービス] を作ってる。[共感できる課題] な人でも、[体感できる変化] になる。[象徴的な特徴] のがポイント。

## パターン B：ストーリー型（カジュアル）

### B-2. カジュアル向け
> [読み手が共感できる体験を問いかけ]、ない？[現状の不満をカジュアルに描写]。
>
> それを解決するために、**[サービスの一行説明]** を作ってる。名前は [サービス名]。
>
> 使い方はシンプルで、[使い方の流れ]。**[一番のポイント]** のが一番のポイント。

「日本語が崩れる」リスクへの注意（ピッチを磨くときに添える）：何度か書き直すことを前提にする。とくに (1) 修飾節を長くしすぎる、(2) 直訳調の硬い表現（「単一体験」「シームレスに統合」など）、(3) 大げさで実態と合わない表現（「世界を変える」など）に注意。最初の版を出し、「ここが読みにくい / 大げさ」と指摘してもらいながら磨く。声に出して読んで自然かを基準にする。

07 機能スコープ（`07-feature-scope.md`）

技術非依存の「何ができるか（What）」の一覧。接頭辞 ID もモジュール分類も付けない（それは tech-designer の責務）。各機能は「機能名：一言補足」を 1 行 で書く（構造化しない＝画面化・状態遷移は下流 prototype-designer の責務）。機能グループは ユーザー行動軸（動詞で括る）。各機能行末に [作る] / [作らない] / [保留]。「いつ作るか」は 08 ロードマップの責務。管理者機能は独立ページにせず内包し、冒頭で必要性を判断する。下流 prototype-designer は [作る] の機能を画面化対象とする。

# 機能スコープ

> 技術非依存の「何ができるか」の一覧。接頭辞 ID もモジュール分類も付けない（tech-designer の責務）。
> 状態は [作る] / [作らない] / [保留] の 3 つ。「いつ作るか（MVP / リリース後）」はロードマップで扱う。

## 利用者向け機能

### 記録する
- 抽出記録を投稿する：写真・豆・抽出条件を添える [作る]
- 下書き保存する [保留]

### つながる
- DM を送る [作らない]

## 管理者向け機能

> 判断軸：UGC があるか / 課金・決済があるか / 不正・通報対応が要るか / 運営がデータを操作する場面があるか
判断：必要（理由：ユーザー投稿があり通報対応とアカウント停止が要る）

### 運営する
- 通報された投稿を確認・対応する [作る]
- ユーザーを停止する [作る]

08 ロードマップ（`08-roadmap.md`）

機能スコープ（07）で [作る] になった機能を時間軸に配置する従属ページ。機能名はコピーするだけで補足・状態ラベルは持ち込まない（採否の真実源は 07）。段は MVP / 近い将来 / 遠い未来 の 3 つ。MVP の線引きだけは「コア価値に必須か」の基準を持ち、PRFAQ（03）のゴールラインと整合させる。近い将来 / 遠い未来の境界は相対的な優先度感覚で運用する。

# ロードマップ

> 機能スコープで [作る] になった機能を時間軸に配置する。機能の採否そのものは機能スコープが真実源。ここでは「いつ」だけを扱う。

## MVP（最初のリリースに必ず入れる）
- 抽出記録を投稿する
- タイムラインを見る

## 近い将来（MVP の次に手を付けたい）
- 投稿を検索する

## 遠い未来（いずれやりたいが優先度は低い）
- DM を送る

09 マネタイズ（`09-monetization.md`）

「どう収益を得るか」の事業判断。技術非依存・方針レベルに留める（具体的な価格表・決済実装は扱わない）。冒頭に収益化の要否判断を置き、「しない／未定」なら以下 4 項目は省略可。PRFAQ（03）FAQ 社内向け「財務的に成り立つか」の詳細はここが受け皿。

# マネタイズ

> どう収益を得るかの事業判断。方針レベルに留める（具体的な価格表・決済実装は扱わない）。
> 性質ごとの省略可否：公開＝要（ただし下記の収益化要否判断あり）/ 限定・社内＝多くは不要 / 自分用＝省略可。

## 収益化の要否
> このサービスは収益化するか。する/しない/未定 ＋ 理由 1 行。しない・未定なら以下は省略可。
判断：する（理由：継続的なサーバーコストを賄い事業として自立させるため）

## 収益モデル
- フリーミアム（理由：まず無料で母数を集め、ヘビーユーザーを有料転換する）

## 課金境界（無料と有料の線引き）
- 無料で使える範囲：記録の投稿・閲覧・基本検索
- 有料の価値：無制限の記録保存・高度な分析・広告非表示

## 価格帯の方針
- 個人向けに月 500〜800 円台を想定（根拠：競合の記録系アプリが月 500 円前後／個人の趣味出費の許容範囲）
- 確定価格は出さない（方針レベル）

## 収益化のタイミング
- リリース後、ユーザーが一定数たまってから有料プランを追加（理由：初期は無料で価値を体験させ離脱を防ぐ）

10 マーケティング（`10-marketing.md`）

「どう知ってもらい、どう最初のユーザーを獲得するか」。技術非依存・方針レベル。要否判断はこのページに持たせず、PRFAQ（03）の性質宣言に委ねる（他者にリリースするサービスのときだけ書かれる）。

# マーケティング

> どう知ってもらい、どう最初のユーザーを獲得するか。方針レベルに留める。
> 性質ごとの省略可否：公開＝要 / 限定・社内＝多くは不要 / 自分用＝省略可（要否は PRFAQ の性質宣言に従う）。

## 獲得チャネル
- X（旧 Twitter）のコーヒー愛好家コミュニティ（理由：ターゲットが密集し口コミが回りやすい）

## 初期ユーザー獲得（コールドスタート）
- まず知人と既存のオンラインコーヒーコミュニティでベータ募集し、最初の 50 人を集める

## 継続・拡散の仕掛け
- 記録が貯まるほど振り返り価値が増す設計でリテンションを作る
- 記録カードを画像でシェアできるようにして自然拡散を狙う

11 KPI・計測（`11-kpi.md`）

サービスの成否を測る指標を方針レベルで決める。計測ツールの選定・実装（イベント設計など）は tech-designer・運用の責務で持ち込まない。North Star 指標（最重要の 1 つ）＋補助指標（2〜4 個。獲得・継続・収益の観点）。補助指標は 09 マネタイズ・10 マーケと連動する。

# KPI・計測

> サービスの成否を測る指標を方針レベルで決める。計測ツールの選定・実装は tech-designer / 運用の責務。
> 性質ごとの省略可否：公開＝要 / 限定・社内＝任意 / 自分用＝省略可（他者に使わせて初めて意味を持つため）。

## North Star 指標（最重要の 1 つ）
- 週あたり抽出記録の投稿数(理由:記録の継続=このサービスのコア価値が回っている証拠だから)

## 補助指標（North Star を支える）
- 新規登録数（獲得）
- 7 日後継続率（継続）
- 有料プラン転換率（収益）

12 リスク・前提・仮説（`12-risks-assumptions.md`）

サービスが成立する前提と、検証すべき仮説、想定リスクを残す。「なぜ成り立つと言えるか」を企画段階で言語化する。3 語の関係：前提＝成立に必要な信じている条件／仮説＝前提のうち未検証で外れたら痛いもの／リスク＝前提が崩れる・外部要因で起きる悪いこと。前提・仮説は統合し各項目に [検証済み] / [未検証] を付す。

# リスク・前提・仮説

> サービスが成立する前提と、検証すべき仮説、想定リスクを残す。
> 「なぜ成り立つと言えるか」を企画段階で言語化する。

## 前提・仮説
> 成立に必要な条件と、検証すべき仮説。各項目に [検証済み] / [未検証] を付す。
> 未検証で外れたら痛いものは、検証方法と外れたときの影響を添える。
- ターゲットは記録を継続したいニーズを持っている [未検証] ／ 検証方法：◯◯ ／ 外れたときの影響：◯◯
- スマホで撮影しながら記録する行動に抵抗がない [検証済み]

## リスク
- 競合が同等機能を無料で出す ＋ 対応方針：◯◯
- 主要 API の仕様変更で記録機能が止まる ＋ 対応方針：◯◯

13 法務（`13-legal.md`）

事業として踏むべき法的観点を企画段階で押さえる。法律の専門助言ではなく「企画者が法的リスクに気づき、必要なら専門家に当たる」ための観点出し。 適法性の断定はせず「気づきと方針」に留める（この注記を冒頭に必ず置く）。4 観点を固定し、全観点を「該当/非該当＋理由」で埋める（非該当も結論として残す）。

# 法務

> 事業として踏むべき法的観点を企画段階で押さえる。専門的な法判断ではなく「気づき」と方針。
> Claude も企画者も法律の専門家ではない。適法性の判断が必要なら専門家に相談する前提。
> 4 観点はすべて埋める。非該当も「非該当 ＋ 理由」と結論を書く。
> 性質ごとの省略可否：公開＝要 / 限定・社内＝要 / 自分用＝多くは省略可。

## 個人情報・プライバシー
- 扱う個人情報：メールアドレス・投稿内容。プライバシーポリシーが必要

## 利用規約
- UGC と将来の課金があるため利用規約を用意する

## 知的財産・ライセンス
- 使用ライブラリのライセンス確認が必要。ユーザー投稿物の権利の扱いを規約で定める

## 業界・サービス固有の規制
- 特商法：将来課金するなら表記が必要 / 資金決済法：送金機能がないので非該当

14 非機能要件の目標値（`14-nfr-targets.md`）

品質の目標値を方針レベルで残す。具体的な実現方法・確定数値は tech-designer（ステージ2）の責務で持ち込まない（冗長化・キャッシュ戦略などの技術構成も書かない）。4 観点を固定し、すべて埋める（該当が薄い観点も「軽微／特になし＋理由」と結論を書く）。

# 非機能要件の目標値

> 品質の目標値を方針レベルで残す。具体的な実現方法・確定数値は tech-designer（ステージ2）の責務。
> 4 観点はすべて埋める。該当が薄い観点も「軽微／特になし ＋ 理由」と結論を書く。
> 性質ごとの省略可否：公開＝要 / 限定・社内＝要 / 自分用＝簡略可（4 観点は残すが各 1 行で軽く）。

## パフォーマンス
- 主要画面は待たせずサクサク動くことを目標（体感速度重視。具体的なレスポンス数値は tech-designer）

## 可用性
- 個人開発のため多少の停止は許容（理由：24/365 を保証する事業段階ではない）

## セキュリティ・プライバシー
- 個人情報（メール・投稿）を扱うため最低限の保護方針を持つ（具体策は tech-designer）

## スケール想定
- 初期は数百〜数千人想定。将来的に数万人規模を見据える（理由：◯◯）

99 サービス固有論点（`99-specific-topics.md`・枠外）

01〜14 の固定ページに収まらない、サービス固有の論点の受け皿（固有の倫理的配慮、特定の技術制約が企画に与える影響、コミュニティ運営方針など）。論点ごとに「論点名＋結論/現状の考え」の最小ブロック。なければ「特になし」と書く。固有論点があるときのみ作成する。

# サービス固有論点

> 01〜14 の固定ページに収まらない、このサービス固有の論点を書く。
> 論点ごとに「論点名 ＋ 結論または現状の考え」を 1 ブロックで。なければ「特になし」。

## ユーザー投稿の倫理的配慮
- 現状の考え：抽出記録に他者が写り込む写真の扱いをガイドラインで定める方針

## 豆のデータベースの出典
- 現状の考え：外部の豆情報をどこまで引用してよいか未確定。要検討（保留）

サービスの性質宣言（全ページ共通の仕組み）

企画の入口（PRFAQ〔03〕の冒頭）で「サービスの性質」を 1 回宣言し、各ページの書式がその宣言を参照して省略可否を決める。要否判断を各ページに個別に持たせると同じ前提を繰り返すことになり「真実源を 1 つ」に反するため、入口で 1 回宣言する。

性質の 3 区分:

公開サービス — 不特定多数の他者に使ってもらう。
限定公開・社内ツール — 特定の組織・グループ内で使う。
自分用ツール — 自分とごく近い範囲だけが使う。

省略可否は各ページの書式側に「この性質では省略可／簡略可」と個別記載してある（早見表は持たない＝二重管理回避）。06 ピッチは例外で、性質によらず全サービス共通で書く。

提供形態（Web／モバイル／デスクトップ等）も性質と並んで PRFAQ 冒頭で宣言し、下流（prototype-designer の画面設計・tech-designer の技術選定）が参照する。

共通要件

1. 入出力契約

出力先: projects/active-dev/{service}/01-service-designer/ 配下に固定ページを置く。ファイル名は英語スラッグ（番号固定）: 01-persona.md / 02-usage-scenes.md / 03-prfaq.md / 04-design-principles.md / 05-competition.md / 06-pitch.md / 07-feature-scope.md / 08-roadmap.md / 09-monetization.md / 10-marketing.md / 11-kpi.md / 12-risks-assumptions.md / 13-legal.md / 14-nfr-targets.md ／枠外 99-specific-topics.md（固有論点があるときのみ）。
入力（起動モード 2 つ）: 最上流スキルなので前段スキルの生成物はない。起動は 2 入口を持つ:
- 新規企画モード: ゼロから対話で前段・アンカー・派生を埋める。
- 既存サービス整理モード: ユーザーが指す既存資料（README・既存 vault・口頭説明など）を読み、固定ページにマッピングする。決定済みは確定として記録し、不明点は TBD として残す。
出力は一度に作らず、対話で合意できたページから順に書き出す。番号は固定。

2. 読み方の地図（ページ間の依存順）

最上流スキルなので前段スキルの生成物はゼロ。代わりにページ間の依存順を地図として持つ:

PRFAQ（03）冒頭の 性質宣言・提供形態 を、下流の全ページが参照する（最初に決める）。
PRFAQ（03）とデザインプリンシプル（04）が 2 アンカー。派生はここから決める。
05 競合・差別化は 06 ピッチ・07 機能スコープより前に置く（競合意識なしに機能を作る順序を避ける）。差別化の核はデザプリ（04）を競合に当てはめる。
06 ピッチは PRFAQ（03）・01 ペルソナ・05 競合が固まってから書く（対外公式ストーリーは PRFAQ が真実源、ここは残り表現）。
08 ロードマップは 07 機能スコープで [作る] が出てから書く。MVP の線は PRFAQ のゴールラインと整合させる。
既存サービス整理モードのときは、前段スキルではなくユーザーが指す既存資料を読む。

3. 完了時の次スキル案内（ハイブリッド完了判定）

性質宣言で省略可になるページを除いた必要ページが埋まったのをスキルが検知したら、(a) ここまでの企画サマリと (b) 未記入／性質宣言により省略したページの一覧、を提示して一拍確認する。ユーザーが合意したら次スキル案内を出す。抜けの検知はスキルが能動的に行うが、次へ進む決定はユーザーに委ねる。

案内の文言（実行環境も添える）:

企画がひととおり固まりました。次は prototype-designer（Claude Chat）でデザインを詰めましょう。

4. 運用知見（運用しながら追記する）

最初は空でよい。運用しながら動的に知見を追記する場。

## 運用知見（運用しながら追記する）

### 判断に迷ったときの参照優先度
（運用しながら書き加える）

### 過去のはまりどころ
（運用しながら書き加える）

### 性質宣言の判定で迷った例
（運用しながら書き加える）

ノート作成の作法

保存先は Obsidian 専任

vault に直接ノートを書く（Obsidian MCP を使う）。保存先モードの判定や Notion への退避は行わない。

起動時は出力先フォルダ（projects/active-dev/{service}/01-service-designer/）を確認し、これが新規企画か既存サービス整理かを聞いてから始める。

ファイル名・見出し

ファイル名は上記の英語スラッグ固定（01-persona.md 等）。
H1 見出しはページの日本語タイトル（# ペルソナ、# PRFAQ など。各書式テンプレート参照）。

内容のスタイル

日本語で書く（ユーザーが日本語の場合）。「である」調または「だ」調。
箇条書き多め、表は適切なところで使う。
決定事項は明確に書く。TBD・要確認は明示する。
コードや構造図は Markdown のコードブロックを活用する。

ノート間の相互参照

Obsidian の wikilink（または相対パスリンク）に一本化する。例: 「詳細は [[09-monetization]] を参照」「優先順位は [[04-design-principles]] が真実源」。

重要な原則

ユーザーのペースに合わせる: 一気に進めず、各ページの合意を取ってから次へ。
企画専任を守る: 技術スタック・アーキテクチャ・運用・インフラ・計測実装には踏み込まない（tech-designer の責務）。
「TBD」を恐れない: 全決定を一気に出さなくてよい。
ユーザーの否定を尊重する: 「不要」と言われたページはスキップする。
真実源を 1 つに: 優先順位は 04、対外公式ストーリーは 03 の PR、機能採否は 07 が真実源。他ページは参照・語り直しに留め、書き写さない。
確認質問は 1 ターンに 1 つずつ（複数並べない）。

service-designer