otomatty/write-zenn-dialogue-article

Zenn 対話形式記事の執筆スキル

A先輩と B後輩の会話で技術トピックを解説する Zenn 記事を書く。 AI臭のない自然な会話で、初心者の「あるある」な疑問に答える形式。 対象読者はプログラミング初心者〜入門者。専門用語は必ず噛み砕いて説明する。

• トーンルール・NG フレーズ → tone-guide.md
• キャラクター設定・会話パターン → dialogue-guide.md

キャラクター設定（概要）

| | A先輩 | B後輩 | | ---------- | -------------------------------------------- | -------------------------------------------- | | 役割 | 解説・改善例を示す | 質問・初心者にありがちなコードを出す | | 話し方 | 的確・結論ファースト。専門用語は必ず噛み砕く | 素朴・ストレート | | 知識レベル | 実務経験豊富 | 完全初心者。プログラミングを学び始めたばかり |

詳細は dialogue-guide.md を参照。

対話のマークダウン記法

Zenn のメッセージ記法（:::message）を使い分ける。

• B後輩の発言: :::message で囲む（質問として目立たせる）
• A先輩の発言: 通常テキスト（回答として流れるように読ませる）

:::message
**B後輩**: SOLIDの「S」って何ですか？ 名前は聞いたことあるんですけど…
:::

**A先輩**: 単一責任の原則だね。ひとつのコンポーネントには、ひとつの役割だけ持たせようっていう考え方。

コード例の扱い

B後輩が初心者にありがちなコードを出す → A先輩が改善版を示す。 コードは発言の直後に配置し、Before/After を会話の流れで自然に見せる。

:::message
**B後輩**: 自分はこんな感じで書いてるんですけど、これってどうですか？
:::

```tsx
const UserPage = () => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch(`/api/users/${id}`)
      .then((res) => res.json())
      .then((data) => {
        setUser(data);
        setLoading(false);
      });
  }, [id]);

  if (loading) return <Spinner />;
  if (!user) return <NotFound />;

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
      {/* ... validation, formatting, etc. 全部ここに */}
    </div>
  );
};
```

**A先輩**: 動くけど、この 1 コンポーネントにやらせすぎだね。fetch・表示・エラー処理が全部混ざってる。分けてみよう。

```tsx
const UserPage = () => {
  const user = useUser(userId);
  return <UserProfile user={user} />;
};
```

記事の基本方針

• 対象読者: プログラミング初心者〜入門者
• トーン: 先輩が後輩に教える自然な会話。堅すぎず、砕けすぎない
• 文体: 会話部分はカジュアルな口語体。地の文（導入・補足）は敬体
• 読了時間: 10〜15 分（5,000〜8,000 字程度）
• AI臭の排除: tone-guide.md を遵守

記事の構成テンプレート

---
title: "（B後輩の疑問が伝わる具体的なタイトル）"
emoji: "（内容に合った絵文字 1 つ）"
type: "tech"
topics: ["トピック1", "トピック2", "トピック3"]
published: false
---

## はじめに

（2〜3 文でテーマと対象読者を書く）
（この記事が対話形式であることを伝える）

---

## テーマ 1: 〜

:::message
**B後輩**: （素朴な疑問。セクションは必ず B後輩の質問から始める）
:::

**A先輩**: （結論 → 理由 → 具体例の順で回答）

:::message
**B後輩**: （追加の疑問、または自分のコードを見せる）
:::

**A先輩**: （改善案をコード例つきで示す）

:::message
**B後輩**: （理解を自分の言葉で言い直す、または次の疑問へ橋渡し）
:::

---

## テーマ 2: 〜

（同様の対話パターン。テーマ間は `---` で区切る）

---

## テーマ N: 〜

---

## まとめ

:::message
**B後輩**: （学んだことを自分の言葉で振り返る）
:::

**A先輩**: （補足やネクストステップを簡潔に）

## 参考

（引用した記事・ツールへのリンク）

対話の流れルール

1. 各セクションは B後輩の質問で始める

読者が B後輩に感情移入し、自分の疑問が解消される体験を作る。

2. 1 往復 = 1 ポイント

1 回のやり取りで伝えるポイントは 1 つだけ。詰め込まない。 ポイントが複数あるなら、B後輩に追加の質問をさせて分ける。

3. B後輩は「わかりました」で終わらない

理解したら自分の言葉で言い直す。または次の疑問につなげる。

<!-- ❌ -->

:::message
**B後輩**: わかりました！
:::

<!-- ✅ -->

:::message
**B後輩**: なるほど、つまり 1 コンポーネント 1 役割ってことですね。でもそうすると、コンポーネントの数がすごく増えませんか？
:::

4. A先輩は結論ファースト

長い前置きをせず、まず答えてから理由を補足する。

❌ A先輩: そもそもSOLIDっていうのはロバート・C・マーティンが提唱した…
✅ A先輩: 結論から言うと、1コンポーネントに責務を詰め込むと壊れやすくなる。理由は…

5. 自然な雑談を少し入れる

教科書にならないよう、先輩の体験談や軽い脱線を挟む。

✅ A先輩: 自分も最初は全部1ファイルに書いてたよ。3ヶ月後に見返して絶望した。

6. A先輩は専門用語を必ず噛み砕く

初心者が読むことを前提に、専門用語が出たら必ず平易な言葉で言い換える。

❌ A先輩: これは SRP 違反だね。
✅ A先輩: 1 つのコンポーネントにいろんな仕事をさせすぎてる。
         これ「単一責任の原則」っていって、1 つにつき 1 つの役割だけにしようねって考え方なんだよね。

7. B後輩のコードは「初心者あるある」レベル

初心者が書きがちなコードを出す。動くが設計上の問題があるコード、 または「とりあえず動かした」段階のコード。 初心者が「え、これダメなんですか？」と思うレベルが理想。

推敲チェックリスト

• [ ] タイトルが B後輩の疑問や読者の興味を引くものになっている
• [ ] 冒頭で対話形式であることと対象読者がわかる
• [ ] 各セクションが B後輩の質問から始まっている
• [ ] B後輩のコード例に初心者あるあるが含まれている
• [ ] A先輩の説明が結論ファーストになっている
• [ ] B後輩が「わかりました」だけで終わっているやり取りがない
• [ ] :::message の記法が正しく使われている（B後輩のみ）
• [ ] tone-guide.md の NG フレーズが会話中に残っていない
• [ ] コードブロックが 30 行を超えていない
• [ ] 1 往復で 1 ポイントが守られている
• [ ] A先輩が専門用語を使ったとき、必ず噛み砕いた説明がセットになっている
• [ ] A先輩の体験談・雑談が最低 1 箇所入っている
• [ ] 読了 10〜15 分に収まっている（5,000〜8,000 字目安）
• [ ] 最後に「参考」セクションでリンクを挙げている

出力先

docs/plan/ 配下に Markdown ファイルとして出力する（Git 追跡外）。 ファイル名は zenn-dialogue-<slug>.md（例: zenn-dialogue-react-solid.md）。