リリースノートの書き方

機能追加や不具合修正の内容など、アプリケーションのアップデートの詳細をユーザーに伝えるためリリースノートを公開します。

リリースノートを公開する目的

私たちは、以下の考えからリリースノートを公開してアップデートの詳細を伝えます。

改善であっても、ユーザーに負荷を与えるという視点を忘れない

より使いやすくするための変更であっても、ユーザーにとってはこれまでと同じ使い方ができない場合もあります。見慣れないユーザーインターフェースに戸惑う可能性もあります。
アプリケーションに慣れてきた頃に、「また使い方を覚えなくてはいけない」と負担に感じるユーザーがいることを忘れないようにします。

変更の意図を明確にし、新しい使い方を学習するユーザーの心理的負担を軽減したい

「なぜ変更したのか」「どのように便利になるのか」「どう使うための変更なのか」など、開発者の意図を伝えることで、アップデートの必要性や意義をユーザーが受け止めやすくなるようにします。

アップデート内容をオープンにし続け、信頼につなげたい

より使いやすくするための変更だという意図の説明は、ユーザーの納得感を得るために必要です。その積み重ねは、アプリケーションを長く使い続けてもらうことにつながると考えます。

リリースノートのカテゴリ

アップデートの種類ごとに、下記のカテゴリに分類します。

新機能

  • 新しく追加した機能を記載します。
  • 開発の背景、想定しているユースケースやこれまで抱えていた課題をできるだけ具体的に説明します。そのうえで、「できるようになったこと」を伝えます。
  • サービスサイトにプレスリリースやアップデートに関する記事を掲載している場合は、記事へのリンクを設置します。

改善

  • 使い勝手の向上を目的としたアップデートを記載します。
  • 変更点だけでなく、これまで使用時にどのような不便があったかなどの背景の説明も伝えます。変更点については、どの画面のことなのか、どの操作に関係するのかを詳しく伝えます。
  • また、アップデートに伴って必要な操作がある場合や、アプリケーションの挙動に影響を与える場合には必ず明記します。
  • SmartHR Design Systemのガイドラインに準拠するための変更の場合は、ガイドラインへのリンクもあるとわかりやすいでしょう。

アクセシビリティ向上

不具合修正

  • 不具合の修正について、箇条書きで記載します。
  • どの画面、どのユーザーインターフェースでどのような不具合が修正されたかを伝えます。

廃止した機能

  • 使えなくなった機能について記載します。
  • 事前に機能の廃止をお知らせしていた、サービスサイトのアップデートの記事へのリンクを設置します。

その他の変更

リリースノートの書き方

基本的な考え方

ユーザーにアップデート内容が伝わりやすくするために、「リリースノートはユーザー目線で書く」という考え方を基本にして書きます。
ユーザー目線 とは、コード追加・修正によって生じるアプリケーションの挙動ではなく、ユーザーにとって、何が実現されたかです。

具体的な書き方としては、ユーザーが主語になるよう、(ユーザーが)”〇〇できるようになりました”と書きます。新機能や改善は、「ユーザーに届ける価値」に基づいて開発されています。それを意識して書くようにします。
ユーザーを主語にできない説明は、開発者を主語にして"△△を修正しました"と書きます。

実例1

Before
  • [アカウント情報を更新] ボタンが [依頼一覧] に追加されました。
  • [アカウント情報を更新] ボタンを [依頼一覧] に追加しました。
After

[アカウント情報を更新] ボタンを押すと、[依頼一覧] から最新の従業員情報を再取得できるようになりました。

解説

[アカウント情報を更新] ボタンを追加したことでユーザーができるようになったこと、ユーザーが得られる価値を伝えます。

実例2

Before

バックグラウンド処理一覧に、展開(解凍)したファイル名が文字化けしてしまった際の対応方法を載せたヘルプへのリンクを表示するようにしました

After

バックグラウンド処理一覧に、ダウンロードしたファイルの名前が文字化けした際の対応方法へのリンクを表示しました

解説

無駄な表現を削除し要約する一方、 「ダウンロードしたファイルの名前」 として、ユーザーが変更点を想起しやすくなる言葉を補います。

タイトルはユーザーへの影響が一番大きい変更を選びましょう

変更点が複数ある場合は、ユーザーへの影響が一番大きいものをリリースノートのタイトルにします。記載する順もユーザーへの影響が大きいものから記載しましょう。

タイトルと見出しは、ユーザーを主語にして、業務から想起しやすい表現で書きましょう

タイトルと見出しは、変更点をそのまま書くのではなく、ユーザーの業務や操作時の認知から想起しやすい言葉を使って書きます。

画面上に変更がある場合には、本文中に画面の名前をわかりやすく示しましょう

アプリケーションの操作画面に変更がある場合には、必ず明記しましょう。
見出しに書こうとすると見出しが簡潔にならないので、本文中に書くと良いです。

実例

Before

各設定ページで表組みフォームに設定を一括変更するためのUIが追加されました。

After

評価テンプレート詳細画面のその他の設定で、表組みフォームに対して一括設定できるUIを追加しました。

なんらかの操作を示すときは、ボタンのアクションテキストを明記しましょう

実例

Before

[評価テンプレート編集]の[評価ロール]では、すでに評価が開始されている評価テンプレートを編集する場合に変更が禁止されています。このとき、変更が禁止されていて何も操作することができないにも関わらず、ドロップダウンリストを開けるようになっていました。

After

すでに評価が開始されている場合、取り込み済みテンプレートのうち、評価ロールは変更できません。しかし、[評価ロール]の設定画面の[操作]のドロップダウンリストを開けるようになっていました。

解説

「ドロップダウンリスト」が具体的にどこを指しているかがわかるように、ボタンのアクションテキストを明記しています。

「改善しました」という表現は避けましょう

「改善しました」は、具体的に何が変わったのかが曖昧な表現です。修正しました追加しました変更しましたなど、具体的な変更点が伝わるように書きわけましょう。

実例

Before

評価シート一覧ページの表示項目を改善しました。

After

従業員モードで表示する、評価シート一覧の列のラベル名を[進行中タスク]から[進行中タスク(期限)]に変更しました。また、[タスク担当者]の列を追加しました。

仕様上、制御している操作は、「禁止」ではなく「制御」や「制限」と表現しましょう

disableにしている状態を表すときは、「できない」「制限」「制御」などと書きましょう。
「禁止」には「エラーを引き起こす原因となる操作」という意味が強く、その操作自体が許可されているかどうかは意図されていません。「できないように制御している状態」とは異なります。

ユーザーの関心事の場合、変更点がないことも伝えましょう

実例

UIのみの変更であり、検索結果や付与する権限については変更ありません。

表記は、基本的にプロダクトのライティングガイドライン、用字用語に則りましょう

特に下記は頻出するため、覚えておきたいルールです。