デザインドリベン（王道）PLG

第一章：共に成長する

2026年8月25日

EN 日本語

チェンジログは、プロダクトがどう変わってきたかの記録だ。ほとんどのチームはそれを義務のように扱っていて、その感覚は理解できる。リリースという仕事自体が消耗するものであり、その記録は仕事の最後に残る事務処理のように感じられるからだ。変更がリリースされ、一行が追加され、チームは次のことに移っていく。このプロセスのどこにも、誰かに何かを感じさせようとする意図はない。

しかし、チェンジログは、企業が自らの軌道をさらけ出す数少ない場所のひとつであり、人々がコミットするかどうかを判断するときに見ているのは、まさにその軌道だ。

プロダクトを選ぶことは、投資をすることだ。 チームが知りたいのは、そのツールが今日何をしてくれるかだけではない。1年後に何ができているか、メンテナンスされ続けているか、そしてその選択が承認した人たちの目にも妥当に映るかどうかだ。その答えの大部分は、機能一覧では出せない。意味のある仕事が継続的にリリースされ続けている記録は、誰も約束をせずにその問いに答えてくれる。だからこそチェンジログは、企業が示せる最も信頼できる「これからの姿」についての主張になる。

このシグナルが果たす役割は、誰が読むかによって変わる。見込み客にとっては、着実なペースで改善がリリースされ続けていることが、そのプロダクトが生きていて、参加する価値のある方向に進んでいることの証明になる。既存ユーザーにとっては、それぞれのアップデートが、目の前のタスクとは関係なく「また見に行こう」と思わせる理由になる。これはチームがわざわざ作り出す必要のなかったエンゲージメントだ。そして、社内でプロダクトの承認を勝ち取ろうとしているチャンピオン（推進者）にとって、チェンジログは弾薬になる。社内で必要な説得は、ほとんどの場合、機能ではなくモメンタムについてのものだからだ。

すべてのアップデートを、祝うべき瞬間にする

FigmaもLinearも、規模は違えどこれを理解していた。Configはそれを年に一度体現するイベントであり、会場に集まった人々が、プロダクトが何になりつつあるのかを一緒に発見し、読むのではなく体験して帰っていく場だ。Linearはその週次版を運用していて、記録するのではなく、まるで誰かがプロダクトの成長を語り聞かせているかのようなチェンジログを公開している。仕組みはどちらの規模でも同じだ。何が変わったかを伝えるのではなく、それがより良くなっていく様子を見てもらう。

この2つの事例の間にあるギャップこそが、多くのチームが読むのをやめてしまうポイントでもある。この種の仕事には、自分たちにはないチームと予算が必要だと思い込んでしまうからだ。だが、そんなことはない。この実践には度合いがあり、役に立つ判断力はその度合いを、変更の重要度に合わせることだ。

4つのレベル

レベル1：伝え方を磨く

同じチェンジログを、より丁寧に書くだけだ。「何が追加されたか」ではなく「何が良くなったか」を書く。「パフォーマンスの改善」よりも「コメントが瞬時に読み込まれるようになった」の方が、ずっと多くのことを伝えるからだ。これには注意力以外に何のコストもかからず、それだけでほとんどの企業と差がつく。

Linearのチェンジログは、質の高いプロダクト体験と同じ水準のクラフトでデザインされている。それぞれの変更がもたらす価値は、画像や動画に支えられながら明確に伝わる。

レベル2：そこからコンテンツを作る

その変更が、投稿になり、記事になり、スクリーンキャストになり、意思決定の理由を説明するコンテンツになる。仕事自体はもう終わっている。このレベルは、それをリリースノートの中に埋もれさせて消えさせることを、ただ拒否するだけのことだ。

Linearが動画とデザインアセットを投稿スレッドと組み合わせ、新機能を紹介しながらプロダクトへのエンゲージメントを生み出している例

レベル3：それを軸にセッションを開く

ウェビナー、ライブのウォークスルー、オープンなオフィスアワー。変更は、一人で読むだけのものではなくなり、みんなで体験するものになる。そして、その周りで交わされる会話自体が、アップデートの一部になる。

FigmaとVercelはどちらも、これを一貫して続けており、それを機能させている決断が2つある。ひとつは、セッションをアーカイブして公開すること。ライブ制作にかけた1時間が、そのリリースが終わったずっと後まで注目を集め続ける、恒久的な資産になる。もうひとつは、そのセッションが実は「プロダクトについて」ではないということだ。人々が何をやろうとしているかから始まり、リリースはそれを実現する手段として位置づけられる。このフレーミングのおかげで、ひとつのセッションが2つのオーディエンスに同時に応えられる。プロダクトを使ったことのない人を引き込みながら、既存ユーザーにも足を運ぶ理由を与えられる。

どちらの企業も、このコンテンツを一人で作るのではなく、パートナーやコミュニティメンバーと一緒に制作している。それによって制作コストは下がり、社内だけでは作れない信頼性を借りることができる。専門知識はすでに外側に存在している。あとはそれを招き入れる仕事をするだけだ。

FigmaとVercelは、直近のリリースをテーマにした定期的なウェビナーを開催し、後から見返せるようサイトにアーカイブしている。セッションは機能一覧からではなく、人々が作りたいものから始まり、多くの場合パートナーやコミュニティメンバーと共に制作されている。

レベル4：それを軸にイベントを作る

会場を成立させられるほど大きな変更のために取っておくレベルだ。Configがまさにそれで、ほとんどのチームがこのレベルに到達するのは、多くても年に一度だろう。一度も到達しないチームも多いが、それは失敗ではなく、妥当な結果だ。

