---

name: confirmation-sheet description: | ヒアリング結果から非エンジニア向け確認資料を生成するスキル。 ヒアリング完了後、承認を得るために使用。 技術用語を排除し、What/Whyを明確にした資料を作成する。 allowed-tools: Read, Write

確認資料生成スキル

目的

ヒアリング結果を、非エンジニアが理解・確認しやすい形式に変換する。 技術的な詳細は省き、「何を作るか」「なぜ作るか」を明確にする。

入力

ヒアリング結果（requirements-hearingスキルのアウトプット）

出力テンプレート

Copy# アプリ確認シート

## 作るもの

{アプリの概要を1-2文で。技術用語は使わない}

## なぜ作るか

{解決したい課題・目的を、ユーザーの言葉で}

## できること（優先順位順）

{優先度順に機能を列挙。必須には「※必須」をつける}

1. {機能1} ※必須
2. {機能2}
3. {機能3}

## 今回は作らないもの

{スコープ外を明確に。期待値を調整するため重要}

- {スコープ外1}
- {スコープ外2}

## 使う人

{利用者の説明}

## 将来的に追加できること

{将来の拡張予定があれば。なければ省略可}

- {将来機能1}
- {将来機能2}

---

**この内容でよろしいですか？**
修正があればお知らせください。
OKであれば「進めて」と言ってください。

変換ルール

1. 技術用語を排除する

2. 具体例を追加する

抽象的な機能には具体例を添える：

Copy❌ データの一覧表示
✅ 過去の請求書を一覧で確認できる

3. 優先順位を明確にする

• 必須機能には「※必須」マークをつける
• 優先度順に並べる（上が重要）

4. スコープを明確にする

「作らないもの」を明示することで：

• 期待値を調整
• 後から「これもできると思った」を防ぐ
• スコープクリープを防止

5. 簡潔にする

• 1項目は1-2文以内
• 箇条書きを活用
• 長い説明は避ける

良い例と悪い例

良い例

Copy# アプリ確認シート

## 作るもの

請求書を作成・管理するアプリ

## なぜ作るか

毎月の請求作業で抜け漏れが発生しているため、
一元管理して漏れを防ぎたい

## できること（優先順位順）

1. 請求書をPDFで出力する ※必須
2. 過去の請求書を顧客ごとに一覧表示
3. 新しい請求書を作成
4. 送付済み・未送付のステータス管理

## 今回は作らないもの

- メールでの自動送信
- 会計ソフトとの連携
- 入金管理

## 使う人

自分とアシスタントの2名

---

この内容でよろしいですか？

悪い例

Copy## 作るもの

Next.js + Supabaseで構築する請求書管理システム。
PostgreSQLでデータを永続化し、RLSでアクセス制御を行う。
← 技術用語だらけ

## できること

- CRUD操作
- PDF生成API
- 認証・認可
← 抽象的で何ができるかわからない

チェックリスト

確認資料を作成したら、以下をチェック：

• 技術用語が含まれていないか
• 機能が具体的に書かれているか
• 優先順位が明確か
• スコープ外が明記されているか
• 承認を求める文言があるか