リリースノートの書き方

開発チームから「対応完了」の一覧を受け取り、利用者向けのお知らせにどう書き直すか迷っていませんか。リリースノートは、製品やサービスの変更内容を利用者へ伝える文書です。「誰に関係するか」「何が変わるか」「必要な操作はあるか」をそろえると、自分への影響を読み取ってもらいやすくなります。

この記事では、提供済みの変更を案内する基本の書き方を説明します。新機能、操作の変更、不具合修正の文例は、説明用の架空の業務ツールを題材にします。アーコレや実在する製品の機能、提供日、実績を示すものではありません。

誰に関係する変更かを、最初に書く

変更点を読む人は、まず自分に関係するかを知りたいはずです。「管理画面を改善しました」だけでは、管理者だけが対象なのか、一般の利用者にも影響があるのか分かりません。「申請を承認する方へ」のように、対象の役割や業務を示します。

書き始める前に、開発担当者と次の情報をそろえます。社内のタスクが完了していても、すべての利用者が使える状態とは限りません。

段階的に提供する場合は、まだ使えない利用者にも一斉に「使えます」と伝えないようにします。案内の公開日と機能の提供日が異なるなら、その違いも明記します。確認できていない対象や日付は、推測で補いません。

今後の計画を知らせるロードマップや、個別の要望への返事とは目的が異なります。特定の顧客への受付・検討中・見送りの連絡は、機能要望への返信文例で扱っています。

変更前と変更後を、利用者の言葉で伝える

開発の作業名だけでは、利用者の作業がどう変わるかは伝わりません。「検索処理の改修」なら、どの検索がどのように変わったのかを確かめてから、案内文へ直します。

SmartHRの公式デザインガイドは、リリースノートの書き方で、利用者ができるようになったことを伝え、変更する画面や操作を具体的に示す方針を説明しています。GitLabの公式執筆ガイドも、読み手が何をできるかを中心に書くよう求めています。両社の方針を参考に、上の表では開発の作業名を利用者の行動が分かる文へ書き直しました。

利用者は、その変更でどの作業ができるようになるのでしょうか。「大幅に効率化します」と書くより、「未処理の申請だけを一覧に表示できます」と書けば、利用者が使う場面を考えられます。測っていない時間短縮率や、確認していない顧客の評価は付け加えません。

必要な操作と注意点を添える

変更のお知らせを読んだ利用者は、最初に何を操作すればよいでしょうか。設定が必要なら、誰が、どの画面で、何をするかを書きます。更新や設定が不要と確認できた場合は、「追加の設定は不要です」と明記できます。

すべての操作手順をリリースノートに詰める必要はありません。最初の操作と注意点を載せ、詳しい手順は該当するヘルプページへつなぎます。「こちら」というリンク文字だけでは、行き先が分かりません。「通知の設定方法」のように、リンク先で分かることを書きます。

注意点には、対象外の画面や既存データへの影響など、利用者の判断に必要な情報を選びます。旧操作が使えなくなる場合は、新しい操作と切り替え時期を伝えます。事前の準備が必要な変更では、提供後の案内だけでは利用者の準備が間に合いません。利用者が準備できる時期に別途案内します。

新機能・操作の変更・不具合修正を書き分ける

以下は、架空の業務ツール「申請ボード」で変更を提供したと仮定した文例です。利用条件や画面名も説明用の設定です。実際に使う際は、自社で確認した事実に合わせます。

新機能は、何に使えるかを伝える

未処理の申請だけを一覧に表示できます

対象は、申請を承認する方です。申請一覧に「未処理」の絞り込みを追加しました。これまで一覧から探していた未処理の申請を、まとめて表示できます。

申請一覧の「状態」で「未処理」を選ぶと表示が切り替わります。追加の設定は不要です。閲覧できる申請の範囲は、これまでと変わりません。

この文例は、対象者、変更によってできること、最初の操作、閲覧範囲の順に書きました。「全員がすべての申請を見られるようになった」という誤解を避けるため、変わらない条件も添えています。

操作の変更は、新しい場所を示す

添付資料を開くボタンの場所が変わりました

申請の添付資料を確認する方が対象です。詳細画面の下部にあった「添付資料」ボタンを、画面上部へ移動しました。

今後は、申請の詳細画面を開き、上部の「添付資料」を選んでください。登録済みの資料の内容や、閲覧権限に変更はありません。

「使いやすくしました」だけで終えず、前の場所と新しい場所を示しています。利用者が慣れた操作を続けようとしたときに、どこを探せばよいか分かる説明です。

不具合修正は、起きていた条件と対応を伝える

月をまたぐ申請の完了日表示を修正しました

月末に申請し、翌月に完了した一部の申請で、一覧の完了日が1日ずれて表示される不具合を修正しました。

保存されている完了日時には影響がなく、表示だけの問題でした。対象の申請も正しい日付で表示されます。利用者による再入力や設定変更は不要です。

この文例の「保存データに影響がない」「再入力が不要」は、開発担当者が確認したという仮定です。不具合が直ったことだけを理由に、データへの影響や利用者の対応まで推測しないでください。

ここまでの文例では、提供日や対象の版を省きました。実際のリリースノートでは、本文の上部など、見つけやすい場所に記載します。複数の変更で提供日や対象が違う場合は、変更ごとに補足します。

公開前に、実際の画面と案内を照合する

利用者は案内どおりに操作できるでしょうか。開発担当者だけでなく、利用者から質問を受ける担当者にも読んでもらうと、説明が足りない箇所を確かめられます。

確認では、対象者と提供範囲が合っているか、画面名やボタン名が実物と同じか、必要な操作が抜けていないかを見ます。ヘルプへのリンクも、開くだけでは確認が終わりません。リンク先が、案内した操作を説明しているかまで照合します。

公開後に誤りが分かった場合は、訂正内容と更新日を残し、すでに読んだ人にも変更が分かるようにします。利用者の作業に影響する訂正なら、本文の修正だけでは気づいてもらえないかもしれません。必要な操作を誤って案内した場合などは、追加の連絡も検討します。

リリースノートで変更を知らせた後、利用者に案内が届いたか、機能が使われたかを確かめる方法は、機能改善の効果を確かめる方法で扱っています。今後の改善計画の伝え方は、プロダクトロードマップの作り方を参照してください。