ソフトウェアテスト自動化プラットフォーム「Autify(オーティファイ)」のプロダクトマネージャー守屋です。

今回は、Autifyで運用している「CS(カスタマーサクセス)チームを巻き込んだプロダクトの仕様設計」についてまとめたいと思います。

プロダクトの機能開発に取り組む方は、仕様を決める段階ではリリース後のことまでなかなか想定しづらいと感じることがあるかと思います。そのような課題を解決して、リリースした機能をお客様に確実に届けたい時に、今回の事例が参考になれば幸いです。

Autifyは、AIを用いた、ノーコードのソフトウェアテスト自動化プラットフォームです。

以前Autifyでは、開発を進める中で「新しい機能をリリースしても、うまくその機能のことがお客様まで伝わらない」という問題が度々起こっていました。

機能をリリースしたときにドキュメントがないため認知していただけなかったり、「この機能はなんですか?」というお客様の問い合わせを受けて初めてCSメンバーが新機能を認知する、ということも起こってしまっており、リリースした新機能を確実にお客様に伝えられるようにワークフローから改善を行う必要がありました。

このような問題が起こった背景として、どのような機能がどのような狙いで開発されているのか、また具体的にどのページがどのように変わるのか実装に関わるメンバーしか知らないという状況がありました。

その状況を改善するため、実装がほぼ終わったタイミングでメンバー向けに新機能をデモする場を設けていたりもしていました。

社内に新機能を紹介するデモも開催していた

しかし、デモからリリースまでの準備期間が十分ではなかったり、タイミングが合わずにデモの実施がリリース後になってしまう場合もありました。また、デモだけでは機能の詳細が社内であっても十分に伝わりきらないことがあったりと、問題が解消されたとは言えない状況でした。

本来は、開発に入る前から「誰のためのリリースなのか」「どうリリースするのか」「どうやってお客様に届けるのか」を社内で一体となって、余裕を持って準備する必要があります。CSチームのメンバーから提案を受け、プロダクト開発のより早い段階から社内での機能理解の促進と顧客とのコミュニケーションを行える仕組みの設計を始めました。

課題を解決するために、仕様設計の段階でCSのメンバーと一緒に「どのようにお客様に届けるのか」を確認した上で開発に移る「PRD (仕様要求書)レビュー」の場を設けることにしました。さらにPRDの中に「コミュニケーションチェックリスト」というテンプレートを用意しました。

Autifyでは、Notion上でPRDをつくっています。

Autifyでは、Notionを使って「PRD(仕様要求書)」をつくっている

そして、PRDのテンプレートの最後に、リリース方法やお客様へのアナウンス方法を決めるためのコミュニケーションチェックリストを組み込んでいます。

アナウンス方法・リリース方法・ドキュメントの改善点をまとめる「コミュニケーションチェックリスト」

顧客コミュニケーションの観点からCSチームとして開発前に知りたい項目をテンプレート化し、仕様を検討する段階でプロダクトマネージャーとして答えていきます。

例えば項目としては以下のようなものがあります。

  • 具体的に、どのようなお客様にどのような影響のあるリリースなのか
  • どのようにリリースする予定か (ex. 対象は全ユーザー? 一部ユーザーのみ?)

PRDを作成し、チェックリストを埋めた後は、CSチームメンバーと週2回開催している「PRDレビュー」のミーティングに持ち込みます。その場でみんなにPRDを読んでもらい、「リリースと同時にドキュメントの更新が必須か」「どのようにアナウンスするべきか」などNotion上にコメントをもらい、リリースに向けた懸念事項やTODOを洗い出します。

日頃から一番お客様とコミュニケーションを取っているCSチームメンバーの視点から、「このUIだと伝わりづらい」「こういう単語を使った方が伝わると思う」といったフィードバックをもらうことで、機能を改善するチャンスにもなっています。

週2回のCSチェックのミーティングで、新機能のコミュニケーションについて検討する。
レビューの中で作成必要だと判断したドキュメントはタスクとして切り出し。何がいつまでに必要なのかが事前にわかるようになっている。

これらの仕様の段階を管理するカンバンボードもNotionで作成しています。

Autifyでは、開発に進めることが決定した「Ready」の段階に移る前に、「In Review」という社内レビューのカラムを設けて、お客様とのコミュニケーションの観点でもレビューをもらった上で開発に進めるように管理しています。

開発に移る前の段階で「PRDレビュー」を終えてから開発に入る仕組みにしている。

このように、開発前にお客様とのコミュニケーションを確認するフローを取り入れたことで、各チームが余裕を持ってリリースに向けた準備ができるようになりました。

例えば、リリース前にドキュメントを用意し、リリースと同時にお客様向けに案内することができるようになり、新しい機能の説明を求められた時にすぐに適切な案内ができるようになりました。

また、CSチームのメンバーに早期のフェーズから関わってもらったことで、以前よりチーム一体となってプロダクト改善に取り組めていると感じます。「プロダクトをより良いものにしていきたい」という思いがチームを超えて共有され、みんな積極的に参加してくれています。

CSチームメンバーも「PRDレビュー」に積極的に参加してくれている

せっかくリリースした機能も、お客様が活用できなければ価値は生まれません。そして、お客様の生の声を一番聞いているのはCSチームのメンバーです。

「PRDレビュー」は小さな取り組みですが、各メンバーの知見をプロダクト開発の早期から取り込み、一緒に計画を立てていくのに大きく役立っています。

これからも、お客様のバーニングニーズを確実に解決するための仕組みを育てていきたいと思います。