こんにちは。「護りたい。その想いを護る。」株式会社ゼストのプロダクトマネージャーを担当している川添です。
2024年3月12日、私たちのフラッグシッププロダクトである「ZEST SCHEDULE」のフルリニューアルをおこないました!わーい!
ゼストに関わるようになって2年。本当にいろいろあったので、リニューアルに関してはいくつかの記事に分けてじっくりと記録しておきたいと思うのですが、まずはフルリニューアルということで「新しいプロダクト開発」との違いや、気をつけるべきポイントを言語化しておこうと思います。
既存プロダクトのリニューアルと新規開発の違いは?
一番の違いは「すでに使ってくださっている顧客がいる」ことです。これに起因する「良さ」も「つらさ」もありました。
良さ
開発途中で実際の顧客にお話を聞かせていただける!
数えてみると、リニューアルプロジェクトが本格始動した2023年2月から実に44回の顧客ヒアリングをおこないました。既存の機能をどのようにブラッシュアップするのか、どのような新機能を追加するのか検討するときに、顧客のニーズや背景を直接聞いて理解できるのは非常に助かりました。
既存プロダクトのデータがある!
「この機能を使っている顧客は全体の○%だから、見直しの必要がありそう」「その設定をしている顧客はほぼいないから優先順位を下げられそう」など、ファクトと突き合わせながら仮説を立てたりブラッシュアップできたりと重宝しました。
ニーズがあるので安心してリソースを投下できる!
どこまでリソースを投じられるかはCTO豊島さんをはじめとした経営陣が判断していましたが、現場の私たちからすると「本当にこのプロダクトにここまで時間と人員を割いて大丈夫なのか…?」という不安を抱くことなく、よりよいプロダクトを作ることに全力投球できました。
つらさ
一方でつらかったのは「現在使われている機能を落としづらい」ことです。その結果、小さく開発できない、一定の機能が揃うまでリリースできないという課題がありました。
特に私たちの既存プロダクトは「設定自由度の高さ」が特徴で、できることの幅が途方もなく広かったが故に、「標準化」と「リリース速度を上げる」ことの難易度が非常に高い状況でした。
目標としている2024年3月リリースを実現するためには、上手に機能を削ぎ落としながらスピードアップを図る必要がありました。
フルリニューアルで気をつけるべき3つのこと
「現在使われている機能を落としづらい」という状況を踏まえて、気をつけたポイントを詳しく見ていきたいと思います。
1. 絶対に落とせない機能を把握する
「この機能は必要ですか?」といったクローズドクエスチョンではなく、「現在はどうしてこのような運用になっているのか」「代替機能に変えた時にどういう懸念があるか、現実的に耐えうるのか」という点に焦点を当てたヒアリングを心がけました。
そのために、最初におこなったのは「業界に対する解像度を高める」ことでした。私たちのプロダクトは在宅医療・介護業界向けなので、保険制度や電子カルテ・レセプトに関する情報などを初期にガッツリ調べ、さらに法改正情報はGoogleアラートに登録して随時追いかけるようにしていました。
そして、顧客のおかれた状況を理解した上で、顧客の日々の業務をストーリー化した仮説を立て、そのうえで「顧客ヒアリング」でファクトを集めました。
2. 経営陣とリリースできるラインを都度すり合わせる
リニューアルプロジェクトは基本的にはTechチームにゆだねられていたので、中盤くらいまではとにかくファクトを中心にあるべき姿を模索し、月に1回、経営陣向けに進捗報告をしていました。また、営業本部長とPdMとで既存顧客向けのリニューアル説明会を何度か開催したのですが、その準備を通してプロダクトの構想をすり合わせていました。
ただ、プロジェクト中盤くらいからTechチームからは「初期リリースの落とし所はどのあたりなのだろう?」「バックログアイテムの優先順位はこれで合っているんだろうか?」という声が、経営陣からは「初期リリースではどこまで実装できるのだろう?」といった声が届き始めたため、週に1回、経営陣と主要Techメンバーとでプロダクトバックログとにらめっこする定例会を設けて密にすり合わせることにしました。
開発は着手してみないと全貌がわかりにくく、どうしてもずれ込みやすい側面があるため、こまめに状況把握をおこなうことでお互いの不安解消につながったと思います。
また、「この機能の実装はまだ先になりそう」などの見通しが共有できたので、「ここまでできたらリリースしよう」という基準が見える化できました。
結果として、当初予定になかった「ここまでの完成度で大丈夫だから、展示会でデモできるようにしよう!」「リリース前だけど、実際にお客様の環境をつくってお客様自身にも見てもらおう!」といった取り組みも実現できました。
3. Techチーム内でスピードを落とさない工夫をおこなう
PdMの観点でいうと
- Slackでエンジニアさん・デザイナーさんからメッセージが来たら即レスする
- Notionを使い倒して仕様書を最新に保てるようにする
- Notionを使い倒してバグ報告からプロダクトバックログを積むフローを作る
- 聞きそびれをなくすためのエンジニアさん・デザイナーさんの定例会など随時開催
といったあたりを気をつけていました。
余談ですが、プロジェクト全体を通して「Notionがなかったら詰んでいたな…」と思う瞬間が多々ありました。Notion大好き!
また、Techチーム全体で各自がいろんな工夫をしていたので、そのうちインタビューしてみようと思います。
いかがでしたか?この記事を読んでちょっとでもゼストに興味を持たれたら、ぜひ一度、弊社のWantedlyをチェックしてみてください!