更新を伝え続ける仕組みをつくる
公開直後の告知が一段落すると、発信は途絶えがちです。しかし個人開発の信頼は、「ちゃんと更新され続けている」という事実の積み重ねから生まれます。逆に、最終更新が1年前に見えるプロダクトは、それだけで選ばれにくくなります。
この記事では、更新情報（チェンジログ）を無理なく書き続け、一度書いたものを複数の場所で使い回す仕組みを整理します。
チェンジログは利用者のために書く
チェンジログの書き方には、Keep a Changelogというよく知られた指針があります。中心にある原則は「チェンジログは機械のためではなく、人間のために書く」です。そこから、個人開発でそのまま使える形に絞ります。
バージョンや日付ごとに、新しいものを上にしてまとめる
変更を種類で分ける。「追加」「変更」「修正」の3つから始めれば十分です
コミットログの貼り付けにしない。利用者に見える変化の言葉で書く
たとえば「refactor: extract validation module」ではなく、「入力エラーの表示が速くなりました」と書きます。内部の改善でも、利用者にとって何が変わるのかまで訳すのがチェンジログの仕事です。
置き場所を一つ決める
更新情報の「正本」を置く場所を一つ決めます。候補は次のとおりです。
サイト内の更新ページ：利用者が最も見つけやすく、検索にも載ります
GitHub Releases：コードをGitHubで公開しているなら、タグと配布物に紐付けて履歴を残せます。GitHub Docsでは、リリースごとにノートと成果物をまとめて公開する仕組みとして説明されています
リポジトリ内のCHANGELOG.md：開発者向けプロダクトなら十分に機能します
大切なのは場所の優劣より、「一次情報を一箇所に決め、他はそこからの転載にする」ことです。複数の場所を別々に手書きすると、必ずどこかが古くなります。
一度書いて三回使う
更新のたびにゼロから発信を考えると続きません。正本のチェンジログを起点に、同じ内容を形を変えて使い回します。
正本：チェンジログに「追加・変更・修正」を書く
SNS：その中から利用者に一番うれしい1項目だけを選び、画面の画像かGIFを添えて投稿する
アプリ内・サイト内のお知らせ：既存の利用者に見える場所で、同じ1項目を短く伝える
告知の経路や書き方に迷ったら、公開直後のマーケティングを小さく始めるで選んだ経路をそのまま使います。新しい経路を増やすより、同じ経路で回数を重ねるほうが、個人開発では効果を確認しやすくなります。
続けるためのルールを小さくする
続かない原因は、ルールが大きすぎることです。次のような最小ルールから始めます。
リリースしたら、その日のうちにチェンジログへ1行書く（あとでまとめて書こうとしない）
毎週書くとは決めない。更新があったときだけ書く
修正だけの地味な更新も書く。「直し続けている」こと自体が信頼になります
要望や不具合報告への対応を更新として書くと、利用者の声を改善バックログに変えるで拾った声が「伝わる形」で利用者へ返っていきます。声をくれた人にとって、自分の報告が反映されたチェンジログは何よりの返信です。
次に読む記事
運用の定期確認と組み合わせるなら公開後30日を無理なく運用するへ。利用者の声の拾い方は利用者の声を改善バックログに変えるで整理しています。