リリースノートに書く7項目｜問い合わせを減らす形

「更新のお知らせは毎回出しているのに、同じ質問が窓口に来ます」「直したことは全部書いたはずなのですが、読まれていないようです」——自社の製品やサービスの更新を顧客に伝えている担当者からは、この二つがほぼ同じ言い方で返ってきます。公開されている書き方の指針を並べてみると、行き着く先は同じ一点です。読み手が知りたいのは、変わったことの一覧ではありません。自分がこれから何かしなければいけないのかどうか、その一点です。この記事では、読み手が3種類いることから始めて、入れる7項目と、それぞれが抜けるとどこから問い合わせが来るのか、規約や個人情報の扱いが変わる回だけ告知の位置づけが変わること、出す頻度と単位の決め方、そして下書きをAIに任せてよい範囲までを順に整理します。

出したのに、同じ問い合わせが来るリリースノート

更新のお知らせを出しているのに窓口の件数が減らないとき、たいてい書かれているのは「何を直したか」です。不具合の修正が12件、機能の追加が3件、といった具合に並んでいる。書いた側から見れば漏れのない一覧ですが、読む側はその中に自分の行があるかどうかを探しています。探して見つからなければ、探すのをやめて聞きに来ます。

件数が多い回ほど読まれない、という逆転がここで起きます。20件並んだ回と3件の回では、3件の回のほうが最後まで読まれます。20件の回は、上から3件目あたりで自分に関係なさそうだと判断されて閉じられる。網羅性を上げるほど、伝わる量は減ります。この関係に気づかないまま、「もっと詳しく書こう」という方向に直してしまうと、件数がさらに増えて悪化します。

直す向きは逆です。書く量を増やすのではなく、読み手が自分の行を先に見つけられるようにする。そのために必要なのは、変更ごとに「誰に関係するか」を先に書くことです。文書共有の道具を提供している会社が公開している解説も、リリースノートを書くときの考慮事項の1番目に「このリリースノートは誰を対象としているか」を置いています。対象を決めてから書き始めるという順序が、そのまま読み手の探す手間を決めます。

読み手は3種類いる——使っている人、止まると困る人、決めた人

外に出す告知の読み手は、大きく三つに分かれます。毎日その画面を触っている人。自分では触らないが、止まると業務が止まる立場の人。そして、そのサービスを入れると決めた人です。三者が知りたいことは重なっていません。同じ1本で全員に届けようとすると、どれかが薄くなります。

触っている人が知りたいのは、明日から操作が変わるかどうかと、変わるならどこかです。止まると困る人が知りたいのは、作業を止める時間帯があるか、他の仕組みとのつなぎ目に影響があるかです。決めた人が知りたいのは、契約や費用の条件が変わるかどうか。この三つを一つの見出しの下にまとめると、どの読み手も自分の行を探すことになります。

三者に分けて出す、という方法もありますが、運用が続かないことが多い。現実的なのは、1本の中で変更ごとに対象を明記するやり方です。「この変更は、管理者の権限を持つ方に関係します」「この変更は、外部との連携を使っている場合にだけ影響します」。この一行があるだけで、関係のない人は1行で判断して次に進めます。読み飛ばせるようにすることが、読ませることの前提になります。

直したことを並べただけの告知が読まれない理由

開発の記録には、変更の単位が細かく残っています。そこから起こすと、どうしても「何をしたか」の一覧になります。「一覧表の並び替え処理を修正しました」と書いてあっても、読み手は自分がその処理を使っているかどうかを知りません。読み手は仕組みの名前を知らないまま使っています。だから仕組みの名前で書かれると、関係の有無を判断できません。

人事労務の業務システムを提供する会社が公開している文書の設計指針は、この点をはっきり書いています。書く軸は、コードを追加したことではなく、利用者が何をできるようになったかである、という立て方です。同じ指針は、できるようになったことだけでなく、できなくなったことも書くべき情報だとしています。できなくなったことは、書かないと必ず問い合わせになります。

言葉づかいの指針も具体的です。同じ資料は「改善しました」を曖昧な表現として避け、「修正しました」「追加しました」「変更しました」を使うとしています。また「禁止」という語は、許可されている状態と混同されやすいので、「制御」や「制限」といった具体的な言い方に置き換えるとしています。細かく見えますが、曖昧な動詞は読み手に「自分に関係あるのか」を判断させないので、そのまま問い合わせに変わります。

