noteのiOSアプリのリリースノートを書き続けて約1年が経つので振り返り
モバイルチームに誘ってもらい、noteのiOSアプリ(以下アプリと表記)のリリースノート作成を担当しています。ver 3.6.0(現在は ver 5.10.2)から担当し、その数もかなり多くなってきたので、自分がどういう意図を込めて書いてきたのか、振り返ってみようと思います。
リリースノートを担当するようになったきっかけ
2020年5月のことでした。CXOの深津さんがSlackのリリースノートがいいとシェアしていて、それにのっかる感じで「大きいカイゼンのときはやってみたい」と手を挙げてみました。
ただ、当時の自分は何がすごいのか言語化できなかったので、自分もSlackのリリースノートを写経したことをきっかけに「UXライティング」という分野を知り、書籍や記事で学んだことをnoteにまとめて公開しました。
そのタイミングで、改めてモバイルチームから声をかけてもらったのです。
リリースノートを公開するまでの流れ
アプリは通常2週間おきにリリースをしているので、それに合わせてリリースノートを作成しています。紆余曲折の末、以下の流れに落ち着きました。
水曜日 : 「リリースノート共有会」を開催
iOSエンジニアのかっくんさんに、今回のリリース内容を共有してもらいます。カイゼンした箇所のBefore&Afterの画面収録をみたり、挙動について質問したり、テキストのニュアンスを相談したりします。
水〜木曜日 : リリースノートを作成
その週の金曜日に「リリースノート検討会」があるので、それまでに準備をします(書くときに気をつけていることは後述)。作成したテキストは、GitHubにアップします。
金曜日 : 「リリースノート検討会」を開催
リリースノート検討会は、iOSだけでなくAndroidアプリも合わせておこないます。モバイルチームと一緒に自分がGitHubに書いたリリースノートをZoomで映しながら、文言検討をおこないます。伝え方をもっとよくできないか、認識のズレがないかを確認する場でもあります。
当初はCrowi(社内で使用しているWikiサービス)に書いているカイゼン内容を元に、自分がSlack上でテキストをアップし、フィードバックをSlack上でおこなっていました。しかし、テキスト上でのやり取りだと細かいニュアンスが掴みづらく手戻り回数が増えてしまったため、現在のように、事前にGitHubにテキストをアップしておき、Zoomで画面を映しながら確認する形に落ち着きました。
リリースノートを書くときに気をつけていること
これまでにもらったフィードバックや、書いていく中で言語化してきたことをまとめてみます。
リリースノートに書く基準
カイゼンの場合
操作、見た目が変わること
アプリ体験がよくなること
気づかれにくいけど周知しておきたいこと
アプリならではの独自体験
バグ修正の場合
「あ、困っていたわ」と思う不具合
カイゼン目安箱でいただいたフィードバック
開発者視点ではなくクリエイターから見て分かる不具合
書くときのポイント
エンジニアから共有されたテキストはそのまま使わない
どういうシチュエーションで起きるかを想像して書く
使うひとの目線に立つ(例 : 〇〇のボタンを押すと〇〇できます)
操作体験の問題や課題の解決に共感する(例 : 〜ですよね)
エンジニアでなくても伝わるか考える(専門用語は極力使わない)
これ以上、端的に誤解なく伝えられないか考える
表記揺れや重複表現はないか、表記ルールを確認する
表記ルールはスプレッドシートで一元管理
今のところは僕がメインでリリースノートを書いていますが、今後のことを考えると、他のメンバーでも書ける状況が望ましいと思っています。
なので、「表記ルール」というスプレッドシートを作成し、リリースノートを書く中で決まったことを随時追記しています。書く内容は大きく3つ。
この「表記ルール」は、アプリに限らず、noteサイト内の漢字/かな表記や、半角/全角表記、ページ名/画面名など、いろんなルールを1つのスプレッドシートにまとめています。そして、誰がいつ更新したかわかるように、日付と更新したひとの名前を入力しています。
リリースノートの試行錯誤
実際、どういうふうにリリースノートをつくっているのか、変更前後のパターンをいくつか挙げて、その意図を合わせて書いてみます。
1. ver 4.0.0
投稿画面のデザインが変わり、アプリでnoteを書く体験が大幅に変わったメジャーアップデート。どこがどう変わったか細かく説明するよりも、「使いやすくなったこと」を全面に出すほうがいいと考えて書きました。
2. ver 5.0.0
カイゼン記事でも合わせて告知した、iPad に対応時のメジャーアップデート。以前からたくさんの要望をいただいていて、投稿画面のリプレイスを経て、ついに対応することができました。このリリースノートでは、実際に何ができるようになったのか、「Split View」などのAppleサポート内の用語に準拠しながら具体的に書くことを心がけました。
3. ver 5.8.0
こちらもカイゼン記事にまとめましたが、アプリのアクセシビリティ向上に関するリリースノート。かなり多くのカイゼンを行ったため、ある程度数をしぼらないと多すぎて読んでもらえません。そのため、まとめられる内容はまとめて整理し、ざっくりと何に対応したのかわかるようにテキストを書きました。合わせて、アクセシビリティ向上プロジェクトのインタビュー記事が公開されたので読んでみてください。
非エンジニアの自分がリリースノートを書く意味
これは密かな趣味なのですが、いろんなアプリのリリースノートを見るのが大好きです。アプリのリリースノートは、アプリ開発者からのメッセージ だと思っているので、どんな内容をアップデートしたのか、その意図を知れば知るほど、アプリに愛着がわいてきます。
しかし最近、GoogleやMessagerなどの大きなサービスのリリースノートは定型文になっていることが多く、もっと詳しく書けばいいのに…と思っていました。そこに課題意識を感じていたので、非エンジニア(使うひとに近い立ち場)の自分が、使うひとの目線から伝えるのであれば、価値を出せるのではないかと思って書き続けています。
「すばやく試そう」というバリューのもと、どんどんアップデートが進んでいます。アプリ体験、格段に良くなっています。ぜひダウンロードして使ってみてください!
モバイルチームのインタビュー記事は、以下の記事にまとまっています!iOSエンジニアも絶賛 募集中 とのことです。
いずれは、リリースノートの作成を他のメンバーでもできるよう、表記ルールやノウハウをまとめ、委譲していくことも検討に入れていきたいです。
よろしければサポートお願いします! いただいたサポートは新しいサブスクを試すための資金にさせていただきます!