deliver-release-notes

リリースノート

リリースノートは、製品の変更点をユーザーに伝え、価値を強調して期待感を高めるものです。技術的な変更点を記録する変更履歴とは異なり、リリースノートでは変更点をユーザーのメリットとして伝えます。優れたリリースノートは、新しい機能をユーザーが見つけやすくし、改善内容を理解できるようにするとともに、問題に対処していることへの信頼を高めます。

使用する場面

• 製品のアップデートを顧客に提供するとき
• 社内の関係者に変更点を伝えるとき
• アプリストアのアップデート説明文を準備するとき
• 顧客向けのメール告知を書くとき
• サポートチームや営業チーム向けに変更点を記録するとき

使用しない場面

• リリース済みの変更を告知するのではなく、進捗を社内の関係者に伝える場合 → foundation-stakeholder-update を使用してください
• 開発者向けに変更点の技術的な記録が必要な場合 → エンジニアリングの変更履歴を維持してください。このスキルでは、変更点をユーザーのメリットとして伝えます
• リリースを伝えるのではなく、ローンチの準備状況を調整する場合 → deliver-launch-checklist を使用してください
• ユーザーに見える変更がリリースされていない場合（社内のみのリファクタリングなど） → メリットを無理に見つけようとするリリースノートは信頼を損ないます。このサイクルでは作成しないか、次回分にまとめてください

手順

リリースノートの作成を依頼された場合は、次の手順に従ってください。

1. 変更履歴を収集する このリリースに含まれる機能、改善、バグ修正をすべて集めます。エンジニアリングの変更履歴、完了したチケット、プルリクエストの説明を参照してください。

2. 主な変更点を選ぶ 特に大きく取り上げる価値のある変更を1～3件選びます。ユーザーが最も気づき、関心を持つ変更を選んでください。最も影響の大きい変更から始めます。

3. メリットとして伝える 各変更をユーザーにとっての価値として書き直します。「検索結果にページネーションを追加」とするのではなく、「大量の検索結果も扱える検索機能で、必要な情報をより速く見つけられます」とします。ユーザーが新たにできるようになったことや、改善されたことに焦点を当てます。

4. 変更を分類する 残りの変更を「新機能」「改善」「バグ修正」の明確なカテゴリに分けます。各カテゴリ内では、影響の大きい順に並べます。

5. 読みやすい説明を書く 各項目は1～2文にします。まずメリットを伝え、必要に応じてその「仕組み」を説明します。ユーザーはリリースノートに目を通すため、どの項目にも価値が伝わるようにします。

6. 既知の問題を明記する 既知の制限事項や問題がある場合は、率直に伝えます。ユーザーは誠実な説明を評価し、サポートの負担も軽減できます。

7. 今後の予定を予告する（任意） 適切であれば、次に予定している内容を少しだけ示します。期待感を高め、取り組みが続いていることを伝えられますが、過度な約束は避けてください。

出力形式

references/TEMPLATE.md のテンプレートを使って出力を構成します。完成したリリースノートには、「主な変更点」「新機能」「改善」「バグ修正」「既知の問題」「近日公開予定（任意）」「フィードバック」のセクションを含めます。

品質チェックリスト

仕上げる前に、次の項目を確認してください。

• 「主な変更点」には、最も影響の大きい変更が1～3件含まれている
• 各項目は技術的な説明ではなく、ユーザーのメリットから始まっている
• すべてのユーザーにわかりやすく、専門用語がない
• 各項目が簡潔（1～2文）である
• バグ修正では、解決した問題に触れている
• 社内用語、チケットID、コードネームが含まれておらず、すべての行が顧客向けの表現になっている

例

完成例は references/EXAMPLE.md を参照してください。