7項目を決めた根拠——抜けると、どこから問い合わせが来るか

入れる項目は7つです。項目名を覚えても点検はできないので、抜けたときに、どこから何を聞かれるかと対で置きます。この右の列が、その項目を入れる根拠そのものになります。

項目	抜けたときに来る問い合わせ	誰から来るか
1 いつから変わるか	「もう変わっているのか、まだなのか」	触っている人
2 誰に関係するか	「うちの契約でもこれは起きるのか」	決めた人
3 できること・できなくなること	「今までできたあれは、まだできるのか」	触っている人
4 読み手にやってもらう作業	「こちらで何かする必要はあるのか」	止まると困る人
5 見た目と操作が変わる場所	「画面が変わって、どこを押せばよいか分からない」	触っている人
6 古い版の期限と戻せるかどうか	「前のやり方はいつまで使えるのか」	止まると困る人
7 行き先と分かっている不具合	「うまく動かないが、これは既知の話か」	全員

表の右の列を見ると、問い合わせてくる相手が項目ごとに違うことが分かります。1と3と5が抜けると触っている人から件数が来て、4と6が抜けると業務を止める側から重い問い合わせが来ます。2が抜けると、決めた人から契約の確認が来る。窓口に来ている質問の種類を数えると、抜けている項目が特定できます。件数の多い質問から順に、対応する項目を埋めていけば足ります。

項目1　いつから変わるか——日付だけでなく、切り替わり方まで

最初に書くのは日付です。ただし日付だけでは足りません。その日をまたいだ瞬間に全員が切り替わるのか、順に切り替わっていくのか、利用者が自分で切り替えるまで前のままなのか。切り替わり方によって、読み手がその日にすることが変わります。

時刻も書きます。「4月1日から」と書くと、3月31日の夜に作業をしている人が困ります。「4月1日の午前2時から」と書いてあれば、その前後を避けられます。止まる時間があるなら、止まる時間帯は日付ではなく時刻の幅で書きます。何時から何時までのあいだ、どの操作ができないのか。この幅がないと、業務の予定を組む側は最悪を想定して1日空けることになります。

段階的に切り替える場合は、その旨と、自分がいつ切り替わるのかを知る方法を書きます。「順次適用します」だけで終わると、「うちはいつですか」という問い合わせが、適用が終わるまで毎日届きます。画面のどこかで確認できるなら、その場所を書く。確認する方法がないなら、問い合わせが来る前提で窓口に想定問答を渡しておくほうが早い。書けないことがあると分かったら、告知の側ではなく窓口の側で受ける準備をします。

項目2　誰に関係するか——範囲を先に名指しする

2つ目は対象です。「すべての利用者の皆さま」と書かれた告知は、結果として誰にも自分事になりません。書くのは、契約の種類、権限の区分、使っている機能、つないでいる外部の仕組み、といった具体的な絞り込みです。絞り込めない変更は、絞り込めないと書きます。

対象の書き方には順番があります。先に「関係しない人」を書いたほうが速く読み終わります。「この変更は、外部との連携を使っていない場合には影響しません」。この一行で、大多数の読み手はそこで読むのをやめられます。読み終わらせることが、次の告知を読んでもらう条件になります。毎回最後まで読まないと分からない告知は、そのうち開かれなくなります。

対象を絞るときに気をつけたいのが、自社の内部の区分で書いてしまうことです。料金の内部呼称や、開発上の機能名で書かれても、読み手は自分がそれに当たるかを判断できません。契約書や請求書に出てくる名前、あるいは画面に表示されている名前で書きます。読み手が自分で確認できる名前だけを使う、という規則にすると、書くときに迷いません。確認できる場所も一緒に書くと、そこで判断が終わります。

項目3　できるようになったことと、できなくなったこと

3つ目が変更の中身です。ここで守るのは、動作ではなく結果で書く、という一点です。「並び替えの処理を最適化しました」ではなく、「一覧を古い順に並べ替えられるようになりました」。読み手の手元で何が変わるかだけを書きます。内部の仕組みの話は、書いても判断の材料になりません。

