Merge pull request #1418 from kufu/SD-945

[SD-945]不具合のリリースノートで気付いてほしいルールが目立つようにする

src/content/articles/products/contents/release-note/releasenotes.mdx

@@ -8,39 +8,39 @@ order: 2
 
 ## ユーザーの立場で、できるようになったこと、できなくなったことを伝える
 
-ユーザーがアップデート内容を理解できるよう、「ユーザー目線で書く」ことを念頭におきます。
+ユーザーがアップデート内容を理解できるよう、「ユーザー目線で書く」ことを念頭におきます。  
 ユーザー目線とは、コード追加・修正によって生じるアプリケーションの挙動ではなく、ユーザーが何をできるようになったか／何をできなくなったかです。  
 また、アップデートの内容をリリースに至った背景とともに伝えることで、ユーザーが開発者の意図を理解しやすくなるようにします。  
 開発者にとっては当たり前でも、ユーザーにとっては不慣れな表現は伝わりません。一般的な言葉で書くことを意識しましょう。
 
-## カテゴリーごとの基本的な書き方
+## カテゴリごとの基本的な書き方
 
 ### 新機能
-新しく追加した機能について記載します。 
- 
-開発の背景、想定しているユースケースや、これまで抱えていた課題をできるだけ具体的に説明します。
-そのうえで、機能として「できるようになったこと」を説明します。
-また、プレスリリースやお知らせの記事、ヘルプページがある場合は、リンクを設置します。
+新しく追加した機能について記載します。
+
+開発の背景、想定しているユースケースや、これまで抱えていた課題をできるだけ具体的に説明します。  
+そのうえで、機能として「できるようになったこと」を説明します。  
+また、プレスリリースやお知らせの記事、ヘルプページがある場合は、リンクを設置します。  
 
 ### 改善
-使い勝手の向上を目的としたアップデートについて記載します。  
+使い勝手の向上を目的としたアップデートについて記載します。
 
 変更点について、「画面」と「操作」を具体的に明示しながら説明します。  
-また、変更内容に加えて、これまで使用時に生じていた不便など、アップデートの背景も説明します。  
-  
-アップデートに伴って必要な操作がある場合や、アプリケーションの挙動に影響を与える場合には必ず明記します。   
-  
+また、変更内容に加えて、これまで使用時に生じていた不便など、アップデートの背景も説明します。
+
+アップデートに伴って必要な操作がある場合や、アプリケーションの挙動に影響を与える場合には必ず明記します。
+
 SmartHR Design Systemのガイドラインに準拠するための変更の場合は、ガイドラインへのリンクもあるとわかりやすいでしょう。
 
 ### アクセシビリティ向上
 アクセシビリティ向上につながる対応について記載します。  
-どの画面、どのUIで、どのようなアクセシビリティ対応が追加されたかを具体的に書きます。  
+どの画面、どのUIで、どのようなアクセシビリティ対応が追加されたかを具体的に書きます。
 
 ### 不具合修正
 不具合の修正について記載します。  
-どの画面、どのUIでどのような不具合が修正されたかを具体的に書きます。  
-不具合修正のリリースが複数あるときは、箇条書きで記載しましょう。  
-不具合修正のカテゴリのみ、見出しは不要です。重要度が高い内容を強調して伝えたい場合は、見出しを立てても構いません。  
+どの画面、どのUIでどのような不具合が修正されたかを具体的に書きます。
+
+不具合修正が複数ある場合は、箇条書きで記載します。
 
 ### 廃止した機能
 使えなくなった機能について記載します。  
@@ -56,8 +56,11 @@ SmartHR Design Systemのガイドラインに準拠するための変更の場
 ![スクリーンショット:リリースノートの要素](../images/releasenotes_1.jpg)
 
 ### タイトル
-リリース日と、変更点の概要、その日のリリース件数を伝えます。  
-変更点が複数ある場合は、ユーザーへの影響が一番大きい見出しをリリースノートのタイトルにします。
+リリース日と、変更点の概要、その日のリリース件数を伝えます。
+
+変更点が複数ある場合は、ユーザーへの影響が一番大きい見出しをリリースノートのタイトルにします。  
+不具合修正の変更しかない場合は、`不具合○件を修正しました`と記載します。
+
 タイトルでは、句点を省略します。[見出しでは句点（。）を省略する](/products/contents/idiomatic-usage/symbol/#h2-1)
 
 例：
@@ -84,6 +87,8 @@ SmartHR Design Systemのガイドラインに準拠するための変更の場
 
 1つのカテゴリに複数のリリース内容が含まれる場合は、ユーザーへの影響が大きいものから順に記載します。
 
+なお、不具合改修のカテゴリでは、見出しは不要です。不具合修正が複数ある場合は、箇条書きで記載してください。  
+ユーザーへの影響が大きい場合など、重要度が高い内容を強調して伝えたい場合は、見出しを立てても構いません。
 
 #### よく使う表現
 - 〇〇で△△できるようになりました
@@ -131,7 +136,7 @@ SmartHR Design Systemのガイドラインに準拠するための変更の場
   - 具体的に何が変わったのかが曖昧なため、非推奨です。
   - 「修正しました」、「追加しました」、「変更しました」など、具体的な変更点が伝わるように書き分けましょう。
 - 「禁止」
-  - 仕様上、制御している操作は、「禁止」ではなく「制御」や「制限」、「できません」と表現しましょう。 
+  - 仕様上、制御している操作は、「禁止」ではなく「制御」や「制限」、「できません」と表現しましょう。
   - 「禁止」にはエラーを引き起こす原因となる操作という意味が強く、その操作自体が許可されているかどうかは意図されていません。「できないように制御している状態」とは異なります。
 
 ##### 例
@@ -155,4 +160,4 @@ SmartHR Design Systemのガイドラインに準拠するための変更の場
 ユーザーの関心事の場合、「できなくなること」や「変更点がないこと」も明記します。  
 
 ##### 例
-UIのみの変更であり、検索結果や付与する権限については変更ありません。 
+UIのみの変更であり、検索結果や付与する権限については変更ありません。