joushinsho

name	joushinsho
description	導入対象がまだ決まっていない段階から、課題ヒアリング → 製品・サービスの候補探索 → 1社に絞り込み → 上申書 (Markdown) 作成 までを対話形式で一気通貫に支援するスキルです。「○○の課題を解決する製品を探して上申書にまとめたい」「導入候補を比較したうえで稟議資料を作りたい」というときに使用してください。

上申書作成スキル（課題ヒアリング〜製品選定〜上申まで）

製品・サービスがまだ決まっていない段階から伴走し、最終的に Markdown (.md) 形式の上申書を出力します。

全体フロー（5 フェーズ）

Phase 1: 課題ヒアリング
   ↓ （ユーザーに要件サマリーを提示して確認）
Phase 2: 候補探索（Web 検索）
   ↓ （3〜5 件の候補を比較表で提示して確認）
Phase 3: 1 社に絞り込み
   ↓ （詳細を Web で深掘りしてユーザーと対話）
Phase 4: 上申書ドラフト作成
   ↓ （Markdown 草案を確認）
Phase 5: Markdown 出力

各フェーズの最後でユーザーの確認を取ってから次へ進むこと。勝手にフェーズを飛ばさない。

---

Phase 1: 課題ヒアリング

平文で質問します（AskUserQuestion ツールは使わない）。関連項目は 3〜4 個ずつまとめて聞き、一問一答にしないこと。

A. 提案者・組織情報（ヒアリングしない／ダミーで作成）

提案者・組織情報は ユーザーに質問せず、以下のダミー値で固定 します。上申書ドラフト作成時にもこの値をそのまま使用してください。

• 提案者所属: 営業企画部
• 提案者氏名: 山田 太郎
• 上申先: 代表取締役社長　佐藤 一郎 殿
• 部署規模・想定利用者数: 部署 30 名 / 想定利用者数 30 名

ユーザーから「提案者は××にして」「上申先を変えたい」など明示的な指定があった場合のみ、その値で上書きする。指定がなければ確認も取らず上記ダミーで進めること。

B. 現状の課題

1. 現在の業務で何に困っているか（具体エピソード歓迎）
2. その課題による影響（時間ロス・ミス・機会損失など、可能なら定量で）
3. 既存ツールで対応できない理由

C. 達成したいゴール

4. 導入によって何が達成できれば成功か（KGI/KPI レベルで）
5. 導入後の理想的な業務イメージ

D. 制約・こだわりポイント

6. 予算感（年間 / 月額）
7. セキュリティ要件（オンプレ必須／SaaS 可、データ保管場所、SOC2 などの認証）
8. 既存システム・ツールとの連携要件
9. 言語・サポート要件（日本語必須、国内ベンダーのみ等）
10. 導入希望時期
11. 絶対に譲れない条件 (Must) と あると嬉しい条件 (Want) の切り分け

ヒアリング完了時のアクション

すべて聞き終えたら、以下の形式で 要件サマリー をユーザーに提示し、過不足がないか確認してください：

【要件サマリー】
- 課題: ...
- ゴール: ...
- Must: ..., ..., ...
- Want: ..., ..., ...
- 予算: 年間 ○○ 円程度
- 制約: ...

OK が出たら Phase 2 へ。

---

Phase 2: 候補探索

WebSearch ツールを使って、要件を満たす製品・サービスを 3〜5 件 ピックアップします。

探索の進め方

1. 要件の Must 条件を組み合わせた検索クエリで WebSearch を実行（複数クエリを並列で）
   • 例: "営業 議事録 自動化 SaaS 日本語" "meeting notes AI Japan SOC2"
2. ヒットした候補について、必要に応じて WebFetch で公式サイトを取得し、実態を確認

候補提示フォーマット

下記のような比較表を Markdown でユーザーに提示：

#	製品名	ベンダー	主な強み	想定コスト	Must 充足	懸念点
1	...	...	...	...	◎/○/△	...
2	...	...	...	...	...	...
3	...	...	...	...	...	...

提示後、「この中で深掘りしたいものはありますか？追加してほしい候補はありますか？」と確認します。

注意:

• WebSearch の結果は出典 URL を必ず付記すること
• 不確かな数値（料金など）は「公式サイト未確認」「要見積」と明記し、勝手に作らない
• 候補は日本国内で実際に導入可能なものを優先

---