できなくなったことは、できるようになったことより前に書きます。順番を逆にするのは、できなくなったことのほうが読み手の予定を壊すからです。「これまで一括で取り出せた項目のうち、取引先の担当者名は取り出せなくなります」。この一行が後ろにあると、読まれずに当日を迎えて、その日の問い合わせが跳ねます。書きにくい行ほど前に置く、と決めてしまうのが確実です。

変わらないことを書く、という手もあります。大きな変更の回ほど、読み手は「他のところも変わったのでは」と疑います。「保存済みの設定と、取り出した過去のデータに変更はありません」の一行があると、そこで疑いが止まります。人事労務の業務システムを提供する会社の指針も、本文に入れる要素として、画面上の変更点と、その背景と、利用者から見て変わらないことまでを挙げています。変わらないことを書くのは、丁寧さではなく、問い合わせを止める仕掛けです。

項目4　読み手にやってもらう作業があるかどうか

4つ目は、読み手側の作業です。これが書かれていない告知は、止まると困る立場の人から必ず問い合わせが来ます。「こちらで何かする必要はありますか」。この質問が来ているなら、項目4が抜けています。作業がないなら、ないと書きます。書かないことは、ないことにはなりません。

作業がある場合は、四つの単位で書きます。誰が、何を、いつまでに、やらなかったらどうなるか。最後の一つが抜けやすい。「期限までに設定を変更してください」だけだと、期限を過ぎたときに何が起きるかが分からないので、急ぐべきかどうかを判断できません。やらなかったときに何が起きるかまで書いて、初めて期限が意味を持ちます。

作業を頼むときは、頼む相手の権限も書きます。「管理者の権限を持つ方が」と書いておかないと、権限のない人が画面を探して見つからず、そこで問い合わせが1件生まれます。作業の量も書きます。1か所を1回押すだけなのか、対象の件数だけ繰り返すのか。件数で変わる作業は、件数の数え方も書く。数えられないと、いつ終わるかが読めず、後回しにされます。

項目5　見た目と操作が変わる場所を、先に名指しする

5つ目は、画面の変化です。機能が同じでも、置き場所が変わっただけで問い合わせは増えます。「設定は右上のメニューの中に移動しました」のように、移動前と移動後の両方を書きます。移動後だけを書くと、前の場所を覚えている人が探し直すことになります。

名指しするときは、画面の名前とボタンの名前を実際の表示どおりに書きます。説明のために言い換えると、読み手は画面と突き合わせられません。文書共有の道具を提供している会社の解説も、画面の画像や短い動画を添えることを勧めています。並べた画像は、文章5行分の説明を置き換えます。ただし画像だけにすると、読み上げで読む人に届きません。文章と画像は両方置きます。

見た目が変わる回は、告知を出す時期も変わります。操作が変わる変更は、当日ではなく事前に出すほうが効きます。事前に出しておけば、読み手は自分の都合のよい日に確かめられます。当日に出すと、変わったことに気づいてから探すことになり、その時間帯に問い合わせが集中します。操作が変わる回だけ、事前告知を1本足す。毎回やる必要はありません。変わる回だけです。

項目6　古い版はいつまで使えるか——移行の期限と、戻せるかどうか

6つ目が、古い版の扱いです。新しいやり方に切り替わる回で、前のやり方がいつまで使えるかを書いていないと、業務を止める側の判断が止まります。期限が分からないと、移す予定が組めません。組めないので、そのまま様子見になり、期限の直前に問い合わせが集中します。

書く内容は三つです。前のやり方が使える最終日。その日を過ぎたときにどうなるか。そして、切り替えたあとで前に戻せるかどうかです。戻せるかどうかは、試す気になるかどうかを直接左右します。戻せると書いてあれば、早めに試す人が増えます。早めに試した人からの指摘は、期限の直前に来る指摘より、はるかに扱いやすい。

廃止する機能については、事前告知への案内を置きます。人事労務の業務システムを提供する会社の指針も、廃止する機能には事前告知の記事へのリンクを置くとしています。廃止は1回の告知で終わらせず、予告、期限の再通知、実施の3回に分けるのが実務的です。1回しか出していない廃止は、必ず取り残しが出ます。3回に分けると、どこかで気づいてもらえます。取り残しが出たときの受け止め方も、先に窓口と決めておきます。

