小さくても大きくても、チームでリリースしたものは全力でお祝い・がつがつアピール・お客様の声をすぐに共有するという活動を推奨したい
プロダクトマネージャーにとって、自分が関わったプロジェクトがローンチされる瞬間というのは、それが派手でも地味でも、小さくても大きくても、このうえなく嬉しいもののはず。そしてそれは、プロダクトに関わっておられるすべてのメンバーにとっても同様かと思います。
ただ、こうしたリリースの直後、例えおこがましくとも雰囲気 and 職責上、「チームでこんなことをやりました！」と声高に主張・お祝いすべき我々 PdM の多くが、実は「リリース」までに全力を投入しすぎるが故に、その直後はほぼ抜け殻。精神力ゼロ値。結果、リリース直後に求められる、地味に重要な「お祝い」のフェーズにおける活動がおざなり・おろそかになる場合があるよなぁ、と最近感じており。（かなり会社・個人のそれぞれの状況・性格によるとは思いますが）
機能・改善リリースのそれぞれをきちんとお祝いすること。社内にアナウンスすること。リリース直後から様々な手法でお客様の声を集め、それをチームにフィードバックしていくこと。
今回はそんな、ここ 1 年くらいで個人的にとても大切にするようになったリリース直後の 自分なりのお祝いのやり方と、それを行う理由について考えをまとめました。チームにもプラスの影響しかないのでやらない理由がない。自分の今までの他記事 (1) (2) (3) と比較して 40% 程度の文量＋ソフト面の話ですが、インターバルとして。
想いが強すぎて記事タイトルが馬鹿みたいに長くなってしまった…US メルカリでプロダクトマネージャーをしております、フリッツ がお送りします。
01# ここで定義しているお祝いとはなにか
端的には以下画像のような、全社（もしくは適切な通知チャンネル）宛ての Slack 投稿をイメージしていただければ良いかと。本記事は、これとその後の活動にまつわる様々な考えをまとめたものです。
単に「お祝い」と書くと少し陳腐に見えるかもですが、ご覧の通り、本記事においては「社内へのリリース（再）通知」の意味も兼ねています。
※ 上記画像の内容は 100% 架空のものです。
02# お祝い・社内通知を行うべき 8 つの理由
早速本題。UX 改善・機能リリース・キャンペーンローンチ等のリリースごとに、これを Slack の適切なチャンネルに投稿して「お祝い」を行うこと。プロジェクトリードを行う方は、大小の差はあれど常に行っているかとは思いますが、こうした行為がどのような効果をもたらすのか？を改めて自分に問い直してみました。8 つほど出てきた。
01#. チームの開発に一旦の区切り・メリハリをつけることで「延々と続く開発」という雰囲気を断ち切る
プロジェクトがリリースされても何もせず、「はい、次！」という状況があまりにも長く続くと、実際には多くのリリースを行っていても「延々と先が見えないトンネルを走り続けている」かのような感覚に陥ってしまいがち。
現実には確かに、もちろん一つのプロジェクトが終了したら直ぐに次がやってくるので、実質的な状況そのものは変わらない。しかし、きちんとしたお祝いは走りっぱなしだったチームメンバー全員で一息つき、少なくとも数日は充実感を感じてもらい気分をリフレッシュさせる効果があります。
（多くの場合、本来リリース通知はこの最後のステージ。それ以前に、ビデオ会議を通してのリリースに立ち会う瞬間や、コロナ前ならば社内での拍手（懐かしいなぁ…）・カウントダウンなどなど色々なステップが含まれるかと思いますが、本記事では割愛しました。（というかコロナ×グローバル開発でこれくらいしかできなくなった…）
02#. ひとまず皆から「ありがとう」「いいね」をもらうことで、まず最初の小さな成功体験を積み上げる
リリース通知には当然、たくさんの Slack のリアクションがつきます。最終的な目標ははもちろんユーザーのみなさまに喜んでもらうことですが、チームが何週間も何カ月も取り組んできた努力に対して、完了直後にポジティブなフィードバックをもらえるというのは大きい。これひとつを「小さな成功体験」と言ってしまうのも過言ではないかと思います。
特に、新しいメンバーにとってはなおさら。
自分が新しく入った会社で「まずはこれね」と渡された小さなプロジェクトでも、最初のリリースはやっぱりドキドキしませんでしたか。新しいメンバーにとっては、こうした Slack のスタンプひとつとっても、多くの場合「ほっと一息つける、小さいけれど最初の成功体験」になっている気がします。
例えミクロないいねひとつであっても、こうした「成功体験」は心理的安全性や次のプロジェクトへのモチベーションにもつながるので、なかなか馬鹿にしたもんでもないかなぁ、と最近は思っています。
03#. プロダクトマネージャーからチームメンバーへの感謝の意を示すことができる・メンバーをスポットライトに当てる
コロナ禍がはじまって、僕の場合はもう 5 カ月以上、チームの誰ともリアルで会っていません。ビデオ会議はやっているにしても、やっぱりコミュニケーションの総量は明らかに減り、特にちょっとした表情で感謝の気持ちを伝えることが難しくなりました。
そんな訳で、Slack でリリースのお祝いをして、プロジェクトをリードしてくれた全員にメンションを飛ばし、感謝の意をきちんと伝えることは、方向として間違っていないはず。（ひょっとしたらウザがられている可能性もありますが笑、ストレートにモノを言うアメリカ社会において、今のところ感謝されこそすれ、文句はまだ言われていないので多分…大丈夫…）
また、これは会社にもよりますが、プロダクトチーム（開発・デザイン・QA等）の外・つまり経営陣や他部署においては、折衝の役目を担う PdM がどうしても注目されやすく、それ以外のメンバーの存在・活動がブラックボックス化しやすくなります。
リリース通知には、こうした構造的な問題をはねのけ、プロジェクトを真の意味で実現に至らせたチームのメンバーそれぞれにスポットライトが当たりやすくなるように調整する効果があります（特に開発難易度の高いプロジェクトなどは CTO からお返事を頂けたりする、みたいな例があるかと）
04# 社内のポジティブな雰囲気づくりに貢献できる・新たなプロジェクトのきっかけとなりえる
これはもう完全に感覚ですが、何度も何度もこうした大小のリリース報告を全社チャンネルに投げていくことで、最終的には社内全体のポジティブな雰囲気の醸成にすら役立つようになります（たぶん）。
「アプリのここホントに良くなってるよね！」「ウェブサイトも見違えるようになった！」「ウチのプロダクト、数年前と比べて本当に良くなった」といった社内全体の雰囲気醸成。具体的に何か見えるものがある訳ではないのですが、なんらかの副次的なメリットがありそうです（たぶん）。
実際に経験したメリットとしては、こうしたリリース通知が新たなプロジェクト開始のきっかけとなること。リリース通知からスレッドがはじまり、「このプロジェクトをキックオフする良いタイミングかもしれない」「ここまで来たなら、この先こうしたキャンペーンを展開できるのではないか？」などなど、他部署との連携がはじまった例は数知れず。
05# 他部署・カスタマーサポートへの周知の再徹底にも使える。落とし穴がすぐに見つかる
基本的に、特に大きなリリースにおいては他部署・特にカスタマーサポートへの連携・周知を当然ながら徹底します。しかし、(1) まさかこの部署に影響が及ぶとは思わなかった (2) 何百人もいるカスタマーサポートの隅々にまで機能が周知されなかった 等の事象は容易に起こりえます。
こうした状況も、全社チャンネルにリリースを通知することで (1) 該当通知を見た他部署の方から「ここの部分どうなっているか確認したい」といった問い合わせを受けたり、もしくは (2) 「一度リーダーから通達が来てたけど、この投稿を見たお陰でカスタマーをスムーズにご案内できました！」などの事例を実際に経験しています。
06# 社内からの早期フィードバックにつながる
リリース通知後、機能によってはすぐに通知コメントに、社内メンバーからのフィードバックがたくさん返信されてくる場合があります。「使ってみた！ここの挙動これで良いの？」「ここ、自分だったらこうしてたけど、この UX を選んだ理由は何でしょうか？」「ここ改善するなら、こっちも…」などなど。
自分達がやっていることが、孤軍奮闘ではなく気にされていると実感できる瞬間です。こうしたフィードバックに対し、場合によってはすぐに修正を行ったり、もう一度デザイナーと UX を議論したりと、ポジティブなサイクルを生み出すことができます。
07# フィードバック⇔改善のループを可視化し、プロダクトチームは社内のフィードバックを大事にしている事を行動で示せる
こうしたリリースの一部には、例えば以前にカスタマーサービスから依頼されていた UX の修正を含んでいたり、経営陣から過去に飛んできていた修正依頼が含まれている場合があります。
そうした修正をただ黙ってやるのではなく、リリース通知を通して、「プロダクトチームは自分達のプロジェクトをただただ進めているのではなく、関連部署からのフィードバックも大切にしています」というメッセージを行動を以て示すことができ、それはまた、未来の他部署がフィードバックを行いたい際の心理的安全性を向上させることにもつながります。
08# 社内での存在感をあげ、チームを徐々に強化していく
自分が過去 1 年に渡ってぎゃーぎゃーとリリース通知を全社チャンネルに垂れ流した結果、大きく実感していることの一つがこれ。
ひとつひとつのリリース報告に社内の方が目を通す時間はたとえほんの数十秒だとしても、こうしたリリース報告は塵も積もれば山となり、最終的にはチームの存在感を社内に知らしめていく大きなきっかけとなります。
こうした存在感の向上は、単にお給料的な意味よりも（というかそれよりも）多くの副次的な効果を PdM とチームメンバーにもたらします。こちらは詳しく 06# に書きました。
ざっと思うのはこんなところ。
ここから、お祝い・通知についての自分が実践している具体的・テクニカルな話をつらつらと。すべて、Slack のような社内コミュニケーション用のツールがあることをを前提として書いています、悪しからずご了承ください。（まぁメールでもできるっちゃできる）
03# 大リリースはすぐに全社チャンネルでお祝い
「大きなリリース」の定義は会社それぞれでまちまちかと思いますが、自分の場合は「UX に大きな影響を与えるもの」および「開発工数が 1 カ月以上にわたるもの」と定義しています。
こうしたリリースは、社内全員に周知することの重要性も高いので、なるべく多くの人間が参加している適切な Slack チャンネルにおいて投稿を行います。冒頭の画像を再掲：
都合上、全社チャンネルと書きましたが、適切なチャンネルは会社によってそれぞれ。US メルカリにおいては、こうした機能リリース・キャンペーン開始・UX の改善等をアナウンスするための専用のチャンネルがあり、社内の大部分の人間がここに参加しています。
自分の場合は月に 1-3 回程度使用しているイメージです。
04# 小リリースはまずはチームチャンネルでお祝い
社内全体にアナウンスするほどではないような小さなリリースでも、それぞれ、簡単でも良いからチーム内でお祝いすべき、のはず。なので、バグ修正や文言修正などのマイクロリリースは除きつつ、ある程度のサイズ感があるものは、チーム内でお祝いしています。イメージとしては以下のような感じの簡潔なもの：
もう少しパーソナルな感じですね。時期によるものの、自分の感覚ではこちらは月換算するとだいたい 7-8 回程度はお祝いしているイメージ。
05# 小リリースがある程度溜まってきたら、全社チャンネルで改めてお祝い
小さなリリースも、塵が積もれば山となります。ので、前項でチーム内でお祝いし続けたものは、ある程度の量がたまったら全社へアナウンス。ただ、あまりにも内容がランダムだと、これを読む方が把握しづらいため、一定のグルーピングを行って通知しています。イメージとしては以下：
US メルカリで言えば、例えば出品画面・ホーム画面・通知画面などなど画面それぞれでの UIUX 修正がある程度溜まってきたら、という感じ。
06# 何百回と繰り返した結果、僕がたどりついたお祝いフォーマットとその意図まとめ
僕自身は過去 1 年にわたり、極端な長文・短文・項目の変更などなど、いろいろとフォーマットを変えてこうしたお祝い・通知を行ってきました。何百回と行ううち、我流でたどり着いた現在のフォーマットは以下の通り。
注意しているのはこんなところ：
・ 長いと読まれず目的を果たせないので、極力短くする
・ ユーザーへの影響がみんな一番興味のあるところ
・ 変更点は誰でも見つけやすいように具体的に書く
・ プロジェクトに関わった人は全員きちんと含める
・ 画像があると圧倒的に注目されやすいので画像を添える
こうした投稿はしっかりとスタンプという形ですぐに謝意が届くので、やっぱり自分も嬉しいし、チームの皆も嬉しいんじゃないかなぁ。
07# あまり主張するのが好きではなかった自分が強くアピールをするようになった 4 つの理由
さて、チーム内でのお祝いは数多くやっていたものの、CS や社内ステークホルダーとのコミュニケーション等のどうしても必要な場合を除き、もともと自分は全社に対してチームの成果を強くアピールする行動が苦手でした。
「そんな大袈裟にしなくても…」「やることをしっかりやっていれば、いつかみんな認めてくれるだろうし。」「余計なメンション飛ばしまくるのも申し訳ない…」「チーム内だけでお祝いすれば…」といった考え方。
しかし、これに関して VPOP から「あなたもっと主張しないと（以下略」とフィードバックを受けたことがきっかけでこれを改め。振り返ってみると、以下のような 4 つのファクターが行動を変えられた理由な気がします。
01# 主張しない/することによるデメリット・メリットが非常に大きい
主張しないことによる最も大きなデメリットは、自分のチームの動きが他部署・また経営陣からブラックボックス化してしまい、「最近見ないけどなにやってるんだあのチームは？」と思われてしまう事。経験談ではありませんが、極端な話、何やってるか良く判らない＝たいしたことやっていないと思われてしまう可能性もあり、チーム存続の危機にすら発展しえる話です。
主張することによる最も大きなメリットはその逆。「あのチームは良く頑張っている」という評価からの、「協力しよう」といったコラボレーションが生まれることや、「来期は予算を増やそう・チームメンバーを増やそう」といったチームの強化に至ることすらありえます（明確にそうかどうかは多くの場合わかりませんが）
これは最終的に「より良いプロダクトを作る」という PdM のゴールに直結するものであり、その為ならば、と行動を大きく変えるに至りました。
02# チームのことを思えばこそ、自分がやらないのは独りよがり。
ぎゃーぎゃーと主張をせずとも、日々多くの関係者とコミュニケーションを取る必要がある PdM である以上、自分は経営陣・他部署・上司それぞれとのコミュニケーションの中で自分のやっていることを伝えれば十分、というマインドセットを持っていました。
がしかし、考えてみればこれは（チームメンバー）にとっては迷惑な話で。もちろんチームメンバーのそれぞれも自分の部署内で自身をアピールする方法を持ってはおり、評価に直結する場所はそこのはずです。しかし、特に他部署・経営陣と言ったステークホルダーにとってはやはり PdM がメインのコミュニケーションチャンネルであり、（直接的な効果は見えないものの）ここでチームの努力を主張していかないことには、最終的にチーム・チームメンバーそれぞれのためにはなりません。
03# フィードバック・依頼が沢山くるようになる
これはもうシンプルな話で、リリース通知兼お祝いをしっかりやっていると、リリース直後から機能に対するフィードバックが社内の思ってもみなかった人から来るようになります。当然、既に検討した部分であったりそうでなかったりしますが、中には UX を大きく改善しうるアィデアもあり、非常に大事にするようになりました。
もう一つが、社内でこうしてリリース通知を行い続けていくことで、「ここ使いづらいんだよな～。そうだ、最近活発に活動しているあのチームに試しに修正をお願いしてみよう！」といった小さな依頼が自分のチームに気軽に投げ込まれるようになります。
当然、これも「良いプロダクトを作る」ことを目標にしている PdM にとっては願ってもないもので、非常にありがたい話です。
04# アメリカ社会は主張の文化
メルカリ US は、個人的にはアメリカの文化・日本の文化が混ざり合った、双方の良いとこどりをしている非常に稀有な会社だと思っています。
アメリカ社会は基本的に「沈黙は金、雄弁は銀」とは対極にあり、チームの成果はしっかりとアピール、極論を承知で言えば何事も交渉を前提としていたりする文化です。（交渉する・しないで自宅のインターネットプロバイダの代金が倍くらい違ってくるというのは有名な話）BLM のスローガンでは「声を上げないものは人種差別に加担している」といった主張も強くされており、やはり多文化・多民族がひとつの国の中で生きてきている以上、それぞれがしっかりと主張をしていなければ生き残れない、そんな文化が人々の価値観の根底に脈々と受け継がれている気がします。
あまりここで詳しく書いてもしょうがないので割愛しますが、US メルカリもやはり、声をあげてしっかりと自分の存在・成果を主張していくことの重要性が比較的高い気がしています。
※「沈黙は金、雄弁は銀」は実はイギリスの諺なんですね。へぇ～。
なお、これらの効果はどれもリリース通知をひたすら続けることで二字曲線を描くように少しずつ強くなっていくものであり、必ずしもすぐに効果を実感できるものではないかもしれません。
08# 一週間ほどたったら、お客さまの声をリサーチしてチームに生の声を届ける
リリース通知を行って一週間ほど経ったのち、お客さまの反応を探り、生の声をチームに届けるようにしています。Facebook , Twitter , アプリへのレビュー、ソースはなんでも良いのだけれど、リリースした機能に関してユーザーがどう反応したか・どう喜んでくれたかをチーム内で共有します。
もちろん、リサーチする中でポジティブな声もネガティブな声も出てきますが、自分の場合はここではポジティブなものに留めます。ここでの目的は、改善点やバグを探すことではなく、ひとまずはお客さまの喜びの声をチームに届け、更なるモチベーションの源泉としてもらうことに限っています。
09# 余談 1 ：期の終わりにリリース総まとめをチームにシェアすると喜ばれる
余談その 1 。期の終わりと言えば、弊社では誰もが自己評価・他己評価の記入に奔走する時期です。ふと「役に立つかな？」と思い以下のような投稿をその昔したところ、大変喜ばれました。期の終わりにリリースした機能の総まとめリストをシェアするの、おススメです。
10# 余談 2：大きなリリース後にはチームで写真を撮る、という文化もアリだよね
余談その 2 。僕自身はなんというか「ちょっと大仰だなぁ」と思ってしまうが故に（＋写真を嫌がる人もいるので）やってはいませんが、過去には大きなリリースの際に該当機能が映った iPad と共にチームで写真を撮る、といった PM の方もいました。個人的にはアリ。良い思い出です。
11# 余談 3 : もうあまりやらないけれど、チームランチ・飲み会もお祝いのひとつだよね
余談その 3。シリコンバレーに来てからはすっかりやらなくなった慣習ですが（さみしい）、大きなプロジェクトの終了後や、期の終わりには大規模なチームランチ・チーム飲み会を開くというのも良い気分転換・お祝いの方法ですよね。
メンバーにいちいち許可を取るのが面倒なので、過去に撮ったアメリカのパブの写真で代用。
12# まとめ
我流で練り上げてきたノウハウ・マインドセットですが、これを実践することは割と本気で 100 利あって 1 害無しと思っています。
正直「読んでみたらたいしたことなかった、だいたい既にやってるわ～」という方が大半だとは思うのですが、改めて自分なりにこの部分の重要性を考えてみたかったので本記事を考察、となりました。もし、やられていない方がいらっしゃいましたら是非試してみて頂ければと思います。
13# 次回予告
UX 調査周りの勉強をしているのですが、思ったよりもフィールドが深すぎて勉強で手一杯＆うかつなことは書きたくないので、次回もひょっとしたら PdM 関連のお話で軽めなものを考えてみようと思います。
ここまでお読みいただきありがとうございました。Twitter @fmkpro1984 もやっていますので是非フォローしてくれれば嬉しいです。
それではまた。
お断りとお願い
本稿および note の全記事は個人的な解釈に基づいたもので、所属していた/している会社の意向・見解とは一切関係ありませんので、その旨ご理解いただけますと幸いです。
いいなと思ったら応援しよう！
