shunk031-writing-kosshi

メモ

この SKILL.md を読んだら、🦴 私は shunk031-writing-kosshi を読みました。 と言う。

骨子箇条書き

大原則

• 骨子箇条書きは、パラグラフ・ライティングの構造を箇条書きへ移し、与えられた素材を「主張」と「支える事実」の階層に整理する
  • 既存の文章を書き換える依頼にも、メモから新しく構成する依頼にも使う
  • 出力は Markdown を既定とする
  • 見出しは、トップレベル項目を複数のまとまりに分ける場合だけ使う
    • 見出しには、その下の項目に共通する話題を書く
• 同じ階層には、共通の上位項目へ直接かかる独立した項目だけを並べる
  • 別の項目を説明・具体化・根拠づける内容は、その項目の一段下に置く

階層の基本形は次の通り。top-level と support-level は説明用のラベルであり、実際の出力には書かない。

- top-level: このまとまりで伝えること
  - support-level: 根拠や説明
    - 根拠や説明の詳細
  - support-level: 小結論（必要な場合）

トップレベルの一項目を一つのパラグラフとする。小結論が必要な場合は、根拠や説明と同じインデントでパラグラフの最後に置く。

構成と出力

• 引用、論文名、資料名、人名、組織名、製品名、固有の表記、引用文は原文の言語と表記を保つ
  • 出典名を勝手に日本語化しない
• 先頭の階層には、全体を要約する 3〜4 本の主張を置く
  • 各トップレベル箇条書きはラベルではなく、そのまとまりの主張や要点を一文で述べる
    • 各トップレベル箇条書きを上から読むだけで、全体の流れが追えるようにする
    • 詳細な時刻、回数、期間、担当者数は、原則として一段下に置く
  • 素材が少ない、または構造上不自然な場合は、3〜4 本に無理に合わせない
• 先頭の階層だけを先に書き、根拠を埋める前にユーザーへ提示する
  • 先頭階層で全体の流れが通るかを壁打ちし、合意してから下の階層を足す
  • 根拠まで書いてから先頭階層を差し替えると、下の階層ごと書き直しになる
• 各論点の下には、必要な範囲で 2〜3 本程度の根拠や説明を置く
  • 根拠、数値、例、原因、制約、未決事項、次の行動を近くに置く
    • 根拠や説明に詳細を加える場合は、インデントをもう一段深くする
  • 一つのまとまりには一つの論点だけを入れる
    • 論点が混ざる場合は、短く押し込まずに分ける
  • ここまでの内容をまとめる必要がある場合だけ、パラグラフの最後に小結論を置く

例: 議事メモから意思決定の流れを作る

この例が示す規則:

• 先頭の階層には 3〜4 本の主張: 出力の先頭階層を 4 本にする
• 各トップレベル箇条書きを上から読むだけで、全体の流れが追える: 会議の要点、現状、改善対象、対応方針の順に主張を並べる
• 各論点の下には根拠や説明を置く: 問い合わせ件数、担当者の報告、次の行動を、それぞれが支える主張の一段下に置く
• 詳細な時刻、回数、期間、担当者数は一段下: 参加者の内訳、問い合わせ件数、期限をトップレベルの主張へ押し込まない
• 一つのまとまりには一つの論点: 現状、改善対象、対応方針を別のトップレベル項目に分ける

入力:

社内ヘルプデスクの検索改善会議。参加者は運用担当 2 人、開発担当 1 人、カスタマーサポート担当 1 人。7 月の問い合わせ 1,180 件のうち、FAQ で解決できた問い合わせは 410 件。カスタマーサポート担当は、顧客向け予約サイトのキャンセル手順と領収書再発行の質問が多いと報告。開発担当は検索ログの表記ゆれが多く、同じ質問が「領収証」「領収書」「レシート」で分散していると説明。8 月末までに同義語辞書を追加し、9 月第 1 週に上位 30 件の検索失敗語を見直す。FAQ 記事の全面改稿は工数が大きいため今回は見送る。

出力:

- 検索改善会議では、関係者が社内ヘルプデスクの現状と対応方針を確認した
  - 参加者は運用担当 2 人、開発担当 1 人、カスタマーサポート担当 1 人だった
- 社内ヘルプデスクでは、FAQ で解決できない問い合わせがまだ多い
  - 7 月の問い合わせ 1,180 件のうち、FAQ で解決できた問い合わせは 410 件だった
- 顧客向け予約サイトでは、キャンセル手順と領収書再発行の質問が検索改善の主な対象になる
  - カスタマーサポート担当は、キャンセル手順と領収書再発行の質問が多いと報告した
  - 開発担当は、「領収証」「領収書」「レシート」の表記ゆれで同じ質問が分散していると説明した
- 今回は検索語の整理を先に進め、FAQ 記事の全面改稿は見送る
  - 8 月末までに同義語辞書を追加する
  - 9 月第 1 週に上位 30 件の検索失敗語を見直す
  - FAQ 記事の全面改稿は工数が大きい

例: 英語で依頼された場合は英語で骨子を書く

Input:

Please turn these notes into a structured bullet outline. Notes: The April customer onboarding webinar had 86 registrants and 52 live attendees, according to the Event Report. The follow-up email had a 38% click rate, according to the Email Report. Three enterprise prospects asked for a security checklist, and two startup customers asked whether the onboarding templates work with free plans. Trial activation rate and paid conversion rate are not available yet.