項目7　行き先と、分かっている不具合

7つ目は、うまくいかなかったときの行き先です。問い合わせ先を書くのは当然として、その手前に置きたいのが、すでに分かっている不具合の一覧です。分かっているものを先に出すと、同じ報告が重複して来なくなります。隠しても、使われれば見つかります。見つかってからのほうが説明が重くなります。

書き方は、症状と、当たる条件と、回避のしかたと、直す見込みの4つです。直す見込みが立っていないなら、立っていないと書きます。「調査中です」と書いてあるほうが、何も書かれていないより問い合わせは減ります。読み手が困るのは不具合そのものより、自分の環境の問題なのかどうかが分からない状態のほうです。

行き先は、窓口の名前と、そこに何を添えて連絡すればよいかまで書きます。「発生した日時と、画面の名前と、契約の識別番号を添えてください」。これが書いてあると、1往復目で調べ始められます。書いていないと、聞き返しが1往復増えます。1往復の削減は、件数の削減と同じだけ効きます。件数が減らせない回でも、往復は減らせます。

規約や個人情報の扱いが変わる回は、告知の位置づけが変わる

ここまでは、読みやすさの話でした。ただし、利用規約の内容が変わる回と、取得した情報の使い道が変わる回だけは、告知がお知らせではなく、効力の条件になります。書き方の巧拙ではなく、出したかどうかが問われる、という違いです。

利用規約が定型約款に当たる場合、民法第548条の4が関わります。同条第2項は、定型約款準備者が変更をするときは、その効力発生時期を定め、かつ、変更する旨と変更後の内容と効力発生時期を、インターネットの利用その他の適切な方法により周知しなければならない、と定めています。同条第3項は、相手方の一般の利益に適合する場合以外の変更について、効力発生時期が到来するまでに周知をしなければ効力を生じない、としています。効力発生の日を決めることと、その日より前に知らせることの2つが条文に書かれています。つまり告知の日付は、読みやすさの問題ではなくなります。

取得した情報の使い道が変わる回には、個人情報の保護に関する法律が関わります。同法第21条第3項は、利用目的を変更した場合は、変更された利用目的について、本人に通知し、または公表しなければならない、と定めています。また同法第17条第2項は、利用目的を変更する場合には、変更前の利用目的と関連性を有すると合理的に認められる範囲を超えて行ってはならない、としています。どの条件で問題になりうるかは個別の事情で変わるので、この2種類の回だけは、出す前に法務に回すと決めておきます。以下は、法務に回すかどうかを判断するための目安です。

• 利用規約や個別の契約条項の文言が変わる回
• 取得した情報の使い道、保存する期間、渡す先が変わる回
• 料金や課金の条件、無料で使える範囲が変わる回
• 機能を廃止して、これまでできていたことができなくなる回
• 外部の事業者に処理を任せる範囲が変わる回

出す頻度と単位を、どう決めるか

頻度は、開発の都合ではなく読み手の都合で決めます。毎日出すと読まれず、四半期に1回にまとめると1本が長くなって、やはり読まれません。決め方の軸は二つです。読み手が予定を組むのに必要な余裕と、変更が読み手の作業を伴うかどうかです。

作業を伴わない変更は、まとめて出して構いません。不具合の修正や、表示の細かい調整はここに入ります。作業を伴う変更と、できなくなる変更は、まとめずに単独で出します。まとめた回の中に埋めると、作業が必要な行が読み飛ばされます。1本にまとめる判断は、件数ではなく、その中に作業を伴う行があるかどうかで決めます。

出す時期についても、先に決めておくと迷いません。文書共有の道具を提供している会社の解説は、リリース日に出すのか、その前に出すのかを先に決め、下書きの間は非公開にして、全体を確認してから公開範囲を変えることを勧めています。実務では、作業を伴う回は前に、伴わない回は当日に、と分けておくと運用が続きます。毎回考えると、忙しい回ほど確認が飛びます。同じ解説は、社内向けの変更履歴と顧客向けの公開版を分け、公開の範囲を権限で制御することも勧めています。過去の回を一覧にして残しておくと、あとから担当になった人が経緯を追えます。窓口に届く質問には、半年前の変更についてのものが必ず混ざります。そのときに当時の告知をそのまま示せるかどうかで、説明にかかる手間が変わります。

