SaaSスタートアップでのリリースの届け方

この記事は株式会社Boulderのアドベントカレンダー5日目の記事です。

BoulderではChiefProductOfficerとして
- なにを作るか
- どう作るか
- 画面デザイン
- 実装
- デリバリー
あたりを主として担当していて、
今回は最後の「デリバリー」について実践していることをご紹介します！

特にBtoB SaaSにおいて、
- 初期クライアントとの共創関係
- 仮設実証の速度
は非常に重要な要素なため、コストをかけて開発したものがユーザーに認知されないままということを避けるために日々試行錯誤している内容です。
（もちろんそもそも自然と認知できるような情報設計が大事）

リリースからデリバリーへ

一般的に新しい機能などを本番に反映することは「リリース」と呼ばれると思いますが、個人的にリリースという言葉に「反映しました！あとよろしく！」という一方的なニュアンスを感じてしまうため、ユーザーに届けるところまでがリリースであるという意味を込めて意識的に「デリバリー」という言葉を使っています。

ユーザーに直接伝える

まずどうやってユーザーにアップデートを伝えるかですが、今BoulderではユーザーとSlackのチャンネルを使ってそこで直接伝えるようにしています。
一般的にはメールやサービス内のお知らせページに掲載するケースが多いように感じていますが、Slackにすることによって
- ユーザーからのリアクションがある
- 埋もれることが少ない
などのメリットがあります。特に前者については実際使ってみた感想をいただけたり、逆にリアクションがないことで「あまり刺さらなかったのかな？」と推測できたりします。

また、ユーザー向けにはある程度まとまった粒度で連絡していますが、
社内向けにはより細かい粒度で展開しています。
これによって
- セールスやカスタマーサクセスがよりタイムリーなアップデートを話のネタに使える
- 日々改善が進むことによりチーム全体のモーメンタムの増大
というような効果狙っています。地味に大切なポイントとして投稿にみんながリアクションをくれるため、開発者のモチベーションも上がります！

フィードバックの反映の第一報を可能な限り早く

定期的にユーザーと利用状況の確認や運用で困っていることの解決のためにミーティングの機会をいただいているのですが、そこでプロダクトへの不満や要望を貰う場合があります。
（もちろん言われたものをそのままやるわけではなく、基準をもとに精査した上ではありますが、）そうした要望にいかに早く答えるかは強く意識していて、可能な限り当日、難しくてもその週のうちに完全ではないにしろ何かしらの形でプロダクトに反映しユーザーに連絡するようにしています。
「言っても無駄」ではなく、「伝えれば改善される！」という実感からさらなる要望がいただける良いサイクルが構築できるため、ここの強度は今後も保っていきたいです。

継続的にやり続ける

「一気に大きく変えず、小さい方向修正を高い頻度で繰り返すこと」
実践はなかなか難しいですが、β版のローンチ後半年以上ほぼ毎週新機能や改善をリリースし、それをユーザーに届けてきました。
文化は習慣から生まれますが、今後チームが拡大していってもユーザーに価値を継続的に届け続ける文化を残すために日々の積み重ねを大切にしていきます。

今後やりたいこと

今のデリバリーからさらによくしていきたい点としては、
- プロダクト上でのガイド
- デリバリー後の利用状況の細かいトラッキング
などがあります。前者についてはともするとユーザーの操作のノイズにもなりやすいため、さまざまな方とディスカッションして進めていきたいと思っています。そういった話やデリバリーの文化について興味のある方はtwitter( https://twitter.com/fnwiya )かコーポレートサイトからお気軽にご連絡いただけると嬉しいです！

株式会社Boulder（ボルダー）