Output:

- The April customer onboarding webinar showed early interest.
  - The webinar had 86 registrants and 52 live attendees, according to the Event Report.
  - The follow-up email had a 38% click rate, according to the Email Report.
- Conversion success cannot be judged yet.
  - Trial activation rate and paid conversion rate are not available yet.
  - Inference: Attendance and email clicks show interest, but they do not prove onboarding success.
  - The next judgment should wait for activation and conversion data.
- Customer questions split between enterprise security review and startup plan limits.
  - Three enterprise prospects asked for a security checklist.
  - Two startup customers asked whether the onboarding templates work with free plans.

事実と出典

• 事実保持は文体より優先し、素材にないことを補わない
  • 事実、数値、因果、評価、結論、提案を勝手に足さない
  • 並べ替え、分割、圧縮はしてよい
  • 数値や根拠は、それが支える主張の近くに置く
  • 成功、失敗、効果、定着、原因、主因などの結論を求められても、素材が足りない場合は不足を明示する
• 引用と URL は、出典が支える最小の単位に付ける
  • 入力にある引用形式は保つ
  • 裸の URL だけは Markdown リンクに直す
  • 引用された用語や対象には、対象A [出典] のように対象の直後へ置く
  • 引用された数値や節には、その数値や節の直後へ置く
  • 複数の対象を比較する場合は、それぞれの対象にそれぞれの出典を付ける
  • 箇条書き全体を一つの出典が支える場合だけ、箇条書き末尾に引用を置く
  • 長い URL や出典注が本文を壊す場合だけ脚注にし、該当ブロックの直下に置く
  • 参考文献セクションや書誌情報が必要な場合だけ、独立した参考文献箇条書きを作る
• 出典の扱いでは、ユーザーが渡した素材を超えない
  • ユーザーが Web 調査を明示した場合を除き、ユーザー提供の出典だけを使う
  • 出典を作ったり、入力より確かな情報源として扱ったり、黙って削除したりしない
  • 出典のない解釈や評価は 推論: または 示唆: と明示し、出典が述べた事実のように引用を付けない
  • 不足情報で結果が大きく変わる場合だけ質問する。それ以外は、不足を短く示して骨子を書く

例: 成果指標が足りない公開後反応

この例が示す規則:

• 素材にないことを補わない: 未集計の成果指標から成功とは結論づけない
• 数値や根拠は、それが支える主張の近くに置く: 訪問数、開封率、問い合わせ件数を「関心を示す反応」の一段下に置く
• 出典が支える最小の単位に付ける: 各出典を対応する数値の直後に置く
• 裸の URL だけは Markdown リンクに直す: メールログの URL を開封率の直後にリンクとして置く
• 出典のない解釈や評価は推論または示唆と明示: 担当者の見立てを 示唆: として集計の事実から分ける

入力:

8 月 1 日に新料金プランを公開。価格ページ訪問は公開後 7 日で[アクセスログ]1,920 件。告知メール開封率は 42%で、ログ URL は https://example.com/mail-log 。問い合わせは 76 件[問い合わせ集計]で、主な内容は既存契約からの移行条件。有料転換率、解約率、売上影響は未集計。担当者の見立てでは、関心は高いが成功判断はまだ早い。

出力:

- 8 月 1 日に公開した新料金プランには、関心を示す反応があった
  - 価格ページ訪問は公開後 7 日で 1,920 件[アクセスログ]だった
  - 告知メール開封率は 42%[mail-log](https://example.com/mail-log)だった
  - 問い合わせは 76 件[問い合わせ集計]だった
    - 主な内容は、既存契約からの移行条件だった
- 成功を裏づける成果指標は未集計のため、結論は保留する
  - 有料転換率、解約率、売上影響は未集計
  - 示唆: 担当者は関心が高いと見ているが、成功とは断定できない
  - 当面の結論: 成果指標の集計後に成功判断を行う

例: 素材が少ない場合は無理に 3 本へ増やさない

入力:

新人研修の満足度アンケートは回答者 18 人、平均 4.1 点。自由記述では「演習時間が足りない」という声が 6 件あった。理解度テスト、配属後の成果、講師別評価はまだ集計していない。

出力:

- 新人研修の参加者満足度は確認できるが、理解度や配属後の成果はまだ判断できない
  - 満足度アンケートの回答者は 18 人だった
  - 平均点は 4.1 点だった
  - 理解度テスト、配属後の成果、講師別評価はまだ集計していない
  - 推論: 研修内容の評価を固めるには、理解度テストや配属後の成果の集計が必要になる
- 演習時間の不足は、自由記述で見えた具体的な改善候補である
  - 自由記述では「演習時間が足りない」という声が 6 件あった

文体

• 簡潔に書くが、形式に合わせるために不自然な文にはしない
  • 箇条書きの行末には句点「。」を付けない
  • 完全な文でも行末の句点は省く
  • 文中や引用文の内部にある句点は、そのまま保つ
  • 具体的な動詞と平易な名詞を使う
  • 同じまとまりの中では、文法や粒度をできるだけそろえる
  • 体言止め、同じ文字数、断片的な文体を無理にそろえない

保守

骨子構造を確認または変更するときは、定義元を参照する。