---
name: case-study-writer
description: 顧客インタビューのメモや通話の文字起こしから導入事例を書く。導入前の状況、課題、選んだ理由、数字で見る変化、お客さまの声をまとめ、公開前にお客さまの承認が要る項目をすべて書き出す。インタビューメモ、成功事例、お客さまの声の通話記録を渡されて「導入事例を書いて」「事例記事にして」「お客さまの声をまとめて」「リファレンス用の事例がほしい」と頼まれたときに使う。
---

# 導入事例

導入事例が売れるのは、見込み客がそこに自分の状況を見つけ、信じられる数字に出会ったとき。お客さまの側から、お客さまの言葉で書き、お客さまが承認していない主張は公開しない。米国では FTC の Endorsement Guides（推奨表示のガイド）が、お客さまの発言を推奨（endorsement）として扱う。発言は「推奨者の正直な意見を反映していなければならない」とされ、その成果がふつうのお客さまの成果と違うなら、一般的な成果を明記する必要がある。日本で公開する場合のルールは異なりうる。[要確認: 日本の法令（景品表示法など）・社内の広報ルール]

## 使う場面

- 顧客インタビューや成功事例のヒアリングのあとで、メモを公開できる記事にするとき。
- 営業が特定の業種や懸念に答える根拠を必要としているとき。
- 満足したお客さまからのメールやレビューを、きちんとした事例にしたいとき。
- 多数の顧客の数字を匿名でまとめるときには使わない。それは事例ではなくレポート。

## 用意するもの

- お客さまへのインタビューメモか文字起こし。なければ頼む。社内メモだけで書いた事例は広告に見える。
- お客さまの氏名、役職、会社名、規模、業種。足りないものは「[確認: ...]」とする。
- 導入前と導入後の数字（時間、費用、売上、ミスの件数）。なければ一度だけ聞く。それでもなければ、変化を数字以外の具体的なことばで書き、承認リストに「数字なし」と書く。
- 任意：この事例で答えたい業種や懸念。

## 手順

1. **導入前の状況を、お客さまの言葉で拾う。** 以前どうしていたか、それで何を失っていたか、変えると決めたきっかけ。言い回しはそのまま引く。「スプレッドシートに埋もれていた」のほうが「非効率な状況に直面していた」より伝わる。
2. **なぜその会社が、なぜ自社を選んだかを書く。** ほかに何を検討したか（何もしないことも含めて）と、自社を選んだ1〜2つの理由。比較検討中の見込み客がいちばん読みたいところ。
3. **数字を拾う。** 導入前後のすべての指標を、期間つきで。「3か月で、週6時間から40分に」。お客さまではなく自社のチームが出した数字には、承認が要る印をつける。切り上げない。1か月の数字から1年分を推計しない。このお客さまの成果が特に良いなら、一般的な成果を1行書くか、「[要確認: 一般的な成果]」と付ける（FTC Endorsement Guides）。
4. **お客さまの声を1〜2つ選ぶ。** 機能の羅列ではなく、成果や気持ちを語る発言を選ぶ。意味を変えない範囲の言葉の整えはよいが、整えた発言には承認の印をつける。発言をつくったり、2つをつないだりしない。推奨表示は、推奨者の体験を偽ってはならない。
5. **見出しは成果から書く。** 「[お客さま]、[X]を[数字]削減」や「[お客さま]が[成果]を実現した方法」。数字がなければ、具体的な変化を書く。
6. **流し読みできる構成にする。** 結論を先に（NN/g の逆ピラミッド）。冒頭に3行の要約（お客さま、課題、成果）を置き、そのあとに「導入前の状況」「課題」「選んだ理由」「変わったこと」「今後」。分量はこのスキルの既定値で1,000〜1,800字。メモが少なければ、水増しせず短く書く。製品の機能は、成果を生んだところにだけ出す。
7. **承認が要る項目を書き出す。** すべての発言、数字、お客さまの社名とロゴ、名前を出す競合、機密になりうる情報（売上、人数、使っているツール）。協力の見返りに何かを受け取った、または受け取る可能性を知っていた場合（値引き、クレジット、無料期間など）は、ページにその旨を書く（FTC Endorsement Guides）。公開前に、お客さまがすべてを承認する。

## 出力の形式