Configは新製品の発表や大型アップデートを中心に組み立てられているが、そこだけに閉じてはいない。周辺のプログラムは、プロダクトとは関係なくFigmaのオーディエンスが気にかけていることに語りかけている。この組み合わせこそがすべての仕掛けだ。このイベントは、企業が伝えたいことと、オーディエンスがすでに求めていることの交差点に位置していて、発表はどのみち人々が参加するつもりだった何かの中に入り込んでくる。

これはFigmaが発明したものではない。おそらくDreamforceがそのオリジナルであり、誰もそれをPLGと呼ぶよりずっと前に、Salesforceはカンファレンスを「プロダクトの瞬間」として扱うテンプレートを確立していた。Figmaが磨き上げたのは、その温度感だ。1万人が世界中から集まり、一室に座ってB2Bソフトウェアのアップデートを聞くというのは、本来なら馬鹿げたことのはずだ。それが馬鹿げたことに見えないという事実こそが、その根底にある関係が本物であるとき、このメカニズムが何を生み出すのかについての、何よりも強力な証拠になっている。

判断力とは、マッチングにある。 小さな修正にレベル4の扱いを与えると、必死さが透けて見え、その後に続くすべてへの信頼を損なう。逆に、プロダクトの動き方を本当に変えるような変更にレベル1の扱いしか与えなければ、二度と戻ってこない瞬間を無駄にすることになる。大きな変更はそれほど頻繁には起きないからこそ、それを不用意に使ってしまうことのコストは高くつく。

デザインの出番

ここまで語ってきたことはすべてデザインの仕事だが、そのほとんどはデザインチームの管轄には入っていない。最初の一手は、ナラティブだ。 どんな変更にも、それが存在する理由と、それが重要である理由がある。仕事は、それをきちんと伝えながら、読む価値のある文章として書き記すことだ。ほとんどのリリースノートがここで失敗するのは、書き手にスキルがないからではなく、そもそも誰もそれを「ライティングの問題」として捉えていなかったからだ。

2つ目の一手は、基準そのものを変えることだ。プロダクトの外側に存在するコンテンツも、プロダクトと同じだけのケアに値する。 チェンジログのエントリー、ローンチ動画、ウェビナー、カンファレンスのセッション。これらは、本当の仕事が終わった後に片付ける「おまけ」ではない。れっきとしたファーストクラスの体験であり、受け取る側にとって重要な意味では、プロダクトそのものと同じように振る舞う。この姿勢さえ取れば、それ以外のほとんどすべてはそこから自然についてくる。

3つ目の一手は、ライブセッションやイベントもまた、体験デザインであると認識することだ。これはデザイナーがすでに理解している領域でもある。ペース配分、注意の向け方、始まったときに人が何を感じ、終わったときに何を持ち帰るか。これらはデザイナーがひとつのフローについて問うのと、まったく同じ問いだ。スキルはほぼそのまま転用できる。ただその方向に向けられていないだけだ。カンファレンスは自分たちが形作っていいものだと、誰もデザインチームに伝えていないからだ。

実際に必要になるのは、コピーライティング、ビジュアルデザイン、ストーリーテリング、そしてイベントプロダクションだ。この4つすべてに強いチームは少なく、それはごく普通のことであって、失格の理由にはならない。今使えるツール群は、数年前なら専門家が必要だったレベルまで、そのギャップのほとんどを埋めてくれる。制約になっているのは、ほとんどの場合能力ではない。これに何ひとつ挑戦していないチームは、どれだけ人員を追加しても取り戻せないほどの成長機会を、みすみす取りこぼしている。

このやり方で仕事をすることから生まれるのは、チームが自分たちのロードマップとどう向き合うかという関係性の変化だ。リリーススケジュールは、社内向けの計画書であることをやめ、プロダクトがどこに向かっているかについて、継続的で信頼できる主張を組み立てるための素材になる。ほとんどのチームは、これに必要なものをすでに持っている。ただ、それを公開していないだけだ。

見落としがちなのは、これをうまくやっている企業のほとんどが、B2Bだという事実だ。Figma、Linear、Vercel、Notion。どれも消費者向けに販売しているわけではないのに、どれも通常はコンシューマープロダクトに結びつけられるような注目を、リリースの周りに生み出している。違いは市場ではない。彼らはプロダクトのアップデートを「その場に居合わせる価値があるもの」として扱っている、というだけのことだ。コンシューマー企業はその感覚をずっと理解してきたが、エンタープライズソフトウェアはそれをほとんど忘れてしまっていた。

これが生み出す変化は、チェンジログそのものよりも大きい。アップデートが不透明な企業は、誰にも注目する理由を与えず、だから誰も注目せず、すべてのリリースは静寂の中に着地する。このやり方で仕事をする企業は、最終的に、何がリリースされるかを見守り、その方向性について意見を持ち、欲しかったものが届いたときには歓声を上げるユーザーを手に入れる。そのオーディエンスは予算ではなく透明性から作られるからこそ、ほとんどどんな規模のチームにも手の届くものになっている。

次回、第二章「ブランドユニバース」に続く。 人々に愛されるプロダクトが、トーン・オブ・ボイスではなく人格を持っているのはなぜか、そして、それを本当のものにするためにプロダクトの周りに何が作られているのかを扱う。公開されたらメールで届くので、追いかけておく必要はない。

その間に、ここで書いたことが自分のプロダクトについて何か疑問を投げかけたなら、あるいはこれが自分の組織の中でどう見えるかを考えているなら、この文章を届けたメールに返信して、どこで行き詰まっているか教えてほしい。すべて目を通し、力になれそうなものには返信している。