下書きはAIに任せ、書かないことの線引きは人が決める

変更の記録から告知を起こす作業は、量が多いのでAIが向いています。任せてよいのは四つです。第一に、変更の記録から下書きを起こすこと。第二に、同じ変更についての言い換えをそろえること。第三に、過去の回の書き方に合わせること。第四に、影響を受ける相手の洗い出しです。この四つは、間違っていても人が見れば分かります。

三つ目の「過去の書き方に合わせる」は、地味ですが効きます。書く人が交代すると、同じ変更でも言い方が変わります。「変更しました」と「対応しました」が混ざると、読み手は違いがあるのかと考えてしまいます。過去10回の告知を渡して、使っている動詞と語尾の一覧を作らせ、そこから外れた行を指摘させる。この使い方なら、判断はすべて人の側に残ります。

人が決めるのは三つです。何を書かないか。影響があると言い切るかどうか。日付と対象の確定。この三つに共通するのは、記録の中には答えがないということです。書かない判断は、社内の事情と相手との約束で決まります。影響を言い切れるかどうかは、確かめた人がいるかどうかで決まります。日付は、社内の別の予定と突き合わせて初めて決まります。だから「この告知でよいですか」と聞かないでください。聞いてよいのは「前の回と言い方がずれている行はどれですか」までです。運用では、人が確認する範囲を先に決めます。日付、対象、できなくなること、料金に関わる記述。この4か所は、AIが書いた文字を残さないと決めておくのが確実です。根拠を書かせることもできますが、その根拠が本当に記録にあるかは、人が開いて確かめる工程が要ります。

任せた結果がどう崩れるかも、型として知っておくと防げます。変更の記録をそのまま流して出した告知には、次の四つが出ます。

• 仕組みの名前で書かれている——「同期処理を修正しました」と書かれても、読み手は自分が使っているか分からない
• 対象がすべて「全ユーザー」になっている——記録には契約の区分が入っていないので、書き分けようがない
• できなくなったことが、改善として書かれている——記録上は同じ1件なので、良い変更として並べられてしまう
• 日付が記録上の日付になっている——実際に切り替わる日とずれ、その差の分だけ問い合わせが来る

出す前に見る確認項目

最後に、出す直前の手順を決めておきます。書き上げてから公開するまでの間に、読み手の立場で1回読み直す工程を必ず挟みます。書いた本人は、変更の中身を知っているので、書いていないことに気づけません。

この5工程のうち、削ってよいのは2だけです。1と3を飛ばすと項目が埋まらず、4と5を飛ばすと出したあとに撤回することになります。急ぐ回は、文章の仕上げを落として、確認の工程を残すほうが、結果として早く終わります。

まとめ

リリースノートが読まれないのは、書き方が下手だからではありません。読み手が探しているのは変更の一覧ではなく、自分に関係があるかどうかの1行だからです。入れるのは7つ。いつから変わるか。誰に関係するか。できるようになったことと、できなくなったこと。読み手にやってもらう作業。見た目と操作が変わる場所。古い版の期限と、戻せるかどうか。行き先と、分かっている不具合。どの欄が空いているかを見れば、どの質問が窓口に来るかが先に分かります。

規約の文言や情報の使い道が変わる回だけは、告知の位置づけが変わります。民法第548条の4は、定型約款を変更するときに効力発生時期を定め、その到来までに周知することを求めています。個人情報の保護に関する法律第21条第3項は、利用目的を変更した場合の通知または公表を求めています。頻度は、作業を伴う変更を単独で出し、伴わない変更をまとめる、で決める。AIには、下書きの起こし、言い換えのそろえ、過去の回への追随、影響を受ける相手の洗い出しまでを任せる。日付と対象とできなくなることと料金の4か所には、AIが書いた文字を残さない。この線を引いてから出すようにすると、告知の本数を増やさずに、窓口に届く質問の種類が減っていきます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。