```markdown
# [成果を入れた見出し]

| お客さま | [会社名、業種、規模] |
|---|---|
| 課題 | [1行] |
| 成果 | [数字を入れた1行] |

## 導入前の状況
[短い段落を2〜3つ]

## 課題
[何を失っていたか、お客さまの言葉で]

## [自社名]を選んだ理由
[検討したほかの選択肢、1〜2つの理由]

## 変わったこと
- [指標：導入前 → 導入後、期間]

> 「[発言]」 — [氏名、役職、会社名]

## 今後
[短い段落1つ]

---
## 公開前に[お客さまの担当者]の承認を得る項目
- [ ] 発言：「[...]」 [整えた／原文のまま]
- [ ] 数字：[...] — [出どころ：お客さま／自社のデータ]
- [ ] 氏名、役職、ロゴの使用
- [ ] 協力の見返り：[なし／内容、ページに明記]
- [ ] [機密や競合に関わる項目]
```

## 例

**入力：** 株式会社みどり便（地域の配送会社、ドライバー60人）の業務部長、高橋 誠さんへのインタビュー。導入前：配車はホワイトボードとグループチャット。「毎朝が戦場でした。ルートを割り振るだけで2時間です」。大規模な車両管理システムを試したが複雑すぎた。ドライバーがすでに使い慣れていたスマホのアプリが決め手で、ルートリンを選んだ。2か月後：ルートの割り振りは20分。配達漏れは週約30件から8件に減った（ルートリンのダッシュボードの数字）。発言：「朝7時にドライバーから電話がかかってこなくなりました」

**出力：**

```markdown
# みどり便、朝の配車を2時間から20分に短縮

| お客さま | 株式会社みどり便、地域配送、ドライバー60人 |
|---|---|
| 課題 | ホワイトボードとグループチャットで手作業の配車 |
| 成果 | 配車は20分に。配達漏れは週約30件から8件へ |

## 導入前の状況
みどり便は、地域で60人のドライバーを抱える配送会社です。導入前は、すべてのルートをホワイトボードで組み、グループチャットで送っていました。

## 課題
「毎朝が戦場でした」と業務部長の高橋 誠さんは話します。ルートの割り振りだけで2時間かかっていました。

## ルートリンを選んだ理由
みどり便は最初に大規模な車両管理システムを試しましたが、複雑すぎました。ルートリンを選んだのは、ドライバーがすでにそのスマホのアプリを使い慣れていたからです。

## 変わったこと
- ルートの割り振り：毎朝2時間 → 20分（2か月後）
- 配達漏れ：週約30件 → 8件（2か月後）

> 「朝7時にドライバーから電話がかかってこなくなりました」 — 高橋 誠、業務部長、株式会社みどり便

## 今後
[確認: みどり便の今後の計画。インタビューでは触れていない]

---
## 公開前に高橋 誠さんの承認を得る項目
- [ ] 発言：「毎朝が戦場でした」（原文のまま）
- [ ] 発言：「朝7時にドライバーから電話がかかってこなくなりました」（原文のまま）
- [ ] 数字：2時間 → 20分 — 出どころ：お客さま
- [ ] 数字：配達漏れ 週約30件 → 8件 — 出どころ：ルートリンのダッシュボード
- [ ] 氏名、役職、ロゴの使用
- [ ] 協力の見返り：インタビューでは言及なし [確認: なし]
- [ ] 先に車両管理システムを試したことへの言及（製品名は出さない）
- [ ] [要確認: 一般的な成果] — この成果はルートリンのお客さまとして一般的か
```

## 送る前のチェック

- [ ] 見出しが成果を伝えていて、数字があれば入っている。
- [ ] どの指標にも、導入前・導入後・期間がある。
- [ ] どの発言もメモにあり、整えたものには印がある。
- [ ] 承認リストが、すべての発言・数字・氏名・ロゴを網羅している。
- [ ] 入力にない内容は書いていない。足りないところは「[確認: ...]」になっている。
- [ ] 特に良い成果には一般的な成果を添えたか、「[要確認: 一般的な成果]」を付けた。

## よくある失敗

- 機能紹介として書く。機能は、成果を生んだところにだけ出す。
- 「選んだ理由」を省く。比較中の見込み客は、まずそこを読む。
- 自社のダッシュボードの数字を、お客さまの承認なしに公開する。