Phase 3: 1 社に絞り込み

ユーザーと対話しながら、最終候補 1 社を決めます。

1. 上位候補について WebFetch で公式ページ・料金ページ・事例ページを取得し、詳細を補強
2. 必要なら追加質問（「自社の規模なら Pro プランか Enterprise プランか」「英語UIでも問題ないか」など）
3. 比較しきれない情報は「要見積」「要問合せ」として明示

最終的にユーザーが 1 社を選んだら、その製品名をユーザーに復唱してもらってから Phase 4 へ。

---

Phase 4: 上申書ドラフト作成 → そのまま出力テンプレートになる

選定結果と Phase 1 のヒアリング情報をもとに、下記テンプレートを埋めて Markdown 草案 を作成し、ユーザーに見せて修正を受け付ける。確認 OK が出るまでファイルに保存しないこと。

テンプレート

日付は !date +%Y年%m月%d日 の出力を使う。

{{今日の日付}}

{{宛先}}

{{提案者所属}}　{{提案者氏名}}

# 上 申 書

## 件名

{{製品名}} の導入について

下記のとおり上申いたしますので、ご検討の程よろしくお願い申し上げます。

---

## 1. 提案概要

{{提案概要：何を、誰のために、どう変えるかを 3〜4 行で}}

## 2. 背景・現状の課題

{{Phase 1 で聞いた課題と影響を整理}}

## 3. 提案内容

- **製品・サービス名**: {{製品名}}
- **提供元**: {{ベンダー}}
- **製品概要**: {{1〜2 行}}
- **主な機能・特徴**:
  - {{機能1}}
  - {{機能2}}
  - {{機能3}}

## 4. 導入による効果・メリット

Phase 1 のゴールと紐づける形で、定量・定性の両面で記述。

- {{効果1（できれば数値）}}
- {{効果2}}
- {{効果3}}

## 5. 導入コスト

| 項目 | 金額 |
|------|------|
| 初期費用 | {{初期費用}} |
| 継続費用 | {{月額または年額}} |
| 投資回収目安 | {{ROI または定性的な回収シナリオ}} |

## 6. 想定リスクと対策

| リスク | 対策 |
|--------|------|
| {{リスク1}} | {{対策1}} |
| {{リスク2}} | {{対策2}} |

## 7. 比較検討した代替案

Phase 2 で挙げた他候補との比較を簡潔に記載。**最終候補を選んだ理由**を明確にすること。

| 候補 | 主な強み | 不採用の理由 |
|------|---------|-------------|
| {{候補A（採用）}} | {{強み}} | （採用） |
| {{候補B}} | {{強み}} | {{理由}} |
| {{候補C}} | {{強み}} | {{理由}} |

## 8. 導入スケジュール

{{契約・導入・本稼働の目安。可能なら表形式で}}

## 9. ご依頼事項

{{承認のお願い、予算枠の確保、関係部署との調整依頼など}}

---

以　上

草案作成時の注意

• 数値や固有名詞を 勝手に作らない。Phase 1〜3 で得られなかった項目は「（要確認）」と明記
• ですます調で統一（社内の正式文書のため敬体／常体の混在を避ける）
• 第 7 章では 不採用候補にも一言は触れる（「他案も検討した結果」のスタンスを示すと説得力が出る）
• 出典が必要な数値（市場データ等）には脚注で URL を残す

---

Phase 5: Markdown 出力

1. 保存先: outputs/（無ければ mkdir -p outputs）
2. ファイル名: outputs/上申書_{{製品名スラッグ}}_{{YYYYMMDD}}.md
3. Phase 4 で確認した Markdown 草案を、そのまま Write で .md ファイルとして保存する
4. 保存後は 絶対パスをユーザーに伝える
5. 既存ファイルがある場合は上書き前に確認
6. 失敗時はエラー内容を共有する

---

全体を通しての注意

• ユーザーが「ここまでで一旦止めて」と言ったら、その時点までの情報で Markdown 出力して構わない。未取得項目は「（要確認）」のままでよい
• ヒアリングが詰まったら無理に全項目を埋めず、「ここは社内で確認して埋めてください」と促す
• WebSearch / WebFetch の使用時は、出典 URL をメモして上申書の脚注に残す
• ユーザーが既に製品を決めている場合は Phase 1 と Phase 2 を簡略化し、Phase 3 から始めても良い（その旨確認すること）